On Tue, Apr 28, 2009 at 08:53:48PM +0100, Matthew Garrett wrote: > On Tue, Apr 28, 2009 at 12:33:04PM -0700, Darrick J. Wong wrote: > > On Thu, Apr 16, 2009 at 11:45:07PM +0100, Matthew Garrett wrote: > > > > > That's not really an option. It works with Windows. > > > > Who verified that? Does anyone know what strategy Windows uses to avoid this > > T60 problem? > > The best guess was that Windows only evaluates _PPC when it receives a > notification. Here's the answer from the Windows side of the house: Windows (both WS03 and WS08) will evaluate the _PPC method during boot once the intelppm.sys processor driver loads. The processor driver will "evaluate" the _PPC method: IntelPPM.sys: 0: Entering AcpiEval_PPC IntelPPM.sys: 0: Entering AcpiEvaluateMethod =0x0 AMLI: EvalObject(\_PR.C000._PPC)=Integer(:Value=0x0[0]) The Windows intelppm.sys driver can return non-zero for the _PPC method (in this example, _PPC returns non-zero based on what's stored in \_PTSE and \_TSTE named objects that were updated during POST. The capture is during Windows boot when evaluating the ACPI P-State objects for each ProcessorId object): .... IntelPPM.sys: Processor Performance States (0x85DF7DF0) IntelPPM.sys: Size: 0x210 IntelPPM.sys: Revision: 0x1 IntelPPM.sys: Type: 0xfe IntelPPM.sys: Count: 0xf IntelPPM.sys: MaxFrequency: 2394 mhz IntelPPM.sys: PState Handler: 0x88fb7006 IntelPPM.sys: PState Context: 0x85d74298 IntelPPM.sys: PState Cap: 0x3 <= PTSE (test: hardcoded PTSE to return something other than P[0]) IntelPPM.sys: TState Handler: 0x88fb7048 IntelPPM.sys: TState Context: 0x85d742c0 IntelPPM.sys: TState Cap: 0x4 <= TSTE (test: hardcoded TSTE to return something other than T[0]) IntelPPM.sys: Feedback Handler: 0x88fb7084 IntelPPM.sys: Target Processors: 0xff IntelPPM.sys: IntelPPM.sys: State Speed Power Latency Control Status IntelPPM.sys: ----- ----- ----- ------- ------- ------ IntelPPM.sys: 0: 2394 mhz 106000 mW 10 us 0x12 0x12 // P[0] IntelPPM.sys: 1: 2261 mhz 90000 mW 10 us 0x11 0x11 IntelPPM.sys: 2: 2128 mhz 74000 mW 10 us 0x10 0x10 IntelPPM.sys: 3: 1995 mhz 58000 mW 10 us 0xf 0xf // PTSE IntelPPM.sys: 4: 1862 mhz 42000 mW 10 us 0xe 0xe IntelPPM.sys: 5: 1729 mhz 26000 mW 10 us 0xd 0xd IntelPPM.sys: 6: 1596 mhz 10000 mW 10 us 0xc 0xc IntelPPM.sys: 7: 1596 mhz 10000 mW 0 us 0x2 0x2 IntelPPM.sys: 8: 1404 mhz 8750 mW 0 us 0x1e 0x1e // T[0] IntelPPM.sys: 9: 1197 mhz 7500 mW 0 us 0x1c 0x1c IntelPPM.sys: 10: 1005 mhz 6250 mW 0 us 0x1a 0x1a IntelPPM.sys: 11: 798 mhz 5000 mW 0 us 0x18 0x18 IntelPPM.sys: 12: 606 mhz 3750 mW 0 us 0x16 0x16 // TSTE IntelPPM.sys: 13: 399 mhz 2500 mW 0 us 0x14 0x14 IntelPPM.sys: 14: 207 mhz 1250 mW 0 us 0x12 0x12 IntelPPM.sys: .... 0: kd> !amli dns /s \TSTE ACPI Name Space: \TSTE (ffffffff854e484c) Integer(TSTE:Value=0x0000000000000004[4]) 0: kd> !amli dns /s \PSTE ACPI Name Space: \PSTE (ffffffff854e4898) Integer(PSTE:Value=0x0000000000000003[3]) Note the two above dbg traces are from different systems. (end reply) I don't know about XP's copy of intelppm.sys, but this would seem to confirm that WS03 and WS08 check _PPC at boot time. --D -- 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
