On Wed, 12 Feb 2014, Alan Stern wrote:
> I have no idea what might have changed between 3.12 and 3.13 to cause
> this problem. Maybe Thomas can figure it out.
>
> > And yes, the issues goes away when no thread irqs are used (with and
> > without the patch).
>
> Thomas, there must be some reason why the patch below is wrong, but I
> don't know enough about the IRQ subsystem to tell what's really going
> on. Can you explain it?
If we force all interrupts into threading, then there is no reason to
disable interrupts and lockdep should not complain at all because all
accesses happen in thread context.
Now the ehci case is different:
The hrtimer callback (ehci_hrtimer_func) still runs from hard
interrupt context and is of course taking the lock which in turn
causes lockdep to yell.
So the local_irq_save() in the usb interrupt handler was hiding the
issue so far. That's why reverting 88ed9fd50e cures it.
On RT we cure it differently as we move all hrtimers which are not
explicitely marked as hardirq safe into the threaded softirq context.
Not sure what's the best solution to solve this, but I really want to
avoid the general interrupt disable in the forced threaded mode.
The simple solution is of course to take the lock in ehci_irq with
spin_lock_irqsave(), but it's not that pretty either ...
Thanks,
tglx
--
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
