Subject: Re: mini iPod gets no device in NetBSD 2.0-BETA
To: None <netbsd-users@NetBSD.org, tech-kern@NetBSD.org>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 11/16/2004 22:37:51
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
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>, email@example.com writes:
>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
> 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
>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.
--Steve Bellovin, http://www.research.att.com/~smb