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-
On Mon, Mar 30, 2009 at 10:23:26AM -, 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
--
resume hangs late in the process
I believe the apport changes are sufficient to detect and report this
late-resume issue, closing out the pm-utils task.
** Changed in: pm-utils (Ubuntu)
Status: In Progress => Invalid
--
resume hangs late in the process appear working and yet report failure on next
reboot
https://bugs.la
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/apportcheckr
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
--
resume hangs late in the process appear working and yet report failure on next
reboot
https://bugs.launchpad.net/bugs/3
On Fri, Mar 27, 2009 at 03:38:49PM -, 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
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 hoo
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?
--
resume hangs late in the process appear
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 an
** Description changed:
+ If a resume hangs late enough in the resume cycle then the resume may
+ appear to the user in front of the machine to have completed
+ successfully. Their screen saver may appear, they can login and use the
+ machine quite normally. However the suspend really is not com
** Summary changed:
- (false positive?) [LENOVO 6465CTO] suspend/resume failure
+ resume hangs late in the process appear working and yet report failure on
next reboot
--
resume hangs late in the process appear working and yet report failure on next
reboot
https://bugs.launchpad.net/bugs/33532
11 matches
Mail list logo
