[PATCH Precise SRU] tick: Fix the spurious broadcast timer ticks after resume

[Tim Gardner]

On 10/15/2012 11:09 AM, Joseph Salisbury wrote:
> On 10/15/2012 12:05 PM, Tim Gardner wrote:
>> 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
> It looks like the patch from the upstream bug report is different than
> upstream commit a6371f8.  The patch from the upstream bug report is:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065076/+attachment/3394539/+files/new_s2ram.patch
>
>
> However, this patch hasn't been submitted upstream yet.  Would you like
> me to build a test kernel with this patch?
>
> Thanks,
>
> Joe
>

Lets try with the cherry-picked patch first 
(a6371f80230eaaafd7eef7efeedaa9509bdc982d)

-- 
Tim Gardner tim.gardner at canonical.com