Re: Dead lock in ehci hcd (3.5.3) with usb-serial adapters.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dead lock in ehci hcd (3.5.3) with usb-serial adapters.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dead lock in ehci hcd (3.5.3) with usb-serial adapters.
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 gre...@linuxfoundation.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
