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
TJ
 
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
occurred:

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.
*/
-#define TEST_SUSPEND_SECONDS 5
+#define TEST_SUSPEND_SECONDS 12

static unsigned long suspend_test_start_time;

--
1.6.0.4


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
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.

Stefan

--

When all other means of communication fail, try words!



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

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