From owner-freebsd-questions  Sun Sep 24 11:59:01 1995
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id LAA09579
          for questions-outgoing; Sun, 24 Sep 1995 11:59:01 -0700
Received: from everest (dtr.rain.com [204.119.8.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09566
          for <questions@freebsd.org>; Sun, 24 Sep 1995 11:58:54 -0700
From: bmk@dtr.com
Received: (from bmk@localhost) by everest (8.6.11/8.6.9) id LAA00435; Sun, 24 Sep 1995 11:47:11 -0700
Message-Id: <199509241847.LAA00435@everest>
Subject: Re: Odd SCSI errors
To: julian@ref.tfs.com (Julian Elischer)
Date: Sun, 24 Sep 1995 11:47:10 -0700 (PDT)
Cc: bmk@dtr.com, questions@freebsd.org
In-Reply-To: <199509241128.EAA05314@ref.tfs.com> from "Julian Elischer" at Sep 24, 95 04:28:35 am
Reply-To: bmk@dtr.com
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1641      
Sender: owner-questions@freebsd.org
Precedence: bulk

Thanks for explaining that.  Let me tell you about the circumstances
surrounding the error -

The error occured while elm was either trying to read the mail spool or
write a temporary mailbox in /tmp.  At first I thought it might be
a bad disk.

I fsck'ed the /tmp and /var filesystems from single user and the problem
went away.  It found a problem with /var/mail/bmk - but I don't recall
what it was.  The file was unlinked and all seems to be well now.

Unfortunately, I lost a couple of messages I was saving.  That's my
fault for leaving them in my mailbox.  :)

This is the first time I've lost any data - from a (probable)
non-hardware cause at lease.  I'd have to say that's a pretty good 
record since I've been running FreeBSD since 1.1 on several machines.
To be fair, it's entirely possible that this is hardware related, since
I had a few panics/reboots due to bad L2 cache.

...Just another testimonial as to the reliability of FreeBSD...

> > 
> > Can anyone explain the meaning of the following SCSI errors?
> > 
> > Sep 22 06:47:50 everest /kernel: bt0: bt_scsi_cmd, more than 33 DMA segs
> > Sep 22 06:47:50 everest /kernel: sd0: oops not queued

> Something has asked for a transfer that is too big..
> I wonder if the clustering code can cluster up a read/write that is too
> big for the device?

> > Sep 22 06:47:50 everest /kernel: biodone: buffer already done
> > Sep 22 06:47:50 everest /kernel: sd0(bt0:0:0): ILLEGAL REQUEST asc:21,0
> > 	Logical block address out of range field replaceable 
> > 	unit: 3 sks:cf,2

> I think this is a bad interpretation of the error above it..
> its a byproduct.. ignore it

> >