Date: Thu, 23 Feb 1995 15:52:58 -0700 (MST) From: Jeremy Chatfield <jdc@day.xinside.com> To: davidg@Root.COM Cc: jkh@freefall.cdrom.com, jeffh@cybernetics.net, current@FreeBSD.org Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP Message-ID: <199502232252.PAA11444@crab.xinside.com> In-Reply-To: <199502232041.MAA00214@corbin.Root.COM> from "David Greenman" at Feb 23, 95 12:41:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman writes:
> >> Ok, for those of you who have been keeping up, I tried to re-install 2.0
> >> and ended up back with 950210-SNAP because my floppy didn't work with
> >> 2.0 This time, I ftp'ed the the 950210-SNAP from scratch, and did not
> >> use one single non-950210-SNAP file (except my X server).
> >
> >[FYI - either -hackers OR -current, but never both. I have adjusted
> > the CC line. Thank you]
Damn - and I follow the hackers. Oh well...
> >> I run Xsetup again, choose Number9 I128 w/4MB, same resolution, same
> >> color depth (16 colors). I load up X, and things are no longer OK.
> >> Before I go into depth with the problems, let me say that I ran this
> >> server under 2.0 for a while (about a month) with 0 problems. I have not
> >> done one thing to my machine since then. It is _EXACTLY_ the same as it
> >> was then. _Something_ that was changed between 2.0 and 950210-SNAP is
> >> causing this problem, either directly or indirectly. I will let the
> >> XInside people know tomorrow, as well.
> >
> >I'm sorry, but this is just frankly bizarre. I can't think of
> >anything except perhaps the mmap() semantics changing (David?) that
> >would lead to semantics like you're describing. The X server should
>
> Ummm, nothing that I know of would affect this. There were a few minor
> bogons fixed in post 0210-SNAP, but these have been around forever. My
> #9GXE/Pro is working just fine. I know through explict checking that it is
> mmaping using /dev/mem and is mapping the a0000-ffffff range (why the whole
> thing I don't know). It is not doing linear mapping on my machine with the
> version of the XInside server that I'm using. Perhaps I need to tweak
> something somewhere to get it to do that, and perhaps this is why I don't see
> the problem? ...I dunno, but it's working fine with the stock configuration.
> Note: Jeremy Chatfield isn't on -current, so if you wish for him to see
> this discourse he needs to be CC'd (which I just did).
We've had a little chat about this. The major difference between the
I-128 and the GXE64pro is that the I-128 maps memory above and below
the usual 1MB boundary. If the mmap code was probing, perhaps to
test for the existance of real memory, that might upset the graphics
engine. The problem is 90+% likely to be something that graphics
engine is causing, because that's the bit that is being given an
offset. To get a recognisable picture from a Netscape image, the only
thing that can be changed is the graphics engine. The mmapping must
be correct or there would be other symptoms (and the GXE64pro would
probably fail in the same or similar ways).
So, did someone introduce some kind of memory probes? Or anything
that might read and write in the memory area mapped by the I-128.
This has a huge address space BTW. We map 8MB for the Mach64 as
well, but most boards have a lower maximum.
The only other cause that we can think of is someone dinking with PCI
registers. There are certain things that are proscribed and
insufficient attention to these, or probing a video device as if a
scsi board or something, might provoke a similar problem. We're much
more vague about this as we don't have a huge amount of PCI
experience, either :-)
Cheers, JeremyC.
--
Jeremy Chatfield, +1(303)470-5302, FAX:+1(303)470-5513, email:jdc@xinside.com
X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA.
Commercial X Server - for more information please try these services
http://www.xinside.com info@xinside.com ftp.xinside.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502232252.PAA11444>