From owner-freebsd-current@FreeBSD.ORG Sat Nov 11 11:30:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB5616A416 for ; Sat, 11 Nov 2006 11:30:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D3E43D69 for ; Sat, 11 Nov 2006 11:30:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 63151 invoked from network); 11 Nov 2006 11:23:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2006 11:23:52 -0000 Message-ID: <4555B45D.6020800@freebsd.org> Date: Sat, 11 Nov 2006 12:30:37 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Pawel Worach References: <200611021653.kA2GrRWx008044@repoman.freebsd.org> <455530E0.5090000@gmail.com> In-Reply-To: <455530E0.5090000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: sendfile data corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 11:30:38 -0000 Pawel Worach wrote: > Andre Oppermann wrote: >> andre 2006-11-02 16:53:26 UTC >> >> FreeBSD src repository >> > ... >> Rewrite kern_sendfile() to work in two loops, the inner which turns >> as many > ... >> Revision Changes Path >> 1.240 +280 -242 src/sys/kern/uipc_syscalls.c >> 1.55 +2 -0 src/sys/sys/libkern.h >> 1.91 +2 -1 src/sys/sys/socket.h > > Hi Andre, > > I'm seeing some strange data corruption with this change. > Using apache 2.0.59 from ports, hardware is SMP i386. > > 0>root@cookie /usr/local/www/data# md5 sh > MD5 (sh) = e090ae9fc697b6ec84165af920034dc4 > 0>root@cookie /usr/local/www/data# unsetenv http_proxy > 0>root@cookie /usr/local/www/data# fetch -o /tmp/sh http://127.0.0.1/sh > /tmp/sh 100% of 109 kB 6516 kBps > 0>root@cookie /usr/local/www/data# md5 /tmp/sh > MD5 (/tmp/sh) = 1b6b9786ce7aa74b7ecbc7ee82c230dd > > It seems to be consistent... > 0>root@zero /usr/local/www/data# fetch -o /tmp/sh2 http://127.0.0.1/sh > /tmp/sh2 100% of 109 kB 41 MBps > 0>root@zero /usr/local/www/data# md5 /tmp/sh2 > MD5 (/tmp/sh2) = 1b6b9786ce7aa74b7ecbc7ee82c230dd > > Checking with hd(1) the changed data always seems to start at offset > 0x0000e000. > > cvs up -D '2006/11/02 17:00:00' OK > Repository revision: 1.239 > /export/ctm/cvs/src/sys/kern/uipc_syscalls.c,v > > cvs up -D '2006/11/02 18:00:00' BROKEN > Repository revision: 1.240 > /export/ctm/cvs/src/sys/kern/uipc_syscalls.c,v > > Files changed with update: > P geom/journal/g_journal.c > P kern/uipc_syscalls.c > P sys/libkern.h > P sys/socket.h > > Any other information I can provide? I'm looking into the problem. Please try a binary FTP transfer as well and check if the checksums match. ftpd uses sendfile(2) as well but w/o headers or trailers and does the send in one swoop. -- Andre