[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.023 / U:71.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site