Didnt see the beginings of this thread - please post on netdev instead
of lkml network related questions.
The real cause seems to be an ARP issue from what i saw in the oops
posted a while back:
--
[4294692.342000] Call Trace:
[4294692.342000] [<c0104d76>] show_stack+0xa6/0xe0
[4294692.342000] [<c0104f2b>] show_registers+0x15b/0x1f0
[4294692.342000] [<c01051a1>] die+0x141/0x2d0
[4294692.342000] [<c011e13e>] do_page_fault+0x22e/0x6a6
[4294692.342000] [<c0104817>] error_code+0x4f/0x54
[4294692.342000] [<c04236da>] qdisc_restart+0xba/0x730
[4294692.342000] [<c04136fe>] dev_queue_xmit+0x13e/0x640
[4294692.342000] [<c0454c4c>] arp_solicit+0xfc/0x210
[4294692.342000] [<c041a6ee>] neigh_timer_handler+0x13e/0x320
[4294692.342000] [<c0137450>] run_timer_softirq+0x130/0x490
[4294692.342000] [<c0131ad2>] __do_softirq+0x42/0xa0
[4294692.342000] [<c01066e1>] do_softirq+0x51/0x60
-----
Is this the same issue?
Can you describe how you create this issue; kernel version etc.
cheers,
jamal
On Fri, 2005-15-04 at 17:37 -0400, Steven Rostedt wrote:
> On Thu, 2005-04-14 at 18:46 +0300, Tarhon-Onu Victor wrote:
> > On Tue, 12 Apr 2005, Tarhon-Onu Victor wrote:
> >
> > > So the problem should be looked in that changes to the pkt sched API,
> > > the patch containing only those changes is at
> >
> > The bug is in this portion of code from net/sched/sch_generic.c,
> > in the qdisc_destroy() function:
> >
> > ==
> > list_for_each_entry(cq, &cql, list)
> > list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list)
> > if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) {
> > if (q->ops->cl_ops == NULL)
> > list_del_init(&q->list);
> > else
> > list_move_tail(&q->list, &cql);
> > }
> > list_for_each_entry_safe(cq, n, &cql, list)
> > list_del_init(&cq->list);
> > ==
> >
> > ...and it happens when q->ops->cl_ops is NULL and
> > list_del_init(&q->list) is executed.
> >
> > The stuff from include/linux/list.h looks ok, it seems like one
> > of those two iterations (list_for_each_entry() and
> > list_for_each_entry_safe()) enters an endless loop when an element is
> > removed from the list under some circumstances.
>
> There's a comment above qdisc_destroy that says:
>
> /* Under dev->queue_lock and BH! */
>
> I'm not so sure this is the case. I've included the emails of those
> listed as Authors of sch_generic.c and sch_htb.c, hopefully they are the
> ones who can help (if not, sorry to bother you).
>
> The list.h is fine, but if another task goes down this list when it
> list_del_init is done, there's a chance that the reading task can get to
> the deleted item just as it is being deleted, and has pointed itself to
> itself. p->next == p. This would go into an infinite loop.
>
> The reason sysrq works is because this doesn't stop interrupts. But put
> a local_irq_save around that list and run your test, I bet you won't be
> able to do anything, but power off with the big button.
>
> Hope someone can help. I don't know the queue disciplines well enough to
> make a proper fix.
>
> -- Steve
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
