From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 21 23:22:41 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7FB116A417; Fri, 21 Dec 2007 23:22:41 +0000 (UTC) (envelope-from nick.hale@gmail.com) Received: from mtai05.charter.net (mtai05.charter.net [209.225.8.185]) by mx1.freebsd.org (Postfix) with ESMTP id 29D6013C4D9; Fri, 21 Dec 2007 23:22:40 +0000 (UTC) (envelope-from nick.hale@gmail.com) Received: from aarprv04.charter.net ([10.20.200.74]) by mtai05.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20071221232240.VZJV12551.mtai05.charter.net@aarprv04.charter.net>; Fri, 21 Dec 2007 18:22:40 -0500 Received: from [127.0.0.1] (really [71.90.167.68]) by aarprv04.charter.net with ESMTP id <20071221232240.UHRP17353.aarprv04.charter.net@[127.0.0.1]>; Fri, 21 Dec 2007 18:22:40 -0500 Message-ID: <476C4ABE.9060304@gmail.com> Date: Fri, 21 Dec 2007 17:22:38 -0600 From: Nick Hale User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: John Baldwin References: <476B1654.9060007@gmail.com> <200712211055.59463.jhb@freebsd.org> In-Reply-To: <200712211055.59463.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Chzlrs: 0 Cc: freebsd-acpi@freebsd.org Subject: Re: Shuttle SD37P2 V2 ACPI - FreeBSD 5.5-REL-p7 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: Fri, 21 Dec 2007 23:22:41 -0000 This has been performed and seems to have fixed the issue. The new .asl has been uploaded to replace the old one (in case anyone cares to take a quick peak...) but the box will now boot into ACPI mode without lockup. Thanks! Regards, Nick John Baldwin wrote: > On Thursday 20 December 2007 08:26:44 pm Nick Hale wrote: >> I have a Shuttle SD37P2 V2 system sitting here (runs the Intel 975 express > chipset) and >> when trying to boot to FreeBSD 5.5-REL-p4 through -p7 (unknown if it did it > before p4) I >> have to force it to boot with ACPI disabled else it locks immediately after > detecting the >> primary HDD in the system. Due to the fact that it locks up, I'm unable to > send the dmesg >> output from a working ACPI boot. I can, however, give you everything else > on the list. >> The acpidump -dt output can be found here: >> >> http://www.n0rse.com/nick/harm-falcon.asl >> >> >> sysctl hw.acpi is an unknown oid currently on the system. >> >> dmesg ouput can be found here: >> >> http://www.n0rse.com/nick/harm-falcon.dmesg >> >> I've tried updating and rebuilding just to make sure I have a build that was > generated on >> this box, but no luck. I've let the machine sit for approximately 48 hours > to see if it >> was just a delay in detecting anything but this also proved to not be the > case. It is >> still locked at the same spot and I had to hard reboot and force ACPI to be > disabled. >> This is a non-production box so I am willing to try patches and such on it > so long as I >> don't have to reinstall (ie: I can at least boot to an old kernel or to a > different kernel >> and try again). >> >> As I said, the system is a Shuttle SD37P2v2 barebones running on an Intel > 955D (3.46 >> Extreme Edition) processor with 1GB of DDR2 memory with a 40G IDE drive > sitting in it. I >> *can* mirror the 40G partition to a SATA drive and boot that, but so far it > has yet to >> actually fix anything. Any advice or guidance is more than welcome and I am > willing to >> attempt to track this down. Please include me in the reply as I am not > currently >> subscribed to any of the FreeBSD mailing lists (this one included). >> >> Thank you! >> >> Regards, >> Nick Hale >> nick.hale@gmail.com > > You would need to capture the dmesg (via serial console if the box has a COM > port perhaps) from the ACPI boot to track this down. I would try using 6.x > though as it is may be a PCI interrupt issue and a lot of that code has > changed in 6.x and will not be backported to 5.x (too disruptive). >