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.