http://bugzilla.kernel.org/show_bug.cgi?id=8346
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Owner|[EMAIL PROTECTED]|[EMAIL PROTECTED]
|m |
Status|NEW |ASSIGNED
Component|Power-Processor |BIOS
Summary|Crashes + hangs during |boot crash + hangduring
|modprobe processor unless |modprobe processor unless
|"processor.nocst" |"processor.nocst" - P4/HT
------- Additional Comments From [EMAIL PROTECTED] 2007-04-25 20:12 -------
This system has a revision 2 FADT,
but it is populating FADT.CST_CONTROL.
However, the FADT.CST_CONTROL field was RESERVED until
FADT revision 3 and ACPI 2.0 -- so a non-zero value
here is technically a BIOS bug.
Linux is believing the BIOS that it should send these
bits to the SMI_COMMAND register in order to tell
the BIOS that Linux knows how to handle a _CST.
As this system doesn't have a CST, it is technically
a 2nd BIOS bug that this field is populated -- even
if the BIOS were up to date with ACPI 2.0.
Which brings us to the actual (intermittant) failure.
We've had problems in the past with tickling SMM
from a thread other than CPU0. My guess is that
on some boots, we are writing this value from cpu1
and that confuses SMM. It is likely that booting
with HT disabled in the BIOS or with "maxcpus=1"
or a UP kernel will make the failure go away.
(give it a try)
But why did 2.6.20 work and 2.6.21-rc7 fails?
It turns out that for FADT revisions before r3,
2.6.20 would explicitly clear this field when
converting the BIOS supplied FADT into the
Linux' in-memory ACPI 2.0 format.
Upon the table-re-write in 2.6.21, we simply bcopy
the entire BIOS supplied FADT into a buffer, preserving
this field, and exposing this series of BIOS bugs.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
