netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Ian Jeffray <ian@jeffray.co.uk>
Cc: linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>,
	jacliburn@bellsouth.net, csnook@redhat.com, jeff@garzik.org
Subject: Re: sendfile() broken with 2.6.26 + Apache 2 ?
Date: Wed, 16 Jul 2008 11:08:04 +0200	[thread overview]
Message-ID: <487DBA74.3090800@cosmosbay.com> (raw)
In-Reply-To: <487DA388.3030104@jeffray.co.uk>

Ian Jeffray a écrit :
> Hi Eric,
> 
> Thanks for directing me to a better list.
> 
> Further responses below:
> 
> Eric Dumazet wrote:
>> CC to netdev where this report might find better answers
>>
>> Ian Jeffray a écrit :
>>> All,
>>>
>>> I moved from kernel 2.6.25.4 to 2.6.26 yesterday and observed that
>>> large files sent via Apache2 are partially corrupt.
>>>
>>> This appears to be linked to sendfile() -- disabling the use of
>>> sendfile in the apache config (EnableSendfile Off) allows it to
>>> function as normal.
>>>
>>> My system is a simple Core2Duo running Debian lenny/sid; nothing
>>> special, and I have never observed problems like this before.
>>>
>>> The problem feels certainly related to sendfile() since the data
>>> reads correctly from disc in other programs, and via CIFS etc.
>>>
>>> The corruption happens part-way in to the file... I've no exact
>>> figure but it would seem like maybe 32KB -- I'm seeing broken
>>> PNGs served from Apache, where the top few dozen lines decode
>>> correctly, and the rest is garbage.
>>>
>>> I've made basically no configuration changes between 2.6.25.4 and
>>> 2.6.26 and have explicitly tried both enabling and disabling the
>>> new PAT support to no effect.
>>>
>>> This is completely repeatable and reproducible.
>>>
>>> Is anyone else seeing this broken behaviour?
>>>
>>
>>
>> What kind of network adapter are you using ? (lspci | grep -i ether)
> 
> 02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit 
> Ethernet Adapter (rev b0)
> 
> 
>> If you disable TCP segmentation offload on this NIC (ethtool -K eth0 
>> tso off) , is this problem still present ?
> 
> Wow.  That 'solves' the problem!  Great.
> 
> Does this therefore point to an attansic driver issue?
>


Yes, maybe related to commit 9d90fb1ac9d97da86e24d9ea947bf2a2f333829a 

In this patch, Jay Cliburn enabled TSO by default for atl1 driver.

This might be a driver problem, or a generic sendfile() problem, I dont know...





  reply	other threads:[~2008-07-16  9:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <487CD7A7.2080800@jeffray.co.uk>
2008-07-16  5:38 ` sendfile() broken with 2.6.26 + Apache 2 ? Eric Dumazet
2008-07-16  7:30   ` Ian Jeffray
2008-07-16  9:08     ` Eric Dumazet [this message]
2008-07-16 13:38       ` J. K. Cliburn
2008-07-16 13:41         ` Pekka Enberg
2008-07-16 14:00           ` J. K. Cliburn
2008-07-16 14:58       ` Holger Hoffstaette
2008-07-19 12:31 ` J. K. Cliburn
     [not found]   ` <4881E0BD.4060608@jeffray.co.uk>
2008-07-19 14:52     ` Jay Cliburn
2008-07-19 16:31       ` Ian Jeffray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=487DBA74.3090800@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=csnook@redhat.com \
    --cc=ian@jeffray.co.uk \
    --cc=jacliburn@bellsouth.net \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).