On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > The log between hub and soundcard shows this: > > SOF > OUT > DATA0 185 byte with CRC error > OUT > DATA0 4 bytes Which is totally wrong, of course. > 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 We can ignore that isoc-IN as not being relevant to any isoc-OUT transfers. This doesn't show any isoc-OUT activity during frame 1193. > 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 > ... That is not good. The two Start SPLIT transactions are not supposed to occur in the same microframe. The second transaction should have occurred during microframe 1194.1. That could easily confuse the hub. (Actually, depending on the details of the scheduling, it seems more likely that the first Start SPLIT should have shown up during microframe 1193.7 and the second during 1194.0.) > Between hub and soundcard (FS): > > frame# > 1193 SOF > OUT EP=1 > DATA0 185 bytes with CRC error This doesn't correspond to anything in the high-speed trace. Also, the CRC is supposed to be generated by the hub's TT, not by the host. If it is wrong, it indicates the hub isn't behaving properly, perhaps because it was confused by the invalid sequence of Start SPLIT transactions. > IN EP=1 > DATA0 0 bytes > OUT EP=1 > DATA0 4 bytes This data is all for frame 1193, not 1194 as in the high-speed trace. Were the two traces made at the same time? > 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.) It does show isoc-IN Start SPLITs if you look closely. It doesn't show isoc-OUT Complete SPLITs because there is no such thing. > While it seems permissible by the USB spec to split the payload, Not permissible -- required! See paragraph 2a in section 11.18.4 of the USB-2 spec. > 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... It's done this way to minimize the amount of data buffering needed in the hub's Transaction Translator. Full-speed transactions are broken up into microframe-sized pieces, and the TT is required to store only a few of these pieces. Since it's not possible to transfer more than 188 bytes over a full-speed link in 125 us (one microframe), transfers are broken up into pieces that are 188 bytes or the remainder of the transfer, whichever is smaller. The same thing happens with Complete SPLITs for long isoc-IN transfers. > Apparently the hubs cannot cope with this sequence, does it > mean all four hubs which were tested are buggy? Judging by your high-speed log, it looks like the host controller is not sending out the Start SPLIT transactions the way it should. Alan Stern -- 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
