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