UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume
 

Andy Whitcroft wrote:
> 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
>
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

--

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

UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoid false kernel oops on resume
 

Andy Whitcroft wrote:
> 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
>


We twiddled with the SATA soft reset timeout so that it is compliant
with the spec in Jaunty commit b65db6fd5d341d27f6d3f62c2b111ca0df0c6dee.
Are we still seeing link restarts that exceed this time?

--
Tim Gardner tim.gardner@canonical.com

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