On Sun, Dec 06, 2009 at 08:33:50PM +0100, Andreas Mohr wrote: > I'll now enable usb-serial debugging (via CONFIG_DYNAMIC_DEBUG), > that should hopefully help in figuring out (by printing read callback > setup data etc.) what kind of catastrophic failure we have > on the read side of things. Something is very fishy. > > BTW, trying to unload the ftdi_sio module without getting stuck > still remains a futile attempt (despite the latency configuration cure), > thus it's likely to have been caused by the huge problem on the read > side. > > > NOTE that the same thing works beautifully with a PL2303 device on this > very same router (both pl2303 and usbserial can be unloaded correctly > after having yanked the device), and pl2303 actually does: dynamic debugging of usb-serial behaviour of FTDI vs. pl2303 drivers didn't show much, except for the fact that FTDI only has bulk in/out endpoints, whereas pl2303 has an additional interrupt in endpoint. (AHA!!) This might now indicate that interrupt-endpoint-less handling on the receive side of things is broken, and possibly for this HC only (ohci-ssb). I followed usb_submit_urb() down to urb_enqueue() and then finally td_submit_urb(), but I don't know which kind of live debugging I'd have to do to determine whether the HC driver does something incorrect or is missing some setup. And is there something that would help me on the userspace side of things to figure out configuration status? (e.g. somewhere below /sys/bus/usb...). Somehow I'm feeling pretty lost now... (the only idea that I currently still have is randomly plugging some further devices to verify whether all non-interrupt devices lock up and all interrupt ones work) Thanks, Andreas Mohr -- 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
