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)
> >
> >
>
>
next prev parent 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).