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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
