Bug 473195 - Thinkpad T60 resume fails with kernel mode setting
Thinkpad T60 resume fails with kernel mode setting
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Reopened
: 473340 474035 (view as bug list)
Depends On:
Blocks: 527874
  Show dependency treegraph
 
Reported: 2008-11-26 20:03 EST by Tim Niemueller
Modified: 2010-06-28 06:50 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 527874 (view as bug list)
Environment:
Last Closed: 2010-06-28 06:50:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages for boot with drm.debug=1 with failed suspend (107.98 KB, text/plain)
2008-12-03 02:21 EST, Lev Shamardin
no flags Details
/var/log/messages via ssh while wrong suspending on IBM T40 (160.46 KB, text/plain)
2008-12-04 03:34 EST, Matthias Haase
no flags Details
related xorg.log (wrong suspend) (72.15 KB, text/plain)
2008-12-04 03:36 EST, Matthias Haase
no flags Details
dmesg terminal output (wrong suspend) (729 bytes, text/plain)
2008-12-04 03:37 EST, Matthias Haase
no flags Details
dmesg after suspend on kernel 2.6.27.7-134.fc10.i686 (121.02 KB, text/plain)
2008-12-11 04:11 EST, Matthias Haase
no flags Details
dmesg after suspend on kernel 2.6.27.7-134.fc10.x86_64 (121.79 KB, text/plain)
2008-12-11 05:17 EST, Tim Niemueller
no flags Details

  None (edit)
Description Tim Niemueller 2008-11-26 20:03:50 EST
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
Comment 1 Andrey Meganov 2008-11-27 11:02:46 EST
Same hardware, same problem.
Comment 2 Matthias Haase 2008-11-30 05:31:03 EST
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.
Comment 3 Matthias Haase 2008-11-30 05:48:16 EST
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.
...
Comment 4 Matthias Haase 2008-11-30 08:20:15 EST
May be my problem is different... Booting with nomodeset doesn't change the broken suspend/hypernate/resume. These functions were always stable on FC9.
Comment 5 Matthias Haase 2008-11-30 10:06:34 EST
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).
Comment 6 Lev Shamardin 2008-12-03 01:41:55 EST
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.
Comment 7 Lev Shamardin 2008-12-03 01:44:37 EST
*** Bug 473340 has been marked as a duplicate of this bug. ***
Comment 8 Dave Airlie 2008-12-03 01:55:45 EST
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.
Comment 9 Lev Shamardin 2008-12-03 02:21:17 EST
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.
Comment 10 Matthias Haase 2008-12-03 02:55:58 EST
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
Comment 11 Matthias Haase 2008-12-03 03:09:44 EST
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).
Comment 12 Lev Shamardin 2008-12-04 02:35:17 EST
*** Bug 474035 has been marked as a duplicate of this bug. ***
Comment 13 Matthias Haase 2008-12-04 03:34:02 EST
Created attachment 325650 [details]
/var/log/messages via ssh while wrong suspending on IBM T40
Comment 14 Matthias Haase 2008-12-04 03:36:30 EST
Created attachment 325651 [details]
related xorg.log (wrong suspend)
Comment 15 Matthias Haase 2008-12-04 03:37:26 EST
Created attachment 325652 [details]
dmesg terminal output (wrong suspend)
Comment 16 Matthias Haase 2008-12-04 03:43:45 EST
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)
Comment 17 David Campbell 2008-12-07 07:43:10 EST
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.
Comment 18 Dave Airlie 2008-12-08 22:47:21 EST
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.
Comment 19 David Campbell 2008-12-09 00:51:39 EST
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]
Comment 20 Dave Airlie 2008-12-09 01:05:55 EST
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
Comment 21 Matthias Haase 2008-12-11 04:08:22 EST
(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.
Comment 22 Matthias Haase 2008-12-11 04:11:34 EST
Created attachment 326596 [details]
dmesg after suspend on kernel 2.6.27.7-134.fc10.i686
Comment 23 Tim Niemueller 2008-12-11 05:17:46 EST
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?
Comment 24 Tim Niemueller 2008-12-17 18:05:12 EST
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.
Comment 25 Matthias Haase 2009-01-26 13:21:01 EST
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
Comment 26 Matthias Haase 2009-01-26 13:33:58 EST
(In reply to comment #25)
Reply to myself:
No problems for suspend / resume using for these functions from gdm without the use of DRI.
Comment 27 Matthias Haase 2009-03-04 15:58:42 EST
Latest update to 2.6.27.19-170.2.35.fc10 does the fix!
This bug can be closed now.
Comment 28 Andrey Meganov 2009-03-05 07:31:59 EST
Not for me. Still the same effect. Dark screen, but the OS is functional.
Comment 29 Tim Niemueller 2009-03-12 13:58:47 EDT
Hasn't fixed it for me either. Still the same.
Comment 30 Tim Niemueller 2009-06-11 18:52:56 EDT
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?
Comment 31 Steven Garrity 2009-06-11 20:13:49 EDT
(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).
Comment 32 Vedran Miletić 2009-09-06 05:29:48 EDT

*** This bug has been marked as a duplicate of bug 464866 ***
Comment 33 Vedran Miletić 2009-09-06 05:39:48 EDT
Sorry, wrong tab.
Comment 34 Tim Niemueller 2009-09-29 05:55:24 EDT
Still a problem with F-11. Any progress on this?
Comment 35 Peng Huang 2009-10-07 22:00:00 EDT
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
Comment 36 David Campbell 2009-11-05 15:53:57 EST
I still see this problem in Fedora 12 Beta, with the Live CD
Comment 37 Bug Zapper 2010-04-27 08:23:09 EDT
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
Comment 38 Bug Zapper 2010-06-28 06:50:31 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.