On Thu, 4 Oct 2012, jx chang wrote: > Hi, all, > > Recently I get a dead lock in ehci_hcd and hope someone can look at my analysis. > > The symptom is: > > When I set loglevel=8 in command line and set console=ttyUSB0, > 115200n8..., and connect a usb-serial adapter to my target device (a > tablet running kernel 3.5.3 with several other changes but I guess > ehci parts should be same as mainstream), the device is dead withing > several seconds after reboot. > > I wrote a small program in user space to dump to disk and enabled > several debug options in kernel configuration. > > The result is the dead lock caught in ehci_hcd as below backtrace > shows. My analysis is when a function driver submits a urb to ehci_hcd > in a process, it will finally grab the spin lock "ehci->lock" in > functions called by ehci_urb_enqueue() to do the job, but it seems > some lower layer will print out echi's debug information in the > further steps. If console is set to a usb-serial adapter and loglevel > is big enough to allow these debug messages out, the prink() just > output log to the user-serial module which should be a function driver > based on ehci_hcd stack. Then a new sequence of urb submitting starts > and calls the same ehci_urb_enqueue() again. The result is the same > process will try to get the ehci->lock it has held. > > Does my analysis make sense? any good solutions if it is so? Yep, that sounds right. The solution is: Don't do that! USB doesn't make for a very good console device (Greg KH is fond of pointing out that the original version was written late one night as the result of a drunken bet). The same deadlock will occur no matter which USB host controller driver you use, by the way. There's nothing special about ehci-hcd. 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
