I sometimes get this error on isp1761:
# testusb -a
...
usbtest 1-1.3:3.0: TEST 11: unlink 1000 reads of 512
/proc/bus/usb/001/003 test 11, 16.002939 secs
usbtest 1-1.3:3.0: TEST 12: unlink 1000 writes of 512
/proc/bus/usb/001/003 test 12, 16.021250 secs
usbtest 1-1.3:3.0: set altsetting to 0 failed, -110
/proc/bus/usb/001/003 test 13 --> 110 (error 110)
usbtest 1-1.3:3.0: set altsetting to 0 failed, -110
/proc/bus/usb/001/003 test 14 --> 110 (error 110)
...
After this no usb transfers work until after reboot for this endpoint (even
after plug-in/plug-out).
The problem is that usb_pipebulk(urb->pipe) does not return true for the urb
sent to the unlink handler isp1760_urb_dequeue(), even though it is a bulk urb,
so the handler unlinks an INT urb instead (code from kill_transfer(), called
from isp1760_urb_dequeue()):
if (usb_pipebulk(urb->pipe)) {
skip_map = reg_read32(hcd->regs, HC_ATL_PTD_SKIPMAP_REG);
skip_map |= (1 << qh->slot);
reg_write32(hcd->regs, HC_ATL_PTD_SKIPMAP_REG, skip_map);
priv->atl_slots[qh->slot].qh = NULL;
priv->atl_slots[qh->slot].qtd = NULL;
} else {
skip_map = reg_read32(hcd->regs, HC_INT_PTD_SKIPMAP_REG);
skip_map |= (1 << qh->slot);
reg_write32(hcd->regs, HC_INT_PTD_SKIPMAP_REG, skip_map);
priv->int_slots[qh->slot].qh = NULL;
priv->int_slots[qh->slot].qtd = NULL;
}
I added a "else if usb_pipeint(urb->pipe)" for the second code block as well
as a default block with a WARN_ON(1), which confirms that neither usb_pipebulk()
nor usb_pipeint() returns true here when the bug triggers, and that the offending
urb was passed to isp1760_urb_dequeue().
Why is this? Is this a bug in how the isp1760 driver uses the usb_pipexxx()
macros in the unlink handler, or is this a problem with the testing driver
(usbtest.c)? Observe that I have only been able to trigger this bug at the
transition between testusb test #12 and #13.
--
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
