Date: Wed, 21 Feb 2007 17:45:13 -0500 From: John Baldwin <jhb@freebsd.org> To: "Moore, Robert" <robert.moore@intel.com> Cc: freebsd-acpi@freebsd.org, "Suietov, Fiodor F" <fiodor.f.suietov@intel.com>, Stephen Hurd <shurd@sasktel.net>, Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>, "Podrezov, Valery A" <valery.a.podrezov@intel.com> Subject: Re: HP LH3000r hangs on boot with ACPI enabled Message-ID: <200702211745.15043.jhb@freebsd.org> In-Reply-To: <B28E9812BAF6E2498B7EC5C427F293A401F0C7CD@orsmsx415.amr.corp.intel.com> References: <B28E9812BAF6E2498B7EC5C427F293A401F0C7CD@orsmsx415.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 21 February 2007 16:47, Moore, Robert wrote: > Nate, > > We have tried to keep ACPICA as OS-independent as possible. In the case > of spinlocks, you can easily implement the interfaces with whatever is > appropriate (or available) for your OS. > > We felt that we needed to split the mutex interfaces into > mutex/spinlocks for those hosts that have these different types of > synchronization mechanisms. > > Certainly, I would suggest that you keep up-to-date with the latest > ACPICA as we continue to develop and debug the code. Since the ACPI interrupt is run in an ithread, you can probably just ignore the IRQL stuff as garbage and use a regular mutex Nate. Also, this bug report was from 6.2, so it was actually from an older version of ACPICA. Can't recall what is holding up the MFC of 20051021 to 6.x. > Bob > > > > > -----Original Message----- > > From: Nate Lawson [mailto:nate@root.org] > > Sent: Wednesday, February 21, 2007 1:15 PM > > To: Moore, Robert > > Cc: John Baldwin; Stephen Hurd; freebsd-acpi@freebsd.org > > Subject: Re: HP LH3000r hangs on boot with ACPI enabled > > > > 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@freebsd.org [mailto:owner-freebsd- > > >> acpi@freebsd.org] On Behalf Of Moore, Robert > > >> Sent: Tuesday, February 20, 2007 3:52 PM > > >> To: John Baldwin; Stephen Hurd > > >> Cc: freebsd-acpi@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@freebsd.org [mailto:owner-freebsd- > > >>> acpi@freebsd.org] On Behalf Of John Baldwin > > >>> Sent: Tuesday, February 20, 2007 9:27 AM > > >>> To: Stephen Hurd > > >>> Cc: freebsd-acpi@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 > -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702211745.15043.jhb>