[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