Bug 14996
| Summary: | HPET WARNING at kernel boot | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Matteo Croce (rootkit85) |
| Component: | i386 | Assignee: | platform_i386 |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | john.stultz, tglx, venki |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.33-rc3 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
Use spinlock_irqsave to disable irqs in hpet_next_event |
||
|
Description
Matteo Croce
2010-01-06 14:51:03 UTC
Matteo: Few questions: Did anything like this crop up with older kernels? Does this happen every boot? Or is it sporadic? thanks -john Thomas: Would a possible fix be to disable the hpet clockevent driver in some fashion similar to how we disable the TSC clocksource? Alternatively, I don't see any locking around the hpet_Tn_CMP(timer) writing, which makes it seem possible that a race could occur. I've not totally audited the code, but it would make sense that a clockevent device could only have one operation on it done at a time, but maybe suspend/resume paths are catching us? Matteo: Could you also attach a dmesg log? Created attachment 24544 [details]
dmesg
It happens with 2.6.31, .32 and .33-rc4 at every boot Venkatesh: Does this look like the unannounced hpet related hardware errata that was brought up earlier on lkml (http://lkml.indiana.edu/hypermail/linux/kernel/0911.1/02305.html) ? Yes. This is the same problem as in the thread mentioned in comment #5. And as of now the problem is not yet announced in spec update. I hear it will be there soon. May be its safe to have the workaround and update with the pointer to spec update once that goes public. Created attachment 25096 [details]
Use spinlock_irqsave to disable irqs in hpet_next_event
This patch adds locking around the hpet_next_event internals. Its really just to make sure we're not hitting any sort of driver that's taking a long time while we set the event to expire. I could have probably used local_irq_disable() but this should also remove the possibility that lots of cpus hammering on the hpet_write might cause the write to stall and take longer then expected.
It would be interesting to see if the messages continue with this patch or go away. If they continue, its likely a hardware issue or an SMI issue, which we can't really control. If they go away, we'll have to look at what is going on in irq context that is preempting this function for so long.
Oh, and this patch is totally un-tested, so my apologies if it doesn't boot.
(In reply to comment #7) > Created an attachment (id=25096) [details] > Use spinlock_irqsave to disable irqs in hpet_next_event > > This patch adds locking around the hpet_next_event internals. Its really just > to make sure we're not hitting any sort of driver that's taking a long time > while we set the event to expire. I could have probably used > local_irq_disable() but this should also remove the possibility that lots of > cpus hammering on the hpet_write might cause the write to stall and take > longer > then expected. > > It would be interesting to see if the messages continue with this patch or go > away. If they continue, its likely a hardware issue or an SMI issue, which we > can't really control. If they go away, we'll have to look at what is going on > in irq context that is preempting this function for so long. > > Oh, and this patch is totally un-tested, so my apologies if it doesn't boot. Ugh! Attached this to the wrong bug #. Please ignore. Venkatesh posted a patch to document and resolve this issue: http://patchwork.kernel.org/patch/82092/ It fixes, great |