On Sat, 26 Jan 2013, Udo van den Heuvel wrote: > On 2013-01-25 19:06, Alan Stern wrote: > > On Fri, 25 Jan 2013, Alan Stern wrote: > > > >> This isn't a software problem. I don't know of any way to fix it or > >> work around it in the driver. The only thing to do is stop using that > >> controller. > > > > Spoke too soon. Try this patch; maybe it will help. (You'll have to > > remove the debugging patch first.) > > Did so. > Reloaded the ohci module, problem did not go away. > In the dmesg below you can see messages of reloading ohci modules, the > issue, then some pwc frame errors and then the restarting of the stuff. > [244322.416040] usb usb2: unregistering interface 2-0:1.0 > [244322.416054] ohci_hcd 0000:00:13.0: shutdown urb ffff88019f5e2900 > ep1in-intr > [244322.416095] usb usb2: usb_disable_device nuking all URBs > [244322.416170] ohci_hcd 0000:00:13.0: OHCI controller state > [244322.416173] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support > registers, rh state running > [244322.416176] ohci_hcd 0000:00:13.0: control 0x083 HCFS=operational CBSR=3 > [244322.416179] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0 > [244322.416182] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF > [244322.416185] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE > RD WDH That SF bit in the intrstatus register is the one causing the problem, I think. It is not set in the intrenable register, so the controller shouldn't issue any IRQs. But it does, nonetheless. Turning off SF apparently doesn't help -- the controller turns it on again a millisecond later anyway. So it looks like there's nothing we can do about this. It's just bad hardware. Sorry. 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
