Description of problem: Using the "ati" (radeon) driver on a Thinkpad T60p (V5200 / R500?) together with compiz, and on a dynamic dual monitor setup (large desktop in office, laptop screen when moving around, using xrandr to change) I find that if compiz/emerald is enabled then upon resume from suspend all I get is a black/white pattern on both screens, and no interaction/vt switching is possible I have a digital photo I can upload if required., It's almost like a chequerboard. Prior to suspend compiz/emerald seems to work fine for effects etc If compiz is *not* running no problem. glxgears reports ~ 1850 fps (faster on rawhide than F10) xorg settings are mostly defaults except I have explicitly set XAA. Screensaver/lock is disabled Originally getting this on F10. Switched to F11 rawhide (newer xorg) and continue to get the exact same behaviour. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.10.0-2.fc11.i386 kernel-PAE-2.6.29-0.96.rc3.git12.fc11.i686 compiz-0.7.8-12.fc11.i386 xorg-x11-server-Xorg-1.5.99.902-6.fc11.i386 rawhide updated yesterday 10 Feb kernel bootline is " kernel /vmlinuz-2.6.29-0.99.rc4.git1.fc11.i686.PAE ro nomodeset quiet" [modesetting removed to avoid interaction] How reproducible: Occurs every time Steps to Reproduce: 1. Login 2. Use fusion icon to switch from metacity/gtk to compiz/emerald 3. Suspend 4. Resume Actual results: Hung patterened screen Expected results: Desktop appears Additional info:
Created attachment 331556 [details] x11 config
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachment using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 331666 [details] Log including resume This is the xorg log from when my "simple" xorg.conf was being used. I recovered this log after reboot, so it shows the start of resume (but note that at this point the sfreen was corrupted, vt switching not possible, no networking, although mouse worked and there was some disk activity)
Created attachment 331667 [details] xorg log (no xorg.conf) Similar to last attachment, but this time without any xorg.conf being used.
Noticed something interesting...... after suspend/resume, 3D is no longer working the same. As an example this was taken from a single shell window: [jonesn@snowdon ~]$ glxgears 9885 frames in 5.0 seconds = 1976.505 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 53448 requests (47196 known processed) with 0 events remaining. [jonesn@snowdon ~]$ glxgears 980 frames in 5.0 seconds = 195.986 FPS XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 3695 requests (1919 known processed) with 0 events remaining. [jonesn@snowdon ~]$ The only difference was I did a suspend/resume before the second run. Nothing interesting in dmesg during resume [drm] Loading R500 Microcode [drm] Num pipes: 1 Nothing in /var/log/Xorg.0.log either perhaps this is a contributory cause in compiz causing this apparent hang? ie the drive/hw is not resetting 3D? Only option set in xorg.conf is a EXA
I get the same thing on my laptop running F10 with an X300: kernel-2.6.27.15-170.2.24.fc10.i686 xorg-x11-drv-ati-6.10.0-2.fc10.i386 No xorg.conf file. Using nomodeset because of bug 487222. The one difference is that if (with no compiz) I run glxgears, suspend, resume, and then run glxgears again, it hangs. #0 0x00a97416 in __kernel_vsyscall () #1 0x003fd979 in ioctl () from /lib/libc.so.6 #2 0x0381b6cf in drmIoctl (fd=11, request=1074291754, arg=0xbfe52d88) at xf86drm.c:186 #3 0x0381b8e7 in drmGetLock (fd=11, context=1, flags=0) at xf86drm.c:1267 #4 0x0017ac3a in DRILock (pScreen=0x9f0f228, flags=0) at dri.c:2180 #5 0x0017aca1 in DRIDoWakeupHandler (screenNum=0, wakeupData=0x0, result=2, pReadmask=0x821c420) at dri.c:1634 #6 0x00179d4b in DRIWakeupHandler (wakeupData=0x0, result=2, pReadmask=0x821c420) at dri.c:1606 #7 0x08089c22 in WakeupHandler (result=2, pReadmask=0x821c420) at dixutils.c:417 #8 0x08128fa3 in WaitForSomething (pClientsReady=0xa0320f8) at WaitFor.c:239 #9 0x08085bce in Dispatch () at dispatch.c:375 #10 0x0806b71d in main (argc=8, argv=0xbfe53214, envp=Cannot access memory at address 0x40086432 ) at main.c:441 A kill -9 on the X process gives me a working login screen again.
still broken with current RH: kernel-PAE-2.6.29-0.157.rc6.git2.fc11.i686 xorg-x11-drv-ati-6.11.0-1.fc11.i586
Now seems to be working with xorg-x11-server-Xorg-1.6.0-2.fc11.i586 kernel-PAE-2.6.29-0.159.rc6.git3.fc11.i686 kernel-PAE-2.6.29-0.176.rc6.git5.fc11.i686 compiz-0.7.8-14.fc11.i586 for the first time since F9 :-)
& xorg-x11-drv-ati-6.11.0-1.fc11.i586
This is working on F10 now as well.
so can I close this bug?
Yes.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #12) > Yes. Thanks