Date: Wed, 17 Apr 2002 17:14:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: msch@snafu.de Cc: freebsd-current@freebsd.org Subject: Re: ATA errors on recent -current Message-ID: <3CBE0FF8.D1D1601F@mindspring.com> References: <E16xCAf-0005kI-00@smart.eusc.inter.net> <E16xYyx-0002DV-00@smart.eusc.inter.net> <3CBCCC84.4AFD0E68@mindspring.com> <E16xw5s-0004pc-00@clever.eusc.inter.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthias Schuendehuette wrote:
> > My hunch, which is why I suggested decreasing the number of
> > tags seen by the driver, is that the tagged queues are over
> > used, and this locks the disk up. [...]
>
> Yes, I understand this (I for myself had already your
> 'off-by-one'-suspicion - it's obvious if one sees the error message)
> and I'll test it ASAP.
>
> What I was wondering yesterday before I fell asleep is that the disk is
> obviously not able to recover from this error - even if the error
> condition is no longer valid due to the switch to PIO-mode. *Any*
> DMA-mode is no longer useable.
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).
This is what I was implying when I said that it involved error
handling with the decoupled operations, which John Baldwin took
exception to the idea ("It is still my hunch..."). I think that
control channel commands, which aren't data commands, need to be
explicitly serialized (maybe) on a reserved channel, to avoid the
problem. This takes 1/N tags out of service, but guarantees that
you can reset the disk drive or whatever.
> I don't know if it's an attribute of these disks or an issue solvable
> by a/the driver. I would expect to be able to do a software reset of
> the drive like with SCSI, but I'm a bit biased against ATA (vs. SCSI)
> because of the opinion/argues of a very knowledgeable guy here in the
> german newsgroup (former core team member ;-), so I wouldn't be
> surprised if that's not possible or not specified.
I'm personally very biased against ATA for most production use;
assuming you know your application, though, and there's not a
huge concurrent access requirement, then ATA is OK (I guess),
if you can live with the electrical limitations.
Manually hacking the drive probe/attach to halve the number of
tag queues that get used based on the reported values seems like
a very quick way to validate whether it's command queue overflow,
or an intrinsic problem with the drive, that's hanging you up.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBE0FF8.D1D1601F>