HP LH3000r hangs on boot with ACPI enabled

[Jung-uk Kim]

On Thursday 22 February 2007 10:56 am, John Baldwin wrote:
> On Wednesday 21 February 2007 21:20, Jung-uk Kim wrote:
> > On Wednesday 21 February 2007 08:00 pm, Nate Lawson wrote:
> > > John Baldwin wrote:
> > > > 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.
> > >
> > > Yes, I'm hoping we can do that.  Jung-uk Kim is preparing a
> > > patch of 20070126 so hopefully we can test and integrate that.
> >
> > Okay, here is the patch:
> >
> > http://people.freebsd.org/~jkim/acpica-import-20070126.diff.gz
> >
> > I have to warn you that I made this patch very quickly from my
> > local tree, which has lots of unrelated and/or experimental
> > stuff.  In fact, I got it about 90 minutes ago. ;-) So, we have
> > to refine a lot, e.g., locking, task queue, madt, table handling,
> > etc, etc...
>
> Well, I looked at it, and the only comments I have so far is:
>
> 1) The MADT changes have a lot of unrelated gratuitous changes, and
> have also broken MADT support on i386 (hint, you can't use
> AcpiOsMapMemory() as early as the MADT is first probed on i386.  I
> wouldn't have used the madt_map() stuff if it wasn't necessary). 
> I'd prefer to just change the MADT stuff that needs to be changed
> to catch up to the new import and not a whole bunch of other stuff.
>  I can come up with alternative diff's for MADT for the import if
> desired.

Some time ago, we had the same discussion privately, right?  In fact, 
I haven't had chance to revise the patch.  So, yeah, I am aware of 
the issue.  And your help and/or alternative diff's for MADT is 
greatly appreciated.

> 2) In acpi_pci_link.c, the first hunk just adds extra ()'s which
> aren't needed and thus in fact violate style(9) (which discourages
> extra ()'s).

Will do.  But it wasn't just about adding more ()'s.  It was actually 
AcpiGbl_FADT->SciInt => AcpiGbl_FADT.SciInterrupt change. :-)

> The rest looked ok, though most of it covered stuff that isn't in
> my areas of experience.

Thanks!

Jung-uk Kim