Re: Dell 1950 does not properly respond to reboot and shutdown -p



In response to Doug Ambrisko <ambrisko@xxxxxxxxxxxx>:
Bruno Ducrot writes:
| On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| > In response to Bruno Ducrot <ducrot@xxxxxxxxxxxx>:
| > > 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);
}

This patch seems to "fix" the problem. I'm going to replace it with
some printfs and see if I can determine which driver is actually
causing the problem (hopefully it's only one).

Am I wrong in saying that the correct solution would be to identify the
driver that needs more time and implementing some sort of polling
mechanism to ensure the hardware is ready when the driver wants to
shut down?

--
Bill Moran
Collaborative Fusion Inc.
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Dell 1950 does not properly respond to reboot and shutdown -p
    ... |>> Bruno Ducrot writes: ... |>> Some what related to this we have a local hack: ... |> driver that needs more time and implementing some sort of polling ... | remove the DELAY and add a printf and see which device is printed last. ...
    (freebsd-stable)
  • Re: Dell 1950 does not properly respond to reboot and shutdown -p
    ... |> driver that needs more time and implementing some sort of polling ... | remove the DELAY and add a printf and see which device is printed last. ... I'm not sure if his system is Dempsey or Woodcrest. ... printf to a KTR trace and enable just that KTR trace and do 'show ktr' in ...
    (freebsd-stable)
  • Re: Dell 1950 does not properly respond to reboot and shutdown -p
    ... |>> Some what related to this we have a local hack: ... |> driver that needs more time and implementing some sort of polling ... | remove the DELAY and add a printf and see which device is printed last. ... I'm not sure if his system is Dempsey or Woodcrest. ...
    (freebsd-stable)
  • Re: xPC crash
    ... Gordon Weast ... I've used this driver by itself and it worked fine with no ... >>>If it hangs and you see an 's' without an 'e', ... Also, the printf output executes ...
    (comp.soft-sys.matlab)
  • Re: Dell 1950 does not properly respond to reboot and shutdown -p
    ... On Tuesday 10 October 2006 08:54, Bill Moran wrote: ... Am I wrong in saying that the correct solution would be to identify the ... driver that needs more time and implementing some sort of polling ... remove the DELAY and add a printf and see which device is printed last. ...
    (freebsd-stable)