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, 08:08 AM
Andy Whitcroft
 
Default UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume

On Mon, Mar 23, 2009 at 08:43:13AM +0000, TJ wrote:
> 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;

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-23-2009, 08:53 AM
TJ
 
Default UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume

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.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-23-2009, 09:07 AM
Andy Whitcroft
 
Default UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume

On Mon, Mar 23, 2009 at 10:59:03AM +0100, Stefan Bader wrote:
> 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.

Yes indeed we have yet to do anything here.

-apw

--
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:02 PM.

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