On Wed, 6 Apr 2011, Arvid Brodin wrote: > > That's normal for a hung system. Of course, the real question is why > > is it hanging? Probably a bug in the isp176x driver. > > > > You were right; I did not unlink active packets correctly. After fixing, I > now get a device reset after 30 s just like you said I should! > > However I still have the problem of the device STALLing for 30 s a few times > per megabyte or so. Any clues from the following info? > > From the USB bus analyser: > > ... > OUT 003:2 ACK 512 bytes > OUT 003:2 ACK 512 bytes > OUT 003:2 ACK 512 bytes > OUT 003:2 NYET 511 bytes 511? That's strange. > IN 003:1 ACK 13 bytes > OUT 003:2 ACK 30 bytes So is 30 -- it should be 31. > OUT 003:2 STALL 512 bytes Which might explain this stall. > Device Request: Clear Feature Endpoint Halt (003:0 OK) > <30 s of IN NAKs> > Device Reset > > > I guess this matches the "-32 line" and the line above that in the > corresponding usbmon dump (taken on 2.6.27): 2.6.27 is several years old. You'd be much better off using a recent kernel, if you can. > ... > 93996200 659495767 S Bi:1:003:1 -115 13 < > 93996200 659496030 C Bi:1:003:1 0 13 = 55534253 0000006f 00000000 00 > 93996200 659497681 S Bo:1:003:2 -115 31 = 55534243 00000070 00e00100 00000a2a 00000ca7 e80000f0 00000000 000000 > 93996200 659497852 C Bo:1:003:2 0 31 > > 93996800 659497990 S Bo:1:003:2 -115 32768 = 403f518d 337a68f1 c7f651ed 0889d5ed a213cd76 73811e68 b6bd4746 2080c422 > 93996880 659498651 S Bo:1:003:2 -115 65536 = f4084289 f573422f c620b17f 9743a720 da104d27 699e0810 0ab2ba9a 443d3489 > 93996900 659499000 S Bo:1:003:2 -115 24576 = 04713170 e4093fd4 feba8615 2ce94705 84dab6a5 64e355bc 54b7293c 3b168ade > 93996800 659506453 C Bo:1:003:2 0 32768 > > 93996880 659522453 C Bo:1:003:2 0 65536 > > 93996900 659529452 C Bo:1:003:2 0 24576 > > 93996200 659529774 S Bi:1:003:1 -115 13 < > 93996200 659529948 C Bi:1:003:1 0 13 = 55534253 00000070 00000000 00 > 93996200 659531264 S Bo:1:003:2 -115 31 = 55534243 00000071 00e00100 00000a2a 00000ca8 d80000f0 00000000 000000 > 93996200 659531463 C Bo:1:003:2 0 31 > > 93996800 659531660 S Bo:1:003:2 -115 40960 = 8dfc378f ecc64464 f3f5a0f9 593a6c07 d52f13ae 4ce0f396 ad80a868 be88f9b9 > 93996800 659532401 C Bo:1:003:2 -32 0 > <STALL above (-32)> Yes, they appear to match up. > Is it normal that usbmon thinks that the urb above the stalling one have 31 > bytes, while the USB analyser says 30 bytes? It certainly is not. It means the kernel gave the HCD a 31-byte URB but the hardware sent a 30-byte packet. (Similarly for the 511-byte packet above.) Another bug in the driver? > Seems weird to me... (the earlier > 13/31 byte transfers are reported as such by the analyser). > > The continued dump, complete until the next STALL: ... Not particularly helpful, unfortunately. 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
