Most recent kernel where this bug did not occur: 2.6.12.5/2.6.12-gentoo-r10 Distribution: Gentoo Hardware Environment: Athlon64, x86_64 Adaptec Starfire Quad ethernet Software Environment: Gentoo, 2.6.15, gcc 3.4.4 Problem Description: Serving data (typically >MTU) fails for both NFS and Apache2 Steps to reproduce: connect throught the Adapted starfire to network go to remote machine(s) and try to fetch big data from HTTP or try to mount NFS drives
Does it work locally? If transfers >MTU don't work remotely it is usually a problem with path mtu discovery and broken firewalls and not caused by the kernel. Anyways reassigning to the network people.
This works fine with the onboard nvnet driver Yes it is all tests on the local ethernet
hvjunk: > This works fine with the onboard nvnet driver > Yes it is all tests on the local ethernet Can you try the command below when the starfire adapter is connected to the same host which was used for testing the nvidia adapter ? Simply replace $REMOTE_HOST with the relevant host/address. for i in $(seq 1467 1473); do ping do -c 1 -s $i $REMOTE_HOST echo done Andi is probably right but it is not expensive to check :o) -- Ueimor
for i in $(seq 1467 1473); do ping -c 1 -s $i 10.11.12.3; echo; done Only hiccup was one packet lost over the wireless from my notebook, but from the LAN all gone through. trying to mount a NFS: mount -o ro 10.11.12.3:/mnt/space /swartes/space mount: 10.11.12.3:/mnt/space: can't read superblock Swapping to the onboard nvnet/forceth works like a charm :(
If you can avoid to transfer on the lan any data which may hurt your privacy, could you : 1 - tcpdump -s 0 -i ethX -w /tmp/dump.pcap & 2 - issue a few pings 3 - mount blah... 4 - issue a few pings 5 - stop tcpdump The dump file should not be huge. I will not claim to be necessarily able to figure the issue but whoever helps may ask for the network dump anyway. -- Ueimor
Please reopen this bug if: - it is still present in kernel 2.6.19 and - you can provide the requested information.