2009/4/10 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 9 Apr 2009, Kung James wrote: > >> Actually, this bug really cause some problem. >> >> I plug an USB mouse and an USB sound card in to USB2.0 HUB. >> When I play music with the 192 byte data in every frame, the mouse will be >> port reset by kernel. Because the start split of QH of intr. IN >> endpoint is scheduled >> at the first micro frame, and the SITD of isoc. OUT endpoint is scheduled >> at the first and the second micro frame. At the first micro frame, the >> HUB need to execute 188 byte start split isoc. OUT transaction and a start split >> intr. IN transaction. Some HUBs can successfully execute the two split >> transaction >> at the first micro frame, but some HUBs (e.g. NEC uD720114) can not. > > Can you explain more fully? I'm just starting to go through the > scheduling code in ehci-sched.c, so I don't understand it all yet. Why > does this patch fix the problem? > > Every USB-2.0-compliant hub should be able to handle those two > start-split transactions in the same uframe. How far should we go to > accomodate buggy hubs? > > Alan Stern The USB 2.0 spec. section 11.18.1 says, "a microframe of time allows at most 187.5 raw bytes of signaling on a full-speed bus." and "The best case full-speed budget assumes that 188 full-speed bytes occur in each microframe." If a full-speed isoc. packet which max. size is bigger than 188 bytes or its max. transfer time is over 125us, the full-speed isoc. packet may fully occupy one or more microframe. So the "tt_available" function must to make sure that those fully occupied microframes are not used by other full- or low-speed transactions. But currently the "tt_available" function doesn't check the last fully occupied microframe. My test case is described as follow: First, submit a intr. IN urb to a low-speed device (mouse), and then submit many isoc. OUT urbs with packet size 192 bytes to a full-speed device (audio device). The EHCI will put the isoc. OUT SSPLIT transaction at microframe (0,1), and put the intr. IN SSPLIT transaction at microframe (0), and the intr. IN CSPLIT transaction at microframe (1,2,3). Because the isoc. OUT packet's size is 192 bytes, the EHCI can execute 188 bytes isoc. OUT SSPLIT at most in microframe 0, and the rest 4 bytes will be executed in the microframe 1. We can observe that the EHCI need to execute an 188 bytes isoc. OUT SSPLIT and an intr. IN SSPLIT in microframe 0. This may makes the HUB have not enough time to execute the intr. IN SSPLIT in microframe 0. (The isoc. OUT SSPLIT will be executed first, because of the EHCI periodic frame list structure) So the schedule result is wrong, the EHCI driver can not put the two split transaction at the same microframe. This mistake is due to the "tt_available" function doest not check the last fully used uframe for the isoc. OUT split transaction. (The intr. IN SSPLIT is already scheduled at microframe 0 by EHCI driver) -- 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
