<div dir="ltr">Just to add one more detail to this... From <a href="http://ark.intel.com">ark.intel.com</a>:<div><a href="http://ark.intel.com/products/37006/Intel-Core2-Duo-Processor-P8700-3M-Cache-2_53-GHz-1066-MHz-FSB">http://ark.intel.com/products/37006/Intel-Core2-Duo-Processor-P8700-3M-Cache-2_53-GHz-1066-MHz-FSB</a><br></div><div><br></div><div>Seems that this one (P8700) is variance of Core 1 Penryn, Came to existence Q4/2008, embedded support just ran out of time. The 8Y span is too large to get fixed it from INTEL resources. Back far (Y2008) PM probably was not so versatile, and it runs up to C6 state (my best guess). And One only knows how ACPI tables are implemented in legacy BIOSes for Penryn, and if these were correctly moved/ported to Coreboot.</div><div><br></div><div>My two cent worth (pure rhetorical) opinion. ;-)</div><div><br></div><div>Would be cool (facultative/optional, when opportunity strikes) if anybody does the same (measurements) for BDW-DE and/or HSW BIOSes/FSPs (much more value to newer CORE 4/CORE 5 CPUs).</div><div><br></div><div>Thank you,</div><div>Zoran</div><div>_______</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 1:16 PM, Nico Huber <span dir="ltr"><<a href="mailto:nico.huber@secunet.com" target="_blank">nico.huber@secunet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02.05.2016 01:06, Daniel Kulesz wrote:<br>
>>> - disabling "cpu power management" makes the idle consumption raise to 12,8W<br>
>> Is this 12.8W compared to 7.5W (i.e. with lowest backlight)?<br>
>><br>
><br>
> Nope, I am only comparing with highest backlight now, so it is 12.8W versus 10.0W here.<br>
</span>Hmmm, 2.8W... whatever that option does it confuses me.<br>
<span class=""><br>
>>> Any ideas which could solve this mystery?<br>
>>><br>
>> One more thing you can test, in case your Linux uses the intel_idle<br>
>> driver: There is a kernel parameter intel_idle.max_cstate, if you boot<br>
>> the vendor BIOS with defaults and Linux with intel_idle.max_cstate=2 it<br>
>> should use C1/C2 but not C3/C4 and thus behave more like coreboot.<br>
>><br>
> Okay. I was just aware of the generic "processor.max_cstate=2"<br>
> parameter. I tried with both parameters using the vendor BIOS and here<br>
> are the results:<br>
><br>
> intel_idle.max_cstate=2: 10W in idle at full brightness (no effect)<br>
> processor.max_cstate=2: 12.6W in idle at full brightness<br>
><br>
> So it seems plausible that this issue is related to Coreboot not<br>
> (properly?) supporting C3/C4. So this is a known issue then? If yes,<br>
> imho it should be *definitely* documented on the wiki page since it<br>
> could be a "showstopper" for many adopters who need the maximum battery<br>
> life the X200 is able to deliver only with the vendor BIOS at this point<br>
> in time ...<br>
</span>Well, let's see what we got:<br>
  o 10.0W with "cpu power management"<br>
  o 12.6W with "cpu power management" but max_cstate=2<br>
  o 12.8W without "cpu power management"<br>
FWIW, C2 usually saves more power. So I wonder how good your measuring<br>
at the wall plug works. Another easy option to measure the power<br>
consumption is looking at what the battery reports (usually<br>
/sys/class/power_supply/BAT0/power_now).<br>
<br>
Regarding C3/C4 support, AFAIK, we implemented it fully but it just<br>
didn't work on the system we originally ported coreboot for (Roda/RK9).<br>
The system kept resetting whenever it should enter (or maybe exit) C3,<br>
IIRC.  You could give it a try on your X200 though. Whatever the issue<br>
on the RK9 was, it might be board specific.<br>
<br>
If you want to try it, in src/mainboard/lenovo/x200/cstates.c add:<br>
        {<br>
                /* acpi C3 / cpu C3 */<br>
                3, 0x02,  300,<br>
                { ACPI_ADDRESS_SPACE_FIXED, 1, 2, { 1 }, 0x20, 0 }<br>
        },<br>
for C3 or<br>
        {<br>
                /* acpi C3 / cpu C4 */<br>
                3, 0x02,  300,<br>
                { ACPI_ADDRESS_SPACE_FIXED, 1, 2, { 1 }, 0x30, 0 }<br>
        },<br>
for C4. You can not have all of them, as ACPI only supports three<br>
C-states.<br>
<br>
Nico<br>
<br>
--<br>
M. Sc. Nico Huber<br>
Senior Berater SINA-Softwareentwicklung<br>
Netzwerk- & Client-Sicherheit / Network & Client Security<br>
Division Öffentliche Auftraggeber / Public Authorities<br>
secunet Security Networks AG<br>
<br>
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325<br>
E-Mail: <a href="mailto:nico.huber@secunet.com">nico.huber@secunet.com</a><br>
Mergenthalerallee 77, 65760 Eschborn, Deutschland<br>
<a href="http://www.secunet.com" rel="noreferrer" target="_blank">www.secunet.com</a><br>
______________________________________________________________________<br>
<br>
Sitz: Kurfürstenstraße 58, 45138 Essen, Deutschland<br>
Amtsgericht Essen HRB 13615<br>
Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Pleines<br>
Aufsichtsratsvorsitzender: Dr. Peter Zattler<br>
______________________________________________________________________<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a></div></div></blockquote></div><br></div>