HP LH3000r hangs on boot with ACPI enabled
Nate Lawson
nate at root.org
Wed Feb 21 21:38:21 UTC 2007
2005/10/21. We've been having problems keeping our acpi-ca up-to-date
due to the misc API changes (especially re: locking) and crashes on some
systems introduced in later versions.
I appreciate the work you're doing, but some of the changes have been
too Linux-specific, and I haven't had time to track down the exact
behavior we can accept. For instance, Linux spinlocks imply IRQL
raised, but we have a separate critical section primitive on FreeBSD.
I'm trying to find the last stable version to import it, but it may take
a while.
-Nate
Moore, Robert wrote:
> What version of ACPICA is running?
>
> Here, on the latest ACPICA, we see this:
>
> ACPI Error (exresop-0780): Needed
> Integer/Buffer/String/Package/Ref/Ddb], found [Device] 0045BA18
> [20070206]
> ACPI Exception (dswexec-0571): AE_AML_OPERAND_TYPE, While resolving
> operands for [Store] [20070206]
> **** AcpiExec: Exception AE_AML_OPERAND_TYPE during execution of method
> [INIT] Opcode [Store] @54
>
> **** Exception AE_AML_OPERAND_TYPE during execution of method
> [\_SB_.PCI0.INIT] (Node 004546D8)
>
> Method Execution Stack:
> Method [INIT] executing: [INIT] @0003D #0070: Store (-Return Value-
> (), -Return Value- ())
>
>
> Local Variables for method [INIT]:
> Local0: 0047C7F8 <Obj> Integer 0000000000000003
> Local1: 0047A648 <Obj> Integer 0000000000000002
> Local2: 00479B88 <Obj> Integer 0000000000000000
> Local3: 0047B868 <Obj> Integer 0000000000000004
> Local4: 00000000 <Null Object>
> Local5: 00000000 <Null Object>
> Local6: 00000000 <Null Object>
> Local7: 00000000 <Null Object>
>
> Arguments for Method [INIT]: (0 arguments defined, max concurrency = 0)
> Arg0: 0047C578 <Obj> Integer 0000000001020304
> Arg1: 0047B118 <Obj> String(12) "AML Debugger"
> Arg2: 00000000 <Null Object>
> Arg3: 00000000 <Null Object>
> Arg4: 00000000 <Null Object>
> Arg5: 00000000 <Null Object>
> Arg6: 00000000 <Null Object>
>
> ACPI Error (psparse-0638): Method parse/execution failed
> [\_SB_.PCI0.INIT] (Node 004546D8), AE_AML_OPERAND_TYPE
> Execution of \_SB_.PCI0.INIT failed with status AE_AML_OPERAND_TYPE
>
>> -----Original Message-----
>> From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
>> acpi at freebsd.org] On Behalf Of Moore, Robert
>> Sent: Tuesday, February 20, 2007 3:52 PM
>> To: John Baldwin; Stephen Hurd
>> Cc: freebsd-acpi at freebsd.org
>> Subject: RE: HP LH3000r hangs on boot with ACPI enabled
>>
>> We have seen things like this when the BIOS incorrectly fusses with
> the
>> raw AML.
>>
>> Please post the acpidump for this machine.
>>
>>
>>> -----Original Message-----
>>> From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
>>> acpi at freebsd.org] On Behalf Of John Baldwin
>>> Sent: Tuesday, February 20, 2007 9:27 AM
>>> To: Stephen Hurd
>>> Cc: freebsd-acpi at freebsd.org
>>> Subject: Re: HP LH3000r hangs on boot with ACPI enabled
>>>
>>> On Monday 19 February 2007 16:04, Stephen Hurd wrote:
>>>> John Baldwin wrote:
>>>>> On Friday 16 February 2007 02:14, Stephen Hurd wrote:
>>>>>
>>>>>> System does not complete the boot (hang) with ACPI enabled
> using
>>> FreeBSD
>>>>>> 6.2-RELEASE
>>>>>>
>>>>> I would look for a BIOS update.
>>>> Yeah, that was the first thing I did... BIOS is newest available.
>>>>
>>>>> First of all this message is worrying:
>>>>>
>>>>>
>>>>>> ACPI-0347: *** Error: During resolve, Unknown Reference
>> opcode 2D
>>>>>> (AE_NOT_CONFIGURED) in 0xc3c5d600
>>>>>> ACPI-1304: *** Error: Method execution failed
>>> [\_SB_.PCI0.ISA_.LINK]
>>>>>> (Node 0xc3bcdbc0), AE_AML_INTERNAL
>>>>>> ACPI-1304: *** Error: Method execution failed
>> [\_SB_.PCI0.INIT]
>>>>>> (Node 0xc3b78480), AE_AML_INTERNAL
>>>>>> ACPI-1304: *** Error: Method execution failed
>> [\_SB_.PCI0._INI]
>>>>>> (Node 0xc3b78500), AE_AML_INTERNAL
>>>>>>
>>>>> This means it wasn't able to finish the init method for the PCI
>> bus.
>>>>> Secondly, if you compare the IRQs for the two dmesg's (which you
>> can
>>> in
>>>>> this case), you will see that ACPI uses different (and in
> theory,
>>> wrong)
>>>>> IRQs for the sym0, sym1, and ahc0 devices, and the last one is
>> causing
>>>>> your hang I think.
>>>>>
>>>> Yeah. To me it seems to imply that support for the 0x2D opcode is
>>>> missing from FreeBSD... when I recompile the aml (I get a _WAK
>> returns
>>>> no value warning) and use that, the error is still the same. To
> me,
>>>> that implies that the compiler supports it, but the AML
> interpreter
>>>> doesn't (of course, I know zip about AML, ASL, and ACPI, so my
>> opinion
>>>> is worthless.)
>>> The interpreter we have is the ACPI-CA one from Intel that Linux
> uses.
>>> Supporting the opcode isn't going to magically fix the flat-wrong
>> Global
>>> System Interrupt numbers in the _PRT tables though. :)
>>>
>>> --
>>> John Baldwin
More information about the freebsd-acpi
mailing list