Date: Wed, 21 Feb 2007 21:20:00 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Cc: John Baldwin <jhb@FreeBSD.org>, "Moore, Robert" <robert.moore@intel.com>, "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: <200702212120.02392.jkim@FreeBSD.org> In-Reply-To: <45DCEB12.2020107@root.org> References: <B28E9812BAF6E2498B7EC5C427F293A401F0C7CD@orsmsx415.amr.corp.intel.com> <200702211745.15043.jhb@freebsd.org> <45DCEB12.2020107@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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... > We didn't MFC 20051021 due to a memory leak on some systems (bad > refcount). That was fixed a few revisions later, but I remember a > few 2006 versions having other problems (hanging on boot) and then > I ran out of time to review/debug the patches. > > Hopefully 20070126 is good and we can commit it quickly, then MFC > after a month. Yup, I am not very happy with keeping my own patchsets forever. :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702212120.02392.jkim>