lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Mar 2012 09:19:53 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	<mingo@...e.hu>, <hirofumi@...l.parknet.co.jp>
Cc:	<tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
	<hpa@...or.com>
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ