Jarek Poplawski wrote:
On Wed, Jan 03, 2007 at 09:07:11AM +0100, Jarek Poplawski wrote:
On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
