resume hangs late in the process appear working and yet report failure on next reboot

One suggestion might be to clean up the pm-utils state file during shutdown, so that if the user reboots or shuts down cleanly, it won't trigger a report like this.

However, we still need to find out how I ended up with a state file indicating the system was suspending, when it was clearly up and running.

I had the crash resuming on a Lenovo ThinkPad X61s, model 7668CTO

On Fri, Feb 27, 2009 at 08:27:27AM -0000, rubiojr wrote:
> I had the crash resuming on a Lenovo ThinkPad X61s, model 7668CTO
>
> ** Attachment added: "report attached"
> http://launchpadlibrarian.net/23171911/susres.2009-02-27_09%3A19%3A20.337714.crash

Please file that separately, as yours appears to be a genuine report.

--
 - mdz

Thanks Matt, done.

Andy, can you pleaes have a look at this?

@Martin -- sure .. .thanks for the pointer.

@Matt -- could you confirm if you recently had had a kernel update? And might you have attempted to suspend while a reboot was pending for it? I am suspicious of an interaction there.

On Fri, Feb 27, 2009 at 07:32:54PM -0000, Andy Whitcroft wrote:
> @Matt -- could you confirm if you recently had had a kernel update? And
> might you have attempted to suspend while a reboot was pending for it?
> I am suspicious of an interaction there.

I had upgraded many times without rebooting, so it's very likely that the
kernel had been updated and a reboot was pending.

--
 - mdz

Ok I have managed to hit the same issue here. There is definatly a tie in between a kernel update disabling suspend, an attempt to suspend, and a subsequent reboot. Will look at this interaction.

In the interim it seems reasonable to also prevent these false positives. When the system is being shutdown normally we know that there cannot be a suspend/hibernate in progress. Should we find an onging suspend/resume indicated we know its is a false indication and can clear it out.

Produced a apport topic branch with this work-around, see related branches.

This cannot be a kernel bug. We are recording that we entered suspend (or hibernate) somehow not going there and yet the state remains recorded. This would be a pm-utils bug.

Tested the apport changes in my PPA. Proposing this change for merge to apport trunk.

Ok. In the process of testing this I think I have hit the actual cause of the issue. If a resume fails late on say resuming bluetooth then the resume may have gotten far enough that the user in front of the screen percieves the machine to be fully functional. They may well see the screen lock and be able to login. About the only thing which will not work is a second attempt to suspend which should at most be able to lock the screensaver. If the user (even much) later reboots the machine the failure will be detected and reported. The user has not seen any problem and reasonably will believe that the suspend/resume failure report is false.

We need to enhance the reporting to catch this case and record the information we need as soon as this is detected. Pretty much we can only tell when we are asked to shutdown. At this point we can see that there is still a suspend/hibernate in progress and we are in a position to check for the presence of the hanging processes. We should also report this as a different type of failure to make it clear that it was the resume and that it would have appeared just fine. We should also be recording the basic suspend logs in the apport bugs.

If you want to pinpoint exactly where in the resume process it is hanging, and you know it is after the kernel haded control back to pm-utils, you can run pm-suspend with PM_DEBUG=true in the environment -- this will cause pm-suspend and all the hooks to be traced.

This is probably one of the hooks hanging, causing the resume process to halt, which prevents pm-utils from releasing its lock file.

Matt, if you can reliably reproduce the issue can you attach your /var/log/pm-suspend.log file to this bug?

Also after rebooting, can you try running

PM_DEBUG=true pm-suspend

as root and attach the /var/log/pm-suspend.log that creates to this report?

On Fri, Mar 27, 2009 at 03:38:49PM -0000, vlowther wrote:
> Matt, if you can reliably reproduce the issue can you attach your
> /var/log/pm-suspend.log file to this bug?
>
> Also after rebooting, can you try running
>
> PM_DEBUG=true pm-suspend
>
> as root and attach the /var/log/pm-suspend.log that creates to this
> report?

I haven't been able to reliably reproduce this, though it has happened to me
more than once.

I've modified pm-action to set PM_DEBUG=true and will grab the log file
if/when it happens again.

Andy, should we just enable this by default for now? I don't expect the log
file is excessively huge, and this would be useful debug data.

--
 - mdz

We get a fair amount of additional data in the pm-suspend.log and my latest branch both fixes detection of this kind of failure and adds reporting of this additional logfile

This bug was fixed in the package apport - 0.147

---------------
apport (0.147) jaunty; urgency=low

  * bin/apportcheckresume: report the pm-suspend.log/pm-hibernate.log
    from /var/lib.
  * bin/apportcheckresume: only attempt to attach the stress log if its is
    present.
  * bin/apportcheckresume, debian/apport.init: add detection for late
    resume hangs, those where the user thinks the system was working.
    (LP: #335323)

 -- Andy Whitcroft <email address hidden> Mon, 30 Mar 2009 09:47:28 +0200

I believe the apport changes are sufficient to detect and report this late-resume issue, closing out the pm-utils task.

On Mon, Mar 30, 2009 at 10:23:26AM -0000, Andy Whitcroft wrote:
> I believe the apport changes are sufficient to detect and report this
> late-resume issue, closing out the pm-utils task.

Shouldn't pm-utils still clean up its lockfile on shutdown?

--
 - mdz

We will remove that status file when it reports the bug on the next boot. As there now a hang log that will trigger a different type of bug. We have a number already. They are looking like there is a chvt hang, and there may be a tie in to jumping to the gdm login screen. I am suspicious the x-server is exiting. We are tracking this on bug #352178.