+++ This bug was initially created as a clone of Bug #473195 +++

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

--- Additional comment from <email address hidden> on 2008-11-27 11:02:46 EDT ---

Same hardware, same problem.

--- Additional comment from <email address hidden> on 2008-11-30 05:31:03 EDT ---

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.

--- Additional comment from <email address hidden> on 2008-11-30 05:48:16 EDT ---

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.
...

--- Additional comment from <email address hidden> on 2008-11-30 08:20:15 EDT ---

May be my problem is different... Booting with nomodeset doesn't change the broken suspend/hypernate/resume. These functions were always stable on FC9.

--- Additional comment from <email address hidden> on 2008-11-30 10:06:34 EDT ---

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).

--- Additional comment from <email address hidden> on 2008-12-03 01:41:55 EDT ---

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.

--- Additional comment from <email address hidden> on 2008-12-03 01:44:37 EDT ---

*** Bug 473340 has been marked as a duplicate of this bug. ***

--- Additional comment from <email address hidden> on 2008-12-03 01:55:45 EDT ---

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.

--- Additional comment from <email address hidden> on 2008-12-03 02:21:17 EDT ---

Created an attachment (id=325492)
/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.

--- Additional comment from <email address hidden> on 2008-12-03 02:55:58 EDT ---

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

--- Additional comment from <email address hidden> on 2008-12-03 03:09:44 EDT ---

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).

--- Additional comment from <email address hidden> on 2008-12-04 02:35:17 EDT ---

*** Bug 474035 has been marked as a duplicate of this bug. ***

--- Additional comment from <email address hidden> on 2008-12-04 03:34:02 EDT ---

Created an attachment (id=325650)
/var/log/messages via ssh while wrong suspending on IBM T40

--- Additional comment from <email address hidden> on 2008-12-04 03:36:30 EDT ---

Created an attachment (id=325651)
related xorg.log (wrong suspend)

--- Additional comment from <email address hidden> on 2008-12-04 03:37:26 EDT ---

Created an attachment (id=325652)
dmesg terminal output (wrong suspend)

--- Additional comment from <email address hidden> on 2008-12-04 03:43:45 EDT ---

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)

--- Additional comment from <email address hidden> on 2008-12-07 07:43:10 EDT ---

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.

--- Additional comment from <email address hidden> on 2008-12-08 22:47:21 EDT ---

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.

--- Additional comment from <email address hidden> on 2008-12-09 00:51:39 EDT ---

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]

--- Additional comment from <email address hidden> on 2008-12-09 01:05:55 EDT ---

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

--- Additional comment from <email address hidden> on 2008-12-11 04:08:22 EDT ---

(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.

--- Additional comment from <email address hidden> on 2008-12-11 04:11:34 EDT ---

Created an attachment (id=326596)
dmesg after suspend on kernel 2.6.27.7-134.fc10.i686

--- Additional comment from <email address hidden> on 2008-12-11 05:17:46 EDT ---

Created an attachment (id=326599)
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?

--- Additional comment from <email address hidden> on 2008-12-17 18:05:12 EDT ---

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.

--- Additional comment from <email address hidden> on 2009-01-26 13:21:01 EDT ---

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

--- Additional comment from <email address hidden> on 2009-01-26 13:33:58 EDT ---

(In reply to comment #25)
Reply to myself:
No problems for suspend / resume using for these functions from gdm without the use of DRI.

--- Additional comment from <email address hidden> on 2009-03-04 15:58:42 EDT ---

Latest update to 2.6.27.19-170.2.35.fc10 does the fix!
This bug can be closed now.

--- Additional comment from <email address hidden> on 2009-03-05 07:31:59 EDT ---

Not for me. Still the same effect. Dark screen, but the OS is functional.

--- Additional comment from <email address hidden> on 2009-03-12 13:58:47 EDT ---

Hasn't fixed it for me either. Still the same.

--- Additional comment from <email address hidden> on 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?

--- Additional comment from <email address hidden> on 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).

--- Additional comment from <email address hidden> on 2009-09-06 05:29:48 EDT ---



*** This bug has been marked as a duplicate of 464866 ***

--- Additional comment from <email address hidden> on 2009-09-06 05:39:48 EDT ---

Sorry, wrong tab.

--- Additional comment from <email address hidden> on 2009-09-29 05:55:24 EDT ---

Still a problem with F-11. Any progress on this?

--- Additional comment from <email address hidden> on 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