On Tue, 24 Apr 2012, Vladimir Davydov wrote:
If hpet is enabled by hpet_late_init() - this usually occurs on systemsThis explanation is worse than an oracle and aside of that, it's
with buggy BIOS, which does not report about hpet presence through ACPI,
hpet_clockevent's event_handler can be left uninitialized by
clockevents_register_device() because of hpet_clockevent low rating (by
the time hpet_late_init() is called, high prio apic timers have already
been setup). The event_handler is then initialized a bit later by the
How the hell is clocksource_done_booting() related to the HPET
Normally, timer interrupts should not be delivered between these twoHow is kexec related to this?
calls, but if e.g. the kernel is booted using kexec, there might be some
pending interrupts from the previous kernel's context, which can lead to
a NULL pointer dereference in timer_interrupt().
And how should pending interrupts be not handled by the always first
initialized PIT ?
Avoid this by initializing hpet's event_handler to noop in its definition."Avoid" is the correct term: You're avoiding to track down the root
cause of the problem.
This is fairy tale mode. I really love fairy tales, just not in the
context of kernel code.
Please provide proper proof why this can happen instead of some