Am Samstag, den 15.02.2014, 02:33 +0100 schrieb Thomas Gleixner: > On Fri, 14 Feb 2014, Stefani Seibold wrote: > > Am Freitag, den 14.02.2014, 10:32 -0500 schrieb Alan Stern: > > > On Fri, 14 Feb 2014, Stefani Seibold wrote: > > > > > > > Hi Alan; > > > > > > > > Am Donnerstag, den 13.02.2014, 15:55 -0500 schrieb Alan Stern: > > > > > > > > > Stefani, please try the patch below, with "threadirq" and the plain > > > > > vanilla kernel. It ought to fix your problem, but let's make certain. > > > > > > > > I tried the patch on 3.13.2 together with the commit 88ed9fd50e57 and it > > > > seems that it solves the problem. > > > > > > > > I also tried the current 3.14.0-rc2-00271-g4675348 without any > > > > modifications and without our patch... and it also works. > > > > > > 3.14-rc2 works with no modifications at all? Then it looks like the > > > patch is unnecessary. > > > > > > But I'm surprised that it works. As far as I know, there haven't been > > > any changes since 3.13 that would fix this problem. > > > > > > > I surprised too. I think it is a kind of race condition and IMHO the > > patch is necessary. > > Lockdep does not care about race conditions and humble opinions at > all. It observes that one place takes the lock with interrupts enabled > and the other takes it in hardirq context. It's that simple. > > So now the question is why one kernel triggers the lockdep warning and > a later version does not while all involved parties claim that nothing > has changed. > > Before we jump into detailed analysis, let's make sure that this > happens > > - with the same .config (i.e. lockdep and the device driver in > question enabled) > > - the same system (i.e. the same drivers loaded and handling the same > devices) > > - the device driver actually doing something which might cause > lockdep to yell. > > When this is the case, then the claim that nothing has changed is > simply wrong and we need to figure out which allegedly unrelated > change has caused this change in behaviour. > > The patch is needed from a code analysis POV. I've been wrong before, > but you really need to provide evidence why 3.14-rc2 does not show the > behaviour and which change has caused that before I'm going to back > off. IMHO is not a convincing argument! > I have cross tested Alan's patch again with kernel 3.13.2 and the current 3.14-rc2. I have now exactly the same .config, the same system and the same kernel cmdline. A kernel 3.13.2 without Alan's patch freeze when accessing a USB flash memory connect to the EHCI. With this patch everything is fine. The current 3.14-rc2 freeze also when the patch is not applied. With this patch it works. The reason that my first test show a different behaviour on the 3.14 kernel was that the cmdline was missing the threadirq, because the boot loader was missconfigured. So i will give an ACK for the patch. - Stefani -- 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
