Re: [PATCH 0/7] more HPET fixes and enhancements

[Petr Vandrovec <vandrove@vc.cvut.cz>]

Clemens Ladisch wrote:
> Petr Vandrovec wrote:
>
> > Clemens Ladisch wrote:
> >
> > > However, I've patched my kernel to initialize the HPET manually
> > > because my BIOS doesn't bother to do it at all.  A quick Google search
> > > shows that in most cases where the BIOS _does_ bother, the third timer
> > > (which is the only free one after system timer and RTC have grabbed
> > > theirs) didn't get initialized and is still set to interrupt 0 (which
> > > isn't actually supported by most HPET hardware).
> > >
> > > This means that hpet.c must initialize the interrupt routing register
> > > in this case.  I'll write a patch for this.
> >
> > I'm using attached diff.
>
>
> The other changes of your patch are already in the -mm kernel.
>
>
> > But I gave up on HPET.  On VIA periodic mode is hopelessly broken,
>
>
> I've heard it works with timer 0, and the capability bit on timer 1 is
> just wrong.

Nope.  Periodic mode works (I've made my tests on timer #2), you can just
set only period (through way which sets value according to the spec), and
you cannot set current value (at least I do not know how).  So I can
program VIA hardware to generate periodic interrupt, there is just
unavoidable delay up to 5 minutes. I've worked around by setting period
to 1 tick, so in 5 minutes value and main timer synchronize, and if
timer is not stopped after that then it stays synchronized with main timer.

> > And fixing this would add at least 1.5us to the interrupt handler,
> > and it seems quite lot to me...
>
>
> I didn't measure how much reading the RTC registers costs us, but
> those aren't likely to be faster.
>
> I'm thinking of a different approach:  Assuming that such a big delay
> almost never actually does happen, we run a separate watchdog timer
> (using a kernel timer that is guaranteed to work) at a much lower
> frequency to check whether the real timer got stuck.  This trades off
> the HPET register read against the timer_list overhead (and that we
> still lose _some_ interrupts when the worst case happens).

It would work for VMware's use of /dev/rtc if number of missed interrupts
will be reported on next read.  Otherwise it might be a problem for
keeping time between host and virtual machines in sync.
								Petr

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/