Messages in this thread | | | Date | Tue, 27 Mar 2012 09:19:53 +0100 | From | "Jan Beulich" <> | Subject | hpet_disable() call sites |
| |
In c86c7fbc829e27e2a4093f98ded9fbd75e515adb (and subsequently 0c1b2724069951b1902373e688042b2ec382f68f) hpet_disable() gets called in the shutdown path. The first of them gives HPET enabling through PCI quirks in conjunction with the use of legacy replacement as sole reason, yet even outside of the context of either the starting up kernel has a problem if the HPET is in an unexpected state, in particular preventing "normal" timer interrupts from occurring (which was in particular found to be the case during kdump attempts after Xen was running).
Is there any reason why hpet_disable() should not also be called from (or some equivalent action be taken, perhaps including clearing certain bits in the individual counters' configuration registers, which are apparently - but perhaps wrongly - implied to be clear in e.g. hpet_set_mode(), in) hpet_enable()?
Thanks, Jan
| |