| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: Failed assertion |
| From: | Andrew Morton <andrewm@xxxxxxxxxx> |
| Date: | Tue, 27 Feb 2001 00:52:32 +0000 |
| Cc: | Ralf Baechle <ralf@xxxxxxxxxxx>, Petr Vandrovec <VANDROVE@xxxxxxxxxx>, netdev@xxxxxxxxxxx |
| References: | <86C68935F9@vcnet.vc.cvut.cz> <15002.59255.720093.731878@pizda.ninka.net> <20010227013850.B17836@bacchus.dhis.org> <15002.63280.997712.635900@pizda.ninka.net> |
| Sender: | owner-netdev@xxxxxxxxxxx |
"David S. Miller" wrote:
>
> Ralf Baechle writes:
> > No backtrace, the machine did continue as you'd suspect after a print.
> > The machine is a dual CPU Origin 200 with an IOC3 NIC.
>
> What is your current kernel based upon, some older 2.4.x or
> even 2.3.x variant? Or is it sync'd to current?
Could this be a driver problem? This code:
netif_rx(skb);
ip->rx_skbs[rx_entry] = NULL; /* Poison */
new_skb = ioc3_alloc_skb(RX_BUF_ALLOC_SIZE, GFP_ATOMIC);
if (!new_skb) {
/* Ouch, drop packet and just recycle packet
to keep the ring filled. */
ip->stats.rx_dropped++;
new_skb = skb;
goto next;
}
looks scary. We've passed an skb to the network stack,
but we can continue to make it available to the device
driver at the same time.
I'd suggest a printk() in there, plus perhaps do the
alloc_skb _before_ the netif_rx(). Don't pass the skb
to the stack if it is to be recycled.
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Failed assertion, Ralf Baechle |
|---|---|
| Next by Date: | Re: Failed assertion, David S. Miller |
| Previous by Thread: | Re: Failed assertion, Ralf Baechle |
| Next by Thread: | Re: Failed assertion, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |