Re: [PATCH] ACPI: make acpi_idle Nehalem-aware

From: Iain
Date: Fri Jul 23 2010 - 08:41:02 EST


Len Brown wrote:
You read it correctly, your BIOS does not request BM_STS, mjg59's does.

Right, and on a DL360 G6 with the 07-24-2009 bios version I saw the same.

I expect that is to enable PCC, which would change P-states,
but unlikely would have an effect on C-states.

I found another option in the bios to limit or disable the C-states today, so plenty of opportunity to configure the system into an odd state.

If you can try it both ways that might be good to know.
(include powertop display once again)
Of course, the default setting is what 99% of customers use...

I'll upload an archive to the bugzilla entry with the details. What seems to happen is that when you set the default Balanced Power and Performance mode the CST code vanishes completely and the processor manages to get to c6 some of the time. Enable OS Control mode and the bad CST code appears.

This is BIOS writer "value add".
Unclear how it migh be an improvement over what Linux has been shipping for years.

Well yes, having Linux and the bios fighting for control probably isn't going to help.

Please upload the output from dmidecode to the bug report.
I am hopeful that you have a current BIOS and that
Matthew may have an pre-production BIOS.

I've uploaded an archive with dmidecode, turbostat and powertop dumps. There are dumps with the bios set to the default, and to OS Control mode.
The original bios on my DL360G6 was 07-24-2009 and has the same issue as Matthew. I upgraded the machine to the latest 2010.05.15 and repeated the tests.
Good news is that the new bios has fixed the CST code so that the Access length values are all 0x01 when they're present and the dumps show the processor getting into c6 much more.

So you were correct, bios fix was needed.

Iain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/