From owner-freebsd-current@FreeBSD.ORG Fri Nov 2 10:57:53 2007 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 86D7416A417; Fri, 2 Nov 2007 10:57:53 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from mail.lxnt.info (mail.lxnt.info [217.23.143.142]) by mx1.freebsd.org (Postfix) with ESMTP id 426D813C4A5; Fri, 2 Nov 2007 10:57:53 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from [217.23.131.8] (helo=lxnt.inside.caravan.ru) by mail.lxnt.info with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InuDX-000OY8-2f; Fri, 02 Nov 2007 13:57:35 +0300 Message-ID: <472B02B5.9020502@lxnt.info> Date: Fri, 02 Nov 2007 13:57:57 +0300 From: Alexander Sabourenkov User-Agent: Thunderbird 2.0.0.6 (X11/20071024) MIME-Version: 1.0 To: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= References: <472A548B.50406@lxnt.info> <472AFB75.1070207@deepcore.dk> <472AFEC3.7090001@deepcore.dk> In-Reply-To: <472AFEC3.7090001@deepcore.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.ORG, sos@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, "Matthew D. Fuller" , Thierry Herbelot Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. 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: Fri, 02 Nov 2007 10:57:53 -0000 Søren Schmidt wrote: > Søren Schmidt wrote: >> Good catch! >> >> However from my quick glimpse at the Promise sources the limit seems >> to be 32 Dwords ie 32*4 = 128bytes. Please see driver named 4_sataii150-300_linux2.6-src_x86-64_v1.01.0.23 >> I'll investigate further and ask Promise for the gory details, stay >> tuned... >> I dont think the PRD count limitation is a real problem, I've newer >> seen that long a list and IIRC we newer do more than 64K transfers in >> one go (yet). In (current) practice, yes, but check should be there even if only to document the limit. >> Anyhow I need to get checks in for that not just here... >> >> Give me a few days and I'll get this figured out for 7-rel... > Oh, and I forgot, do you have a surefire way to reproduce the problem so > the fix can be tested ? dd if=/dev/ad8 of=/dev/null bs=1048576 count=1000 works every time. I have tested it on my home machine: without the patch first timeouts and errors appear about 10 seconds into the read. with the patch a read of entire disk (320G) completed without errors. Previous tests of analogous linux driver fix shown no errors and no data corruption on two write-whole-drive, read-whole-drive cycles. > > I've newer been able to trigger this problem myself so far. > Seems like the bug is highly configuration-dependent, or pci-chiset-depended, or just present in some production runs and not other. -- ./lxnt