Bug 186442
Summary: | xorg-x11-server-Xorg-1.0.99-1 breaks vesa driver | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> | ||||||
Component: | xorg-x11-drv-vesa | Assignee: | Adam Jackson <ajax> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | xgl-maint | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2006-06-07 13:55:54 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Alexandre Oliva
2006-03-23 16:44:54 UTC
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. |