Hi, I'm working on the isp1760 driver (mostly modifying the qtd queueing to get rid of BUG() calls in interrupt context). I have a high-speed USB-stick, that (probably due to some protocol error of mine) STALLs when I transfer a 15 MB file to it (after first transferring a few MB successfully with repeated 512 B OUT, NYET, PINGs etc.). After the stall is received, the host immediately sends a "Device request: Clear feature: Endpoint halt" which succeeds. After that, the host continues with IN transactions, but the device NAKs these indefinitely and the bus hangs (and I get a softlockup BUG after 120 s). This behaviour was detected using a USB analyzer. When I try this stick on my desktop EHCI, I never get the STALL, but lots of NAKs on IN bulk packets. The stick works fine here. a) Should there be some kind of limit/quench on bulk IN NAKs somehow, so that a (malicious/erroneous) device cannot hang the USB subsystem like this? The EHCI driver loads the NakCnt field with 4 (EHCI_TUNE_RL_HS), but when 4 NAKs have been detected and the HC returns the packet, I believe it's just reset and enqueued again? b) My host controller driver returns urb->status = -EPIPE (-32) to the usb core after receiving the STALL packet. I'm guessing this is correct since usb core then sends the Clear Endpoint Halt command afterwards. Am I right in this? c) Clearly, continued bulk IN requests is not the right thing to do after this. Any ideas why this happens? I'm pretty much out of ideas on this now. Alternatively, I've done something wrong to cause the STALL in the first place, which puts the host/device in some very unfortunate state - what could I have done to cause this? (Some problem with ping or toggle state?) Thanks, Arvid Brodin Enea Services Stockholm AB -- 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
