commit 64b3db22c04586997ab4be46dd5a5b99f8a2d390 (2.6.39),
"Remove use of unreliable FADT revision field" caused a regression
for old P4 systems because now cst_control and other fields are
not reset to 0.
The effect is that acpi_processor_power_init will notice
cst_control != 0 and a write to CST_CNT register is performed
that should not happen. As result, the system oopses after the
"No _CST, giving up" message, sometimes in acpi_ns_internalize_name,
sometimes in acpi_ns_get_type, usually at random places. May be
during migration to CPU 1 in acpi_processor_get_throttling.
Every one of these settings help to avoid this problem:
- acpi=off
- processor.nocst=1
- maxcpus=1
Oneiric SRU Justification:
Impact:
commit 64b3db22c045869 97ab4be46dd5a5b 99f8a2d390 (2.6.39),
"Remove use of unreliable FADT revision field" caused a regression
for old P4 systems because now cst_control and other fields are
not reset to 0.
The effect is that acpi_processor_ power_init will notice internalize_ name, get_throttling.
cst_control != 0 and a write to CST_CNT register is performed
that should not happen. As result, the system oopses after the
"No _CST, giving up" message, sometimes in acpi_ns_
sometimes in acpi_ns_get_type, usually at random places. May be
during migration to CPU 1 in acpi_processor_
Every one of these settings help to avoid this problem:
- acpi=off
- processor.nocst=1
- maxcpus=1
Fix:
Apply upstream commit 3e80acd1af40fcd 91a200b0416a761 6b20c5d647
Testcase:
Without the fix, machines are effectively unbootable unless acpi=off or processor.nocst=1 or maxcpus=1 is used. With the fix the system will boot.