Re: [RFC 2/3] mei: unstaging mei driver

[Alan Cox <alan@xxxxxxxxxxxxxxx>]

On Thu, 29 Mar 2012 20:24:15 +0000
"Winkler, Tomas" <tomas.winkler@xxxxxxxxx> wrote:

> > > > > Anyway, sorry, but the request still stands, I would like to
> > > > > see Alan's or other core kernel developers at Intel's acks on
> > > > > this before I will move it out of staging.
> > > >
> > > > Sure, this is understandable.  Alan is involved so I will check
> > > > where this stands.
> > >
> > >
> > > It looks like Alan was too busy  with his other tasks in order to
> > > review the code.
> > 
> > I gave it a first spin today on a T61 with Fedora 15
> 
> Thanks for trying this,  this is with current staging-next tree,
> right? 
> > - the userspace lms code didn't build but adding a missing include
> >   <cstdio> fixed that trivially
> 
> Can you tell me where did you get LMS from?

The URL given in the doc in the mei directory. When I have a moment
I'll send you a patch to fix the missing include.

> 
> > 
> > - the kernel side seems a bit more broken however
> > 
> > mei 0000:00:03.0: setting latency timer to 64 mei 0000:00:03.0: irq
> > 49 for MSI/MSI-X
> > 
> > and when I tried opening it I get the following spew and an error
> > of - ENODEV.
> 
> When you say opening... what do you refer to exactly?
> 
> 
> > ======================================================
> > [ INFO: possible circular locking dependency detected ]
> > 3.3.0-next-20120328 #1 Tainted: G         C
> 
> I've just run full validation cycle on this last week but I've never
> seen this one. I will try to reproduce with lockdep enabled.

The watchdog register takes the misc device lock which means you've got
a lock ordering bug and it looks like a correct lockdep error to me.

I generally do my validations with an SMP kernel, lockdep, and the
various memory debugging options on.

Alan
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel