From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 22 17:21:48 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47AAD16A403; Thu, 22 Feb 2007 17:21:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id A873A13C441; Thu, 22 Feb 2007 17:21:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l1MHLj2W087867; Thu, 22 Feb 2007 12:21:46 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Thu, 22 Feb 2007 12:21:42 -0500 User-Agent: KMail/1.6.2 References: <200702212120.02392.jkim@FreeBSD.org> <200702221056.22119.jhb@freebsd.org> In-Reply-To: <200702221056.22119.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200702221221.43946.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2628/Thu Feb 22 06:31:25 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: John Baldwin Subject: Re: HP LH3000r hangs on boot with ACPI enabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 17:21:48 -0000 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