http://bugzilla.kernel.org/show_bug.cgi?id=12788
--- Comment #44 from Thomas Renninger <tr...@suse.de> 2009-12-07 11:58:55 --- Quick summary: If you use idle=nomwait the irq activity drops from 40000 to 800 which you say is high, but this looks pretty normal if you still have some things running. So the root cause for the IRQ storm seem to be C-states triggered through mwait. You should also look out for BIOS updates from time to time... Can you add "idle=nomwait helps" to the title (I searched but couldn't find how to do that -> no permission?). As this only happens after a suspend/resume, I expect we or the BIOS forgot to re-program a chip properly or do something wrongly (or this is a bug in the CPU itself). Possibly this is APIC related and I had a look at the the suspend/resume code there. What I wonder is: Why is the code there only executed on one CPU while there is one local APIC per CPU, it even seem to be luck on which CPU the code gets executed (or it's ensured to be run on CPU0, because other CPUs are offlined at that time, not sure). Could you try out attached patch, please. Please give it two test runs, always with apic=verbose boot param added (and without passing idle=nomwait): - with default/normal params - additionally with disable_apic_suspend_hooks boot param Is the IRQ storm gone after resume with one of above tries? Thanks. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
