FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

LinkBack Thread Tools
Old 03-23-2009, 07:43 AM
Default UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume

Bug: # 286672

This arbitrary value is intended to detect failures during resume.

The default value of 5 seconds is however likely to lead to false
reports where no failure exists. After analysing all bug reports
that had attachments with logs with the string:

"PM: resume devices took XX seconds"

It appears there are two ranges of delays to address where no failure

1. 5-9 seconds: usually just slightly over 5 seconds
2. 10-12 seconds: usually a result of waiting for SATA links

Setting TEST_SUSPEND_SECONDS to 12 avoids both of these ranges
causing false bug reports.
kernel/power/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/power/main.c b/kernel/power/main.c
index b8f7ce9..5f73330 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -144,7 +144,7 @@ static inline int suspend_test(int level) { return 0; }
* The time it takes is system-specific though, so when we test this
* during system bootup we allow a LOT of time.

static unsigned long suspend_test_start_time;


kernel-team mailing list
Old 03-23-2009, 08:59 AM
Stefan Bader
Default UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume

TJ wrote:
> On Mon, 2009-03-23 at 10:20 +0100, Stefan Bader wrote:
>> Andy Whitcroft wrote:
>>> On Mon, Mar 23, 2009 at 08:43:13AM +0000, TJ wrote:
>>>> Bug: # 286672
>>> We are seeing a number of reports triggered by this. The code talks
>>> about using a WARN_ON to get the proper focus, but its not clear that it
>>> achieves that. Escpecially as this is now going to trigger kerneloops
>>> I believe. This does look like a reasonable approach. I wonder if 12
>>> is too close to the expected range. Perhaps 15 or 30 are more reasonable
>>> places to start producing serious errors.
>>> -apw
>> Probably 15. But i guess, whether by kerneloops or not, we probably get the
>> bugs reported anyways. Waiting for more than around 5s for resume makes me
>> start getting impatient at least.
>> Stefan
> I chose 12 seconds because I want to be sure to not lose any real Oops.
> At 12 seconds I'm already feeling a bit apprehensive - my original
> thought was it'd be 9 seconds but the few reports that went over 10
> (SATA link delays) persuaded me to push it up slightly more.
> We don't have sufficient quantity of reports from Jaunty in particular
> for me to feel confident of going higher without missing real issues.

Andy, havn't we spoken lately of this. IIRC we wanted felt that there might be
issues that still some soft resets are take slightly too long which cause
recovery to do a hard reset wlightly before the soft one is done. Which then
confuses the disk completely. And that it might be a good idea to add debugging
to see the events during recovery. But I am not sure we already did anything.



When all other means of communication fail, try words!

kernel-team mailing list

Thread Tools

All times are GMT. The time now is 03:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org