This might just be the worst bug report I've ever filed, but there are so many things potentially involved here that I'm needing help just to start sorting out the mess :-(.

The short problem statement: I haven't had a working NVIDIA driver under Linux since 2.6.24 (just before the 96.43.07 legacy driver was released). 96.43.07 was released to restore functionality with 2.6.26 kernels, but that never worked for me: as soon as the driver initialized the GART, the X server aborted on a signal 4.

Figured I might have been dealing with old/obsolete software, so I've since upgraded Xorg to version 1.3.0 (19 April 2007, included with Slackware 12.0). That took care of the signal 4 issues, but now I *think* I'm fighting mtrr and/or GART issues with my AMD K6-III/450 on a Tyan S1590S motherboard.

About the only thing I'm sure of at this point is that MTRRs are definitely broken in the latest 2.6.27-rcX kernels. Running "cat /proc/mtrr" on a -rc4 kernel generates an I/O error. Applying a patch that's supposed to fix the MTRR issues on K6-2,3 processors gets rid of the I/O error, but there's no output as far as showing any configured MTRRs.

Attempting to use the legacy 96.43.07 driver (plus patches to allow compilation that appear elsewhere in this forum) with a 2.6.27-rc5+mtrr_patch kernel results in what looks like proper driver initialization as far as what appears in the Xorg.log.0 file. However, once the GART is initialized, the screen goes "orange" with vertical black stripes and becomes unreadable until I reboot the machine. Fortunately, the console is otherwise usable and I can gracefully terminate the X server and reboot the machine.

There are no errors in the Xorg.0.log file. The "nv" driver (not the binary "nvidia" driver) seems to work ok with the same and earlier 2.6.X kernels other than being so slow I can barely use what *had* been a good little machine. Yes, this is probably a kernel issue, but I expect and get no sympathy from the kernel developers when the only software that seems to trigger the problems is the "nvidia" driver.

As far as NVIDIA options in my xorg.conf file, these are the relevant lines that worked with the prior legacy driver and earlier 2.6.X kernels:

Tried Option NoMTRR? I didn't think they were used so much anymore, but Xorg.conf's manpage makes it sound useful still.. Certain compiler optimizations (like SSE) on components related to X could be causing problems on an older processor like that. Could you revert to an older kernel and/or X? CentOS 5.x has been running 2.6.18 for ages. If you used their sources to build your own kernel, it should be safe to use (so long as you keep up with it).

Tried Option NoMTRR? (...) Could you revert to an older kernel and/or X?

NoMTRR sounds like it's worth a try... As far as trying older kernels and/or X, everything was working great with a 2.6.24 kernel and whatever version of X shipped with Slackware 11. The problems started when 2.6.25 changes broke compilation of the previous NVIDIA 9x.y.z legacy driver.

Well, I was just thinking something a bit more long lived... I'm not sure how long the stable team updates mainline kernels with patches for 2.6.xx.x, but RedHat backports whatever is needed, for 2.6.9 (rhel4) and 2.6.18 (rhel5).

I'm using 96.43.07 on an Athlon XP for a GeForce 4 Ti 4200 (unstable Debian, Xorg 1.4.2, 2.6.26) without problem, but that CPU is a bit more recent.

which seems correct for my GeForce2 MX400 card. MTRR sanitization (relatively new kernel configuration option) seems to be working correctly: when X isn't active, the above command shows nothing. That's why I indicated in my first posting that MTRRs still seemed to be broken: my bad.

Anyway, the attached files (xorg.conf and Xorg.0.log) might help someone more clueful than me figure out what's going on... Sorry about the ".txt" extension on the configuration file: upload filters didn't like the ".conf".

BTW, I tried NoMTRR and setting NvAgp to "0": both settings were active at the time the attached files were created. No difference as far as the orange screen.