Hello,
Yep, that's the problem we're run into as well. We're working on a NAPI
patch for the sb1250-mac.c driver which fixes this - but that's not
quite ready for release yet.
In the meantime, adding the following line manually to net/core/dev.c
(in netif_rx(), right after the enqueue label) appears to suppress the
problem with no ill effects... Note: this is *NOT* a fix, it's a hack.
Please let me know if it works for you.
Thx,
Mark
if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
if (queue->input_pkt_queue.qlen) {
enqueue:
+ netif_rx_schedule(&queue->backlog_dev);
dev_hold(skb->dev);
__skb_queue_tail(&queue->input_pkt_queue, skb);
local_irq_restore(flags);
return NET_RX_SUCCESS;
}
netif_rx_schedule(&queue->backlog_dev);
goto enqueue;
}
> -----Original Message-----
> From: Stuart Anderson [mailto:anderson@xxxxxxxxxxxx]
> Sent: Friday, February 24, 2006 12:03 PM
> To: Mark E Mason
> Cc: linux-mips@xxxxxxxxxxxxxx
> Subject: RE: [RFC] SMP initialization order fixes.
>
> On Fri, 24 Feb 2006, Mark E Mason wrote:
>
> > Hello Stuart,
> >
> > Um - define "hung"...
>
> Networking stops happening. At this point, processes are still active.
> Because I am using NFS root, any process that touches the
> filesystem will then hang. It doesn't take too long for
> enough processes to touch the FS for the system to be
> useless. As a test, I put a tmpfs on /tmp, and ran sash from
> there. That shell would remain responsive after the rest of
> the system was hung waiting on NFS.
>
> Stuart
>
> Stuart R. Anderson anderson@xxxxxxxxxxxx
> Network & Software Engineering
> http://www.netsweng.com/
> 1024D/37A79149: 0791 D3B8
> 9A4C 2CDC A31F
> BD03 0A62
> E534 37A7 9149
>
>
