Bug 5924

Summary: Starfire interface stopped working "properly" since 2.6.13
Product: Networking Reporter: hvjunk (hvjunk)
Component: OtherAssignee: Arnaldo Carvalho de Melo (acme)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: bunk, romieu
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.13 till 2.6.15.1 Subsystem:
Regression: --- Bisected commit-id:

Description hvjunk 2006-01-19 09:28:22 UTC 
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
Comment 1 Andi Kleen 2006-01-19 10:19:12 UTC 
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.
Comment 2 hvjunk 2006-01-19 10:37:17 UTC 
This works fine with the onboard nvnet driver
Yes it is all tests on the local ethernet
Comment 3 Francois Romieu 2006-01-20 10:48:32 UTC 
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
Comment 4 hvjunk 2006-01-25 12:28:27 UTC 
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 :(
Comment 5 Francois Romieu 2006-01-25 13:14:02 UTC 
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
Comment 6 Adrian Bunk 2006-11-30 21:42:18 UTC 
Please reopen this bug if:
- it is still present in kernel 2.6.19 and
- you can provide the requested information.