From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 21 16:28:09 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 DFC4016A417 for ; Fri, 21 Dec 2007 16:28:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 78CCF13C4D5 for ; Fri, 21 Dec 2007 16:28:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 225439766-1834499 for multiple; Fri, 21 Dec 2007 11:26:10 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBLGRtbY087500; Fri, 21 Dec 2007 11:27:56 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 21 Dec 2007 10:55:58 -0500 User-Agent: KMail/1.9.6 References: <476B1654.9060007@gmail.com> In-Reply-To: <476B1654.9060007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712211055.59463.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 21 Dec 2007 11:27:56 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5204/Fri Dec 21 10:21:31 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Nick Hale 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 16:28:10 -0000 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). -- John Baldwin