Messages in this thread | | | Date | Wed, 19 Oct 2005 17:56:18 +0200 | From | Petr Vandrovec <> | Subject | Re: [PATCH 0/7] more HPET fixes and enhancements |
| |
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/
| |