On Thu, 30 Sep 2010, [Windows-1252] Hársszegi Tibor wrote: > Hi, > > Our company is trying to use a USB2VGA adapter from StarTech.com (practically it is a sisusbvga stuff) > under OpenSuse. The USB2VGA adapter operates at USB 2.0 high speed. We also have a USB 1.1 printer > using usblp. The 2 devices are one the same bus. > > T: Bus=04 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=0711 ProdID=0900 Rev= 1.10 > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=222mA > I: If#= 0 Alt= 0 #EPs= 9 Cls=ff(vend.) Sub=00 Prot=00 Driver=sisusb > > T: Bus=04 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 7 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=13ea ProdID=0326 Rev= 0.16 > S: Manufacturer= Scientific Games Ltd > S: Product=USB PRINTER > S: SerialNumber=0100001060577867 > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=400mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp > > When doing transfers to the printer the sisusbvga starts to act crazy, starts - after a while - refusing URBs with > EPIPE or similar. > > c1b244c0 2517956235 S Bo:007:01 EINPROGRESS 3 = 1b4f01 > c1b244c0 2517956297 C Bo:007:01 0 3 > > c1b244c0 2517956406 S Bo:007:01 EINPROGRESS 6 = 1b540000 1532 > c1b244c0 2517956546 C Bo:007:01 0 6 > > c1b244c0 2517956594 S Bo:007:01 EINPROGRESS 2 = 1b43 > c1b244c0 2517956671 C Bo:007:01 0 2 > > f755e4c0 2517956721 S Ci:007:00 s a1 01 0000 0000 0001 1 < > f755e4c0 2517956922 C Ci:007:00 0 1 = 18 > f7c486c0 2517956927 C Bo:004:03 0 60896 > > c1b244c0 2517957942 S Bo:007:01 EINPROGRESS 1024 = 1b2a5000 20000000 00000000 00000000 00000000 00000000 00000000 00000000 > c1b244c0 2517963921 C Bo:007:01 0 1024 > > c1b244c0 2517963936 S Bo:007:01 EINPROGRESS 1024 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > f7c487c0 2517967918 S Bo:004:13 EINPROGRESS 10 = 1f00d401 0000102c 01d0 > f7c487c0 2517968044 C Bo:004:13 EPIPE 0 > f7c487c0 2517968059 S Bo:004:13 EINPROGRESS 10 = 1f00d001 0000e0ed 1b00 > f7c487c0 2517968294 C Bo:004:13 EPIPE 0 > f7c487c0 2517968308 S Bo:004:13 EINPROGRESS 10 = 1f00c001 00001600 0000 > f7c487c0 2517968544 C Bo:004:13 EPIPE 0 > f7c487c0 2517968637 S Bo:004:03 EINPROGRESS 65536 = 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff > f7ced2c0 2517968726 S Bo:004:03 EINPROGRESS 65536 = 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff > f7ce7140 2517968804 S Bo:004:03 EINPROGRESS 65536 = 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff 000000ff Device 007 is the printer and device 004 is the display? > If the devices are connected on different buses, the issue does not happen. Sadly we can't do that on the target > device. > We have tracked down the issue until the point that on XP Embedded, XP does not allow consecutive transfers of different Do you mean "consecutive" or "concurrent"? > speeds for devices on the same bus, practically the VGA playback is paused while the printer transfer is done. > We could conclude the same with logs from USB sniffers. DEV=05 is the 1.1 printer, DEV=04 is the USB2VGA. > > 254305,0:04.200.661.500,66 ns,,,,,[1 SOF] > 254318,0:04.200.778.350,66 ns,,,OUT,0C,DEV=05 EP=01 > 254319,0:04.200.778.683,1.133 us,64,,DATA0,D0BF,00 00 00 ... Shouldn't there be some SSPLIT and CSPLIT packets here? Does your sniffer filter them out? And shouldn't there be an ACK following the DATA0 above? > 254320,0:04.200.786.500,66 ns,,,,,[1 SOF] > 254321,0:04.200.790.950,66 ns,,,PING,0D,DEV=04 EP=0D > 254322,0:04.200.791.466,33 ns,,,ACK,, > 254337,0:04.200.911.500,66 ns,,,,,[1 SOF] > 254351,0:04.201.036.483,83 ns,,,,,[1 SOF] > 254352,0:04.201.036.816,83 ns,,,PING,0D,DEV=04 EP=0D > 254353,0:04.201.037.350,33 ns,,,ACK,, > 254367,0:04.201.138.416,83 ns,,,OUT,0C,DEV=05 EP=01 > 254368,0:04.201.138.766,1.150 us,64,,DATA0,D0BF,00 00 00 ... > 254369,0:04.201.161.483,83 ns,,,,,[1 SOF] > 254383,0:04.201.286.483,83 ns,,,,,[1 SOF] > 254384,0:04.201.286.816,83 ns,,,PING,0D,DEV=04 EP=0D > 254385,0:04.201.287.350,50 ns,,,ACK,, > 254400,0:04.201.411.483,83 ns,,,,,[1 SOF] > 254413,0:04.201.519.500,83 ns,,,OUT,0C,DEV=05 EP=01 > 254414,0:04.201.519.833,1.150 us,64,,DATA1,D0BF,00 00 00 ... > 254415,0:04.201.536.483,83 ns,,,,,[1 SOF] > 254432,0:04.201.661.483,66 ns,,,,,[1 SOF] > 254433,0:04.201.673.116,66 ns,,,OUT,16,DEV=04 EP=03 > 254434,0:04.201.673.466,8.600 us,512,,DATA1,44BE,00 00 00 ... > 254435,0:04.201.682.500,50 ns,,,ACK,, > 254454,0:04.201.786.483,66 ns,,,,,[1 SOF] > 254455,0:04.201.788.866,66 ns,,,OUT,16,DEV=04 EP=03 > 254456,0:04.201.789.216,8.600 us,512,,DATA1,44BE,00 00 00 ... > 254457,0:04.201.798.250,50 ns,,,ACK,, > 254477,0:04.201.911.483,66 ns,,,,,[1 SOF] > 254478,0:04.201.911.816,66 ns,,,OUT,16,DEV=04 EP=03 > 254479,0:04.201.912.166,8.600 us,512,,DATA1,44BE,00 00 00 ... > 254480,0:04.201.921.200,50 ns,,,ACK,, > 254499,0:04.202.036.466,83 ns,,,,,[1 SOF] > > So we suspect that the concurrent 1.1/2.0 transfer within Linux causes us the problems as either the USB (ICH4-I82801) chipset > underneath or either the USB2VGA does not tolerate this issue. Have tried the issue on both 2.6.18.8 (OpenSuse 10.2) and on > 2.6.34.12 (OpenSuse 11.3)- no luck either, concurrency is still there. Perhaps the problem is in the hub, not in the EHCI controller. Have you tried using different types of hubs? Have you tried sniffing the USB connection between the hub and the USB2VGA? That will tell you what device actually sees; it should be different from the traffic between the computer and the hub. > Do you have any idea whether: > > a.) is there any current flag in the Linux kernel (CONFIG_*) to disable this concurrency of transfers? No. > b.) do you have any suggestion where should we look at within the kernel code to try to disable this parallelization? > Would guess for 'urb_enqueue', but not sure. There is no good place. You can start at submit_async, but more would be needed. The driver is not designed to support what you want to do. 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
