[Bug 43278] New: System hangs after suspend to ram or disk cause radeon firmware cannot be loaded.
https://bugs.freedesktop.org/show_bug.cgi?id=43278
Bug #: 43278 Summary: System hangs after suspend to ram or disk cause radeon firmware cannot be loaded. Classification: Unclassified Product: DRI Version: XOrg 6.7.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hubba@online.de
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
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.
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #2 from Rolf hubba@online.de 2011-11-28 00:48:57 PST --- On 27.11.2011 19:19, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #1 from Jonathan Niederjrnieder@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
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?
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #4 from Rolf hubba@online.de 2011-11-28 02:43:20 PST --- On 28.11.2011 09:58, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #3 from Jonathan Niederjrnieder@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
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
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #6 from Rolf hubba@online.de 2011-11-28 05:44:48 PST --- On 28.11.2011 12:16, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #5 from Jonathan Niederjrnieder@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!
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.
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #8 from Rolf hubba@online.de 2011-11-28 07:11:01 PST --- On 28.11.2011 15:39, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #7 from Alex Deucheragd5f@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
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*)?
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #10 from Rolf hubba@online.de 2011-11-28 23:39:22 PST --- On 29.11.2011 00:38, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
Jonathan Niederjrnieder@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 Niederjrnieder@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?
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #11 from Rolf hubba@online.de 2011-11-28 23:39:23 PST --- Created attachment 53932 --> https://bugs.freedesktop.org/attachment.cgi?id=53932 dmesg.1.gz
--- Comment #12 from Rolf hubba@online.de 2011-11-28 23:39:23 PST --- Created attachment 53933 --> https://bugs.freedesktop.org/attachment.cgi?id=53933 dmesg.2.gz
--- Comment #13 from Rolf hubba@online.de 2011-11-28 23:39:23 PST --- Created attachment 53934 --> https://bugs.freedesktop.org/attachment.cgi?id=53934 dmesg.3.gz
--- Comment #14 from Rolf hubba@online.de 2011-11-28 23:39:23 PST --- Created attachment 53936 --> https://bugs.freedesktop.org/attachment.cgi?id=53936 ls.txt
--- Comment #15 from Rolf hubba@online.de 2011-11-28 23:39:23 PST --- Created attachment 53935 --> https://bugs.freedesktop.org/attachment.cgi?id=53935 dmesg.4.gz
--- Comment #16 from Rolf hubba@online.de 2011-11-28 23:39:23 PST --- Created attachment 53931 --> https://bugs.freedesktop.org/attachment.cgi?id=53931 dmesg.0
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?
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #18 from Rolf hubba@online.de 2012-03-21 05:01:34 PDT --- On 20.03.2012 19:47, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #17 from Jonathan Niederjrnieder@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
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.
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #20 from Rolf hubba@online.de 2012-03-26 01:46:54 PDT --- On 21.03.2012 18:49, bugzilla-daemon@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #19 from Jonathan Niederjrnieder@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
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #21 from Jonathan Nieder jrnieder@gmail.com ---
Yes, it can be reproduced with kernel Debian 3.8.5-1~experimental.1 .
https://bugs.freedesktop.org/show_bug.cgi?id=43278
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #22 from Martin Peres martin.peres@free.fr --- -- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org