On Mon, Mar 30, 2015 at 04:23:53PM +0200, Johannes Stezenbach wrote:
> On Mon, Mar 30, 2015 at 10:07:35AM -0400, Alan Stern wrote:
> > On Mon, 30 Mar 2015, Johannes Stezenbach wrote:
> >
> > > cases URBs with typically 5 isoc frames of 192 bytes
> > > length are queued. The wMaxPacketSize of the
> > > endpoint is 196 bytes. A USB analyzer connected
> > > via musb and hub revealed that musb breaks
> > > the 192 byte frames into two parts, one 188 byte
> > > and one 4 byte frame, ie. a 192 byte OUT transaction
> > > produces the following token sequence:
> > >
> > > SPLIT
> > > OUT
> > > DATA0 188 bytes
> > > SPLIT
> > > OUT
> > > DATA0 4 bytes
> >
> > That is correct behavior when a full-speed device is connected to a
> > high-speed hub.
>
> Is it? I would expect a single 192 byte packet here, breaking
> it in two doesn't make sense even if the hub would be able
> to reassemble the parts. My recollection of the SPLIT mechanism
> is to free up the HS bus between FS send and FS ACK for other
> transactions on other hub ports, not to split the data packets.
>
> > Have you tried hooking your USB analyzer between the
> > hub and the sound card? In that position it ought to show a single
> > 192-byte OUT packet, as you expect.
>
> I'll don't have the logs here but I'll let you know asap.
> IIRC there were CRC errors, but I did not take this
> log myself, I only took the log between musb host and hub
> to confirm the data packet split which I assumed was the root
> cause of the issue.
The log between hub and soundcard shows this:
SOF
OUT
DATA0 185 byte with CRC error
OUT
DATA0 4 bytes
Four different hubs have been tried to rule out a hub issue,
both powered and unpowered.
But I just re-read the USB spec about the special case of
Isochronous OUT split handling, in this case it is indeed
possible to split the payload. So let me expand the log,
maybe the issue is caused by the interleaving of IN and OUT
transactions? (The soundcard has audio inputs and outputs.)
Between host and hub (HS):
frame#
1193.1 SOF
1193.2 SOF
SPLIT Complete S=0 ET=Isoc
IN EP=1
DATA0 0 bytes
1193.3 SOF
1193.4 SOF
1193.5 SOF
1193.6 SOF
1193.7 SOF
1194.0 SOF
SPLIT Start S=1 E=0 ET=Isoc
OUT EP=1
DATA0 188 bytes
SPLIT Start S=0 E=1 ET=Isoc
OUT EP=1
DATA0 4 bytes
1194.1 SOF
1194.2 SOF
...
Between hub and soundcard (FS):
frame#
1193 SOF
OUT EP=1
DATA0 185 bytes with CRC error
IN EP=1
DATA0 0 bytes
OUT EP=1
DATA0 4 bytes
1194 SOF
...
(The Total Phase analyzer does not allow text export or copy&paste,
so I had to reproduce manually. Apparently it does not show
OUT SPLIT Comlete and IN SPLIT Start.)
While it seems permissible by the USB spec to split the payload,
I don't understand the reason to do so. I mean the payload has
to be smaller than the wMaxPacketSize of the EP, and the
wMaxPacketSize of a FS EP is always smaller than the max
size of an HS Isoc data packet? I must be missing something...
Apparently the hubs cannot cope with this sequence, does it
mean all four hubs which were tested are buggy?
Thanks,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
