Re: panic after removing usb flash drive

On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote:
> Bernd Walter wrote:
> >On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote:
> >>Ben Kaduk wrote:
> >>>On 8/31/05, Kyle Brooks <captinsmock_at_columbus.rr.com> wrote:
> >This would really a step backward.
> >Originally we had LUN creation/deletion on shared SIM and lots of
> >different problems.
> >SIM deletion should really be fixed - not only for umass, but generally
> >as we live in a world with removeable cards.
> 
> Bugs in the umass detach code are immediately responsible for the
> problem, but you are correct that CAM in general doesn't like SIMs
> going away.  DFly worked on this a while back, but I don't recall
> whether the work there was to add more sanity checks in the data
> path (which I don't want to do), or if it was the correct approach of
> flushing and quiescing the data/queuing, topology, and error recovery
> paths.

What bugs are you refering?
Sample code on how to correctly detach a sim a sparse.
The umass code doesn't know that devices on a scbus are in use, or
should it?
I think with a single sim style the target remains a ghost device
as long as it is refered, right?

In the USB-world we have the problem that a blocking detach blocks
other port attachment/detachments on the same bus as well.
This is because we currently have a single thread per bus processing
these events.
We already see this problem with ucom devices where an open tty on a
detached device blocks.
But it is better than the panic that we have right now.
In the tty case we have a timeout, don't know what we can do with CAM.

> >Technically a shared sim with using targets could be made work for
> >umass as it's defined today, but it won't work for USB to SCSI
> >converters - that we don't support one of these adapters today doesn't
> >solve the problem.
> 
> This is a completely different situation.  A USB-SCSI adapter would
> provide its own SCSI bus that is separate from the USB bus with its
> own queueing resources and own error recovery mechanisms.

Many umass devices are ide converters - even some flash drives.

> >Is is a academical standpoint defining where in the USB/umass
> >infrastrukture the SIM is located, but I personally always saw it
> >inside the USB-device and not on the USB.
> >USB is just a transport medium and not a SIM in the same way as PCI is
> >just a transport medium for a classical SCSI-Interface.
> >Yes - umass creates a SIM, bus and targed, because that is what a user
> >really attaches/detaches.
> >
> 
> It is muddy, but for a mass storage class device, you are using the
> USB bus as the transport medium and you are using the USB controller
> as the transport initiator.  Command queueing and resource arbitration
> happens in the USB controller and driver, not in the umass device or
> driver.  Same for error recovery.  The USB controller is essentially
> acting as a SCSI controller, just with a USB bus instead of a SPI bus.
> The whole point of CAM is to assist with queueing and arbitrating bus
> resources.  There is no way that the SIM-per-device approach can provide
> this information.

I can follow you to some degree.
With the single-sim design we have had the following problems:
- probing of LUNs filed on attach and required a manual rescan.
  undoubly fixable by someone with good CAM knowledge.
- CAM needs a max target value, but how many target do we really have?
  Each USB has up to 127 devices (pratically 100 useable as we need
  some hubs)
  Each device can have multiple functions, which means multiple umass
  instances.
  Previously we had a small hardcoded number, too big numbers slow
  down bus rescans, too small restrict the number of possible devices.
  We should have a dynamic way.
Don't remember if ther were others.

>From the technical standpoint - no matter what we do, there are
problems to solve.

> Your analogy of a PCI bus is correct for the USB-SCSI adapters, where 
> the adapter is doing a full conversion and bridge from one bus type to
> another.  It's not true for a umass device where it's merely using the
> USB bus as a SCSI transport.

So what is an USB-IDE converter?
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.
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?

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