Shuttle SD37P2 V2 ACPI - FreeBSD 5.5-REL-p7

[John Baldwin]

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 at 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