Thread (182 messages) 182 messages, 27 authors, 2008-08-01

Re: [crash] kernel BUG at net/core/dev.c:1328!

From: David Miller <davem@davemloft.net>
Date: 2008-07-21 20:11:41
Also in: lkml

From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Mon, 21 Jul 2008 21:20:20 +0200
In the meantime:  Is there perhaps something obviously wrong with 
drivers/ieee1394/eth1394.c's netdevice initialization?  We do it in 
ether1394_add_host(), and shortly thereafter the crashing 
ether1394_host_reset() is called.  So we have essentially

(add host)
	dev = alloc_netdev(...);
	initialize various members in dev...
	register_netdev(dev);

(host reset)
	netif_stop_queue(dev);
	discard some stale 1394 stuff if there were some...
	netif_wake_queue(dev);  <-- crashes in __netif_schedule(dev);
You should only do a netif_stop_queue() in your device
initialization, at the very end of ->open() processing
when you've fully committed to returning success.

You should not, in particular, be doing a netif_wake_queue()
before you've even done a netif_start_queue().

Many of these drivers are using netif_{stop,wake}_queue()
to stop packet flow, in particular when link state changes,
and netif_carrier_{on,off}() already does all of that for
you.

Really, anything outside of:

1) netif_start_queue() in ->open()
2) netif_stop_queue() in ->stop()
3) netif_{stop,wake}_queue() in the TX packet handling path

is superfluous.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help