From owner-freebsd-stable Fri Jul 26 7:21:54 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E419C37B401 for ; Fri, 26 Jul 2002 07:21:48 -0700 (PDT) Received: from popmail.ct.lodgenet.com (mozart.lodgenet.com [204.124.122.253]) by mx1.FreeBSD.org (Postfix) with SMTP id 6751443E3B for ; Fri, 26 Jul 2002 07:21:47 -0700 (PDT) (envelope-from johnp@lodgenet.com) Received: (qmail 27777 invoked from network); 26 Jul 2002 14:21:45 -0000 Received: from windoze.ct.lodgenet.com (HELO windoze.lodgenet.com) (10.0.122.50) by popmail.ct.lodgenet.com with SMTP; 26 Jul 2002 14:21:45 -0000 Message-Id: <5.0.2.1.2.20020726091807.020b31b0@popmail.ct.lodgenet.com> X-Sender: johnp@popmail.ct.lodgenet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 26 Jul 2002 09:21:50 -0500 To: Ian Dowse From: John Prince Subject: Re: READ_BIG problems Cc: Hans Ottevanger , John Baldwin , stable@FreeBSD.org, Mark Hartley , Jesse Gross , John Prince In-Reply-To: <200207252206.aa43155@salmon.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Ian. I am sorry, I did not get back to you with regards to the patches you sent last week. I applied them, unfortunately, no changes.. At first I thought I saw an improvement, however after further testing, the unpatched and the patched revisions, both exhibit the same symptoms. Thanks. --john At 10:06 PM 7/25/2002 +0100, Ian Dowse wrote: >In message <3D406319.1136A6EA@iae.nl>, Hans Ottevanger writes: > >acd0: READ_BIG command timeout - resetting > >ata1: resetting devices .. done > >acd0: READ_BIG command timeout - resetting > >ata1: resetting devices .. done > >Could people seeing this and other ATA problems try the patch below? >This should fix some unlikely races that could potentially be >responsible for these problems, though I suspect it will not make >any difference. > >The second part of the patch is a workaround for the "atprq" hangs >on ATAPI tape drives. > >Ian > >Index: ata-all.c >=================================================================== >RCS file: /home/iedowse/CVS/src/sys/dev/ata/ata-all.c,v >retrieving revision 1.50.2.37 >diff -u -r1.50.2.37 ata-all.c >--- ata-all.c 19 Jun 2002 08:30:48 -0000 1.50.2.37 >+++ ata-all.c 18 Jul 2002 17:00:27 -0000 >@@ -228,10 +228,10 @@ > !ch->r_io || !ch->r_altio || !ch->r_irq) > return ENXIO; > >+ s = splbio(); > /* make sure channel is not busy */ > ATA_SLEEPLOCK_CH(ch, ATA_CONTROL); > >- s = splbio(); > #if NATADISK > 0 > if (ch->devices & ATA_ATA_MASTER && ch->device[MASTER].driver) > ad_detach(&ch->device[MASTER], 1); >@@ -669,10 +669,12 @@ > #endif > int s; > >- if (!ATA_LOCK_CH(ch, ATA_ACTIVE)) >+ s = splbio(); >+ if (!ATA_LOCK_CH(ch, ATA_ACTIVE)) { >+ splx(s); > return; >+ } > >- s = splbio(); > #if NATADISK > 0 > /* find & call the responsible driver if anything on the ATA queue */ > if (TAILQ_EMPTY(&ch->ata_queue)) { >Index: atapi-all.c >=================================================================== >RCS file: /home/iedowse/CVS/src/sys/dev/ata/atapi-all.c,v >retrieving revision 1.46.2.14 >diff -u -r1.46.2.14 atapi-all.c >--- atapi-all.c 14 Jul 2002 12:35:28 -0000 1.46.2.14 >+++ atapi-all.c 14 Jul 2002 23:39:00 -0000 >@@ -186,6 +186,7 @@ > request->flags = flags; > request->timeout = timeout * hz; > request->ccbsize = atadev->param->packet_size ? 16 : 12; >+ request->error = EINPROGRESS; > bcopy(ccb, request->ccb, request->ccbsize); > if (callback) { > request->callback = callback; >@@ -215,7 +216,8 @@ > } > > /* wait for request to complete */ >- tsleep((caddr_t)request, PRIBIO, "atprq", 0); >+ if (request->error == EINPROGRESS) >+ tsleep((caddr_t)request, PRIBIO, "atprq", 0); > splx(s); > error = request->error; > if (error) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message