On Thu, 13 Dec 2007 03:19:43 +0100, Holger Hoffstaette wrote:
I have now gone back to enable TSO since vsftp with sendfile really seems
to be the only app that causes this. I have simply set it to
use_sendfile=NO and no corruption occurs at all; the machine is stable and
fast.
In the good
On Thu, 06 Dec 2007 19:44:26 +0100, Francois Romieu wrote:
Holger Hoffstaette [EMAIL PROTECTED] : [...]
Maybe turning off sendfile or NAPI just lead to random success - so far
it really looks like tso on the r8169 is the common cause.
TSO on the r8169 is the magic switch but the regression
On Thu, 06 Dec 2007 19:44:26 +0100, Francois Romieu wrote:
Holger Hoffstaette [EMAIL PROTECTED] : [...]
Maybe turning off sendfile or NAPI just lead to random success - so far
it really looks like tso on the r8169 is the common cause.
TSO on the r8169 is the magic switch but the regression
Francois Romieu wrote:
Holger Hoffstaette [EMAIL PROTECTED] :
[...]
Maybe turning off sendfile or NAPI just lead to random success - so far it
really looks like tso on the r8169 is the common cause.
TSO on the r8169 is the magic switch but the regression makes imvho more
sense from a VM pov:
On Wed, 05 Dec 2007 23:54:29 +0100, Francois Romieu wrote:
Holger Hoffstaette [EMAIL PROTECTED] : [...]
Should I file this in bugzilla?
Yes.
Thanks for responding - will do. I verified with 2.6.24-rc4 (same bug) and
have some new information about this.
Despite my previous posting the
(removing .kernel as it seems to concern netdev only)
On Thu, 06 Dec 2007 02:13:00 +0100, Francois Romieu wrote:
Francois Romieu [EMAIL PROTECTED] :
Holger Hoffstaette [EMAIL PROTECTED] : [...]
Should I file this in bugzilla?
Yes.
5326 5585327 5585328 5585329 5585330 5585331 5585332
Holger Hoffstaette [EMAIL PROTECTED] :
[...]
Maybe turning off sendfile or NAPI just lead to random success - so far it
really looks like tso on the r8169 is the common cause.
TSO on the r8169 is the magic switch but the regression makes imvho more
sense from a VM pov:
- the corrupted file has
Holger Hoffstaette [EMAIL PROTECTED] :
[...]
Should I file this in bugzilla?
Yes.
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Francois Romieu [EMAIL PROTECTED] :
Holger Hoffstaette [EMAIL PROTECTED] :
[...]
Should I file this in bugzilla?
Yes.
5326 5585327 5585328 5585329 5585330 5585331 5585332 5585333 5585334 5585335 558
5336 5585337 5585338 5585339 5585340 5585341 5585342 5585343 5589440 5589441 558
On Fri, 30 Nov 2007 10:26:54 -0800, Rick Jones wrote:
Could the corruption be seen in a tcpdump trace prior to transmission (ie
taken on the sender) or was it only seen after the data passed out the
NIC?
I did the following:
1) turn on tso on the server's r8169: ethtool --offload eth0 tso
Holger Hoffstaette a écrit :
Hi -
This regular Linux user and lkml lurker just noticed data corruption in
ftp'ed files and narrowed it down to vsftpd using sendfile(). So far this
has never caused problems in the past; I have not noticed this with
2.6.22.x but may have missed it. I do remember
Btw, the r8169 has NAPI enabled.
kernel config:
http://hoho.dyndns.org/~holger/dist/kernel-config-x86-2.6.23.9
dmesg:
http://hoho.dyndns.org/~holger/dist/dmesg
lspci -vv:
http://hoho.dyndns.org/~holger/dist/lspci
thanks
Holger
-
To unsubscribe from this list: send the line unsubscribe
On Fri, 30 Nov 2007 09:07:53 +0100, Eric Dumazet wrote:
CC to netdev, it might concern network guys
It is indeed related to network/r8169, more below.
Could you try with a test file containing unique patterns ?
Same result, here is new information.
- contrary to my first posting, the
Could the corruption be seen in a tcpdump trace prior to transmission
(ie taken on the sender) or was it only seen after the data passed out
the NIC?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
14 matches
Mail list logo
