vbestate handling is broken in sleep/resume (Presario 700)

You're absolutely right, this is broken. Does it work if you edit resume.sh and change that block to read

# Attempt to restore some video card state
if [ x$SAVE_VBE_STATE = xtrue ]; then
  vbetool vbestate restore <$VBESTATE
  if [ $VBEMODE != "3" ]; then
    vbetool vbemode set $VBEMODE;
  fi
fi

? The reason to move back to mode 3 is that it's easier to try to get the card into text mode and work from there than it is to reinitialise directly into the vesa mode.

Thanks, swapping the order like suggested above made wonders! Now the laptop sleeps and resumes happily with no grunginess.

The hibernation is more tricky, I seem to have more luck replacing "shutdown" with "platform" in /etc/defaults/acpi-support, but I have to do more tests to see exactly what is going on.

The above changes seem to have made they way into the newly organised /etc/acpi/resume.d/17-video-restore.sh, so maybe we can close this bug.

But I still experience problems resuming from hibernation: The screen goes black as if screen blanking is on. If a press a key, the screen turns on, I can see Ubuntu colours and the black shades from windows (maybe just old cruft from the video memory), then it freezes solid - no reaction to CapsLock or SysReq. This happens only if I have let the machine hibernate for some time, so this could have something to do with power management thinking it is time to lock or turn off the screen (for what I know).

I had Rhythmbox playing while I was hibernating, and at resume the music continued to play. Only when I hit a key to wake up the screen, the music went into a 0.5s-period loop together with the freeze described above.

I don't have a serial port on this laptop. Is there any way I can do any debugging?

In PowerManagement preferences I have put-computer/screen-to-sleep set to Never. I once resumed into a running screensaver (with no password locking), so the screensaver on its own should not be a problem.

I logged in through ssh from another machine, and the ssh session survived the hibernation. There was in particular this message:
[4298031.572000] [drm:savage_bci_wait_event_shadow] *ERROR* failed!
[4298031.572000] [drm] status=0x00000a75, e=0x0a78

When I pressed a key on the laptop and it crashed again, there was nothing more coming to the "tail -f syslog" in the ssh session.

For completeness, dmesg from the failed resume.

I am now running without DRI, and it resumed fine this time. I have to try more (especially let it hibernate for longer time) to see if this is the problem.

I am tracking the drm errors and hangs in bug #43007. I think the vbestate handling in this bug is fine now.

I have to reopen this bug. If laptop-detect (inside /etc/init/vbesave) fails to detect a laptop (for instance because of bug #40503), the vbestate is not saved.

In resume.d/17-video-restore.sh the vbestate is unconditionally restored. I guess the command will just fail if the $VBESTATE file does not exist. Anyway, it would be better to check if the file exist before carrying on.

suspend.d/80-video-vesa-state.sh also takes for granted that the file was saved at boot.

I guess this kicks in only in the case where SAVE_VBE_STATE has been set to true _and_ laptop-detect fails. Maybe SAVE_VBE_STATE should be disabled somehow if laptop-detect fails.

Since laptop-detect is broken on my laptop, I put "LAPTOP=true" in /etc/default/acpi-support, and this seems to have fixed the display corruption I had at resume from hibernation.

How safe is it to use the vbestate saved during boot, now that usplash does its stuff? I inserted a "vbetool vbemode get" into /etc/init.d/vbesave and the result was 33047 and not 3.

I made a modified hibernate.sh, only sourcing the video-related scripts, and not doing the actual hibernation. After running this script the consoles are borked. Logging from that script, I see the vbetool complains:
++ vbetool vbestate restore
Function not supported

I said two comments ago that the "LAPTOP=true" trick had fixed the display corruption, but that is not true. It must have worked just intermittently.

3 comments ago I said the "vbemore get" returned 33047. This might be since: "The VESA specification does not require that "vbemode get" provides the correct mode if the current mode was set via some means other than the VESA BIOS extensions."

I looked some more into the vbetool code. The "Function not supported" message above comes from the do_set_mode(3,1) call in the restore_state function, which is equivalent to a "vbetool vgamode 3".

Actually, running "vbetool vgamode 3" (after switching to a console) cleans up the consoles again, apart from a gray background on some consoles which goes away by typing in it. Of course, the "Function not supported" appears, but it seems to do something good anyway.

Although I feel that my comments above about SAVE_VBE_STATE should be addressed at some point, I close the bug again for this time since this update fixed my consoles:

acpi-support (0.90) edgy; urgency=low

  * Explicitly switch the screen back to text mode if it was that way
    before resume

 -- Matthew Garrett <email address hidden> Sun, 15 Oct 2006 18:09:03 +0100