From owner-freebsd-current@FreeBSD.ORG Sat Nov 11 18:00:35 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 539E416A40F for ; Sat, 11 Nov 2006 18:00:35 +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 97E9F43D64 for ; Sat, 11 Nov 2006 18:00:27 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 66257 invoked from network); 11 Nov 2006 17:53:39 -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 17:53:39 -0000 Message-ID: <45560FB8.1040607@freebsd.org> Date: Sat, 11 Nov 2006 19:00:24 +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> <4555B45D.6020800@freebsd.org> <4555BA65.4020603@gmail.com> In-Reply-To: <4555BA65.4020603@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 18:00:35 -0000 Pawel Worach wrote: > Andre Oppermann wrote: >> >> 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. >> > > Oh, didn't think of that, ftpd is ok, transferring a 64MB file does not > trash it. Meanwhile a couple of other things where tested, SMP disabled > (removed from kernel config), added some printf's which when printing to > a serial console moves the offset where the breakage begins to > 0x01000000, sometimes. I tried to reproduce the problem with lighttpd w/o success. My guess is that something gets wrong when using non-blocking sockets and the http headers. Could you obtain the truss of the sendfile(2) calls so I get the input parameters to it? A visual inspection of a corruptly transferred text file would be helpful too. This should give more hints what happens, like duplicated or missing pages, etc. -- Andre