On Fri, Feb 16, 2007 at 08:06:25AM -0800, Ben Greear wrote:
...
Well, I had lockdep and all of the locking debugging I could find
enabled, but
it did not catch this problem..I had to use sysctl -t and manually dig
through the backtraces
to find the deadlock
It may be that lockdep
On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote:
...
Maybe there should be something like an ASSERT_NOT_RTNL() in the
flush_scheduled_work()
method? If it's performance criticial, #ifdef it out if we're not
debugging locks?
Yes! I thought about the same (at first). But in my
Jarek Poplawski wrote:
On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote:
...
Maybe there should be something like an ASSERT_NOT_RTNL() in the
flush_scheduled_work()
method? If it's performance criticial, #ifdef it out if we're not
debugging locks?
Yes! I thought about the
On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote:
Jarek Poplawski wrote:
On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote:
...
Maybe there should be something like an ASSERT_NOT_RTNL() in the
flush_scheduled_work()
method? If it's performance criticial, #ifdef it
On Fri, Feb 16, 2007 at 10:04:25AM +0100, Jarek Poplawski wrote:
On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote:
...
I don't see how asserting it in the rtnl_lock would help anything,
because at that
point we are about to deadlock anyway... (and this is probably very
rare,
Jarek Poplawski wrote:
On Fri, Feb 16, 2007 at 10:04:25AM +0100, Jarek Poplawski wrote:
On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote:
...
I don't see how asserting it in the rtnl_lock would help anything,
because at that
point we are about to deadlock anyway... (and
On Thu, 15 Feb 2007 23:40:32 -0800
Ben Greear [EMAIL PROTECTED] wrote:
Jarek Poplawski wrote:
On 14-02-2007 22:27, Stephen Hemminger wrote:
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the
Stephen Hemminger wrote:
On Thu, 15 Feb 2007 23:40:32 -0800
Ben Greear [EMAIL PROTECTED] wrote:
Maybe there should be something like an ASSERT_NOT_RTNL() in the
flush_scheduled_work()
method? If it's performance criticial, #ifdef it out if we're not
debugging locks?
You can't safely add
Francois Romieu wrote:
Ben Greear [EMAIL PROTECTED] :
[...]
I seem to be able to trigger this within about 1 minute on a
particular 2.6.18.2 system with some 8139too devices, so if someone
has a patch that could be tested, I'll gladly test it. For
whatever reason, I haven't hit this problem on
On 14-02-2007 22:27, Stephen Hemminger wrote:
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the RTNL mutex. What can happen is that a work queue routine (like
bridge port_carrier_check) is waiting forever
Jarek Poplawski wrote:
On 14-02-2007 22:27, Stephen Hemminger wrote:
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the RTNL mutex. What can happen is that a work queue routine (like
bridge
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the RTNL mutex. What can happen is that a work queue routine (like
bridge port_carrier_check) is waiting forever for RTNL, and the driver
routine has called
Stephen Hemminger wrote:
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the RTNL mutex. What can happen is that a work queue routine (like
bridge port_carrier_check) is waiting forever for RTNL, and the
Ben Greear [EMAIL PROTECTED] :
[...]
I seem to be able to trigger this within about 1 minute on a
particular 2.6.18.2 system with some 8139too devices, so if someone
has a patch that could be tested, I'll gladly test it. For
whatever reason, I haven't hit this problem on 2.6.20 yet, but
that
14 matches
Mail list logo
