From owner-freebsd-current@FreeBSD.ORG Sun Mar 1 18:06:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06684106564A for ; Sun, 1 Mar 2009 18:06:42 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id D25B88FC0A for ; Sun, 1 Mar 2009 18:06:41 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id E59D9C97; Sun, 1 Mar 2009 12:47:02 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ldpbt-000Pzc-Cn; Sun, 01 Mar 2009 11:37:53 -0600 To: freebsd-current@freebsd.org References: <49A99EA7.4000202@errno.com> <49A9A09A.2070900@freebsd.org> <49A9AA83.1030300@freebsd.org> <49A9ACF2.3090101@FreeBSD.org> From: Richard Todd Date: Sun, 01 Mar 2009 11:37:53 -0600 In-Reply-To: (Alexander Motin's message of "Sat, 28 Feb 2009 23:30:26 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.22 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Motin Subject: Re: ata problems @ r189170 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: Sun, 01 Mar 2009 18:06:42 -0000 Alexander Motin writes: > Looks like while fixing small problems I have found bigger ones. Try > please this patch against HEAD, it reverts r189166, r189091 and > partially r188903: > > http://people.freebsd.org/~mav/ata.rollback.patch > > If it works, I will stop for some time to cool down and search for > better solution. I too found problems with the "new" ATA code you'd tried -- not any obvious error messages or timeouts from the ATA system, but it was obviously sometimes returning corrupt data, as evidenced by ZFS giving checksum errors. (Yay for ZFS for catching this!) Moving to the current (post-r189195) code that has your aforementioned rollback patch seems to have fixed the problem, and I've been "zfs scrubbing" the disks without any sign of errors. So something in the patches you reverted apparently can cause silent data corruption that could go unnoticed without a higher-level checksum like ZFS has. Something you might want to watch out for when reworking those patches.... If it matters, this is on a Core2Duo system in amd64 mode, with a Intel DP965LT motherboard; the SATA controller is, if I recall right, ICH8: atapci1: port 0x3108-0x310f,0x3114-0x3117,0x3100-0x3107,0x3110-0x3113,0x3020-0x303f mem 0xe8325000-0xe83257ff irq 19 at device 31.2 on pci0 atapci1@pci0:0:31:2: class=0x010601 card=0x514d8086 chip=0x28248086 rev=0x02 hdr=0x00