> > 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? Yes, right. > > 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"? Eh lame me sorry, obviously wanted to write 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? afaik splits are filtered out, about the DATA afaik it is the "normal" behaviour of the printer (at least on XP, haven't really checked on Linux, though). > > > 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. No we didn't do that, didn't want to solder onto the motherboard yet. But anyhow will try that. > > > 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. Thanks! -- 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
