[PATCH Precise SRU] tick: Fix the spurious broadcast timer ticks after resume
Tim Gardner
tim.gardner at canonical.com
Mon Oct 15 16:05:03 UTC 2012
On 10/12/2012 01:06 PM, Seth Forshee wrote:
> On Fri, Oct 12, 2012 at 12:32:53PM -0600, Tim Gardner wrote:
>> From: Suresh Siddha <suresh.b.siddha at intel.com>
>>
>> BugLink: http://bugs.launchpad.net/bugs/1065076
>>
>> During resume, tick_resume_broadcast() programs the broadcast timer in
>> oneshot mode unconditionally. On the platforms where broadcast timer
>> is not really required, this will generate spurious broadcast timer
>> ticks upon resume. For example, on the always running apic timer
>> platforms with HPET, I see spurious hpet tick once every ~5minutes
>> (which is the 32-bit hpet counter wraparound time).
>>
>> Similar to boot time, during resume make the oneshot mode setting of
>> the broadcast clock event device conditional on the state of active
>> broadcast users.
>>
>> Signed-off-by: Suresh Siddha <suresh.b.siddha at intel.com>
>> Tested-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> Tested-by: svenjoac at gmx.de
>> Cc: torvalds at linux-foundation.org
>> Cc: rjw at sisk.pl
>> Link: http://lkml.kernel.org/r/1334802459.28674.209.camel@sbsiddha-desk.sc.intel.com
>> Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
>> (cherry picked from commit a6371f80230eaaafd7eef7efeedaa9509bdc982d)
>>
>> Signed-off-by: Tim Gardner <tim.gardner at canonical.com>
>
> I'm rather confused.
>
> The bug report is about a failure to resume, but the commit message
> describes fixing a spurious timer interrupt. On the bug the reporter
> states that upstream kernel 3.6 is still affected, and this patch was
> merged during 3.4. There's also no verification that I can see that
> backporting this patch to 3.2 fixes the issue.
>
> So how did you arrive at the conclusion that this patch fixes the bug?
>
Well, I found the patch from the upstream bug report after it was merged
in Linus' tree. However, you're right in that it doesn't really seem
related (aside from some folks reporting success). I'll get Joe to build
a test kernel and harvest the results.
rtg
--
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team
mailing list