Jarek Poplawski wrote:

On Wed, Jan 03, 2007 at 09:07:11AM +0100, Jarek Poplawski wrote:
  

quoted

On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
    

quoted

I've looked at this a little too -- it'd be nice to know who holds
the write lock.
      

If you mean mc_list_lock - probably nobody - it's
not initialized (so the timers) for this in_device
    

I should say: "... probably not initialized ...".
  

That should print out the debugging when you access an un-initialized 
lock, and I did not
see that print-out in the logs.   I looked at the code and could not 
explain how it could
be accessed un-initialized, so I'm not certain this is the problem.

If I can reproduce this in a controlled manner, I'll add debugging to 
print out who is holding
the lock (if anyone), as well as make sure it is initialized before the 
blocking method initializes
it.  It will likely be a few days before we can set up something to 
reproduce it, however.

If you can explain any code path that could leave the lock 
uninitialized, then that would be a
big help...but it looked ok to me...

Ben

Jarek P. 
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

-- 
Ben Greear [off-list ref] 
Candela Technologies Inc  http://www.candelatech.com