[PATCH] UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to avoidfalse kernel oops on resume

[Mario_Limonciello at Dell.com]

Matter of fact the change for the 5 seconds for sata links has landed
upstream now:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
t;h=e7d3ef13d52a126438f687a1a32da65ff926ed57

Regards

-----Original Message-----
From: kernel-team-bounces at lists.ubuntu.com
[mailto:kernel-team-bounces at lists.ubuntu.com] On Behalf Of Tim Gardner
Sent: Monday, March 23, 2009 8:07 AM
To: Andy Whitcroft
Cc: kernel-team
Subject: Re: [PATCH] UBUNTU: SAUCE: PM: Increase TEST_SUSPEND_SECONDS to
avoidfalse 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 at canonical.com

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