HP nc8000 Laptop ACPI Issues

Brian McDonald brianmcd at columbus.rr.com
Wed Sep 1 19:59:48 PDT 2004


On Wednesday 01 September 2004 03:28 pm, Moore, Robert wrote:
> Perhaps the acquisition of C0E9 failed for some reason. It would be
> interesting to see a trace of the execution of the method
> [\_SB_.C135._PSR].

I ran acpidb on the aml from the BIOS, and it ran through the method using 
Debug.  It failed to lock the both mutexes (Acquire returned 0 - False).  
I did some reading on ACPI, and hacked up my DSDT to add in some debugging 
output to the running system.  Basically, I wrapped all of the calls to 
Acquire in some debugging Stores:

-- being snippet --
Store (Acquire (C126, 0xFFFF), Local1)
Store ("C128 Acquire C126:", Debug)
Store (Local1, Debug)
-- end --

I then enabled all the ACPI debug goo, and got additional information during 
the boot:

[ACPI Debug] String: Length 0x12, "C128 Acquire C126:"
[ACPI Debug] Integer: 0x       0       0
[ACPI Debug] String: Length 0x12, "C128 Acquire C0E9:"
[ACPI Debug] Integer: 0x       0       0

So, both Acquire calls in Method C128 failed on the real hardware, too.  
Digging around in the ACPI docs indicates that Device C135 is the ACline 
device (based on the presence of the _PSR method).  If I disable acad via 
debug.acpi.disabled, the messages do go away.  However, acpi_acad0 seems to 
work fine normally - I get messages in the console when I unplug and plug in 
the laptop (including the debugging ones).  I added another Debug to spit out 
C128s return value, and it reads right (0 when I unplug it, and 1 when I plug 
it back in.)

So - can this really be keeping the system from powering down?  Seems like 
although it isn't properly locking Mutexes, the method _is_ working.

Next steps?

Brian
-- 
Brian McDonald, CCNA
Klein bottle for sale.  Inquire within.


More information about the freebsd-acpi mailing list