Red Hat Bugzilla – Bug 194043
[regression] vesa driver freezes kernel on ATI Radeon 9200SE, often while scrolling
Last modified: 2008-05-06 20:31:38 EDT
+++ This bug was initially created as a clone of Bug #186442 +++ Description of problem: After bug 186442 was fixed, I was able to start X with vesa mode (ATI Radeon 9200SE, running with vesa driver because of bug 181736). 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 following packages gets me fast scrolling and stability back: xorg-x11-server-Xorg-1.0.1-9.x86_64.rpm xorg-x11-drv-vesa-1.0.1.3-1.2.x86_64.rpm xorg-x11-drv-keyboard-1.0.1.3-1.2.x86_64.rpm xorg-x11-drv-mouse-1.0.4-1.x86_64.rpm This is on x86_64, if it makes any difference. I have tried this on an x86_64 notebook with an NVidia card, and I was not able to trigger the problem. I tried commenting out `Load "dri"', just in case, to no avail. Unfortunately the box becomes totally irresponsible when the problem shows up, nothing is logged anywhere and I can't even ping it any more :-( Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.1.0-2 xorg-x11-drv-vesa-1.2.0-1 xorg-x11-drv-keyboard-1.1.0-1 xorg-x11-drv-mouse-1.1.0-2 How reproducible: Every time Steps to Reproduce: 1.Upgrade to current rawhide 2.Restart X using the vesa driver Actual results: X starts fine, but scrolling graphical content on firefox is much slower than before, and often gets the box to freeze. Expected results: Fast scrolling, no freezes. Additional info:
Created attachment 130488 [details] X log of a session that would eventually freeze
Created attachment 130489 [details] X logs from the earlier X builds, that never freeze and scroll fast
I forgot to mention the box that freezes with X in vesa mode is an SMP box, maybe it makes a difference. Since the kernel should never freeze, and I doubt it's actually some DRI feature being (ab)used since VESA doesn't use DRI, I thought I'd Cc the kernel maintainers, although the fact that older X doesn't trigger the problem kind of points to X, and not the kernel. It might be something new in X that triggers a latent bug in the kernel, though.
Is this bug tracking the slow scrolling problem, or the crash problem? Presumeably they are separate issues.
I thought they were the same because I pretty much always got freezes while scrolling. But this morning I got a crash shortly after logging in, while windows were still opening, no scrolling involved. So I guess they may be separate issues, indeed. I'll create a separate bug for the slower scroll, even though they might still be related.
FWIW, I've tried to reproduce the bug after booting my Athlon64 X2 box with maxcpus=1, and it didn't occur any more.
(In reply to comment #6) > FWIW, I've tried to reproduce the bug after booting my Athlon64 X2 box with > maxcpus=1, and it didn't occur any more. Ok, it does sound like a kernel problem then, reassigning...
Strictly speaking, this is not exactly a regression. I tried the newer X with an old kernel and it still crashed. So it's just the new X exposing a bug that had been latent in the kernel for quite a while. Unfortunately I can't tell whether the kernel prints anything to the console because I still haven't got a serial cable :-( These are getting extremely hard to find :-(
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp