Red Hat Bugzilla – Bug 443834
kernel BUG in :radeon:radeon_cp_init_ring_buffer on resume-from-ram
Last modified: 2009-07-14 10:57:37 EDT
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):
regularly, and I don't seem to be the only one:
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)
Xorg for first user killed due to oops. Other user still logged in.
After logging in as first user, kerneloops applet pops up.
Xorg is using driver "radeon". Package versions:
can you test with the kernel-2.6.25-8.fc9 from koji
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
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
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
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:
I have just tried the current F9 packages
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
I have recently checked
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
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
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
I have examined the following four test cases:
A) 184.108.40.206-170.2.5.fc10.i686.PAE rhgb quiet
B) 220.127.116.11-170.2.5.fc10.i686 rhgb quiet
C) 18.104.22.168-170.2.5.fc10.i686.PAE nomodeset
D) 22.214.171.124-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
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:
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.