Re: CVS commit: src/sys/dev/scsipi

[Juergen Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>]

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 - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)