[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080721.131129.244101157.davem@davemloft.net>
Date: Mon, 21 Jul 2008 13:11:29 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: stefanr@...6.in-berlin.de
Cc: torvalds@...ux-foundation.org, mingo@...e.hu,
akpm@...ux-foundation.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [crash] kernel BUG at net/core/dev.c:1328!
From: Stefan Richter <stefanr@...6.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists