On 7/3/06, Alan Stern <[EMAIL PROTECTED]> wrote: > 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. ... > 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. >
Hi Alan, one side question with respect to the -EPROTO handling code. We are using libusb to power control ports on a hub that is chained behind another hub (we discussed this several months ago on the list). We are experiencing similar problems like Christopher since we are intervening behind the back of the driver from userspace. After ten -EPROTO events (because of the Interrupt URBs I presume) the hub driver starts a self-healing procedure repowering the whole tree, eventually powering the port on the hub that we want to keep off. I wanted to ask if the new autosuspend/remote wakeup code that you have proposed, will in any way change this unfortunate behavior? Will there be a way for the user to control this using sysfs, achieving port power control on chained hubs without a re-power because of the -EPROTO events? Vlado 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
