Hi, since a couple of months I have the problem with my notebook that the system hangs after doing a suspend to ram or disk. I reported the problem to the Debian team and to Bugzilla kernel team (find links below). Some tests last week by Debian (please watch the debian bug report link for further details) showed that the problem is caused by the Radeon module. The following error message occurrs when loading the radeon module: [ 270.715016] radeon_cp: Failed to load firmware "radeon/R300_cp.bin" [ 270.715045] [drm: r100_cp.init] *ERROR* Failed to load firmware! [ 270.715061] radeon 0000:01:05:0: failed initializing CP (-2) . [ 270.715072] radeon 0000:01:05:0:Disabling GPU acceleration The firmware and especially the file R300_cp.bin exists in /lib/firmware/radeon . The current version of xserver-xorg-video-radeon package is 6.14.3-1 . Please let me know if you need further information or if I can do something else. Thanks and regards Rolf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600846 https://bugzilla.kernel.org/show_bug.cgi?id=22022
Hi Rolf, Actually there's one more test that it would be useful to try. Please try preventing the radeon driver from being loaded at boot time, like this: echo 'blacklist radeon' >/etc/modprobe.d/rh-blacklist-radeon.conf update-initramfs -u -k all reboot Then try hibernating before and after loading the radeon module. If I am lucky, the "Failed to load firmware" messages will not show up in dmesg, but the second time you hibernate after loading the radeon module the hibernation will fail.
On 27.11.2011 19:19, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > --- Comment #1 from Jonathan Nieder<jrnieder@gmail.com> 2011-11-27 10:19:47 PST --- > Hi Rolf, > > Actually there's one more test that it would be useful to try. Please try > preventing the radeon driver from being loaded at boot time, like this: > > echo 'blacklist radeon'>/etc/modprobe.d/rh-blacklist-radeon.conf > update-initramfs -u -k all > reboot > > Then try hibernating before and after loading the radeon module. > > If I am lucky, the "Failed to load firmware" messages will not show up in > dmesg, but the second time you hibernate after loading the radeon module the > hibernation will fail. > Hi Jonathan, first I should mention that there already exist 2 files in /etc/modprobe.d concerning the radeon module and having the following contents: fbdev-blacklist.conf:blacklist radeonfb radeon-kms.conf:options radeon modeset=1 Second, executing your proposition seems not to prevent the radeon module from being loaded. There is a certain difference in system behaviour that the login window of the graphical desktop manager kdm is not automatically opened but insteat a shell login prompt is given. But after login as user root the lsmod command shows that radeon is loaded - maybe because other modules like ttm and drm are depending on it? Unloading the module with "modprobe -r radeon" does not work and shows message "the module is in use" . The dmesg output does not contain the firmware error message at this point. Please let me know how to go on. Thanks and regards Rolf
bugzilla-daemon@freedesktop.org wrote: > executing your proposition seems not to prevent the radeon > module from being loaded. Oh, right --- X loads the radeon module. Could you choose "recovery mode" from the grub menu so X isn't started and try again?
On 28.11.2011 09:58, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > --- Comment #3 from Jonathan Nieder<jrnieder@gmail.com> 2011-11-28 00:58:39 PST --- > bugzilla-daemon@freedesktop.org wrote: > >> executing your proposition seems not to prevent the radeon >> module from being loaded. > Oh, right --- X loads the radeon module. Could you choose "recovery > mode" from the grub menu so X isn't started and try again? > So, in recovery mode everything behaves as you expected: - radeon module is not loaded - hibernate test works very fine 3 times in follow - after load of radeon module, system hangup on first hibernate test
Created attachment 53901 [details] dmesg_after_first_sleep.txt bugzilla-daemon@freedesktop.org wrote: > - hibernate test works very fine 3 times in follow > - after load of radeon module, system hangup on first hibernate test Great. Hopefully someone knowledgeable can step in to figure out why the radeon device is failing to hibernate. Aside from diving into the source and writing patches to confirm guesses about what's happening, the only trick I can think of is to try passing "drm.debug=0x6" and "no_console_suspend" as parameters on the kernel command line and hibernate to provoke the hang, capturing messages either using netconsole[1] or by taking a photograph of the screen if it stays up long enough. You mentioned before that suspend-to-RAM always works the first time you try it, and not the second. Please attach full output from "dmesg" after booting and suspending successfully (to RAM or disk is not so important to me) with the radeon driver loaded and kernel parameter drm.debug=0x6 (and no_console_suspend if it happens to have been passed; it's not too relevant here). Thanks for your help and patience, Jonathan [1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt
On 28.11.2011 12:16, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > --- Comment #5 from Jonathan Nieder<jrnieder@gmail.com> 2011-11-28 03:16:18 PST --- > bugzilla-daemon@freedesktop.org wrote: > >> - hibernate test works very fine 3 times in follow >> - after load of radeon module, system hangup on first hibernate test > Great. > > Hopefully someone knowledgeable can step in to figure out why the > radeon device is failing to hibernate. > > Aside from diving into the source and writing patches to confirm > guesses about what's happening, the only trick I can think of is to > try passing "drm.debug=0x6" and "no_console_suspend" as parameters on > the kernel command line and hibernate to provoke the hang, capturing > messages either using netconsole[1] or by taking a photograph of the > screen if it stays up long enough. > > You mentioned before that suspend-to-RAM always works the first time > you try it, and not the second. Please attach full output from > "dmesg" after booting and suspending successfully (to RAM or disk is > not so important to me) with the radeon driver loaded and kernel > parameter drm.debug=0x6 (and no_console_suspend if it happens to have > been passed; it's not too relevant here). > > Thanks for your help and patience, > Jonathan > > [1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt > Attached the dmesg output after successful first suspend to ram. When the system hangs up there is no output on the screen - after some seconds the screen turns to power safe mode and the power led of the notebook does not start to blink as normally in sleep mode but keeps on burning - and the system does not react any longer to mouse or keyboard action - and that's it - not output. When trying the "drm.debug=0x6" and "no_console_suspend" parameters the system sometimes didn't hangup on hibernate test - the test worked 3 times in follow without hangup. And second suspend to disk with the two parameters did not really suspend - the power led continued to burn as described above - and the screen turned to power safe mode - but after a second or two the screen powered up again and showed the login screen of suspend mode. But this could not be reproduced constantly - strange!
Install the debian firmware package.
On 28.11.2011 15:39, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > --- Comment #7 from Alex Deucher<agd5f@yahoo.com> 2011-11-28 06:39:03 PST --- > Install the debian firmware package. > What is the name of the package you mean? The packages firmware-linux, firmware-linux-free and firmware-linux-nonfree are already installed. The directory /lib/firmware/radeon exists and has the following contents: -rw-r--r-- 1 root root 24096 Nov 2 14:45 BARTS_mc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 BARTS_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 BARTS_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 BTC_rlc.bin -rw-r--r-- 1 root root 24096 Nov 2 14:45 CAICOS_mc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 CAICOS_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 CAICOS_pfp.bin -rw-r--r-- 1 root root 24148 Nov 2 14:45 CAYMAN_mc.bin -rw-r--r-- 1 root root 8704 Nov 2 14:45 CAYMAN_me.bin -rw-r--r-- 1 root root 8704 Nov 2 14:45 CAYMAN_pfp.bin -rw-r--r-- 1 root root 4096 Nov 2 14:45 CAYMAN_rlc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 CEDAR_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 CEDAR_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 CEDAR_rlc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 CYPRESS_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 CYPRESS_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 CYPRESS_rlc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 JUNIPER_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 JUNIPER_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 JUNIPER_rlc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 PALM_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 PALM_pfp.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 R100_cp.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 R200_cp.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 R300_cp.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 R420_cp.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 R520_cp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 R600_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 R600_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 R600_rlc.bin -rw-r--r-- 1 root root 4096 Nov 2 14:45 R700_rlc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 REDWOOD_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 REDWOOD_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 REDWOOD_rlc.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 RS600_cp.bin -rw-r--r-- 1 root root 2048 Nov 2 14:45 RS690_cp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 RS780_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 RS780_pfp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 RV610_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 RV610_pfp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 RV620_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 RV620_pfp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 RV630_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 RV630_pfp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 RV635_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 RV635_pfp.bin -rw-r--r-- 1 root root 21504 Nov 2 14:45 RV670_me.bin -rw-r--r-- 1 root root 2304 Nov 2 14:45 RV670_pfp.bin -rw-r--r-- 1 root root 5440 Nov 2 14:45 RV710_me.bin -rw-r--r-- 1 root root 3392 Nov 2 14:45 RV710_pfp.bin -rw-r--r-- 1 root root 5440 Nov 2 14:45 RV730_me.bin -rw-r--r-- 1 root root 3392 Nov 2 14:45 RV730_pfp.bin -rw-r--r-- 1 root root 5440 Nov 2 14:45 RV770_me.bin -rw-r--r-- 1 root root 3392 Nov 2 14:45 RV770_pfp.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 SUMO2_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 SUMO2_pfp.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 SUMO_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 SUMO_pfp.bin -rw-r--r-- 1 root root 3072 Nov 2 14:45 SUMO_rlc.bin -rw-r--r-- 1 root root 24096 Nov 2 14:45 TURKS_mc.bin -rw-r--r-- 1 root root 5504 Nov 2 14:45 TURKS_me.bin -rw-r--r-- 1 root root 4480 Nov 2 14:45 TURKS_pfp.bin
Created attachment 53930 [details] dmesg Alex Deucher wrote: > Install the debian firmware package. The bug summary is wrong. The warnings about firmware were artifacts from debugging in a minimal environment (to rule out other some other driver causing the hibernation trouble). Rolf wrote: > When trying the "drm.debug=0x6" and "no_console_suspend" parameters the > system sometimes didn't hangup on hibernate test - the test worked 3 > times in follow without hangup. > And second suspend to disk with the two parameters did not really > suspend - the power led continued to burn as described above - and the > screen turned to power safe mode - but after a second or two the screen > powered up again and showed the login screen of suspend mode. > But this could not be reproduced constantly - strange! Do you have logs from when this happened (they might be somewhere in /var/log/dmesg*)?
On 29.11.2011 00:38, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > Jonathan Nieder<jrnieder@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Summary|System hangs after suspend |RS482: Hibernation reliably > |to ram or disk cause radeon |hangs, suspend-to-RAM > |firmware cannot be loaded. |unreliably hangs > > --- Comment #9 from Jonathan Nieder<jrnieder@gmail.com> 2011-11-28 15:38:47 PST --- > Alex Deucher wrote: > >> Install the debian firmware package. > The bug summary is wrong. The warnings about firmware were artifacts from > debugging in a minimal environment (to rule out other some other driver causing > the hibernation trouble). > > Rolf wrote: > >> When trying the "drm.debug=0x6" and "no_console_suspend" parameters the >> system sometimes didn't hangup on hibernate test - the test worked 3 >> times in follow without hangup. >> And second suspend to disk with the two parameters did not really >> suspend - the power led continued to burn as described above - and the >> screen turned to power safe mode - but after a second or two the screen >> powered up again and showed the login screen of suspend mode. >> But this could not be reproduced constantly - strange! > Do you have logs from when this happened (they might be somewhere in > /var/log/dmesg*)? > Please find attached all the /var/log/dmesg* files with their timestamps in ls.txt . But about the firmware warning in the initramfs environment - is it really useless ? Cause all the other roundabout 100 modules did load successfully using "modprobe -d /mnt" after mounting the harddisk /dev/sda8 at /mnt . Doesn't that mean that the radeon driver does not evaluate some environment settings but instead uses some fixed path settings - which might be wrong under certain circumstances?
Created attachment 53931 [details] dmesg.0
Created attachment 53932 [details] dmesg.1.gz
Created attachment 53933 [details] dmesg.2.gz
Created attachment 53934 [details] dmesg.3.gz
Created attachment 53935 [details] dmesg.4.gz
Created attachment 53936 [details] ls.txt
(In reply to comment #10) >>> When trying the "drm.debug=0x6" and "no_console_suspend" parameters the >>> system sometimes didn't hangup on hibernate test - the test worked 3 >>> times in follow without hangup. >>> And second suspend to disk with the two parameters did not really >>> suspend - the power led continued to burn as described above - and the >>> screen turned to power safe mode - but after a second or two the screen >>> powered up again and showed the login screen of suspend mode. >>> But this could not be reproduced constantly - strange! >> Do you have logs from when this happened (they might be somewhere in >> /var/log/dmesg*)? > > Please find attached all the /var/log/dmesg* files with their timestamps > in ls.txt . That isn't quite what I meant. The timestamps aren't so helpful to us since we weren't there; we can't easily tell which suspend you are talking about. What kernel are you using these days? Does it still fail to hibernate when the radeon driver is loaded?
On 20.03.2012 19:47, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > --- Comment #17 from Jonathan Nieder<jrnieder@gmail.com> 2012-03-20 11:47:35 PDT --- > (In reply to comment #10) > >>>> When trying the "drm.debug=0x6" and "no_console_suspend" parameters the >>>> system sometimes didn't hangup on hibernate test - the test worked 3 >>>> times in follow without hangup. >>>> And second suspend to disk with the two parameters did not really >>>> suspend - the power led continued to burn as described above - and the >>>> screen turned to power safe mode - but after a second or two the screen >>>> powered up again and showed the login screen of suspend mode. >>>> But this could not be reproduced constantly - strange! >>> Do you have logs from when this happened (they might be somewhere in >>> /var/log/dmesg*)? >> Please find attached all the /var/log/dmesg* files with their timestamps >> in ls.txt . > That isn't quite what I meant. The timestamps aren't so helpful to us since we > weren't there; we can't easily tell which suspend you are talking about. > > What kernel are you using these days? Does it still fail to hibernate > when the radeon driver is loaded? > Today I am using kernel 3.2.0-2-amd64 . The problem still exists in exactly the same way - the first hibernate always works perfectly fine - the second hibernate causes system hangup. After this long time I am not sure if I remember all the checks to do. Maybe also some things changed in the newer kernels ;-) What I did is: - start system with option "break=bottom" - in the shell coming up, lsmod shows that radeon driver is not loaded - hibernate check works fine three times in follow But at this point I do not know how to load the radeon driver cause "modprobe radeon" brings up error message "module radeon not found in modules.dep", so I cannot tell if radeon has the same error message as last year. By the way - don't know if you are concerned by this - but I also received a mail from a guy at bugzilla.kernel.org asking if the problem still exists - but my answer mail could not be delivered to him 4 times because of the following server problem :" The following addresses failed: <bugzilla-daemon@bugzilla.kernel.org> host bugzilla.kernel.org[198.145.19.204]: connection to mail exchanger failed" Regards
(In reply to comment #18) > Today I am using kernel 3.2.0-2-amd64 . > The problem still exists in exactly the same way - the first hibernate > always works perfectly fine - the second hibernate causes system hangup. Thanks. Please try 3.3 when it hits experimental, too. [...] > But at this point [in the initramfs shell] I do not know how to load > the radeon driver cause "modprobe radeon" brings up error message > "module radeon not found in modules.dep", so I cannot tell if radeon > has the same error message as last year. Not necessary. The initramfs shell is a weird environment that we were using for debugging, and we've already retrieved all the information we wanted from there.
On 21.03.2012 18:49, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=43278 > > --- Comment #19 from Jonathan Nieder<jrnieder@gmail.com> 2012-03-21 10:49:34 PDT --- > (In reply to comment #18) > >> Today I am using kernel 3.2.0-2-amd64 . >> The problem still exists in exactly the same way - the first hibernate >> always works perfectly fine - the second hibernate causes system hangup. > Thanks. Please try 3.3 when it hits experimental, too. > > [...] >> But at this point [in the initramfs shell] I do not know how to load >> the radeon driver cause "modprobe radeon" brings up error message >> "module radeon not found in modules.dep", so I cannot tell if radeon >> has the same error message as last year. > Not necessary. The initramfs shell is a weird environment that we were > using for debugging, and we've already retrieved all the information we > wanted from there. > Hi, the problem still exists in kernel 3.3.0-trunk-amd64 Regards
From https://bugzilla.kernel.org/show_bug.cgi?id=22022#c30: > Yes, it can be reproduced with kernel Debian 3.8.5-1~experimental.1 .
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/236.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.