Bug 7834

Created attachment 6512 [details]
log when ghosting occurs (i810 1.6.3)

Ghosting occurs after S3 resume when SWcursor is set.	resume only works when
the 
   cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config
   echo -n mem > /sys/power/state
   cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0
hack is used.

I'm giving up on using the current driver with suspend/resume. It's just
unworkable given the BIOS has to do the work.

Try the modesetting branch which should work much better with suspend/resume.

Oh, there is the alternative of looking at
/usr/src/linux/Documentation/power/video.txt for other helpful issues with suspend .

You might want to try using the s3_bios option to see if that helps.

Created attachment 6513 [details]
log with good resume  (i810 1.6.1)

OK, I'll try various permutations and report back if I have any success.

In the meanwhile, here is the log from 1.6.1 with normal (HW) cursor.  After
resume it works fine.  Curiously, at resume it does give the blue aura over the
top bar of the screen, but upon clicking the mouse button, the aura disappears
and the system behaves normally. The cursor is in place and windows draw
correctly. What changed between 1.6.1 and 1.6.3?

None of the S3 suspend-to-ram alternatives I've tried so far seem to help. Not
s3_bios nor s3_mode not s2ram.

Fortunately s2disk (new app for S4 suspend-to-disk) appears to work fine, so
this is probably my best workaround. It's what I wanted all along, in fact, I've
only been using S3 because S4 never worked before.

I can confirm accidental disappearing of cursor after S3 resume in modesetting
branch.

Sometimes (I did not figure out when exactly), after S3 resume, the cursor is
shown at position 0,0 instead of current position. If this happen and I switch
to console and back, then I got only blank screen. Dumping register shows that
Pipe SRC is set to random value.

If I cycle windows on desktop using [alt]-[tab] then cursor is back normal until
it crosses border of any window.

For me, it looks like accidental memory corruption.

Can you try the latest git repo.

Is vbetool being used in the suspend/resume scripts ??

If so, turn it off and report back.

The bug priority was upgraded (P2->high) with the bugzilla configuration change.
I'm Changing the priority back to the normal one.
Sorry for the spam.

Closing. Please use the new 2.0 driver.

Sorry for the bad news, S3 suspend is still broken under intel 2.0.  The cursor is now fine (I've adjusted the bug title accordingly) but the ghosting windows are still in play.

Running intel 2.0.0 (debian 2:2.0.0-1) under xserver 1.3 (debian 2:1.3.0.0.dfsg-4), for Intel 855GM (IBM Thinkpad R51).

The same behaviour occurs using three alternate methods of suspend: the default method of the gnome-power-manager (2.18.2), clicking on "suspend"; and running the script mentioned earlier:
   cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config
   echo -n mem > /sys/power/state
   cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0

or its variant with kbd console tools:
   curcons=`fgconsole`
   chvt 1
   cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config
   sync
   sleep 2
   echo -n mem > /sys/power/state
   cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0
   chvt $curcons

(so vbetools is not being used).

Created attachment 9971 [details]
log for intel 2.0

The X log obtained by entering S3 suspend from gnome-power-manager

The i810 Option VBERestore helps me with the ghosting windows. s2disk and s2ram use common workarounds for certain chipsets, which seems to have vbetool included for the 855gm. With the following option it works fine with normal suspend2ram:

Option          "VBERestore"    "true"

Sascha, which version of the driver are you working with?

The man page for the intel driver (2.0.0) does not have the VBERestore option, and indeed, when I add the option, the server log reports

(WW) intel(0): Option "VBERestore" is not used

Correspondingly, the problem of the ghost windows is still there upon S3 suspend/resume.

Looks like VBERestore was removed last September in commit b6ba268d0d5f22c6a18ce45416452fce83438620

You could also try booting your kernel with 'acpi_sleep=s3_bios' to see if that helps.

acpi_sleep=s3_bios does not work, unfortunately (with linux kernel 2.6.22). Upon resume the display shows the last screen at point of suspending (with the message "Suspending") but goes no further with the system frozen.

acpi_sleep=s3_mode works the same way as with no option, resulting in the ghosted windows.

This is with linux 2.6.22, xserver 1.3.0.0 and X intel video driver 2.1.0.

Probably worth mentioning that the ghosted window problem seems to be fixed now.  Invoking S3 suspend-to-ram via the Gnome suspend button (part of Gnome power management), the computer now enters suspend and resumes successfully. All windows (and mouse cursor) seem to be working correctly.

Versions are
intel driver 2.1.1   (Debian 2:2.1.1-4)
Xorg  1.4   (2:1.4-3)
Linux kernel 2.6.22  (2.6.22-3)
gnome-powermanager 2.20.0   (2.20.0-1+b1)

There is a problem that when switching to virtual console via Ctrl-Alt-F1, the virtual consoles come up blank, but I think that might be a different bug.  Switching to Alt-F7 returns successfully back to the X session.

Ok, I'll mark this fixed then.  You can file another bug or look for a DUP of the other problem.

One thing to check with the VT switch problem is whether it works correctly before a suspend/resume cycle.  If it works then but gives you a blank screen after you've done a suspend/resume, then it's possible the i915 DRM suspend/resume patch I posted to lkml and dri-devel@lists.sf.net will help you out.

Thanks for filing the bug and testing.

Curiously about the VT switching problem, seems it only occurred after S3 suspend-to-ram.  Resuming from S4 suspend-to-disk (suspending from the same session where VT switching was broken), the virtual consoles were restored again.  Anyway, I'll follow this problem up separately in the VT bug reports.

Yeah, that means we're probably not saving & restoring VGA text mode properly.  Can you give that DRM patch a try?  Or just try the latest bits from the Mesa DRM tree (git://anongit.freedesktop.org/git/mesa/drm)?  If that doesn't work, please file another bug or add to one of the existing ones...

Thanks,
Jesse