|
Bugzilla – Full Text Bug Listing |
| Summary: | resume takes more than a minute | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Felix Möller <felix> |
| Component: | Kernel | Assignee: | Pavel Machek <pavel> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | burnus |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | dmesg | ||
|
Description
Felix Möller
2008-09-25 22:14:36 UTC
Created attachment 241796 [details]
dmesg
hm seems like the dmesg is not really interesting. Is there anything else to provide? pm-suspend.log does not look more interesting. probably a duplicate of bug 427052. If "nohz=off" or a newer kernel of the day do not help, please reopen. *** This bug has been marked as a duplicate of bug 427052 *** I am now testing kernel-default-2.6.27-rc7.28.1.i586.rpm Coming home from work today the system took a little over 7 minutes to resume. But the problem seems to be related to suspend time. When suspending an resuming a few seconds later the problem does not appear. Ok, so this looks like a different issue. Can you try if it works better if booted with "nohz=off"? If it turns out not to be dependend on suspend time, try with minimum ammount of modules.. maybe one of them just takes long to resume. sorry for not answering my @opensuse.org adress is down for two weeks now... With current kernel (2.6.27-rc7-12-pae) resume does not take several minutes anymore. It is now about 5 seconds. So I think this is fixed for me. Sadly suspend is not really reliable... But it is not repeatable: sometimes the system does nothing, sometimes the keyboard is dead, sometimes X freezes, sometimes the battery goes empty while suspended ... It is my feeling that Linux uses way more energy while suspended than OS X ... Ok, so this is fixed... "Not being reliable" is bad... and yes we need more info to debug this. Can you at least reliably kill the machine by suspending/resuming ten times in a row? THen we could binary search for a module that breaks it... Using more energy while suspended is quite common (and nasty and hard to debug). That would be separate bug report. |