Messages in this thread | | | Date | Thu, 5 Feb 2009 15:53:11 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86: fix hpet timer reinit for x86_64 |
| |
* Kirill Korotaev <dev@parallels.com> wrote:
> 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).
okay. Could you guys please put this info in the commit log on the resubmitted patch? Thanks,
Ingo
| |