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

Tim Gardner tim.gardner at canonical.com
Mon Mar 23 13:06:41 UTC 2009


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




More information about the kernel-team mailing list