Description of problem: Ater upgrading to yesterday's rawhide and rebooting, X wouldn't set up the local display (ATI Radeon 9200SE, running with vesa driver because of bug 181736), even though connecting through VNC it was perfectly functional. The problem is that the local display is pure noise, so the display is unusable. Reverting to xorg-x11-server-Xorg-1.0.1-9 fixed the problem. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.0.99-1 How reproducible: Every time Steps to Reproduce: 1.Upgrade to xorg-x11-server-Xorg-1.0.99-1 2.Restart X using the vesa driver Actual results: Noise on the local display; X otherwise functional over vnc Expected results: X functional for local and remote Additional info: Using the radeon driver the local display is good. I haven't tested connecting over vnc to see whether the other bug was fixed.
I forgot to mention that this was the .x86_64 version of it, but then I realized I could easily test it on a .i686 notebook with an Nvidia GeForce2 Go card that was working just fine with the nv driver, but that, after switching to vesa, breaks in the very same way. So the problem appears to be architecture- and video-card-independent.
The vesa driver has not been updated for the CVS head X server which is in rawhide currently. Please use the FC5 server/driver for now until rawhide stabilizes and has all of the drivers updated to work with the server that is present. Reassigning to adam for driver updates ...
NEEDINFO_ENG is hate
All drivers were updated in today's rawhide, but it just got worse. The server still has corrupted VESA, and now it crashes if I load the vnc driver. I have to downgrade vesa, keyboard and mouse in order to get X back to an operational state, even if I were to comment out the VNC driver load (but then, if I weren't to use VNC, I might as well switch to the radeon driver...)
VESA driver is still broken with today's X in rawhide. xorg-x11-server-Xorg-1.0.99.903-1 xorg-x11-drv-vesa-1.1.0-1
I think I know what the VNC problem is; if you could file it as a separate bug I'd appreciate it. Regarding comment #4, which version of vesa works for you?
VNC problem is bug 191657, filed yesterday. I was going to point it out here but I forgot. This is the combination that works for vesa: xorg-x11-server-Xorg-1.0.1-9 xorg-x11-drv-vesa-1.0.1.3-1.2 I have to downgrade the server (and other drivers too, like keyboard, mouse and synaptics) in order to avoid some binary incompatibility that causes crashes. Perhaps that's what the VNC thing is about too, since IIRC VNC used to contain X sources and might need an update.
can you attach X logs from both the working and non-working configurations?
I've tracked this one down to recent miext/shadow changes. I've just checked in my fix upstream, and it should be included in the next driver spin.
Not fixed in 1.1.0-1 :-( I'll attach the logs momentarily.
Created attachment 130062 [details] Working VESA logs, with older Xorg release
Created attachment 130063 [details] Broken VESA logs, with latest Xorg release
This problem appears to have been fixed in 1.2.0, but scrolling of a full-screen 1024x768 firefox are significant slower and my box became crashy after this update. The crashes don't seem to be fully repeatable, but they're quite consistent; it's pretty difficult to avoid a total system freeze after logging in, getting Firefox to visit a dozen web pages in separate tabs, and then just going closing each one of them in a row. Reverting to the old, working X packages gets me fast scrolling and stability back. This is on x86_64, if it makes any difference, and the card is an ATI 9200SE. I haven't tried this on other boxes with different cards; please let me know whether it would make any sense to do so. Unfortunately the box becomes totally irresponsible when the problem shows up, nothing is logged anywhere and I can't even ping it any more :-( Should I file this as a separate report, or is there any chance it might still be the same problem?
(In reply to comment #13) > This problem appears to have been fixed in 1.2.0 So can we close this particular issue now as "RAWHIDE"? >, but scrolling of a full-screen > 1024x768 firefox are significant slower and my box became crashy after this > update. Sounds like a separate unrelated issue. > The crashes don't seem to be fully repeatable, but they're quite > consistent; it's pretty difficult to avoid a total system freeze after logging > in, getting Firefox to visit a dozen web pages in separate tabs, and then just > going closing each one of them in a row. Best to file new individual bugs for each new problem encountered, so they can be tracked individually. Best to have new reports rather than cloned bugs (to avoid a lot of unrelated data being in the bug reports). > Should I file this as a separate report, or is there any chance it might still > be the same problem? Separate reports generally always work best. It's easy to close each issue out as they vanish, and leave the other ones open to continue tracking them if they don't also vanish. Also, it is easy to close a bug as a dupe if later it is determined they are the same issue, or that they're different issues both fixed by the same fix. It is hard to manage 2 or more bugs that "might" not be the same issue, within a single bug report however, and if one issue does get fixed, do you then close the report, or leave it open, and have a bug get more and more different issues added to it? It makes bug reports ugly and hard to follow over time as they get longer and cover 2-5 different issues. So, my vote is always for separate bug reports for each individual problem occuring, even if it is related to another problem. Cross referencing related or possibly related bugs with URLs to each other and/or using the bugzilla dependency features (blocks bug #, is blocked by bug #) is a much better mechanism. If the original issue here is fixed now though, I'd recommend we close this one, and start fresh bug reports for remaining issues. TIA
Cloning bugs is nice because it shows what the bug was taken out of, even though even that big can be snipped out while cleaning up the submission like I often do. Sometimes it's appropriate to keep the dependency, sometimes it's not, but it's easy enough to take it out when it's not, and generally good to do so after creating the descendent bug, such that there are bidirectional links between the possibly-related bugs. So I've just done that to the other bug (now bugs). This one can be closed, indeed.