Date: Thu, 22 Feb 2007 10:56:21 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: Jung-uk Kim <jkim@freebsd.org> Subject: Re: HP LH3000r hangs on boot with ACPI enabled Message-ID: <200702221056.22119.jhb@freebsd.org> In-Reply-To: <200702212120.02392.jkim@FreeBSD.org> References: <B28E9812BAF6E2498B7EC5C427F293A401F0C7CD@orsmsx415.amr.corp.intel.com> <45DCEB12.2020107@root.org> <200702212120.02392.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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). The rest looked ok, though most of it covered stuff that isn't in my areas of experience. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702221056.22119.jhb>