Messages in this thread | | | From | Kirill Korotaev <> | Date | Thu, 5 Feb 2009 11:01:07 +0300 | Subject | Re: [PATCH] x86: fix hpet timer reinit for x86_64 |
| |
On 2/4/09 4:49 PM, "Ingo Molnar" <mingo@elte.hu> wrote:
> > > * Pavel Emelyanov <xemul@openvz.org> wrote: > >> There's a small problem with hpet_rtc_reinit function - it checks >> for the >> hpet_readl(HPET_COUNTER) - hpet_t1_cmp > 0 >> to continue increasing both the HPET_T1_CMP (register) and the >> hpet_t1_cmp (variable). >> >> But since the HPET_COUNTER is always 32-bit, if the hpet_t1_cmp >> is 64-bit this condition will always be FALSE once the latter hits >> the 32-bit boundary, and we can have a situation, when we don't >> increase the HPET_T1_CMP register high enough. >> >> The result - timer stops ticking, since HPET_T1_CMP becomes less, >> than the COUNTER and never increased again. >> >> The solution is to cut the upper 32-bit from the hpet_t1_cmp >> variable to make the comparison to HPET_COUNTER correct. >> >> Reported-by: Kirill Korotaev <dev@openvz.org> >> Signed-off-by: Pavel Emelyanov <xemul@openvz.org> > > applied to tip/timers/urgent, thanks Pavel! > > I'm wondering, what symptoms were seen due to the bug? Did system time stop, > or did it become erratic, or were there outright lockups?
Symptoms were observed in user space. An application doing read() on /dev/rtc blocked sometimes for a long periods of time (as turned out - until counter gets wrap around).
Regards, Kirill
| |