hpet_disable() call sites
From: Jan Beulich
Date: Tue Mar 27 2012 - 04:19:08 EST
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()?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/