From: "Michael S. Tsirkin"
Date: Thu, 7 May 2020 03:25:56 -0400
> When we fill up a receive VQ, try_fill_recv currently tries to count
> kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that
> uses a seqcount. sequence counts are "lock" constructs where you need to
> make sure th
When we fill up a receive VQ, try_fill_recv currently tries to count
kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that
uses a seqcount. sequence counts are "lock" constructs where you need to
make sure that writers are serialized.
In turn, this means that we mustn't run two tr
From: "Michael S. Tsirkin"
Date: Tue, 5 May 2020 20:01:31 -0400
> - u64_stats_update_end(&rq->stats.syncp);
> + u64_stats_update_end_irqrestore(&rq->stats.syncp);
Need to pass flags to this function.
On 2020/5/6 上午8:01, Michael S. Tsirkin wrote:
When we fill up a receive VQ, try_fill_recv currently tries to count
kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that
uses a seqcount. sequence counts are "lock" constructs where you need to
make sure that writers are serialize
When we fill up a receive VQ, try_fill_recv currently tries to count
kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that
uses a seqcount. sequence counts are "lock" constructs where you need to
make sure that writers are serialized.
In turn, this means that we mustn't run two tr
On Sun, Feb 17, 2019 at 06:55:39PM +0100, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:27:32PM +, Russell King wrote:
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.20.0+ #302 Not tainted
> > ---
On Sun, Feb 17, 2019 at 04:27:32PM +, Russell King wrote:
> ==
> WARNING: possible circular locking dependency detected
> 4.20.0+ #302 Not tainted
> --
> systemd-udevd/160 is trying to acquir
On Sun, Feb 17, 2019 at 06:00:24PM +0100, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:51:40PM +, Russell King - ARM Linux admin
> wrote:
> > On Sun, Feb 17, 2019 at 05:46:29PM +0100, Andrew Lunn wrote:
> > > On Sun, Feb 17, 2019 at 04:27:32PM +, Russell King wrote:
> > > >
Hi Russell,
On 2/17/2019 8:27 AM, Russell King wrote:
> ==
> WARNING: possible circular locking dependency detected
> 4.20.0+ #302 Not tainted
> --
> systemd-udevd/160 is trying to acquire lock:
On Sun, Feb 17, 2019 at 04:51:40PM +, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 05:46:29PM +0100, Andrew Lunn wrote:
> > On Sun, Feb 17, 2019 at 04:27:32PM +, Russell King wrote:
> > > ==
> > > WARNING: possible circu
On Sun, Feb 17, 2019 at 05:46:29PM +0100, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:27:32PM +, Russell King wrote:
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.20.0+ #302 Not tainted
> > ---
On Sun, Feb 17, 2019 at 04:27:32PM +, Russell King wrote:
> ==
> WARNING: possible circular locking dependency detected
> 4.20.0+ #302 Not tainted
> --
Hi Russell
Thanks for turning this in
==
WARNING: possible circular locking dependency detected
4.20.0+ #302 Not tainted
--
systemd-udevd/160 is trying to acquire lock:
edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
b
From: Jon Maloy
Date: Mon, 26 Nov 2018 12:26:14 -0500
> We see the following lockdep warning:
...
> The reason is that the node timer handler sometimes needs to delete a
> node which has been disconnected for too long. To do this, it grabs
> the lock 'node_list_lock', whic
We see the following lockdep warning:
[ 2284.078521] ==
[ 2284.078604] WARNING: possible circular locking dependency detected
[ 2284.078604] 4.19.0+ #42 Tainted: GE
[ 2284.078604
On 02/22/2018 07:10 PM, Yonghong Song wrote:
> Commit 9a3efb6b661f ("bpf: fix memory leak in lpm_trie map_free callback
> function")
> fixed a memory leak and removed unnecessary locks in map_free callback
> function.
> Unfortrunately, it introduced a lockdep warning.
From: Yonghong Song
Date: Thu, 22 Feb 2018 10:10:35 -0800
> Commit 9a3efb6b661f ("bpf: fix memory leak in lpm_trie map_free callback
> function")
> fixed a memory leak and removed unnecessary locks in map_free callback
> function.
> Unfortrunately, it introduced a lock
On Thu, 2018-02-22 at 10:10 -0800, Yonghong Song wrote:
> Commit 9a3efb6b661f ("bpf: fix memory leak in lpm_trie map_free callback
> function")
> fixed a memory leak and removed unnecessary locks in map_free callback
> function.
> Unfortrunately, it introduced a lock
Commit 9a3efb6b661f ("bpf: fix memory leak in lpm_trie map_free callback
function")
fixed a memory leak and removed unnecessary locks in map_free callback function.
Unfortrunately, it introduced a lockdep warning. When lockdep checking is
turned on,
running tools/testing/sel
troduced a lockdep warning. When lockdep checking is
turned on,
running tools/testing/selftests/bpf/test_lpm_map will have:
[ 98.294321] =
[ 98.294807] WARNING: suspicious RCU usage
[ 98.295359] 4.16.0-rc2+ #193 Not tainted
[
Hi Yonghong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf/master]
url:
https://github.com/0day-ci/linux/commits/Yonghong-Song/bpf-fix-rcu-lockdep-warning-for-lpm_trie-map_free-callback/20180222-202658
base: https://git.kernel.org/pub/scm/linux
On Wed, 2018-02-21 at 22:38 -0800, Yonghong Song wrote:
> Commit 9a3efb6b661f ("bpf: fix memory leak in lpm_trie map_free callback
> function")
> fixed a memory leak and removed unnecessary locks in map_free callback
> function.
> Unfortrunately, it introduced a lock
Commit 9a3efb6b661f ("bpf: fix memory leak in lpm_trie map_free callback
function")
fixed a memory leak and removed unnecessary locks in map_free callback function.
Unfortrunately, it introduced a lockdep warning. When lockdep checking is
turned on,
running tools/testing/sel
From: Jack Morgenstein
In the mac and vlan register/unregister/replace functions, the driver locks
the mac table mutex (or vlan table mutex) on both ports.
We move to use mutex_lock_nested() to prevent warnings, such as the one below.
[ 101.828445] =
Em 02-11-2015 22:38, Cong Wang escreveu:
On Mon, Nov 2, 2015 at 1:31 PM, Cong Wang wrote:
Good catch!
This is probably introduced by:
commit baf606d9c9b12517e47e0d1370e8aa9f7323f210
Author: Marcelo Ricardo Leitner
Date: Wed Mar 18 14:50:42 2015 -0300
ipv4,ipv6: grab rtnl before lock
On Mon, Nov 2, 2015 at 1:31 PM, Cong Wang wrote:
>
> Good catch!
>
> This is probably introduced by:
>
> commit baf606d9c9b12517e47e0d1370e8aa9f7323f210
> Author: Marcelo Ricardo Leitner
> Date: Wed Mar 18 14:50:42 2015 -0300
>
> ipv4,ipv6: grab rtnl before locking the socket
>
> I am think
On Mon, Nov 2, 2015 at 7:22 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with syzkaller inside a KVM tools guest running the latest
> -next, I saw
> the following warning:
>
> [ 2391.993558] ==
> [ 2391.995441] [ INFO: possible circular lo
Hi all,
While fuzzing with syzkaller inside a KVM tools guest running the latest -next,
I saw
the following warning:
[ 2391.993558] ==
[ 2391.995441] [ INFO: possible circular locking dependency detected ]
[ 2391.995771] 4.3.0-rc6-next-20151022
Hi all,
I'm seeing a lockdep warning that was introduced in 869e7c624 ("net: af_unix:
implement stream sendpage support"):
[377296.160447] ==
[377296.160449] [ INFO: possible circular locking dependency detected ]
[377296.160455]
From: Dmitry Torokhov
Dynamically allocated sysfs attributes should be initialized with
sysfs_attr_init() otherwise lockdep will be angry with us:
[ 45.468653] BUG: key ffc030fad4e0 not in .data!
[ 45.468655] [ cut here ]
[ 45.468666] WARNING: CPU: 0 PID: 1176 a
On Mon, Jul 13, 2015 at 08:02:36AM -0700, Dmitry Torokhov wrote:
> On Mon, Jul 13, 2015 at 6:20 AM, Pablo Neira Ayuso
> wrote:
> > On Thu, Jul 09, 2015 at 05:15:01PM -0700, Dmitry Torokhov wrote:
> >> Dynamically allocated sysfs attributes should be initialized with
> >> sysfs_attr_init() otherwi
On Mon, Jul 13, 2015 at 6:20 AM, Pablo Neira Ayuso wrote:
> On Thu, Jul 09, 2015 at 05:15:01PM -0700, Dmitry Torokhov wrote:
>> Dynamically allocated sysfs attributes should be initialized with
>> sysfs_attr_init() otherwise lockdep will be angry with us:
>>
>> [ 45.468653] BUG: key ffc030fa
On Thu, Jul 09, 2015 at 05:15:01PM -0700, Dmitry Torokhov wrote:
> Dynamically allocated sysfs attributes should be initialized with
> sysfs_attr_init() otherwise lockdep will be angry with us:
>
> [ 45.468653] BUG: key ffc030fad4e0 not in .data!
> [ 45.468655] [ cut here ]
Dynamically allocated sysfs attributes should be initialized with
sysfs_attr_init() otherwise lockdep will be angry with us:
[ 45.468653] BUG: key ffc030fad4e0 not in .data!
[ 45.468655] [ cut here ]
[ 45.468666] WARNING: CPU: 0 PID: 1176 at
/mnt/host/source/src/
From: Andy Gospodarek
Date: Fri, 26 Jun 2015 19:37:11 -0400
> The following lockdep splat was seen due to the wrong context for
> grabbing in_dev.
...
> This patch resolves that splat.
>
> Signed-off-by: Andy Gospodarek
> Reported-by: Sergey Senozhatsky
Applied, thanks Andy.
--
To unsubscrib
The following lockdep splat was seen due to the wrong context for
grabbing in_dev.
===
[ INFO: suspicious RCU usage. ]
4.1.0-next-20150626-dbg-00020-g54a6d91-dirty #244 Not tainted
---
include/linux/inetdevice.h:205 suspicious rcu_dereference
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > > Any chance that
> > > git revert 69cc64d8d92
> > > makes this report go away?
> I've tested the patch and I no longer get that lock thing in my syslog.
Thanks for verification.
Hmm, I don't immediately see how this patch could make neigh->loc
[EMAIL PROTECTED] said:
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
I've tested the patch and I no longer get that lock thing in my syslog.
/A
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTE
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > This needs to be CCed to netdev.
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
> I'll have to install a git repo to check, or maybe you can send me the diff
> to
> reverse vs. 2.6.25-rc2?
diff --git a/net/core/
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> I found this is a newly booted 2.6.25-rc2's syslog.
> Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633,
> d2c04084
> Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3
> Feb 21 20:46:33 tippex [] r
Hello,
After using "Lock debugging: prove locking correctness" with the Kernel I
got this warning:
=
[ INFO: inconsistent lock state ]
2.6.24-dg8ngn-p02 #1
-
inconsistent {softirq-on-W} -> {in-softirq-R} usage.
linuxnet/3046 [HC0[0]:
On Jan 24, 2008 5:25 PM, Dave Young <[EMAIL PROTECTED]> wrote:
>
> On Jan 24, 2008 11:02 AM, Dave Young <[EMAIL PROTECTED]> wrote:
> > =
> > [ INFO: possible recursive locking detected ]
> > 2.6.24-rc8-mm1 #8
> > --
On Jan 24, 2008 11:02 AM, Dave Young <[EMAIL PROTECTED]> wrote:
> =
> [ INFO: possible recursive locking detected ]
> 2.6.24-rc8-mm1 #8
> -
> bluepush/3213 is trying to acquire lock:
> (sk_lock-AF_BLUETOOTH){--
=
[ INFO: possible recursive locking detected ]
2.6.24-rc8-mm1 #8
-
bluepush/3213 is trying to acquire lock:
(sk_lock-AF_BLUETOOTH){--..}, at: []
l2cap_sock_bind+0x40/0x100 [l2cap]
but task is already holding
I'm getting this on current -git after adding an obexfs mount
to my fstab:
=
[ INFO: possible recursive locking detected ]
2.6.22-rc6 #2
-
obexfs/3786 is trying to acquire lock:
(sk_lock-AF_BLUETOOTH){--..}, a
On Tue, May 15, 2007 at 11:17:51PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 16 May 2007 08:17:32 +0200
>
> > BTW - I think some patch on vlan cannot do any harm (at
> > least like this previous of mine - with only ppp
> > considered), and maybe this all c
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Wed, 16 May 2007 08:17:32 +0200
> BTW - I think some patch on vlan cannot do any harm (at
> least like this previous of mine - with only ppp
> considered), and maybe this all could be forgotten.
Let's wait to see if any new messages show up.
I thin
On Tue, May 15, 2007 at 10:47:25PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 16 May 2007 07:40:00 +0200
>
> > After initializing dev->_xmit_lock register_netdevice()
> > sets lockdep class according to dev->type.
> >
> > Idea of this patch - by David Mill
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Wed, 16 May 2007 07:40:00 +0200
> After initializing dev->_xmit_lock register_netdevice()
> sets lockdep class according to dev->type.
>
> Idea of this patch - by David Miller.
>
> Reported & tested by: "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
> S
On Tue, May 15, 2007 at 12:49:47PM +0400, Yuriy N. Shkandybin wrote:
> I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
>
So, you mean only this one patch - without previous vlan patch?
Very interesting...
Thanks once more,
Jarek P.
-
To unsubscribe from this list: send the
Sorry - I've fogotten about something very important!
(Plus a small change in the diff.)
Jarek P.
---> (take 2)
After initializing dev->_xmit_lock register_netdevice()
sets lockdep class according to dev->type.
Idea of this patch - by David Miller.
Reported & tested by: "Yuriy N. Shkandybin" <
On Tue, May 15, 2007 at 12:49:47PM +0400, Yuriy N. Shkandybin wrote:
> I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
>
> Jura
Many thanks, Jura!
It seems reality is sometimes merciful...
On the other hand I wonder, how all this could stay so long:
a configuration similar
MAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, May 15, 2007 9:31 AM
Subject: [PATCH] netdev: lockdep classes in register_netdevice Re: [patch
04/13] ppp_generic: fix lockdep warning
On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
From: Jarek Poplawski <[EMAIL PR
MAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, May 15, 2007 9:31 AM
Subject: [PATCH] netdev: lockdep classes in register_netdevice Re: [patch
04/13] ppp_generic: fix lockdep warning
On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
From: Jarek Poplawski <[EMAIL PR
On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 08:07:00 +0200
>
> > After sending this patch I was a little confused, when next
> > lockdep warning report appeared, and I thought - si
On Mon, May 14, 2007 at 10:08:29AM +0200, Jarek Poplawski wrote:
> On Mon, May 14, 2007 at 09:28:45AM +0200, Jarek Poplawski wrote:
> > On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
> ...
> > > For each unique netdev type, use a different locking class.
> > >
> > > That will fix th
On Mon, May 14, 2007 at 02:18:31AM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 09:28:45 +0200
>
> > Yes, this is very good idea, and I wonder, why you didn't try
> > this yourself (after my "ignore").
>
> Because you are a skilled programmer and
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Mon, 14 May 2007 09:28:45 +0200
> Yes, this is very good idea, and I wonder, why you didn't try
> this yourself (after my "ignore").
Because you are a skilled programmer and you might find some
flaw in my suggestion :-)
-
To unsubscribe from this li
On Mon, May 14, 2007 at 09:28:45AM +0200, Jarek Poplawski wrote:
> On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
...
> > For each unique netdev type, use a different locking class.
> >
> > That will fix this forever, anything else is a situation specific
> > band-aid (but then agai
On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 08:07:00 +0200
>
> > After sending this patch I was a little confused, when next
> > lockdep warning report appeared, and I thought - si
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Mon, 14 May 2007 08:07:00 +0200
> After sending this patch I was a little confused, when next
> lockdep warning report appeared, and I thought - since this is
> not enough, this patch could be dumped. But now I changed my
> mind
applied
> >
> > I was under the impression that this patch didn't actually fix the
> > problem yet? I might be thinking about something else...
>
> yeah, sorry, it seems that the discussion is ongoing. Please drop the
> patch. I did.
>
After sending this patc
On Fri, 11 May 2007 14:03:09 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Fri, 11 May 2007 16:57:19 -0400
>
> > applied
>
> I was under the impression that this patch didn't actually fix the
> problem yet? I might be thinking about somethin
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 11 May 2007 16:57:19 -0400
> applied
I was under the impression that this patch didn't actually fix the
problem yet? I might be thinking about something else...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a m
applied
-
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
Hi,
Read below, please:
On Thu, May 10, 2007 at 12:06:09AM +0400, Yuriy N. Shkandybin wrote:
> After applying this patch i've got this:
>
> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-gentoo #2
> -
le (delta = 4686844667 ns)
> Time: acpi_pm clocksource has been installed.
...
lockdep has seen locks "-> #0" - "-> #3" taken in circular order, but IMHO,
lock "-> #3" (&pch->downl) taken after "-> #2" (&ppp->wlock) differs from
&am
On Thu, May 10, 2007 at 10:03:23AM +0400, Yuriy N. Shkandybin wrote:
> Yes, there is no real lockup with pppoe
> ll repeat my configuration:
> vpn (pptp(mostly)+pppoe) concentrator
> PPPoE provided through 802.1q
> +OSPF (quagga)
I think, it's a little too general... Probably at least
ifconfig and
EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; ;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, May 10, 2007 9:30 AM
Subject: Re: [PATCH] vlan: lockdep subclass for ppp _xmit_lock Re:
ppp_generic: fix lockdep warning
On Thu, May 10, 2007 at 12:06:09AM +0400, Yuriy N. Shkandybin wrote:
> After applying this patch i've got this:
>
> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-gentoo #2
> ---
[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2007 1:35 PM
Subject: [PATCH] vlan: lockdep subclass for ppp _xmit_lock Re: ppp_generic:
fix lockdep warning
On Thu, Apr 26, 2007 at 12:49:50PM +0200, Jarek Poplawski wrote:
...
But there is also a second, very similar
On Wed, May 09, 2007 at 02:32:24AM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 9 May 2007 11:35:37 +0200
>
> > After rethinking there is the 3-rd way (as usual):
> >
> > c) vlan should use different lockdep lock subclasses or
> > classes for different types
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Wed, 9 May 2007 11:35:37 +0200
> After rethinking there is the 3-rd way (as usual):
>
> c) vlan should use different lockdep lock subclasses or
> classes for different types of devices, used at the same
> time.
Perhaps we should just bite the bulle
On Thu, Apr 26, 2007 at 12:49:50PM +0200, Jarek Poplawski wrote:
...
> But there is also a second, very similar lockdep report,
> probably also false (lockdep cannot see the difference
> between locks of two different, I hope, vlan devices),
> which needs more work:
> a) vlan should use different l
gt;
> > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
> > Cc: Paul Mackerras <[EMAIL PROTECTED]>
> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> > ---
> >
> > drivers/net/ppp_generic.c |6 --
> > 1 file changed, 4 ins
On Thu, Apr 26, 2007 at 01:39:11AM -0700, David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Thu, 26 Apr 2007 00:27:29 -0700
>
> > lockdep has seen locks "-> #0" - "-> #3" taken in circular order, but IMHO,
> > lock "-> #3" (&pch->downl) taken after "-> #2" (&ppp->wlock) differs from
> > &pch->
TECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> drivers/net/ppp_generic.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN drivers/net/ppp_generic.c~ppp_generic-fix-lockdep-warning
> drivers/net/ppp_generic.c
From: [EMAIL PROTECTED]
Date: Thu, 26 Apr 2007 00:27:29 -0700
> lockdep has seen locks "-> #0" - "-> #3" taken in circular order, but IMHO,
> lock "-> #3" (&pch->downl) taken after "-> #2" (&ppp->wlock) differs from
> &pch->downl lock taken in "-> #0" (before &vlan_netdev_xmit_lock_key) and
> lock
le (delta = 4686844667 ns)
> Time: acpi_pm clocksource has been installed.
...
lockdep has seen locks "-> #0" - "-> #3" taken in circular order, but IMHO,
lock "-> #3" (&pch->downl) taken after "-> #2" (&ppp->wlock) differs from
&am
On Mon, Mar 19, 2007 at 10:49:12AM +0300, Yuriy N. Shkandybin wrote:
> I've changed kernel to rc4 and completely changed hardware.
> Now this is
>
> I've got new trace, but this is another problem as i can see and connected
> with pppoe
>
> ===
On Thu, Sep 28, 2006 at 07:20:00AM -0700, Stephen Hemminger wrote:
> On Thu, 28 Sep 2006 15:13:01 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> > > [My mail provider is down, so responding "manually"]
> > >
> > > Jarek
On Thu, 28 Sep 2006 15:13:01 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> > [My mail provider is down, so responding "manually"]
> >
> > Jarek Poplawski wrote:
> > > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> >
On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> [My mail provider is down, so responding "manually"]
>
> Jarek Poplawski wrote:
> > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> >
> > Sorry again but I can't abstain from some doubts:
> >
> > ...
> > > diff --git a/net/
[My mail provider is down, so responding "manually"]
Jarek Poplawski wrote:
> > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
>
> Sorry again but I can't abstain from some doubts:
>
> ...
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 14de297..4d891be 100644
> > --- a/net/core/de
On Wed, Sep 27, 2006 at 04:53:04PM -0700, David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Wed, 27 Sep 2006 14:07:04 +0200
...
> Although the HTB bug is post-2.6.18, the other issue has been
> around for a long time.
>
> Thus I'll need to submit the second patch to -stable,
On Wed, Sep 27, 2006 at 02:07:04PM +0200, Patrick McHardy wrote:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely.
> > I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters on
> > inpu
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2006 14:07:04 +0200
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely.
> > I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters
On Wed, Sep 27, 2006 at 02:07:04PM +0200, Patrick McHardy wrote:
> Dave Jones wrote:
> >
> > Call Trace:
> > [] show_trace+0xae/0x336
> > [] dump_stack+0x15/0x17
> > [] :sch_htb:htb_safe_rb_erase+0x3b/0x55
>
> I found the reason for this, it was an unrelated bug. I've attached
> the l
27 Eyl 2006 Çar 15:07 tarihinde, Patrick McHardy şunları yazmıştı:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely. I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters on
> > input de
27 Eyl 2006 Çar 13:14 tarihinde şunları yazmıştınız:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely. I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters on
> > input device check on
>
Dave Jones wrote:
> With this patch, I get no lockdep warnings, but the machine locks up
> completely.
> I hooked up a serial console, and found this..
>
>
> u32 classifier
> Performance counters on
> input device check on
> Actions configured
> BUG: warning at net/sched/sch_htb.c:
Dave Jones wrote:
> With this patch, I get no lockdep warnings, but the machine locks up
> completely.
> I hooked up a serial console, and found this..
>
>
> u32 classifier
> Performance counters on
> input device check on
> Actions configured
> BUG: warning at net/sched/sch_htb.c:
Jarek Poplawski wrote:
> Sorry for my not humble and simplistic opinion, but I'd dare
> to remind you are changing "stable" version and even without
> this lockups this patch would look very "serious". Why don't
> try to restore not-rcu version of qdisc_destroy which looks
> not lot to do.
I'm try
On Tue, Sep 26, 2006 at 05:20:34PM -0400, Dave Jones wrote:
> On Tue, Sep 26, 2006 at 06:15:21PM +0200, Patrick McHardy wrote:
> > Patrick McHardy wrote:
> > > jamal wrote:
> > >
> > >>Yes, that looks plausible. Can you try making those changes and see if
> > >>the warning is gone?
> > >
>
On Tue, Sep 26, 2006 at 06:15:21PM +0200, Patrick McHardy wrote:
> Patrick McHardy wrote:
> > jamal wrote:
> >
> >>Yes, that looks plausible. Can you try making those changes and see if
> >>the warning is gone?
> >
> >
> > I think this points to a bigger brokeness caused by the move of
>
Patrick McHardy wrote:
> jamal wrote:
>
>>Yes, that looks plausible. Can you try making those changes and see if
>>the warning is gone?
>
>
> I think this points to a bigger brokeness caused by the move of
> dev->qdisc to RCU. It means destruction of filters and actions doesn't
> necessarily happ
[EMAIL PROTECTED] wrote:
From: Peter Zijlstra <[EMAIL PROTECTED]>
BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted)
Call Trace:
show_trace
dump_stack
trace_hardirqs_on
:forcedeth:nv_nic_irq_other
handle_IRQ_event
__do_IRQ
do_IRQ
ret_from_intr
DWARF2 barf
default_i
--
1 file changed, 17 insertions(+), 14 deletions(-)
diff -puN drivers/net/forcedeth.c~forcedeth-hardirq-lockdep-warning
drivers/net/forcedeth.c
--- a/drivers/net/forcedeth.c~forcedeth-hardirq-lockdep-warning
+++ a/drivers/net/forcedeth.c
@@ -2497,6 +2497,7 @@ static irqreturn_t nv_nic_irq_tx(i
jamal wrote:
> On Mon, 2006-25-09 at 14:43 +0200, Jarek Poplawski wrote:
>
>
>>It's probably 2.6.18 and should change a little now (git4) but
>>IMHO main problem stays: it looks tcf_act_police_locate in
>>act_police.c was preempted in read_lock (tcf_police_lookup)
>>- now the same is possible in
On 25-09-2006 14:47, jamal wrote:
> On Mon, 2006-25-09 at 14:43 +0200, Jarek Poplawski wrote:
>
>> It's probably 2.6.18 and should change a little now (git4) but
>> IMHO main problem stays: it looks tcf_act_police_locate in
>> act_police.c was preempted in read_lock (tcf_police_lookup)
>> - now th
1 - 100 of 107 matches
Mail list logo
