> Date: Mon, 25 Mar 2002 00:47:59 -0800 > From: Kees Cook <[EMAIL PROTECTED]> > > usb-ohci.c: USB OHCI at membase 0xf8cf6000, IRQ 10 > usb-ohci.c: usb-00:0f.2, ServerWorks OSB4/CSB5 OHCI USB Controller > usb-ohci.c: USB HC reset_hc usb-00:0f.2: ctrl = 0x0 ; > usb.c: new USB bus registered, assigned bus number 1 > usb-ohci.c: SUB URB:[ 0] dev: 0,ep: 0-O,type:CTRL,flags: 0,len:0/0,stat:0(0) > usb-ohci.c: cmd(8): 00 05 01 00 00 00 00 00 > usb-ohci.c: RET(rh) URB:[ 0] dev: 0,ep: 0-O,type:CTRL,flags: 0,len:0/0,stat:0(0) > usb-ohci.c: USB Schedule overrun > usb-ohci.c: USB Schedule overrun > ... etc
Well that's curious. OHCI isn't actually allowed to emit a schedule overrun interrupt until the periodic schedule has contents. It's never going to have any at that point, since it will be completely empty (filled with zeroes, to indicate no contents). The OHCI spec does suggest (5.2.10.1) that if the HC can't access the (PCI) bus this might happen, but that'd imply something locking it out for most of a millisecond and preventing it from reading even one 32-bit word. (And in your case, doing that almost all of the time!) You might try to disable OHCI_INTR_SO in the hc_start() routine. That'll keep the controller from flooding your system with spurious schedule overrun interrupts (which likely caused the lockup). (By the way, I'm assuming you're using a relatively recent kernel, not something from pre-history ... :) As for why this silicon is deluded into thinking there's something in the periodic schedule that could overrun, I'm puzzled. Though for the record, I've seen some other silicon do the same, and haven't figured out if it's the same issue. Maybe someone's gone on a licensing binge with a flakey OHCI design ... :) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
