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
| ||
|
Date: Mon, 20 Dec 2010 21:56:00 +0100 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Tejun Heo <tj@...nel.org> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Kernel Testers List <kernel-testers@...r.kernel.org>, Maciej Rutecki <maciej.rutecki@...il.com>, Florian Mickler <florian@...kler.org>, Ozan Caglayan <ozan@...dus.org.tr> Subject: Re: [Bug #20232] kworker consumes ~100% CPU on HP Elitebook 8540w running 2.6.36_rc6-git4 On Monday, December 20, 2010, Tejun Heo wrote: > Hello, > > On 12/20/2010 11:35 AM, Peter Zijlstra wrote: > > On Sun, 2010-12-19 at 13:50 +0100, Rafael J. Wysocki wrote: > >> This message has been generated automatically as a part of a report > >> of regressions introduced between 2.6.35 and 2.6.36. > >> > >> The following bug entry is on the current list of known regressions > >> introduced between 2.6.35 and 2.6.36. Please verify if it still should > >> be listed and let the tracking team know (either way). > >> > >> > >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20232 > >> Subject : kworker consumes ~100% CPU on HP Elitebook 8540w running 2.6.36_rc6-git4 > >> Submitter : Ozan Caglayan <ozan@...dus.org.tr> > >> Date : 2010-10-13 06:13 (68 days old) > > > > I'd be thinking that kworker going wonky is something for Tejun to have > > a look at.. Anyway, is it still relevant for current kernels? > > It looks like the work is scheduled in loop, so the kworker acting out > seems to be the symptom of the problem not the cause. Looks like > Rafael already has a proper fix on mind, so... Rather, something that _might_ work. I'm quite confident that this is a BIOS issue. Apparently, the BIOS tells us we can control PCI Express hotplug, but then it tries to do that itself via ACPI at the same time and that leads to a GPE storm. We may try to poke the BIOS a bit differently than we do right now, but whether or not it helps is to be seen. Also, we can try to handle both ACPI-based and native PCIe hotplug simultaneously at the same port, but that's going to be tricky. We still can use DMI-based blacklisting as the last resort. Thanks, Rafael -- 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