From: "Holger Hoffstaette" <holger@wizards.de>
To: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: sendfile() broken with 2.6.26 + Apache 2 ?
Date: Wed, 16 Jul 2008 16:58:08 +0200 [thread overview]
Message-ID: <pan.2008.07.16.14.58.05.879125@wizards.de> (raw)
In-Reply-To: 487DBA74.3090800@cosmosbay.com
On Wed, 16 Jul 2008 11:08:04 +0200, Eric Dumazet wrote:
> 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...
Maybe related to http://lkml.org/lkml/2007/12/6/229 ?
I switched to a different server with e1000 NIC in the meantime and so I
cannot test if this is still a problem in 2.6.26, but apparently it seems
so. For me the combo e1000/e1000e + sendfile works reliably..
Holger
next prev parent reply other threads:[~2008-07-16 14:58 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
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 [this message]
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=pan.2008.07.16.14.58.05.879125@wizards.de \
--to=holger@wizards.de \
--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).