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]
Message-Id: <20100115013957.027452000@intel.com>
Date:	Thu, 14 Jan 2010 17:39:57 -0800
From:	"Venkatesh Pallipadi" <venkatesh.pallipadi@...el.com>
To:	"Ingo Molnar" <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Len Brown" <lenb@...nel.org>, "Mark Hounschell" <markh@...pro.net>
Cc:	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"Alain Knaff" <alain@...ff.lu>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Li, Shaohua" <shaohua.li@...el.com>
Subject: [patch 0/4] Only use HPET MSI timers on systems with deep C-state support

There is a functionality issue reported on some AMD platforms
http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01118.html
wherein, fdformat fails when HPET MSI based percpu timer is used.

We do not have the real root-cause for that problem. But, that
report exposed an issue with our current usage HPET MSI timers.
We use HPET MSI timers even on platforms that do not have
support for C2/C3 states. On those systems we should rather be
using LAPIC timers.

So, this series of patches does just that.
* Use LAPIC timer when there is always running APIC timer
* Use LAPIC timer on platforms that do not have support for deep C states
* Only use HPET MSI timers as percpu timers on systems that have LAPICs
  that stop in deep C-states _and_ system supports deep C-states

The change turned out to be more than what I expected, due to
the current static nature of clockevent rating and unrelated
issues in acpi processor driver resume path. I also ended up
touching different subsystems to handle this.

If the patchset resolves the issue for Mark and if it looks sane
can one of the maintainers queue it up for .34

Reported-by: Mark Hounschell <markh@...pro.net>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>

-- 

--
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