From owner-freebsd-current Thu Apr 18 8:13: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from clever.eusc.inter.net (clever.eusc.inter.net [213.73.101.4]) by hub.freebsd.org (Postfix) with ESMTP id 3AD2D37B400 for ; Thu, 18 Apr 2002 08:13:04 -0700 (PDT) Received: from tc12-n67-156.de.inter.net ([213.73.67.156] helo=there) by clever.eusc.inter.net with smtp (Exim 3.22 #3) id 16yDao-0005vq-00; Thu, 18 Apr 2002 17:13:02 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Matthias Schuendehuette Reply-To: msch@snafu.de Organization: Micro$oft-free Zone To: sos@freebsd.dk, Terry Lambert Subject: Re: ATA errors on recent -current Date: Thu, 18 Apr 2002 17:13:01 +0200 X-Mailer: KMail [version 1.3.1] Cc: freebsd-current@FreeBSD.ORG References: <200204181444.g3IEijc8048289@freebsd.dk> In-Reply-To: <200204181444.g3IEijc8048289@freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Am Donnerstag, 18. April 2002 16:44 schrieb Søren Schmidt: > It seems Terry Lambert wrote: > > "Søren Schmidt" wrote: > > > It seems Terry Lambert wrote: > > > > My other hunch is that there will need to be a channel reserved > > > > for "reset" commands to be queued to the disk, so that you can > > > > queue more commands to it later (e.g. can't connect to send the > > > > reset because of the already disconnected commands in > > > > progress). > > > > > > Terry, read the ATA spec, it doesn't work that way, tags on > > > ATA is very different from tags on SCSI, and beside a reset > > > is not a command, but a bit in a HW port.. > > > > I didn't mean for the reset itself, I meant for the process. You > > can't "take back" writes that are in progress and not acknowledged, > > in order to retry them after the reset, so as to not lose data. > > Oh yes you can, the ATA driver does just that in case of the drive > loosing its marbels. Does that mean that the driver isn't aware of the 'tags-problem'? If I understand you right, it should be possible to reset the drive and continue, maybe without tags or at a reduced UDMA-Speed or whatever actions seem appropriate... ...ahh, I mean, the driver *does* take an action (it/he(?) switches back to PIO4), but why is any UDMA-Mode no longer usable afterwards? Is the drive been reset or just switched back? What is the impact of a reset compared to a switch back? Well, just my thoghts, I'm no specialist at all.... -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message