On 12 Jun 2013, at 6:40 AM, Matthew Garrett wrote: > On Tue, Jun 11, 2013 at 02:30:30PM -0700, Larry Baker wrote: >> I have an IBM System x3650 M3 with an Intel Xeon L5630 processor. My IBM support team alerted me to an issue with C6 states for those processors when running Linux and the intel_idle kernel module is used. The IBM solutions page, http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-5091901, recommends disabling intel_idle. I propose intel_idle disable C6 for the affected processors. > > As you note: > >>> Workaround: >>> It is possible for the BIOS to contain a workaround for this erratum. Not my comment -- this comes from the Intel processor errata. It is not really very clear from this exactly what the BIOS is supposed to do. The IBM BIOS, for example, disables all C states. However, intel_idle ignores the BIOS settings. I did some Google'ing and found HP and Dell documents describing how to configure Linux to reduce latency, which, of course, requires that C states be disabled. http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01804533/c01804533.pdf http://en.community.dell.com/techcenter/extras/m/white_papers/20227764/download.aspx The Dell document explains that the intel_idle driver overrides what the BIOS says and does its own thing. It says the acpi_idle driver gets the ACPI information from the BIOS and does what it says to do: > And, to reiterate—there are a number of kernel parameters and BIOS settings that deal with C-states, but most of these will be ignored if intel_idle is in use. Disabling intel_idle with kernel parameter ―intel_idle.max_cstate=0 will result in more intuitive control of C-states, and there should not be any disadvantage to disabling it on systems that provide correct C-state information to the operating system via ACPI. Maybe disabling intel_idle is the best solution? I don't know. But, if that is so, why does Linux have it at all? I suspect it is because intel_idle can use C states that are Intel processor-specific, while acpi_idle probably sticks to ACPI "standard" C states. > Are you actually seeing this specific problem? On my systems, not that I know of. The processor errata only says this may happen. I only have a few, and I suppose I have been lucky. I am sure that Intel would have caught this prior to shipping the processor if it was a solid failure. My IBM support contact has told me that it has caused grief at his accounts. > If so, you should > probably request a firmware update from IBM. If that's not a > possibility, and if it is necessary to disable package C6 in this > situation, it'd be nice to determine what the BIOS workaround actually > does and limit the quirk to that case. The processor errata is operating system agnostic. I suspect the BIOS workaround they envision would be a feature in the BIOS to limit the choice of C states to be used. The IBM BIOS has such a setting, and the default value is to completely disable C states. However, intel_idle ignores the BIOS setting. I think the intel_idle code came from Intel engineers. I assume they have good reason to prefer it to acpi_idle. I hope they read this list and will decide if my proposals have merit. Thanks. > -- > Matthew Garrett | mjg59@xxxxxxxxxxxxx Larry Baker US Geological Survey 650-329-5608 baker@xxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
