On Wed, 26 Oct 2011, Thomas Poussevin wrote: > Hello, > We have a issue on uframe reservation order on ehci-sched. > The problem appears on a usb sound card pluged on a usb hub, when you > try to launch a arecord whereas a aplay is runnning. > The error "cannot submit datapipe for urb 0, error -28: not enough > bandwidth" occurs, and no recording is possible. > If you start recording before reading, both will work without problem. > The same comportment is present on OMAP with kernel 2.6.35 or on a > computer with 3.0.0-1 kernel. You have run across a very difficult problem. The fact is, the support in ehci-hcd for periodic split transactions is broken in many ways. > Desription of the problem : > > > * Standard comportment : > > Use ehci-logs.patch for information. Activation of standard ehci-hcd > debug modify comportement of driver. > Situation at start : 13 usec used for sound card hid. > > uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | > ---------------------------------------------------------------------- > max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | > ---------------------------------------------------------------------- > used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > ---------------------------------------------------------------------- > > cat /dev/urandom | alsa_aplay -Dhw:2,0 -f S16_LE -c2& > uframe 0 : isoc 164 > 125us, first frame must be empty, but 13 usecs used > uframe 1 : sheduled > > Situation is now : > > uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | > ---------------------------------------------------------------------- > max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | > ---------------------------------------------------------------------- > used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 | > ---------------------------------------------------------------------- And in fact, this is wrong already. An isochronous transaction should never be scheduled after an interrupt transaction. This is only one of many bugs. > arecord -Dhw:2,0 --rate=48000 -c 2 -f S16_LE > /tmp/input > uframe 0 : isoc 165 > 125us, first frame must be empty, but 13 usecs used > uframe 1 is fully scheduled : 125/125 (needs 165 usecs) > uframe 2 : isoc 165 > 125us, first frame must be empty, but 39 usecs used > uframe 3, for IN, don't wrap CSPLIT into the next frame, not ok > uframe 4, for IN, don't wrap CSPLIT into the next frame, not ok > uframe 5, for IN, don't wrap CSPLIT into the next frame, not ok > ehci-omap ehci-omap.0: iso resched full c0caab40 (now 256 max 4352) > no room in the shedule > cannot submit datapipe for urb 0, error -28: not enough bandwidth > > > > * Modified ehci-sched comportment : > > The patch ehci-scheduler.patch invert uframe choice order in > iso_stream_schedule. > When scheduling, check when is the next uframe we could start from the > end of the period. > So the output usecs are not scheduled in the first uframes, allowing > input usecs to find a place. > Here is the new comportment with the patch : > > > uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | > ---------------------------------------------------------------------- > max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | > ---------------------------------------------------------------------- > used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > ---------------------------------------------------------------------- > > cat /dev/urandom | alsa_aplay -Dhw:2,0 -f S16_LE -c2& > uframe 5 : usecs 164 unavailable (remains 9/0 on uframe 7) > Note : On uframe 5 , the 164 usecs would be uframe 5 : 125, uframe 6 : > 30, uframe 7 : 9,out of max > uframe 4 : sheduled > > > uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | > ---------------------------------------------------------------------- > max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | > ---------------------------------------------------------------------- > used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 78 | 0 | 0 | > ---------------------------------------------------------------------- This is a very bad idea. ehci-hcd does not support isochronous-IN CSPLIT transactions extending beyond a frame boundary. In practice this means that no isochronous-IN transaction should ever be scheduled in uframe 4 or later. > arecord -Dhw:2,0 --rate=48000 -c 2 -f S16_LE > /tmp/input > uframe 5, for IN, don't wrap CSPLIT into the next frame, not ok > uframe 4, for IN, don't wrap CSPLIT into the next frame, not ok > uframe 3, for IN, don't wrap CSPLIT into the next frame, not ok > uframe 2 : sheduled > > uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | > ---------------------------------------------------------------------- > max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | > ---------------------------------------------------------------------- > used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 78 | 0 | 0 | > ---------------------------------------------------------------------- It's not possible to truly fix this problem without a very extensive rewrite of ehci-sched.c. For now, the easiest band-aid solution is to relax the restriction that transfers lasting longer than 125 us must start in an empty uframe. Instead, check that no existing transactions will be pushed back beyond their uframe boundary. 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
