Has anyone looked into this further?  I can confirm that the problem 
still exists for me with a USB flash disk (PNY Attache 2.0) on a very 
recent -current.

Here's the trace:

umass0 at uhub2 port 1 configuration 1 interface 0
umass0: PNY Attache 2.0, rev 2.00/2.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target

This machine has uhci and ehci



In message <20040914100055.A4189@yoda.cubidou.net>, cube@cubidou.net writes:
>On Tue, Sep 14, 2004 at 09:26:43AM +0200, Christian Palomino wrote:
>> On Mon, 13 Sep 2004 11:21:37 +0200
>> cube@cubidou.net wrote:
>> 
>> 
>> > Could you post the relevant part of dmesg(1) output?
>> > 
>> > Quentin Garnier.
>> 
>> Sure, I get:
>> umass0 at uhub3 port 3 configuration 1 interface 0
>> umass0: Apple iPod mini, rev 2.00/0.01, addr 2
>> umass0: using SCSI over Bulk-Only
>> scsibus0 at umass0: 2 targets, 1 lun per target
>> 
>> And nothing else.
>
>That's what I suspected.  I have the same issue with a DiskOnKey
>device (lent by a friend), and while I understand what happens, so
>far I couldn't find a solution.
>
>It's likely to be a bug in our USB stack.
>
>Here are my observations so far (hence I'm CC-ing tech-kern):
>
>o the device behaves the same way in ohci and uhci.  However, I made
>  intense debugging only with a uhci system.
>o when plugged into a ehci-only (there should not be such thing, but
>  there is one port on my laptop where nothing seems to attach as
>  USB<2, so interpret ehci-only as ehci-very-friendly), the port gets
>  an error, and sometimes ends up disconnected.
>
>The actual sequence of event is the following:
>
>o umass attachment starts.  It detects it should be using bulk-only
>  transfers.
>o umass code reads the number of LUNs.  This is a BBB command.  This
>  command succeeds, and will usually return 1 (or actually 0, the
>  maximum index).
>o umass attaches a scsibus device.
>o scsibus scans the bus, and finds one device
>o scsibus code sends an INQUIRY command
>o umass code starts the transfer
>o uhci code handles the bulk transfer
>
>A bulk transfer consists of three steps:
>
>o the host sends a CBW structure containing the command and a header
>o the data transfers happen (it can be in one way or another, in our
>  case it's an IN one, from the device to the host)
>o the host receives a CSW structure, indicating the status of the
>  command
>
>What happens in NetBSD for such devices is the following:
>
>o the CBW is correctly sent, and the interrupt confirming it is
>  correctly generated and handled
>o the data transfer doesn't happen.  Instead, in the buffer that
>  supposedly contains the data, we get the CSW structure.
>o the data is improperly parsed, and the INQUIRY commands fails.
>
>Thus, no scsi device ever gets attached.
>
>I got a trace from a Linux host (everything works fine) and from a Windows
>host, and I get the expected results.  So far I don't see why we're not
>getting the correct data at the relevant point of the transfer.
>
>First I would have suspected a uhci issue, since the controller code handles
>the whole transfer, but since the same seems to happen with ohci, I suspect
>it is a more general issue that only shows up in that case.
>
>In any way, I'm interested in getting a trace with an ohci controller, if you
>have such one.  I want the full thing, with umassdebug at 0xffffffff, usbdebug
>at a large value (say, 0xffff) and ohcidebug at a large value too.
>
>Of course, I'm interested in the uhci trace for the mini iPod too, in case you
>don't have an ohci controller.
>
>Quentin Garnier.
>


		--Steve Bellovin, http://www.research.att.com/~smb