> How much long was the card under load ? A few seconds ? > The same 1500 bytes mtu is used everywhere and the issue can not be > reproduced with a simple ping -f -q -l 64 -s what_you_want aimed at > the 8169, right ? Correct, > > What next? > > ethtool -d/-S before and after failure, .config and /proc/interrupts. Ok, here it all is, the attached archive has: - .before is right after the interface came up - .mid is after flooding it with ping -f commands from 2 machines at once - .bad is after doing the cpio over nc that killed it after 170MB - .back is after ifconfig down / ifconfig up that restored it Note, the kernel config has SMP etc turned back on, as it doesn't seem to affect things, and the eepro100 back on eth0, I'm testing this against eth1 so that the machine can be normally useful as well... r8169-bad/ifconfig.before r8169-bad/dmesg.before r8169-bad/arp-n.before r8169-bad/ethtool-d.before r8169-bad/ethtool-S.before r8169-bad/config.gz r8169-bad/proc-interrupts.before r8169-bad/ping-during r8169-bad/dmesg.mid r8169-bad/arp-n.mid r8169-bad/ifconfig.mid r8169-bad/ethtool-d.mid r8169-bad/ethtool-S.mid r8169-bad/proc-interrupts.mid r8169-bad/ifconfig.bad r8169-bad/dmesg.bad r8169-bad/ethtool-d.bad r8169-bad/ethtool-S.bad r8169-bad/proc-interrupts.bad r8169-bad/ifconfig.back r8169-bad/dmesg.back r8169-bad/ethtool-d.back r8169-bad/ethtool-S.back r8169-bad/proc-interrupts.back -Thanks, -Tom
r8169-bad.tar.bz2
Description: Binary data
