Bug 190307

Summary: suspend (to RAM) with i810 driver results in redraw corruption after resume
Product: [Fedora] Fedora Reporter: Lonni J Friedman <netllama>
Component: xorg-x11-drv-i810Assignee: Adam Jackson <ajax>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: hanwen, jensk.maps, mcepl, ncunning, sahai
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: FC 6.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-20 09:38:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
X log which includes suspend/resume cycle
none
drawing corruption none

Description Lonni J Friedman 2006-04-30 23:17:04 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. In Gnome, click on the 'Suspend' menu item 
2. system suspends
3. hit a key on the keyboard to wake the system
4. X comes back, however all the windows get corrupted when redrawing.  
  
Actual results:
Bizarre corruption on any pre-existing windows or new windows.  As long as
pre-existing windows (Firefox, xterms, etc) aren't moved at all, they are fine.
 But as soon as you move them, the window fails to redraw (the previous content
remains in the same position, and the new location/geomtry of the window is
transparent, showing the root window/background).  Opening new apps/windows
(such as an xterm result in only its borders getting drawn, however dragging
another window on top seems to force a redraw.

Expected results:
No corruption, windows can be moved/resized and have their contents redraw properly.

Additional info:
I'm seeing this problem on a (older) Sharp MV10 notebook which has an I815 GPU.
 I ran 'yum update' this morning, so everything is fully up to date, including
the kernel.  I'll attach the X log from immediately after resuming from suspend.
The only thing that looks suspicious is this line:
(WW) I810(0): Fixing display offsets

Here's what dmesg looks like for the entire suspend/awake cycle:
PM: Preparing system for mem sleep
Stopping tasks:
========================================================================|
PM: Entering mem sleep
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
PM: Finishing wakeup.
PM: Writing back config space on device 0000:00:02.0 at offset 1. (Was 900000,
writing 900007)
PM: Writing back config space on device 0000:00:02.0 at offset 4. (Was 8,
writing e8000008)
PM: Writing back config space on device 0000:00:02.0 at offset 5. (Was 0,
writing e0000000)
PM: Writing back config space on device 0000:00:02.0 at offset f. (Was 100,
writing 109)
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9
PM: Writing back config space on device 0000:00:02.1 at offset 1. (Was 900000,
writing 900007)
PM: Writing back config space on device 0000:00:02.1 at offset 4. (Was 8,
writing f0000008)
PM: Writing back config space on device 0000:00:02.1 at offset 5. (Was 0,
writing e0080000)
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9
PCI: Setting latency timer of device 0000:00:1d.0 to 64
usb usb1: root hub lost power or was reset
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 3 (level, low) -> IRQ 3
PCI: Setting latency timer of device 0000:00:1d.1 to 64
usb usb2: root hub lost power or was reset
PM: Writing back config space on device 0000:00:1e.0 at offset 1. (Was 800005,
writing 800107)
PM: Writing back config space on device 0000:00:1e.0 at offset 6. (Was 20200,
writing 40050100)
PM: Writing back config space on device 0000:00:1e.0 at offset 7. (Was 228000f0,
writing 22802020)
PM: Writing back config space on device 0000:00:1e.0 at offset 8. (Was fff0,
writing e020e020)
PM: Writing back config space on device 0000:00:1e.0 at offset 9. (Was fff0,
writing 21f02000)
PM: Writing back config space on device 0000:00:1e.0 at offset f. (Was 0,
writing 40000)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PM: Writing back config space on device 0000:00:1f.1 at offset 1. (Was 2800005,
writing 2800007)
PM: Writing back config space on device 0000:00:1f.1 at offset 9. (Was 0,
writing 22000000)
PM: Writing back config space on device 0000:00:1f.1 at offset f. (Was 100,
writing 1ff)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
PM: Writing back config space on device 0000:00:1f.3 at offset 8. (Was 1101,
writing 1861)
PM: Writing back config space on device 0000:00:1f.5 at offset 1. (Was 2800000,
writing 2800001)
PM: Writing back config space on device 0000:00:1f.5 at offset 4. (Was 1,
writing 1c01)
PM: Writing back config space on device 0000:00:1f.5 at offset 5. (Was 1,
writing 1881)
PM: Writing back config space on device 0000:00:1f.5 at offset f. (Was 200,
writing 205)
ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:1f.5 to 64
PM: Writing back config space on device 0000:01:00.0 at offset 3. (Was 20000,
writing 2a820)
PM: Writing back config space on device 0000:01:00.0 at offset 4. (Was 0,
writing e0201000)
PM: Writing back config space on device 0000:01:00.0 at offset 6. (Was 0,
writing b0050201)
PM: Writing back config space on device 0000:01:00.0 at offset 7. (Was 0,
writing 20000000)
PM: Writing back config space on device 0000:01:00.0 at offset 8. (Was 0,
writing 21fff000)
PM: Writing back config space on device 0000:01:00.0 at offset 9. (Was 0,
writing 24000000)
PM: Writing back config space on device 0000:01:00.0 at offset a. (Was 0,
writing 25fff000)
PM: Writing back config space on device 0000:01:00.0 at offset b. (Was 0,
writing 2400)
PM: Writing back config space on device 0000:01:00.0 at offset c. (Was 0,
writing 24fc)
PM: Writing back config space on device 0000:01:00.0 at offset d. (Was 0,
writing 2800)
PM: Writing back config space on device 0000:01:00.0 at offset e. (Was 0,
writing 28fc)
PM: Writing back config space on device 0000:01:00.0 at offset f. (Was 34001ff,
writing 5c001ff)
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
PM: Writing back config space on device 0000:01:01.0 at offset 1. (Was 2900000,
writing 2900107)
PM: Writing back config space on device 0000:01:01.0 at offset 3. (Was 0,
writing 4000)
PM: Writing back config space on device 0000:01:01.0 at offset 4. (Was 1,
writing 2001)
PM: Writing back config space on device 0000:01:01.0 at offset 5. (Was 0,
writing e0200000)
pnp: Device 00:03 does not supported activation.
pnp: Device 00:04 does not supported activation.
Restarting tasks... done
eth1: New link status: Connected (0001)
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Lid Switch [LID]

Comment 1 Lonni J Friedman 2006-04-30 23:17:04 UTC
Created attachment 128427 [details]
X log which includes suspend/resume cycle

Comment 2 Need Real Name 2006-08-17 06:18:54 UTC
I have seen some potentially related behaviour, but in reverse, on my Lenovo
X60s laptop using the latest  xorg-x11-drv-i810-1.5.1.0-1.i386.rpm drivers from
updates-testing. (Before that update, the i810 driver would not even work at all
for me)

The system is working fine in 24 bit mode. Xine plays .mpg files normally. 

Start audacity. Quit audacity. 

Xine's output using the "xv" video-out plugin is now ugly looking (as though we
were in 16 color mode or something like that). It looks fine using the "xshm"
plugin.

Switch to console CTRL-ALT-F1. switch back to X session using ALT-F7. Still ugly
using xv, but fine using xshm. (So merely switching to console and back does not
cure the problem)

Switch to console CTRL-ALT-F1. Suspend to RAM using Fn-F4. Resume. Switch back
to X session using ALT-F7. Now everything works again using the "xv" plugin!
Suspend/Resume somehow cures the symptoms. 



Comment 3 Han-Wen Nienhuys 2006-10-19 14:45:49 UTC
I have a related problem. After suspend, there a pixel-line of the screen is
copied to another location of the screen (see also attached PNG), which is
especially annoying as this will smear out over a scrolling window.

Apparently, the copy is offset by a fixed amount; I have the problem at
1600x1200 (24bpp). Moving to lower resolution shifts the line to the bottom of
the screen, and at 1024x768 the artefact is not visible. 

This is on a Thinkpad T60, with i945 chipset.
 

Comment 4 Han-Wen Nienhuys 2006-10-19 14:46:43 UTC
I have

[hanwen@haring ~]$ rpm -qa |grep  xorg-x11-drv-i810 
xorg-x11-drv-i810-1.6.5-9.fc6
xorg-x11-drv-i810-devel-1.6.5-9.fc6


Comment 5 Han-Wen Nienhuys 2006-10-19 14:47:51 UTC
Created attachment 138877 [details]
drawing corruption

Comment 6 Need Real Name 2006-11-07 02:50:29 UTC
I think I may understand Han-Wen Nienhuys problem; if the GTT table is
corrupted, you will see such symptoms. Perhaps we need to restore the GTT table
on resume.

Comment 7 Need Real Name 2006-11-07 02:51:37 UTC
btw, filing bugs here is not that useful; we don't scan redhat bugzilla during
X.org development. Please make sure all of your issues are filed (and these are
all separate) to X.org bugzilla.

Comment 8 Lonni J Friedman 2006-11-07 03:07:25 UTC
Thanks Keith.  I've filed a new bug now:
https://bugs.freedesktop.org/show_bug.cgi?id=8923

I'm hoping that it will get more love than this bug has gotten from the FC folks.

Comment 9 Nigel Cunningham 2006-12-03 22:13:48 UTC
This looks like it might be a duplicate of Bug 214023. Could you please try 
the updated xorg driver linked to there?

Comment 10 Lonni J Friedman 2006-12-03 22:23:41 UTC
I don't see any updated xorg drivers in bug 214023.  Also, this bug is against
FC5, not FC6.

Comment 11 Han-Wen Nienhuys 2006-12-17 22:33:42 UTC
I've opened a bug on freedesktop.org,
https://bugs.freedesktop.org/show_bug.cgi?id=9381 about my bug.

Comment 13 Matěj Cepl 2006-12-20 09:38:02 UTC
Reading https://bugs.freedesktop.org/show_bug.cgi?id=8923#c7, I think you should
rather upgrade to the current release of Fedora, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".