Subject: Re: mini iPod gets no device in NetBSD 2.0-BETA
To: Christian Palomino <firstname.lastname@example.org>
From: None <email@example.com>
Date: 09/14/2004 10:00:55
On Tue, Sep 14, 2004 at 09:26:43AM +0200, Christian Palomino wrote:
> On Mon, 13 Sep 2004 11:21:37 +0200
> firstname.lastname@example.org 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
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
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
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.