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!
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
