Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
On Tue, 14 Sep 2010 11:44:45 +0300 Andriy Gapon wrote: > Additionally, it seems that we do not currently have any support for > Functional > Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS > of a register used to enter a C state with address space ID set to > ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled > in a > special way: > ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf > > Currently we simply (and silently) ignore such _CST entries. > I think that this should be useful (if not necessary) with mwait. I have a proof-of-concept, quick'n'dirty patch against pre-r212541 to utilize FFH _CST. Unfortunately I have no time to catch up the latest and fantastic work by mav, though. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote: > on 13/09/2010 20:07 Andriy Gapon said the following: >> I am also going to take a look how Linux and OpenSolaris name the C-states. > > Well, Linux does what you suggested, it uses index of a C-state as its name. > There is one difference from our current code - if a C-state is skipped for > some > reason, then its index is not re-used, but the entry is marked as non-valid. > So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on > Linux. > Also, they print a type/class of a C state using C1, C2, C3 and "--" for > higher/unknown types. > > Additionally, it seems that we do not currently have any support for > Functional > Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS > of a register used to enter a C state with address space ID set to > ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled > in a > special way: > ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf > > Currently we simply (and silently) ignore such _CST entries. > I think that this should be useful (if not necessary) with mwait. I added some FFHW support for ACPI P-states. You can see that in the cpufreq code or in the speedstep driver. -- Nate ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote: > on 14/09/2010 11:44 Andriy Gapon said the following: >> on 13/09/2010 20:07 Andriy Gapon said the following: >>> I am also going to take a look how Linux and OpenSolaris name the C-states. >> Well, Linux does what you suggested, it uses index of a C-state as its name. >> There is one difference from our current code - if a C-state is skipped for >> some >> reason, then its index is not re-used, but the entry is marked as non-valid. >> So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on >> Linux. >> Also, they print a type/class of a C state using C1, C2, C3 and "--" for >> higher/unknown types. > > OpenSolaris, on the other hand, collapses multiple entries of the same type > into > a single entry using the most power-saving alternative. I don't think it is perfect choice. In such case it would be useless for ACPI BIOS to report extra states. The only case when I think can be reasonable to drop some items is if they are equal except using different entry methods. For example, one OS may prefer to use port read, while another may use MWAIT to be able to wake up without using IPI. > They also use the type as a C state reported name, index is not used in > interfacing. In their case it is possible. -- Alexander Motin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 14/09/2010 11:44 Andriy Gapon said the following: > on 13/09/2010 20:07 Andriy Gapon said the following: >> I am also going to take a look how Linux and OpenSolaris name the C-states. > > Well, Linux does what you suggested, it uses index of a C-state as its name. > There is one difference from our current code - if a C-state is skipped for > some > reason, then its index is not re-used, but the entry is marked as non-valid. > So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on > Linux. > Also, they print a type/class of a C state using C1, C2, C3 and "--" for > higher/unknown types. OpenSolaris, on the other hand, collapses multiple entries of the same type into a single entry using the most power-saving alternative. They also use the type as a C state reported name, index is not used in interfacing. So, hm, talk about confusing again :) -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 13/09/2010 20:07 Andriy Gapon said the following: > I am also going to take a look how Linux and OpenSolaris name the C-states. Well, Linux does what you suggested, it uses index of a C-state as its name. There is one difference from our current code - if a C-state is skipped for some reason, then its index is not re-used, but the entry is marked as non-valid. So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on Linux. Also, they print a type/class of a C state using C1, C2, C3 and "--" for higher/unknown types. Additionally, it seems that we do not currently have any support for Functional Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS of a register used to enter a C state with address space ID set to ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled in a special way: ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf Currently we simply (and silently) ignore such _CST entries. I think that this should be useful (if not necessary) with mwait. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 19:00 Alexander Motin said the following: > > I am not sure this patch is complete: Well, I agree, it's far from complete. And situation is somewhat messy. > 1) AFAIR I have seen somewhere example where system had several C-states > with different latency, but the same type - C3. Type only means > enter/exit semantics, and there could be several states with the same > semantics. Not sire how to properly them in this case. ACPI specification suggests how to address this, but I am not sure if we want to follow that suggestion and how we would do that: ACPI> Notice in the example above that OSPM should anticipate the possibility of a _CST object providing more ACPI> than one entry with the same C_State_Type value. In this case OSPM must decide which C_State_Register ACPI> it will use to enter that C state. So it looks like the specification does tie C_State_Type to "C state". But then, in general, the specification looks confusing. It mentions C4, ..., Cn states; but then says that their enter/exit semantics should correspond to C1, C2, C3; but then it uses "1, 2, 3, *etc*" [emphasis mine] when it describes C State type. So, at least I am confused as to what they would designate with C4 - a state described in _CST with type of 4, or a forth state in _CST perhaps with a type of 3. And entry/exit semantics the state would have in the former case. I do not see an explicit answer in their wording. > May be existing > approach was not so bad. It is ACPI C-states, not CPU C-states, they are > not same. > May be we should just mention type somewhere in addition. > 2) This change makes heavily understandable values of cx_lowest. > 3) If touch cx_lowest, I would prefer to see there possibility to set it > to some abstract C6 or whatever, allowing system automatically choose > state it has available at the moment. > Yes, I agree. It's just overall confusing. But you are correct that index of a C-state works better than "C-state-type" or whatever it can be called. And a user probably doesn't care much about the latter. But probably it's a good idea to report the type somewhere. I am also going to take a look how Linux and OpenSolaris name the C-states. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote:
> on 12/09/2010 18:22 Andriy Gapon said the following:
>> Observations are correct, but incomplete; the conclusions are wrong.
>> At the end of the boot there are message like this one:
>> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
>> latency
>> This is a result of re-evaluation of _CST because of a notification from
>> ACPI.
>
> But still, as you suggest, a patch like the following should be tested and
> committed:
>
> --- a/sys/dev/acpica/acpi_cpu.c
> +++ b/sys/dev/acpica/acpi_cpu.c
> @@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
> sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported),
> SBUF_FIXEDLEN);
> for (i = 0; i < sc->cpu_cx_count; i++) {
> - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat);
> + sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
> + sc->cpu_cx_states[i].trans_lat);
> if (sc->cpu_cx_states[i].type < ACPI_STATE_C3)
> sc->cpu_non_c3 = i;
> }
I am not sure this patch is complete:
1) AFAIR I have seen somewhere example where system had several C-states
with different latency, but the same type - C3. Type only means
enter/exit semantics, and there could be several states with the same
semantics. Not sire how to properly them in this case. May be existing
approach was not so bad. It is ACPI C-states, not CPU C-states, they are
not same. May be we should just mention type somewhere in addition.
2) This change makes heavily understandable values of cx_lowest.
3) If touch cx_lowest, I would prefer to see there possibility to set it
to some abstract C6 or whatever, allowing system automatically choose
state it has available at the moment.
--
Alexander Motin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi avg. On Sun, 12 Sep 2010 18:38:58 +0300 Andriy Gapon wrote: > > Observations are correct, but incomplete; the conclusions are wrong. > > At the end of the boot there are message like this one: > > PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245 > > latency > > This is a result of re-evaluation of _CST because of a notification from > > ACPI. > But still, as you suggest, a patch like the following should be tested and > committed: Thank you, I'll test your patch. But I'm rebuilding another patches. So please wait next day. -- Norikatsu Shigemura ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 18:22 Andriy Gapon said the following:
> Observations are correct, but incomplete; the conclusions are wrong.
> At the end of the boot there are message like this one:
> PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
> latency
> This is a result of re-evaluation of _CST because of a notification from ACPI.
>
But still, as you suggest, a patch like the following should be tested and
committed:
--- a/sys/dev/acpica/acpi_cpu.c
+++ b/sys/dev/acpica/acpi_cpu.c
@@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported),
SBUF_FIXEDLEN);
for (i = 0; i < sc->cpu_cx_count; i++) {
- sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat);
+ sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
+ sc->cpu_cx_states[i].trans_lat);
if (sc->cpu_cx_states[i].type < ACPI_STATE_C3)
sc->cpu_non_c3 = i;
}
P.S. I restored acpi@ cc: which I think is quite relevant, but was somehow lost.
--
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 12/09/2010 02:14 Norikatsu Shigemura said the following:
> According to acpidump -dt, I could find CPU0CST table, but
> not found _CST.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Scope (\)
> {
> Name (SSDT, Package (0x0C)
> {
> :
> "CPU0CST ",
> 0xDA9AB618,
> 0x05CD,
> :
> })
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
>
> Hum... ACPI CA 20100806 has a bug?
How do you conclude? Does a different version work?
It seems that our acpidump doesn't dump a dynamically loaded table.
That the table was loaded we can see from these messages:
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
--
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 11/09/2010 21:30 Nate Lawson said the following: > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. >From reading of the code, C3 should be used in this case even if C2 is not available. But I think that it might get removed for a different reason: PM2_CNT_BLK length seems to be zero. With ACPI_DB_INFO enabled there should be "no BM control" message in the log. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
on 11/09/2010 21:30 Nate Lawson said the following: >> PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6 >> PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not >> available. >> PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 >> latency > > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. > The "not available" message means that transition latency is defined too high. That is, in this case latency is greater than 100 for C2. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
On Sun, 12 Sep 2010 08:14:09 +0900
Norikatsu Shigemura wrote:
> According to acpidump -dt, I could find CPU0CST table, but
> not found _CST.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Scope (\)
> {
> Name (SSDT, Package (0x0C)
> {
> :
> "CPU0CST ",
> 0xDA9AB618,
> 0x05CD,
> :
> })
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Hum... ACPI CA 20100806 has a bug?
Humm... I wonder if CF-R9 required another initialization?
I don't know what is HI0 and HC0. But default values of HI0 and
HC0 is 0, and HI0 and HC0 are set CST related values by GCAP,
I think..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Scope (\_PR.CPU0)
{
Name (HI0, Zero)
Name (HC0, Zero)
:
Method (GCAP, 1, NotSerialized)
{
CreateDWordField (Arg0, Zero, STS0)
CreateDWordField (Arg0, 0x04, CAP0)
If (LOr (LEqual (STS0, 0x06), LEqual (STS0, 0x0A)))
{
Return (Zero)
}
If (And (STS0, One))
{
And (CAP0, 0x0BFF, CAP0)
Return (Zero)
}
Or (And (PDC0, 0x7FFF), CAP0, PDC0)
If (And (CFGD, One))
{
If (LAnd (LAnd (And (CFGD, 0x0100), LEqual (And (PDC0,
0x09), 0x09)), LNot (And (SDTL, One
{
Or (SDTL, One, SDTL)
OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT,
One)), DerefOf (Index (SSDT, 0x02
)))
Load (IST0, HI0)
}
}
If (And (CFGD, 0xF0))
{
If (LAnd (LAnd (And (CFGD, 0x0100), And (PDC0, 0x18
)), LNot (And (SDTL, 0x02
{
Or (SDTL, 0x02, SDTL)
OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT,
0x07)), DerefOf (Index (SSDT, 0x08
)))
Load (CST0, HC0)
}
}
Return (Zero)
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Thank you.
--
Norikatsu Shigemura
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi nate.
On Sat, 11 Sep 2010 11:30:29 -0700
Nate Lawson wrote:
> I think the issue is that C2 is not available for some reason and thus
> C3 can't be used either. The way to tell is to use acpidump and look for
> the CPU objects' _CST fields.
I attached acpidump -dt (nork-CFR9.asl.bz2) on previous mail, and
I couldn't find _CST, too.
And I added more ACPI debug option, ACPI_DB_INFO. I got following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
cpu0: on acpi0
PROCESSOR-0311 [230584] cpu_attach: acpi_cpu0: P_BLK at 0x410/6
ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109)
ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
PROCESSOR-0696 [241753] cpu_cx_cst: acpi_cpu0: C2[1] not available.
PROCESSOR-0730 [241753] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency
cpu1: on acpi0
PROCESSOR-0311 [241991] cpu_attach: acpi_cpu1: P_BLK at 0x410/6
ACPI: SSDT 0xda9aca98 00303 (v01 PmRefApIst 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00303 (v01 PmRefApIst 3000 INTL 20061109)
ACPI: SSDT 0xda9aad98 00119 (v01 PmRefApCst 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00119 (v01 PmRefApCst 3000 INTL 20061109)
PROCESSOR-0696 [254000] cpu_cx_cst: acpi_cpu1: C2[1] not available.
PROCESSOR-0730 [254000] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency
cpu2: on acpi0
PROCESSOR-0311 [254238] cpu_attach: acpi_cpu2: P_BLK at 0x410/6
PROCESSOR-0696 [255657] cpu_cx_cst: acpi_cpu2: C2[1] not available.
PROCESSOR-0730 [255657] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency
cpu3: on acpi0
PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6
PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not available.
PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
According to acpidump -dt, I could find CPU0CST table, but
not found _CST.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Scope (\)
{
Name (SSDT, Package (0x0C)
{
:
"CPU0CST ",
0xDA9AB618,
0x05CD,
:
})
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Hum... ACPI CA 20100806 has a bug?
Thank you.
--
Norikatsu Shigemura
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Norikatsu Shigemura wrote: > Hi ACPI specialists! > > I noticed that CPU cooling doesn't work with testing mav@'s > timers_oneshot*.patch, so I got following results: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% last 24us > dev.cpu.1.cx_supported: C1/3 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% last 485us > dev.cpu.2.cx_supported: C1/3 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% last 155us > dev.cpu.3.cx_supported: C1/3 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% last 590us I think the problem is here. > cpu0: on acpi0 > PROCESSOR-0311 [230584] cpu_attach: acpi_cpu0: P_BLK at 0x410/6 > ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109) > ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109) > PROCESSOR-0696 [241753] cpu_cx_cst: acpi_cpu0: C2[1] not > available. > PROCESSOR-0730 [241753] cpu_cx_cst: acpi_cpu0: Got C3 - 245 > latency > cpu1: on acpi0 > PROCESSOR-0311 [241991] cpu_attach: acpi_cpu1: P_BLK at 0x410/6 > ACPI: SSDT 0xda9aca98 00303 (v01 PmRefApIst 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00303 (v01 PmRefApIst 3000 INTL 20061109) > ACPI: SSDT 0xda9aad98 00119 (v01 PmRefApCst 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00119 (v01 PmRefApCst 3000 INTL 20061109) > PROCESSOR-0696 [254000] cpu_cx_cst: acpi_cpu1: C2[1] not > available. > PROCESSOR-0730 [254000] cpu_cx_cst: acpi_cpu1: Got C3 - 245 > latency > cpu2: on acpi0 > PROCESSOR-0311 [254238] cpu_attach: acpi_cpu2: P_BLK at 0x410/6 > PROCESSOR-0696 [255657] cpu_cx_cst: acpi_cpu2: C2[1] not > available. > PROCESSOR-0730 [255657] cpu_cx_cst: acpi_cpu2: Got C3 - 245 > latency > cpu3: on acpi0 > PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6 > PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not > available. > PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 > latency I think the issue is that C2 is not available for some reason and thus C3 can't be used either. The way to tell is to use acpidump and look for the CPU objects' _CST fields. -- Nate ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
