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

[Joseph Salisbury]

On 10/15/2012 01:43 PM, Tim Gardner wrote:
> 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)
>

Ok.  I'll let you know the testing results.