Messages in this thread | | | Date | Sat, 7 Jul 2012 08:39:49 +1000 | From | NeilBrown <> | Subject | Infinite looping in omap2430.c USB driver |
| |
Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`
omap2430_musb_set_vbus in omap2430.c contains:
while (musb_readb(musb->mregs, MUSB_DEVCTL) & 0x80) {
cpu_relax();
if (time_after(jiffies, timeout)) { dev_err(musb->controller, "configured as A device timeout"); ret = -EINVAL; break; } }
having set unsigned long timeout = jiffies + msecs_to_jiffies(1000);
so it can busy-loop for up to 1 second. Probably not ideal, but if it works I wouldn't complain.
The if (int_usb & MUSB_INTR_SESSREQ) { branch of musb_stage0_irq() called from musb_interrupt (from generic_interrupt) calls this:
if (musb->int_usb) retval |= musb_stage0_irq(musb, musb->int_usb, devctl, power);
so the busy loop can happen in an interrupt handler (not a threaded interrupt handler), which is probably less ideal.
However this can be called with interrupt disabled, as happens at least during resume when resume_irqs() calls:
raw_spin_lock_irqsave(&desc->lock, flags); __enable_irq(desc, irq, true); raw_spin_unlock_irqrestore(&desc->lock, flags);
and an interrupt is found to be IRQS_PENDING.
In this case interrupts are disabled so 'jiffies' never changes so this loop can continue forever.
This happens on my (GTA04) phone fairly regularly - between 1 in 10 and 1 in 30 resumes. The musb-hdrc interrupt is pending and reports
[ 4957.624176] musb-hdrc musb-hdrc: ** IRQ peripheral usb0040 tx0000 rx0000
'usb0040' is MUSB_INTR_SESSREQ. I think this is triggered by detecting a voltage change on the USB ID pin - is that right? A short-to-earth would be a request to switch to host mode, which is why it tries to enable VBUS. Maybe there is some electrical noise which is being picked up?
In any case I get the interrupt despite nothing being plugged in, and the 0x80 bit of MUSB_DEVCTL never gets cleared.
I've added a simple loop counter which aborts the loop after 1000 loops - this takes about 5 seconds, but includes some printks which probably slow it down.
In 2 out of 2 cases, subsequent messages show that the hsmmc driver for the uSD card that holds my root filesystem is messed up. It seems to be waiting for a request that is never going to complete. So maybe the hsmmc is causing the noise that triggers the musb issue.
I can send a patch which add a loop count if you like, but I suspect you can come up with a much better approach.
Thanks, NeilBrown [unhandled content-type:application/pgp-signature]
| |