Bug 485051 - radeon R500 + compiz -> corrupted screen/hang after suspend/resume
radeon R500 + compiz -> corrupted screen/hang after suspend/resume
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
11
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-11 06:38 EST by Nigel Jones
Modified: 2018-04-11 04:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-13 11:33:43 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)
x11 config (2.70 KB, text/plain)
2009-02-11 06:40 EST, Nigel Jones
no flags Details
Log including resume (45.57 KB, text/plain)
2009-02-12 04:14 EST, Nigel Jones
no flags Details
xorg log (no xorg.conf) (47.95 KB, text/plain)
2009-02-12 04:16 EST, Nigel Jones
no flags Details

  None (edit)
Description Nigel Jones 2009-02-11 06:38:53 EST
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:
Comment 1 Nigel Jones 2009-02-11 06:40:04 EST
Created attachment 331556 [details]
x11 config
Comment 2 Matěj Cepl 2009-02-11 19:23:08 EST
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.
Comment 3 Nigel Jones 2009-02-12 04:14:53 EST
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)
Comment 4 Nigel Jones 2009-02-12 04:16:16 EST
Created attachment 331667 [details]
xorg log (no xorg.conf)

Similar to last attachment, but this time without any xorg.conf being used.
Comment 5 Nigel Jones 2009-02-13 05:55:55 EST
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
Comment 6 Samuel Sieb 2009-02-24 15:58:13 EST
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.
Comment 7 Nigel Jones 2009-03-01 05:40:16 EST
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
Comment 8 Nigel Jones 2009-03-02 15:04:31 EST
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 :-)
Comment 9 Nigel Jones 2009-03-02 15:05:44 EST
& xorg-x11-drv-ati-6.11.0-1.fc11.i586
Comment 10 Samuel Sieb 2009-03-05 15:06:16 EST
This is working on F10 now as well.
Comment 11 Dave Airlie 2009-03-07 06:26:53 EST
so can I close this bug?
Comment 12 Samuel Sieb 2009-03-07 11:48:06 EST
Yes.
Comment 13 Bug Zapper 2009-06-09 07:16:21 EDT
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
Comment 14 Matěj Cepl 2009-10-13 11:33:43 EDT
(In reply to comment #12)
> Yes.  

Thanks

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