Re: panic after removing usb flash drive

On Wed, Aug 31, 2005 at 06:30:00PM -0600, Scott Long wrote:
> Bernd Walter wrote:
> >On Wed, Aug 31, 2005 at 05:02:38PM -0600, Scott Long wrote:
> >>Bernd Walter wrote:
> >>>On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote:
> You could probably get around the problem of sleeping in the USB event
> thread by doing the sleep parts of the detach in a taskqueue.  But that
> just adds more complexity and more need for synchronization.  If the
> only choice was to retain the SIM-per-device model then this is what I
> would do, but it's not a choice that I like.

I don't see how your single-SIM per bus solves that problem - you still
have to delete a SIM in case an USB-controller is detached.
USB-controller detachments can happen more often as one think, e.g. in
case of a cardbus host controller.

> >What I mean is a single USB device with multiple umass instances.
> >umass ist just a logical interface in the USB world, normaly ment
> >to allow e.g. an ulpt and umass on the same USB device, but also
> >possible to have multiple umass interfaces on the same USB device.
> >Since an umass interface needs at least two bulk endpoints a single
> >USB-channel can have up to 16 * 127 umass instances.
> >
> 
> CAM right now is really geared for parallel SCSI with only 16 targets,
> but it should work fine with 2048 targets.  A project for CAMng is to
> properly support FC fabrics properly as well as iSCSI; in both cases
> the max-target-per-bus concept has little meaning and would need 
> fundamental changes.  That's future work, though.

OK - 2048 per bus should be fine for any possible case of umass
compliant devices.
I personally was worried about bus scan-time with that many targets.

> For a physical device with multiple umass logical devices, each logical
> device would again just be a target.  The actual target and bus numbers
> don't really matter in practical use because they aren't exposed to
> /dev.  To make it truly transparent we would need to have an automounter
> like other OSes that mounts based on filesystem label, not based on
> device node name.  But that's mostly a detail at this point.

Not exactly the same, but there is already glabel.

> >OK - I got it now.
> >Nevertheless I could imagine a pseudo USB-SCSI converter that just
> >enhances umass transactions with a target-ID.
> >This won't invalidate what you wrote above, since you still don't have
> >full access on the SCSI-bus, but also requires a sim per (enhanced)umass.
> >
> 
> I assume that this is really just a mythical device, right?  If it were
> really just a very simple extension of the umass protocol then I'd 
> probably elect to treat it as multiple targets with the same single
> SIM.

USB to SCSI converters do exist, but I don't know if ant of them is
really based on umass, so yes one can call it mythical.

> >>>OK - that won't help for a practical solution.
> >>>In the practical way it sounded easier to go the multiple sim way.
> >>>sim detach needs to be fixed either way.
> >>
> >>Yes.  It somewhat works now as long as the system is completely idle.
> >>It breaks down horribly if I/O or error recovery is in progress and
> >>a periph driver is left with CCBs in flight and/or a dangling
> >>reference to a SIM.  The only way to deal with this is to allow
> >>blocking while CAM drains itself.
> >
> >
> >Have to think about it.

OK - dangling SIM reference is bad.
But Sorry - I still don't understand any other influences.
In which way a loaded single SIM system is in a better position than a
multi SIM one?

> >>>Are there any other technical reasons for doing single sim?
> >>>You've mentioned rescource arbitration and error recovery.
> >>>Is there anything that can CAM do for us that it won't with multiple
> >>>sim?
> >>>
> >>
> >>It means that you'll be able to detach umass targets without doing the
> >>complicated dance of sleeping for CAM to drain itself.  It also will

Ack, but your proposed way of using a SIM per bus still requires SIM
detaching in some cases.
In the meantime I understood your point of view why you think that SIMs
are logically assigned with the USB channels, but I still don't
understand what it brings code-wise.
I still don't see any other positive effects other than reducing the
places where we need to detach a SIM.

> So was the motivation to change from a single SIM to SIM-per-device 
> based solely on the problem of doing manual bus rescans when a device
> got inserted?  If not, what were the other problems that got solved?

The motivation was a mix of rescan, max_lun and flexibility for mythical
devices.

> Btw, I envision my changes resulting in a SIM per USB controller.  So
> on a system with 3-4 controllers (as seem to be common these days), 
> you'd have that many SIMs.  umass targets would be paired with the SIM
> that was associated with the physical USB controller/bus of the target.

> 
> Scott

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd_at_bwct.de                                  info_at_bwct.de