On Thu, Mar 15, 2012 at 02:17:28AM +0000, Xu, Andiry wrote: > > -----Original Message----- > > From: Dmitri Belimov [mailto:d.belimov@xxxxxxxxx] > > Sent: Thursday, March 15, 2012 9:32 AM > > To: Xu, Andiry > > Cc: Mauro Carvalho Chehab > > Subject: USB3.0 race condition? > > > > Hello > > > > Our company design and sell own TV cards. One of them has USB 2.0 interface > > and based on the tm6010 chip. > > I wrote some open-source drivers of linux kernel for our TV cards. > > > > Some times a go one of our customers report me about some problems with USB > > TV cards and newest USB 3.0 host. > > When many TV cards connected to the USB 3.0 we see errors: > > > > > > [ 846.285810] tm6000 #0: registered device video0 > > [ 846.285835] tm6000 #0: registered device radio0 > > [ 846.285838] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load > > status: 0) > > [ 846.285851] tm6000_usb_probe stop OK > > First device init OK > > > > [ 846.285859] tm6000_usb_probe start > > [ 846.285861] befor usb_set_int > > [ 846.286099] usb 3-1.2: Not enough bandwidth for new device state. > > [ 846.286104] usb 3-1.2: Not enough bandwidth for altsetting 1 > > [ 846.286106] usb_set_interface FAILURE rc = -28 > > [ 846.286107] tm6000: Error -28 while registering > > [ 846.286156] tm6000_usb_probe stop FAIL > > Second and other devices init FAIL > > > > We have this errors when many TV cards installed into USB3.0. > > > > If we set at the first time only one all is good. When we add next TV cards > > after some time > > all is good too. We try add step by step 7 TV cards to USB 3.0 all of them > > init OK. > > > > I think the xhci can has race condition or spinlock a bug. May be I wrong. > > What you think about it?? > > > > Well, I don't think it's a race/spinlock problem. When a device is plugged in > and addressed, the xHCI driver will send a configure endpoint command and > ask host to allocate bandwidth for the device. Isoc devices such as TV cards > require more bandwidth. If the bandwidth is not enough, host rejects the command > and returns failure, and devices init fail. > > However, I don't know why adding them one by one is OK. Maybe Sarah has some > suggestions. I don't know either, but without looking at a full log or lsusb, here's some hypotheses. One possibility is that the host controller is just buggy, and it really should reject the Nth card if they're added slowly, one at a time. That's a hardware bug we can't fix. Another possibility is that alt setting 0 has a higher bandwidth than another alt setting on the TV tuner. The video driver might change to the less bandwidth intensive alt setting after the device is enumerated. However, if you plug all the devices in at once, the USB core may try to enumerate the next device before the driver has a chance to change the alternate interface setting. A third possibility is that the driver goes through a less-more-less bandwidth intensive switch between alt settings, and the enumeration of the next card just happens to occur when the driver has a more bandwidth intensive setting. I've seen this happen with two video cameras, because the USB sound driver is grabbing the microphone on the USB device (causing more bandwidth to be allocated), and then dropping it. If you plug in a camera just when the sound alt setting is switched, and you're reaching the full bus bandwidth, you might overload the bus bandwidth and get the device rejected. But if you wait until the USB sound device turns off the USB microphone on the webcam, you can plug in a second device. But these are just guesses. Without a full log of the failed and successful runs, and lsusb for the devices, I can't be sure. Sarah Sharp -- 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
