Hi Alan, On Thu, May 14, 2015 at 10:52 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 14 May 2015, Petri Gynther wrote: > >> linux-usb: >> >> I'm seeing the following recursive locking issue in Linux 3.19 USB stack. >> >> This happens on every boot on BCM7xxxx (MIPS) STB board with Dell 30" >> monitor's built-in USB hub connected to the BCM7xxx USB port. >> >> I think the problem is: >> ehci_irq() >> spin_lock_irqsave(&ehci->lock, flags); >> ... >> if (bh) ehci_work (ehci); >> ... >> hub_irq() >> ehci_urb_enqueue() >> intr_submit() >> spin_lock_irqsave (&ehci->lock, flags); >> >> I can't test the 4.1-rc code immediately, but looking at the code, the >> same issue is present there. >> >> Any suggestions on how to fix this? > > The trick here is that hub_irq() and all the stuff beneath it is > supposed to execute in a tasklet, not in the same context as > ehci_irq(). Consequently the lock should not be taken recursively. > > Perhaps your EHCI platform driver has forgotten to include the HCD_BH > bit in the .flags member of its hc_driver structure. Which driver are > you using? Running "grep EHCI" on the kernel config file should > provide the answer. > Thanks for your reply. The flag HCD_BH was indeed missing from our driver (echi-brcm, not in upstream), and adding it fixes the problem. Having said that -- adding HCD_BH effectively masks this recursive locking problem. Perhaps it is still worth fixing, so that drivers could operate without HCD_BH? > 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
