Description of problem: The resume after suspend or hibernate of a Thinkpad T60 with Radeon Mobility X1400 fails fails. The light of the display is turned on, but it remains black. In /var/log/messages I have the following lines: kernel: [drm:radeon_resume] *ERROR* kernel: [drm] Loading R500 Microcode kernel: [drm] Num pipes: 1 kernel: [drm] writeback test failed kernel: [drm:drm_ttm_bind] *ERROR* Couldn't bind backend. kernel: executing set pll kernel: executing set crtc timing kernel: [drm] LVDS-8: set mode 1400x1050 11 kernel: executing set LVDS encoder When booting with nomodeset suspend/resume works just fine, but without the nice new eye candy... The machine has been upgraded from F-9 to F-10 via a yum upgrade. Version-Release number of selected component (if applicable): kernel-2.6.27.5-117.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot laptop (without nomodeset) 2. Suspend 3. Resume, see black screen Actual results: The machine cannot be used. A hard power down and power up is required. Expected results: The screensaver password prompt should appear. Additional info: The smolt profile of the machine can be found at http://www.smolts.org/client/show/pub_d3521300-de3d-40ee-be30-5c99bb593c3b
Same hardware, same problem.
suspend/resume fails on Thinkpad T40 (Radeon Mobility 7500) too after upgrading from FC9 -> FC10 without error messages. # Nov 30 10:59:12 thinkpad kernel: [drm] Loading R100 Microcode Nov 30 10:59:12 thinkpad kernel: [drm] writeback test succeeded in 2 usecs Nov 30 11:07:46 thinkpad kernel: [drm] Initialized drm 1.1.0 20060810 Nov 30 11:07:46 thinkpad kernel: [drm] Initialized radeon 1.29.0 20080528 on minor 0 Nov 30 11:07:54 thinkpad kernel: [drm] Setting GART location based on new memory map # Machine is unusable... black screen after resume. kernel-2.6.27.5-117.fc10.i686 rhgb/plymouth is enabled using vga=0x318 as kernel boot arg.
pm-suspend --quirk-none doesn't help. Problem is related to xorg. I can find countless related messages in previous xorg.log: ... II) Macintosh mouse button emulation: Device reopened after 1 attempts. (II) USB Optical Mouse: Device reopened after 1 attempts. [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b] 1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379] 2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262] 3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8] 4: /usr/lib/xorg/modules/input//evdev_drv.so [0x355a8d] 5: /usr/bin/Xorg [0x80bcdb7] 6: /usr/bin/Xorg [0x80ac91e] 7: [0x110400] 8: [0x110416] 9: /lib/libc.so.6(ioctl+0x19) [0x484949] 10: /usr/lib/libdrm.so.2 [0x20026cf] 11: /usr/lib/libdrm.so.2(drmCommandWriteRead+0x34) [0x2002934] 12: /usr/lib/dri/radeon_dri.so [0x3089b2] 13: /usr/lib/dri/radeon_dri.so [0x308b38] 14: /usr/lib/dri/radeon_dri.so(radeonCopyBuffer+0x102) [0x30a960] 15: /usr/lib/dri/radeon_dri.so(radeonCopySubBuffer+0x6d) [0x307b95] 16: /usr/lib/dri/radeon_dri.so [0x304af8] 17: /usr/lib/xorg/modules/extensions//libglx.so [0x1824c4] 18: /usr/lib/xorg/modules/extensions//libglx.so [0x174a55] 19: /usr/lib/xorg/modules/extensions//libglx.so [0x173ae7] 20: /usr/lib/xorg/modules/extensions//libglx.so [0x17863a] 21: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f] 22: /usr/bin/Xorg(main+0x47d) [0x806b71d] 23: /lib/libc.so.6(__libc_start_main+0xe5) [0x3bf6d5] 24: /usr/bin/Xorg [0x806ab01] [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. ...
May be my problem is different... Booting with nomodeset doesn't change the broken suspend/hypernate/resume. These functions were always stable on FC9.
Minutes ago I have tried Dave Airlie's build on koji kernel-2.6.27.7-132.fc10.i686. Unfortunately this doesn't fix the described error above for IBM Thinkpad T40 using R100 (up to T43). My xorg.conf contains Section "Device" Identifier "Videocard0" Driver "radeon" Option "RenderAccel" "true" Option "AGPMode" "4" Option "GARTSize" "128" Option "AGPSize" "128" #Option "AGPFastWrite" "true" Option "EnableDepthMoves" "true" Option "AccelDFS" "true" Option "AccelMethod" "XAA" Option "XAANoOffscreenPixmaps" "true" Option "ColorTiling" "on" Option "DynamicClocks" "on" Option "SWcursor" "off" EndSection (3d is working fast enough).
I can confirm the problem. The smolt profile is here: http://www.smolts.org/client/show/pub_d33f4595-a01e-49c9-9ba8-e363b8ffccfa I've got these messages in logs: Dec 2 12:25:35 lopeptoid kernel: Suspending console(s) (use no_console_suspend to debug) Dec 2 12:25:35 lopeptoid kernel: [drm:drm_bo_evict_mm] *ERROR* lru empty Dec 2 12:25:35 lopeptoid kernel: [drm] Num pipes: 1 ... Dec 2 12:25:35 lopeptoid kernel: pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Dec 2 12:25:35 lopeptoid kernel: [drm:radeon_resume] *ERROR* Dec 2 12:25:35 lopeptoid kernel: [drm] Loading R500 Microcode Dec 2 12:25:35 lopeptoid kernel: [drm] Num pipes: 1 Dec 2 12:25:35 lopeptoid kernel: [drm] writeback test failed Dec 2 12:25:35 lopeptoid kernel: [drm:drm_ttm_bind] *ERROR* Couldn't bind backend. Dec 2 12:25:35 lopeptoid kernel: executing set pll Dec 2 12:25:35 lopeptoid kernel: executing set crtc timing Dec 2 12:25:35 lopeptoid kernel: [drm] LVDS-8: set mode 1280x800 10 Dec 2 12:25:35 lopeptoid kernel: executing set LVDS encoder Dec 2 12:25:35 lopeptoid kernel: Restarting tasks ... done. I've also found a workaround. I have disabled that fancy boot stuff, I mean "nomodeset" option to the kernel in /etc/grub.conf and suspend worked without problems already for 6 times. Some additional remarks: 1. I've discovered that the machine is not completely dead, it just pretends to be. At least if you have a second machine around you still can ssh to a semi-dead host and reboot it remotely. 2. Switching to radeonhd driver partially fixes the problem: machine gets back from suspend, but the picture on the screen is covered with dotty garbage. But it is still usable enough to make a clean reboot and may be even save some files before that. Switched back to radeon.
*** Bug 473340 has been marked as a duplicate of this bug. ***
can someone do a boot with drm.debug=1 then suspend/resume and ssh in afterwards and get the logs? and attach the full log here.
Created attachment 325492 [details] /var/log/messages for boot with drm.debug=1 with failed suspend Here you go. A strange thing: when I booted with drm.debug=1 after resume I've got garbled screen and no wireless (not sure about last thing, may be I should wait a bit longer). Booting without nomodeset and without drm.debug brings empty screen and working wireless on my system.
Booting with drm.debug=1 as grub kernel arg results in "unknown kernel option" for me. There are error messages.. 08:35:21 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:22 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:22 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:22 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:22 thinkpad kernel: <70x51, dev 0xe200, auth=1 Dec 3 08:35:22 thinkpad ntpd[1956]: Listening on interface #7 eth1, 192.168.3.121#123 Enabled Dec 3 08:35:22 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:23 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:23 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:23 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:23 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:24 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:24 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:24 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:25 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:25 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:25 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:25 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:25 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:26 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:26 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:26 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:27 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:28 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:28 thinkpad kernel: <7_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:29 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:30 thinkpad kernel: <70x51, dev 0xe200, auth=1 Dec 3 08:35:31 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:31 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:32 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:33 thinkpad kernel: <7_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:34 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:34 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:34 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:35 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:35 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:36 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:36 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:37 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:37 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:38 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:39 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:39 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:39 thinkpad kernel: <7_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:39 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:40 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:40 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:41 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:41 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:41 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:43 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:43 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:44 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:46 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:46 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:47 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:47 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:48 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:48 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:48 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:48 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:49 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:49 thinkpad kernel: <70x51, dev 0xe200, auth=1 Dec 3 08:35:49 thinkpad kernel: 0x51, dev 0xe200, auth=1 Dec 3 08:35:49 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:50 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:50 thinkpad kernel: <_ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:50 thinkpad kernel: <0x51, dev 0xe200, auth=1 Dec 3 08:35:50 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:51 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 Dec 3 08:35:51 thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200
Because I have no other box available at home, I'll post /var/log/messages here tommorow after ssh login. "thinkpad kernel: _ioctl] pid=2061, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1" was written while wrong suspend has happen, but is useless info (for me).
*** Bug 474035 has been marked as a duplicate of this bug. ***
Created attachment 325650 [details] /var/log/messages via ssh while wrong suspending on IBM T40
Created attachment 325651 [details] related xorg.log (wrong suspend)
Created attachment 325652 [details] dmesg terminal output (wrong suspend)
Required files are there now... I'm not sure about drm.debug=1 "unknown command... ignoring" message. dmesg: [drm:drm_ioctl] pid=2043, cmd=0xc0086451, nr=0x51, dev 0xe200, auth=1 [drm:radeon_cp_getparam] pid=2043 .. (see last attachement)
My Clevo D870P notebook ( http://smolts.org/show?uuid=pub_483d83b6-cdb4-456c-bebb-42f8c704839a ) which works fine with f8 and f9 has an ATI Mobility radeon 9700 chipset whose dmesg details are in duplicate bug https://bugzilla.redhat.com/show_bug.cgi?id=473340 exhibits this behaviour... Without the "nomodeset" option, I find that once the computer has been suspended and then resumed, that all windows are rendered without any symbols (minimise, maximise, close) in the top right corner of the windows, and instead I get corruption - it seems that the minimise, maximise and close are being wrongly rendered, corrupting the display. An easy way to reproduce the corruption is to open a gnome-terminal windows and grab the bottom of it and resize the windows vertically repeatedly increasing and decreasing the size of the window...the more I do this, the more corruption I see on screen. It might be that the resize is causing the re-rendering the minimise, maximise, and close and hence the corruption. With the "nomodeset" kernel option, I don't see any screen corruption on resume, but I do see mouse-pointer corruption, for example the mouse-pointer that is supposed to show when resizing a window becomes a dotty mess.
So I need another try, I need to see the dmesg after the resume not /var/log/messages with drm.debug=1 as it appears to lose stuff in /var/log/messages.
Dave Airlie, does this link provide the info you need? https://bugzilla.redhat.com/show_bug.cgi?id=473340 [the above bug is now a duplicate of this one]
nope, it only has the dmesg, I need it drm debugging enabled. btw enabling debugging before suspend might produce less crap.. echo 1 > /sys/module/drm/parameters/debug pm-suspend --quirk-none echo 0 > /sys/module/drm/parameters/debug
(In reply to comment #20) > nope, it only has the dmesg, I need it drm debugging enabled. > > btw enabling debugging before suspend might produce less crap.. > > echo 1 > /sys/module/drm/parameters/debug > pm-suspend --quirk-none > echo 0 > /sys/module/drm/parameters/debug Done, dmesg after resume.. attached... same crap I think. (updated to 2.6.27.7-134.fc10.i686 kernel). I see the desktop and can move the mouse after resume... but desktop is frozen and unusable.
Created attachment 326596 [details] dmesg after suspend on kernel 2.6.27.7-134.fc10.i686
Created attachment 326599 [details] dmesg after suspend on kernel 2.6.27.7-134.fc10.x86_64 dmesg output after suspend. Executed immediately after pm-suspend returned. It's truncated at the beginning, but the resume output is complete. Sufficient?
Problem persists with kernel-2.6.27.9-159.fc10.x86_64 and xorg-x11-drv-ati-6.9.0-62.fc10.x86_64. Recently I've seen the following in the log: During suspend, immediately after "Suspending console" [drm:drm_bo_evict_mm] *ERROR* lru empty During resume: [drm:radeon_resume] *ERROR* [drm] Loading R500 Microcode [drm] Num pipes: 1 [drm] writeback test failed Hope that helps.
Same as described early for 2.6.27.12-2.5.fc10.i686 from updates-testing on IBM Thinkpad T40 :-( [ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]] No problem before with FC9 on T40, kernel 2.6.26.*-. @Dave: Can I do some more precisely debugging for you? -- Regards from Germany Matthias
(In reply to comment #25) Reply to myself: No problems for suspend / resume using for these functions from gdm without the use of DRI.
Latest update to 2.6.27.19-170.2.35.fc10 does the fix! This bug can be closed now.
Not for me. Still the same effect. Dark screen, but the OS is functional.
Hasn't fixed it for me either. Still the same.
kernel-2.6.27.24-170.2.68.fc10.x86_64 is still broken. Haven't tried F-11, yet. Has anyone else, is it fixed?
(In reply to comment #30) > kernel-2.6.27.24-170.2.68.fc10.x86_64 is still broken. Haven't tried F-11, yet. > Has anyone else, is it fixed? I'm seeing the problem in a stock install of Fedora 11 (T60 with X1400).
*** This bug has been marked as a duplicate of bug 464866 ***
Sorry, wrong tab.
Still a problem with F-11. Any progress on this?
This problem still happens in rawhide. kernel-PAE-2.6.31.1-56.fc12.i686 xorg-x11-drv-ati-6.13.0-0.7.20091006git457646d73.fc12.i686 xorg-x11-server-Xorg-1.7.0-1.fc12.i686
I still see this problem in Fedora 12 Beta, with the Live CD
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.