On Mon, Apr 25, 2011 at 12:33:20PM -0500, David Young wrote: > On Mon, Apr 25, 2011 at 06:26:09PM +0200, Juergen Hannken-Illjes wrote: > > On Mon, Apr 25, 2011 at 10:33:14AM -0500, David Young wrote: > > > On Mon, Apr 25, 2011 at 02:14:23PM +0000, Juergen Hannken-Illjes wrote: > > > > Module Name: src > > > > Committed By: hannken > > > > Date: Mon Apr 25 14:14:22 UTC 2011 > > > > > > > > Modified Files: > > > > src/sys/dev/scsipi: scsiconf.c > > > > > > > > Log Message: > > > > Don't kill outstanding requests when detaching a scsibus on shutdown. > > > > Both the controller and tyhe targets are still running. > > > > > > I don't think you have fixed the actual bug. It sounds like the > > > detachment routine is broken in every case where the controller was not > > > abruptly detached, but the driver relinquishes control of the controller > > > in an orderly fashion because of an operator command. > > > > The actual bug was i386 shutdown, a loop of vfs_unmountall1, > > config_detach_all > > and vfs_unmount_forceone. Here config_detach_all() detaches devices from > > the leafs up. > > For me it sometimes happend that the (scsi) root disk had outstanding xfers > > when it came to config_detach_all(). The disk would not detach but the > > bus detach would kill all outstanding operations. I don't want these xfers > > to > > abort but the disk continue operations until all xfers are done. > > > > And yes, this detach routine looks bogus at least ... > > The bug was in scsibusdetach(), which is not doing things in the proper > order: it has to detach its children and check for error. If no error, > then it can release the resources that the children were using. See > attached patch.
Yes, looks much better than mine ... please commit. -- Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)