[lkml]   [2005]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-10-19 17:58    [W:0.032 / U:0.772 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site