Alan and Greg, Appreciate your quick feedback. I guess even if I could fix dead lock with other APIs like spin_is_locked(), it will just make code convoluted. I don't think there is a solution either. Thanks lot for the help! On Thu, Oct 4, 2012 at 10:24 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Oct 04, 2012 at 12:52:24PM -0400, Alan Stern wrote: >> 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. > > Yes, I agree, never try to debug the USB subsystem, while using the USB > subsystem, doing that usually ends up in buffer overflows and endless > loops. > > greg k-h -- 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
