Bruno Ducrot writes: | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote: | > In response to Bruno Ducrot <[EMAIL PROTECTED]>: | > > Hi, | > > | > > On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: | > > > | > > > A reboot causes the OS to halt, but the hardware just sits there on the | > > > shutdown screen. | > > > | > > > A shutdown -p does the same. | > > | > > What exactly are the last few lines? | > | > (manually copied) | > | > ... | > All buffers synced. | > Uptime: 1m16s | > | | Thanks. Then this happen after print_uptime(). | | I believe one of the drivers register a shutdown_final (or | shutdown_post_sync) event that hang your system. I think (though I | may be wrong) mfi may be that one. | | It would help if you can add some printf in dev/mfi/mfi.c into the | mfi_shutdown() function in order to check if that assumption | is correct.
Some what related to this we have a local hack: --- sys/kern/subr_bus.c.orig Tue Jun 27 15:49:39 2006 +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006 @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev) device_t child; TAILQ_FOREACH(child, &dev->children, link) { + DELAY(1000); device_shutdown(child); } Seems like we were tearing things done to fast and resources stolen away from HW that was totally shutdown yet or something. I think this was worse when things had shared interrupts but I forget the exact details. It's been a lot time when I put in the hack and moved onto the next fire. It seems the more HW we had in the machine the worse the problem was. This is just a hack and not a fix. Doug A. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"