From owner-freebsd-hardware@FreeBSD.ORG Fri Sep 24 15:51:08 2004 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1020F16A516; Fri, 24 Sep 2004 15:51:07 +0000 (GMT) Received: from post5.inre.asu.edu (post5.inre.asu.edu [129.219.110.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8F0643D1F; Fri, 24 Sep 2004 15:51:06 +0000 (GMT) (envelope-from David.Bear@asu.edu) Received: from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769) id <0I4J00B01YJD5M@asu.edu>; Fri, 24 Sep 2004 08:47:37 -0700 (MST) Received: from smtp.asu.edu (smtp.asu.edu [129.219.110.107]) <0I4J00AKBYJD5Y@asu.edu>; Fri, 24 Sep 2004 08:47:37 -0700 (MST) Received: from moroni.pp.asu.edu (moroni.pp.asu.edu [129.219.69.200]) (8.12.10/8.12.10/asu_smtp_relay,nullclient,tcp_wrapped) with ESMTP id i8OFla71013697; Fri, 24 Sep 2004 08:47:36 -0700 (MST) Received: by moroni.pp.asu.edu (Postfix, from userid 500) id D49D2F0C; Fri, 24 Sep 2004 08:47:03 -0700 (MST) Received: from post1.inre.asu.edu (post1.inre.asu.edu [129.219.110.72]) by imap1.asu.edu (8.11.0/8.11.0/asu_cyrus,tcp_wrapped) with ESMTP id h02Gcsi03771 for ; Thu, 02 Jan 2003 09:38:54 -0700 (MST) Received: from conversion.post1.inre.asu.edu by asu.edu (PMDF V6.1 #40110) david.bear@asu.edu) ; Thu, 02 Jan 2003 09:38:55 -0700 (MST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by asu.edu (PMDF V6.1 #40110) with ESMTP id <0H8300F6MI8U0I@asu.edu> for iddwb@IMAP1.ASU.EDU (ORCPT david.bear@asu.edu); Thu, 02 Jan 2003 09:38:54 -0700 (MST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 41F5255811; Thu, 02 Jan 2003 08:38:33 -0800 Received: by hub.freebsd.org (Postfix, from userid 538) id 1EFCE37B401; Thu, 02 Jan 2003 08:38:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 033112E8020; Thu, 02 Jan 2003 08:38:32 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Thu, 02 Jan 2003 08:38:31 -0800 Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EA2A37B405 for ; Thu, 02 Jan 2003 08:38:27 -0800 (PST) Received: from mail.tiscali.it (mail-7.tiscali.it [195.130.225.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20EF743ED1 for ; Thu, 02 Jan 2003 08:38:21 -0800 (PST envelope-from fcasadei@inwind.it) Received: from goku.kasby (217.133.211.64) by mail.tiscali.it (6.5.032) id 3E00972000611084 for freebsd-questions@freebsd.org; Thu, 02 Jan 2003 17:38:19 +0100 Received: (qmail 2870 invoked by uid 1000); Thu, 02 Jan 2003 16:38:12 +0000 From: Francesco Casadei In-reply-to: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> Sender: owner-freebsd-questions@FreeBSD.ORG To: dwbear75@gmail.com Message-id: <20030102163812.GA2350@goku.kasby> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=wRRV7LY7NUeQGEoC Content-disposition: inline Precedence: bulk X-Loop: FreeBSD.ORG Delivered-to: freebsd-questions@freebsd.org Old-To: Bruce Campbell User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.7-STABLE i386 Lines: 193 References: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> cc: freebsd-questions@FreeBSD.ORG cc: freebsd-hardware@FreeBSD.ORG Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 24 Sep 2004 15:51:08 -0000 X-Original-Date: Thu, 02 Jan 2003 17:38:12 +0100 X-List-Received-Date: Fri, 24 Sep 2004 15:51:08 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 31, 2002 at 03:57:16PM -0500, Bruce Campbell wrote: >=20 > I am seeing a problem with ata disks on 4 new systems, which > I believe is either a bug in the ata driver, or a problem with > the onboard IDE controller, or something else. Systems are as follows: >=20 > Motherboard: ASUS A7M266-D > CPUs : 2 x 2000+ AMD MP > Memory : 2 x 512MB Crucial part: CT6472Y265 >=20 > Disks (all UDMA100): >=20 > Master Slave > System 1: WDC WD400BB WDC WD1000BB > System 2: WDC WD400BB WDC WD1000BB > System 3: WDC WD400BB WDC WD800BB > System 4: WDC WD400BB Maxtor 98196H8 >=20 > Kernel : 4.7-RELEASE, custom kernel (compared to GENERIC): >=20 > commented out: >=20 > cpu I386_CPU > cpu I486_CPU >=20 > enabled=20 >=20 > options SMP # Symmetric MultiProcessor Kernel > options APIC_IO # Symmetric (APIC) I/O >=20 >=20 > I am running a test with "dbench" (/usr/ports/benchmarks/dbench) > with a script which runs: >=20 > dbench 1 > sleep for 5 minutes > dbench 2 > sleep for 5 minutes > dbench 3 > ... >=20 > to simulate 1,2,3... clients. >=20 > The following has happened on systems 2,3 and 4, after about 15 hours > of running the test: >=20 > Dec 30 23:26:59 ecserv13 /kernel: ad0: WRITE command timeout tag=3D0 serv= =3D0 - > resetting > Dec 30 23:26:59 ecserv13 /kernel: ata0: resetting devices .. done > Dec 30 23:26:59 ecserv13 /kernel: ad0: WRITE command timeout tag=3D0 serv= =3D0=20 > resetting > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done > Dec 30 23:27:00 ecserv13 /kernel: ad0: WRITE command timeout tag=3D0 serv= =3D0=20 > resetting > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done > Dec 30 23:27:00 ecserv13 /kernel: ad0: WRITE command timeout tag=3D0 serv= =3D0=20 > resetting > Dec 30 23:27:00 ecserv13 /kernel: ad0: timeout waiting for cmd=3Def s=3Dd= 0 e=3D00 > Dec 30 23:27:00 ecserv13 /kernel: ad0: trying fallback to PIO mode > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done >=20 > The test continues to run with the ata controller in PIO mode, with > slower performance, and higher load average. >=20 > Once the master drops to PIO, attempts to access the slave then cause > it to drop to PIO. >=20 > If I run: >=20 > atacontrol mode 0 UDMA100 UDMA100 >=20 > attempts to access either drive result in a delay until the controller > drops to PIO, and then operations resume. A soft reboot and things > work in UDMA mode again. Also tried UDMA33 and UDMA66 with no change. > I also tried "atacontrol reinit 0" with no help. >=20 > Theories when I search the web for "fallback to PIO mode" include: >=20 > - bad disks > - something to do with thermal recalibration >=20 > I don't believe the problems are bad disks, as the slave drops to PIO > after the master does, and I can't get in back to UDMA, other than by > soft reboot. Plus I see the problem on 6 of 8 disks. >=20 > The problem is very repeatable. >=20 > Can anyone offer any ideas, or suggest investigative steps ? I have a sy= stem > in PIO mode right now. >=20 > Thanks, >=20 > --=20 > Bruce Campbell > Engineering Computing > CPH-2374B > University of Waterloo > (519)888-4567 ext 5889 >=20 > ---------------------------------------- > This mail sent through www.mywaterloo.ca >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message >=20 > end of the original message Same problem here, but slightly different configuration: # atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI rev 5 Slave: no device present ATA channel 1: Master: acd0 ATA/ATAPI rev 0 Slave: no device present ATA channel 2: Master: ad4 ATA/ATAPI rev 5 Slave: no device present ATA channel 3: Master: ad6 ATA/ATAPI rev 5 Slave: no device present ad4 and ad6 are attached to a Promise FastTrak 100 TX2 ATA RAID controller. # atacontrol mode 0 Master =3D UDMA100=20 Slave =3D ??? # atacontrol mode 1 Master =3D PIO4=20 Slave =3D ??? # atacontrol mode 2 Master =3D UDMA100=20 Slave =3D ??? # atacontrol mode 3 Master =3D PIO4=20 Slave =3D ??? ad6 falls back to PIO mode on heavy I/O activity, i.e. when the system does= a level 0 file systems dump from the RAID 1 array (ad4,ad6) to the backup disk ad0. Rebooting and rebuilding the array with the Promise BIOS utility temporarily solve the problem. The system may be up and running for 1-4 weeks doing a level 0 dump every morning at 5:30am and then one day the drive ad6 falls b= ack to PIO mode again (little before the completion of fs dump). Do the hard drives you are using support the ATA tagged queuing? And if so,= do you have TQ enbled? Francesco Casadei --=20 You can download my public key from http://digilander.libero.it/fcasadei/ or retrieve it from a keyserver (pgpkeys.mit.edu, wwwkeys.pgp.net, ...) Key fingerprint is: 1671 9A23 ACB4 520A E7EE 00B0 7EC3 375F 164E B17B --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE+FGr0fsM3XxZOsXsRAlInAKDb4DiO9vSpMBJnmfRnS3v+qtTs+ACg0EZG BvkLn2Sdg7cpD6KSWoxsYRA= =sE+F -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message