On Tue, 2010-01-26 at 09:34 +0100, Anders Boström wrote: > >>>>> "JY" == Jie Yang <jie.y...@atheros.com> writes: > > JY> Anders Boström <and...@netinsight.net> wrote: > > JY> following is my test cese, > >> > JY> a nfs server server with ar8131chip, device id 1063. > >> export /tmp/ dir as the nfs share directory, JY> the client, > >> mount the server_ip:/tmp to local dir /mnt/nfs, ust a python > >> script to write and read data on the JY> > >> /mnt/nfs/testnfs.log. it works fine. > >> > >> OK, the device-ID in our NFS-server is 1026, rev. b0. So it > >> is possible that the problem is specific to that chip/version. > JY> oops, its my mistake in writing, my case is 1026 device ID > > >> > JY> Can you give me some advice on how to reproduce this bug?? > >> > >> The only suggestion I have is to try to find a board with a > >> 1026-chip on it. > >> > >> My test-case is just copy of a 1 Gbyte file from the > >> NFS-server to /dev/null , after making sure that the file > >> isn't cached on the client by reading huge amounts of other data. > >> > JY> just to check, if the kernel version is 2.6.26-2 ?? > > I've tested with > Debian linux-image-2.6.26-2-amd64 version 2.6.26-19lenny2, > Debian linux-image-2.6.30-bpo.2-amd64 version 2.6.30-8~bpo50+2 and > kernel.org 2.6.30.10 amd64 with ethtool patch for setting of tso. Same > result.
Does booting with the kernel parameter 'pci=nomsi' avoid the problem? Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else.
signature.asc
Description: This is a digitally signed message part
