On Mon, 29 Mar 2010, Justin Piszcz wrote:Here it is (after I plugged it back in)
What about the "registers" file?
This all looks normal. It's possible that we've been looking for theYes, I've done this before for a bug in the Intel USB controller (P55) on
bug in the wrong place; maybe there's nothing wrong with the OHCI
controller.
So next you should get a usbmon trace showing what happens on bus 2
when one of these mouse failures occurs. Instructions for usbmon are
in Documentation/usb/usbmon.txt.
At the same time, just to be increase my level of certainty, you should
apply the following debugging patch for ohci-hcd. Let's see both the
usbmon trace and the dmesg log for the same event. The trace and the
debugging patch will generate plenty of output during normal operation,
but don't worry about that. Only the part starting from shortly before
the mouse quits really matters.
--
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-hcd.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ohci-hcd.c
+++ usb-2.6/drivers/usb/host/ohci-hcd.c
@@ -290,6 +290,8 @@ static int ohci_urb_dequeue(struct usb_h
*/
urb_priv = urb->hcpriv;
if (urb_priv) {
+ ohci_info(ohci, "start unlink urb %p, ed %p\n",
+ urb, urb_priv->ed);
if (urb_priv->ed->state == ED_OPER)
start_ed_unlink (ohci, urb_priv->ed);
}
@@ -324,6 +326,9 @@ ohci_endpoint_disable (struct usb_hcd *h
if (!ed)
return;
+ ohci_info(ohci, "disable ed %p (#%02x) state %d%s\n",
+ ed, ep->desc.bEndpointAddress, ed->state,
+ list_empty(&ed->td_list) ? "" : " (has tds)");
rescan:
spin_lock_irqsave (&ohci->lock, flags);
@@ -770,6 +775,10 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_HANDLED;
}
+ ohci_info(ohci, "int %x enable %x rm_list %p\n", ints,
+ ohci_readl(ohci, ®s->intrenable),
+ ohci->ed_rm_list);
+
/* We only care about interrupts that are enabled */
ints &= ohci_readl(ohci, ®s->intrenable);