From owner-freebsd-bugs@FreeBSD.ORG Sat Dec 6 15:36:22 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA7AA16A4CE; Sat, 6 Dec 2003 15:36:22 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E915143FB1; Sat, 6 Dec 2003 15:36:20 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id KAA17467; Sun, 7 Dec 2003 10:36:08 +1100 Date: Sun, 7 Dec 2003 10:36:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Divacky Roman In-Reply-To: <200312030816.hB38Gqpb002759@eva.fit.vutbr.cz> Message-ID: <20031207102255.S6648@gamplex.bde.org> References: <200312030816.hB38Gqpb002759@eva.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/59917: ata reset update in ATAng X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 23:36:23 -0000 On Wed, 3 Dec 2003, Divacky Roman wrote: > >Description: > > I have PIIX4 ata controller has very slow ata-reset under ATAng How slow? The patch seesm to mainly just increase the resolution of the polling so that you have to wait up to 99 msec less. > >How-To-Repeat: > > this is default behaviour > > >Fix: > this patch fixes it: > > --- /tmp/ata-lowlevel.c Sat Nov 22 16:48:27 2003 > +++ /sys/dev/ata/ata-lowlevel.c Sat Nov 22 17:06:45 2003 > @@ -549,19 +549,22 @@ > ATA_IDX_INB(ch, ATA_ERROR); > > /* wait for BUSY to go inactive */ > - for (timeout = 0; timeout < 310; timeout++) { > + /* Hacked by neologism... too slow for me ;) */ > + for (timeout = 0; timeout < 31000; timeout++) { I use similar changes (this and the corresponding decreased delay) for unrelated reasons (to monitor the status in closer to real time). > if (stat0 & ATA_S_BUSY) { > ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_MASTER); > DELAY(10); > - err = ATA_IDX_INB(ch, ATA_ERROR); > - lsb = ATA_IDX_INB(ch, ATA_CYL_LSB); > - msb = ATA_IDX_INB(ch, ATA_CYL_MSB); > stat0 = ATA_IDX_INB(ch, ATA_STATUS); > - if (bootverbose) > - ata_printf(ch, ATA_MASTER, > - "stat=0x%02x err=0x%02x lsb=0x%02x msb=0x%02x\n", > - stat0, err, lsb, msb); > if (!(stat0 & ATA_S_BUSY)) { > + /* this should be there because of that condition... > + dont know why sos did this... */ > + err = ATA_IDX_INB(ch, ATA_ERROR); > + lsb = ATA_IDX_INB(ch, ATA_CYL_LSB); > + msb = ATA_IDX_INB(ch, ATA_CYL_MSB); > + if (bootverbose) > + ata_printf(ch, ATA_MASTER, > + "stat=0x%02x err=0x%02x lsb=0x%02x msb=0x%02x\n", > + stat0, err, lsb, msb); > if ((err & 0x7f) == ATA_E_ILI) { > if (lsb == ATAPI_MAGIC_LSB && msb == ATAPI_MAGIC_MSB) { > ch->devices |= ATA_ATAPI_MASTER; I use similar changes to avoid spec violations. Unfortunately sos doesn't like them. The strange order is a hack which is claimed to help for some out-of spec drives. It only breaks in-spec drives sometimes (if a race is lost). On many systems the order makes no difference because we waited a long time before beginning the loop, so all drives are already unbusy. Bruce