Description of problem:After upgrading from F7 to F8 I needed to manually create an xorg.conf file because a mode was being chosen that would not work at the default depth of 24. I used systme-config-display to create a generic xorg.conf with depth set to 16 and then I could use X again and more easily adjust the configuration. Version-Release number of selected component (if applicable): xorg-x11-server 1.3.0.0-33.fc8 How reproducible:100% Steps to Reproduce: 1.remove xorg.conf 2.restart X 3. Actual results:Garbage displayed on screen, which eventually locked me out of the machine. I could switch to a VT as long as I didn't wait too long. Expected results:Normal X display. Additional info:
Created attachment 259401 [details] Xorg.0.log This is from a successful X start up, but does provide information about my hardware. I don't really think it is a hardware specific problem though. Modes are limited not only by monitors and DACs, but also by memory and higher color depths need more memory for the same resolution.
We do filter modes out by available memory. You can even see it in that log: (II) NV(0): Not using default mode "1792x1344" (insufficient memory for mode) And you've got plenty enough memory for 1024x768 at 32bpp. Can you attach a log from an unsuccessful 32bpp run?
Created attachment 283331 [details] Xorg.0.log from problematic try I removed my xorg.conf file and rebooted and X did not run properly. I restarted a few times with mashups of my normal background image and some text displayed in smaller than normal fonts. Eventually the screen would end up being vertical bars of various colors, in particular ones appearing in my background image. When it got to that point c-a-f1 and c-a-bs would not work and I needed to reboot. Doing a telinit 3 after the first try or two let me get at things. I'll also attach an Xorg.0.log from when I use my xorg.conf file that gets things to work.
Created attachment 283341 [details] xorg.conf I normally use
Created attachment 283351 [details] Xorg.0.log using my normal xorg.conf file
1920x1080 at 32bpp just _barely_ fits into vram on that card. It's also a completely stupid choice of resolution for that monitor, but that's a different issue. I suspect what's happening here is the card's getting starved. You're probably burning all your memory bandwidth just scanning the picture out, and eventually the DMA engine just gives up. Does 1600x1200 work reliably?
1600x1200 at 24 bit color depth (which I think effectively uses 32) seems to work OK.
I built an nv driver that I think will fix this into rawhide. Can you test that, or do you need an F8 build?
As it happens I am trying to do a yum upgrade of that machine to Rawhide now. I think I have the dependency issues worked around for now, and I should be able to confirm that I want to proceed in a couple of minutes. Then if things work well the machine will be running rawhide when I get in tomorrow and I can retest this. If things don't work it may be another day or two. But I don't think you should need to bother with an f8 version.
The upgrade attempt last night got screwed up when I had the I/O lockup problem occur (this is one of the things I hoping gets fixed with the upgrade) after the start of actual updates from the yum upgrade and left things a bit messed up. So it will be another day or two before I can give you feedback.
I was able to test this with rawhide (xorg-x11-drv-nv-2.1.6-7.fc9) and it seems to work reasonably. When I booted without an /etc/x11/xorg.conf file and logged in I got 1600x1200 at 85Hz (according to prefernces, but that preference seemed believable). So I think the problem is fixed in Rawhide.
Cool. Marking fixed, will push as an F8 update too.