Dell 1950 does not properly respond to reboot and shutdown -p
Doug Ambrisko
ambrisko at ambrisko.com
Thu Oct 5 05:17:00 UTC 2006
Bruno Ducrot writes:
| On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| > In response to Bruno Ducrot <ducrot at poupinou.org>:
| > > 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.
More information about the freebsd-stable
mailing list