John Philips a écrit :
Hum, given your slow cpu, you might revert tx queue
length to 2.4.XX level
(100 instead of 1000)
I tried that, it didn't help any.
Are you sure you cannot post here :
tc -s -d qdisc show dev eth6
As I said, there are rules in place for every single
IP in a /22 subnet. It would be over 12000 lines. I
tried turning off the traffic shaping, it didn't help.
You might want to make inet_peer_cache purge faster
:
echo 1 >/proc/sys/net/ipv4/inet_peer_gc_mintime
echo 2 >/proc/sys/net/ipv4/inet_peer_gc_maxtime
I tried that as well, unfortunately it didn't help.
This was just to reduce size of the table (and time of the lookups), not to
solve the nic problem at all :)
It's worth noting that this behavior happens at
seemingly random times for random amounts of time. It
also causes the interface to auto-negotiate it's
settings again. During these periods, ping times to a
switch plugged directly into eth6 are 4000+ms. When I
statically set the interface to 100baseT/full duplex
with mii-tool, ping times to the switch immediately
return to normal. Unfortunately this fix only lasts a
few minutes, because the interface hangs up and
returns to auto-negotiation.
Also, I know this isn't a problem with my hardware
since it started happening immediately after I
upgraded the kernel from 2.4.25.
Yes, I supposed that your hardware was running OK with previous kernels.
Which NIC driver is handling eth6 ?
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
