Date: Thu, 22 Feb 2007 12:21:42 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: HP LH3000r hangs on boot with ACPI enabled Message-ID: <200702221221.43946.jkim@FreeBSD.org> In-Reply-To: <200702221056.22119.jhb@freebsd.org> References: <B28E9812BAF6E2498B7EC5C427F293A401F0C7CD@orsmsx415.amr.corp.intel.com> <200702212120.02392.jkim@FreeBSD.org> <200702221056.22119.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702221221.43946.jkim>