panic after removing usb flash drive
ticso at cicely12.cicely.de
Sat Sep 3 11:01:22 GMT 2005
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
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
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
> >>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
> 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.
B.Walter BWCT http://www.bwct.de
bernd at bwct.de info at bwct.de
More information about the freebsd-current