From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 28 11:09:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E5716A4CE for ; Thu, 28 Oct 2004 11:09:54 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 927C443D2F for ; Thu, 28 Oct 2004 11:09:54 +0000 (GMT) (envelope-from miha@ghuug.org) Received: from [64.62.253.84] (helo=m) by beer.ux6.net with esmtpa (Exim 4.43 (FreeBSD)) id 1CN8AC-000BX9-JN; Thu, 28 Oct 2004 04:09:54 -0700 From: "Mikhail P." To: freebsd-hackers@freebsd.org Date: Thu, 28 Oct 2004 11:09:48 +0000 User-Agent: KMail/1.7 References: <200410081937.15068.miha@ghuug.org> <200410091843.06854.miha@ghuug.org> <4168F9E7.9040408@DeepCore.dk> In-Reply-To: <4168F9E7.9040408@DeepCore.dk> Organization: Ghana Unix Users Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200410281109.48424.miha@ghuug.org> X-Spam-Score: -4.9 (----) X-Spam-Report: Spam detection software, running on the system "beer.ux6.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sunday 10 October 2004 08:59, Søren Schmidt wrote: > There is definitly something fishy here, since I dont have either the > disks nor any VIA chips here in the lab I cannot do any testing here. > However I dont know of any problems with the VIA chips in this regard, > so that leaves the disks for scrutiny. One thing to try is change the > tripping point where we switch from 28bit mode to 48 bit mode, could be > a 1 off error in the firmware... [...] Content analysis details: (-4.9 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] cc: =?iso-8859-1?q?S=F8ren_Schmidt?= Subject: Re: ad0: FAILURE - WRITE_DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 11:09:54 -0000 On Sunday 10 October 2004 08:59, S=F8ren Schmidt wrote: > There is definitly something fishy here, since I dont have either the > disks nor any VIA chips here in the lab I cannot do any testing here. > However I dont know of any problems with the VIA chips in this regard, > so that leaves the disks for scrutiny. One thing to try is change the > tripping point where we switch from 28bit mode to 48 bit mode, could be > a 1 off error in the firmware... I apologize for bumping that old thread.. I have received both 200G drives (the ones that were giving me "adX: FAILUR= E -=20 WRITE_DMA" on 5.2.1 system). I have plugged both drives into running 4.10 system, re-formatted them to U= =46S1=20 from sysinstall. After filling those drives with 180G of data each (files=20 ranging in size from 10k to 1G), I did a lot of load on them (e.g. transfer= ed=20 data between other drives in the system, deleted random files, "dd", etc) a= nd=20 those adX failures did not appear anymore (in fact, I'm running those drive= s=20 on the file server for 5 days now, and there is no single failure/timeout s= o=20 far - system has been very stable all the time on FreeBSD-4.10) On the side note - I did changes to the tripping point as suggested above a= nd=20 re-compiled kernel on 5.2.1 running system - disk operations dramatically=20 decreased as expected, but number of timeouts decreased too (per dmesg -=20 one-two timeouts in 3-4 days). I should probably also note another interesting thing - on another system w= ith=20 4 hard drives (20G, 60G, 120G, 200G) where I ran RELENG_5 for the past week= ,=20 timeouts and failures were appearing randomly under heavy disk writes. That system had a mix of filesystems - primary 20G drive had UFS2, and the= =20 rest of the drives were UFS1 (as they hold data, and I ran 4.7 on that syst= em=20 half a year ago) - data transfer between interfaces was horrible, less than= =20 8-10mb/sec, even when system was IDLE. After re-installing system to 4.10 (no changes to hardware/etc - all remain= ed=20 the same apart from OS), I don't see timeouts/errors anymore, and speed of= =20 transfers between the drives got back to 20-25mb/sec, that's including that= =20 system isn't IDLE. There is also a third system with 2 x 200G ide drives and FBSD-5.2.1. Today= , I=20 had to transfer approx. 160G of data from one of the drives to another syst= em=20 via NFS, and unfortunately some files could not be transfered due to the sa= me=20 ad1 failures as above.. I'm going to mount drive in "ro", to finish the=20 transfer. regards, M.