From owner-freebsd-scsi Sun Jan 14 15:48:35 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id CC6DC37B401 for ; Sun, 14 Jan 2001 15:48:18 -0800 (PST) Received: (qmail 91950 invoked by uid 1000); 14 Jan 2001 23:48:40 -0000 Date: Sun, 14 Jan 2001 15:48:18 -0800 From: Jos Backus To: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? Message-ID: <20010114154818.A91448@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <3A614EB7.D72489A7@iprimus.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A614EB7.D72489A7@iprimus.com.au>; from jclift@iprimus.com.au on Sun, Jan 14, 2001 at 06:00:49PM +1100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fyi: I'm pretty sure that NetBackup was made by a company named OpenVision, before it was bought by Veritas. I was looking for an alternative to Legato's NetWorker at the time and surely the Legato rep would have told me they were going to acquire NetBackup :) -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 1: 2:31 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from tamaris.wanadoo.fr (smtp-rt-12.wanadoo.fr [193.252.19.60]) by hub.freebsd.org (Postfix) with ESMTP id 8A38A37B69B for ; Mon, 15 Jan 2001 01:02:12 -0800 (PST) Received: from villosa.wanadoo.fr (193.252.19.122) by tamaris.wanadoo.fr; 15 Jan 2001 10:02:10 +0100 Received: from hautmedoc.dockes.com (193.250.57.187) by villosa.wanadoo.fr; 15 Jan 2001 10:02:09 +0100 Received: (from dockes@localhost) by hautmedoc.dockes.com (8.9.3/8.9.3) id KAA14063; Mon, 15 Jan 2001 10:02:02 +0100 (MET) From: Jean-Francois Dockes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14946.48266.332620.887204@hautmedoc.dockes.com> Date: Mon, 15 Jan 2001 10:02:02 +0100 (MET) To: mjacob@feral.com Cc: Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: References: X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > [cut] > So, all other things being equal, "First Block Value" should be > good enough if one assumes that blocks Z..A get flushed to tape. > > ... > Anyone else out there have an opinion on this? > ... Funny, I was just working with sa last week for the purpose of porting some NDMP backup tape server code. I had trouble with how 'sa' maintains the current tape position (I submitted a few PRs), and I wondered if I could use MTIOCRDSPOS instead, but I was prevented to do this precisely by the flush thing (I didn't even try to use MTIOCRDSPOS, as the code made it clear that it was unusable for my purpose). So, yes, I have an opinion, and it is that no flush should be performed. In practise, I think that only the 'First Block' value is useful for backup software, and its signification is pretty clear. I guess that the comment in the code about how the SCSI spec is vague relate to the 'Last block' value, but I can't really understand what the 'Last Block' thing is good for anyway. Jean-Francois Dockes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 8:39:22 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 91D6E37B69E for ; Mon, 15 Jan 2001 08:39:05 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id JAA00955; Mon, 15 Jan 2001 09:40:15 -0700 Date: Mon, 15 Jan 2001 09:40:15 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Jos Backus Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: <20010114154818.A91448@lizzy.bugworks.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 Sun, 14 Jan 2001, Jos Backus wrote: > Fyi: I'm pretty sure that NetBackup was made by a company named OpenVision, > before it was bought by Veritas. I was looking for an alternative to Legato's > NetWorker at the time and surely the Legato rep would have told me they were > going to acquire NetBackup :) Sorry, NetWorker, not NetBackup, that'll teach me to send email at the end of a 70 hour week :-}. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 8:39:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 18F9937B6A3 for ; Mon, 15 Jan 2001 08:39:28 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA06849; Mon, 15 Jan 2001 08:34:04 -0800 Date: Mon, 15 Jan 2001 08:34:04 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jean-Francois Dockes Cc: Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: <14946.48266.332620.887204@hautmedoc.dockes.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 Okay. You're porting and NDMP server? Good! Will you make it publicly available? On Mon, 15 Jan 2001, Jean-Francois Dockes wrote: > Matthew Jacob writes: > > [cut] > > So, all other things being equal, "First Block Value" should be > > good enough if one assumes that blocks Z..A get flushed to tape. > > > > ... > > Anyone else out there have an opinion on this? > > ... > > Funny, I was just working with sa last week for the purpose of porting some > NDMP backup tape server code. I had trouble with how 'sa' maintains the > current tape position (I submitted a few PRs), and I wondered if I could > use MTIOCRDSPOS instead, but I was prevented to do this precisely by the > flush thing (I didn't even try to use MTIOCRDSPOS, as the code made it > clear that it was unusable for my purpose). > > So, yes, I have an opinion, and it is that no flush should be performed. In > practise, I think that only the 'First Block' value is useful for backup > software, and its signification is pretty clear. I guess that the comment > in the code about how the SCSI spec is vague relate to the 'Last block' > value, but I can't really understand what the 'Last Block' thing is good > for anyway. > > Jean-Francois Dockes > > > 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 Mon Jan 15 8:41:45 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id E9C0737B400 for ; Mon, 15 Jan 2001 08:41:28 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id JAA00946; Mon, 15 Jan 2001 09:37:57 -0700 Date: Mon, 15 Jan 2001 09:37:57 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Jean-Francois Dockes Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: <14946.48266.332620.887204@hautmedoc.dockes.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 Mon, 15 Jan 2001, Jean-Francois Dockes wrote: > So, yes, I have an opinion, and it is that no flush should be performed. In > practise, I think that only the 'First Block' value is useful for backup > software, and its signification is pretty clear. I guess that the comment > in the code about how the SCSI spec is vague relate to the 'Last block' > value, but I can't really understand what the 'Last Block' thing is good > for anyway. Well, I agree (obviously!). Sunday I decided to skip the whole tape driver and go straight to the sgen device that corresponds with the tape drive and issue raw SCSI commands to grab tape position (no, I'm not intermingling sgen and sa commands, this was for use from the storage manager prior to opening sa for read or write). I had the Tandberg SLR 50/60/100 manual and noticed that 'Last Block Location' is hard-coded to zero when you request logical block position (BT=0). Obviously this isn't too useful! I believe the Mammoth II also hardwires 'Last Block' to '0'. The Seagate DAT says it has something in the 'Last Block Location' field (apparently a copy of whatever is in the 'First Block Location' field, according to page 121 of the DDS-4 manual), but obviously if one of our major supported drives has it hard-coded to zero, this tends to indicate that the field is useless. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 9: 7:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id A025B37B404 for ; Mon, 15 Jan 2001 09:07:28 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id KAA00980; Mon, 15 Jan 2001 10:04:33 -0700 Date: Mon, 15 Jan 2001 10:04:33 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? 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 Sat, 13 Jan 2001, Matthew Jacob wrote: > LOGICAL block position is different- I would expect block #Z to be 26 more > than block #A above- this shouldn't change. Again, assuming Z..A make it to > tape (if they don't that's a catastrophic error). > > I notice you're using MTIOCRSPOS- I think I would tend agree that this > wouldn't require a flush. Hardware position should probably stay where it is > now. And in fact at least one of the drives we must be compatible with (the Tandberg SLR line) will happily burp all over the floor if you attempt to use physical positioning. I assume that anybody else doing enterprise backup would have the same problem, so the logical positioning case is probably more common. > p.s.: Not all drives, btw, have a horrible speed loss with the flush > operation. DAT drives seem fine. DLTs are horribly affected. I noticed the horrible speed loss with a Seagate DDS-3 DAT drive. We're talking about going down to a max of 20K per second thruput when talking about small files (those < 20K in size). Taking out the flush got us back up to the full 1M/sec thruput of the DDS-3 DAT drive. > [ yes, I'll ignore your barbarous manners. the content *is* important- not > because BRU or ESTinc (ESTINK? New Unix errno?) is all that important- but the Thanks :-). And yes, I agree that these products are not particularly important for most current users of FreeBSD, who appear to be big users of 'dump' or afio. I do believe, however, that there is a potential market for an easy-to-use network tape backup product for small businesses and workgroups -- one that can be easily installed and configured by mere mortals without having to have a high-level Unix system administrator on staff. Obviously someone else agrees -- we have some venture capital for that. I managed to sell the idea of FreeBSD as a tier 1 platform to my management by using the spectre of backup appliances. Since my management is extremely Linux-centric (as you'd expect, given that we're owned by a Linux vendor), that was a pretty hard sale, but (shrug). What can I say, sometimes I like to use a real OS rather than a hodge-podge of tossed together software :-). > problem *has* been seen before... And, oh, btw, NetBackup ended up owned by > Veritas, not Legato, I believe ] I'm getting confused now. Let's see, Veritas is the former Seagate Software is the former software division of Archive Corporation? Or is that Legato? What do I know, I'm just an engineer :-). -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 9:20:57 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D437637B400 for ; Mon, 15 Jan 2001 09:20:40 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA07030; Mon, 15 Jan 2001 09:15:22 -0800 Date: Mon, 15 Jan 2001 09:15:20 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? 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'll do some tests today with the drives I have in -current- I also will fix a couple other PRs while I'm at it. There's a policy to not drop it back to -stable 'right away', so expect it to show up in -stable in about a week. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 10:20: 6 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from alisier.wanadoo.fr (smtp-rt-9.wanadoo.fr [193.252.19.55]) by hub.freebsd.org (Postfix) with ESMTP id 0A43F37B400 for ; Mon, 15 Jan 2001 10:19:49 -0800 (PST) Received: from amyris.wanadoo.fr (193.252.19.150) by alisier.wanadoo.fr; 15 Jan 2001 19:19:47 +0100 Received: from hautmedoc.dockes.com (193.248.71.235) by amyris.wanadoo.fr; 15 Jan 2001 19:19:24 +0100 Received: (from dockes@localhost) by hautmedoc.dockes.com (8.9.3/8.9.3) id TAA15646; Mon, 15 Jan 2001 19:19:23 +0100 (MET) From: Jean-Francois Dockes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14947.16163.316903.727185@hautmedoc.dockes.com> Date: Mon, 15 Jan 2001 19:19:15 +0100 (MET) To: mjacob@feral.com Cc: Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: References: <14946.48266.332620.887204@hautmedoc.dockes.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > You're porting and NDMP server? Good! Will you make it publicly available? I am doing this NDMP thing for a customer, using some of their proprietary code, so I can't release the result. This was mainly a solaris job, and I just tried the FreeBSD port for the fun of it, and with the goal of enabling FreeBSD as a tape server platform for my customer's product ;) As I ran into trouble with maintaining tape position, I dropped the idea for the moment. Convincing them that FreeBSD was the best tape server platform for them was a long bet anyway, and if I have to add a custom driver, it becomes really complicated (I hope to be back at it later). There is a nice open-source NDMP package at http://traakan.traakan.com/ndmjob/ . There are some pieces missing, but the author said that he is going to release a new version soon, and this could be the basis for a FreeBSD port. In the current release, the main missing pieces are: - Part of the authentication code. I submitted small FreeBSD patches to the author for this, I hope that they (or a replacement) will be in the future release. - Real tape interface code. This would be really easy to add for FreeBSD, if only 'sa' would better keep the tape position. It would probably be possible to do it with the current 'sa' by using the resid counts on tape move operations, and updating the position internally on read/write. - Some of the 'DATA' interface code. You can backup, but not restore... I hope that this will be added in the next release of ndmjob. With this port, I think that a FreeBSD machine could be part of an NDMP setup, either as a TAPE server (machine with a tape drive connected), or as a DATA server (machine to be backed-up/restored). The NDMP client (backup manager) in ndmjob is not that useful, it's mainly a test tool. I'll take a try at doing the port when the new version comes out, if this is okayed by my customer. Jean-Francois Dockes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 10:29:48 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 805B537B400 for ; Mon, 15 Jan 2001 10:29:31 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id LAA01038; Mon, 15 Jan 2001 11:26:35 -0700 Date: Mon, 15 Jan 2001 11:26:35 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? 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, 15 Jan 2001, Eric Lee Green wrote: > On Sat, 13 Jan 2001, Matthew Jacob wrote: > > p.s.: Not all drives, btw, have a horrible speed loss with the flush > > operation. DAT drives seem fine. DLTs are horribly affected. > > I noticed the horrible speed loss with a Seagate DDS-3 DAT drive. We're Sorry, I just checked to see what drive was hooked up to my FreeBSD box and I was wrong about the vendor of the DDS-3 drive. The drive that got slowed down to 8K/sec by the SETMARK 0 was a Tecmar DDS-3 DAT drive. I will attest that the READ_POSITION works fine there w/o the preceding SETMARK 0. I'll test it with an Ecrix VXA shortly. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 10:30:21 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C925D37B404 for ; Mon, 15 Jan 2001 10:30:03 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA07351; Mon, 15 Jan 2001 10:24:43 -0800 Date: Mon, 15 Jan 2001 10:24:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jean-Francois Dockes Cc: Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: <14947.16163.316903.727185@hautmedoc.dockes.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 Mon, 15 Jan 2001, Jean-Francois Dockes wrote: > Matthew Jacob writes: > > You're porting and NDMP server? Good! Will you make it publicly available? > > I am doing this NDMP thing for a customer, using some of their proprietary > code, so I can't release the result. > > This was mainly a solaris job, and I just tried the FreeBSD port for > the fun of it, and with the goal of enabling FreeBSD as a tape server > platform for my customer's product ;) > > As I ran into trouble with maintaining tape position, I dropped the > idea for the moment. Convincing them that FreeBSD was the best tape server > platform for them was a long bet anyway, and if I have to add a custom > driver, it becomes really complicated (I hope to be back at it later). Yeah, well, my bad. I'm working on this this morning. > > There is a nice open-source NDMP package at > http://traakan.traakan.com/ndmjob/ . There are some pieces missing, but the > author said that he is going to release a new version soon, and this could > be the basis for a FreeBSD port. Actually, I'm on the hook for doing this for FreeBSD/NetBSD/Linux (I do some work for Traakan). It's just that other items have gotten in the way before I could get to it. But, hey, if you're gonna do it.... > In the current release, the main missing pieces are: > - Part of the authentication code. I submitted small FreeBSD patches to the > author for this, I hope that they (or a replacement) will be in the > future release. > - Real tape interface code. This would be really easy to add for FreeBSD, > if only 'sa' would better keep the tape position. It would probably be > possible to do it with the current 'sa' by using the resid counts on > tape move operations, and updating the position internally on read/write. > - Some of the 'DATA' interface code. You can backup, but not restore... I > hope that this will be added in the next release of ndmjob. > > With this port, I think that a FreeBSD machine could be part of an NDMP > setup, either as a TAPE server (machine with a tape drive connected), or as > a DATA server (machine to be backed-up/restored). The NDMP client (backup > manager) in ndmjob is not that useful, it's mainly a test tool. > > I'll take a try at doing the port when the new version comes out, if > this is okayed by my customer. Well- that'd be cool, actually. I think that *BSD and Linux could really use this. Dump/Restore just don't cut it. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 11:49:48 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from arutam.inch.com (ns.inch.com [216.223.192.21]) by hub.freebsd.org (Postfix) with ESMTP id 3F9FB37B400 for ; Mon, 15 Jan 2001 11:49:30 -0800 (PST) Received: from inch.com (inch.com [216.223.192.20]) by arutam.inch.com (8.9.3/8.9.3/UTIL-INCH-2.2.0) with ESMTP id OAA16418; Mon, 15 Jan 2001 14:49:17 -0500 (EST) Date: Mon, 15 Jan 2001 14:49:17 -0500 (EST) From: Charles Sprickman To: Chris Faulhaber Cc: Subject: Re: recommended/supported raid In-Reply-To: <20010111130735.A12629@peitho.fxp.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 I've seen Mike's page, and I finally got a BSDI/Telenet rep to quote out a system... I have a choice between an Adaptec 3200 (BSDI's recommendation) or a Mylex 352. On paper, the Mylex looks better. I also can't quite tell from Mike's page or Adaptec's site where the the driver came from for this card. Adaptec claims FreeBSD support, but don't really mention to what extent. I believe the Adaptec has a management interface, which is essential in my case as the box is at a remote location (If a drive fails in the middle of a forest...). I don't believe there is a management app for that particular Mylex card. If anyone can clarify any of these points, it would be much appreciated. thanks, Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Thu, 11 Jan 2001, Chris Faulhaber wrote: > On Thu, Jan 11, 2001 at 12:55:47PM -0500, Charles Sprickman wrote: > > > > My question is this... Which "built-in" raid controllers out there work > > with FreeBSD? I was looking at the IBM Netfinity with "IBM ServeRaid", > > and I can't tell what kind of controller this is or if it's supported... > > > > Generically, supported RAID controller info can be found at: > http://people.FreeBSD.org/~msmith/RAID/ > > -- > Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org > -------------------------------------------------------- > FreeBSD: The Power To Serve - 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 Jan 15 13:39:45 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (dhcp45-24.dis.org [216.240.45.24]) by hub.freebsd.org (Postfix) with ESMTP id 3AD2D37B400 for ; Mon, 15 Jan 2001 13:39:27 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f0FLrSs00896; Mon, 15 Jan 2001 13:53:28 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101152153.f0FLrSs00896@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Charles Sprickman Cc: Chris Faulhaber , freebsd-scsi@freebsd.org Subject: Re: recommended/supported raid In-reply-to: Your message of "Mon, 15 Jan 2001 14:49:17 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jan 2001 13:53:28 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The two cards are about equivalent, and you're correct; there's no management support for the Mylex cards at this point in time. > I've seen Mike's page, and I finally got a BSDI/Telenet rep to quote out a > system... I have a choice between an Adaptec 3200 (BSDI's recommendation) > or a Mylex 352. > > On paper, the Mylex looks better. I also can't quite tell from Mike's > page or Adaptec's site where the the driver came from for this card. > Adaptec claims FreeBSD support, but don't really mention to what extent. > > I believe the Adaptec has a management interface, which is essential in my > case as the box is at a remote location (If a drive fails in the middle of > a forest...). I don't believe there is a management app for that > particular Mylex card. > > If anyone can clarify any of these points, it would be much appreciated. > > thanks, > > Charles > > | Charles Sprickman | Internet Channel > | INCH System Administration Team | (212)243-5200 > | spork@inch.com | access@inch.com > > On Thu, 11 Jan 2001, Chris Faulhaber wrote: > > > On Thu, Jan 11, 2001 at 12:55:47PM -0500, Charles Sprickman wrote: > > > > > > My question is this... Which "built-in" raid controllers out there work > > > with FreeBSD? I was looking at the IBM Netfinity with "IBM ServeRaid", > > > and I can't tell what kind of controller this is or if it's supported... > > > > > > > Generically, supported RAID controller info can be found at: > > http://people.FreeBSD.org/~msmith/RAID/ > > > > -- > > Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org > > -------------------------------------------------------- > > FreeBSD: The Power To Serve - http://www.FreeBSD.org > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 17:27: 8 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E1B1B37B69B; Mon, 15 Jan 2001 17:26:49 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id RAA09407; Mon, 15 Jan 2001 17:26:50 -0800 Date: Mon, 15 Jan 2001 17:26:48 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: freebsd-scsi@freebsd.org, alpha@freebsd.org Subject: huh... watch out for overflows... 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 construct is fairly common in CAM drivers: timeout(XXXX, YYYYY, (ccb->ccb_h.timeout * hz)/1000); The problem here is that timeout is u_int32_t and that some platforms have a high hz rate (1024 on some alphas, e.g.). If you take the normal tape timeout of two hours for an I/O operation, and keeping in mind that timeout is in milliseconds, you overflow 32 bits, thus leading to a timeout with a somewhat unpredictable (but surely wrong) value. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 15 20: 4:55 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail2.clarkson.edu (majordomo.clarkson.edu [128.153.4.13]) by hub.freebsd.org (Postfix) with SMTP id A837E37B401 for ; Mon, 15 Jan 2001 20:04:38 -0800 (PST) Received: (qmail 13393 invoked by uid 0); 16 Jan 2001 04:04:31 -0000 Received: from vador.aoc.clarkson.edu (128.153.130.33) by mail.clarkson.edu with SMTP; 16 Jan 2001 04:04:31 -0000 Date: Mon, 15 Jan 2001 23:03:19 -0500 (EST) From: Todd Cohen X-Sender: cohentl@vador.aoc.clarkson.edu To: freebsd-scsi@freebsd.org Subject: Tekram 315 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 Is anyone working on supporting the Tekram DC315U controller in freebsd-current? I know that tekram has some drivers on their ftp site, but I do not know if they work with FreeBSD 4.2 or newer. Any chance in this being merged into the current code base? Or is there a licensing issue? -Todd __________________________________________________________________________ ICMP: The protocol that goes PING! I like angles, but only to a degree. cthread. cthread_fork(). Fork, thread, fork! Black holes suck. http://wckn.clarkson.edu/~cohentl/ Real_men_don't_need_spacebars. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 16 20:19:11 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id 27D6D37B400 for ; Tue, 16 Jan 2001 20:18:52 -0800 (PST) Received: (qmail 26580883 invoked from network); 17 Jan 2001 04:18:50 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 17 Jan 2001 04:18:50 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id f0H4ImK59297; Wed, 17 Jan 2001 05:18:48 +0100 (CET) (envelope-from clefevre@citeweb.net) To: "Kenneth D. Merry" Cc: clefevre@poboxes.com, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI suspend/resume References: <20010112211218.A32720@panzer.kdm.org> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: "Kenneth D. Merry"'s message of "Fri, 12 Jan 2001 21:12:18 -0700" From: Cyrille Lefevre Reply-To: clefevre@poboxes.com Mail-Copies-To: never Date: 17 Jan 2001 05:18:45 +0100 Message-ID: Lines: 71 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" writes: sorry for the late answer, but I can't "spin down" my drives until now. > On Sat, Jan 13, 2001 at 05:01:10 +0100, Cyrille Lefevre wrote: > > Is there a way to suspend/resume SCSI devices as IDE devices does ? > > > > currently, if an SCSI device is manually suspended using camcontrol, > > it couldn't be automatically resumed except using camcontrol as well. > > The only thing I can figure you mean by "suspend" is "spin down". > > You can do that with camcontrol, like this: > > camcontrol stop da0 yes, I know that. > As soon as you try to access the drive, the SCSI subsystem will spin it > back up. You can also spin a drive up with camcontrol: > > camcontrol start da0 yes, but those thing cannot be made automatically by the kernel as this is done for IDE devices. > > while EDI devices maybe suspended/resumed through apm -z... > > EDI devices? What are those? typo, read IDE. what do I mean is... on zzz (apm -Z), IDE drives are slept and waiked u[ automatically by the kernel. and it seems there is no equivalent way to do this for SCSI devices. try the following sequence : # grep /disk[12] /etc/fstab /dev/ad0s1a /disk1 ufs rw 1 2 /dev/da1s1a /disk2 ufs rw 1 2 # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 1904559 1720449 31746 98% / /dev/ad0s1a 1904559 1655671 96524 94% /disk1 /dev/da1s1a 2031922 1872260 -2891 100% /disk2 (yes, I know, I'm almost full :) # umount /disk1 # umount /disk2 # zzz (you heard that disk1 is spinning down, but not disk2, so) # camcontrol stop da1 # mount /disk1 (no problem, disk1 is waiked up and mounted) # mount /disk2 (oops) Jan 17 05:01:57 gits /kernel: (da1:sym0:0:4:0): . CDB: 8 0 0 0 1 0 Jan 17 05:01:57 gits /kernel: (da1:sym0:0:4:0): NOT READY asc:4,2 Jan 17 05:01:57 gits /kernel: (da1:sym0:0:4:0): field replaceable unit: 2 Jan 17 05:01:57 gits /kernel: da1: reading primary partition table: error reading fsbn 0 Jan 17 05:09:40 gits /kernel: (da1:sym0:0:4:0): . CDB: 8 0 0 0 1 0 # camcontrol stop da1 Unit started successfully # mount /disk2 (ok) do you understand what I mean ? PS : don't do that if you have any swap space on an SCSI drive or you're dead. Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 16 21:39: 1 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from kwanon.research.canon.com.au (kwanon.research.canon.com.au [203.12.172.254]) by hub.freebsd.org (Postfix) with ESMTP id 5901137B401 for ; Tue, 16 Jan 2001 21:38:42 -0800 (PST) Received: from bellmann.research.canon.com.au (bellmann.research.canon.com.au [10.5.0.3]) by kwanon.research.canon.com.au (Postfix) with ESMTP id A78088A8B4 for ; Wed, 17 Jan 2001 05:45:05 +0000 (UTC) Received: from elph.research.canon.com.au (elph.research.canon.com.au [203.12.174.253]) by bellmann.research.canon.com.au (Postfix) with ESMTP id D927C8B10 for ; Wed, 17 Jan 2001 16:27:08 +1100 (EST) Received: from blow.research.canon.com.au (blow.research.canon.com.au [10.8.1.4]) by elph.research.canon.com.au (Postfix) with ESMTP id 26B913A0 for ; Wed, 17 Jan 2001 16:38:35 +1100 (EST) Date: Wed, 17 Jan 2001 16:38:40 +1100 (EST) From: Iain Templeton To: freebsd-scsi@freebsd.org Subject: Target mode on aic7880 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 Howdy folks, I am having a bit of trouble with target mode on an aic7880 controller and I am looking for some ideas as to why. I have two Adaptec 2940UW cards in two different machines (annoyingly both coming up as ahc1, but nevermind), one with id = 6, and one with id = 7. They are connected using the internal 68 pin connection using a flat ribbon cable type of affair. The termination is set to automatic for both. This is the only connection on both controller cards. I'm putting the id7 controller into target mode using scsi_target from /usr/share/examples/scsi_target. From here I can do things like camcontrol reset using the id6 controller which does reset the bus, and I see the message ahc1: Somebody reset channel A or likewise on the other machine (id7 controller). However if I try and do a rescan of that bus, the target mode controller does not respond to an inquiry command. It appears also that the CAM system doesn't even get a message from ahc1 that such a command is sent. In fact, I put a few extra printf's in aic7xxx.c and got nothing out of them at all (inside the ahc_seqint() function looking for HOST_MSG_LOOP). I cannot use camcontrol to send CCB's to the target device either since there is no pass through driver allocated for the device. So what I'd like to know is: 1. Is target mode even known to work on aic7880's or aic7891's? 2. Is there any particular controller that target mode is known to work well on. I know there are a few qlogic's that it is said to work on, but for political reasons I can't buy one of them (or anything else for that matter) right now. Plus, if we use SCSI for what I'm doing it will probably be a motherboard controller, and I don't know if there are many mb's with non-adaptec controllers. I have tried the same thing using an aic7891 as both the target and initiator and that didn't seem to work either. I have also had an extra device hanging off the bus to make sure that it is cabled/terminated properly. I seem to be able to find it (its a ZIP drive) from both machines. The interesting parts of dmesg for machine #1 (with id 6 are): ahc0: port 0xf400-0xf4ff mem 0xfedfa000-0xfedfafff irq 10 at device 8.0 on pci0 ahc0: No SEEPROM available. ahc0: Using left over BIOS settings ahc0: hardware scb 64 bytes; kernel scb 52 bytes; ahc_dma 8 bytes ahc0: Downloading Sequencer Program... 429 instructions downloaded aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs ahc1: port 0xec00-0xecff mem 0xfedf9000-0xfedf9fff irq 11 at device 12.0 on pci0 ahc1: Reading SEEPROM...done. ahc1: internal 50 cable not present, internal 68 cable is present ahc1: external cable not present ahc1: BIOS eeprom is present ahc1: 68 pin termination Enabled ahc1: 50 pin termination Enabled ahc1: hardware scb 64 bytes; kernel scb 52 bytes; ahc_dma 8 bytes ahc1: Downloading Sequencer Program... 428 instructions downloaded aic7880: Wide Channel A, SCSI Id=6, 16/255 SCBs using shared irq11. Similarly for machine #2 (with id 7); ahc0: port 0x1400-0x14ff mem 0xfa100000-0xfa100fff irq 11 at device 13.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Manual LVD Termination ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 422 instructions downloaded aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x1c00-0x1cff mem 0xfa101000-0xfa101fff irq 11 at device 18.0 on pci0 ahc1: Reading SEEPROM...done. ahc1: internal 50 cable not present, internal 68 cable is present ahc1: external cable not present ahc1: BIOS eeprom is present ahc1: 68 pin termination Enabled ahc1: 50 pin termination Enabled ahc1: Downloading Sequencer Program... 428 instructions downloaded aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs using shared irq11. [ and later ] Configuring Target Mode 392 instructions downloaded (targ0:ahc0:0:7:0): Lun now enabled for target mode (targ0:ahc0:0:7:0): Target mode disabled Configuring Initiator Mode 422 instructions downloaded In between the time that I turn target mode on and it gets turned back off again I have run camcontrol rescan on the other machine, and it doesn't make any difference. Anyway, any suggestions greatfully accepted. Iain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 9:47:25 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id BBFC237B401 for ; Wed, 17 Jan 2001 09:47:00 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA17475; Wed, 17 Jan 2001 10:44:37 -0700 (MST) (envelope-from ken) Date: Wed, 17 Jan 2001 10:44:37 -0700 From: "Kenneth D. Merry" To: clefevre@poboxes.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI suspend/resume Message-ID: <20010117104437.B17373@panzer.kdm.org> References: <20010112211218.A32720@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from clefevre@citeweb.net on Wed, Jan 17, 2001 at 05:18:45AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 17, 2001 at 05:18:45 +0100, Cyrille Lefevre wrote: > "Kenneth D. Merry" writes: > > sorry for the late answer, but I can't "spin down" my drives until now. > > > As soon as you try to access the drive, the SCSI subsystem will spin it > > back up. You can also spin a drive up with camcontrol: > > > > camcontrol start da0 > > yes, but those thing cannot be made automatically by the kernel as this > is done for IDE devices. Justin says that the apm code makes a BIOS call, and that the BIOS knows how to spin down an IDE disk. It doesn't know how to spin down a SCSI disk, though. So that's why apm -Z doesn't spin down your SCSI disk. > > > while EDI devices maybe suspended/resumed through apm -z... > > > > EDI devices? What are those? > > typo, read IDE. > > what do I mean is... on zzz (apm -Z), IDE drives are slept and waiked > u[ automatically by the kernel. and it seems there is no equivalent > way to do this for SCSI devices. try the following sequence : > > # grep /disk[12] /etc/fstab > /dev/ad0s1a /disk1 ufs rw 1 2 > /dev/da1s1a /disk2 ufs rw 1 2 > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 1904559 1720449 31746 98% / > /dev/ad0s1a 1904559 1655671 96524 94% /disk1 > /dev/da1s1a 2031922 1872260 -2891 100% /disk2 > (yes, I know, I'm almost full :) > # umount /disk1 > # umount /disk2 > # zzz > (you heard that disk1 is spinning down, but not disk2, so) > # camcontrol stop da1 > # mount /disk1 > (no problem, disk1 is waiked up and mounted) > # mount /disk2 > (oops) > Jan 17 05:01:57 gits /kernel: (da1:sym0:0:4:0): . CDB: 8 0 0 0 1 0 > Jan 17 05:01:57 gits /kernel: (da1:sym0:0:4:0): NOT READY asc:4,2 > Jan 17 05:01:57 gits /kernel: (da1:sym0:0:4:0): field replaceable unit: 2 > Jan 17 05:01:57 gits /kernel: da1: reading primary partition table: error reading fsbn 0 > Jan 17 05:09:40 gits /kernel: (da1:sym0:0:4:0): . CDB: 8 0 0 0 1 0 I'm not sure why you're getting errors, that should work in theory...and it does work for me: # umount /mnt/usr # umount /mnt/var # umount /mnt # camcontrol stop da1 -v Unit stopped successfully # mount /dev/da1s1a /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 158783 73406 72675 50% / /dev/da0s1f 7766844 3016956 4128541 42% /usr /dev/da0s1e 254063 2770 230968 1% /var procfs 4 4 0 100% /proc /dev/da1s1a 158783 62397 83684 43% /mnt For what it's worth, it looks like you've compiled out the sense strings and the CDB strings in your kernel. That makes it more difficult to debug problems. Your drive is spitting out the correct error code, though. (ASC 0x4, ASCQ 0x2 -- logical unit not ready, initializing command required) > # camcontrol stop da1 > Unit started successfully Umm, what's going on there? It should have said unit stopped sucessfully, since you issued a 'camcontrol stop'... > # mount /disk2 > (ok) > do you understand what I mean ? > > PS : don't do that if you have any swap space on an SCSI drive or you're dead. Right, because the swap code probably times out before the disk can spin back up. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 9:57:29 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 2B02F37B404 for ; Wed, 17 Jan 2001 09:57:11 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0HHv0s00905; Wed, 17 Jan 2001 10:57:00 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101171757.f0HHv0s00905@aslan.scsiguy.com> To: Iain Templeton Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Target mode on aic7880 controllers In-Reply-To: Your message of "Wed, 17 Jan 2001 16:38:40 +1100." Date: Wed, 17 Jan 2001 10:57:00 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >However if I try and do a rescan of that bus, the target mode controller >does not respond to an inquiry command. Can you be more specific? Do you see a selection timeout or something else on the other controller? If you boot verbose, the initiator should tell you about selection timeouts. >It appears also that the CAM >system doesn't even get a message from ahc1 that such a command is sent. >In fact, I put a few extra printf's in aic7xxx.c and got nothing out of >them at all (inside the ahc_seqint() function looking for >HOST_MSG_LOOP). You won't necessarily see a HOST_MSG_LOOP. That will only occur during transfer rate negotations. >I cannot use camcontrol to send CCB's to the target device either since >there is no pass through driver allocated for the device. It doesn't make sense to send CCBs to a target device unless you are responding to an ATIO. There is an example in the tree that shows how to do this. >So what I'd like to know is: > >1. Is target mode even known to work on aic7880's or aic7891's? I have not tested the aic7880 recently. The 7890/91 and above did work the last I tried. >2. Is there any particular controller that target mode is known to work >well on. I know there are a few qlogic's that it is said to work on, but >for political reasons I can't buy one of them (or anything else for that >matter) right now. Plus, if we use SCSI for what I'm doing it will >probably be a motherboard controller, and I don't know if there are many >mb's with non-adaptec controllers. > >I have tried the same thing using an aic7891 as both the target and >initiator and that didn't seem to work either. Hmm. What version of FreeBSD are you running? I will try to reproduce this sometime this weekend. >In between the time that I turn target mode on and it gets turned back >off again I have run camcontrol rescan on the other machine, and it >doesn't make any difference. Do you have the processor target device in your kernel? That is what the target mode sample driver emulates. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 10: 7: 8 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by hub.freebsd.org (Postfix) with ESMTP id 4F92137B401 for ; Wed, 17 Jan 2001 10:06:49 -0800 (PST) Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.8.12]) by boco.fee.vutbr.cz (8.11.2/8.11.2) with ESMTP id f0HI6ao61760 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 17 Jan 2001 19:06:37 +0100 (CET) Received: (from cejkar@localhost) by kazi.dcse.fee.vutbr.cz (8.11.0/8.11.0) id f0HI6au29163 for freebsd-scsi@freebsd.org; Wed, 17 Jan 2001 19:06:36 +0100 (CET) Date: Wed, 17 Jan 2001 19:06:36 +0100 From: Cejka Rudolf To: freebsd-scsi@freebsd.org Subject: Troubles with Mammoth2 if there is a tape error Message-ID: <20010117190636.A28937@dcse.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have Exabyte EZ17 library (message in dmesg is bogus) and Mammoth II tape drive. If there is an tape error, I can not kill writing process, because it is in "D" ps-state and tons of error messages are generated in /var/log/messages. Details follow: -- FreeBSD 4.2-STABLE #0: Thu Dec 7 16:08:27 CET 2000 CPU: Pentium III/Pentium III Xeon/Celeron (737.02-MHz 686-class CPU) real memory = 134131712 (130988K bytes) ahc0: port 0xb000-0xb0ff mem 0xf1800000-0xf1800fff irq 5 at device 13.0 on pci2 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs sa0 at ahc0 bus 0 target 1 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) ch0 at ahc0 bus 0 target 0 lun 0 ch0: Removable Changer SCSI-2 device ch0: 3.300MB/s transfers ch0: 7 slots, 1 drive, 1 picker, 0 portals -- At present, I test tapes with following script (Exabyte has still problems with Mammoth2 reliability): -- mt -f /dev/nrsa0 comp off mt -f /dev/nrsa0 rewind dd if=/dev/zero of=/dev/nrsa0 bs=32k -- If I use error-free tape, tests pass: -- # time dd if=/dev/zero of=/dev/nrsa0 bs=32k dd: /dev/nrsa0: No space left on device 1856046+0 records in 1856045+0 records out 60818882560 bytes transferred in 4814.912483 secs (12631358 bytes/sec) real 83m3.857s user 0m2.228s sys 1m44.261s -- Until now, we have had Mammoth II with firmware v02p or lower. If I use bad tape with this firmware, there is still no problem: dd ends with I/O error and in syslog I can find: -- WRITE(06). CDB: a 0 0 80 0 0 MEDIUM ERROR csi:0,0,0,6 asc:9,0 Track following error WRITE FILEMARKS. CDB: 10 0 0 0 2 0 MEDIUM ERROR csi:0,0,0,6 asc:9,0 Track following error failed to write terminating filemark(s) tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state -- But by now, we are trying a new firmware v02r and if I try a bad tape, dd locks in "D" ps-state and tons of messages are generated in /var/log/messages: -- WRITE(06). CDB: a 0 0 80 0 0 Deferred Error: MEDIUM ERROR asc:9,0 Track following error -- I can only reboot server. I tested Mammoth2 with a new firmware v02r and with a bad tape on Novell NetWare and on Solaris too. I have to say that these systems have not any problems. Both stop writing process and write reasonable error message. Do you have any idea, what to do? I'm not SCSI guru and do not understand meaning of "deferred error". Thanks. -- Rudolf Cejka (cejkar@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 10:42:12 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AC22B37B699 for ; Wed, 17 Jan 2001 10:41:50 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA17308; Wed, 17 Jan 2001 10:41:47 -0800 Date: Wed, 17 Jan 2001 10:41:47 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Cejka Rudolf Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error In-Reply-To: <20010117190636.A28937@dcse.fee.vutbr.cz> 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 > If I use error-free tape, tests pass: > > -- > # time dd if=/dev/zero of=/dev/nrsa0 bs=32k > dd: /dev/nrsa0: No space left on device > 1856046+0 records in > 1856045+0 records out > 60818882560 bytes transferred in 4814.912483 secs (12631358 bytes/sec) > > real 83m3.857s > user 0m2.228s > sys 1m44.261s > -- > > Until now, we have had Mammoth II with firmware v02p or lower. > If I use bad tape with this firmware, there is still no problem: > dd ends with I/O error and in syslog I can find: > > -- > WRITE(06). CDB: a 0 0 80 0 0 > MEDIUM ERROR csi:0,0,0,6 asc:9,0 > Track following error > WRITE FILEMARKS. CDB: 10 0 0 0 2 0 > MEDIUM ERROR csi:0,0,0,6 asc:9,0 > Track following error > failed to write terminating filemark(s) > tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state > -- That's correct. If a WFM fails, the driver has no clue where in the tape you are. > > But by now, we are trying a new firmware v02r and if I try a bad > tape, dd locks in "D" ps-state and tons of messages are generated > in /var/log/messages: > > -- > WRITE(06). CDB: a 0 0 80 0 0 > Deferred Error: MEDIUM ERROR asc:9,0 > Track following error Ditto. > I can only reboot server. Somehow I doubt this. Did you try interupting dd? Is dd getting an error propagated back? I would presume it would be, unless you're doing something interesting like selecting a 20 megabyte size, which will be (silently) split at a 64k sizes. Are you using the drive in fixed length mode? Error handling might be broken there. Please advise. > > I tested Mammoth2 with a new firmware v02r and with a bad tape on > Novell NetWare and on Solaris too. I have to say that these > systems have not any problems. Both stop writing process and > write reasonable error message. > I can't speak for Novell, but I wrote the Solaris tape driver, and I would prefer to use the FreeBSD driver myself. > Do you have any idea, what to do? I'm not SCSI guru and do not > understand meaning of "deferred error". It has nothing to do with anything here except that the drive is saying that the error is for an event that ocurred in the past (not for this command but a previous one). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 11:42:35 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by hub.freebsd.org (Postfix) with ESMTP id 1AF1337B6A9 for ; Wed, 17 Jan 2001 11:42:06 -0800 (PST) Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.8.12]) by boco.fee.vutbr.cz (8.11.2/8.11.2) with ESMTP id f0HJg3o81326 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 17 Jan 2001 20:42:04 +0100 (CET) Received: (from cejkar@localhost) by kazi.dcse.fee.vutbr.cz (8.11.0/8.11.0) id f0HJg2633464; Wed, 17 Jan 2001 20:42:02 +0100 (CET) Date: Wed, 17 Jan 2001 20:42:02 +0100 From: Cejka Rudolf To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error Message-ID: <20010117204202.B30484@dcse.fee.vutbr.cz> References: <20010117190636.A28937@dcse.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Wed, Jan 17, 2001 at 10:41:47AM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote (2001/01/17): > Somehow I doubt this. Did you try interupting dd? Is dd getting Yes. Ctrl-C does not work. Here is a cut from one session with Ctrl-Z pressed after there are generated error messages in a terminal window, where I'm logged as a root and with a kill command: $ cat bin/tapewtest : DST=/dev/nrsa0 BS=32k mt -f ${DST} rewind mt -f ${DST} comp off mt -f ${DST} status time dd if=/dev/zero of=${DST} bs=${BS} time mt -f ${DST} rewind mt -f ${DST} comp on mt -f ${DST} status mt -f ${DST} offline $ sh bin/tapewtest Mode Density Blocksize bpi Compression Current: 0x28:X3.224 variable 37871 disabled ---------available modes--------- 0: 0x28:X3.224 variable 37871 0x4 1: 0x28:X3.224 variable 37871 0x4 2: 0x28:X3.224 variable 37871 0x4 3: 0x28:X3.224 variable 37871 0x4 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 ^Z [1]+ Stopped sh bin/tapewtest $ kill -9 %1 [1]+ Killed sh bin/tapewtest $ ps -ax | grep dd 25627 p0 DL 0:11.41 dd if=/dev/zero of=/dev/nrsa0 bs=32k 25646 p0 S+ 0:00.01 grep dd $ kill -9 25627 and next old lines are lost, but I know that messages were still generated. I don't know how long I should wait before reboot, but one of rotated "messages" file has 86 MB, contains 1069569 lines of error messages and this one were generated exactly one hour, what means roughly 100 threeline messages per second :-) But I repeat this test - for assurance and in order to show full session with kill attempts, if you want. > an error propagated back? I would presume it would be, unless you're No, as you can see, dd does report nothing. > doing something interesting like selecting a 20 megabyte size, > which will be (silently) split at a 64k sizes. Do you think "20 megabyte size" as a block size? It is 32k. > Are you using the drive in fixed length mode? If I understand correctly, it is variable mode: mt status says variable (blocksize). > Error handling might be broken there. Please advise. Very gladly. This server is relatively usable for experiments and this form of troubles is very critical for me. Is it valuable to compile kernel with any CAM debugging options? I have one FreeBSD 5.0-CURRENT, Sun Dec 10 ... 2000 and this box has the same problem. > I can't speak for Novell, but I wrote the Solaris tape driver, and Great. > I would prefer to use the FreeBSD driver myself. Me too, but without these forced reboots ;-) > It has nothing to do with anything here except that the drive > is saying that the error is for an event that ocurred in the > past (not for this command but a previous one). So the bug has to be in FreeBSD kernel? I thought that it means that receiver can ignore these errors and the bug is possibly in the new firmware. I still do not understant, why it worked with older firmware... Thanks. -- Rudolf Cejka (cejkar@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 13:53:40 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 091A537B6AE for ; Wed, 17 Jan 2001 13:53:22 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id OAA29645; Wed, 17 Jan 2001 14:54:53 -0700 Date: Wed, 17 Jan 2001 14:54:52 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Cejka Rudolf Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error In-Reply-To: <20010117190636.A28937@dcse.fee.vutbr.cz> 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 Wed, 17 Jan 2001, Cejka Rudolf wrote: > -- > WRITE(06). CDB: a 0 0 80 0 0 > Deferred Error: MEDIUM ERROR asc:9,0 > Track following error > -- > Do you have any idea, what to do? I'm not SCSI guru and do not > understand meaning of "deferred error". Well, first I would say that it is a bug in the firmware that you're testing -- after the first time that the tape drive attempts to write that block on tape, it should be reported as an immediate error, not as a deferred error. "Deferred error" means that the drive has already reported that the operation succeeded, and now has changed its mind. It's not unusual to have a deferred error (it's inherent in buffered tape i/o), but the drive is supposed to know for further writes that it should send an immediate error. I have no idea how FreeBSD handles the drive coming back and saying that sorry, it did not succeed, when it previously had said it did succeed. I assume that by this point in time FreeBSD has already returned a "success" status to dd and thus has no way of letting dd know there's a problem on the initial write. As for why you don't have this problem with Solaris, I assume that on the next attempt to write the tape driver checks the last sense data for that SCSI device, notices the last write failed, and decides to just give up then and there, oh joy... but the Solaris tape driver has its own faults (my office-mate is teaching me some new vocabulary as he deals with porting some software that delves deeply into tape internals, the impression I get is that the Solaris tape driver was okay for 1990... unfortunately, it's no longer 1990). As for Linux, don't even bother, this is the point at which the entire Linux SCSI layer locks up solid as a rock. Aren't tape drives lovely? For some interesting info, you might try running 'tapeinfo' out of the mtx package ( ftp://mtx.sourceforge.net/pub/mtx/mtx-1.2.11pre3.tar.gz ), please note the documentation at http://mtx.sourceforge.net . (Warning, this uses the SCSI generic interface to piddle with tape drives at the SCSI level, and interacts badly with native OS tape drivers... definitely a hacker type of tool). -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 14:54:52 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id 7FA0137B401 for ; Wed, 17 Jan 2001 14:54:33 -0800 (PST) Received: (qmail 26917559 invoked from network); 17 Jan 2001 22:54:23 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 17 Jan 2001 22:54:23 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id f0HMsK166761; Wed, 17 Jan 2001 23:54:21 +0100 (CET) (envelope-from clefevre@citeweb.net) To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI suspend/resume References: <20010112211218.A32720@panzer.kdm.org> <20010117104437.B17373@panzer.kdm.org> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C Reply-To: Cyrille Lefevre In-Reply-To: "Kenneth D. Merry"'s message of "Wed, 17 Jan 2001 10:44:37 -0700" From: Cyrille Lefevre Date: 17 Jan 2001 23:54:17 +0100 Message-ID: Lines: 70 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" writes: > On Wed, Jan 17, 2001 at 05:18:45 +0100, Cyrille Lefevre wrote: > > "Kenneth D. Merry" writes: > [snip] > > Justin says that the apm code makes a BIOS call, and that the BIOS knows > how to spin down an IDE disk. It doesn't know how to spin down a SCSI > disk, though. > > So that's why apm -Z doesn't spin down your SCSI disk. as I remember me (almost 1 year I dont; run M$ things), M$ Windows knows how to do this! isn't it possible to do this at the same time the BIOS syscall is done ? [snip] > > I'm not sure why you're getting errors, that should work in theory...and it > does work for me: > > # umount /mnt/usr > # umount /mnt/var > # umount /mnt > # camcontrol stop da1 -v > Unit stopped successfully > # mount /dev/da1s1a /mnt > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 158783 73406 72675 50% / > /dev/da0s1f 7766844 3016956 4128541 42% /usr > /dev/da0s1e 254063 2770 230968 1% /var > procfs 4 4 0 100% /proc > /dev/da1s1a 158783 62397 83684 43% /mnt don't understand why this works for you and not for me ? I'll ask some friends about that... until now, I was always thinking this was a "normal" comportment. my machine is an old P166 (3 years) w/ a TEKRAM 390F host adapter (2 years). > For what it's worth, it looks like you've compiled out the sense strings > and the CDB strings in your kernel. That makes it more difficult to debug > problems. Your drive is spitting out the correct error code, though. (ASC > 0x4, ASCQ 0x2 -- logical unit not ready, initializing command required) you are right, I've : options SCSI_NO_SENSE_STRINGS options SCSI_NO_OP_STRINGS why this makes more difficult to debug problems ? have you some preferences about kernel settings ? do you want a copy of my kernel config file ? any other things ? > > # camcontrol stop da1 > > Unit started successfully > > Umm, what's going on there? It should have said unit stopped sucessfully, > since you issued a 'camcontrol stop'... typo again, read start, sorry. [snip] Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 15:23:55 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from kwanon.research.canon.com.au (kwanon.research.canon.com.au [203.12.172.254]) by hub.freebsd.org (Postfix) with ESMTP id 57A7337B401 for ; Wed, 17 Jan 2001 15:23:36 -0800 (PST) Received: from bellmann.research.canon.com.au (bellmann.research.canon.com.au [10.5.0.3]) by kwanon.research.canon.com.au (Postfix) with ESMTP id DA0408A89C; Wed, 17 Jan 2001 23:30:01 +0000 (UTC) Received: from elph.research.canon.com.au (elph.research.canon.com.au [203.12.174.253]) by bellmann.research.canon.com.au (Postfix) with ESMTP id 98FFF8B10; Thu, 18 Jan 2001 10:11:58 +1100 (EST) Received: from blow.research.canon.com.au (blow.research.canon.com.au [10.8.1.4]) by elph.research.canon.com.au (Postfix) with ESMTP id 14E66A7; Thu, 18 Jan 2001 10:23:24 +1100 (EST) Date: Thu, 18 Jan 2001 10:23:31 +1100 (EST) From: Iain Templeton To: "Justin T. Gibbs" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Target mode on aic7880 controllers In-Reply-To: <200101171757.f0HHv0s00905@aslan.scsiguy.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 Wed, 17 Jan 2001, Justin T. Gibbs wrote: > > > >However if I try and do a rescan of that bus, the target mode controller > >does not respond to an inquiry command. > > Can you be more specific? Do you see a selection timeout or something > else on the other controller? If you boot verbose, the initiator should > tell you about selection timeouts. > No I don't believe so. [Checks again] No, doesn't appear so, I put a link to the dmesg output below. Should a camcontrol rescan on the bus find the target device and create a pass or pt device for that particular thing? > >I cannot use camcontrol to send CCB's to the target device either since > >there is no pass through driver allocated for the device. > > It doesn't make sense to send CCBs to a target device unless you > are responding to an ATIO. There is an example in the tree that shows > how to do this. > Is that scsi_target.c, if so that is what I'm using. > >So what I'd like to know is: > > > >1. Is target mode even known to work on aic7880's or aic7891's? > > I have not tested the aic7880 recently. The 7890/91 and above did > work the last I tried. > Hmm... > >2. Is there any particular controller that target mode is known to work > >well on. I know there are a few qlogic's that it is said to work on, but > >for political reasons I can't buy one of them (or anything else for that > >matter) right now. Plus, if we use SCSI for what I'm doing it will > >probably be a motherboard controller, and I don't know if there are many > >mb's with non-adaptec controllers. > > > >I have tried the same thing using an aic7891 as both the target and > >initiator and that didn't seem to work either. > > Hmm. What version of FreeBSD are you running? I will try to > reproduce this sometime this weekend. > 4.2-STABLE as of yesterday eastern australia time. The versions of some of the files are: $FreeBSD: src/sys/dev/aic7xxx/aic7xxx.c,v 1.41.2.13 2001/01/09 00:46:53 gibbs Exp $ $FreeBSD: src/sys/dev/aic7xxx/aic7xxx.seq,v 1.94.2.7 2001/01/07 22:50:46 gibbs Exp $ $FreeBSD: src/sys/cam/cam_xpt.c,v 1.80.2.10 2000/10/31 22:09:59 gibbs Exp $ $FreeBSD: src/sys/cam/scsi/scsi_target.c,v 1.22.2.5 2000/07/18 06:44:14 mjacob Exp $ > >In between the time that I turn target mode on and it gets turned back > >off again I have run camcontrol rescan on the other machine, and it > >doesn't make any difference. > > Do you have the processor target device in your kernel? That is what > the target mode sample driver emulates. > I have pt and targ in both kernels (since I've been known to try it the other way around). I wouldn't put it beyond myself that I am missing something obvious. If its of any help at all the dmesg and kernel config files are at: http://starbug.ugh.net.au/~iaint/target/dmesg.RICE http://starbug.ugh.net.au/~iaint/target/dmesg.GIGLI http://starbug.ugh.net.au/~iaint/target/RICE http://starbug.ugh.net.au/~iaint/target/GIGLI Do you have any suggestions of printf()'s that I could put in suitable places? Iain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 21:36:12 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 835EA37B404 for ; Wed, 17 Jan 2001 21:35:53 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA22613; Wed, 17 Jan 2001 22:36:02 -0700 (MST) (envelope-from ken) Date: Wed, 17 Jan 2001 22:36:02 -0700 From: "Kenneth D. Merry" To: Cyrille Lefevre Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI suspend/resume Message-ID: <20010117223602.A22556@panzer.kdm.org> References: <20010112211218.A32720@panzer.kdm.org> <20010117104437.B17373@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from clefevre@citeweb.net on Wed, Jan 17, 2001 at 11:54:17PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 17, 2001 at 23:54:17 +0100, Cyrille Lefevre wrote: > "Kenneth D. Merry" writes: > > > On Wed, Jan 17, 2001 at 05:18:45 +0100, Cyrille Lefevre wrote: > > > "Kenneth D. Merry" writes: > > > [snip] > > > > Justin says that the apm code makes a BIOS call, and that the BIOS knows > > how to spin down an IDE disk. It doesn't know how to spin down a SCSI > > disk, though. > > > > So that's why apm -Z doesn't spin down your SCSI disk. > > as I remember me (almost 1 year I dont; run M$ things), > M$ Windows knows how to do this! > > isn't it possible to do this at the same time the BIOS syscall is done ? It would likely be possible, but it wouldn't be very high on my to-do list. > [snip] > > > > I'm not sure why you're getting errors, that should work in theory...and it > > does work for me: > > > > # umount /mnt/usr > > # umount /mnt/var > > # umount /mnt > > # camcontrol stop da1 -v > > Unit stopped successfully > > # mount /dev/da1s1a /mnt > > # df > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/da0s1a 158783 73406 72675 50% / > > /dev/da0s1f 7766844 3016956 4128541 42% /usr > > /dev/da0s1e 254063 2770 230968 1% /var > > procfs 4 4 0 100% /proc > > /dev/da1s1a 158783 62397 83684 43% /mnt > > don't understand why this works for you and not for me ? > I'll ask some friends about that... until now, I was always thinking > this was a "normal" comportment. Nope, that's not normal. The drive should spin up automatically. I'm not sure why yours doesn't. > my machine is an old P166 (3 years) w/ a TEKRAM 390F host adapter (2 years). > > > For what it's worth, it looks like you've compiled out the sense strings > > and the CDB strings in your kernel. That makes it more difficult to debug > > problems. Your drive is spitting out the correct error code, though. (ASC > > 0x4, ASCQ 0x2 -- logical unit not ready, initializing command required) > > you are right, I've : > > options SCSI_NO_SENSE_STRINGS > options SCSI_NO_OP_STRINGS > > why this makes more difficult to debug problems ? > have you some preferences about kernel settings ? Well, the sense strings provide a text description of the numeric error codes (ASC and ASCQ). That saves me from having to look up the error code in the table if I don't have it memorized. The opcode strings tell me what command failed (i.e. start unit, test unit ready, etc.). > do you want a copy of my kernel config file ? any other things ? Nah, that's okay. The only thing I'm curious about is what sort of drive this is. Can you send dmesg output for your SCSI disk? Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 17 22:29: 8 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from kwanon.research.canon.com.au (kwanon.research.canon.com.au [203.12.172.254]) by hub.freebsd.org (Postfix) with ESMTP id 52ED337B402 for ; Wed, 17 Jan 2001 22:28:49 -0800 (PST) Received: from bellmann.research.canon.com.au (bellmann.research.canon.com.au [10.5.0.3]) by kwanon.research.canon.com.au (Postfix) with ESMTP id E65838A8BE for ; Thu, 18 Jan 2001 06:35:18 +0000 (UTC) Received: from elph.research.canon.com.au (elph.research.canon.com.au [203.12.174.253]) by bellmann.research.canon.com.au (Postfix) with ESMTP id 084AA8B10 for ; Thu, 18 Jan 2001 17:17:13 +1100 (EST) Received: from blow.research.canon.com.au (blow.research.canon.com.au [10.8.1.4]) by elph.research.canon.com.au (Postfix) with ESMTP id 081A0400 for ; Thu, 18 Jan 2001 17:28:40 +1100 (EST) Date: Thu, 18 Jan 2001 17:28:47 +1100 (EST) From: Iain Templeton To: freebsd-scsi@freebsd.org Subject: More target mode observations 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 Following up to myself with a bit more info, I played around a little bit more, and discovered that yes, we do have some atio's waiting, and if we get a bus reset one of these gets sent back. I also discovered that ahc_intr() never gets called during the rescan of the bus whilst in target mode. To me at least this would suggest that the controller is never being selected, or failing that the controller is never telling the device driver that it has been selected. Unfortunately we do not have any hardware here for examining SCSI busses, otherwise I could find out whether the controller was responding to the select with BSY (well, we have the logic analyser, but nothing to plug it in with). The other thing is that I only get bus reset intermittantly, which worries me. By this I mean that I can do a camcontrol reset on one machine, and the other machine doesn't always pick it up (I don't get the "Somebody reset bus %d" message). I doubt this helps particularly much though. -- Iain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 10: 9:40 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by hub.freebsd.org (Postfix) with ESMTP id A040F37B400 for ; Thu, 18 Jan 2001 10:09:21 -0800 (PST) Received: from smtp.flashnet.it (ip019.pool-173.cyb.it [195.191.181.20]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f0II92102460 for ; Thu, 18 Jan 2001 19:09:06 +0100 Message-Id: <200101181809.f0II92102460@relay2.flashnet.it> To: freebsd-scsi@freebsd.org X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Thu, 18 Jan 2001 19:09:04 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: sym0 errors Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. What do you make of this error: sym0:1 ERROR (0:18) (1-21-0) (1f/9f) (scripta 5f8:11000000). sym0: script cmd = 11000000 sym0: regdump: da 10 c0 9f 47 1f 01 03 76 01 81 21 80 01 01 09 00 ce 1e 01 08 ff ff ff. (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. then, some sym0: unexpected disconnect This happens on a FreeBSD 4.2R system with a Tekram DC390U2W with an UltraPlex 40x on the narrow bus and two Atlas 10K2 on the LVD bus. Termination is correct. Bye & Thanks av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 10:52:16 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by hub.freebsd.org (Postfix) with ESMTP id 8A01637B404 for ; Thu, 18 Jan 2001 10:51:58 -0800 (PST) Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.8.12]) by boco.fee.vutbr.cz (8.11.2/8.11.2) with ESMTP id f0IIpto87073 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 18 Jan 2001 19:51:56 +0100 (CET) Received: (from cejkar@localhost) by kazi.dcse.fee.vutbr.cz (8.11.0/8.11.0) id f0IIptt34453; Thu, 18 Jan 2001 19:51:55 +0100 (CET) Date: Thu, 18 Jan 2001 19:51:54 +0100 From: Cejka Rudolf To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error Message-ID: <20010118195154.A33758@dcse.fee.vutbr.cz> References: <20010117190636.A28937@dcse.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eric@estinc.com on Wed, Jan 17, 2001 at 02:54:52PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Eric Lee Green wrote (2001/01/17): > Well, first I would say that it is a bug in the firmware that you're > testing -- after the first time that the tape drive attempts to write that > block on tape, it should be reported as an immediate error, not as a > deferred error. Hmm, so what to do now? Does anybody have close relationship with Exabyte? At this time I'm sure that I can not kill dd process and in /var/log/messages there are no immediate errors - just deferred errors. But I still do not know, what commands flow over SCSI bus (is CAMDEBUG sufficient?). > have a deferred error (it's inherent in buffered tape i/o), but the drive > is supposed to know for further writes that it should send an immediate > error. If I can not kill -9 dd, are any further writes without dd possible? -- Rudolf Cejka (cejkar@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 12: 1:13 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 52D1637B404 for ; Thu, 18 Jan 2001 12:00:56 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA00709; Thu, 18 Jan 2001 11:48:20 -0800 Date: Thu, 18 Jan 2001 12:00:38 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Cejka Rudolf Cc: Eric Lee Green , freebsd-scsi@FreeBSD.org Subject: Re: Troubles with Mammoth2 if there is a tape error In-Reply-To: <20010118195154.A33758@dcse.fee.vutbr.cz> 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, 18 Jan 2001, Cejka Rudolf wrote: > > Eric Lee Green wrote (2001/01/17): > > Well, first I would say that it is a bug in the firmware that you're > > testing -- after the first time that the tape drive attempts to write that > > block on tape, it should be reported as an immediate error, not as a > > deferred error. > > Hmm, so what to do now? > > Does anybody have close relationship with Exabyte? > > At this time I'm sure that I can not kill dd process and in > /var/log/messages there are no immediate errors - just deferred errors. > But I still do not know, what commands flow over SCSI bus (is CAMDEBUG > sufficient?). Yes- in this case. > > > have a deferred error (it's inherent in buffered tape i/o), but the drive > > is supposed to know for further writes that it should send an immediate > > error. > > If I can not kill -9 dd, are any further writes without dd possible? Well, I can annoy the frick out of even more people and declare that Deferred Media errors *also* make the tape state frozen (thus nuking dd and causeing you to do an EOM, REWIND or OFFLINE to get state back to a known place (actually, setting specific block position should do it too- need to remember to do this...).... Was wollen sie? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 12: 9: 5 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (unknown [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id D9A4E37B404 for ; Thu, 18 Jan 2001 12:08:47 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f0IKNNQ00888; Thu, 18 Jan 2001 12:23:23 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101182023.f0IKNNQ00888@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.org Subject: Re: Troubles with Mammoth2 if there is a tape error In-reply-to: Your message of "Thu, 18 Jan 2001 12:00:38 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jan 2001 12:23:23 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Well, I can annoy the frick out of even more people and declare that Deferred > Media errors *also* make the tape state frozen (thus nuking dd and causeing > you to do an EOM, REWIND or OFFLINE to get state back to a known place > (actually, setting specific block position should do it too- need to remember > to do this...).... Well, I'm inclined to think this is the right thing to do. A 'deferred media error' basically just tells you that the tape you've just written is now junk (because it's corrupt), and the only correct actions I can think of are: - eject and discard - rewind, erase and retry since the drive will, in theory, already have exhausted its error-compensation capability so offering anything that just tries to allow re-writing the block isn't going to help... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 12:11:18 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E439437B404; Thu, 18 Jan 2001 12:11:00 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA00838; Thu, 18 Jan 2001 11:58:41 -0800 Date: Thu, 18 Jan 2001 12:10:59 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: freebsd-scsi@FreeBSD.org Subject: Re: Troubles with Mammoth2 if there is a tape error In-Reply-To: <200101182023.f0IKNNQ00888@mass.osd.bsdi.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 Yes, but also given how many people turn purple in the face and scream at you me on this very topic, I suspect y'all will understand if I'm a bit reluctant to do so..... -matt > > Well, I can annoy the frick out of even more people and declare that Deferred > > Media errors *also* make the tape state frozen (thus nuking dd and causeing > > you to do an EOM, REWIND or OFFLINE to get state back to a known place > > (actually, setting specific block position should do it too- need to remember > > to do this...).... > > Well, I'm inclined to think this is the right thing to do. > > A 'deferred media error' basically just tells you that the tape you've > just written is now junk (because it's corrupt), and the only correct > actions I can think of are: > > - eject and discard > - rewind, erase and retry > > since the drive will, in theory, already have exhausted its > error-compensation capability so offering anything that just tries to > allow re-writing the block isn't going to help... > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 12:43:40 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by hub.freebsd.org (Postfix) with ESMTP id AEBB237B404 for ; Thu, 18 Jan 2001 12:43:21 -0800 (PST) Received: from nas1-107.cgy.club-internet.fr (nas1-107.cgy.club-internet.fr [195.36.197.107]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA07787; Thu, 18 Jan 2001 21:43:18 +0100 (MET) Date: Thu, 18 Jan 2001 20:42:40 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Andrea Venturoli Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sym0 errors In-Reply-To: <200101181809.f0II92102460@relay2.flashnet.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 18 Jan 2001, Andrea Venturoli wrote: > Hello.=20 > =20 > What do you make of this error:=20 > =20 > sym0:1 ERROR (0:18) (1-21-0) (1f/9f) (scripta 5f8:11000000).=20 ^ This bit means SCSI GROSS ERROR. It is generally a SCSI ACK/REQ protocol problem detected by the controller SCSI core. A SCSI BUS that hasn't margin enough for the transfer speed used is=20 likely the cause. > sym0: script cmd =3D 11000000=20 > sym0: regdump: da 10 c0 9f 47 1f 01 03 76 01 81 21 80 01 01 09 00 ce 1e 0= 1 08 ff ff ff.=20 > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected.=20 > =20 > then, some=20 > =20 > sym0: unexpected disconnect=20 This one means that the device (target) disconnected the SCSI BUS when this wasn't expected by the initiator. This is the way target signals problems that cannot be reported using the normal SCSI protocol. A SCSI BUS problem that affects handshake (ACK/REQ) can be reported so by the target, for example. =20 > This happens on a FreeBSD 4.2R system with a Tekram DC390U2W with an Ultr= aPlex 40x on the =20 > narrow bus and two Atlas 10K2 on the LVD bus.=20 > Termination is correct.=20 A SCSI BUS including all devices, cables, connectors, etc.., is something complex. The breakage can simply not be visible. I suggest you to decrease the synchronous speed of your devices to half the values currently used. If the problem disappears or gets an order of magnitude less frequent, then a SCSI BUS problem is very likely the cause. (man camcontrol, or set device settings in NVRAM accordingly) Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 18 14: 4:55 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 2FC0A37B400; Thu, 18 Jan 2001 14:04:38 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id PAA10238; Thu, 18 Jan 2001 15:06:20 -0700 Date: Thu, 18 Jan 2001 15:06:20 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Mike Smith Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error In-Reply-To: <200101182023.f0IKNNQ00888@mass.osd.bsdi.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, 18 Jan 2001, Mike Smith wrote: > > Well, I can annoy the frick out of even more people and declare that Deferred > > Media errors *also* make the tape state frozen (thus nuking dd and causeing > > you to do an EOM, REWIND or OFFLINE to get state back to a known place > > (actually, setting specific block position should do it too- need to remember > > to do this...).... Allowing setting specific block position to clear state would be useful for some backup programs, I think, ones that try to verify the current tape before moving to the next one. BRU Pro does not do that (it does the write, no matter how many tapes it takes, then does the verify starting back with the first tape, in an attempt to reduce the backup window), but I can see how people with standalone tape drives in particular would prefer a backup program that did the verify on a tape-by-tape basis. This would also allow the backup program to detirmine how many blocks of data actually did get written, so that it knows how many blocks (out of its buffer) need to be prepended to the next tape prior to starting to write new blocks of data. > A 'deferred media error' basically just tells you that the tape you've > just written is now junk (because it's corrupt), and the only correct > actions I can think of are: > > - eject and discard > - rewind, erase and retry The nastiness behind 'deferred media error' is that it means that data was reported written to the tape when it actually did not make it to the tape. This is Evil(tm). This means that the backup program lost data without knowing it. With BRU or afio that means you'd lose a block or two of data, maybe one or two files. With compressed or gzipped 'tar', that means the rest of the archive is unreadable. Now you know why I prefer afio or BRU to 'tar' for tape backups (if I didn't work for the BRU guys, I'd use afio). In any event, the important thing is that it gets reported as an error to the tape backup program as soon as possible. The tape backup program will then rewind the tape, eject it, and ask for the next tape (well, it'll rewind the tape and eject it if it's a tape program that's more sophisticated than 'tar' :-). . Whether the tape backup program starts rewriting from scratch or decides to continue where it left off (perhaps prepending the new data with some buffered data that was written at the end of the previous tape) is an issue for the applications writer. So yes, I think that a deferred media error making the tape state frozen would probably be preferred by tape backup software authors. Of course, if it happens to break *MY* software I'll be yelling as much as the rest of the crowd (grin). -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 19 9:43: 4 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from siafu.iconnect.co.ke (upagraha.iconnect.co.ke [209.198.248.2]) by hub.freebsd.org (Postfix) with ESMTP id D88BD37B402 for ; Fri, 19 Jan 2001 09:42:42 -0800 (PST) Received: from [64.110.74.50] (helo=poeza.iconnect.co.ke) by siafu.iconnect.co.ke with esmtp (Exim 2.12 #1) id 14JfXM-000Jin-00 for freebsd-scsi@freebsd.org; Fri, 19 Jan 2001 20:41:21 +0300 Received: from wash by poeza.iconnect.co.ke with local (Exim 3.20 #1) id 14JfZ4-0003eW-00 for freebsd-scsi@freebsd.org; Fri, 19 Jan 2001 20:43:06 +0300 Date: Fri, 19 Jan 2001 20:43:06 +0300 From: Corvette To: freebsd-scsi@freebsd.org Subject: CANNOT ACCESS T20 TAPE Message-ID: <20010119204306.A14007@poeza.iconnect.co.ke> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD poeza.iconnect.co.ke 4.2-STABLE FreeBSD 4.2-STABLE X-Mailer: Mutt http://www.mutt.org/ X-Location: Mombasa, KE, East Africa Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I recently cvsupped and updated my 3.5-STABLE box to 4.2_STABLE. I had quite a few problems initially when doing buildworld but a good samaritan came to my rescue and sent me precise details that had worked for one of 'us'. At the moment I seem to be in a bad fix because I cannot access my tape drive, an HP T20. What I mean is that mt returns an error /dev/nsa0: device not configured. I posted this to the -quetsions and I got overwhelming response but all the suggestions I received did not yield the solution I was looking for. So please pardon me if this is considered a double post. I am only anxious for a solution. Without a backup, we all know where I stand - on the firing line. I am running an HP Netserver E20 and here is a section of my dmesg.boot: ## [snip] ahc0: port 0x1000-0x10ff mem 0xfc100000-0xfc100fff irq 10 at device 5.0 on pci0 ahc0: Using left over BIOS settings aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x1400-0x14ff mem 0xfc101000-0xfc101fff irq 10 at device 5.1 on pci0 ahc1: Host Adapter Bios disabled. Using default SCSI device parameters aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs . . . Waiting 15 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) [snip] and here is some output from /dev wash:~$ cd /dev/ wash:/dev$ ls -al *sa0 crw-rw---- 4 root operator 14, 2 Jan 18 12:18 ersa0 crw-rw---- 4 root operator 14, 2 Jan 18 12:18 esa0 crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nrsa0 crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nsa0 crw-rw---- 4 root operator 14, 0 Jan 18 12:18 rsa0 crw-rw---- 4 root operator 14, 0 Jan 18 12:18 sa0 ...and a little bit more... wash:/dev$ mt status mt: /dev/nsa0: Device not configured And I followed the procedure below to go to 4.2_STABLE... All help welcome. Thanks. NB: I am not subscribed to this list, so kindly cc me in your reply. -Wash -- Odhiambo Washington Inter-Connect Ltd., wash@iconnect.co.ke 5th Flr Furaha Plaza Tel: 254 11 222604 Nkrumah Rd., Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Sex is what women have and men want. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 19 9:56:44 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A3C4937B401 for ; Fri, 19 Jan 2001 09:56:24 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA04993; Fri, 19 Jan 2001 09:43:56 -0800 Date: Fri, 19 Jan 2001 09:56:14 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Corvette Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <20010119204306.A14007@poeza.iconnect.co.ke> 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 Is a tape inserted? If not, then there is no bug here. Insert a tape prior to attempting to get status (unless you use the 'control' entry point, but that will yield pointless information). If so, build a kernel with CAMDEBUG enabled, boot that, and then do camcontrol debug -Ic 0:4:0 and then do the 'mt status' and ship the output back to the list. > Hi, > I recently cvsupped and updated my 3.5-STABLE box to 4.2_STABLE. > I had quite a few problems initially when doing buildworld but a > good samaritan came to my rescue and sent me precise details that > had worked for one of 'us'. > > At the moment I seem to be in a bad fix because I cannot access my > tape drive, an HP T20. What I mean is that mt returns an error > > /dev/nsa0: device not configured. > > I posted this to the -quetsions and I got overwhelming response but all > the suggestions I received did not yield the solution I was looking for. > So please pardon me if this is considered a double post. I am only anxious for > a solution. Without a backup, we all know where I stand - on the firing line. > > > I am running an HP Netserver E20 and here is a section of my dmesg.boot: > ## > [snip] > ahc0: port 0x1000-0x10ff mem 0xfc100000-0xfc100fff irq 10 at device 5.0 on pci0 > ahc0: Using left over BIOS settings > aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs > ahc1: port 0x1400-0x14ff mem 0xfc101000-0xfc101fff irq 10 at device 5.1 on pci0 > ahc1: Host Adapter Bios disabled. Using default SCSI device parameters > aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs > . > . > . > Waiting 15 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 4 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 3.300MB/s transfers > da1 at ahc0 bus 0 target 2 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled > da1: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) > Mounting root from ufs:/dev/da0s1a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled > da0: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) > [snip] > > > and here is some output from /dev > wash:~$ cd /dev/ > wash:/dev$ ls -al *sa0 > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 ersa0 > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 esa0 > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nrsa0 > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nsa0 > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 rsa0 > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 sa0 > > ...and a little bit more... > > wash:/dev$ mt status > mt: /dev/nsa0: Device not configured > > > And I followed the procedure below to go to 4.2_STABLE... > > All help welcome. > > Thanks. > > NB: I am not subscribed to this list, so kindly cc me in your reply. > > -Wash > > -- > Odhiambo Washington Inter-Connect Ltd., > wash@iconnect.co.ke 5th Flr Furaha Plaza > Tel: 254 11 222604 Nkrumah Rd., > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. > > Sex is what women have and men want. > > > 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 Jan 19 10: 8:53 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from siafu.iconnect.co.ke (upagraha.iconnect.co.ke [209.198.248.2]) by hub.freebsd.org (Postfix) with ESMTP id 260BF37B400 for ; Fri, 19 Jan 2001 10:08:19 -0800 (PST) Received: from [64.110.74.50] (helo=poeza.iconnect.co.ke) by siafu.iconnect.co.ke with esmtp (Exim 2.12 #1) id 14Jfvs-000Kr5-00; Fri, 19 Jan 2001 21:06:42 +0300 Received: from wash by poeza.iconnect.co.ke with local (Exim 3.20 #1) id 14JfxS-0004rW-00; Fri, 19 Jan 2001 21:08:18 +0300 Date: Fri, 19 Jan 2001 21:08:18 +0300 From: Odhiambo Washington To: Matthew Jacob Cc: freebsd-scsi@freebsd.org Subject: Re: CANNOT ACCESS T20 TAPE Message-ID: <20010119210817.B14078@poeza.iconnect.co.ke> References: <20010119204306.A14007@poeza.iconnect.co.ke> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from "Matthew Jacob" on Fri, Jan 19, 2001 at 09:56:14AM -0800 X-Operating-System: FreeBSD poeza.iconnect.co.ke 4.2-STABLE FreeBSD 4.2-STABLE X-Location: Mombasa, KE, East Africa Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Jacob [20010119 20:56]: writing on the subject 'Re: CANNOT ACCESS T20 TAPE' Matthew> Matthew> Matthew> Is a tape inserted? If not, then there is no bug here. Insert a tape prior to Matthew> attempting to get status (unless you use the 'control' entry point, but that Matthew> will yield pointless information). Matthew> Matthew> If so, build a kernel with CAMDEBUG enabled, boot that, and then do Matthew> Matthew> camcontrol debug -Ic 0:4:0 Matthew> Matthew> and then do the 'mt status' and ship the output back to the list. Hi Matthew, It happened when I had a tape in the drive. I even changed tapes but still same issue I am now building a kernel with options CAMDEBUG. I am going to send the feedback first thing tomorrow. Thank you so much Matthew> > Hi, Matthew> > I recently cvsupped and updated my 3.5-STABLE box to 4.2_STABLE. Matthew> > I had quite a few problems initially when doing buildworld but a Matthew> > good samaritan came to my rescue and sent me precise details that Matthew> > had worked for one of 'us'. Matthew> > Matthew> > At the moment I seem to be in a bad fix because I cannot access my Matthew> > tape drive, an HP T20. What I mean is that mt returns an error Matthew> > Matthew> > /dev/nsa0: device not configured. Matthew> > Matthew> > I posted this to the -quetsions and I got overwhelming response but all Matthew> > the suggestions I received did not yield the solution I was looking for. Matthew> > So please pardon me if this is considered a double post. I am only anxious for Matthew> > a solution. Without a backup, we all know where I stand - on the firing line. Matthew> > Matthew> > Matthew> > I am running an HP Netserver E20 and here is a section of my dmesg.boot: Matthew> > ## Matthew> > [snip] Matthew> > ahc0: port 0x1000-0x10ff mem 0xfc100000-0xfc100fff irq 10 at device 5.0 on pci0 Matthew> > ahc0: Using left over BIOS settings Matthew> > aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs Matthew> > ahc1: port 0x1400-0x14ff mem 0xfc101000-0xfc101fff irq 10 at device 5.1 on pci0 Matthew> > ahc1: Host Adapter Bios disabled. Using default SCSI device parameters Matthew> > aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs Matthew> > . Matthew> > . Matthew> > . Matthew> > Waiting 15 seconds for SCSI devices to settle Matthew> > sa0 at ahc0 bus 0 target 4 lun 0 Matthew> > sa0: Removable Sequential Access SCSI-2 device Matthew> > sa0: 3.300MB/s transfers Matthew> > da1 at ahc0 bus 0 target 2 lun 0 Matthew> > da1: Fixed Direct Access SCSI-2 device Matthew> > da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled Matthew> > da1: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Matthew> > Mounting root from ufs:/dev/da0s1a Matthew> > da0 at ahc0 bus 0 target 0 lun 0 Matthew> > da0: Fixed Direct Access SCSI-2 device Matthew> > da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled Matthew> > da0: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Matthew> > [snip] Matthew> > Matthew> > Matthew> > and here is some output from /dev Matthew> > wash:~$ cd /dev/ Matthew> > wash:/dev$ ls -al *sa0 Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 ersa0 Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 esa0 Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nrsa0 Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nsa0 Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 rsa0 Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 sa0 Matthew> > Matthew> > ...and a little bit more... Matthew> > Matthew> > wash:/dev$ mt status Matthew> > mt: /dev/nsa0: Device not configured Matthew> > Matthew> > Matthew> > And I followed the procedure below to go to 4.2_STABLE... Matthew> > Matthew> > All help welcome. Matthew> > Matthew> > Thanks. Matthew> > Matthew> > NB: I am not subscribed to this list, so kindly cc me in your reply. Matthew> > Matthew> > -Wash Matthew> > Matthew> > -- Matthew> > Odhiambo Washington Inter-Connect Ltd., Matthew> > wash@iconnect.co.ke 5th Flr Furaha Plaza Matthew> > Tel: 254 11 222604 Nkrumah Rd., Matthew> > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Matthew> > Matthew> > Sex is what women have and men want. Matthew> > Matthew> > Matthew> > To Unsubscribe: send mail to majordomo@FreeBSD.org Matthew> > with "unsubscribe freebsd-scsi" in the body of the message Matthew> > Matthew> -Wash -- Odhiambo Washington Inter-Connect Ltd., wash@iconnect.co.ke 5th Flr Furaha Plaza Tel: 254 11 222604 Nkrumah Rd., Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Men fear thought as they fear nothing else on earth, more than ruin, more even than death... Thought is subversive and revolutionary, destructive and terrible, thought is merciless to privilege, established institutions, and comfortable habit. Thought looks into the pit of hell and is not afraid. Thought is great and swift and free, the light of the world, and the chief glory of man. -Bertrand Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 19 10:12:32 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 33CBA37B699 for ; Fri, 19 Jan 2001 10:12:15 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA05073; Fri, 19 Jan 2001 09:59:50 -0800 Date: Fri, 19 Jan 2001 10:12:08 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Odhiambo Washington Cc: freebsd-scsi@freebsd.org Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <20010119210817.B14078@poeza.iconnect.co.ke> 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 might be failing the 'autosense' for density step. You might be able to construct a quirk table entry with SA_QUIRK_NODREAD that helps in this case. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 19 23: 9:52 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from siafu.iconnect.co.ke (upagraha.iconnect.co.ke [209.198.248.2]) by hub.freebsd.org (Postfix) with ESMTP id C93F637B400 for ; Fri, 19 Jan 2001 23:09:28 -0800 (PST) Received: from [64.110.74.50] (helo=poeza.iconnect.co.ke) by siafu.iconnect.co.ke with esmtp (Exim 2.12 #1) id 14Js80-000LcG-00; Sat, 20 Jan 2001 10:08:03 +0300 Received: from wash by poeza.iconnect.co.ke with local (Exim 3.20 #1) id 14Js9i-00007K-00; Sat, 20 Jan 2001 10:09:46 +0300 Date: Sat, 20 Jan 2001 10:09:46 +0300 From: Corvette To: freebsd-scsi@freebsd.org Cc: mjacob@feral.com Subject: Re: CANNOT ACCESS T20 TAPE Message-ID: <20010120100945.A365@poeza.iconnect.co.ke> References: <20010119204306.A14007@poeza.iconnect.co.ke> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from "Matthew Jacob" on Fri, Jan 19, 2001 at 09:56:14AM -0800 X-Operating-System: FreeBSD poeza.iconnect.co.ke 4.2-STABLE FreeBSD 4.2-STABLE X-Location: Mombasa, KE, East Africa Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Jacob [20010119 20:56]: writing on the subject 'Re: CANNOT ACCESS T20 TAPE' Matthew> Matthew> Matthew> Is a tape inserted? If not, then there is no bug here. Insert a tape prior to Matthew> attempting to get status (unless you use the 'control' entry point, but that Matthew> will yield pointless information). Matthew> Matthew> If so, build a kernel with CAMDEBUG enabled, boot that, and then do Matthew> Matthew> camcontrol debug -Ic 0:4:0 Matthew> Matthew> and then do the 'mt status' and ship the output back to the list. Hi, As a followup to the problem that I'm having with my tape drive, I've built and booted up a kernel with "options CAMDEBUG" and below is my output. ## wash:/usr/home/wash# camcontrol debug -Ic 0:4:0 Debugging enabled for 0:4:0 wash:/usr/home/wash# mt status mt: /dev/nsa0: Device not configured wash:/usr/home/wash# ## I'm still not subscribed to this list. Kindly include me in any replies via a cc. Thank you. Matthew> Matthew> Matthew> Matthew> > Hi, Matthew> > I recently cvsupped and updated my 3.5-STABLE box to 4.2_STABLE. Matthew> > I had quite a few problems initially when doing buildworld but a Matthew> > good samaritan came to my rescue and sent me precise details that Matthew> > had worked for one of 'us'. Matthew> > Matthew> > At the moment I seem to be in a bad fix because I cannot access my Matthew> > tape drive, an HP T20. What I mean is that mt returns an error Matthew> > Matthew> > /dev/nsa0: device not configured. Matthew> > Matthew> > I posted this to the -quetsions and I got overwhelming response but all Matthew> > the suggestions I received did not yield the solution I was looking for. Matthew> > So please pardon me if this is considered a double post. I am only anxious for Matthew> > a solution. Without a backup, we all know where I stand - on the firing line. Matthew> > Matthew> > Matthew> > I am running an HP Netserver E20 and here is a section of my dmesg.boot: Matthew> > ## Matthew> > [snip] Matthew> > ahc0: port 0x1000-0x10ff mem 0xfc100000-0xfc100fff irq 10 at device 5.0 on pci0 Matthew> > ahc0: Using left over BIOS settings Matthew> > aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs Matthew> > ahc1: port 0x1400-0x14ff mem 0xfc101000-0xfc101fff irq 10 at device 5.1 on pci0 Matthew> > ahc1: Host Adapter Bios disabled. Using default SCSI device parameters Matthew> > aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs Matthew> > . Matthew> > . Matthew> > . Matthew> > Waiting 15 seconds for SCSI devices to settle Matthew> > sa0 at ahc0 bus 0 target 4 lun 0 Matthew> > sa0: Removable Sequential Access SCSI-2 device Matthew> > sa0: 3.300MB/s transfers Matthew> > da1 at ahc0 bus 0 target 2 lun 0 Matthew> > da1: Fixed Direct Access SCSI-2 device Matthew> > da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled Matthew> > da1: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Matthew> > Mounting root from ufs:/dev/da0s1a Matthew> > da0 at ahc0 bus 0 target 0 lun 0 Matthew> > da0: Fixed Direct Access SCSI-2 device Matthew> > da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled Matthew> > da0: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Matthew> > [snip] Matthew> > Matthew> > Matthew> > and here is some output from /dev Matthew> > wash:~$ cd /dev/ Matthew> > wash:/dev$ ls -al *sa0 Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 ersa0 Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 esa0 Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nrsa0 Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nsa0 Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 rsa0 Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 sa0 Matthew> > Matthew> > ...and a little bit more... Matthew> > Matthew> > wash:/dev$ mt status Matthew> > mt: /dev/nsa0: Device not configured Matthew> > Matthew> > Matthew> > And I followed the procedure below to go to 4.2_STABLE... Matthew> > Matthew> > All help welcome. Matthew> > Matthew> > Thanks. Matthew> > Matthew> > NB: I am not subscribed to this list, so kindly cc me in your reply. Matthew> > Matthew> > -Wash Matthew> > Matthew> > -- Matthew> > Odhiambo Washington Inter-Connect Ltd., Matthew> > wash@iconnect.co.ke 5th Flr Furaha Plaza Matthew> > Tel: 254 11 222604 Nkrumah Rd., Matthew> > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Matthew> > Matthew> > Sex is what women have and men want. Matthew> > Matthew> > Matthew> > To Unsubscribe: send mail to majordomo@FreeBSD.org Matthew> > with "unsubscribe freebsd-scsi" in the body of the message Matthew> > Matthew> -Wash -- Odhiambo Washington Inter-Connect Ltd., wash@iconnect.co.ke 5th Flr Furaha Plaza Tel: 254 11 222604 Nkrumah Rd., Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Many years ago in a period commonly know as Next Friday Afternoon, there lived a King who was very Gloomy on Tuesday mornings because he was so Sad thinking about how Unhappy he had been on Monday and how completely Mournful he would be on Wednesday.... -Walt Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 20 0: 0:14 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1895A37B400 for ; Fri, 19 Jan 2001 23:59:45 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA07473; Fri, 19 Jan 2001 23:45:53 -0800 Date: Fri, 19 Jan 2001 23:58:11 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Corvette Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <20010120100945.A365@poeza.iconnect.co.ke> 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 You're missing where the output is coming out. Ship your /var/log/messages file. On Sat, 20 Jan 2001, Corvette wrote: > * Matthew Jacob [20010119 20:56]: writing on the subject 'Re: CANNOT ACCESS T20 TAPE' > Matthew> > Matthew> > Matthew> Is a tape inserted? If not, then there is no bug here. Insert a tape prior to > Matthew> attempting to get status (unless you use the 'control' entry point, but that > Matthew> will yield pointless information). > Matthew> > Matthew> If so, build a kernel with CAMDEBUG enabled, boot that, and then do > Matthew> > Matthew> camcontrol debug -Ic 0:4:0 > Matthew> > Matthew> and then do the 'mt status' and ship the output back to the list. > > Hi, > As a followup to the problem that I'm having with my tape drive, I've built and > booted up a kernel with "options CAMDEBUG" and below is my output. > > ## > wash:/usr/home/wash# camcontrol debug -Ic 0:4:0 > Debugging enabled for 0:4:0 > wash:/usr/home/wash# mt status > mt: /dev/nsa0: Device not configured > wash:/usr/home/wash# > ## > > I'm still not subscribed to this list. Kindly include me in any replies via a cc. > > Thank you. > > > > Matthew> > Matthew> > Matthew> > Matthew> > Hi, > Matthew> > I recently cvsupped and updated my 3.5-STABLE box to 4.2_STABLE. > Matthew> > I had quite a few problems initially when doing buildworld but a > Matthew> > good samaritan came to my rescue and sent me precise details that > Matthew> > had worked for one of 'us'. > Matthew> > > Matthew> > At the moment I seem to be in a bad fix because I cannot access my > Matthew> > tape drive, an HP T20. What I mean is that mt returns an error > Matthew> > > Matthew> > /dev/nsa0: device not configured. > Matthew> > > Matthew> > I posted this to the -quetsions and I got overwhelming response but all > Matthew> > the suggestions I received did not yield the solution I was looking for. > Matthew> > So please pardon me if this is considered a double post. I am only anxious for > Matthew> > a solution. Without a backup, we all know where I stand - on the firing line. > Matthew> > > Matthew> > > Matthew> > I am running an HP Netserver E20 and here is a section of my dmesg.boot: > Matthew> > ## > Matthew> > [snip] > Matthew> > ahc0: port 0x1000-0x10ff mem 0xfc100000-0xfc100fff irq 10 at device 5.0 on pci0 > Matthew> > ahc0: Using left over BIOS settings > Matthew> > aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs > Matthew> > ahc1: port 0x1400-0x14ff mem 0xfc101000-0xfc101fff irq 10 at device 5.1 on pci0 > Matthew> > ahc1: Host Adapter Bios disabled. Using default SCSI device parameters > Matthew> > aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs > Matthew> > . > Matthew> > . > Matthew> > . > Matthew> > Waiting 15 seconds for SCSI devices to settle > Matthew> > sa0 at ahc0 bus 0 target 4 lun 0 > Matthew> > sa0: Removable Sequential Access SCSI-2 device > Matthew> > sa0: 3.300MB/s transfers > Matthew> > da1 at ahc0 bus 0 target 2 lun 0 > Matthew> > da1: Fixed Direct Access SCSI-2 device > Matthew> > da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled > Matthew> > da1: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) > Matthew> > Mounting root from ufs:/dev/da0s1a > Matthew> > da0 at ahc0 bus 0 target 0 lun 0 > Matthew> > da0: Fixed Direct Access SCSI-2 device > Matthew> > da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled > Matthew> > da0: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) > Matthew> > [snip] > Matthew> > > Matthew> > > Matthew> > and here is some output from /dev > Matthew> > wash:~$ cd /dev/ > Matthew> > wash:/dev$ ls -al *sa0 > Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 ersa0 > Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 esa0 > Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nrsa0 > Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nsa0 > Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 rsa0 > Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 sa0 > Matthew> > > Matthew> > ...and a little bit more... > Matthew> > > Matthew> > wash:/dev$ mt status > Matthew> > mt: /dev/nsa0: Device not configured > Matthew> > > Matthew> > > Matthew> > And I followed the procedure below to go to 4.2_STABLE... > Matthew> > > Matthew> > All help welcome. > Matthew> > > Matthew> > Thanks. > Matthew> > > Matthew> > NB: I am not subscribed to this list, so kindly cc me in your reply. > Matthew> > > Matthew> > -Wash > Matthew> > > Matthew> > -- > Matthew> > Odhiambo Washington Inter-Connect Ltd., > Matthew> > wash@iconnect.co.ke 5th Flr Furaha Plaza > Matthew> > Tel: 254 11 222604 Nkrumah Rd., > Matthew> > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. > Matthew> > > Matthew> > Sex is what women have and men want. > Matthew> > > Matthew> > > Matthew> > To Unsubscribe: send mail to majordomo@FreeBSD.org > Matthew> > with "unsubscribe freebsd-scsi" in the body of the message > Matthew> > > Matthew> > > -Wash > > -- > Odhiambo Washington Inter-Connect Ltd., > wash@iconnect.co.ke 5th Flr Furaha Plaza > Tel: 254 11 222604 Nkrumah Rd., > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. > > Many years ago in a period commonly know as Next Friday Afternoon, there lived > a King who was very Gloomy on Tuesday mornings because he was so Sad thinking > about how Unhappy he had been on Monday and how completely Mournful he would > be on Wednesday.... -Walt Kelly > > > 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 Sat Jan 20 2:14:24 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from siafu.iconnect.co.ke (upagraha.iconnect.co.ke [209.198.248.2]) by hub.freebsd.org (Postfix) with ESMTP id C5A2537B400 for ; Sat, 20 Jan 2001 02:13:37 -0800 (PST) Received: from [64.110.74.50] (helo=poeza.iconnect.co.ke) by siafu.iconnect.co.ke with esmtp (Exim 2.12 #1) id 14JuzL-000IzP-00; Sat, 20 Jan 2001 13:11:17 +0300 Received: from wash by poeza.iconnect.co.ke with local (Exim 3.20 #1) id 14Jv13-0000Ww-00; Sat, 20 Jan 2001 13:13:01 +0300 Date: Sat, 20 Jan 2001 13:13:01 +0300 From: Odhiambo Washington To: Matthew Jacob Cc: freebsd-scsi@freebsd.org Subject: Re: CANNOT ACCESS T20 TAPE Message-ID: <20010120131301.A2015@poeza.iconnect.co.ke> References: <20010120100945.A365@poeza.iconnect.co.ke> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from "Matthew Jacob" on Fri, Jan 19, 2001 at 11:58:11PM -0800 X-Operating-System: FreeBSD poeza.iconnect.co.ke 4.2-STABLE FreeBSD 4.2-STABLE X-Mailer: Mutt http://www.mutt.org/ X-Location: Mombasa, KE, East Africa Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Jacob [20010120 11:00]: writing on the subject 'Re: CANNOT ACCESS T20 TAPE' Matthew> Matthew> You're missing where the output is coming out. Ship your /var/log/messages Matthew> file. Sorry for my being daft. Here I attach the output from /var/log/messages after the test. ## Jan 20 13:10:16 poeza /kernel: (xpt0:ahc0:0:4:0): debugging flags now 9 Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): saopen(0): dev=0x0 softc=0x0 Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): sastart(sa0:ahc0:0:4:0): RESERVE(06). CDB: 16 0 0 0 0 0 Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): sastart(sa0:ahc0:0:4:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ Jan 20 13:10:16 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ Jan 20 13:10:16 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ Jan 20 13:10:17 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ Jan 20 13:10:17 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): REWIND. CDB: 1 0 0 0 0 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x2 ASC/ASCQ Jan 20 13:10:17 poeza /kernel: 0x3a 0x0 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): REWIND. CDB: 1 0 0 0 0 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x2 ASC/ASCQ Jan 20 13:10:17 poeza /kernel: 0x3a 0x0 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): REWIND. CDB: 1 0 0 0 0 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x2 ASC/ASCQ Jan 20 13:10:17 poeza /kernel: 0x3a 0x0 flags 0x0 resid 0 dxfer_len 0 Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): sastart(sa0:ahc0:0:4:0): RELEASE(06). CDB: 17 0 0 0 0 0 ## Thank you. Matthew> Matthew> Matthew> On Sat, 20 Jan 2001, Corvette wrote: Matthew> Matthew> > * Matthew Jacob [20010119 20:56]: writing on the subject 'Re: CANNOT ACCESS T20 TAPE' Matthew> > Matthew> Matthew> > Matthew> Matthew> > Matthew> Is a tape inserted? If not, then there is no bug here. Insert a tape prior to Matthew> > Matthew> attempting to get status (unless you use the 'control' entry point, but that Matthew> > Matthew> will yield pointless information). Matthew> > Matthew> Matthew> > Matthew> If so, build a kernel with CAMDEBUG enabled, boot that, and then do Matthew> > Matthew> Matthew> > Matthew> camcontrol debug -Ic 0:4:0 Matthew> > Matthew> Matthew> > Matthew> and then do the 'mt status' and ship the output back to the list. Matthew> > Matthew> > Hi, Matthew> > As a followup to the problem that I'm having with my tape drive, I've built and Matthew> > booted up a kernel with "options CAMDEBUG" and below is my output. Matthew> > Matthew> > ## Matthew> > wash:/usr/home/wash# camcontrol debug -Ic 0:4:0 Matthew> > Debugging enabled for 0:4:0 Matthew> > wash:/usr/home/wash# mt status Matthew> > mt: /dev/nsa0: Device not configured Matthew> > wash:/usr/home/wash# Matthew> > ## Matthew> > Matthew> > I'm still not subscribed to this list. Kindly include me in any replies via a cc. Matthew> > Matthew> > Thank you. Matthew> > Matthew> > Matthew> > Matthew> > Matthew> Matthew> > Matthew> Matthew> > Matthew> Matthew> > Matthew> > Hi, Matthew> > Matthew> > I recently cvsupped and updated my 3.5-STABLE box to 4.2_STABLE. Matthew> > Matthew> > I had quite a few problems initially when doing buildworld but a Matthew> > Matthew> > good samaritan came to my rescue and sent me precise details that Matthew> > Matthew> > had worked for one of 'us'. Matthew> > Matthew> > Matthew> > Matthew> > At the moment I seem to be in a bad fix because I cannot access my Matthew> > Matthew> > tape drive, an HP T20. What I mean is that mt returns an error Matthew> > Matthew> > Matthew> > Matthew> > /dev/nsa0: device not configured. Matthew> > Matthew> > Matthew> > Matthew> > I posted this to the -quetsions and I got overwhelming response but all Matthew> > Matthew> > the suggestions I received did not yield the solution I was looking for. Matthew> > Matthew> > So please pardon me if this is considered a double post. I am only anxious for Matthew> > Matthew> > a solution. Without a backup, we all know where I stand - on the firing line. Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > I am running an HP Netserver E20 and here is a section of my dmesg.boot: Matthew> > Matthew> > ## Matthew> > Matthew> > [snip] Matthew> > Matthew> > ahc0: port 0x1000-0x10ff mem 0xfc100000-0xfc100fff irq 10 at device 5.0 on pci0 Matthew> > Matthew> > ahc0: Using left over BIOS settings Matthew> > Matthew> > aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs Matthew> > Matthew> > ahc1: port 0x1400-0x14ff mem 0xfc101000-0xfc101fff irq 10 at device 5.1 on pci0 Matthew> > Matthew> > ahc1: Host Adapter Bios disabled. Using default SCSI device parameters Matthew> > Matthew> > aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs Matthew> > Matthew> > . Matthew> > Matthew> > . Matthew> > Matthew> > . Matthew> > Matthew> > Waiting 15 seconds for SCSI devices to settle Matthew> > Matthew> > sa0 at ahc0 bus 0 target 4 lun 0 Matthew> > Matthew> > sa0: Removable Sequential Access SCSI-2 device Matthew> > Matthew> > sa0: 3.300MB/s transfers Matthew> > Matthew> > da1 at ahc0 bus 0 target 2 lun 0 Matthew> > Matthew> > da1: Fixed Direct Access SCSI-2 device Matthew> > Matthew> > da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled Matthew> > Matthew> > da1: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Matthew> > Matthew> > Mounting root from ufs:/dev/da0s1a Matthew> > Matthew> > da0 at ahc0 bus 0 target 0 lun 0 Matthew> > Matthew> > da0: Fixed Direct Access SCSI-2 device Matthew> > Matthew> > da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled Matthew> > Matthew> > da0: 8678MB (17773524 512 byte sectors: 64H 32S/T 8678C) Matthew> > Matthew> > [snip] Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > and here is some output from /dev Matthew> > Matthew> > wash:~$ cd /dev/ Matthew> > Matthew> > wash:/dev$ ls -al *sa0 Matthew> > Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 ersa0 Matthew> > Matthew> > crw-rw---- 4 root operator 14, 2 Jan 18 12:18 esa0 Matthew> > Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nrsa0 Matthew> > Matthew> > crw-rw---- 4 root operator 14, 1 Jan 18 12:18 nsa0 Matthew> > Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 rsa0 Matthew> > Matthew> > crw-rw---- 4 root operator 14, 0 Jan 18 12:18 sa0 Matthew> > Matthew> > Matthew> > Matthew> > ...and a little bit more... Matthew> > Matthew> > Matthew> > Matthew> > wash:/dev$ mt status Matthew> > Matthew> > mt: /dev/nsa0: Device not configured Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > And I followed the procedure below to go to 4.2_STABLE... Matthew> > Matthew> > Matthew> > Matthew> > All help welcome. Matthew> > Matthew> > Matthew> > Matthew> > Thanks. Matthew> > Matthew> > Matthew> > Matthew> > NB: I am not subscribed to this list, so kindly cc me in your reply. Matthew> > Matthew> > Matthew> > Matthew> > -Wash Matthew> > Matthew> > Matthew> > Matthew> > -- Matthew> > Matthew> > Odhiambo Washington Inter-Connect Ltd., Matthew> > Matthew> > wash@iconnect.co.ke 5th Flr Furaha Plaza Matthew> > Matthew> > Tel: 254 11 222604 Nkrumah Rd., Matthew> > Matthew> > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Matthew> > Matthew> > Matthew> > Matthew> > Sex is what women have and men want. Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > Matthew> > To Unsubscribe: send mail to majordomo@FreeBSD.org Matthew> > Matthew> > with "unsubscribe freebsd-scsi" in the body of the message Matthew> > Matthew> > Matthew> > Matthew> Matthew> > Matthew> > -Wash Matthew> > Matthew> > -- Matthew> > Odhiambo Washington Inter-Connect Ltd., Matthew> > wash@iconnect.co.ke 5th Flr Furaha Plaza Matthew> > Tel: 254 11 222604 Nkrumah Rd., Matthew> > Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Matthew> > Matthew> > Many years ago in a period commonly know as Next Friday Afternoon, there lived Matthew> > a King who was very Gloomy on Tuesday mornings because he was so Sad thinking Matthew> > about how Unhappy he had been on Monday and how completely Mournful he would Matthew> > be on Wednesday.... -Walt Kelly Matthew> > Matthew> > Matthew> > To Unsubscribe: send mail to majordomo@FreeBSD.org Matthew> > with "unsubscribe freebsd-scsi" in the body of the message Matthew> > Matthew> Matthew> -Wash -- Odhiambo Washington Inter-Connect Ltd., wash@iconnect.co.ke 5th Flr Furaha Plaza Tel: 254 11 222604 Nkrumah Rd., Fax: 254 11 222636 PO Box 83613 MOMBASA, KE. Efficiency is intelligent laziness. -David Dunham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 20 10:18: 1 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7ABCB37B401 for ; Sat, 20 Jan 2001 10:17:43 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA08909; Sat, 20 Jan 2001 10:05:17 -0800 Date: Sat, 20 Jan 2001 10:17:35 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Odhiambo Washington Cc: freebsd-scsi@freebsd.org Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <20010120131301.A2015@poeza.iconnect.co.ke> 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 > > Sorry for my being daft. Here I attach the output from /var/log/messages after the test. Good. Exactly what I'm wanting to see.. So... The Sense Key 9 being returned is "VENDOR SPECIFIC". W/O T20 docs I can't tell you what the issue is. So, the first thing the tape driver does when it sees a tape driver for the first time is to make sure the tape is rewound. Clearly LOAD(to BOT) is failing. With 5/24 as the ASC/ASCQ, I'm sure somebody at HP *MEANT* to use Sense Key 5 (Illegal Command) but they just forgot their SCSI spec at home that day. Now, the REWIND command (used alternately) is failing with Sense Key 2 (Not Ready) and the ASC/ASCQ values are 'Medium Not Present'. So, you either don't have a tape inserted in the drive or the drive doesn't like the tape at all. Things don't work w/o a tape inserted. > > ## > Jan 20 13:10:16 poeza /kernel: (xpt0:ahc0:0:4:0): debugging flags now 9 > Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): saopen(0): dev=0x0 softc=0x0 > Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): sastart(sa0:ahc0:0:4:0): RESERVE(06). CDB: 16 0 0 0 0 0 > Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): sastart(sa0:ahc0:0:4:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ > Jan 20 13:10:16 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > Jan 20 13:10:16 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ > Jan 20 13:10:16 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ > Jan 20 13:10:17 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x9 ASC/ASCQ > Jan 20 13:10:17 poeza /kernel: 0x5 0x24 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x2 ASC/ASCQ > Jan 20 13:10:17 poeza /kernel: 0x3a 0x0 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x2 ASC/ASCQ > Jan 20 13:10:17 poeza /kernel: 0x3a 0x0 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): Key 0x2 ASC/ASCQ > Jan 20 13:10:17 poeza /kernel: 0x3a 0x0 flags 0x0 resid 0 dxfer_len 0 > Jan 20 13:10:17 poeza /kernel: (sa0:ahc0:0:4:0): sastart(sa0:ahc0:0:4:0): RELEASE(06). CDB: 17 0 0 0 0 0 > ## To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 20 15:26:14 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4E35337B400 for ; Sat, 20 Jan 2001 15:25:57 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA00703; Sat, 20 Jan 2001 15:13:22 -0800 Date: Sat, 20 Jan 2001 15:25:47 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Odhiambo Washington Cc: freebsd-scsi@freebsd.org Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <20010119210817.B14078@poeza.iconnect.co.ke> 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 T20 with 3.00 f/w which works just peacy in -current. I know you said things worked fine under 3.4 and now don't work when you upgraded to 4.2- but I have to say that this seems very unlikely somehow. It seems like your tape drive has died. Please retry 3.4 and see what's up with that and let me know. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 20 22:36: 8 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from synology.com (dns1.synology.com [202.173.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 21ACC37B400 for ; Sat, 20 Jan 2001 22:35:49 -0800 (PST) Received: from derrenltest ([192.168.1.227]) by synology.com (8.9.3/8.9.3) with SMTP id OAA11633; Sun, 21 Jan 2001 14:35:45 +0800 From: "Derren L." To: , "Iain Templeton" Cc: "cheen" , Subject: RE: More target mode observations Date: Sun, 21 Jan 2001 14:45:41 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org PkZvbGxvd2luZyB1cCB0byBteXNlbGYgd2l0aCBhIGJpdCBtb3JlIGluZm8sICANCj4NCj5JIHBs YXllZCBhcm91bmQgYSBsaXR0bGUgYml0IG1vcmUsIGFuZCBkaXNjb3ZlcmVkIHRoYXQgeWVzLCB3 ZSBkbyBoYXZlDQo+c29tZSBhdGlvJ3Mgd2FpdGluZywgYW5kIGlmIHdlIGdldCBhIGJ1cyByZXNl dCBvbmUgb2YgdGhlc2UgZ2V0cyBzZW50DQo+YmFjay4NCj4NCj5JIGFsc28gZGlzY292ZXJlZCB0 aGF0IGFoY19pbnRyKCkgbmV2ZXIgZ2V0cyBjYWxsZWQgZHVyaW5nIHRoZSByZXNjYW4gb2YNCj50 aGUgYnVzIHdoaWxzdCBpbiB0YXJnZXQgbW9kZS4gVG8gbWUgYXQgbGVhc3QgdGhpcyB3b3VsZCBz dWdnZXN0IHRoYXQNCj50aGUgY29udHJvbGxlciBpcyBuZXZlciBiZWluZyBzZWxlY3RlZCwgb3Ig ZmFpbGluZyB0aGF0IHRoZSBjb250cm9sbGVyDQo+aXMgbmV2ZXIgdGVsbGluZyB0aGUgZGV2aWNl IGRyaXZlciB0aGF0IGl0IGhhcyBiZWVuIHNlbGVjdGVkLg0KPg0KPlVuZm9ydHVuYXRlbHkgd2Ug ZG8gbm90IGhhdmUgYW55IGhhcmR3YXJlIGhlcmUgZm9yIGV4YW1pbmluZyBTQ1NJDQo+YnVzc2Vz LCBvdGhlcndpc2UgSSBjb3VsZCBmaW5kIG91dCB3aGV0aGVyIHRoZSBjb250cm9sbGVyIHdhcyBy ZXNwb25kaW5nDQo+dG8gdGhlIHNlbGVjdCB3aXRoIEJTWSAod2VsbCwgd2UgaGF2ZSB0aGUgbG9n aWMgYW5hbHlzZXIsIGJ1dCBub3RoaW5nIHRvDQo+cGx1ZyBpdCBpbiB3aXRoKS4NCj4NCj5UaGUg b3RoZXIgdGhpbmcgaXMgdGhhdCBJIG9ubHkgZ2V0IGJ1cyByZXNldCBpbnRlcm1pdHRhbnRseSwg d2hpY2gNCj53b3JyaWVzIG1lLiBCeSB0aGlzIEkgbWVhbiB0aGF0IEkgY2FuIGRvIGEgY2FtY29u dHJvbCByZXNldCA8YnVzPiBvbiBvbmUNCj5tYWNoaW5lLCBhbmQgdGhlIG90aGVyIG1hY2hpbmUg ZG9lc24ndCBhbHdheXMgcGljayBpdCB1cCAoSSBkb24ndCBnZXQNCj5oZSAiU29tZWJvZHkgcmVz ZXQgYnVzICVkIiBtZXNzYWdlKS4NCj4NCg0KSGk6DQoNCkkgYW0gZXhwZXJpZW5jaW5nIGV4YWN0 bHkgd2hhdCB5b3UgZGVzY3JpYmVkIGluIHlvdXIgbWFpbC4NCkFuZCBJIGFtIGFsc28gbG9va2lu ZyBmb3IgdGhlIGFuc3dlcnMuDQoNCkkgaGF2ZSB0d28gQUhBLTI5NDBVMlcgY2FyZCBvbiB0d28g ZGlmZmVyZW50IG1hY2hpbmUgcmVzcGVjdGl2ZWx5Lg0KSSBuYW1lZCB0aGVtIGJyYWluLXRlc3Qg YW5kIGlkYi10ZXN0IHJlc3BlY3RpdmVseS4gVGhleSBhcmUgY29ubmVjdGVkIGJ5DQphbiBleHRl cm5hbCBzY3NpIGNhYmxlLiBUaGUgY2hpcCBvbiB0aGUgc2NzaSBjYXJkIGlzIGFpYy03ODkwIChp dCBzaG91bGQgDQp3b3JrIHdlbGwgYWNjb3JkaW5nIHRvIEp1c3Rpbi4pIEFuZCB0aGUgRnJlZUJT RCB2ZXJzaW9uIGlzIDQuMS0yMDAwMDgxMi1TVEFCTEUuDQoNClVuZm9ydHVuYXRlbHksIHdoZW4g SSB0cmlnZ2VyZWQgdGhlIHRhcmdldCBtb2RlIG9wZXJhdGlvbiBvbiB0aGUgaWRiLXRlc3QgDQpt YWNoaW5lIGFuZCByZXNjYW5uZWQgdGhlIGJ1cyBmcm9tIHRoZSBicmFpbi10ZXN0IG1hY2hpbmUs IGl0IGZvdW5kIG5vdGhpbmcuIA0KT24gdGhlIG9uZSB3YXksIHRoZSBicmFpbi10ZXN0IGRpZCBz ZWxlY3QgdGhlIHRhcmdldCBtb2RlIGNvbnRyb2xsZXIsIGJ1dCBpdCANCmdvdCBubyByZXNwb25z ZSBhbmQgcmV0dXJuZWQgd2l0aCB0aW1lIG91dCBtZXNzYWdlLiBPbiB0aGUgb3RoZXIgd2F5LCB0 aGUNCnRhcmdldCBjb250cm9sbGVyIGRpZG4ndCBjYXB0dXJlIGFueSBzZWxlY3QgcmVxdWVzdC4g SXQgbG9va3MgbGlrZSB0aGF0IGNoaXAgb24NCmlkYi10ZXN0IGlzIG5vdCBwcm9wZXJseSB0cmln Z2VyZWQuIEkgbWVhbiBpdCBkb2Vzbid0IGtub3cgaXQgc2hvdWxkIGFjdA0KYXMgYSB0YXJnZXQg bW9kZSBjb250cm9sbGVyLiBCdXQgdGhlIGludGVyZXN0aW5nIHRoaW5zIGlzIGl0IGNhbiBjYXRj aCB0aGUgDQpjaGFubmVsIHJlc2V0IHNpZ25hbC4NCg0KSSBoYWQgYWxzbyB0ZXN0ZWQgdGhlIGFp Yy03ODk5LCBhbmQgcHV0IGluIG9uIHRoZSBpZGItdGVzdCBtYWNoaW5lLiANCkJ1dCBpdCBzdGls bCBkaWRuJ3Qgd29yay4NCg0KSSdtIGluY2x1ZGluZyBhIGNvcHkgb2YgdGhlIC92YXIvbG9nL21l c3NhZ2VzIHdpdGggZGlhZ25vc3RpYyBvdXRwdXQuDQpJIHdpc2ggaXQgaGVscHMgZm9yIHZlcmlm eWluZyB0aGUgc2l0dWF0aW9ucy4NCg0KSWYgYW55b25lIGhhcyBhbnkgaWRlYXMgb3Igc3VnZ2Vz dGlvbnMsIEkgd291bGQgbGlrZSB0byBoZWFyIGZyb20geW91DQoNCglEZXJyZW4gTC4NCglkZXJy ZW5sQHN5bm9sb2d5LmNvbQ0KDQoNCkhlcmUgaXMgdGhlIC92YXIvbG9nL21lc3NhZ2VzIG91dHB1 dDoNCiMNCiMgdGhlIGxvZyBvbiBicmFpbi10ZXN0IG1hY2hpbmUNCiMNCmJyYWluLXRlc3QgL2tl cm5lbDogYWhjMTogPEFkYXB0ZWMgMjk0MCBVbHRyYTIgU0NTSSBhZGFwdGVyPiBwb3J0IDB4MWMw MC0weDFjZmYgbWVtIDB4ZmI0MDAwMDAtMHhmYjQwMGZmZiBpcnEgMTAgYXQgZGV2aWNlIDE0LjAg b24gcGNpMQ0KYnJhaW4tdGVzdCAva2VybmVsOiBhaGMxOiBSZWFkaW5nIFNFRVBST00uLi5kb25l Lg0KYnJhaW4tdGVzdCAva2VybmVsOiBhaGMxOiBCSU9TIGVlcHJvbSBpcyBwcmVzZW50DQpicmFp bi10ZXN0IC9rZXJuZWw6IGFoYzE6IFNlY29uZGFyeSBIaWdoIGJ5dGUgdGVybWluYXRpb24gRW5h YmxlZA0KYnJhaW4tdGVzdCAva2VybmVsOiBhaGMxOiBTZWNvbmRhcnkgTG93IGJ5dGUgdGVybWlu YXRpb24gRW5hYmxlZA0KYnJhaW4tdGVzdCAva2VybmVsOiBhaGMxOiBQcmltYXJ5IExvdyBCeXRl IHRlcm1pbmF0aW9uIEVuYWJsZWQNCmJyYWluLXRlc3QgL2tlcm5lbDogYWhjMTogUHJpbWFyeSBI aWdoIEJ5dGUgdGVybWluYXRpb24gRW5hYmxlZA0KYnJhaW4tdGVzdCAva2VybmVsOiBhaGMxOiBh aWM3ODkwLzkxIFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElkPTcsIDE2LzI1NSBTQ0JzDQpicmFpbi10 ZXN0IC9rZXJuZWw6IGFoYzE6IGhhcmR3YXJlIHNjYiA2NCBieXRlczsga2VybmVsIHNjYiAzMiBi eXRlczsgYWhjX2RtYSA4IGJ5dGVzDQpicmFpbi10ZXN0IC9rZXJuZWw6IGFoYzE6IERvd25sb2Fk aW5nIFNlcXVlbmNlciBQcm9ncmFtLi4uIDQwMyBpbnN0cnVjdGlvbnMgZG93bmxvYWRlZA0KDQoj IEVuYWJsZSB0aGUgZGVidWcgaW5mb3JtYXRpb24NCmJyYWluLXRlc3QgL2tlcm5lbDogKHhwdDA6 eHB0MDowOi0xOi0xKTogZGVidWdnaW5nIGZsYWdzIG5vdyA3DQoNCiMgUmVzZXQgdGhlIGJ1cy4g QW5kIHRoZSBpZGItdGVzdCBkaWQgZ2V0IHRoZSByZXNldCByZXF1ZXN0Lg0KYnJhaW4tdGVzdCAv a2VybmVsOiAobm9wZXJpcGg6YWhjMTowOi0xOi0xKTogU0NTSSBidXMgcmVzZXQgZGVsaXZlcmVk LiAwIFNDQnMgYWJvcnRlZC4NCg0KIyBSZXNjYW4gdGhlIHRhcmdldCBtb2RlIGNvbnRyb2xsZXIN CiMgSXQgZ290IGEgc2VsZWN0IHRpbWUgb3V0IHN0YXR1cw0KYnJhaW4tdGVzdCAva2VybmVsOiAo cHJvYmUwOmFoYzE6MDo5OjApOiBwcm9iZXN0YXJ0ICAgDQpicmFpbi10ZXN0IC9rZXJuZWw6IChw cm9iZTA6YWhjMTowOjk6MCk6IHhwdF9hY3Rpb24gICANCmJyYWluLXRlc3QgL2tlcm5lbDogKHBy b2JlMDphaGMxOjA6OTowKTogYWhjX2FjdGlvbg0KYnJhaW4tdGVzdCAva2VybmVsOiAocHJvYmUw OmFoYzE6MDo5OjApOiBzdGFydCBzY2IoMHhjMGE0MTAwMCkNCmJyYWluLXRlc3QgL2tlcm5lbDog YWhjX2hhbmRsZV9zY3NpaW50OiBTRUxUTw0KYnJhaW4tdGVzdCAva2VybmVsOiAocHJvYmUwOmFo YzE6MDo5OjApOiBhaGNfZG9uZSAtIHNjYiAwDQpicmFpbi10ZXN0IC9rZXJuZWw6IChwcm9iZTA6 YWhjMTowOjk6MCk6IHhwdF9kb25lDQpicmFpbi10ZXN0IC9rZXJuZWw6IChwcm9iZTA6YWhjMTow Ojk6MCk6IGNhbWlzcihwcm9iZTA6YWhjMTowOjk6MCk6IHByb2JlZG9uZQ0KDQoNCiMNCiMgdGhl IGxvZyBvbiBpZGItdGVzdCBtYWNoaW5lDQojDQppZGItdGVzdCAva2VybmVsOiBhaGMxOiA8QWRh cHRlYyAyOTQwIFVsdHJhMiBTQ1NJIGFkYXB0ZXI+IHBvcnQgMHgxYzAwLTB4MWNmZiBtZW0gMHhm YjQwMDAwMC0weGZiDQppZGItdGVzdCAva2VybmVsOiBhaGMxOiBSZWFkaW5nIFNFRVBST00uLi5k b25lLg0KaWRiLXRlc3QgL2tlcm5lbDogYWhjMTogQklPUyBlZXByb20gaXMgcHJlc2VudA0KaWRi LXRlc3QgL2tlcm5lbDogYWhjMTogU2Vjb25kYXJ5IEhpZ2ggYnl0ZSB0ZXJtaW5hdGlvbiBFbmFi bGVkDQppZGItdGVzdCAva2VybmVsOiBhaGMxOiBTZWNvbmRhcnkgTG93IGJ5dGUgdGVybWluYXRp b24gRW5hYmxlZCANCmlkYi10ZXN0IC9rZXJuZWw6IGFoYzE6IFByaW1hcnkgTG93IEJ5dGUgdGVy bWluYXRpb24gRW5hYmxlZCAgIA0KaWRiLXRlc3QgL2tlcm5lbDogYWhjMTogUHJpbWFyeSBIaWdo IEJ5dGUgdGVybWluYXRpb24gRW5hYmxlZCAgIA0KaWRiLXRlc3QgL2tlcm5lbDogYWhjMTogYWlj Nzg5MC85MSBXaWRlIENoYW5uZWwgQSwgU0NTSSBJZD05LCAxNi8yNTUgU0NCcw0KaWRiLXRlc3Qg L2tlcm5lbDogYWhjMTogaGFyZHdhcmUgc2NiIDY0IGJ5dGVzOyBrZXJuZWwgc2NiIDMyIGJ5dGVz OyBhaGNfZG1hIDggYnl0ZXMNCmlkYi10ZXN0IC9rZXJuZWw6IGFoYzE6IERvd25sb2FkaW5nIFNl cXVlbmNlciBQcm9ncmFtLi4uIDM5MiBpbnN0cnVjdGlvbnMgZG93bmxvYWRlZA0KDQojIEVuYWJs ZSB0aGUgZGVidWcgaW5mb3JtYXRpb24NCmlkYi10ZXN0IC9rZXJuZWw6ICh4cHQwOnhwdDA6MDot MTotMSk6IGRlYnVnZ2luZyBmbGFncyBub3cgNw0KDQojIFRoZSB0YXJnZXQgbW9kZSB3YXMgZW5h YmxlZCBoZXJlDQppZGItdGVzdCAva2VybmVsOiAodGFyZzA6YWhjMTowOjk6MCk6IEx1biBub3cg ZW5hYmxlZCBmb3IgdGFyZ2V0IG1vZGUNCg0KIyBpZGItdGVzdCBjYW4gY2FwdHVyZSB0aGUgY2hh bm5lbCByZXNldCBzaWduYWwNCmlkYi10ZXN0IC9rZXJuZWw6IGFoYzE6IFNvbWVvbmUgcmVzZXQg Y2hhbm5lbCBBDQppZGItdGVzdCAva2VybmVsOiAodGFyZzA6YWhjMTowOjk6MCk6IGNhbWlzclNh dyBldmVudCA0ZTowDQoNCg== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message