Hi, On Mon, Dec 21, 2009 at 09:34:44PM +0100, Andreas Mohr wrote: > Hi, > > On Wed, Dec 09, 2009 at 11:15:50AM -0500, Alan Stern wrote: > > I know extremely little about the operation of FTDI chips, so you'll > > have to figure the rest of this out by yourself. In particular, I > > don't know what's significanct in the usbmon data. > > > > But at least now you are started off in a productive direction. > > Well, not so sure after all... ;) > > I slightly upgraded, to 2.6.31.9 (from .6), and now I found something > rather more interesting: on this platform, I can plug/unplug things > as I like, as long as I don't open() anything. > > After I actually did a cat /dev/ttyUSB0 (doesn't matter whether FTDI > 8U232AM or pl2303 or FTDI 232RL), after the next unplug things will then > have gone haywire, with the result being this trace: > > SysRq : Show Blocked State > task PC stack pid father > khubd D 8000b3d0 0 59 2 0x00100000 > Stack : 00000000 8014d8b8 81c57dbc 00000004 1000d001 0002b880 00000001 > 80340000 > 81c57d28 00000003 00000002 00000001 00000003 8000b3d0 81c57dec > 00000004 > 81c56000 81c57d48 815209b4 803a6628 0002b880 8003d6b4 81c2f000 > 803a6220 > 00000000 00000000 00000000 00000000 00000000 ffffffff a1dcb480 > 1000d001 > 81dca080 81dca158 81eb4258 801dbbe0 81eb4258 81eb4b00 00000001 > 81eb4b68 > ... > Call Trace: > [<8000acd4>] schedule+0x5b8/0x638 > [<8000b3d0>] schedule_timeout+0x1d4/0x210 > [<801dbbe0>] ehci_endpoint_disable+0x134/0x298 > [<801cb558>] usb_disable_device+0x88/0x1cc > [<801c49c0>] usb_disconnect+0x104/0x264 > [<801c60d8>] hub_thread+0x854/0x1664 > [<8004a92c>] kthread+0x7c/0x84 > [<8000fb4c>] kernel_thread_helper+0x10/0x18 OK, that's now finally fully debugged and working (we unfortunately lost all external listeners in the meantime), with very useful guidance by Alan (the Sternish kind of Alan, that is ;). Turned out that the ehci-ssb.c host controller driver (which is currently OpenWrt-only!) had simply (but certainly painfully!) gotten out-of-sync with USB development in mainline kernels since ~ 2.6.30, with no updates of the relevant OpenWrt quilt patches. Thus a crucial new USB callback entry (.clear_tt_buffer_complete) had not been added, causing ehci_endpoint_disable() to hang forever waiting for the qh->clearing_tt flag to... uhmm... clear, thereby disrupting any subsequent USB plug/unplug. I will now make sure to get the OpenWrt quilt patchset fully updated and then submit the ehci-ssb driver towards mainline, ASAP. Another question: if missing one of these callbacks can have such disastrous effects, shouldn't we add a debugging warning in case certain important struct hc_driver callbacks are missing? 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
