> This is fixing the symptom and is not the cure. Unfortunately I don't
> have a e1000 card so I can't try a fix. But I did have a e100 card that
> would lock up the same way. The problem was that netpoll_poll calls the
> cards netpoll routine (in e1000_main.c e1000_netpoll). In the e100
> case, when the transmit buffer would fill up, the queue would go down.
> But the netpoll routine in the e100 code never put it back up after it
> was all transfered. So this would lock up the kernel when that happened.
In my case the hang happened when no cable was connected.
There is no way to handle this in any other way. You eventually
have to bail out.
>
> repeat:
> - if(!np || !np->dev || !netif_running(np->dev)) {
> + if(try-- == 0 || !np || !np->dev || !netif_running(np->dev)) {
> + if (!try)
> + printk(KERN_WARNING "net driver is stuck down, maybe a"
> + " problem with the driver's netpoll\n");
... and nobody will see that. It will not even trigger an output.
-Andi
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|