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

Andy Whitcroft apw at canonical.com
Mon Mar 23 09:08:35 UTC 2009


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




More information about the kernel-team mailing list