From owner-freebsd-scsi Sun Mar 7 5:41: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 9868414D28 for ; Sun, 7 Mar 1999 05:40:38 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id OAA11147 for freebsd-scsi@freebsd.org; Sun, 7 Mar 1999 14:40:21 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10JdTs-000WycC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Sun, 7 Mar 1999 14:20:32 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Wangtek 51000HT tape drive Date: 7 Mar 1999 14:20:29 +0100 Message-ID: <7btuet$451$1@mips.rhein-neckar.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I moved my Wangtek 51000HT QIC-1000 drive from a Linux box, where it worked flawlessly, to my FreeBSD (4.0-CURRENT) box. Here's how the drive is detected: sa0 at ncr0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-CCS device sa0: 3.300MB/s transfers Now I'm trying to run a backup, "dump 0af /dev/nrsa0 / && dump 0af /dev/nrsa0 /usr". The first dump gets written fine, however when the second one starts writing to the tape during Pass II, I get an error and this: (sa0:ncr0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST Repeating this with cpio, writing the first archive succeeds, however writing a second one after that to the tape aborts with (sa0:ncr0:0:6:0): WRITE(06). CDB: a 0 0 78 0 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST Oh, and right now the kernel tells me (sa0:ncr0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST csi:0,8,0,0 right away in response to a freshly inserted tape. I kind of need this drive to do backups. Now, I'm one of those people who treat SCSI as "plug & play", i.e. I'm used to it just working. I guess the drive requires a "quirk" entry. Any suggestions how to proceed? -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de 100+ SF Book Reviews: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 14:18: 9 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 A545B14CB3 for ; Sun, 7 Mar 1999 14:18:07 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA10002; Sun, 7 Mar 1999 14:17:07 -0800 Date: Sun, 7 Mar 1999 14:17:06 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Christian Weisgerber Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: <7btuet$451$1@mips.rhein-neckar.de> 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 It's not detecting it as fixed length only device. The code tries to autodetect this but can fail. There's a quirk entry to add for it in scsi_sa.c. On 7 Mar 1999, Christian Weisgerber wrote: > I moved my Wangtek 51000HT QIC-1000 drive from a Linux box, where it > worked flawlessly, to my FreeBSD (4.0-CURRENT) box. Here's how the drive > is detected: > > sa0 at ncr0 bus 0 target 6 lun 0 > sa0: Removable Sequential Access SCSI-CCS device > sa0: 3.300MB/s transfers > > Now I'm trying to run a backup, "dump 0af /dev/nrsa0 / && dump 0af > /dev/nrsa0 /usr". The first dump gets written fine, however when the > second one starts writing to the tape during Pass II, I get an error and > this: > > (sa0:ncr0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 > (sa0:ncr0:0:6:0): ILLEGAL REQUEST > > Repeating this with cpio, writing the first archive succeeds, however > writing a second one after that to the tape aborts with > > (sa0:ncr0:0:6:0): WRITE(06). CDB: a 0 0 78 0 0 > (sa0:ncr0:0:6:0): ILLEGAL REQUEST > > Oh, and right now the kernel tells me > > (sa0:ncr0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 > (sa0:ncr0:0:6:0): ILLEGAL REQUEST csi:0,8,0,0 > > right away in response to a freshly inserted tape. > > I kind of need this drive to do backups. Now, I'm one of those people > who treat SCSI as "plug & play", i.e. I'm used to it just working. I > guess the drive requires a "quirk" entry. Any suggestions how to > proceed? > > -- > Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de > 100+ SF Book Reviews: > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 14:31:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 31850151DF for ; Sun, 7 Mar 1999 14:31:47 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.2/8.8.5) id PAA74982; Sun, 7 Mar 1999 15:31:19 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903072231.PAA74982@panzer.plutotech.com> Subject: Re: RAID saga In-Reply-To: <199903051045.NAA77228@sinbin.demos.su> from "Alex G. Bulushev" at "Mar 5, 1999 1:45:19 pm" To: bag@sinbin.demos.su (Alex G. Bulushev) Date: Sun, 7 Mar 1999 15:31:19 -0700 (MST) Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex G. Bulushev wrote... > > Justin T. Gibbs wrote... > > > > we use several IFT3102 without problems, it can work with fbsd cam as is > > > > or with path to scsi_da.c > > > > > > > > 127,135d126 > > > > < * Infortrend RAID controller doesn't like the > > > > < * synchronize cache command. > > > > < */ > > > > < {T_DIRECT, SIP_MEDIA_FIXED, "IFT", "3102", "01*"}, > > > > < /*quirks*/ DA_Q_NO_SYNC_CACHE > > > > < > > > > < }, > > > > > > This will disable tagged queueing (min and max tags default to 0 since > > > they are not initialized). Was this your intention? I would not expect > > > to see good performance from this array without tagged queueing turned > > > on. > > > > The quirk is for the DA driver, not the transport layer. (i.e., it won't > > affect tags) > > so this patch disable only sync cache command and it is usefull > commit it in -stable and -carrent, without this patch we see > not good messages when syncing disks: > > syncing disks... 22 22 13 1 done > (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 > (da1:ahc1:0:1:0): Invalid command operation code > (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 > (da2:ahc1:0:2:0): Invalid command operation code > (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 > (da3:ahc1:0:3:0): Invalid command operation code Those messages are harmless. Justin checked in some code into -current on Friday (and -stable on Saturday) that will silence the error messages if the error is illegal request. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 15: 0:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (Postfix) with ESMTP id D862D14D32; Sun, 7 Mar 1999 15:00:53 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA11588; Mon, 8 Mar 1999 00:00:34 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.6.9) id WAA01185; Sat, 6 Mar 1999 22:23:01 +0100 (CET) Date: Sat, 6 Mar 1999 22:23:00 +0100 From: Stefan Esser To: David Kelly Cc: Tom Torrance at home , scsi@freebsd.org, Stefan Esser Subject: Re: ncr timeout w/ RELENG_3 Message-ID: <19990306222300.B386@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: <199903020239.UAA01989@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199903020239.UAA01989@nospam.hiwaay.net>; from David Kelly on Mon, Mar 01, 1999 at 08:39:55PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-03-01 20:39 -0600, David Kelly wrote: > I wonder how much affect the NCR BIOS has on a running FreeBSD system? > Could it initialize something funny? Or load misbehaving code in the > SCSI chip? Am thinking if there is a BIOS upgrade for your board then > this might be the time to give it a try. The driver used to initialize just about any NCR register (killing any effect the BIOS might have had ;-) but does now preserve some of the settings. But there really should not be much of a difference, whether you boot from one version of SDMS or another. > My Asus SC875 has Symbios's 4.0.11 BIOS, but there is a 4.3 (?) > available for the download. *Had* to apply that upgrade to cards at work > to get them to work in another Asus motherboard. I understand that to mean that the BIOS update was required to make the system recognize the SCSI chip and load even the primary boot block ? If there is any system where the SCSI BIOS version makes a difference to the running kernel, please let me know! Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 15: 1: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (Postfix) with ESMTP id 6AA6A14D5B; Sun, 7 Mar 1999 15:00:59 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA11592; Mon, 8 Mar 1999 00:00:38 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.6.9) id WAA01176; Sat, 6 Mar 1999 22:15:36 +0100 (CET) Date: Sat, 6 Mar 1999 22:15:36 +0100 From: Stefan Esser To: Tom Torrance at home , Calvin Yee Cc: scsi@freebsd.org, Stefan Esser Subject: Re: ncr timeout w/ RELENG_3 Message-ID: <19990306221536.A386@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: <000501be6403$0aef7fa0$5c069a8e@stomp.xe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Tom Torrance at home on Mon, Mar 01, 1999 at 04:44:19PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-03-01 16:44 -0500, Tom Torrance at home wrote: > > Hi Tom, > > > > I too have the same problem w/ the "ncr0: timeout nccb= xxxxxxxx (skip)" > > error message. > > Did anyone respond to your email? Do you know have a solution? > > No, Cal, to both questions. Matt Jacob tells me that no one > wants to "own" that driver. My take is that if someone modifies it > they should at least own their changes :-\ Sorry, but is this the NCR 53c8xx driver you are talking about ? Sure, I think I'm still "owning" it, though my spare time is very limited and I only manage to scan my mail about every second weekend. (I have been maintaining the driver for so may years now, and was the co-author, when it was originally written in 386BSD times ;-) I did not have the time to work on porting the driver to CAM (except for some feedback sent to Justin Gibbs about his changes. But there are people reading the mail-lists, that used to forward any questions regarding the driver ... Anyway, I missed your original messages, but will try to locate it in previous weeks' unread mail. This reply is just meant to tell that I took notice of your problems. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 17:27:16 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 14F2114C85; Sun, 7 Mar 1999 17:27:14 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id RAA10559; Sun, 7 Mar 1999 17:26:46 -0800 Date: Sun, 7 Mar 1999 17:26:46 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Stefan Esser Cc: Tom Torrance at home , Calvin Yee , scsi@FreeBSD.ORG Subject: Re: ncr timeout w/ RELENG_3 In-Reply-To: <19990306221536.A386@dialup124.mi.uni-koeln.de> 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 Oh- Stefan? You're still maintaining the NCR? I'll keep that in mind and send things your way then... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 17:34: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 6CA4B14D2D for ; Sun, 7 Mar 1999 17:34:03 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id CAA27614 for freebsd-scsi@freebsd.org; Mon, 8 Mar 1999 02:33:45 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10JnkF-000WydC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Mon, 8 Mar 1999 01:18:07 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Wangtek 51000HT tape drive Date: 8 Mar 1999 01:18:03 +0100 Message-ID: <7bv4vr$99v$1@mips.rhein-neckar.de> References: <7btuet$451$1@mips.rhein-neckar.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > It's not detecting it as fixed length only device. The code tries to > autodetect this but can fail. > > There's a quirk entry to add for it in scsi_sa.c. I'm not sure I understand. Let's see... /sys/cam/scsi/scsi_sa.c Are you saying that I should duplicate that entry for the Wangtek 5525ES in the quirk table for the 51000HT? -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de >H Deutsche Transhumanismus-Mailingliste echo 'subscribe trans-de' | mail majordomo@lists.rhein-neckar.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 17:41:27 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 46AF314F2B for ; Sun, 7 Mar 1999 17:41:22 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id RAA10584; Sun, 7 Mar 1999 17:40:51 -0800 Date: Sun, 7 Mar 1999 17:40:51 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Christian Weisgerber Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: <7bv4vr$99v$1@mips.rhein-neckar.de> 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 > > I'm not sure I understand. > > Let's see... /sys/cam/scsi/scsi_sa.c > Are you saying that I should duplicate that entry for the Wangtek 5525ES > in the quirk table for the 51000HT? Yes. If it works, send it to me and I'll check it in in a variety of places. The deal here is that QIC drives are much in the minority, so I changed the driver to try and force variable mode as the default. Unfortunately a number of drives accept the mode select to do this when they really *can't* do variable mode. Apparently the 51000HT is another one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 17:55:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duey.wolves.k12.mo.us (duey.wolves.k12.mo.us [207.160.214.9]) by hub.freebsd.org (Postfix) with ESMTP id 5BBEF14D39 for ; Sun, 7 Mar 1999 17:55:41 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from duey.wolves.k12.mo.us (cdillon@duey.wolves.k12.mo.us [207.160.214.9]) by duey.wolves.k12.mo.us (8.8.8/8.8.8) with ESMTP id TAA06029; Sun, 7 Mar 1999 19:55:11 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Sun, 7 Mar 1999 19:55:10 -0600 (CST) From: Chris Dillon To: Matthew Jacob Cc: Christian Weisgerber , freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: 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 On Sun, 7 Mar 1999, Matthew Jacob wrote: > > > > > I'm not sure I understand. > > > > Let's see... /sys/cam/scsi/scsi_sa.c > > Are you saying that I should duplicate that entry for the Wangtek 5525ES > > in the quirk table for the 51000HT? > > Yes. If it works, send it to me and I'll check it in in a variety of > places. > > > The deal here is that QIC drives are much in the minority, so I changed > the driver to try and force variable mode as the default. Unfortunately a > number of drives accept the mode select to do this when they really > *can't* do variable mode. Apparently the 51000HT is another one. I must have missed the first part of this thread, or forgot that I actually had a Wangtek 51000 (apparently not HT). sa0: Removable Sequential Access SCSI-CCS device It has been working fine for me with 32k block sizes. Need me to test anything? I'm running 3.1-STABLE. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net /* FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and compatibles (SPARC and Alpha under development) ( http://www.freebsd.org ) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 17:57:26 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 9316214DDC for ; Sun, 7 Mar 1999 17:57:24 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id RAA10683; Sun, 7 Mar 1999 17:56:51 -0800 Date: Sun, 7 Mar 1999 17:56:51 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Dillon Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: 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 > > > > > > I'm not sure I understand. > > > > > > Let's see... /sys/cam/scsi/scsi_sa.c > > > Are you saying that I should duplicate that entry for the Wangtek 5525ES > > > in the quirk table for the 51000HT? > > > > Yes. If it works, send it to me and I'll check it in in a variety of > > places. > > > > > > The deal here is that QIC drives are much in the minority, so I changed > > the driver to try and force variable mode as the default. Unfortunately a > > number of drives accept the mode select to do this when they really > > *can't* do variable mode. Apparently the 51000HT is another one. > > I must have missed the first part of this thread, or forgot that I > actually had a Wangtek 51000 (apparently not HT). > > sa0: Removable Sequential Access SCSI-CCS > device > > It has been working fine for me with 32k block sizes. Need me to test > anything? I'm running 3.1-STABLE. > Um- what does mt -f status say right after you boot? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 18: 9:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 7919114E40; Sun, 7 Mar 1999 18:08:46 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-156.dialup.HiWAAY.net [216.180.15.156]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id UAA28857; Sun, 7 Mar 1999 20:08:25 -0600 (CST) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id UAA47527; Sun, 7 Mar 1999 20:08:20 -0600 (CST) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199903080208.UAA47527@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: se@FreeBSD.ORG Cc: scsi@FreeBSD.ORG From: David Kelly Subject: Re: ncr timeout w/ RELENG_3 In-reply-to: Message from Stefan Esser of "Sat, 06 Mar 1999 22:23:00 +0100." <19990306222300.B386@dialup124.mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Mar 1999 20:08:20 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser writes: > > My Asus SC875 has Symbios's 4.0.11 BIOS, but there is a 4.3 (?) > > available for the download. *Had* to apply that upgrade to cards at work > > to get them to work in another Asus motherboard. > > I understand that to mean that the BIOS update was required to make > the system recognize the SCSI chip and load even the primary boot > block ? Uh, something in the MB BIOS (it was a dual P-II Asus MB with one P-II and onboard Adaptec, P-somthing-97-with-an-S-somewhere) recognized the Asus SC875 well enough to lock up the entire system in boot. Part of the problem (I now recognize) was some NCR/Symbios BIOS's have fits if a HD is not on their bus at boot time. Tried the above with nothing. And with Seagate Scorpion DDS-3 drives. Seems the last message printed to the screen was, "^C for BIOS Setup". New BIOS flashed into the SC875's (there were two in this system) cured my booting problems. Now I'm thinking the sa driver or something is performing reliably but something about the 3.1 scheduler, buffering, or the lack of buffering, is causing performance to be less than what the hardware is capable of. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 7 20:34:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duey.wolves.k12.mo.us (duey.wolves.k12.mo.us [207.160.214.9]) by hub.freebsd.org (Postfix) with ESMTP id B720714F6A for ; Sun, 7 Mar 1999 20:34:33 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from duey.wolves.k12.mo.us (cdillon@duey.wolves.k12.mo.us [207.160.214.9]) by duey.wolves.k12.mo.us (8.8.8/8.8.8) with ESMTP id WAA06507; Sun, 7 Mar 1999 22:34:13 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Sun, 7 Mar 1999 22:34:13 -0600 (CST) From: Chris Dillon To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: 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 On Sun, 7 Mar 1999, Matthew Jacob wrote: > > > > > > > > > I'm not sure I understand. > > > > > > > > Let's see... /sys/cam/scsi/scsi_sa.c > > > > Are you saying that I should duplicate that entry for the Wangtek 5525ES > > > > in the quirk table for the 51000HT? > > > > > > Yes. If it works, send it to me and I'll check it in in a variety of > > > places. > > > > > > > > > The deal here is that QIC drives are much in the minority, so I changed > > > the driver to try and force variable mode as the default. Unfortunately a > > > number of drives accept the mode select to do this when they really > > > *can't* do variable mode. Apparently the 51000HT is another one. > > > > I must have missed the first part of this thread, or forgot that I > > actually had a Wangtek 51000 (apparently not HT). > > > > sa0: Removable Sequential Access SCSI-CCS > > device > > > > It has been working fine for me with 32k block sizes. Need me to test > > anything? I'm running 3.1-STABLE. > > > > Um- what does mt -f status say right after you boot? Since you asked, I decided to document every move I made. Contrary to Murphy's Law, I didn't notice the problems until I started looking for them. :-) I didn't mean I had set the block sizes on tape to 32k with something like 'mt blocksize 32768'... I had actually managed to set it to 'variable' blocksize and had 'team' working with 32k blocks. Sorry about that irrelevant remark. :-) Running 3.1-19990228-STABLE Fresh cold boot.. no tape. root@cheetah [/root] # mt status Mode Density Blocksize bpi Compression Current: QIC-320 512 bytes 16000 unsupported ---------available modes--------- 0: QIC-320 512 bytes 16000 unsupported 1: QIC-320 512 bytes 16000 unsupported 2: QIC-320 512 bytes 16000 unsupported 3: QIC-320 512 bytes 16000 unsupported --------------------------------- Current Driver State: at rest. "3M Magnus 1.2" tape inserted. Same 'mt status' output. root@cheetah [/root] # tar cv . (sa0:ncr0:0:5:0): MODE SELECT(06). CDB: 15 0 0 0 c 0 (sa0:ncr0:0:5:0): ILLEGAL REQUEST csi:0,8,0,0 (sa0:ncr0:0:5:0): unable to set fixed blocksize to 512 tar: can't open /dev/rsa0 : Invalid argument Hmmm... remove tape, reinsert it. root@cheetah [/root] # mt status Mode Density Blocksize bpi Compression Current: ECMA TC17 512 bytes 45434 unsupported ---------available modes--------- 0: ECMA TC17 512 bytes 45434 unsupported 1: ECMA TC17 512 bytes 45434 unsupported 2: ECMA TC17 512 bytes 45434 unsupported 3: ECMA TC17 512 bytes 45434 unsupported --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Hmmm again. root@cheetah [/root] # mt offline root@cheetah [/root] # mt status Mode Density Blocksize bpi Compression Current: 0x00 variable 0 unsupported ---------available modes--------- 0: 0x00 variable 0 unsupported 1: 0x00 variable 0 unsupported 2: 0x00 variable 0 unsupported 3: 0x00 variable 0 unsupported --------------------------------- Current Driver State: at rest. root@cheetah [/root] # mt blocksize 512 root@cheetah [/root] # tar czv . At this point, it tars up 13MB of data, but right at the end I get: (sa0:ncr0:0:5:0): Invalid request. Fixed block device requests must be a multiple of 1 bytes tar (child): can't write to /dev/rsa0 : Invalid argument root@cheetah [/root] # mt blocksize 0 root@cheetah [/root] # tar czv . [tars up about 13MB of data and spits it to tape... no errors] root@cheetah [/root] # tar tzv [lists every file tarred in previous command... no errors] Weird. Did that help any? :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net /* FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and compatibles (SPARC and Alpha under development) ( http://www.freebsd.org ) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 8 3:30: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 3E98314EDC for ; Mon, 8 Mar 1999 03:30:04 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id MAA05548 for freebsd-scsi@freebsd.org; Mon, 8 Mar 1999 12:29:46 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10Jx6G-000WydC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Mon, 8 Mar 1999 11:17:28 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Wangtek 51000HT tape drive Date: 8 Mar 1999 11:17:25 +0100 Message-ID: <7c083l$di6$1@mips.rhein-neckar.de> References: To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Dillon wrote: > I must have missed the first part of this thread, or forgot that I > actually had a Wangtek 51000 (apparently not HT). > > sa0: Removable Sequential Access SCSI-CCS > device Well, it says "51000HT" on the OEM installation sheet that came with the drive. The kernel detects it as sa0: Removable Sequential Access SCSI-CCS device I'll try Matthew's suggestion. Gotta do a "make world" first, though, which takes a few hours on a P-100... and just bombed out. This may still take a bit. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de See another pointless homepage at . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 8 9:31:45 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 8C88D14BE0 for ; Mon, 8 Mar 1999 09:31:42 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA13294; Mon, 8 Mar 1999 09:31:11 -0800 Date: Mon, 8 Mar 1999 09:31:11 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Dillon Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: 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 I am *very* confused now. Looks like things are pretty badly broken. The read block limits command is broken. The mode select is broken. In a couple of days I'll integrate a couple more changes in -current, and I'll do a Move from Current to -STABLE if folks can do some testing to see if this gets things fixed. > Since you asked, I decided to document every move I made. Contrary to > Murphy's Law, I didn't notice the problems until I started looking for > them. :-) > > I didn't mean I had set the block sizes on tape to 32k with something > like 'mt blocksize 32768'... I had actually managed to set it to > 'variable' blocksize and had 'team' working with 32k blocks. Sorry > about that irrelevant remark. :-) > > Running 3.1-19990228-STABLE > > Fresh cold boot.. no tape. > > root@cheetah [/root] # mt status > Mode Density Blocksize bpi Compression > Current: QIC-320 512 bytes 16000 unsupported > ---------available modes--------- > 0: QIC-320 512 bytes 16000 unsupported > 1: QIC-320 512 bytes 16000 unsupported > 2: QIC-320 512 bytes 16000 unsupported > 3: QIC-320 512 bytes 16000 unsupported > --------------------------------- > Current Driver State: at rest. > > "3M Magnus 1.2" tape inserted. Same 'mt status' output. > > root@cheetah [/root] # tar cv . > (sa0:ncr0:0:5:0): MODE SELECT(06). CDB: 15 0 0 0 c 0 > (sa0:ncr0:0:5:0): ILLEGAL REQUEST csi:0,8,0,0 > (sa0:ncr0:0:5:0): unable to set fixed blocksize to 512 > tar: can't open /dev/rsa0 : Invalid argument > > Hmmm... remove tape, reinsert it. > > root@cheetah [/root] # mt status > Mode Density Blocksize bpi Compression > Current: ECMA TC17 512 bytes 45434 unsupported > ---------available modes--------- > 0: ECMA TC17 512 bytes 45434 unsupported > 1: ECMA TC17 512 bytes 45434 unsupported > 2: ECMA TC17 512 bytes 45434 unsupported > 3: ECMA TC17 512 bytes 45434 unsupported > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 0 > > Hmmm again. > > root@cheetah [/root] # mt offline > root@cheetah [/root] # mt status > Mode Density Blocksize bpi Compression > Current: 0x00 variable 0 unsupported > ---------available modes--------- > 0: 0x00 variable 0 unsupported > 1: 0x00 variable 0 unsupported > 2: 0x00 variable 0 unsupported > 3: 0x00 variable 0 unsupported > --------------------------------- > Current Driver State: at rest. > > root@cheetah [/root] # mt blocksize 512 > root@cheetah [/root] # tar czv . > > At this point, it tars up 13MB of data, but right at the end I get: > > (sa0:ncr0:0:5:0): Invalid request. Fixed block device requests must > be a multiple of 1 bytes > tar (child): can't write to /dev/rsa0 : Invalid argument > > root@cheetah [/root] # mt blocksize 0 > root@cheetah [/root] # tar czv . > [tars up about 13MB of data and spits it to tape... no errors] > root@cheetah [/root] # tar tzv > [lists every file tarred in previous command... no errors] > > Weird. Did that help any? :-) > > > -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net > /* FreeBSD: The fastest and most stable server OS on the planet. > For Intel x86 and compatibles (SPARC and Alpha under development) > ( http://www.freebsd.org ) */ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 8 9:42:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duey.wolves.k12.mo.us (duey.wolves.k12.mo.us [207.160.214.9]) by hub.freebsd.org (Postfix) with ESMTP id DDC3314E30 for ; Mon, 8 Mar 1999 09:42:55 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from duey.wolves.k12.mo.us (cdillon@duey.wolves.k12.mo.us [207.160.214.9]) by duey.wolves.k12.mo.us (8.8.8/8.8.8) with ESMTP id LAA09995; Mon, 8 Mar 1999 11:42:31 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Mon, 8 Mar 1999 11:42:31 -0600 (CST) From: Chris Dillon To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: 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 On Mon, 8 Mar 1999, Matthew Jacob wrote: > > I am *very* confused now. Looks like things are pretty badly broken. The > read block limits command is broken. The mode select is broken. > > In a couple of days I'll integrate a couple more changes in -current, and > I'll do a Move from Current to -STABLE if folks can do some testing to see > if this gets things fixed. I'll be more than happy to do some testing. I have plenty of blank tapes and more than enough data to fill one up. I wonder if I can get a firmware upgrade for this thing, or if I should... Its actually a Compaq incarnation of the WangTek 51000, though I don't think they changed anything. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net /* FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and compatibles (SPARC and Alpha under development) ( http://www.freebsd.org ) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 2:10:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 07A0115040 for ; Tue, 9 Mar 1999 02:10:32 -0800 (PST) (envelope-from freebsd@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10KJSk-000HytC; Tue, 9 Mar 1999 05:10:10 -0500 (EST) Message-Id: From: freebsd@tomqnx.com (Tom Torrance) Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: from Matthew Jacob at "Mar 8, 1999 7:50:26 am" To: mjacob@feral.com Date: Tue, 9 Mar 1999 05:10:10 -0500 (EST) Cc: scsi@freebsd.org, tom@tomqnx.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM920974210-19344-0_ Content-Transfer-Encoding: 7bit Content-Length: 5661 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM920974210-19344-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > What errors? And what 'does not honor'? I know that Tom Torrance claimed > this happened- which I can't reproduce. RELENG_3 generates errors. Your routine to rewind the tape at EOM is activated by those errors. The test version of "current" that you sent me does not generate those errors. Your routine to rewind the tape is not activated. Attached you will find a backup script and the associated errors generated from it using today's version of RELENG_3. More errors than usual are generated now. It used to only complain about the PREVENT/ALLOW. Using RELENG_3 the tape always rewinds on the "DUMP: Closing /dev/nrsa0" message which appears on the console. Note that a person running X-windows would not see the error messages. Regards, Tom > > On 8 Mar 1999, Chris Shenton wrote: > > > Oops, should have provided details on the drive; dmesg says: > > > > ahc0: rev 0x03 int a irq 9 on pci0.8.0 > > ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs > > > > sa0 at ahc0 bus 0 target 5 lun 0 > > sa0: Removable Sequential Access SCSI-2 device > > sa0: 3.300MB/s transfers > > > > da0 at ahc0 bus 0 target 3 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > > da0: 8682MB (17781964 512 byte sectors: 255H 63S/T 1106C) > > changing root device to da0s1a > > > > cd0 at ahc0 bus 0 target 2 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 5.681MB/s transfers (5.681MHz, offset 15) > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > --ELM920974210-19344-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=dmesg Content-Description: dmesg Content-Transfer-Encoding: 7bit evice sa0: 3.300MB/s transfers pass0 at ncr0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number JKA5580002KB3M pass0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled pass1 at ncr0 bus 0 target 5 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 3.300MB/s transfers pass2 at ncr0 bus 0 target 6 lun 0 pass2: Removable Sequential Access SCSI-2 device pass2: 3.300MB/s transfers cd0 at ncr0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: cd present [253970 x 2048 byte records] da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number JKA5580002KB3M da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) Considering FFS root f/s. changing root device to da0s2a da0s1: type 0x6, start 63, end = 1025891, size 1025829 : OK da0s2: type 0xa5, start 1025892, end = 8885267, size 7859376 : OK ffs_mountfs: superblock updated for soft updates (sa0:ncr0:0:6:0): MODE SENSE(06). CDB: 1a 0 f 0 1c 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:24,0 (sa0:ncr0:0:6:0): Invalid field in CDB (sa0:ncr0:0:6:0): MODE SELECT(06). CDB: 15 0 0 0 c 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:26,0 (sa0:ncr0:0:6:0): Invalid field in parameter list (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code (sa0:ncr0:0:6:0): SPACE. CDB: 11 1 ff ff ff 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:2c,0 (sa0:ncr0:0:6:0): Command sequence error (sa0:ncr0:0:6:0): unable to backspace over one of double filemarks at EOD- opting for safety (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code (sa0:ncr0:0:6:0): SPACE. CDB: 11 1 ff ff ff 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:2c,0 (sa0:ncr0:0:6:0): Command sequence error (sa0:ncr0:0:6:0): unable to backspace over one of double filemarks at EOD- opting for safety (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code (sa0:ncr0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (sa0:ncr0:0:6:0): ILLEGAL REQUEST asc:20,0 (sa0:ncr0:0:6:0): Invalid command operation code --ELM920974210-19344-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=backup Content-Description: backup script Content-Transfer-Encoding: 7bit #!/bin/sh # System Backup export TAPE=/dev/nrsa0 mt rewind mt status >/dev/null 2>&1 dump 0abuf 64 /dev/nrsa0 / dump 0abuf 64 /dev/nrsa0 /usr mt rewind --ELM920974210-19344-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 4:48: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from amethyst.bsdx.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 33EB614E7E for ; Tue, 9 Mar 1999 04:47:49 -0800 (PST) (envelope-from bsdx@spawnet.com) Received: from spawnet.com (localhost [127.0.0.1]) by amethyst.bsdx.net (8.9.3/8.9.1) with ESMTP id HAA29596 for ; Tue, 9 Mar 1999 07:47:30 -0500 (EST) (envelope-from bsdx@spawnet.com) Message-ID: <36E51861.5CA0A408@spawnet.com> Date: Tue, 09 Mar 1999 07:47:29 -0500 From: Adam McDougall X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 4.0-CURRENT i386) MIME-Version: 1.0 To: scsi@freebsd.org Subject: Support for 53C876 (as found in fireport 40 dual) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I couldnt find this number in ncr.c nor any mention of dual, would this board be unsupported then? I recently became interested because diamondmm seems to be having a sale.. fireport 40 (a uw card) for $49.95, and the dual channel version for $69.95. If the dual would work with freebsd, I'd like to know, because it costs less than some singlechannel boards :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 7: 4:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from absinthe.shenton.org (Absinthe.Shenton.Org [209.31.147.194]) by hub.freebsd.org (Postfix) with ESMTP id 41AAF14F97 for ; Tue, 9 Mar 1999 07:04:00 -0800 (PST) (envelope-from chris@shenton.org) Received: (from chris@localhost) by absinthe.shenton.org (8.9.1/8.9.1) id KAA17729; Tue, 9 Mar 1999 10:03:32 -0500 (EST) To: mjacob@feral.com Cc: tom@tomqnx.com, scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs References: X-Emacs: Emacs 20.3, MULE 4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.8.5 - "Nishi-Takaoka") Content-Type: text/plain; charset=US-ASCII From: Chris Shenton Date: 09 Mar 1999 10:03:31 -0500 In-Reply-To: Matthew Jacob's message of "Mon, 8 Mar 1999 07:50:26 -0800 (PST)" Message-ID: <87aexm7lj0.fsf@absinthe.shenton.org> Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Changed CC from hackers@ to scsi@ --chris] Matthew Jacob writes: > What errors? And what 'does not honor'? I know that Tom Torrance claimed > this happened- which I can't reproduce. I posted them in the previous message. It was on a 3.1-STABLE system built from source cvsupped about 3 days ago. Here's what dmesg says: (sa0:ahc0:0:5:0): SPACE. CDB: 11 1 ff ff ff 0 (sa0:ahc0:0:5:0): ILLEGAL REQUEST asc:2c,0 (sa0:ahc0:0:5:0): Command sequence error (sa0:ahc0:0:5:0): unable to backspace over one of double filemarks at EOD- opting for safety This occurs just after a dump completes and says "closing device sa0", before the next dump begins. So it overwrites each dump file due to the rewind. I don't see the PREVENT/ALLOW messages that Tom cites, but he's right about not seeing the messages if you're using an Xterm; I missed 'em for a day. Is there anything I can do to help locate the source of the bug? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 7:14:19 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 DFC2114F90 for ; Tue, 9 Mar 1999 07:14:16 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id HAA18008; Tue, 9 Mar 1999 07:13:37 -0800 Date: Tue, 9 Mar 1999 07:13:37 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Shenton Cc: tom@tomqnx.com, scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: <87aexm7lj0.fsf@absinthe.shenton.org> 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 Yes- I added the code that tries to unload the tape if things get screwed up- but some tapes don't eject. Let's get a sense from y'all- is this a bad idea? Frankly, dump and tar and other backup programs are fantastically broken if they don't, at each open, always either explicitly position to a known locatio, or get position information and use that, or explicitly space to EOD. It seems to me that if you've lost position information you should try and force the tape out. -matt On 9 Mar 1999, Chris Shenton wrote: > [Changed CC from hackers@ to scsi@ --chris] > > Matthew Jacob writes: > > > What errors? And what 'does not honor'? I know that Tom Torrance claimed > > this happened- which I can't reproduce. > > I posted them in the previous message. It was on a 3.1-STABLE system > built from source cvsupped about 3 days ago. Here's what dmesg says: > > (sa0:ahc0:0:5:0): SPACE. CDB: 11 1 ff ff ff 0 > (sa0:ahc0:0:5:0): ILLEGAL REQUEST asc:2c,0 > (sa0:ahc0:0:5:0): Command sequence error > (sa0:ahc0:0:5:0): unable to backspace over one of double filemarks at EOD- opting for safety > > This occurs just after a dump completes and says "closing device sa0", > before the next dump begins. So it overwrites each dump file due to > the rewind. > > I don't see the PREVENT/ALLOW messages that Tom cites, but he's right > about not seeing the messages if you're using an Xterm; I missed 'em > for a day. > > Is there anything I can do to help locate the source of the bug? > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 9:30:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id C416715056 for ; Tue, 9 Mar 1999 09:30:46 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id SAA02155 for scsi@FreeBSD.ORG; Tue, 9 Mar 1999 18:30:19 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 60191883F; Tue, 9 Mar 1999 15:38:55 +0100 (CET) Date: Tue, 9 Mar 1999 15:38:55 +0100 From: Ollivier Robert To: scsi@FreeBSD.ORG Subject: Re: Support for 53C876 (as found in fireport 40 dual) Message-ID: <19990309153855.A6213@keltia.freenix.fr> Mail-Followup-To: scsi@FreeBSD.ORG References: <36E51861.5CA0A408@spawnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: <36E51861.5CA0A408@spawnet.com>; from Adam McDougall on Tue, Mar 09, 1999 at 07:47:29AM -0500 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5120 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Adam McDougall: > I couldnt find this number in ncr.c nor any mention of dual, would this > board be unsupported then? I recently became interested because The 876 is just a dual-875 card so 1) it will work and 2) you'll see two 875 in your system. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 10:44:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from nezu.gs.verio.net (nezu.gs.verio.net [204.27.67.227]) by hub.freebsd.org (Postfix) with ESMTP id B10C114FF4 for ; Tue, 9 Mar 1999 10:44:16 -0800 (PST) (envelope-from rzig@verio.net) Received: by nezu.internal with Internet Mail Service (5.5.2232.9) id ; Tue, 9 Mar 1999 12:43:55 -0600 Message-ID: <79103FDEF940D2118D9D00A0C9C9309C2927AF@nezu.internal> From: Raul Zighelboim To: "'scsi@freebsd.org'" Subject: Hellp 'scsi errors' Date: Tue, 9 Mar 1999 12:43:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Running FreeBSD-stable... ahc0: rev 0x00 int a irq 11 on pci0.13.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 64H 32S/T 4340C) I cannot shutdown! su-2.02# shutdown -r now su: /sbin/shutdown: Input/output error (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=6) size: 65536, resid: 65536, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 12:13:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from absinthe.shenton.org (Absinthe.Shenton.Org [209.31.147.194]) by hub.freebsd.org (Postfix) with ESMTP id 6CEAB154CF for ; Tue, 9 Mar 1999 12:13:10 -0800 (PST) (envelope-from chris@shenton.org) Received: (from chris@localhost) by absinthe.shenton.org (8.9.1/8.9.1) id PAA18836; Tue, 9 Mar 1999 15:12:39 -0500 (EST) To: mjacob@feral.com Cc: tom@tomqnx.com, scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs References: X-Emacs: Emacs 20.3, MULE 4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.8.5 - "Nishi-Takaoka") Content-Type: text/plain; charset=US-ASCII From: Chris Shenton Date: 09 Mar 1999 15:12:38 -0500 In-Reply-To: Matthew Jacob's message of "Tue, 9 Mar 1999 07:13:37 -0800 (PST)" Message-ID: <874snu777t.fsf@absinthe.shenton.org> Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > Yes- I added the code that tries to unload the tape if things get screwed > up- but some tapes don't eject. The Travan-TR4's (and probably any QIC) won't eject. > Let's get a sense from y'all- is this a bad idea? Frankly, dump and tar > and other backup programs are fantastically broken if they don't, at each > open, always either explicitly position to a known locatio, or get > position information and use that, or explicitly space to EOD. It seems to > me that if you've lost position information you should try and force the > tape out. I dunno. I recall seeing some amusing comment on the "sa" or "scsi" man page something about "we don't know why it's done this way but we follow the convention that...". Frankly, if the "better" way breaks existing behavier, then it's not a win for the users. There's plenty of braindead hardware out there in the PeeCee world :-( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 12:59:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id BA85114F1B for ; Tue, 9 Mar 1999 12:58:44 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10KTZn-000I4EC; Tue, 9 Mar 1999 15:58:07 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: from Matthew Jacob at "Mar 9, 1999 7:13:37 am" To: mjacob@feral.com Date: Tue, 9 Mar 1999 15:58:07 -0500 (EST) Cc: chris@shenton.org, scsi@freebsd.org, tom@tomqnx.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3861 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Yes- I added the code that tries to unload the tape if things get screwed > up- but some tapes don't eject. > > Let's get a sense from y'all- is this a bad idea? Frankly, dump and tar > and other backup programs are fantastically broken if they don't, at each > open, always either explicitly position to a known locatio, or get > position information and use that, or explicitly space to EOD. It seems to > me that if you've lost position information you should try and force the > tape out. > > -matt Howdy, Matt! This is a very well put argument for never doing ANYTHING at the driver level that would cause a backup program to lose position information. When you are working with a modern device driver, it is a temptation to do lots of nice sophisticated things - because you can. The thing is, though, that you are doing something that used to be done in hardware. They were dumb. Essentially, they still are, in that they have no idea what is happening at the application layer. There is a class of error that must be handled at the application layer because the device driver has no idea what to do about it. EOM is one of them. The shear fact that you have detected a reflective spot on the tape does not mean that the application has finished writing to it. Depending on the sophistication of the application, it may still have to write EOV (end of volume) labels or some such foolishness before the double TM is written. It definitely has to know that following the next open, it has to write beginning of volume label(s) before writing any data, if it is doing volume labels at all (e.g. optional with 'tar'). Even simple things - like a normal I/O error, the application would like to know about. If you "man dump" you will see that dump wants to know about them, as it will force EOM processing after a default of 30 I/O errors on a volume irrespective of the amount of tape used. I am very surprised that these issues are not explicitely addressed by RFCs or SCSI standards, or whatever. In the event that they are not, I recommend that you look at the code of some backup programs of some sophistication (amanda and dump, perhaps) and determine what their expectations are. Give them what they want, unless you have a very good reason to do otherwise. Alternatively, do not take actions that other drivers do not. Applications have a right to expect consistant interfaces to their media, no matter what hardware/os they are dealing with. In summary, I think it a very poor idea for the tape driver to take any unilateral action that would affect tape positioning. It is worthy of note that you are taking the action in instances where EOM has NOT occured. Just My Humble (very long-winded) Opinion... Cheers, Tom > > > > > On 9 Mar 1999, Chris Shenton wrote: > > > [Changed CC from hackers@ to scsi@ --chris] > > > > Matthew Jacob writes: > > > > > What errors? And what 'does not honor'? I know that Tom Torrance claimed > > > this happened- which I can't reproduce. > > > > I posted them in the previous message. It was on a 3.1-STABLE system > > built from source cvsupped about 3 days ago. Here's what dmesg says: > > > > (sa0:ahc0:0:5:0): SPACE. CDB: 11 1 ff ff ff 0 > > (sa0:ahc0:0:5:0): ILLEGAL REQUEST asc:2c,0 > > (sa0:ahc0:0:5:0): Command sequence error > > (sa0:ahc0:0:5:0): unable to backspace over one of double filemarks at EOD- opting for safety > > > > This occurs just after a dump completes and says "closing device sa0", > > before the next dump begins. So it overwrites each dump file due to > > the rewind. > > > > I don't see the PREVENT/ALLOW messages that Tom cites, but he's right > > about not seeing the messages if you're using an Xterm; I missed 'em > > for a day. > > > > Is there anything I can do to help locate the source of the bug? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 13:10:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id A1DFD14FDB for ; Tue, 9 Mar 1999 13:09:55 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10KTka-000I4EC; Tue, 9 Mar 1999 16:09:16 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: <874snu777t.fsf@absinthe.shenton.org> from Chris Shenton at "Mar 9, 1999 3:12:38 pm" To: chris@shenton.org (Chris Shenton) Date: Tue, 9 Mar 1999 16:09:16 -0500 (EST) Cc: mjacob@feral.com, tom@tomqnx.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 205 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Frankly, if the "better" way breaks existing behavier, then it's not a > win for the users. There's plenty of braindead hardware out there in > the PeeCee world :-( Amen. Very well put. Cheers, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 15:21:52 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 470C214F4A for ; Tue, 9 Mar 1999 15:21:49 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id PAA20219; Tue, 9 Mar 1999 15:21:02 -0800 Date: Tue, 9 Mar 1999 15:21:02 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Tom Torrance at home Cc: chris@shenton.org, scsi@freebsd.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: 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 > > This is a very well put argument for never doing ANYTHING at the driver > level that would cause a backup program to lose position information. > All very cogent arguments, except it is the broken applications here that the tape needs to be protected from. I'm writing (or reading) a tape. Something bad happens such that the tape driver loses a notion of where it is. Previously, nothing would happen- leading you to often either overwrite tapes or write them with an inconsistent set of filemarks. I added in a change that should (for most drives) eject the tape. This has turned out to be less than desirable for tapes that can't eject. Here's the alternative I'll offer: If the driver loses position, it will refuse to accept any I/O until either a rewind or an explicit space to EOD, or an unload occurs. This is somewhat trickier than other cases because I'll have to allow opens but no operations but the three mentioned. Opinions? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 9 19:29:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 356C914E22 for ; Tue, 9 Mar 1999 19:29:34 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10KZfr-000I4EC; Tue, 9 Mar 1999 22:28:47 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: from Matthew Jacob at "Mar 9, 1999 3:21: 2 pm" To: mjacob@feral.com Date: Tue, 9 Mar 1999 22:28:47 -0500 (EST) Cc: tom@tomqnx.com, chris@shenton.org, scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7081 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > This is a very well put argument for never doing ANYTHING at the driver > > level that would cause a backup program to lose position information. > > > > All very cogent arguments, except it is the broken applications here that > the tape needs to be protected from. This is the first premise that I would question for a couple of simple reasons. I don't think that amanda and dump are broken. They work very well in a number of different OS environments. If an application is truly broken, the application needs to be fixed - not rewrite the OS to protect the media from the broken app. If this were truly the case, I would rather see the process wait for operator intervention or be terminated with a meaningful error message. A human needs to get involved and make a value judgement. This means the application must be informed and handle the situation as the driver does not communicate at that level. > I'm writing (or reading) a tape. Something bad happens such that the tape > driver loses a notion of where it is. Previously, nothing would happen- > leading you to often either overwrite tapes or write them with an > inconsistent set of filemarks. I hear you and I understand where you are coming from, I think. The problems you cite are valid and require a solution. I do see this from a slightly different perspective though, so let me restate the situation to illustrate: I'm writing a tape (reading is not an issue for the problems you identify). Something unexpected happens, and the tape driver incorrectly assumes that it no longer knows where it is. In fact, the driver's idea of where it was when the incident(s) happened is entirely accurate. In fact, with 4.0-current the unexpected incidents do not occur, or at least are no longer presented to the driver (the hardware 'quirks' are better handled), at least with this particular drive. You are the expert here, I'm just a guy that has been jocking around with tape systems for 39 years, but I would suggest the following: 1) I believe that your concerns and the need for action by the driver are closely and exclusively associated with detection and processing of EOM while writing. 2) It may be presented to you as such, but detection of EOM is a data condition that is not an error. It is a very common facility that is designed into the hardware, and is positively communicated to the driver ( or in the worst case, with really broken hardware, the driver can perform actions to positively identify the condition). 3) The driver should NEVER assume that it is dealing with EOM when it runs across an unfamiliar I/O or command error. To work properly and reliably, a driver MUST be able to positively and reliably identify an EOM condition, if it is to take action based on its presence. 4) If the driver runs across a situation it does not know positively know how to handle, it should kick it up the line for an abort/retry/ignore decision. It ain't pretty or elegant, I agree, but it does no harm. That should be the first rule - do no harm. > I added in a change that should (for most drives) eject the tape. This has > turned out to be less than desirable for tapes that can't eject. No disrespect intended, Matt, but it may not be proven that it isn't less than desireable for all tape drives. We'll postulate that it worked for the applications that you thoroughly tested with it, but that is not a proof of correctness. The change that you added was not consistent within the context of the driver itself, or it would not be attempting to backspace over a TM after you have rewound (and attempted to eject) the tape. There was also no communication with the operator to replace that ejected tape. Not all of us have automated changers. You may also have proven conclusively to yourself that all permutations and combinations of volume/data header and trailer label handling are working properly for all situations but I am not that sure.... > Here's the alternative I'll offer: If the driver loses position, it will > refuse to accept any I/O until either a rewind or an explicit space to > EOD, or an unload occurs. This is somewhat trickier than other cases > because I'll have to allow opens but no operations but the three > mentioned. Hmmm. That doesn't sound too efficacious to me. I might be misunderstanding you though. I believe that a driver that works does not lose position:-) It sounds to me as though you are proposing that scsi-sa silently "hang" if it ever gets confused. I'm no Unix guru, but I have designed and implemented a lot of goodies for various OS's & I would not do that. What would generate those magic instructions, and why? > Opinions? I think I am qualified to give you some advice, but I'm not qualified to tell you what to do here. You are the expert. Unless we are communicating at cross-purposes, your first task, before you determine what else to do, is to figure out how to reliably detect EOM. Until you can do that, you cannot reliably implement actions within the driver based on its presence. The actions implemented will not be judged by me - they will be judged by the likes of amanda and dump (and restore). If they work reliably all will be well. Otherwise I and others will be voices crying in the wildnerness, begging you to fix it:-) It might be useful to bear in mind that for each voice you hear crying, there are probably literally hundreds of people happily making backups that are not worth the powder to blow them up:-/ My suggestion would be to back out the change related to EOM processing until you feel that you really have it aced (rewind et al). The fact that no apparent problems surface with my equipment under 4.0-current is immaterial in my view - if it ain't right, then leaving it in is leaving a time-bomb there for others to suffer. I would also get myself a screwdriver and an audio splicing kit and make a short tape for quick and easy testing... I also strongly urge you again to look at the amanda/dump code. Any action requiring operator intervention, as with an ejected tape (in the absence of an automated changer) requires that it be done in conjunction with the application layer, which is responsible for system/human interaction in this case. If the application layer can handle all or part of the problem, why reinvent the wheel? Even 'tar' under 2.2.8 handles this effectively. Perhaps those 'broken' applications you were mentioning were never informed by the driver that action was required of them? BTW - when someone asks for my opinion, I have a nasty habit of climbing up on a soapbox and spouting lots of very direct and positive things. Just as though I was an expert too:-) Don't let it irritate you; just take whatever good you think you find and leave the rest for trash:-)) There is probably something good buried in all this, though... might even be worth reading more than once:-) Hope this helps! Please let us know what you decide to do... Cheers, and signing off, Long-Winded Tom > -matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 10 10:24:38 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 6582714E22 for ; Wed, 10 Mar 1999 10:24:31 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA24149; Wed, 10 Mar 1999 10:23:42 -0800 Date: Wed, 10 Mar 1999 10:23:42 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Tom Torrance at home Cc: chris@shenton.org, scsi@freebsd.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: 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 Okay. A long response. I won't respond point to point. It's also an inaccurate view of many items, but that's not germane. The summary I'll take from this that the eject is wrong. I'll agree with that- that was probably the wrong thing to do. You're further asserting that any other state action that the driver attempts to take that will protect the tape from being overwritten in the wrong place is also an incorrect action. Well- I'm not so sure. I can't claim 39 years in this business- only 20. But I will assert that the applications we're talking about here are ill-conceived at best. Yes, it's a problem for applications that try and run on multiple platforms, but any application that receives an error indication *and does not use the information at it's disposal to assure data integrity or take other steps to ensure data integrity* is bad joke. I don't give a rat's ass whether it's the popular backup program of choice for the masses- it's just plain wrong. The only question here is whether the driver should try and shield idiot applications from doing something bad to existing data. The steps I took previously are wrong- but mostly only because I screwed up and didn't handle the case of tapes that don't eject. This isn't entirely to do with EOM conditions. This also has to do with any catastrophic error. Let's say a SCSI Bus reset resets the tape drive. Let's say somebody manually ejects the tape and replaces it with another. Either action means that the tape identity is not known and the tape position isn't known- but that writing can continue, and if it does so blindly, data destruction will occur. There are two behaviours I should choose from at this juncture: 1 Receive an error indicating that tape position has been lost. Propagate it, mapped to EIO, badk to the user application. Nothing else. 2 Receive an error that indicates that tape position has been lost- and no, user applications aren't the owners of this information- and require specific programmatic intervention before writing can resume. Reading we don't really care about. The step I took before wasn't such a hot idea. Requiring a user application to then make the position and state of the tape known via either a rewind/eject or a space to EOD is sufficient. But a pain to implement. I want to get a sense of what people would like to see in this case. From your mail, I'm assuming choice #1. It'd be easier to implement- that's for sure (just remove any checks). Taking the point of view of an application writer (I worked at Legato- the mmd code I worked on supported 30 different platforms- a large fraction of which *weren't* Unix) I'd also probably pick #1- because I would be writing an application that doesn't want the tape driver to get in the way and *I'll* manage data integrity. But in general, Unix user applications that do backups don't manage data integrity, or manage it poorly. So, I'm a little unsure as to the right choice- that's why I asked for opinions, and I hope to see more of them than yours, Tom. But thanks for it all the same- it was quite informative. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 10 16:47:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 648CD14C3B for ; Wed, 10 Mar 1999 16:47:55 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-14-22.dialup.HiWAAY.net [216.180.14.22]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id SAA17536 for ; Wed, 10 Mar 1999 18:47:36 -0600 (CST) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id SAA14287 for ; Wed, 10 Mar 1999 18:47:34 -0600 (CST) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199903110047.SAA14287@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: scsi@FreeBSD.ORG From: David Kelly Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-reply-to: Message from Matthew Jacob of "Wed, 10 Mar 1999 10:23:42 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Mar 1999 18:47:34 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > > Taking the point of view of an application writer (I worked at Legato- the > mmd code I worked on supported 30 different platforms- a large fraction of > which *weren't* Unix) I'd also probably pick #1- because I would be > writing an application that doesn't want the tape driver to get in the way > and *I'll* manage data integrity. But in general, Unix user applications > that do backups don't manage data integrity, or manage it poorly. So, I'm > a little unsure as to the right choice- that's why I asked for opinions, > and I hope to see more of them than yours, Tom. But thanks for it all the > same- it was quite informative. Lets do the right thing. If the applications such as dump, tar, pax, and tcopy are broken, then lets fix them. No point in fixing dd. While *I* often write tapes with dd, when I do I want it to blow up and fail on error. Then maybe I'll try it again on the same tape, or throw the tape away and use a new one. Then again, I'm not filling one tape and desiring to continue on another. Hmm. That reminds me that I haven't send-pr'ed some patches for tcopy teaching it how to know the difference between a file and a device, and to use that information to "rewind" a file (for "tcopy -c"). -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 10 18:30:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id AD42214D0F for ; Wed, 10 Mar 1999 18:30:42 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id DAA26514 for freebsd-scsi@freebsd.org; Thu, 11 Mar 1999 03:30:24 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10KtzI-000WyeC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Thu, 11 Mar 1999 02:10:12 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Wangtek 51000HT tape drive Date: 11 Mar 1999 02:10:09 +0100 Message-ID: <7c755h$cv9$1@mips.rhein-neckar.de> References: <7bv4vr$99v$1@mips.rhein-neckar.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > > Are you saying that I should duplicate that entry for the Wangtek 5525ES > > in the quirk table for the 51000HT? > > Yes. If it works, send it to me and I'll check it in in a variety of > places. I've added an entry { { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "WANGTEK", "51000*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 } to sa_quirk_table in /sys/cam/scsi/scsi_sa.c. This gives an improvement, but it still doesn't really work. Test #1 ------- $ echo file0 | cpio -oH crc -F $TAPE 7 blocks $ echo file1 | cpio -oH crc -F $TAPE 121 blocks $ mt rew $ rm * $ cpio -iF $TAPE 7 blocks $ mt stat ... File Number: 0 Record Number: 7 $ cpio -iF $TAPE Found end of volume. Load next volume and press RETURN. cpio: file0 not created: newer or same age version exists 7 blocks $ mt stat ... File Number: 0 Record Number: 7 Shouldn't the position be at file #1 after file #0 has been read? $ mt fsf $ mt stat ... File Number: 1 Record Number: 0 $ cpio -iF $TAPE 121 blocks $ mt stat File Number: 1 Record Number: 121 In real life, of course, I use something like buffer(1) or team(1). So lets try again: $ rm * $ mt rew $ mt stat File Number: 0 Record Number: 0 $ buffer -i $TAPE | cpio -i buffer (reader): failed to read input: Input/output error cpio: premature end of archive $ mt stat File Number: 1 Record Number: 20 Something's screwy here. Test #2 ------- $ dump 0a /var ... DUMP: DUMP IS DONE $ dump 0a /home ... DUMP: DUMP IS DONE $ mt stat ... File Number: 2 Record Number: 0 $ mt rew $ restore t $ mt stat File Number: 0 Record Number: 448 $ restore t Tape is not a dump tape $ mt stat File Number: 0 Record Number: 512 $ mt fsf $ mt stat File Number: 1 Record Number: 0 $ restore t $ mt stat File Number: 1 Record Number: 1408 $ mt rew $ restore r $ mt stat File Number: 0 Record Number: 7680 $ rm -rf * $ restore r tape read error: Undefined error: 0 $ mt stat File Number: 1 Record Number: 64 -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de 100+ SF Book Reviews: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 10 18:49:20 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 CFB3E151EA for ; Wed, 10 Mar 1999 18:49:18 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id SAA26204; Wed, 10 Mar 1999 18:48:41 -0800 Date: Wed, 10 Mar 1999 18:48:41 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Christian Weisgerber Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: <7c755h$cv9$1@mips.rhein-neckar.de> 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 > Matthew Jacob wrote: > > > > Are you saying that I should duplicate that entry for the Wangtek 5525ES > > > in the quirk table for the 51000HT? > > > > Yes. If it works, send it to me and I'll check it in in a variety of > > places. > > I've added an entry > > { > { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "WANGTEK", > "51000*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 > } > > to sa_quirk_table in /sys/cam/scsi/scsi_sa.c. This gives an improvement, > but it still doesn't really work. Did you run a CAMDEBUG kernel? That should then print out: printf("found quirk entry %d\n", (int).... I had to put this in at one point because I found that the bloody quirk wasn't matching. > > Test #1 > ------- > > > $ echo file0 | cpio -oH crc -F $TAPE > 7 blocks > $ echo file1 | cpio -oH crc -F $TAPE > 121 blocks > $ mt rew > $ rm * > $ cpio -iF $TAPE > 7 blocks > > $ mt stat > ... > File Number: 0 Record Number: 7 > $ cpio -iF $TAPE > Found end of volume. Load next volume and press RETURN. > cpio: file0 not created: newer or same age version exists > 7 blocks > $ mt stat > ... > File Number: 0 Record Number: 7 > > Shouldn't the position be at file #1 after file #0 has been read? Not necessarily. Both CPIO and TAR can stop short of reading over a filemark. Also, if it's fixed block mode, some of the file/record accounting isn't right (depending on the version of the driver)- you didn't think I put the warning into the man page for no reason, eh? Here's my replication of this: fctblab.nas.nasa.gov > mt stat Mode Density Blocksize bpi Compression Current: default variable 0 0x1 ---------available modes--------- 0: default variable 0 0x1 1: default variable 0 0x1 2: default variable 0 0x1 3: default variable 0 0x1 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 fctblab.nas.nasa.gov > echo file0 | cpio -oH crc -F $TAPE 4070 blocks fctblab.nas.nasa.gov > echo file1 | cpio -oH crc -F $TAPE 67 blocks fctblab.nas.nasa.gov > sum file0 file1 60461 2035 file0 4931 33 file1 fctblab.nas.nasa.gov > rm file0 file1 fctblab.nas.nasa.gov > mt rew fctblab.nas.nasa.gov > cpio -iF $TAPE 4070 blocks fctblab.nas.nasa.gov > mt stat Mode Density Blocksize bpi Compression Current: default variable 0 0x1 ---------available modes--------- 0: default variable 0 0x1 1: default variable 0 0x1 2: default variable 0 0x1 3: default variable 0 0x1 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 4070 fctblab.nas.nasa.gov > mt fsf fctblab.nas.nasa.gov > mt stat Mode Density Blocksize bpi Compression Current: default variable 0 0x1 ---------available modes--------- 0: default variable 0 0x1 1: default variable 0 0x1 2: default variable 0 0x1 3: default variable 0 0x1 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 1 Record Number: 0 fctblab.nas.nasa.gov > cpio -iF $TAPE 67 blocks fctblab.nas.nasa.gov > sum file0 file1 60461 2035 file0 4931 33 file1 > > $ mt fsf > $ mt stat > ... > File Number: 1 Record Number: 0 > $ cpio -iF $TAPE > 121 blocks > > $ mt stat > File Number: 1 Record Number: 121 > > In real life, of course, I use something like buffer(1) or team(1). So And where are these entities? Ports collection? > lets try again: > > $ rm * > $ mt rew > > $ mt stat > File Number: 0 Record Number: 0 > $ buffer -i $TAPE | cpio -i > buffer (reader): failed to read input: Input/output error > cpio: premature end of archive > $ mt stat > File Number: 1 Record Number: 20 > > Something's screwy here. Did it used to work that CPIO and/or tar would always end up in the next tape file? > > Test #2 > ------- > > > $ dump 0a /var > ... > DUMP: DUMP IS DONE > $ dump 0a /home > ... > DUMP: DUMP IS DONE > $ mt stat > ... > File Number: 2 Record Number: 0 > $ mt rew > $ restore t > > $ mt stat > File Number: 0 Record Number: 448 > $ restore t > Tape is not a dump tape > $ mt stat > File Number: 0 Record Number: 512 > $ mt fsf > $ mt stat > File Number: 1 Record Number: 0 > $ restore t > > $ mt stat > File Number: 1 Record Number: 1408 > $ mt rew > $ restore r > > $ mt stat > File Number: 0 Record Number: 7680 > $ rm -rf * > $ restore r > tape read error: Undefined error: 0 > $ mt stat > File Number: 1 Record Number: 64 > > -- Okay. Let me ponder. On the latter- I have to go off to flute quartets now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 8:20:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 087D7151BD for ; Thu, 11 Mar 1999 08:20:44 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10L8Bw-000I0zC; Thu, 11 Mar 1999 11:20:12 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: from Matthew Jacob at "Mar 10, 1999 10:23:42 am" To: mjacob@feral.com Date: Thu, 11 Mar 1999 11:20:12 -0500 (EST) Cc: tom@tomqnx.com, chris@shenton.org, scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1547 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Matt: I'd like to submit a somewhat more positive suggestion for your consideration. I don't object to positive action to prevent data corruption, I just don't like the idea of unilateral action by the driver that affects tape positioning. How about the following? 1) Receive the error. 2) Verify that it is not a harmless device quirk. 3) Map the error back to the application for action. 4) Until the application or the operator does something positive to re-establish positioning, greet further attempts to write with a media write-protected error. 5) It might be possible to allow the tape operator a mechanism to turn off the condition (the 'ignore' option) in some harmless way. Perhaps an 'mt status'? There might be some actions that would/should be allowable, like writing tape marks - you would be much better qualified to judge those. On the face of it, though, this approach might satisfy your concerns (and mine). The downside is all the queries you might receive from people puzzled as to why they would suddenly get a media write- protected error from a tape that they have been happily writing to... Good explanations/instructions in the error logs would help in this regard. Particular care should be taken that only the problem device/app is affected for systems with multiple tape drives. Obviously something like this would have to be properly tested with the most common backup systems to ensure that there is not some potentially harmful application interaction. What do you think? Cheers, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 9:36: 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 1983A15319 for ; Thu, 11 Mar 1999 09:35:58 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA28660; Thu, 11 Mar 1999 09:35:17 -0800 Date: Thu, 11 Mar 1999 09:35:17 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Tom Torrance at home Cc: scsi@freebsd.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: 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 > How about the following? > > 1) Receive the error. > 2) Verify that it is not a harmless device quirk. > 3) Map the error back to the application for action. > 4) Until the application or the operator does something positive to > re-establish positioning, greet further attempts to write with a > media write-protected error. > 5) It might be possible to allow the tape operator a mechanism to > turn off the condition (the 'ignore' option) in some harmless > way. Perhaps an 'mt status'? Steps 1-4 was exactly what I was proposing. The positive steps can be by the operator via mt(1) or via a backup program. Step 5 I hadn't considered. Would a config option for the kernel be okay for this (e.g., SA_PASSIVE_DRIVER)? > There might be some actions that would/should be allowable, like > writing tape marks - you would be much better qualified to judge those. Hmm. I'd think not. > > On the face of it, though, this approach might satisfy your concerns > (and mine). The downside is all the queries you might receive from > people puzzled as to why they would suddenly get a media write- > protected error from a tape that they have been happily writing to... > Good explanations/instructions in the error logs would help in > this regard. Yes. This is something I often fail to do. It's hard to figure out who the audience is in some of these systems. > Particular care should be taken that only the problem > device/app is affected for systems with multiple tape drives. Obviously. > > Obviously something like this would have to be properly tested with > the most common backup systems to ensure that there is not some > potentially harmful application interaction. > > What do you think? > Good positive suggestions. To summarize: + We agree for steps 1-4. + Step 5 could be a config option (?) + The man pages should explain these actions. I don't want to go too far with this. I'm just trying to stabilize *this* driver. I'm more interested in seeing whether a new driver based upon the TapeAlert working group proposals (see http://www.hp.com/tape/tapealert) is worth doing. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 10: 8:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 0976A15114 for ; Thu, 11 Mar 1999 10:08:17 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10L9s4-000I0zC; Thu, 11 Mar 1999 13:07:48 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: from Matthew Jacob at "Mar 11, 1999 9:35:17 am" To: mjacob@feral.com Date: Thu, 11 Mar 1999 13:07:48 -0500 (EST) Cc: tom@tomqnx.com, scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1338 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > How about the following? > > > > 1) Receive the error. > > 2) Verify that it is not a harmless device quirk. > > 3) Map the error back to the application for action. > > 4) Until the application or the operator does something positive to > > re-establish positioning, greet further attempts to write with a > > media write-protected error. > > 5) It might be possible to allow the tape operator a mechanism to > > turn off the condition (the 'ignore' option) in some harmless > > way. Perhaps an 'mt status'? > > Steps 1-4 was exactly what I was proposing. The positive steps can be by > the operator via mt(1) or via a backup program. Step 5 I hadn't > considered. Would a config option for the kernel be okay for this (e.g., > SA_PASSIVE_DRIVER)? I would think this highly desireable. > > There might be some actions that would/should be allowable, like > > writing tape marks - you would be much better qualified to judge those. > > Hmm. I'd think not. > I mentioned this because a half-written tape is worse than useless (fit only for the scratch bin). It might have some value if there were a mechanism to close it off in some way. Definitely EOM should not trigger this routine. TM, trailer labels and TMs have to be written, possibly following a short erase over the reflective spot area. Cheers, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 10:20: 4 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 B8DBD14D3D for ; Thu, 11 Mar 1999 10:20:01 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA28919; Thu, 11 Mar 1999 10:19:21 -0800 Date: Thu, 11 Mar 1999 10:19:21 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Tom Torrance at home Cc: scsi@freebsd.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: 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 > > I mentioned this because a half-written tape is worse than useless > (fit only for the scratch bin). It might have some value if there > were a mechanism to close it off in some way. > > Definitely EOM should not trigger this routine. TM, trailer labels and TMs > have to be written, possibly following a short erase over the > reflective spot area. > EOM by itself doesn't trigger a 'loss of position'. However, FreeBSD (and NetBSD) insist on calling EOM (really 'early warning') an error and EIO has to be propagated back to the application. There was a lot of discussion about this some months back. The consensus (which I didn't agree with) was that EIO should still be propagated at early warning (the EOM bit in Sense Data- not the VOLUME OVERFLOW which is hard physical EOT) rather than using a (possibly deferred) residual count to an I/O operation to provide the signification. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 10:27:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id B369114D83 for ; Thu, 11 Mar 1999 10:27:43 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id KAA28464 for ; Thu, 11 Mar 1999 10:27:41 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA198626842; Thu, 11 Mar 1999 10:27:22 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id KAA15788 for ; Thu, 11 Mar 1999 10:27:21 -0800 (PST) Message-Id: <199903111827.KAA15788@mina.sr.hp.com> To: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 11 Mar 1999 11:20:12 EST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Mar 1999 10:27:20 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org tom@tomqnx.com (Tom Torrance at home) wrote: > How about the following? > > 1) Receive the error. > 2) Verify that it is not a harmless device quirk. Going off on a tangent, has anyone thought of making the quirk table specifiable via a kld module? I'll go away now. ;-) -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 11: 0:29 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 BB67F14FF3 for ; Thu, 11 Mar 1999 11:00:26 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA29058; Thu, 11 Mar 1999 10:56:38 -0800 Date: Thu, 11 Mar 1999 10:56:38 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Darryl Okahata Cc: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: <199903111827.KAA15788@mina.sr.hp.com> 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 > tom@tomqnx.com (Tom Torrance at home) wrote: > > > How about the following? > > > > 1) Receive the error. > > 2) Verify that it is not a harmless device quirk. > > Going off on a tangent, has anyone thought of making the quirk > table specifiable via a kld module? > > I'll go away now. ;-) > Yes, in fact some of us have. Alternatively, a .conf file that gets loaded during rc phase. Were you, err, umm, volunteering? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 11:17:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 05DE814A0B for ; Thu, 11 Mar 1999 11:17:18 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id LAA13970; Thu, 11 Mar 1999 11:16:53 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA231099812; Thu, 11 Mar 1999 11:16:52 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA16160; Thu, 11 Mar 1999 11:16:51 -0800 (PST) Message-Id: <199903111916.LAA16160@mina.sr.hp.com> To: mjacob@feral.com Cc: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 11 Mar 1999 10:56:38 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Mar 1999 11:16:51 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mjacob@feral.com wrote: > > Going off on a tangent, has anyone thought of making the quirk > > table specifiable via a kld module? > > Yes, in fact some of us have. Alternatively, a .conf file that gets loaded > during rc phase. Is the discussion in the archives? If so, where? > Were you, err, umm, volunteering? Urm, probably not. Although I wouldn't mind diving into the deep end, I've got limited amounts of free time. ;-( At the moment, I'm thinking about talking to the doc folks about updating the FAQ and handbook (I just upgraded to 3.1-RELEASE, from 2.2.5, and ran into landmine after landmine -- none of which were mentioned anywhere except in the mailing list archives). -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 11:50:40 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 C968614EBB for ; Thu, 11 Mar 1999 11:50:32 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA29278; Thu, 11 Mar 1999 11:46:49 -0800 Date: Thu, 11 Mar 1999 11:46:49 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Darryl Okahata Cc: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: <199903111916.LAA16160@mina.sr.hp.com> 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 On Thu, 11 Mar 1999, Darryl Okahata wrote: > mjacob@feral.com wrote: > > > > Going off on a tangent, has anyone thought of making the quirk > > > table specifiable via a kld module? > > > > Yes, in fact some of us have. Alternatively, a .conf file that gets loaded > > during rc phase. > > Is the discussion in the archives? If so, where? Nawp -just private discussion with Justin && Ken. Nothing very extensive. > > > Were you, err, umm, volunteering? > > Urm, probably not. Although I wouldn't mind diving into the deep > end, I've got limited amounts of free time. ;-( At the moment, I'm > thinking about talking to the doc folks about updating the FAQ and > handbook (I just upgraded to 3.1-RELEASE, from 2.2.5, and ran into > landmine after landmine -- none of which were mentioned anywhere except > in the mailing list archives). > Such is life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 12:45:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles134.castles.com [208.214.165.134]) by hub.freebsd.org (Postfix) with ESMTP id 0230E14F5D for ; Thu, 11 Mar 1999 12:45:28 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA01099; Thu, 11 Mar 1999 12:39:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199903112039.MAA01099@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Darryl Okahata Cc: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-reply-to: Your message of "Thu, 11 Mar 1999 10:27:20 PST." <199903111827.KAA15788@mina.sr.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Mar 1999 12:39:04 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > tom@tomqnx.com (Tom Torrance at home) wrote: > > > How about the following? > > > > 1) Receive the error. > > 2) Verify that it is not a harmless device quirk. > > Going off on a tangent, has anyone thought of making the quirk > table specifiable via a kld module? Actually, doing this would be ridiculously easy, and wouldn't require a KLD module at all. Just put the stuff in a text file and use preload_search_by_type() to find it inside the CAM code. Then you have sscanf() to parse it and you're done. Diffs should be simple, and would probably be committed if you were to provide them. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 13:18:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id CA5EE1531B for ; Thu, 11 Mar 1999 13:18:09 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id QAA29005 for freebsd-scsi@freebsd.org; Thu, 11 Mar 1999 16:17:48 -0500 (EST) (envelope-from cao) Date: Thu, 11 Mar 1999 16:17:48 -0500 From: "Chuck O'Donnell" To: freebsd-scsi@freebsd.org Subject: error messages from bt driver Message-ID: <19990311161748.D27999@milf18.bus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone seen anything like output attached below? It shows up pretty much daily at 2:00 a.m. (specifically when the security script runs `find' I think). I have replaced the disk once and verified correct termination of the SCSI bus. I spent a while reading through bt(4) and bt.c, but I haven't been able to diagnose anything from them. I am mostly interested to know if it is a harmless diagnostic, buslogic hardware/firmware issue, or an actual error condition. I will be happy to do any research or whatever is necessary if someone can point me in the right direction. Thanks. Chuck Configuration: ----- FreeBSD 3.1-STABLE #0: Sun Mar 7 bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), \ Tagged Queueing Enabled Output: ----- Mar 8 02:02:10 fern /kernel: bt0: Encountered busy mailbox with 191 out of 192 commands active!!!bt0: Encountered busy mailbox with 190 out of 192 commands active!!!bt0: Encountered busy mailbox with 189 out of 192 commands active!!! Mar 8 02:02:10 fern /kernel: bt0: Encountered busy mailbox with 188 out of 192 commands active!!!bt0: Encountered busy mailbox with 187 out of 192 commands active!!!bt0: Encountered busy mailbox with 186 out of 192 commands active!!!bt0: Encountered busy mailbox with 185 out of 192 commands active!!!bt0: Encountered busy mailbox with 184 out of 192 commands active!!!bt0: Encountered busy mailbox with 183 out of 192 commands active!!!bt0: Encountered busy mailbox with 182 out of 192 commands active!!!bt0: Encountered busy mailbox with 181 out of 192 commands active!!!bt0: Encountered busy mailbox with 180 out of 192 commands active!!!bt0: Encountered busy mailbox with 179 out of 192 commands active!!!bt0: Encountered busy mailbox with 178 out of 192 commands active!!!bt0: Encountered busy mailbox with 177 out of 192 commands active!!!bt0: Encountered busy mailbox with 176 out of 192 commands active!!!bt0: Encountered busy mailbox with 175 out of 192 commands active!!!bt0: En! countered busy mailbox with 174 ou t of 192 commands acti Mar 8 02:02:10 fern /kernel: : Encountered busy mailbox with 173 out of 192 commands active!!!bt0: Encountered busy mailbox with 172 out of 192 commands active!!! Mar 8 02:02:11 fern /kernel: bt0: btdone - Attempt to free non-active BCCB 0xf5511540 Mar 8 02:03:10 fern /kernel: (da0:bt0:0:0:0): CCB 0xf5510240 - timed out Mar 8 02:03:27 fern /kernel: bt0: btdone - Attempt to free non-active BCCB 0xf550f3c0 Mar 8 02:03:27 fern /kernel: (da0:bt0:0:0:0): CCB 0xf5510240 - timed out Mar 8 02:03:27 fern /kernel: bt0: No longer in timeout To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 14:14:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id A02D315284 for ; Thu, 11 Mar 1999 14:14:26 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id PAA00492; Thu, 11 Mar 1999 15:04:57 -0700 (MST) Date: Thu, 11 Mar 1999 15:04:57 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903112204.PAA00492@narnia.plutotech.com> To: "Chuck O'Donnell" Cc: scsi@FreeBSD.org Subject: Re: error messages from bt driver X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <19990311161748.D27999@milf18.bus.net> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19990311161748.D27999@milf18.bus.net> you wrote: > Has anyone seen anything like output attached below? It shows up > pretty much daily at 2:00 a.m. (specifically when the security script > runs `find' I think). > > I have replaced the disk once and verified correct termination of the > SCSI bus. > > I spent a while reading through bt(4) and bt.c, but I haven't been > able to diagnose anything from them. I am mostly interested to know if > it is a harmless diagnostic, buslogic hardware/firmware issue, or an > actual error condition. Well, from a quick look at the code, I would guess that your card is getting somewhat confused under high load. I would suggest switching to 5.06I as 5.07B has been reported by the Linux driver author to occassionally hang under load. 5.06I is also the only firmware version Mylex is distributing off their ftp site. I'll check in a fix to '\n' terminate the mailboxs full warning. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 15:15:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 448CB14F60 for ; Thu, 11 Mar 1999 15:14:52 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id SAA00735 for ; Thu, 11 Mar 1999 18:13:15 -0500 (EST) Date: Thu, 11 Mar 1999 18:13:15 -0500 (EST) From: Chuck Robey To: FreeBSD-scsi@freebsd.org Subject: Buslogic controllers 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 I have a friend with a BusLogic 930 controller (yeah, that's the number, I verified it with him). Does anyone know if this thing runs under our CAM stuff, and maybe anything else about it? Thanks. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 15:38:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 8092714CC5 for ; Thu, 11 Mar 1999 15:38:45 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA21333; Thu, 11 Mar 1999 16:38:01 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903112338.QAA21333@panzer.plutotech.com> Subject: Re: Buslogic controllers In-Reply-To: from Chuck Robey at "Mar 11, 1999 6:13:15 pm" To: chuckr@mat.net (Chuck Robey) Date: Thu, 11 Mar 1999 16:38:01 -0700 (MST) Cc: FreeBSD-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chuck Robey wrote... > I have a friend with a BusLogic 930 controller (yeah, that's the number, > I verified it with him). Does anyone know if this thing runs under our > CAM stuff, and maybe anything else about it? That's a BusLogic Flashpoint card. It doesn't work under CAM (or the old SCSI code for that matter), but it should at some point. Justin intends to do a driver for it. Only the BusLogic MultiMaster cards work under CAM at the moment. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 11 23:16:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from friley-185-205.res.iastate.edu (friley-185-205.res.iastate.edu [129.186.185.205]) by hub.freebsd.org (Postfix) with ESMTP id 5242E14BF9 for ; Thu, 11 Mar 1999 23:16:48 -0800 (PST) (envelope-from cc@137.org) Received: from friley-185-205.res.iastate.edu (localhost [127.0.0.1]) by friley-185-205.res.iastate.edu (Postfix) with ESMTP id 5163DB1 for ; Fri, 12 Mar 1999 01:16:30 -0600 (CST) X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@freebsd.org Subject: SCSI disk oddities and Buslogic problems.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Mar 1999 01:16:30 -0600 From: Chris Csanady Message-Id: <19990312071630.5163DB1@friley-185-205.res.iastate.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently purchased a two new disks, and have noticed some odd behavior. The drives are IBM DDRS-34560D's. Anyways, whenever I get new disks, I like to benchmark them. In this case, I have found that while running the following commands that the data transfer is very erratic. dd if=/dev/rda2s3 of=/dev/null bs=128k (or any place on the disk..) iostat -w 1 da2 Are the statistics output by iostat accurate? The values output by iostat usually range from 4 to 9MB/s for the DDRS drives. Although it seems random, it it is consistent in the same place on the drives. Does anyone else have any input on the DDRS drives? I'm sure it is harmless, but I can't help but to be bothered by this behavior.. I was just wondering if this is typical with some hard drives. I do not see this on the seagates that we have at work--the values are near constant. The other thing problem I have is with a Buslogic 946c. Are these controllers just really crappy? It is only a interim solution, so it is not a big deal to me if it gets fixed.. The reason I bring it up is that the errors are similar to those in the "CAM Ate my Machine" thread. The filesystems in this case were completely trashed.. Chris Csanady Here is the output from my current dmesg. Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #2: Fri Mar 12 00:41:20 CST 1999 ccsanady@friley-185-205.res.iastate.edu:/usr/src/sys/compile/xSMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 127696896 (124704K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel.quirk" at 0xc02aa000. Preloaded elf module "ccd.ko" at 0xc02aa0a4. Preloaded elf module "procfs.ko" at 0xc02aa140. Preloaded elf module "ntfs.ko" at 0xc02aa1e0. Preloaded elf module "cd9660.ko" at 0xc02aa27c. Preloaded elf module "linux.ko" at 0xc02aa31c. ccd0-3: Concatenated disk drivers Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 fxp0: rev 0x02 int a irq 18 on pci0.6. 0 fxp0: Ethernet address 00:a0:c9:55:9e:4f chip1: rev 0x01 on pci0.7.0 ahc0: rev 0x00 int a irq 17 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga0: rev 0x01 int a irq 16 on pci0.11.0 bt0: rev 0x00 int a irq 17 on pci0.15. 0 bt0: BT-946C FW Rev. 4.28D Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs bktr0: rev 0x12 int a irq 18 on pci0.17.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only iicsmb0: on iicbus0 smbus0: on iicsmb0 smbus1: on bti2c0 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo. fxp1: rev 0x04 int a irq 19 on pci0.19 .0 fxp1: Ethernet address 00:a0:c9:c8:d3:44 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 at 0x530 irq 5 drq 1 flags 0xa610 on isa mss_attach 0 at 0x530 irq 5 dma 1:0 flags 0xa610 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface ntfs_init(): APIC_IO: routing 8254 via 8259 on pin 0 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! da0 at bt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device bt0: btfetchtransinfo - Inquire Sync Info Failed 0x7 da0: 3.300MB/s transfers, Tagged Queueing Enabled da0: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) da1 at bt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device bt0: btfetchtransinfo - Inquire Setup Info Failed da1: 216268.800MB/s transfers (524288bit), Tagged Queueing Enabled da1: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) da3 at ahc0 bus 0 target 1 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da3: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da2 at ahc0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da2: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) cd0 at bt0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device bt0: btfetchtransinfo - Inquire Sync Info Failed 0x7 cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at bt0 bus 0 target 6 lun 1 cd1: Removable CD-ROM SCSI-2 device bt0: btfetchtransinfo - Inquire Setup Info Failed cd1: 216268.800MB/s transfers (524288bit) cd1: Attempt to query device size failed: NOT READY, Medium not present cd2 at bt0 bus 0 target 6 lun 2 cd2: Removable CD-ROM SCSI-2 device cd2: 10.000MB/s transfers (10.000MHz, offset 15) cd2: Attempt to query device size failed: NOT READY, Medium not present ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates cd3 at bt0 bus 0 target 6 lun 3 cd3: Removable CD-ROM SCSI-2 device bt0: btfetchtransinfo - Inquire Sync Info Failed 0x7 cd3: 3.300MB/s transfers cd3: Attempt to query device size failed: NOT READY, Medium not present (cd4:bt0:0:6:4): CCB 0xc5920240 - timed out (cd4:bt0:0:6:4): CCB 0xc5920240 - timed out bt0: No longer in timeout cd4 at bt0 bus 0 target 6 lun 4 cd4: Removable CD-ROM SCSI-2 device bt0: btfetchtransinfo - Inquire Sync Info Failed 0x7 cd4: 3.300MB/s transfers cd4: Attempt to query device size failed: NOT READY, Logical unit is in process of becoming ready (da0:bt0:0:0:0): CCB 0xc5920240 - timed out bt0: No longer in timeout ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 0:50:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 6E83314D9A for ; Fri, 12 Mar 1999 00:50:01 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 3238 invoked by uid 1001); 12 Mar 1999 08:43:01 +0000 (GMT) To: cc@137.org Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI disk oddities and Buslogic problems.. From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 12 Mar 1999 01:16:30 -0600" References: <19990312071630.5163DB1@friley-185-205.res.iastate.edu> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 12 Mar 1999 09:43:00 +0100 Message-ID: <3236.921228180@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I recently purchased a two new disks, and have noticed some odd behavior. > The drives are IBM DDRS-34560D's. Anyways, whenever I get new disks, I > like to benchmark them. > > In this case, I have found that while running the following commands that > the data transfer is very erratic. > > dd if=/dev/rda2s3 of=/dev/null bs=128k (or any place on the disk..) > > iostat -w 1 da2 > > Are the statistics output by iostat accurate? The values output by iostat > usually range from 4 to 9MB/s for the DDRS drives. Although it seems > random, it it is consistent in the same place on the drives. Does anyone > else have any input on the DDRS drives? I'm sure it is harmless, but I > can't help but to be bothered by this behavior.. da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) No problem with a 9 GB model here. Typical iostat output: tty da0 da1 wd0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 229 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 2 0 98 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 76 64.00 205 12.81 0.00 0 0.00 0.00 0 0.00 0 0 1 0 99 0 76 64.00 204 12.75 0.00 0 0.00 0.00 0 0.00 0 0 2 0 98 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 2 0 98 0 76 64.00 205 12.81 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 1 1 98 0 76 64.00 204 12.75 0.00 0 0.00 0.00 0 0.00 0 0 2 1 98 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 2 1 97 0 76 64.00 205 12.81 0.00 0 0.00 0.00 0 0.00 0 0 0 1 99 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 1 0 99 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 1 1 98 0 76 64.00 205 12.81 0.00 0 0.00 0.00 0 0.00 0 0 2 0 98 0 76 64.00 206 12.87 0.00 0 0.00 0.00 0 0.00 0 0 2 0 98 seems to correspond pretty well with the numbers from dd (multiple runs): # dd if=/dev/rda0s1 of=/dev/null bs=128k count=4096 536870912 bytes transferred in 39.885097 secs (13460439 bytes/sec) 536870912 bytes transferred in 40.334386 secs (13310502 bytes/sec) 536870912 bytes transferred in 39.890058 secs (13458765 bytes/sec) This is with an Adaptec 7890 U2W onboard controller. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 2:34: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id DDD5014CCF for ; Fri, 12 Mar 1999 02:33:58 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA22983; Fri, 12 Mar 1999 20:33:24 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma022977; Fri, 12 Mar 99 20:33:08 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA03011; Fri, 12 Mar 1999 20:33:08 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA24284; Fri, 12 Mar 1999 20:33:07 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA23811; Fri, 12 Mar 1999 20:33:05 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199903121033.UAA23811@nymph.detir.qld.gov.au> To: Adam McDougall Cc: freebsd-scsi@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: Support for 53C876 (as found in fireport 40 dual) References: <36E51861.5CA0A408@spawnet.com> In-Reply-To: <36E51861.5CA0A408@spawnet.com> from Adam McDougall at "Tue, 09 Mar 1999 07:47:29 -0500" Date: Fri, 12 Mar 1999 20:33:05 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 9th March 1999, Adam McDougall wrote: >I couldnt find this number in ncr.c nor any mention of dual, would this >board be unsupported then? I recently became interested because >diamondmm seems to be having a sale.. fireport 40 (a uw card) for >$49.95, and the dual channel version for $69.95. If the dual would work >with freebsd, I'd like to know, because it costs less than some >singlechannel boards :) This is dreadfully unfair! I tried for 2 months to get a FirePort 40 dual in this country, and I was told they no longer were made, and nobody had any. Further, they were willing to sell me a single channel board for AU$360, which is about US$220. And that, of course, is robbery! Who can sell me one at this sweet price? Oh, and the 876 should probe as two separate 875's, even though it's just one chip, because it is a multi function PCI device. That means it should be even better than 2x 875's and a bridge chip. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 2:58:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 1954914E98 for ; Fri, 12 Mar 1999 02:58:14 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA23696; Fri, 12 Mar 1999 20:57:54 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma023662; Fri, 12 Mar 99 20:57:33 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA03782 for ; Fri, 12 Mar 1999 20:57:33 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA24954 for ; Fri, 12 Mar 1999 20:57:32 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA24445; Fri, 12 Mar 1999 20:57:30 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199903121057.UAA24445@nymph.detir.qld.gov.au> To: freebsd-scsi@freebsd.org Cc: syssgm@detir.qld.gov.au Subject: Strange SCSI QIC tape behaviour Date: Fri, 12 Mar 1999 20:57:30 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a TANDBERG TDC 4200 attached to an aha1542CF in an old 486DX2/66. I run 4.0-current on it (only a couple days old). I'm using 2GB tapes (marked QD9600) from an old backup set from this very machine (in another life). It acts rather strangely... If I put in a tape, "mt status" claims that the density is 0x11:QIC-320 and the blocksize is 512 bytes. This in itself is a contradiction, since that format uses 1024 byte fixed blocks. If I try to read the old data (say, with restore), I get a failure: tape read error: Input/output error There are no kernel error messages associated with this. At this point, though, it has changed its mind about the density, claiming it is 0x22:QIC-2GB(C), but still thinks the blocksize is 512 bytes. The new idea of the density is correct, but the blocksize is still silly. If I set the blocksize to 0 (variable), then I can read the old dumps. Yes, the dumps were written with 32KB (variable) blocks. You might cry "foul" at this, but it is supported by the drive, and should, I think, be automatically selected. But, I don't want to just read old dumps. When I try to write to the tape, I set the blocksize to 1024 (which works as verified by mt), and try to write, I get errors: Mar 12 20:05:49 twoflower /kernel: (sa0:aha0:0:5:0): WRITE(06). CDB: a 1 0 0 20 0 Mar 12 20:05:49 twoflower /kernel: (sa0:aha0:0:5:0): ILLEGAL REQUEST asc:30,0 Mar 12 20:05:49 twoflower /kernel: (sa0:aha0:0:5:0): Incompatible medium installed Well, the medium looks pretty compatible to me, but I'm not a tape drive! Undeterred, I tried 'mt erase'. This appeared to succeed. I tried to write. Again, I got the "incompatible medium" error message. Trying a different block size in the write (64KB vs 32KB previously) changed the message slightly (the 20 changed to 40 in the WRITE error line). So, I removed the tape, and inserted it again. Same write failures. Then I set the blocksize back to variable. Wrote /kernel on to it with dd and it succeeded, but wrote very slowly (38KB/s). So, I rewound it, set it back to 1024 byte block size, and it worked like there had never been any problem at all! So, is this the most bizarre drive on Earth, or perhaps are there bugs in the SCSI tape driver that need addressing? At the very least, the fixed block size for QIC tapes should be 1024 not 512 for densities above QIC-320. Tandberg has a nice SCSI manual for their drive (though it's hard to find on their web site). Thus, I am armed with raw data, but no understanding of the current code. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 3:30:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 3DB2814A09 for ; Fri, 12 Mar 1999 03:30:29 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id MAA07901 for freebsd-scsi@freebsd.org; Fri, 12 Mar 1999 12:30:11 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10LPUw-000WyaC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Fri, 12 Mar 1999 11:48:58 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Wangtek 51000HT tape drive Date: 12 Mar 1999 11:48:54 +0100 Message-ID: <7carem$sn1$1@mips.rhein-neckar.de> References: <7c755h$cv9$1@mips.rhein-neckar.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > Did you run a CAMDEBUG kernel? That should then print out: I have now. Yes, the quirk matches. > fctblab.nas.nasa.gov > cpio -iF $TAPE > 4070 blocks > fctblab.nas.nasa.gov > mt stat ... > File Number: 0 Record Number: 4070 > fctblab.nas.nasa.gov > mt fsf > fctblab.nas.nasa.gov > mt stat ... > File Number: 1 Record Number: 0 > fctblab.nas.nasa.gov > cpio -iF $TAPE > 67 blocks Yes, exactly. You shouldn't need to do an explicit fsf, should you? > > In real life, of course, I use something like buffer(1) or team(1). So > And where are these entities? Ports collection? team is a port, buffer will be (again) as soon as somebody gets around to committing ports/10549. > Did it used to work that CPIO and/or tar would always end up in the next > tape file? I think so. Actually, now that you're asking, I think it rather was like this: $ tar x ... # extracts first archive $ tar x # does nothing, apparently gets EOF $ tar x ... # extracts second archive -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de See another pointless homepage at . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 8:40:44 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 0EBEA1533C for ; Fri, 12 Mar 1999 08:40:40 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id IAA00237; Fri, 12 Mar 1999 08:39:59 -0800 Date: Fri, 12 Mar 1999 08:39:59 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Stephen McKay Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour In-Reply-To: <199903121057.UAA24445@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 > So, I removed the tape, and inserted it again. Same write failures. > > Then I set the blocksize back to variable. Wrote /kernel on to it with dd > and it succeeded, but wrote very slowly (38KB/s). So, I rewound it, set it > back to 1024 byte block size, and it worked like there had never been any > problem at all! > > So, is this the most bizarre drive on Earth, or perhaps are there bugs in > the SCSI tape driver that need addressing? At the very least, the fixed > block size for QIC tapes should be 1024 not 512 for densities above QIC-320. Yes, that's a bug for me to address. Where is this piece of information from? > > Tandberg has a nice SCSI manual for their drive (though it's hard to find > on their web site). Thus, I am armed with raw data, but no understanding > of the current code. > -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 8:46:52 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 C9F36152DF for ; Fri, 12 Mar 1999 08:46:46 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id IAA00290; Fri, 12 Mar 1999 08:45:28 -0800 Date: Fri, 12 Mar 1999 08:45:28 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Christian Weisgerber Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive In-Reply-To: <7carem$sn1$1@mips.rhein-neckar.de> 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 > Matthew Jacob wrote: > > > Did you run a CAMDEBUG kernel? That should then print out: > > I have now. Yes, the quirk matches. > > > fctblab.nas.nasa.gov > cpio -iF $TAPE > > 4070 blocks > > fctblab.nas.nasa.gov > mt stat > ... > > File Number: 0 Record Number: 4070 > > fctblab.nas.nasa.gov > mt fsf > > fctblab.nas.nasa.gov > mt stat > ... > > File Number: 1 Record Number: 0 > > fctblab.nas.nasa.gov > cpio -iF $TAPE > > 67 blocks > > Yes, exactly. You shouldn't need to do an explicit fsf, should you? Unless you are explicitly using either a AT&T style tape behaviour or have an application that keeps reading until it gets an error or gets an indication that less data was moved than asked for, yes. Or...[see below] > > > > In real life, of course, I use something like buffer(1) or team(1). So > > And where are these entities? Ports collection? > > team is a port, buffer will be (again) as soon as somebody gets around > to committing ports/10549. > > > Did it used to work that CPIO and/or tar would always end up in the next > > tape file? > > I think so. I believe, in fact, that AT&T invented the 'space to next file on close' behaviour *because* CPIO doesn't do this. > Actually, now that you're asking, I think it rather was like this: > > $ tar x > ... # extracts first archive > $ tar x # does nothing, apparently gets EOF > $ tar x > ... # extracts second archive That counts as part of the description above. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 10:45:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 87AE714D8F for ; Fri, 12 Mar 1999 10:45:47 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id TAA08291 for ; Fri, 12 Mar 1999 19:45:26 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id TAA19232 for ; Fri, 12 Mar 1999 19:45:28 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id TAA16474 for ; Fri, 12 Mar 1999 19:45:27 +0100 (CET) Date: Fri, 12 Mar 1999 19:45:25 +0100 From: Andre Albsmeier To: ken@plutotech.com, gibbs@narnia.plutotech.com, freebsd-scsi@freebsd.org Subject: IOMEGA jaz access now really fast with CAM Message-ID: <19990312194525.A84383@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, being back from holidays, I built a complete up-to-date 3.1-STABLE system and noticed, that accessing JAZ drives now works as fast as it used to be under 2.2.8-NonCAM. I have now about 2MB/sec, regardless of the file coming from the memory or via the network: coming from the network: andre@bali:/server>mydd /server/FreeBSD/ctm/3/src-3.0001.gz /a/jaz/test 725+1 records in 725+1 records out 47542559 bytes transferred in 25.018278 secs (1900313 bytes/sec) now coming from the buffers in memory: root@bali:/server>mydd /server/FreeBSD/ctm/3/src-3.0001.gz /a/jaz/test 725+1 records in 725+1 records out 47542559 bytes transferred in 23.714647 secs (2004776 bytes/sec) So I don't know what fixed it but it really rocks :-) -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 15: 1:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles321.castles.com [208.214.167.21]) by hub.freebsd.org (Postfix) with ESMTP id 8CFF214C30 for ; Fri, 12 Mar 1999 15:01:25 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id OAA01397 for ; Fri, 12 Mar 1999 14:55:51 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199903122255.OAA01397@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@freebsd.org Subject: Possible errata for the 7890? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Mar 1999 14:55:51 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------- Forwarded Message From: Andrew Heybey To: freebsd-gnats-submit@freebsd.org, mike@smith.net.au Subject: Re: kern/10243: Under heavy disk and network load read(2) can return garbage. Date: Fri, 12 Mar 1999 11:44:21 -0500 This bug (under simulataneous heavy disk and network activity reads from disk appear to suffer from short DMA tranfers resulting in incorrect data being returned by read(2)) appears to be a hardware bug. The motherboard on the systems on which I experienced the problem is an Asus P2B-LS with on-board intel ethernet and AIC7890 SCSI controller. If I change the "PCI Latency" BIOS setting from the default of 32 to 64, the problem seems to go away. At least I can run my test programs overnight without a failure while previously they would not run for more than 10-20 minutes. My hypothesis is that the 7890 is not getting sufficient PCI bus bandwidth to keep up with the disks and that there is some bug either in the controller or the disks (IBM Ultrastart 9LZX) such that they lose part of a transfer in this cas. I am not very familiar with the SCSI protocol, but I would think that there is some way that the controller could apply backpressure to the disk to ask it to slow down if the controller's FIFOs are getting full. To lose data either the controller is not applying back pressure or the disk is ignoring it. This PR can be closed, and I apologize for jumping to the conclusion that this is a FreeBSD bug. andrew ------- End of Forwarded Message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 15:13: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id C7D9115093 for ; Fri, 12 Mar 1999 15:12:46 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id PAA11707 for ; Fri, 12 Mar 1999 15:12:45 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA281080346; Fri, 12 Mar 1999 15:12:26 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id PAA12555 for ; Fri, 12 Mar 1999 15:12:25 -0800 (PST) Message-Id: <199903122312.PAA12555@mina.sr.hp.com> To: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI disk oddities and Buslogic problems.. Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 12 Mar 1999 09:43:00 +0100." <3236.921228180@verdi.nethelp.no> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Mar 1999 15:12:25 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no wrote: > Chris Csanady wrote: > > In this case, I have found that while running the following commands that > > the data transfer is very erratic. > > > > dd if=/dev/rda2s3 of=/dev/null bs=128k (or any place on the disk..) > > > > iostat -w 1 da2 > > No problem with a 9 GB model here. Typical iostat output: I have seen strange things with 3.1-RELEASE (I've yet to try -current), and tagged queueing. Using 3.1-RELEASE, an Adaptec 7895 controller (built into my Gigabyte 6BXDS motherboard) and two IBM Ultrastar 9ES drives striped together using vinum, I get strange performance numbers using iozone (yeah, iozone isn't very good for benchmarking striped drives, but I'm just using it as a zero-th order gauge). Individually (if I do not use vinum and just newfs a single drive), I get around 11MB/s write, and 13MB/s read. No problem here. If I stripe the drives together using vinum, and use the default newfs values, I get something like 3.7MB/s write, and 16MB/s read. The write throughput sucks. If I run newfs with 4K frag sizes, the write throughput jumps up to around 7MB/sec. Better, but still not great. However, if I go into the BIOS and disable SCSI disconnect, the write throughput jumps back up to 11MB/s. Much better, but disabling disconnects kinda defeats the purpose of striping .... The only thing I can think of is that tags are somehow involved, as disabling disconnects also disables tags. However, one slightly unusual thing about the striped drives is that one drive is a plain fast/wide disk ("IBM DDRS-39130W S97B"), and the other is the LVD version running in single-ended mode ("IBM DDRS-39130D DC1B"), but this shouldn't matter. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 15:51:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from friley-185-205.res.iastate.edu (friley-185-205.res.iastate.edu [129.186.185.205]) by hub.freebsd.org (Postfix) with ESMTP id E2DBE14CF8 for ; Fri, 12 Mar 1999 15:51:26 -0800 (PST) (envelope-from cc@137.org) Received: from friley-185-205.res.iastate.edu (localhost [127.0.0.1]) by friley-185-205.res.iastate.edu (Postfix) with ESMTP id 302BFAB; Fri, 12 Mar 1999 17:51:08 -0600 (CST) X-Mailer: exmh version 2.0.2 2/24/98 To: Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG, ken@plutotech.com Subject: Re: SCSI disk oddities and Buslogic problems.. In-reply-to: Your message of "Fri, 12 Mar 1999 15:12:25 PST." <199903122312.PAA12555@mina.sr.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Mar 1999 17:51:08 -0600 From: Chris Csanady Message-Id: <19990312235108.302BFAB@friley-185-205.res.iastate.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, therein lies the problem. When I disable disconnection on these drives, the performance is just as advertised. So, does it mean that the problem is likely driver related? Chris >sthaug@nethelp.no wrote: > >> Chris Csanady wrote: >> > In this case, I have found that while running the following commands that >> > the data transfer is very erratic. >> > >> > dd if=/dev/rda2s3 of=/dev/null bs=128k (or any place on the disk..) >> > >> > iostat -w 1 da2 >> >> No problem with a 9 GB model here. Typical iostat output: > > I have seen strange things with 3.1-RELEASE (I've yet to try >-current), and tagged queueing. Using 3.1-RELEASE, an Adaptec 7895 >controller (built into my Gigabyte 6BXDS motherboard) and two IBM >Ultrastar 9ES drives striped together using vinum, I get strange >performance numbers using iozone (yeah, iozone isn't very good for >benchmarking striped drives, but I'm just using it as a zero-th order >gauge). > > Individually (if I do not use vinum and just newfs a single drive), >I get around 11MB/s write, and 13MB/s read. No problem here. > > If I stripe the drives together using vinum, and use the default >newfs values, I get something like 3.7MB/s write, and 16MB/s read. The >write throughput sucks. If I run newfs with 4K frag sizes, the write >throughput jumps up to around 7MB/sec. Better, but still not great. > > However, if I go into the BIOS and disable SCSI disconnect, the >write throughput jumps back up to 11MB/s. Much better, but disabling >disconnects kinda defeats the purpose of striping .... > > The only thing I can think of is that tags are somehow involved, as >disabling disconnects also disables tags. > > However, one slightly unusual thing about the striped drives is >that one drive is a plain fast/wide disk ("IBM DDRS-39130W S97B"), and >the other is the LVD version running in single-ended mode ("IBM >DDRS-39130D DC1B"), but this shouldn't matter. > >-- > Darryl Okahata > darrylo@sr.hp.com > >DISCLAIMER: this message is the author's personal opinion and does not >constitute the support, opinion, or policy of Hewlett-Packard, or of the >little green men that have been following him all day. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 16: 0:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id B1C8814E8B for ; Fri, 12 Mar 1999 16:00:43 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA34730; Fri, 12 Mar 1999 16:58:44 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903122358.QAA34730@panzer.plutotech.com> Subject: Re: SCSI disk oddities and Buslogic problems.. In-Reply-To: <199903122312.PAA12555@mina.sr.hp.com> from Darryl Okahata at "Mar 12, 1999 3:12:25 pm" To: darrylo@sr.hp.com Date: Fri, 12 Mar 1999 16:58:43 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darryl Okahata wrote... > sthaug@nethelp.no wrote: > > > Chris Csanady wrote: > > > In this case, I have found that while running the following commands that > > > the data transfer is very erratic. > > > > > > dd if=/dev/rda2s3 of=/dev/null bs=128k (or any place on the disk..) > > > > > > iostat -w 1 da2 > > > > No problem with a 9 GB model here. Typical iostat output: > > I have seen strange things with 3.1-RELEASE (I've yet to try > -current), and tagged queueing. Using 3.1-RELEASE, an Adaptec 7895 > controller (built into my Gigabyte 6BXDS motherboard) and two IBM > Ultrastar 9ES drives striped together using vinum, I get strange > performance numbers using iozone (yeah, iozone isn't very good for > benchmarking striped drives, but I'm just using it as a zero-th order > gauge). > > Individually (if I do not use vinum and just newfs a single drive), > I get around 11MB/s write, and 13MB/s read. No problem here. Yep, sounds fine. > If I stripe the drives together using vinum, and use the default > newfs values, I get something like 3.7MB/s write, and 16MB/s read. The > write throughput sucks. If I run newfs with 4K frag sizes, the write > throughput jumps up to around 7MB/sec. Better, but still not great. > > However, if I go into the BIOS and disable SCSI disconnect, the > write throughput jumps back up to 11MB/s. Much better, but disabling > disconnects kinda defeats the purpose of striping .... > > The only thing I can think of is that tags are somehow involved, as > disabling disconnects also disables tags. But it would also decrease the number of simultaneous transactions that vinum has to process. I think it's kinda hard to pin this on CAM or the drives, since the drives behave okay without being striped. How does the array perform if you stripe the disks together using ccd? It may just be a problem with whatever stripe size or parameters you're using with vinum. The fact that you got a vastly different result by upping the frag size to 4K points to that. Perhaps you just need to experiment a little more with stripe sizes and filesystem parameters. You may want to talk to Greg Lehey about this. He'll probably have some suggestions on vinum performance tuning. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 16: 1:32 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 EE8EA14F8F for ; Fri, 12 Mar 1999 16:01:29 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id PAA02283; Fri, 12 Mar 1999 15:56:57 -0800 Date: Fri, 12 Mar 1999 15:56:56 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Csanady Cc: Darryl Okahata , freebsd-scsi@FreeBSD.ORG, ken@plutotech.com Subject: Re: SCSI disk oddities and Buslogic problems.. In-Reply-To: <19990312235108.302BFAB@friley-185-205.res.iastate.edu> 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 > > Well, therein lies the problem. When I disable disconnection on these drives, > the performance is just as advertised. So, does it mean that the problem > is likely driver related? Only in that #'s of tags && disconnection are not dynamically determined based upon runtime performance measurement, and Ken will hit me over the head for saying so... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 16:10:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CE2C14D46 for ; Fri, 12 Mar 1999 16:10:25 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA34792; Fri, 12 Mar 1999 17:08:35 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903130008.RAA34792@panzer.plutotech.com> Subject: Re: SCSI disk oddities and Buslogic problems.. In-Reply-To: <19990312235108.302BFAB@friley-185-205.res.iastate.edu> from Chris Csanady at "Mar 12, 1999 5:51: 8 pm" To: cc@137.org (Chris Csanady) Date: Fri, 12 Mar 1999 17:08:35 -0700 (MST) Cc: darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Csanady wrote... > > Well, therein lies the problem. When I disable disconnection on these drives, > the performance is just as advertised. So, does it mean that the problem > is likely driver related? No, it doesn't. Try disabling tagged queueing for that disk and see what happens. (set the DQue bit on mode page 10 to 1 and reboot) Disabling disconnection effectively disables tagged queueing, I think. It means that the disk stays on the bus until a transaction is complete. It also means that no other disk will be able to get on the bus at the same time. I'm still confounded that you're having performance problems with that drive, when I've got > 100 of them and they perform just fine with tagged queueing and disconnection turned on. I would say that it's possible that you've got a bad firmware rev, but Steinar Haug has the same firmware rev, and gets good performance. It might also be worth running those disks on an Ultra-2 bus. Steinar Haug's disk is on an LVD bus. [long shot] It could be that the differential firmware for that drive has trouble running on a single ended bus. (All of the drives I have are single ended.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 16:12:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id B4CA115191 for ; Fri, 12 Mar 1999 16:12:29 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA34805; Fri, 12 Mar 1999 17:10:43 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903130010.RAA34805@panzer.plutotech.com> Subject: Re: SCSI disk oddities and Buslogic problems.. In-Reply-To: from Matthew Jacob at "Mar 12, 1999 3:56:56 pm" To: mjacob@feral.com Date: Fri, 12 Mar 1999 17:10:43 -0700 (MST) Cc: cc@137.org, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > > > > Well, therein lies the problem. When I disable disconnection on these drives, > > the performance is just as advertised. So, does it mean that the problem > > is likely driver related? > > Only in that #'s of tags && disconnection are not dynamically determined > based upon runtime performance measurement, and Ken will hit me over the > head for saying so... *whap* :) If you can come up with a reliable way to measure that sort of thing, I think it would be worth looking into. I think it is an extremely difficult proposition, though. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 16:18:46 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 1A69114F9C for ; Fri, 12 Mar 1999 16:17:25 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id QAA02385; Fri, 12 Mar 1999 16:13:32 -0800 Date: Fri, 12 Mar 1999 16:13:32 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: cc@137.org, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI disk oddities and Buslogic problems.. In-Reply-To: <199903130010.RAA34805@panzer.plutotech.com> 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 > Matthew Jacob wrote... > > > > > > Well, therein lies the problem. When I disable disconnection on these drives, > > > the performance is just as advertised. So, does it mean that the problem > > > is likely driver related? > > > > Only in that #'s of tags && disconnection are not dynamically determined > > based upon runtime performance measurement, and Ken will hit me over the > > head for saying so... > > *whap* > > :) > > If you can come up with a reliable way to measure that sort of thing, I > think it would be worth looking into. I think it is an extremely difficult > proposition, though. > D'accord. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 22:36:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp2.jps.net (smtp2.jps.net [209.63.224.235]) by hub.freebsd.org (Postfix) with ESMTP id 7C82914D4A for ; Fri, 12 Mar 1999 22:36:28 -0800 (PST) (envelope-from ulairi@jps.net) Received: from default (208-237-196-206.irv.jps.net [208.237.196.206]) by smtp2.jps.net (8.8.5/8.8.5) with SMTP id WAA24491 for ; Fri, 12 Mar 1999 22:36:06 -0800 (PST) From: "Ulairi" To: "FreeBSD - SCSI" Subject: Mylex FlashPoint LW drivers Date: Fri, 12 Mar 1999 22:35:52 -0800 Message-ID: <000e01be6d1b$bd729420$cec4edd0@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (keeping in mind I'm a newbie... :) ) Are there any projects for getting those? (Or maybe they are already there and I just did not look hard enough to find them?) the BT950 is the Mylex's designation for the card. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 12 22:49:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id DA6D514D69 for ; Fri, 12 Mar 1999 22:49:29 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA00947; Fri, 12 Mar 1999 23:49:09 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903130649.XAA00947@panzer.plutotech.com> Subject: Re: Mylex FlashPoint LW drivers In-Reply-To: <000e01be6d1b$bd729420$cec4edd0@default> from Ulairi at "Mar 12, 1999 10:35:52 pm" To: ulairi@jps.net (Ulairi) Date: Fri, 12 Mar 1999 23:49:09 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ulairi wrote... > (keeping in mind I'm a newbie... :) ) > Are there any projects for getting those? (Or maybe they are already there > and I just did not look hard enough to find them?) > > the BT950 is the Mylex's designation for the card. There are plans to do a Flashpoint driver, but there is no driver at the moment. This is a very frequently asked question. In fact, someone just asked about a Flashpoint card on this list yesterday. It's generally a good idea to search through the list archives before asking questions. If you search for 'flashpoint' in the freebsd-scsi list archives, you'll come up with a number of hits, and the first couple would probably answer your question. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 1:20:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id ED1A414C90 for ; Sat, 13 Mar 1999 01:20:45 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA09940 for freebsd-scsi@FreeBSD.ORG; Sat, 13 Mar 1999 10:20:26 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id KAA12534; Sat, 13 Mar 1999 10:13:50 +0100 (MET) (envelope-from j) Message-ID: <19990313101349.51196@uriah.heep.sax.de> Date: Sat, 13 Mar 1999 10:13:49 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour Reply-To: Joerg Wunsch References: <199903121057.UAA24445@nymph.detir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Fri, Mar 12, 1999 at 08:39:59AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote: > Yes, that's a bug for me to address. Where is this piece of > information from? I'd guess it's from the Tandberg manual. They are going great length to explain all the underlying concepts of QIC tapes, their block sizes etc. In a short summary: . QIC <= 150 uses 512-byte physical blocks . QIC >= 320 uses 1024-byte physical blocks (with 14 of them each being grouped into a frame, where frames are written as a single unit to the tape) . The Tandberg drives always support variable-length recording, where the logical block length can be 1..65535 for QIC <= 150, and 1..16MB for QIC >= 320. . The drives always support fixed-length recording with either 512, or for QIC >= 320 also 1024 bytes per block. For QIC >= 320, two logical 512 byte blocks will share one 1024-byte physical block. . Variable-length recording is basically an illusion that hides the underlying physical blocking. For QIC <= 150, this is very expensive, since a single tape block (512 bytes) is used for each variable-length logical block in order to record the block length, followed by the actual data blocks. This explains why nobody's going to use it. For QIC >= 320, the logical block length is apparently stored outside the physical tape block, so the efficiency of variable-length operation is high as long as the logical block size is a multiple of the physical blocksize (1024 bytes). That also explains why QIC >= 320 is commonly used with variable-length logical blocking. OTOH, setting the FIX bit, and using 1024-byte fixed blocks might IMHO increase the performance for them (since with the FIX bit set, you can specify multiple tape blocks in one SCSI command). I don't know whether anybody else could really read them, however. ;-) Btw., the Tandberg drives also have an option to enable the overwrite feature. Setting bit 4 in byte 8 on mode page 0x20 enables this (called EOWR). The comment says: ``Whe this bit is set the Drive will simulate the TAR (1/2" reel-to-reel) overwrite feature. The overwrite function can be used to overwrite data after the first data block on the tape or to overwrite two sequential filemarks before EOD. To overwrite data block(s) on the tape, the following cases must be satisfied: The tape must be positioned after the 1st logical block on the tape. If variable block, the logical block must not be more than 65534 (FFFEh) bytes. There are no filemarks so far on the tape and the next block from the tape is a data block. To overwrite a filemark, the following cases must be satisfied: The tape must be positioned at the 2nd of two sequential filemarks right in front of EOD. That means there are no data blocks following the filemarks. In this case overwrite from EOD will be allowed and the filemark cancel block will be written as the first block. ...'' -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 3:43:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 1173C14C2A for ; Sat, 13 Mar 1999 03:43:33 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id VAA19400; Sat, 13 Mar 1999 21:43:06 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma019395; Sat, 13 Mar 99 21:42:49 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id VAA18511; Sat, 13 Mar 1999 21:42:49 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id VAA28310; Sat, 13 Mar 1999 21:42:48 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id VAA24110; Sat, 13 Mar 1999 21:42:47 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199903131142.VAA24110@nymph.detir.qld.gov.au> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG, syssgm@detir.qld.gov.au Subject: Re: Strange SCSI QIC tape behaviour References: In-Reply-To: from Matthew Jacob at "Fri, 12 Mar 1999 08:39:59 -0800" Date: Sat, 13 Mar 1999 21:42:46 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Friday, 12th March 1999, Matthew Jacob wrote: >> So, is this the most bizarre drive on Earth, or perhaps are there bugs in >> the SCSI tape driver that need addressing? At the very least, the fixed >> block size for QIC tapes should be 1024 not 512 for densities above QIC-320. > >Yes, that's a bug for me to address. Where is this piece of information >from? Jörg described the situation quite well. But if you want to see Tandberg's view on it, read http://www.tandberg.com/download/manuals/42304206.pdf. It looks quite detailed and comprehensive. For the rest of their QIC info try http://www.tandberg.com/slr/slr_docs.html. So, do you think the other problems I raised are possible bugs, or simply drive quirks? For example, if I read a fixed blocked tape in variable block mode it works (a bit of a surprise) but is very slow. When I tell it to use fixed blocks (1024 bytes) it works at full speed. The driver never works it out for itself. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 9:17:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 83A351546A for ; Sat, 13 Mar 1999 09:15:16 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id KAA04031; Sat, 13 Mar 1999 10:05:55 -0700 (MST) Date: Sat, 13 Mar 1999 10:05:55 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903131705.KAA04031@narnia.plutotech.com> To: "Kenneth D. Merry" Cc: scsi@FreeBSD.org Subject: Re: SCSI disk oddities and Buslogic problems.. X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199903130008.RAA34792@panzer.plutotech.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199903130008.RAA34792@panzer.plutotech.com> you wrote: > > I'm still confounded that you're having performance problems with that > drive, when I've got > 100 of them and they perform just fine with tagged > queueing and disconnection turned on. Just remember the Jaz drive saga. We still have no idea why the performance was bad on these drives, but the performance issue went away when the user upgraded to a more recent 4.0-current. Perhaps there is a VM issue involved? We certainly didn't change any algorithms that would affect that device. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 9:18: 5 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 10D8A14D22 for ; Sat, 13 Mar 1999 09:17:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA04964; Sat, 13 Mar 1999 09:17:05 -0800 Date: Sat, 13 Mar 1999 09:17:04 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Joerg Wunsch , Stephen McKay Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour In-Reply-To: <19990313101349.51196@uriah.heep.sax.de> 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 Thanks for the info- I usually don't really try and program to devices I can't really test, but in this case I've noticed a lot of usage of this device, so I should try and get it right. It really was news to me that fixed block mode goes to 1K above QIC-320- but then, I haven't really worked with QIC for some years. It's not clear to me whether this is a generic standard or not. What I need to do here is to move up the priority list expanding the quirk entries so that drive specific preferred blocksizes and density codes are used (sound vaguely familiar from the old FreeBSD driver, eh?). I'd love to do this all from first principles and standards, but, guess what- that fails to please everyone (well, nothing will please everyone, and I might as well be disliked for something worthwhile like the tape driver than something silly like a Win32 Bulk Emailer...). The other problems you reported, Stephen, are mostly related to the hardwar. The speed issue and the strange densities- the former just *is* and the latter is just pretty much a passthru from/to the device. I'll probably be updating the -stable release streams by the middle of next week with changes here. Which I'll try and fit somewhere within the 7-8 projects I'm involved in (let's see- Fibre Channel Fabric support for Solaris today? Or NT PCI PCMCIA card reader driver? Get the slides for my "common driver talk" to Univ. of Minnesota? Merge latest NetBSD-current into Nasa/AMES MSS3a tree and resolve all the DMFS induced file conflicts? Build a 9 DataDirect CCD (~1TB) and test Matt Dillon's FFS/VM changes on that? So *many* things to do....urp..help!..) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 15:35:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id 0420514EAD for ; Sat, 13 Mar 1999 15:35:06 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id SAA11496; Sat, 13 Mar 1999 18:34:36 -0500 (EST) (envelope-from cao) Date: Sat, 13 Mar 1999 18:34:36 -0500 From: "Chuck O'Donnell" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: error messages from bt driver Message-ID: <19990313183436.B11051@milf18.bus.net> References: <19990311161748.D27999@milf18.bus.net> <199903112204.PAA00492@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199903112204.PAA00492@narnia.plutotech.com>; from Justin T. Gibbs on Thu, Mar 11, 1999 at 03:04:57PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 11, 1999 at 03:04:57PM -0700, Justin T. Gibbs wrote: > In article <19990311161748.D27999@milf18.bus.net> you wrote: > > Has anyone seen anything like output attached below? It shows up > > pretty much daily at 2:00 a.m. (specifically when the security script > > runs `find' I think). > > > > I have replaced the disk once and verified correct termination of the > > SCSI bus. > > > > I spent a while reading through bt(4) and bt.c, but I haven't been > > able to diagnose anything from them. I am mostly interested to know if > > it is a harmless diagnostic, buslogic hardware/firmware issue, or an > > actual error condition. > > Well, from a quick look at the code, I would guess that your > card is getting somewhat confused under high load. I would > suggest switching to 5.06I as 5.07B has been reported by the > Linux driver author to occassionally hang under load. 5.06I > is also the only firmware version Mylex is distributing off > their ftp site. > Thanks for the reply Justin. I tried 5.06I from the Mylex site, but no improvement. Same error messages show up. Any thoughts on other things I can check? Thanks. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 16:53:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 9F05F14DA9 for ; Sat, 13 Mar 1999 16:53:55 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id RAA13024; Sat, 13 Mar 1999 17:53:32 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903140053.RAA13024@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Chuck O'Donnell" Cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: error messages from bt driver In-reply-to: Your message of "Sat, 13 Mar 1999 18:34:36 EST." <19990313183436.B11051@milf18.bus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Mar 1999 17:44:29 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Thanks for the reply Justin. > >I tried 5.06I from the Mylex site, but no improvement. Same error >messages show up. Any thoughts on other things I can check? > >Thanks. > >Chuck One thing I don't know about on the MultiMasters is how they deal with a disk returning queue full status. Your Seagate will only handle 64 commands at a time, but we've queued up 191 to the Buslogic. Perhaps it will not release the mailbox for a transaction that is in the queue full state? This would cause the first error message to occur. My guess is that a quirk entry in sys/cam/cam_xpt.c limiting the number of tags for your drive to 64 will prevent the problem from happening. I'll also contact Mylex to see if they can give me any more information about how their controllers react. It's really a shame that they don't report queue full status back up to the driver so that we can be smarter about limiting the number of commands we send. RAID arrays can really make use of the extra tags, so I'd rather not place an artificial limit on them. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 23:50:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 59D5214C28 for ; Sat, 13 Mar 1999 23:50:33 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA25234 for freebsd-scsi@FreeBSD.ORG; Sun, 14 Mar 1999 08:50:14 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA55703; Sun, 14 Mar 1999 08:37:10 +0100 (MET) (envelope-from j) Message-ID: <19990314083709.50127@uriah.heep.sax.de> Date: Sun, 14 Mar 1999 08:37:09 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour Reply-To: Joerg Wunsch References: <19990313101349.51196@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Sat, Mar 13, 1999 at 09:17:04AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote: > Thanks for the info- I usually don't really try and program to > devices I can't really test, but in this case I've noticed a lot of > usage of this device, so I should try and get it right. Well, i've now finally also found the time to upgrade my machine to FreeBSD-current, which included (among others) an upgrade to CAM. So i can help out here as well, since i do have such a drive. I can confirm the problems with the drive under -current. Inserting a 2.5 GB cartridge (for my nightly backup), mt status displays a fixed blocksize of 1024 bytes, but the driver apparently fails to use this blocksize. (The drive is supposed to support it.) Some time when trying to use the drive (i eventually forgot when it happened), i get: (sa0:ncr0:0:4:0): Err0, Mode Select Data= 0x00 0x00 0x10 0x08 0x7f \ 0x00 0x00 0x00 0x00 0x00 0x02 0x00 on the console. After adjusting the blocksize to `variable', the drive works with this cartridge. However, if i compare the nightly dump speed to the pre-CAM system, it dropped from 400...500 KB/s down to 300 KB/s. (I can't say for sure that this was caused by the tape driver, it could be due to a lower disk performance under CAM as well, but i wouldn't really expect the latter.) I also noticed that the sa driver doesn't claim device entries in DEVFS. This should be easy to fix (and a lot more of the CAM entries are missing, only the da's are there), so i could try to fix this myself. > It really was news to me that fixed block mode goes to 1K above > QIC-320- but then, I haven't really worked with QIC for some > years. It's not clear to me whether this is a generic standard or > not. It was also news to me :). From reading their manual, the physical block size on the tape seems to be mandated by the QIC standard. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 13 23:50:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 7152F14D7E for ; Sat, 13 Mar 1999 23:50:38 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA25235 for freebsd-scsi@FreeBSD.org; Sun, 14 Mar 1999 08:50:19 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA58166; Sun, 14 Mar 1999 08:48:51 +0100 (MET) (envelope-from j) Message-ID: <19990314084849.47902@uriah.heep.sax.de> Date: Sun, 14 Mar 1999 08:48:49 +0100 From: J Wunsch To: FreeBSD SCSI list Subject: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, as i wrote in the other message, i'm now (finally) also with CAM at home. Basically, everything's working fine so far. (Unlike what Ken wrote, i can't confirm the problems with the IBM DCAS with tagged queuing, but i'll try to collect bonnie and iozone data first.) Well, the subject says what's not working yet: my old SONY MO drive. Upon booting, i get (after a rather long timeout, i. e. while the system is already proceeding with the boot): (da2:ncr1:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:ncr1:0:3:0): NOT READY asc:4,0 (da2:ncr1:0:3:0): Logical unit not ready, cause not reportable (da2:ncr1:0:3:0): fatal error, failed to attach to device (da2:ncr1:0:3:0): lost device (da2:ncr1:0:3:0): removing device entry Hmm, yes, the drive ain't spinning by that time (i keep it down when not used), but i was under the impression the probe routine would spin it up anyway? At least the old od(4) driver did so (and in my hacked version, automatically brought the drive down when not openened by anyone.) I can then spin it up manually using the associated pass device, but a `camcontrol rescan' doesn't get it back as a `da2' as i would have expected. Here's all i could get so far: uriah # camcontrol inquiry -n pass -u 4 Removable Direct Access SCSI-CCS device Serial Number 0.0MB/s transfers uriah # camcontrol start -n pass -u 4 Unit started successfully uriah # camcontrol tur -n pass -u 4 Unit is ready uriah # camcontrol rescan 1 Re-scan of bus 1 was successful uriah # camcontrol rescan 0 Re-scan of bus 0 was successful uriah # camcontrol devlist < > at scbus-1 target -1 lun -1 (xpt0) at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 2 lun 0 (pass1,cd0) at scbus0 target 4 lun 0 (pass2,sa0) < > at scbus0 target -1 lun -1 () at scbus1 target 1 lun 0 (pass3,da1) at scbus1 target 3 lun 0 (pass4) < > at scbus1 target -1 lun -1 () Does anybody have a hint, maybe an idea for the quirk entry that's required in order to get the drive working? (Yes, it's SCSI-CCS only, and it actually ain't even a SCSI drive, but rather an ESDI-to-SCSI bridge. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message