Michael Chan a écrit : On Wed, 2005-06-22 at 17:25 +0200, Eric Dumazet wrote: Is there anything I can try to tune the coalescing ? Being able to handle 100 packets each interrupt instead of one or
David S. Miller a écrit : From: Eric Dumazet <dada1@xxxxxxxxxxxxx> Date: Mon, 04 Jul 2005 23:22:12 +0200 But it seems something is wrong because when network load becomes high I get : Jul 4 23:01:1
Eric Dumazet a écrit : David S. Miller a écrit : From: Eric Dumazet <dada1@xxxxxxxxxxxxx> Date: Mon, 04 Jul 2005 23:22:12 +0200 But it seems something is wrong because when network load becomes high
Eric Dumazet a écrit : Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all hw IRQ handler spinlocks. (Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT)) Maybe I should revert to stock 2
Please don't ever do stuff like that :-( That makes the driver version, and any other information you report completely meaningless and useless. You've just wasted a lot of our time. I have no idea t
David S. Miller a écrit : Please don't ever do stuff like that :-( That makes the driver version, and any other information you report completely meaningless and useless. You've just wasted a lot o
Eric Dumazet a écrit : For your information, 2.6.13-rc1 locks too. Very easy way to lock it : ping -f some_destination. Arg. False alarm. Sorry. Time for me to sleep
The case here is that you didn't even mention that you had the patch applied. If you don't say what changes you've applied to the stock driver we can't properly debug anything. SMP system? What platf
David S. Miller a écrit : SMP system? What platform and 570x chip revision? dual opterons 248, Ethernet controller: Broadcom Corporation NetXtreme BCM5702 Gigabit Ethernet (rev 02) Does the stock d
Is there anything I can try to tune the coalescing ? Being able to handle 100 packets each interrupt instead of one or two would certainly help. I dont mind about latency. But of course I would like
But it seems something is wrong because when network load becomes high I get : Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit
Eric Dumazet a écrit : David S. Miller a écrit : But it seems something is wrong because when network load becomes high I get : Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Eric Dumazet a écrit : Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all hw IRQ handler spinlocks. (Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT)) Maybe I should revert to stock 2.6