From owner-freebsd-scsi Thu Dec 2 10:12: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1D6A714D2D for ; Thu, 2 Dec 1999 10:11:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA02497; Thu, 2 Dec 1999 10:10:49 -0800 Date: Thu, 2 Dec 1999 10:10:49 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Stephen McKay Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Tape driver problems In-Reply-To: <199912021530.BAA12298@nymph.detir.qld.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > "mt status" with no tape loaded gives an error: > > mt: /dev/nrsa0: Device not configured > > which seems a bit harsh. Also the kernel logs error messages like: Yes, let me think about the error a bit. It may be more a question of changing 'mt' to report something other than just perror. > > Dec 3 00:35:41 bucket /kernel: (sa0:aha0:0:5:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > Dec 3 00:35:41 bucket /kernel: (sa0:aha0:0:5:0): NOT READY asc:3a,0 > Dec 3 00:35:41 bucket /kernel: (sa0:aha0:0:5:0): Medium not present > Dec 3 00:35:41 bucket /kernel: (sa0:aha0:0:5:0): REWIND. CDB: 1 0 0 0 0 0 > Dec 3 00:35:41 bucket /kernel: (sa0:aha0:0:5:0): NOT READY asc:3a,0 > Dec 3 00:35:41 bucket /kernel: (sa0:aha0:0:5:0): Medium not present > > It seems like these should be silenced, I'll have to check what happened here. Do you have CAMDEBUG defined? >and not cause mt itself to fail. If you want mt to not 'fail', use the control device (rsa0.ctl), however this won't exercise any attempts at media detection. > This is an "old" problem, ie more than 2 weeks, at least. :-) > > "mt status" with a tape loaded gives the correct values (including density), > but the kernel spits out: > > Dec 3 00:44:36 bucket /kernel: bus_dmamap_load: Too many segs! buf_len = 0x3000 > > The last bit changes. I've seen 0xb000 or 0xd000 or 0xe000 or 0xf000 also. > This is a new problem related to the density autodetection read. I expect > that an aha1542B just can't read MAXPHYS bytes from anything. Hmm, indeed. The density determining code does indeed issue a read of MAXPHYS bytes. It seems to me that all HBA's should at least support that! The maintainer for the 1542X will have to speak to this tho... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message