From owner-freebsd-questions Fri Jan 10 2:36:19 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 764B637B401 for ; Fri, 10 Jan 2003 02:36:14 -0800 (PST) Received: from mail.tiscali.it (mail-6.tiscali.it [195.130.225.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA1D43E4A for ; Fri, 10 Jan 2003 02:36:13 -0800 (PST) (envelope-from fcasadei@inwind.it) Received: from goku.kasby (217.133.210.149) by mail.tiscali.it (6.5.032) id 3E1575F2002B443B for freebsd-questions@freebsd.org; Fri, 10 Jan 2003 11:36:11 +0100 Received: (qmail 1312 invoked by uid 1000); 10 Jan 2003 10:35:54 -0000 Date: Fri, 10 Jan 2003 11:35:54 +0100 From: Francesco Casadei To: freebsd-questions@freebsd.org Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems Message-ID: <20030110103554.GA1284@goku.kasby> Mail-Followup-To: freebsd-questions@freebsd.org References: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> <20030102163812.GA2350@goku.kasby> <1041532923.3e1487fb50a0e@www.nexusmail.uwaterloo.ca> <20030105140246.GA8010@goku.kasby> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20030105140246.GA8010@goku.kasby> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.7-STABLE i386 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 05, 2003 at 03:02:46PM +0100, Francesco Casadei wrote: >=20 [snip] > Yesterday I checked the drive ad6 with the Drive Fitness Test program fro= m IBM. > Both quick and advanced test returned that the drive is ok. I then ran th= e test > against ad0 (the backup drive): the quick test showed that the drive was > defective because of "Excessive Shock". Re-executing the test gave same r= esult. > I rebooted the system and disabled the S.M.A.R.T. option for the drive at= tached > to the motherboard's controller (i.e. the backup drive). Re-executing the= quick > test showed that the drive is ok! >=20 > After 16 hours of uptime and one level-0 file system dump all drives are = still > using UDMA100. >=20 > If for some reason the system will fall back again to PIO4 mode I will tr= y to > remove the two following options from the kernel: >=20 > # ISA optimization > options AUTO_EOI_1 > options AUTO_EOI_2 >=20 >=20 > If the problem won't still be solved then I will try in order the followi= ng: > - disable tagged queuing > - buy different hardware! >=20 > 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, ...) >=20 > Key fingerprint is: 1671 9A23 ACB4 520A E7EE 00B0 7EC3 375F 164E B17B >=20 > end of the original message Disabling S.M.A.R.T. capability on ad0 did not solve the problem :( After ~5 days of uptime: Jan 9 05:39:34 zeus /kernel: ad6: SERVICE timeout tag=3D24 s=3Dc0 e=3D04 Jan 9 05:39:44 zeus /kernel: ad6: invalidating queued requests Jan 9 05:39:44 zeus /kernel: ad6: timeout sending command=3D00 s=3Dc0 e=3D= 04 Jan 9 05:39:44 zeus /kernel: ad6: flush queue failed Jan 9 05:39:44 zeus /kernel: ad6: timeout sending command=3Dc7 s=3Dc0 e=3D= 04 Jan 9 05:39:44 zeus /kernel: ad6: error executing commandad6: invalidating= queued requests Jan 9 05:39:44 zeus /kernel: ad6: timeout sending command=3D00 s=3Dc0 e=3D= 04 Jan 9 05:39:44 zeus /kernel: ad6: flush queue failed Jan 9 05:39:44 zeus /kernel: - resetting Jan 9 05:39:44 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:39:44 zeus /kernel: done Jan 9 05:39:44 zeus /kernel: ad6: no request for tag=3D1 Jan 9 05:39:44 zeus /kernel: ad6: invalidating queued requests Jan 9 05:39:34 zeus apcsmart[159]: Serial port read timed out Jan 9 05:39:44 zeus upsd[162]: Data for UPS [Back-UPS_PRO_650] is stale - = check support module (shm_ctime too old) Jan 9 05:39:44 zeus upsmon[166]: Poll UPS [Back-UPS_Pro_650@localhost] fai= led - Data stale Jan 9 05:39:44 zeus /kernel: Jan 9 05:39:44 zeus upsmon[166]: Poll UPS [B= ack-UPS_Pro_650@localhost] failed - Data stale Jan 9 05:39:44 zeus upsd[162]: Host 127.0.0.1 disconnected Jan 9 05:39:44 zeus upsmon[166]: Communications with UPS Back-UPS_Pro_650@= localhost lost Jan 9 05:39:44 zeus apcsmart[159]: Serial port read ok again Jan 9 05:39:46 zeus upsd[162]: Data for UPS [Back-UPS_PRO_650] is now OK Jan 9 05:39:46 zeus upsd[162]: Data source for UPS [Back-UPS_PRO_650]: SHM= (65536) Jan 9 05:39:49 zeus upsd[162]: Connection from 127.0.0.1 Jan 9 05:39:49 zeus upsmon[166]: Communications with UPS Back-UPS_Pro_650@= localhost established Jan 9 05:39:49 zeus upsd[162]: Client 127.0.0.1 logged into UPS [Back-UPS_= Pro_650] Jan 9 05:39:54 zeus /kernel: ad6: READ command timeout tag=3D1 serv=3D0 - = resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: READ command timeout tag=3D0 serv=3D1 - = resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: timeout waiting for READY Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ad6: timeout sending command=3D00 s=3Dd0 e=3D= 04 Jan 9 05:40:15 zeus /kernel: ad6: flush queue failed Jan 9 05:40:15 zeus /kernel: - resetting Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: READ command timeout tag=3D1 serv=3D0 - = resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: READ command timeout tag=3D0 serv=3D1 - = resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: no request for tag=3D0 Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ad6: WRITE command timeout tag=3D0 serv=3D0 -= resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: READ command timeout tag=3D1 serv=3D0 - = resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ad6: trying fallback to PIO mode Jan 9 05:40:15 zeus /kernel: ata3: resetting devices ..=20 Jan 9 05:40:15 zeus /kernel: stray irq 7 Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: ad6: READ command timeout tag=3D0 serv=3D1 - = resetting Jan 9 05:40:15 zeus /kernel: ad6: invalidating queued requests Jan 9 05:40:15 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:15 zeus /kernel: done Jan 9 05:40:15 zeus /kernel: Jan 9 05:40:15 zeus /kernel: stray irq 7 Jan 9 05:40:05 zeus apcsmart[159]: Serial port read timed out Jan 9 05:40:05 zeus /usr/sbin/cron[10319]: (root) CMD (/usr/libexec/atrun)= =20 Jan 9 05:40:05 zeus apcsmart[159]: Serial port read ok again Jan 9 05:40:25 zeus /kernel: ad6: READ command timeout tag=3D1 serv=3D0 - = resetting Jan 9 05:40:25 zeus /kernel: ata3: resetting devices .. ad6: invalidating = queued requests Jan 9 05:40:25 zeus /kernel: done I have another question: it seems that the system falling to PIO4 mode caus= es read time out on the serial port too, why did this happen? I will try to run the system without tagged queuing. 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 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+HqIJfsM3XxZOsXsRAthAAJ9sBZ+xjRLlGZi4PwmAPp04QK4nywCg6sSD IyWTXAuD3Tbm9qf9xpB8FAU= =EGtQ -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message