9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Martin Harriss <martin@Princeton.EDU>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] stupid vga tricks...
Date: Wed, 18 Jul 2001 00:02:15 -0400	[thread overview]
Message-ID: <3B550A47.12D7AEC1@princeton.edu> (raw)
In-Reply-To: <3.0.5.32.20010717184226.013ea858@mail.real.com>

Does the machine in question have other (non-VGA) PCI hardware made by
ATI?  If so, you may indeed be seeing a problem similar to what I saw.
The same technique may be used to fix the problem.

Martin


Fariborz 'Skip' Tavakkolian wrote:
>
> In the process of doing an install from VN's CD on an IBM Aptiva I get the
> following:
>
> aux/vga: vgactlw: <linear 0x800000 0x1000000>: not enough free address space
> rio: can't open display: initdisplay: /dev/draw/new: no frame buffer
>
> The buildin vga is an ATI Mach64. I've attached the vgginfo.txt and vgadb
> (I added
> the entry for 'Aptiva'). Has anyone else seen this?
>
> P.S. I've looked through the old mail and the only explanation to a similar
> problem
> is the following:
>
> >From: Martin Harriss <martin@Princeton.EDU>
> >Organization: Princeton University CIT
> >X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
> >X-Accept-Language: en
> >To: 9fans@cse.psu.edu, 9trouble@plan9.bell-labs.com
> >Subject: [9fans] S3 video problem solved, and a patch
> >Sender: 9fans-admin@cse.psu.edu
> >X-BeenThere: 9fans@cse.psu.edu
> >X-Mailman-Version: 2.0.1
> >Reply-To: 9fans@cse.psu.edu
> >List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> >List-Archive: <http://lists.cse.psu.edu/archives/9fans/>
> >Date: Fri, 23 Feb 2001 12:10:10 -0500
> >
> >I took another look last night at the problem that I was having with the
> >S3 video card (was getting "no free address space" message.)  The good
> >news is that I fixed the problem.  The following description is probably
> >old hat to the Bell Labs folks, but may be of interest to other 9fans.
> >
> >The S3 video driver, along with other drivers of various kinds, calls
> >"pcimatch" to find a data structure kept by the pci code that holds card
> >configuration information.  Included in that information is a physical
> >address that the kernel must map in order to access the frame buffer.
> >The pcimatch routine looks up entries based on PCI vendor ID and card
> >ID.  Either can be wild-carded in the call to pcimatch.
> >
> >It so happens that I have another S3 card in the system in question - an
> >S3 sound card.  (Not supported by Plan 9, but I sometimes run other
> >software on this system.)  The call to pcimatch in vgas3.c was finding
> >the information on the S3 sound card, since all it was looking for was
> >the vendor ID.  This information was not at all what the video driver
> >wanted, and it barfed. (Note that it's not possible to include a device
> >ID in the call to pcimatch, as there are many device variants of S3
> >video cards, all supported by the same driver.)
> >
> >The following (admittedly ugly) patch to vgas3.c fixes the problem by
> >forcing vgas3.c to ignore cards that are not display adapters.  It
> >probably argues for a more intelligent pcimatch routine with an
> >additional argument for device class, but I don't feel like opening that
> >can of worms right now.
> >
> >Martin Harriss
> >
> >---------------------------------------------------------------------
> >diff -c vgas3.c vgas3.c.dist
> >*** vgas3.c     Fri Feb 23 11:46:40 2001
> >--- vgas3.c.dist        Wed Feb 21 11:21:13 2001
> >***************
> >*** 100,118 ****
> >        mmiosize = 0;
> >        mmiobase = 0;
> >        mmioname = nil;
> >!
> >!       /*
> >!        * S3 makes cards other than display controllers. Make
> >!        * sure we've found a display controller and not
> >!        * one of their sound cards.
> >!        */
> >!       p = nil;
> >!       while (p = pcimatch(p, PCIS3, 0)){
> >!               /* device class 3 is display card */
> >!               if (p -> ccrb == 3)
> >!                       break;
> >!       }
> >!       if (p) {
> >                for(i=0; i<nelem(p->mem); i++){
> >                        if(p->mem[i].size >= *size
> >                        && ((p->mem[i].bar & ~0x0F) & (*align-1)) == 0)
> >--- 100,106 ----
> >        mmiosize = 0;
> >        mmiobase = 0;
> >        mmioname = nil;
> >!       if(p = pcimatch(nil, PCIS3, 0)){
> >                for(i=0; i<nelem(p->mem); i++){
> >                        if(p->mem[i].size >= *size
> >                        && ((p->mem[i].bar & ~0x0F) & (*align-1)) == 0)
> >
> >
>
>


  reply	other threads:[~2001-07-18  4:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18  1:42 Fariborz 'Skip' Tavakkolian
2001-07-18  4:02 ` Martin Harriss [this message]
2001-07-18  4:11 forsyth
2001-07-18  4:24 forsyth
2001-07-18  4:34 forsyth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B550A47.12D7AEC1@princeton.edu \
    --to=martin@princeton.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).