late resume failure -- chvt hang

[Shaved Wookie]

Hi there,

My apologies if this is a dupe, but I didn't know any way of transferring the automatically collected data to another bug report.

Anyway, the machine is a HP Mini 1010NR and this happens reasonably often. It might be my imagination, but it seems to happen more often after automatic "Power Devil" suspend / hibernates than when I do it myself from the system menu.

ProblemType: KernelOops
Annotation: This occured during a previous suspend and prevented it from resuming properly. The resume processing hung very near the end and will have appeared to have completed normally.
Architecture: i386
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/share/apport/apportcheckresume
Failure: late resume
InterpreterPath: /usr/bin/python2.6
MachineType: Hewlett-Packard HP Mini
Package: linux-image-2.6.28-11-generic 2.6.28-11.38
ProcAttrCurrent: unconfined
ProcCmdLine: root=UUID=70344f85-8d93-432c-919f-7db6cba30b4c ro quiet splashs
ProcCmdline: /usr/bin/python /usr/share/apport/apportcheckresume
ProcEnviron: PATH=(custom, no user)
ProcVersionSignature: Ubuntu 2.6.28-11.38-generic
SourcePackage: linux
Tags: resume suspend resume-late-hang
Title: [Hewlett-Packard HP Mini] late resume failure
UserGroups:

[Andy Whitcroft (apw)]

Looking at the SleepLog.txt we can see that we were waiting on the suspend chvt to terminal 63:

    /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success.
    /usr/lib/pm-utils/sleep.d/75modules suspend suspend: success.
    /usr/lib/pm-utils/sleep.d/90chvt suspend suspend:

We can see that the chvt is still running, and has been for nearly an hour, it is clearly hung:

    root 4435 4282 0 17:57 ? 00:00:00 /bin/sh /usr/lib/pm-utils/sleep.d/90chvt suspend suspend
    root 4441 4435 0 17:57 ? 00:00:00 chvt 63
    [...]
    root 5070 1 0 18:50 ? 00:00:00 /bin/sh /etc/init.d/rc 0

So this looks like it is an issue with the chvt implementation.

[Andy Whitcroft (apw)]

We have a number of duplicates of this bug. On bug #354151 the reporter notes that they asked for a suspend and they ended up at the gdm login prompt. We also have heard anecdotal evidence of suspend/resume working correctly but that the resume comes back to the gdm login screen and not the pre-suspend desktop. Both of these would be consistant with the X server exiting in responce to the chvt notification, which would also explain the chvt hang.

[Andy Whitcroft (apw)]

If any of those affected see this effect, returning immediatly to gdm login, could you attach a copy of your X11 log file from the previous X run, the file /var/log/Xorg.0.log.old

[Matt Zimmerman (mdz)]

The symptom of resuming to the gdm prompt is consistent with bug 328035 (fixed post-beta), so it might be worth checking the gdm log to see if that's what is happening. There may be multiple issues mixed in here.

[Matt Zimmerman (mdz)]

The symptom of resuming to the gdm prompt is consistent with bug 328035 (fixed post-beta), so it might be worth checking the gdm log to see if that's what is happening. There may be multiple issues mixed in here.

I can't think of a reason why the X server should exit in response to a chvt notification.

[Andy Whitcroft (apw)]

bug #359479 is a duplicate of this and also shows the 'gdm rather than my desktop' behavior. The chvt would hang if the X-server exited as a result of any bug in the window while we are trying to chvt back to it. The bug above mentioned above (bug #328035) and we should get this retested once the fix for that is released.

[Andy Whitcroft (apw)]

It appears that that fix has been released now. Could those of you affected by this bug please retest once you have ensured you have the following xorg update installed. Please report back here:

xorg-server (2:1.6.0-0ubuntu5) jaunty; urgency=low

  [Tormod Volden]
  * Disable 160_log_timestamping.patch before the beta, this was only used
    for testing, and the patch also has a serious stack corruption bug.
    (LP: #328035)

[Andy Whitcroft (apw)]

This is likely to be a difficult one to reproduce. As we believe it is fixed closing Fix Released. If any of you see this with the xorg-server (2:1.6.0-0ubuntu5) or later installed please reopen this bug by moving it to 'New'.

[Matt Zimmerman (mdz)]

It looks like this bug's status was changed erroneously back to Fix Committed. Setting back to Fix Released where it belongs.