Description of problem: Kernel BUG is triggered on resume-from-RAM after I played around with the Gnome user switch thingie before doing the suspend-to-RAM. Version-Release number of selected component (if applicable): kernel-PAE-2.6.25-1.fc9.i686 How reproducible: regularly, and I don't seem to be the only one: http://kerneloops.org/guilty.php?guilty=radeon_cp_init_ring_buffer&version=2.6.25-release&start=1671168&end=1703935&class=oops Steps to Reproduce: 1. Take my ThinkPad T60 with ATI X1400 graphics chip 2. switch to different user 3. try to suspend, which will fail due to policymagic 4. switch back to first user 5. suspend (STR) 6. resume Actual results: Xorg for first user killed due to oops. Other user still logged in. After logging in as first user, kerneloops applet pops up. Expected results: No oops. Additional info:
Xorg is using driver "radeon". Package versions: xorg-x11-drv-ati-6.8.0-10.fc9.i386 xorg-x11-server-Xorg-1.4.99.901-22.20080415.fc9.i386
can you test with the kernel-2.6.25-8.fc9 from koji http://koji.fedoraproject.org/packages/kernel/2.6.25/8.fc9/ or if it hits rawhide.
kernel-PAE-2.6.25-8.fc9.i686 appears to have fixed the BUG/Oops. Now some non-oopsy bug remains somewhere (kernel, Xorg, radeon driver) preventing me from switching between users, but that needs a separate investigation and probably a separate bz ticket.
OK, I was wrong about that. One user-switch, then suspend/resume gives me the BUG again. /var/log/messages attachment to follow.
Created attachment 303611 [details] /var/log/messages kernel-BUG-on-resume 2.6.25-8.fc9.i686.PAE Excerpt from /var/log/messages with 2.6.26-8.fc9 kernel-PAE from koji.
This also breaks fast user switching. Any call to EnterVT, really.
Fast user switching with the xorg-x11-drv-radeonhd-1.2.1-1.1.20080429git.fc9.i386 driver and kernel-PAE-2.6.25-8.fc9.i686 works. This shows that the Gnome/Xorg-server/hal/... magic all work. The difference to non-working is xorg-x11-drv-ati with kernel DRM vs xorg-x11-drv-radeonhd without DRM.
I just had someone show me another instance of this on .25-8, and he hadn't resumed from ram, just a straight forward boot up. Full trace available, but it looks very similar to the one in comment #5 modulo some offsets.
I have just tested kernel-PAE-2.6.25-14.fc9.i686 straight from bootup: 1. Cold boot. 2. gdm comes up 3. Log in as $USER1 4. Choose "Other..." on fast user switching applet 5. Watch gdm come up 6. Watch gdm assemble its list of users 7. Watch as the mouse pointer stops reacting to movements. System appears completely frozen. (Sysrq emergency sync does not flicker HDD LED) Time between 5 and 8 is betweeb 0 and 4 seconds (two tries).
Forgot to mention for the record: xorg-x11-drv-ati-6.8.0-12.fc9.i386
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have just tried the current F9 packages xorg-x11-drv-ati-6.8.0-14.fc9.i386 kernel-PAE-2.6.25.3-18.fc9.i686 Comment #9 still applies. A hard freeze happens, with no apparent way to get crash information from the box. Hardware is Lenovo ThinkPad T60, ATI X1400.
Comment #9 and comment #12 (complete system freeze) confirmed with kernel-PAE-2.6.25.6-55.fc9.i686 xorg-x11-drv-ati-6.8.0-14.fc9.i386
I have recently checked kernel-PAE-2.6.25.9-76.fc9.i686 xorg-x11-drv-ati-6.8.0-14.fc9.i386 and am still getting the total system freeze when using fast user switching. Using xorg-x11-drv-radeonhd-1.2.1-3.3.20080630git.fc9.i386 now as workaround, which works flawlessly in the FUS department, probably due to not doing anything with DRI.
Hans, Could you test a fully updated F10 and report ? Preferably both with and without nomodeset in the kernel command line. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I installed F10 on this system (Lenovo ThinkPad T60 with M54 Mobile X1400 graphics) around 2009-02-01. I needed to boot with the nomodeset kernel parameter in order to make resume-from-RAM work, with whatever kernel and xorg-x11-drv-ati versions were current then. I will check with an up to date F10 later today.
I have just tested the following package versions in an updated F10 installation: xorg-x11-drv-ati-6.10.0-2.fc10.i386 kernel-2.6.27.12-170.2.5.fc10.i686 kernel-PAE-2.6.27.12-170.2.5.fc10.i686 I have examined the following four test cases: A) 2.6.27.12-170.2.5.fc10.i686.PAE rhgb quiet B) 2.6.27.12-170.2.5.fc10.i686 rhgb quiet C) 2.6.27.12-170.2.5.fc10.i686.PAE nomodeset D) 2.6.27.12-170.2.5.fc10.i686 nomodeset The test procedure: 1. boot given kernel with the given command line params 2. wait until gdm comes up 3. log into Gnome desktop as normal user 4. suspend to ram clicking System -> Shut Down... -> [Suspend]. 5. wait until computer is suspended 6. press Fn key to resume from RAM 7. observe Results: A) and B) result in vertical stripes on the display and sync problems. The only fix is a reboot which can be triggered by pressing Ctrl-Alt-Del. C) and D) resume without issue. None of the four test cases appear to produce kernel BUGs any more. Apparently, the really bad BUG has been fixed, but there are still bugs preventing resume-from-RAM with KMS.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.