Date: Tue, 14 Dec 1999 00:40:03 -0800 (PST) From: Ken Harrenstien <klh@netcom.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/15448: Would be nice if the kernel could detect/report problems with SCSI tagged queueing Message-ID: <199912140840.AAA86542@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR kern/15448; it has been noted by GNATS.
From: Ken Harrenstien <klh@netcom.com>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: klh@netcom.com, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/15448: Would be nice if the kernel could detect/report
problems with SCSI tagged queueing
Date: Tue, 14 Dec 99 0:37:04 PST
> On Sun, Dec 12, 1999 at 06:52:28PM -0800, klh@netcom.com wrote:
> > >Synopsis: Would be nice if the kernel could detect/report problems with SCSI tagged queueing
>
> [ ... ]
>
> > FreeBSD <hostname> 3.1-RELEASE FreeBSD 3.1-RELEASE #<n>: <buildstring> i386
> > >Description:
> > I just spent a nerve-wracking day backing up some drives that I thought
> > were about to crash their little heads, only to finally discover that
> > the problem was a failure of SCSI command tagged queueing to work
> > properly.
> >
> > I was very surprised that even though I was getting user program I/O
> > errors (from tar), the kernel gave me no feedback at all on the
> > console. This was really mystifying. I don't know enough about how
> > tagging works to know whether it's even feasible to detect when it's
> > not working -- but the kernel is clearly getting SOME kind of error
> > that it's relaying back to the user.
> >
> > Would it be possible to make sure that I/O errors of this nature send
> > *something* to the console log? (Actually, that's a good idea for
> > any sort of I/O error; I know most of them are reported OK). This
> > would be a huge help tracking down potentially buggy drives; the effort
> > to zero in on this possibility is otherwise very time-consuming.
>
> I don't know why the kernel didn't print out any errors, but you'll get a
> lot more information if you boot with the '-v' switch. At the boot loader
> prompt, you can type:
>
> boot kernel -v
I know about (and like) -v, but it doesn't make any difference. Which
is to say, there is no error output either way. Just user-level I/O
errors except when a page transfer fails, in which case the pager code
then complains. Never the CAM subsystem.
One way of verifying this might be to test with a known broken drive
after re-enabling tagged queueing, and see what happens in the way of
error reporting.
Unfortunately I don't have any of the ones in the current table or I
could do that test. Regardless of the actual cause of the I/O errors,
it is still worrisome to me that there is no kernel log output at all.
--Ken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912140840.AAA86542>