BIOS Regression on HP/Compaq [d]v6000 series notebooks

[Peter Jeremy]

On 2008-May-17 19:43:26 +0800, Ariff Abdullah <ariff at FreeBSD.org> wrote:
>Install sysutils/devcpu from ports, load cpu.ko, and grab / compile
>http://people.freebsd.org/~ariff/misc/k8c1e/ . Try playing with it
>(enable, disable, status)

It reported C1E disabled normally and enabled when I removed power.
Explicitly disabling it when running on battery caused everything to
behave.  Curiously, enabling C1E when running on AC power did not
make things stop - which confused me.

I extended k8c1e.c to report the actual IPMR contents.  This gave
me the following.

Running on AC (ie after plugging AC back in):
cpu0: MSR=0x0000000004c10000 C1E disabled
cpu1: MSR=0x0000000004c10000 C1E disabled

Disconnecting AC:
cpu0: MSR=0x0000000014c11015 C1E enabled
cpu1: MSR=0x000000001cc11015 C1E enabled

I notice that it doesn't set SmiOnCmpHalt on CPU0.  Interestingly,
"BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors"
(#32559) revision 3.08, states that each of C1eOnCmpHalt, SmiOnCmpHalt
and IntPndMsg are mutually exclusive (only one can be set to 1) and
that all cores should be programmed the same - it looks like the BIOS
is not doing this.

I don't know why your patch is not working.  It looks suspiciously
like it's not getting the relevant ACPI notify message (or maybe the
ACPI BIOS is sending the ACPI notify early and juggling C1E after the
notify).  I checked and I _am_ running a kernel with the patch in it.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080518/4d3990e1/attachment.pgp