On Mon, 21 Dec 2009, Andreas Mohr wrote: > 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: Did the "cat" process end before you unplugged the device? > 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 > IOW, it seems to keep waiting for QH_STATE_LINKED, QH_STATE_UNLINK or > QH_STATE_UNLINK_WAIT to clear. Yes. That's an interrupt-driven event. But why is ehci_endpoint_disable() running? Isn't the serial device full speed? Are you attaching it behind a high-speed hub? > It could also be that the open simply caused more USB traffic - I > suspect that perhaps _some_ of the URBs simply get stuck on this HC > (with likelihood higher with an opened device due to higher traffic). > And thus some URBs remain in-flight and the USB stack is unable to do > a proper shutdown. That could be the case. Can you get a usbmon trace? It will show all the URBs. (See Documentation/usb/usbmon.txt.) Start the trace before you plug in the device. > However so far I haven't managed to make it hang by simply plugging/unplugging > (without opening the devices at all)... > > > Note that as an alternate debug attempt, using an USB audio card > and opening the mixer device does NOT cause the unplug to get stuck. > And also note than on ohci/x86 there's no such issue, on 2.6.32.1. > (neither on 2.6.31.6 uhci/x86). That's good to hear. :-) > Thus I'm currently suspecting operation of the ohci-ssb / ehci-ssb > drivers (or remaining problems with silicon bugs there). Or some other platform-specific part of the system. > ohci-ssb / ehci-ssb drivers are daisy-chained in a weird way, > since there's only one base SSB bus device, thus ohci needs to co-maintain > (launch) its ehci brother. And both drivers use IRQF_DISABLED | IRQF_SHARED > (resulting in sitting on the same IRQ, 6, without any other devices). > > I've been testing several things in the ftdi_sio area before > (such as reset timing etc. or calling usb_clear_halt() etc.), > but so far everything certainly points away from ftdi_sio and towards HC issues > (especially since the pl2303 driver locks up, too). > Hmm - or is it a problem on the usb-serial level? Not if you're getting stuck in ehci_endpoint_disable(). > Interchanging various active/passive hubs etc. doesn't really change matters... > > And the register set with or without open (and thus broken plugging) > remains very similar, only the counter values are changed when diffing: > > /debug/usb/ohci# cat ssb0\:1/registers > bus ssb, device ssb0:1 > SSB OHCI Controller > ohci_hcd > OHCI 1.0, NO legacy support registers > control 0x083 HCFS=operational CBSR=3 > cmdstatus 0x00000 SOC=0 > intrstatus 0x00000024 FNO SF > intrenable 0x8000005a MIE RHSC UE RD WDH > ed_controlhead 01ddb000 > hcca frame 0x91ff > fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf > fmremaining 0x80001ab9 FRT FR=0x1ab9 > periodicstart 0x2a2f > lsthresh 0x0628 > hub poll timer off > roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2) > roothub.b 00000000 PPCM=0000 DR=0000 > roothub.status 00008000 DRWE > roothub.portstatus [0] 0x00000100 PPS > roothub.portstatus [1] 0x00000100 PPS What about the other files in that directory? And if EHCI really is the problem then you should be looking in the /debug/usb/ehci directory. > Another (albeit isolated) interesting fact is that cat /dev/ttyUSB0 on > the pl2303 driver will sit there and keep reading, > whereas the same thing on ftdi_sio driver (no matter which adapter) > will return immediately (tty stuff I guess, not USB). Probably. > Now the entire dmesg log of a successful USB pull: > hub 2-1.1:1.0: state 7 ports 7 chg 0000 evt 0040 > hub 2-1.1:1.0: port 6, status 0100, change 0001, 12 Mb/s > usb 2-1.1.6: USB disconnect, address 8 > usb 2-1.1.6: unregistering device > usb 2-1.1.6: usb_disable_device nuking all URBs > usb 2-1.1.6: unregistering interface 2-1.1.6:1.0 ... > In case of an open()ed driver, it would have gotten stuck directly after the > usb 2-1.1.6: usb_disable_device nuking all URBs > line, with any subsequent device plug remaining unsuccessful, no matter which device class. > (NOTE that an existing usb-storage device remains functional all the time!) > > Any idea what to do next? > I could instrument the QH_STATE_LINKED / QH_STATE_UNLINK / QH_STATE_UNLINK_WAIT > thing, but on that router every change is quite a bit more painful than on x86... Let's begin with the usbmon trace and the contents of the files in /debug/usb/ehci/ssb0:whatever. Alan Stern -- 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
