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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912140840.AAA86542>