Hi Peter,
Thanks for the bug report.
On 13/10/13(Sun) 16:24, Peter Kane wrote:
> What is the current expectation for plugging/unplugging USB keyboards?
This is obviously not the expected behavior, it should not crash your
system ;)
> Plugging and unplugging a Yubikey several times usually causes my notebooks
> to crash. It seems this probem extends to USB keyboards in general as I
> have found that on a second suspend-resume cycle my Thinkpad T42 will no
> longer restart with a Yubikey (or USB keyboard) attached.
The problem you're seeing is a side effect of my last change to usbdi.c
to stop queuing transfers as soon as possible when an I/O error is
reported generally corresponding to a device being detached.
Diff below should fix this regression, could you try it?
Bob, could you also give it a try and tell me if it still fixes your
ehci(4) issue?
Index: usbdi.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.60
diff -u -p -r1.60 usbdi.c
--- usbdi.c 24 Sep 2013 09:01:41 -0000 1.60
+++ usbdi.c 13 Oct 2013 13:29:39 -0000
@@ -803,15 +803,6 @@ usb_transfer_complete(struct usbd_xfer *
}
if (pipe->repeat) {
- /*
- * If we already got an I/O error that generally means
- * the device is gone or not responding, so don't try
- * to enqueue a new transfer as it will more likely
- * results in the same error.
- */
- if (xfer->status == USBD_IOERROR)
- pipe->repeat = 0;
-
if (xfer->callback)
xfer->callback(xfer, xfer->priv, xfer->status);
pipe->methods->done(xfer);
@@ -820,6 +811,15 @@ usb_transfer_complete(struct usbd_xfer *
if (xfer->callback)
xfer->callback(xfer, xfer->priv, xfer->status);
}
+
+ /*
+ * If we already got an I/O error that generally means the
+ * device is gone or not responding, so don't try to enqueue
+ * a new transfer as it will more likely results in the same
+ * error.
+ */
+ if (xfer->status == USBD_IOERROR)
+ pipe->repeat = 0;
if ((xfer->flags & USBD_SYNCHRONOUS) && !polling)
wakeup(xfer);
