* assertion failure at net/sched/sch_generic.c(530)
@ 2003-09-24 0:11 David Brownell
2003-09-24 0:02 ` David S. Miller
0 siblings, 1 reply; 6+ messages in thread
From: David Brownell @ 2003-09-24 0:11 UTC (permalink / raw)
To: netdev
After running some TTCP tests (unidirectional TTCP 9+ hours,
then bidirectional for about 8 hours more) over a network link,
I shut it down the usual way and got an unusual message. I've
never seen this before; this is a recent 2.6.0-test5 BK snapshot
(a few days old):
KERNEL: assertion (dev->qdisc_list == NULL) failed at
net/sched/sch_generic.c(530)
Could someone please translate that for me -- trouble?
The interface was down at that point, and this was evidently
triggered by the unregister_netdev() that "rmmod" caused.
- Dave
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: assertion failure at net/sched/sch_generic.c(530)
2003-09-24 0:11 assertion failure at net/sched/sch_generic.c(530) David Brownell
@ 2003-09-24 0:02 ` David S. Miller
2003-09-24 0:08 ` David S. Miller
0 siblings, 1 reply; 6+ messages in thread
From: David S. Miller @ 2003-09-24 0:02 UTC (permalink / raw)
To: David Brownell; +Cc: hadi, netdev
On Tue, 23 Sep 2003 17:11:22 -0700
David Brownell <david-b@pacbell.net> wrote:
> KERNEL: assertion (dev->qdisc_list == NULL) failed at
> net/sched/sch_generic.c(530)
Crap, I think I know what made this start happening.
Jamal, your pfifo_fast statistics patch added this to
dev_activate() when we decide to add a default discipline:
write_lock(&qdisc_tree_lock);
qdisc->next = dev->qdisc_list;
dev->qdisc_list = qdisc;
write_unlock(&qdisc_tree_lock);
Something probably isn't clearing it later on when we
down the device.
Doesn't the ->reset() operation need to do this list
removal? If so, that's the problem, pfifo_fast_reset()
isn't doing the dev->qdisc_list removal. Actually it seems
like qdisc_destroy() takes care of it.
Or another possibility is that pfifo_fast is being added
twice to the list.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: assertion failure at net/sched/sch_generic.c(530)
2003-09-24 0:02 ` David S. Miller
@ 2003-09-24 0:08 ` David S. Miller
2003-09-24 0:44 ` David Brownell
0 siblings, 1 reply; 6+ messages in thread
From: David S. Miller @ 2003-09-24 0:08 UTC (permalink / raw)
To: David S. Miller; +Cc: david-b, hadi, netdev
On Tue, 23 Sep 2003 17:02:16 -0700
"David S. Miller" <davem@redhat.com> wrote:
> On Tue, 23 Sep 2003 17:11:22 -0700
> David Brownell <david-b@pacbell.net> wrote:
>
> > KERNEL: assertion (dev->qdisc_list == NULL) failed at
> > net/sched/sch_generic.c(530)
>
> Crap, I think I know what made this start happening.
Wait, David do you have CONFIG_NET_SCHED enabled in your
config?
Qdiscs don't get unlinked in qdisc_destroy() unless that config
is enabled. If you have it off, that explains the bug and the
fix is obvious.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: assertion failure at net/sched/sch_generic.c(530)
2003-09-24 0:08 ` David S. Miller
@ 2003-09-24 0:44 ` David Brownell
2003-09-24 0:42 ` David S. Miller
0 siblings, 1 reply; 6+ messages in thread
From: David Brownell @ 2003-09-24 0:44 UTC (permalink / raw)
To: David S. Miller; +Cc: hadi, netdev
>>> KERNEL: assertion (dev->qdisc_list == NULL) failed at
>>> net/sched/sch_generic.c(530)
>>
>>Crap, I think I know what made this start happening.
>
>
> Wait, David do you have CONFIG_NET_SCHED enabled in your
> config?
No ...
> Qdiscs don't get unlinked in qdisc_destroy() unless that config
> is enabled. If you have it off, that explains the bug and the
> fix is obvious.
Well, obvious to people who know that part of the stack ... :)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: assertion failure at net/sched/sch_generic.c(530)
2003-09-24 0:44 ` David Brownell
@ 2003-09-24 0:42 ` David S. Miller
2003-09-24 15:10 ` David Brownell
0 siblings, 1 reply; 6+ messages in thread
From: David S. Miller @ 2003-09-24 0:42 UTC (permalink / raw)
To: David Brownell; +Cc: hadi, netdev
On Tue, 23 Sep 2003 17:44:30 -0700
David Brownell <david-b@pacbell.net> wrote:
> > Qdiscs don't get unlinked in qdisc_destroy() unless that config
> > is enabled. If you have it off, that explains the bug and the
> > fix is obvious.
>
> Well, obvious to people who know that part of the stack ... :)
Honest, it's a pretty simple bug :) Try this patch:
--- net/sched/sch_generic.c.~1~ Tue Sep 23 17:52:22 2003
+++ net/sched/sch_generic.c Tue Sep 23 17:52:28 2003
@@ -416,7 +416,6 @@
dev = qdisc->dev;
-#ifdef CONFIG_NET_SCHED
if (dev) {
struct Qdisc *q, **qp;
for (qp = &qdisc->dev->qdisc_list; (q=*qp) != NULL; qp = &q->next) {
@@ -428,7 +427,6 @@
}
#ifdef CONFIG_NET_ESTIMATOR
qdisc_kill_estimator(&qdisc->stats);
-#endif
#endif
if (ops->reset)
ops->reset(qdisc);
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: assertion failure at net/sched/sch_generic.c(530)
2003-09-24 0:42 ` David S. Miller
@ 2003-09-24 15:10 ` David Brownell
0 siblings, 0 replies; 6+ messages in thread
From: David Brownell @ 2003-09-24 15:10 UTC (permalink / raw)
To: David S. Miller; +Cc: hadi, netdev
David S. Miller wrote:
> Honest, it's a pretty simple bug :) Try this patch:
Yes, I see. The patch resolved this problem.
- Dave
> --- net/sched/sch_generic.c.~1~ Tue Sep 23 17:52:22 2003
> +++ net/sched/sch_generic.c Tue Sep 23 17:52:28 2003
> @@ -416,7 +416,6 @@
>
> dev = qdisc->dev;
>
> -#ifdef CONFIG_NET_SCHED
> if (dev) {
> struct Qdisc *q, **qp;
> for (qp = &qdisc->dev->qdisc_list; (q=*qp) != NULL; qp = &q->next) {
> @@ -428,7 +427,6 @@
> }
> #ifdef CONFIG_NET_ESTIMATOR
> qdisc_kill_estimator(&qdisc->stats);
> -#endif
> #endif
> if (ops->reset)
> ops->reset(qdisc);
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-09-24 15:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-24 0:11 assertion failure at net/sched/sch_generic.c(530) David Brownell
2003-09-24 0:02 ` David S. Miller
2003-09-24 0:08 ` David S. Miller
2003-09-24 0:44 ` David Brownell
2003-09-24 0:42 ` David S. Miller
2003-09-24 15:10 ` David Brownell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).