Hello > 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. Ok. It's here motherboard GA-H67N-USB3-B3 lsusb and dmesg (init OK with delay 2 sec) for that USB3.0 -> D-link active USB Hub -> 8 pcs of our TV cards and dmesg init without error fail Well when we found that init is OK for one by one TV cards I try set some delay to function tm6000_usb_probe. With delay 2 sec. all of TV cards init OK. With delay 1 sec init OK only first 6 next init FAIL. Why I think about problem with USB3.0 part. We try only 2 TV cards with USB2.0 and USB3.0 For USB2.0 init without problem. For USB3.0 init FAIL, bandwith error One of TV cards can't eat full bandwith of USB3.0. This TV cards receive common analog TV and can use only around 12Mbit/s ISOC mode. When module of TV card init it don't capture any ISOC or BULK pipes. It's only when start wath TV or heard Radio. With my best regards, Dmitry. > 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
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 010: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 009: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 008: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 007: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 006: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 005: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 004: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 003: ID 6000:dec3 Beholder International Ltd. Bus 003 Device 002: ID 2001:f103 D-Link Corp. DUB-H7 7-port USB 2.0 hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 05ac:020c Apple, Inc. Extended Keyboard [Mitsumi] Bus 001 Device 003: ID 05ac:1003 Apple, Inc. Hub in Pro Keyboard [Mitsumi, A1048] Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Attachment:
tm6000_usb3_init_sleep2.dmesg
Description: Binary data
Attachment:
tm6000_multifail.dmesg
Description: Binary data
