https://bugzilla.kernel.org/show_bug.cgi?id=15886
--- Comment #5 from Len Brown <[email protected]> 2010-07-21 18:13:25 --- Created an attachment (id=27187) --> (https://bugzilla.kernel.org/attachment.cgi?id=27187) patch vs 2.6.35-rc5 Please give this patch a try. You should notice that in /proc/acpi/processor/*/power that the C3 type C-states are now C2-type. As such, BM_STS will not be checked on entry and deep c-states will be used even if the chipset reports BM_STS. --- Comment #6 from Len Brown <[email protected]> 2010-07-22 05:15:30 --- According to "Intel Processor Vendor-Specific ACPI Interface Specification": http://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state This means that Linux should not be checking BM_STS on these states unless this bit is set. However, Linux is always checking BM_STS for C3-type states. The Good news is that according to Philip's acpidump for the failing gigabyte motherboard in the original description above, Gigabyte does not set this bit in _CST.GAS -- only bit 0 is set in access size, which indicates HW coordiation: If (CondRefOf (\_OSI, Local0)) { If (LAnd (\_OSI ("Windows 2001.1"), LAnd (LNot (\_OSI ("Windows 2006")), LNot (\_OSI ( "Windows 2001.1 SP1"))))) { Store (0x00, CSEN) } } If (CSEN) { If (LAnd (MWOS, And (TYPE, 0x0200))) { Return (Package (0x04) { 0x03, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000000, // Address 0x01, // Access Size ) }, 0x01, 0x0001, 0x000003E8 }, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000010, // Address 0x01, // Access Size ) }, 0x02, 0x0040, 0x000001F4 }, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000020, // Address 0x01, // Access Size ) }, 0x03, 0x0060, 0x0000015E } }) The Bad news is that according to the acpidump in comment #3, HP is asking for BM_STS checking on the DL360G6 via access size 3 for C2 and C3: Method (_CST, 0, NotSerialized) { If (CSEN) { If (LAnd (MWOS, And (TYPE, 0x0200))) { Return (Package (0x04) { 0x03, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000000, // Address 0x01, // Access Size ) }, 0x01, 0x0001, 0x000003E8 }, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000010, // Address 0x03, // Access Size ) }, 0x03, 0x0040, 0x000001F4 }, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000020, // Address 0x03, // Access Size ) }, 0x03, 0x0060, 0x0000015E } }) } So if we fix Linux to check this bit, the Gigabyte will be fixed, but the HP appears to be explicitly asking us to check BM_STS. Unclear if that is HP's intention or if it is a BIOS bug. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
