On Sun, 2 Jul 2006, Christopher Montgomery wrote: > The part I forgot to mention is that usb-hub.c implements a magic > number of ten consecutive interrupt errors on a given hcd before it > starts aggressively resetting/downing hardware.
Ah, okay. That's different from what I thought you meant -- the "Nobody cared" message when the kernel disables an entire IRQ. And by the way, your description above is pretty inaccurate. That magic number of 10 in hub.c (not "usb-hub.c") doesn't apply to interrupt errors on a given hcd; it refers to error status in interrupt URBs for a given hub. > On 7/2/06, Alan Stern <[EMAIL PROTECTED]> wrote: > > > I don't understand the problem you are describing. The kernel doesn't > > kill off an IRQ unless it gets a lot of unhandled interrupts (99900 out of > > the last 100000). But none of the interrupts you mention will be > > unhandled -- ehci-hcd will handle all of them. So what's the issue? > > I may be conflating the results of two different problems (that is, > the logging may also be slowing down interrupt handling enough that > that's enough to have the kernel think interrupts are not being > serviced). I'll assemble logs; I don't have them now because I had to > disable all the code that kills off devices when too many interrupt > errors come in else I couldn't syslog for debugging purposes. > > But the real question is why USB's left hand is processing thousands > of interrupts reporting -EPROTO (and trying, repeatedly, to reset and > re-up the device) while USB's right hand is fully aware that the > hardware has disappeared-- it is already well into > usb_disconnect_xxx() processing as this is going on (of that much I'm > certain). The interrupts are coming in and being serviced during the > attempt to remove the hardware. (Do you mean "interrupt" or "interrupt URB"? They are two very different things.) Well, part of the problem is that there _is_ no "USB" with a right hand or a left hand. There is only the kernel drivers with their associated kernel threads. It's typical of multiprocessing systems that different threads get out-of-sync with each other from time to time. If you look more closely at what's really happening, you should find that it all makes sense. You can't get -EPROTO status in URBs for devices that the kernel knows are disconnected, because the core won't even accept these URBs when they are submitted. Also, khubd is a single thread so it can do only one thing at a time. If it's busy with disconnect processing for one device, it can't suddenly start doing disconnect processing for a different device. Alan Stern Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
