From owner-freebsd-scsi Sun Oct 18 03:26:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA02869 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 03:26:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ninbox.ml.org (hsv1-232.airnet.net [207.242.81.232]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA02861 for ; Sun, 18 Oct 1998 03:26:42 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (localhost [127.0.0.1]) by ninbox.ml.org (8.8.8/8.8.8) with ESMTP id FAA03890; Sun, 18 Oct 1998 05:24:31 -0500 (CDT) (envelope-from kris@airnet.net) Message-ID: <3629C1DE.75AFE069@airnet.net> Date: Sun, 18 Oct 1998 05:24:30 -0500 From: Kris Kirby Organization: Absolutely None! X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) MIME-Version: 1.0 To: "Kenneth D. Merry" CC: scsi@FreeBSD.ORG Subject: Re: 2.2.7-RELEASE + CAM = Error Code 1? References: <199810180618.AAA13444@panzer.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry wrote: > You've quite obviously applied a set of CAM patches twice. In addition, > the last 2.2 CAM snapshot isn't guaranteed to apply cleanly to 2.2.7. Why does that not suprise me? :-) -- Kris Kirby UAH Mail UAH CS Home WWW ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 03:59:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA05434 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 03:59:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA05429; Sun, 18 Oct 1998 03:59:57 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA00540 (5.67b/IDA-1.5); Sun, 18 Oct 1998 12:47:37 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id XAA08150; Sat, 17 Oct 1998 23:31:18 +0200 (CEST) From: Wilko Bulte Message-Id: <199810172131.XAA08150@yedi.iaf.nl> Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <19981017191758.A13174@gvr.org> from Guido van Rooij at "Oct 17, 98 07:17:58 pm" To: guido@gvr.org (Guido van Rooij) Date: Sat, 17 Oct 1998 23:31:18 +0200 (CEST) Cc: tlambert@primenet.com, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Guido van Rooij wrote... > On Fri, Oct 16, 1998 at 07:58:17PM +0000, Terry Lambert wrote: > > > > The errors seen are a result of uncommitted data in the drive cache, > > not power spikes and gremlins. The interaction is well understood, > > and on firm footing unrelated to Stephan King novels. > > I always thought a drive will always be able to flush its write cache > to disk, even when power fails. You'd say so, but it is not always the case. I have discussed with the disk experts in our company and they have told me enough to always keep WB caching disabled. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 12:25:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26829 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 12:25:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26811; Sun, 18 Oct 1998 12:25:29 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA24141; Sun, 18 Oct 1998 12:25:05 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd024134; Sun Oct 18 12:24:59 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA19638; Sun, 18 Oct 1998 12:24:58 -0700 (MST) From: Terry Lambert Message-Id: <199810181924.MAA19638@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sun, 18 Oct 1998 19:24:58 +0000 (GMT) Cc: tlambert@primenet.com, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810162349.RAA11679@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 16, 98 05:42:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >The errors seen are a result of uncommitted data in the drive cache, > >not power spikes and gremlins. The interaction is well understood, > >and on firm footing unrelated to Stephan King novels. > > And why do you think the drive didn't bother to commit the data even > though power was constantly supplied to the drive and only a few, > recent transactions were lost? Most likely because hitting the > reset switch caused a power glitch that reverted the drive to its > power on state. I think it's because the PCI bus POSTed the controller, resulting in a SCSI reset, which lost the uncommitted data. It's a lot easier to believe that than to believe the other. I suppose we should test by making a loadable system call that directly calls the reset code, so as to put the "reset causes a reset reliably, but even though no hardware other than the disk write cache is affected, we believe it's because no one debounced the switch" theory to rest. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 12:26:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27047 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 12:26:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA27027; Sun, 18 Oct 1998 12:26:41 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA24326; Sun, 18 Oct 1998 12:26:16 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd024301; Sun Oct 18 12:26:07 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA19706; Sun, 18 Oct 1998 12:26:05 -0700 (MST) From: Terry Lambert Message-Id: <199810181926.MAA19706@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: guido@gvr.org (Guido van Rooij) Date: Sun, 18 Oct 1998 19:26:05 +0000 (GMT) Cc: tlambert@primenet.com, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <19981017191758.A13174@gvr.org> from "Guido van Rooij" at Oct 17, 98 07:17:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The errors seen are a result of uncommitted data in the drive cache, > > not power spikes and gremlins. The interaction is well understood, > > and on firm footing unrelated to Stephan King novels. > > I always thought a drive will always be able to flush its write cache > to disk, even when power fails. The disks which do this are no longer being manufactured by Quantum. I know, because we tried to buy them, in volume. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 12:29:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27393 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 12:29:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA27365; Sun, 18 Oct 1998 12:29:28 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA24841; Sun, 18 Oct 1998 12:29:06 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd024822; Sun Oct 18 12:28:59 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA19832; Sun, 18 Oct 1998 12:28:58 -0700 (MST) From: Terry Lambert Message-Id: <199810181928.MAA19832@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: julian@whistle.com (Julian Elischer) Date: Sun, 18 Oct 1998 19:28:58 +0000 (GMT) Cc: guido@gvr.org, tlambert@primenet.com, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Oct 17, 98 06:59:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I always thought a drive will always be able to flush its write cache > > to disk, even when power fails. > > no, > That's a myth. Actually, there are a number of drives which used to be manufactured, which did this. I don't think anyone is manufacturing them any more, but I know that at least one 7200 RPM IBM SCSI drive did this, and I have the spec sheets (somewhere) for a quantum that would so this, so long as the unwritten data was only a single track. Perhaps they realized that the mpst likely event after a power fluctuation was a bus reset, and figured "why bother?". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 13:38:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA05880 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 13:38:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA05872; Sun, 18 Oct 1998 13:38:57 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199810182038.NAA05872@hub.freebsd.org> Subject: tape drive problem To: scsi Date: Sun, 18 Oct 1998 13:38:57 -0700 (PDT) Cc: gibbs (Justin T. Gibbs) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org finally converted to CAM last night....my tape drive no longer works. its an old Archive Anaconda 1.35GB QIC drive. scsi probe messages are: [snip] Waiting 8 seconds for SCSI devices to settle ncr0: restart (scsi reset). ncr1: restart (scsi reset). (probe11:ncr1:0:4:0): . CDB: 12 1 80 0 ff 0 (probe11:ncr1:0:4:0): ILLEGAL REQUEST asc:24,0 (probe11:ncr1:0:4:0): sks:c8,1 ncr1:4: ERROR (0:4) (8-0-0) (8/33) @ (script 1c4:900b0000). ncr1: script cmd = 910a0000 ncr1: regdump: da 00 80 33 47 08 04 1f 01 08 06 00 80 00 02 02. ncr1: have to clear fifos. ncr1:4: ERROR (0:1) (8-0-0) (8/33) @ (script 3f0:900b0000). ncr1: script cmd = 72100000 ncr1: regdump: da 00 80 33 47 08 04 1f 01 08 06 00 80 00 02 02. ncr1: have to clear fifos. ncr1: restart (fatal error). (probe2:ncr1:0:6:3): COMMAND FAILED (9 ff) @0xf08ed200. (probe11:ncr1:0:4:0): COMMAND FAILED (9 ff) @0xf08f6800. [snip] ncr1:4: ERROR (0:1) (8-0-0) (8/33) @ (script 3f0:900b0000). ncr1: script cmd = 72100000 ncr1: regdump: da 00 80 33 47 08 04 1f 01 08 06 00 80 00 02 02. ncr1: have to clear fifos. ncr1: restart (fatal error). (probe0:ncr1:0:4:7): COMMAND FAILED (9 ff) @0xf08f8a00. sa0 at ncr1 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI2 device sa0: 3.300MB/s transfers [snip] trying to get drive status shows: Aspen:[49] mt status mt: /dev/nrsa0: Input/output error Aspen:[50] mt -f /dev/nrsa0 status mt: /dev/nrsa0: Input/output error Aspen:[51] this drive required special treatment by Stefan Esser to get it working with the scsi/st.c code. any ideas? jmb -- Jonathan M. Bresler FreeBSD Core Team, Postmaster jmb@FreeBSD.ORG FreeBSD--The Power to Serve http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 14:14:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10010 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 14:14:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ninbox.ml.org (hsv1-139.airnet.net [207.242.81.139]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA09998 for ; Sun, 18 Oct 1998 14:14:54 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (localhost [127.0.0.1]) by ninbox.ml.org (8.8.8/8.8.8) with ESMTP id QAA08714 for ; Sun, 18 Oct 1998 16:12:45 -0500 (CDT) (envelope-from kris@airnet.net) Message-ID: <362A59CD.797A20A2@airnet.net> Date: Sun, 18 Oct 1998 16:12:45 -0500 From: Kris Kirby Organization: Absolutely None! X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) MIME-Version: 1.0 To: scsi@FreeBSD.ORG Subject: 2.2.7-RELEASE + CAM = mt.o problem? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From a (supposedly) clean source tree (Meaning I rm -r'd /usr/src and restored from a backup) I applied the patches and it stopped on mt.o: "Undefined symbol '_stringtocomp' referenced from text segment". Any ideas? I do have a copy of the CVS-Repository. -- Kris Kirby UAH Mail UAH CS Home WWW ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 15:11:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14125 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 15:11:44 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14118 for ; Sun, 18 Oct 1998 15:11:41 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA16345; Sun, 18 Oct 1998 16:11:16 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810182211.QAA16345@panzer.plutotech.com> Subject: Re: 2.2.7-RELEASE + CAM = mt.o problem? In-Reply-To: <362A59CD.797A20A2@airnet.net> from Kris Kirby at "Oct 18, 98 04:12:45 pm" To: kris@airnet.net (Kris Kirby) Date: Sun, 18 Oct 1998 16:11:16 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kirby wrote... > >From a (supposedly) clean source tree (Meaning I rm -r'd /usr/src and > restored from a backup) I applied the patches and it stopped on mt.o: > "Undefined symbol '_stringtocomp' referenced from text segment". Any > ideas? I do have a copy of the CVS-Repository. I've got an idea -- follow the directions! If you want to apply the patches, follow the instructions from the README at: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/development/cam/README Here's a quote: ======================================================================== BACKUP YOUR OLD SRC TREE AND KERNEL!!!! cp /kernel /kernel.works Get the code: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/3.0CAM-19980716-SNAP.diffs.gz ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/2.2CAM-19980716-SNAP.diffs.gz or ftp://ftp.kdm.org/pub/FreeBSD/cam/3.0CAM-19980716-SNAP.diffs.gz ftp://ftp.kdm.org/pub/FreeBSD/cam/2.2CAM-19980716-SNAP.diffs.gz On a FreeBSD-current/FreeBSD-stable system from ~0200 PDT on 19980716 # Apply the patches. All patches include "src" in them, so # assuming your src tree is in "/usr": ======================================================================== Notice that it says a source tree/system from ~0200PDT on July 16th. Like I said yesterday, the last 2.2 snapshot isn't guaranteed to apply cleanly to a 2.2.7 tree. It was made a day or two before 2.2.7, and many things were merged into the -stable tree from -current in the intervening time period. If you're going to apply the diffs to a source tree that isn't from the time that was specified in the README file, you've got to have at least enough knowledge of C to fix up any resulting problems. Another alternative is either downloading the release from: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/development/cam/2.2CAM-19980716-SNAP or downloading the entire (correctly) patched source tree from the 'src' subdirectory of the release directory. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 16:08:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18004 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 16:08:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA17999; Sun, 18 Oct 1998 16:08:53 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id RAA21386; Sun, 18 Oct 1998 17:08:21 -0600 (MDT) Message-Id: <199810182308.RAA21386@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: julian@whistle.com (Julian Elischer), guido@gvr.org, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Sun, 18 Oct 1998 19:28:58 -0000." <199810181928.MAA19832@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Oct 1998 17:01:30 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Perhaps they realized that the mpst likely event after a power >fluctuation was a bus reset, and figured "why bother?". And why is this relevant? The only reasons allowed for cache contents never making it to the disk are power loss and hardware failure. A bus reset (assuming the hard reset alternative is in effect) only clears any transactions that have not been reported as completed to the host. Perhaps you should add the SCSI II and SCSI II specs to your list of things to read. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 16:17:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18668 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 16:17:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA18659; Sun, 18 Oct 1998 16:17:08 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id RAA21632; Sun, 18 Oct 1998 17:16:43 -0600 (MDT) Message-Id: <199810182316.RAA21632@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Sun, 18 Oct 1998 19:24:58 -0000." <199810181924.MAA19638@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Oct 1998 17:09:52 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> And why do you think the drive didn't bother to commit the data even >> though power was constantly supplied to the drive and only a few, >> recent transactions were lost? Most likely because hitting the >> reset switch caused a power glitch that reverted the drive to its >> power on state. > >I think it's because the PCI bus POSTed the controller, resulting in >a SCSI reset, which lost the uncommitted data. On a Hawk? I've never seen one respond incorrectly to a bus reset condition. We're also talking about several seconds of delay before the reset occurs (more than the few ms wait before the hawk will flush its cache) since the aic7xxx chips will not assert the reset line until the BIOS has been installed (i.e. hitting the chip reset or POSTing the chip will not cause a spurious bus reset). >It's a lot easier to believe that than to believe the other. Not really. Hawks have had a very good firmware record and the only way that this could happen in your scenario would be because of a firmware bug. >I suppose we should test by making a loadable system call that directly >calls the reset code, so as to put the "reset causes a reset reliably, >but even though no hardware other than the disk write cache is >affected, we believe it's because no one debounced the switch" theory >to rest. Who needs a system call? The user can easily cause a bus reset to occur by opening the XPT device and sending a ccb with the XPT_RESET_BUS function code in it. The alternative is to put the drive on a separate power supply. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 18:39:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29577 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 18:39:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ninbox.ml.org (hsv1-232.airnet.net [207.242.81.232]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29300 for ; Sun, 18 Oct 1998 18:37:01 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (localhost [127.0.0.1]) by ninbox.ml.org (8.8.8/8.8.8) with ESMTP id UAA00360; Sun, 18 Oct 1998 20:30:42 -0500 (CDT) (envelope-from kris@airnet.net) Message-ID: <362A9642.703ADA9F@airnet.net> Date: Sun, 18 Oct 1998 20:30:42 -0500 From: Kris Kirby Organization: Absolutely None! X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) MIME-Version: 1.0 To: "Kenneth D. Merry" CC: scsi@FreeBSD.ORG Subject: Re: 2.2.7-RELEASE + CAM = mt.o problem? References: <199810182211.QAA16345@panzer.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry wrote: > I've got an idea -- follow the directions! But that would make me a good user... :-) > Another alternative is either downloading the release from: > > ftp://ftp.FreeBSD.ORG/pub/FreeBSD/development/cam/2.2CAM-19980716-SNAP > > or downloading the entire (correctly) patched source tree from the 'src' > subdirectory of the release directory. I've decided to go 3.0-RELEASE. This is the only machine that would directly benefit from the upgrade. PIIX3 + Advansys SCSI, the new pcm code... I'm really beginning to like FreeBSD. Thanks for the help, though. -- Kris Kirby UAH Mail UAH CS Home WWW ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 18 22:42:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21418 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 22:42:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21413 for ; Sun, 18 Oct 1998 22:42:03 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA09107; Mon, 19 Oct 1998 01:41:37 -0400 (EDT) Date: Mon, 19 Oct 1998 01:41:37 -0400 (EDT) From: "Matthew N. Dodd" To: Joerg Wunsch cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <19981017085100.15382@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 17 Oct 1998, J Wunsch wrote: > As Matthew N. Dodd wrote: > > I suspect I need to format the media but that command fails as well. > I don't think you can format an optical medium, at least i have yet to > see one where you can. They are hard-sectored. ftp://ftp.jurai.net/users/winter/C1716_scsi.pdf Page 79 "Format Unit Command (04H) Initializes the optical disk surface. An unformated Write-Once disk can be formatted only once." Anyhow, I've low level formatted these things before on an SGI and on a DOS box. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 00:21:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA28669 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 00:21:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA28658 for ; Mon, 19 Oct 1998 00:21:26 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA00303; Mon, 19 Oct 1998 09:21:02 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id IAA13232; Mon, 19 Oct 1998 08:54:47 +0200 (MET DST) (envelope-from j) Message-ID: <19981019085446.46449@uriah.heep.sax.de> Date: Mon, 19 Oct 1998 08:54:46 +0200 From: J Wunsch To: scsi@FreeBSD.ORG Cc: "Matthew N. Dodd" Subject: Re: Strange error Reply-To: Joerg Wunsch References: <19981017085100.15382@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew N. Dodd on Mon, Oct 19, 1998 at 01:41:37AM -0400 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew N. Dodd wrote: > "Format Unit Command (04H) > Initializes the optical disk surface. An unformated Write-Once disk can > be formatted only once." Oh, that's a write-once medium. I thought it were an M-O one. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 08:32:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15839 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 08:32:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA15833 for ; Mon, 19 Oct 1998 08:32:04 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id LAA13198; Mon, 19 Oct 1998 11:31:05 -0400 (EDT) Date: Mon, 19 Oct 1998 11:31:04 -0400 (EDT) From: "Matthew N. Dodd" To: Joerg Wunsch cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <19981019085446.46449@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 19 Oct 1998, J Wunsch wrote: > As Matthew N. Dodd wrote: > > "Format Unit Command (04H) > > Initializes the optical disk surface. An unformated Write-Once disk can > > be formatted only once." > > Oh, that's a write-once medium. I thought it were an M-O one. No, they're qualifying the 'format unit command'. The paragraph should be read as: "rewritable MO media may be formatted as you like; wrinte once MO media can be formatted only once." MO media, while hard sectored, have error correction, bad block maps and other information that must be initializd by a low level format. I'd venture to say that since the media is all common b/t the various 5 1/4" MO drives they all may be low level formatted. I have no experience with 3 1/2" MO drives; frankly they're capacity is so small as to be useless. The only saving feature about the 650 meg MO media is that its quite nearly the size of a CD and works well for arranging CD volumes. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 09:05:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18835 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 09:05:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from lirmm.lirmm.fr (lirmm.lirmm.fr [193.49.104.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18829 for ; Mon, 19 Oct 1998 09:05:45 -0700 (PDT) (envelope-from Michel.Jacquot@lirmm.fr) Received: from lirmm.fr (myosotis.lirmm.fr [193.49.104.14]) by lirmm.lirmm.fr (8.9.1a/8.9.1) with ESMTP id SAA16741 for ; Mon, 19 Oct 1998 18:05:08 +0200 (MET DST) Message-Id: <199810191605.SAA16741@lirmm.lirmm.fr> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG Subject: AMI RAID II controler Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Oct 1998 18:05:08 +0200 From: Michel Jacquot Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, we just purchased a DELL PC with a RAID II American Megatrends Inc. (AMI) controler. After the boot, the novice installation says: "No disk were found" (with the 2.2.7 and 3.0). Does anyone know if there is a driver or patch for this controler? Best regards, Michel -- Michel Jacquot LIRMM 161 rue ADA 34392 Montpellier Cedex 5 FRANCE Tel +33 (0)4 67 41 85 94 Fax +33 (0)4 67 41 85 00 email: jacquot@lirmm.fr www : http://www.lirmm.fr/~jacquot --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 09:52:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23186 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 09:52:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Gatekeeper.Alameda.net (gatekeeper.Alameda.net [207.90.181.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA23181 for ; Mon, 19 Oct 1998 09:52:20 -0700 (PDT) (envelope-from ulf@Gatekeeper.Alameda.net) Received: by Gatekeeper.Alameda.net (8.8.8/8.8.6) id JAA01502; Mon, 19 Oct 1998 09:51:58 -0700 (PDT) Message-ID: <19981019095158.A27633@Alameda.net> Date: Mon, 19 Oct 1998 09:51:58 -0700 From: Ulf Zimmermann To: Michel Jacquot , freebsd-scsi@FreeBSD.ORG Subject: Re: AMI RAID II controler Reply-To: ulf@Alameda.net References: <199810191605.SAA16741@lirmm.lirmm.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199810191605.SAA16741@lirmm.lirmm.fr>; from Michel Jacquot on Mon, Oct 19, 1998 at 06:05:08PM +0200 Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 2.2.6-STABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Oct 19, 1998 at 06:05:08PM +0200, Michel Jacquot wrote: > Hi, > > > we just purchased a DELL PC with a RAID II American Megatrends Inc. (AMI) > controler. > > After the boot, the novice installation says: "No disk were found" > (with the 2.2.7 and 3.0). > > Does anyone know if there is a driver or patch for this controler? No driver exists. I tried to get programming documentation from AMI, but got never even a response. Don't know if Dell maybe has that documentation and if they would give it out. > > > Best regards, > > Michel > > -- > Michel Jacquot > LIRMM 161 rue ADA > 34392 Montpellier Cedex 5 FRANCE > Tel +33 (0)4 67 41 85 94 Fax +33 (0)4 67 41 85 00 > email: jacquot@lirmm.fr > www : http://www.lirmm.fr/~jacquot > --- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 10:37:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27275 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 10:37:00 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA27270 for ; Mon, 19 Oct 1998 10:36:59 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id LAA23839; Mon, 19 Oct 1998 11:36:18 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810191736.LAA23839@panzer.plutotech.com> Subject: Re: Strange error In-Reply-To: from "Matthew N. Dodd" at "Oct 16, 98 02:14:28 am" To: winter@jurai.net (Matthew N. Dodd) Date: Mon, 19 Oct 1998 11:36:18 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Fri, 16 Oct 1998, Kenneth D. Merry wrote: > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): NOT READY asc:4,2 > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): Logical unit not ready, initializing cmd. required > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): fatal error, failed to attach to device(da2:bt0:0:2:0): removing device entry > > When I boot with media in the drive. > > Most annoying this behavior. I'm not sure why it thinks it needs to > remove the device entry. Did the patch I sent fix that problem? > > > If it would help I have the entire SCSI reference for the drive and the > > > changer available. (2meg PDF @ 600 odd pages). My review of this document > > > has turned up nothing but maybe someone a bit more clued in to the SCSI > > > system would have better luck. > > > > Well, send it on. I'll take a look through it when I get a chance and see > > if I can figure out what's going on. (or you can just give me the URL to > > download it from somewhere) [ ... ] > > Did this work under the old SCSI code? Do you know if it works with any > > other OSes? > > I'm pretty sure they worked with VMS at one point. > > I'd test 'em with Linux but 1. linux doesn't support OPTICAL devices 2. > linux has no way to set mode pages that I can tell. 3. linux has no scsi > changer support. My NetBSD machines didn't seem to like them but I didn't > try very hard and they are all running really old software. Well, I've taken a look through the spec (yes, the whole thing), and I didn't really see anything that would indicate what the problem is. So, I've got a couple of ideas: - Hook it up to an NT box (or some other platform that HP supports) and see whether it works. I know this is distasteful, and you might have to install some HP drivers to make it work, but it would tell us whether there is a hardware problem or not. - If it works under NT, send me the changer and I'll try to get it to work. We've got SCSI analyzers here and can send bus traces to HP if necessary. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 10:48:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28452 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 10:48:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28421; Mon, 19 Oct 1998 10:48:12 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id KAA21084; Mon, 19 Oct 1998 10:47:47 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd021057; Mon Oct 19 10:47:40 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA28054; Mon, 19 Oct 1998 10:47:39 -0700 (MST) From: Terry Lambert Message-Id: <199810191747.KAA28054@usr02.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 19 Oct 1998 17:47:39 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, guido@gvr.org, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810182308.RAA21386@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 18, 98 05:01:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Perhaps they realized that the mpst likely event after a power > >fluctuation was a bus reset, and figured "why bother?". > > And why is this relevant? The only reasons allowed for cache contents > never making it to the disk are power loss and hardware failure. A > bus reset (assuming the hard reset alternative is in effect) only clears > any transactions that have not been reported as completed to the host. > > Perhaps you should add the SCSI II and SCSI II specs to your list of things > to read. Feel free to engage in Ad Hominim attacks, *after* you explain why Don Lewis is seeing the empirical behaviour he is seeing, in contradiction to your claims of what's possible and not. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 10:51:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28970 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 10:51:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28952; Mon, 19 Oct 1998 10:51:27 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id KAA22386; Mon, 19 Oct 1998 10:51:02 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd022349; Mon Oct 19 10:50:55 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA28209; Mon, 19 Oct 1998 10:50:55 -0700 (MST) From: Terry Lambert Message-Id: <199810191750.KAA28209@usr02.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 19 Oct 1998 17:50:55 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810182316.RAA21632@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 18, 98 05:09:52 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >I suppose we should test by making a loadable system call that directly > >calls the reset code, so as to put the "reset causes a reset reliably, > >but even though no hardware other than the disk write cache is > >affected, we believe it's because no one debounced the switch" theory > >to rest. > > Who needs a system call? The user can easily cause a bus reset to occur > by opening the XPT device and sending a ccb with the XPT_RESET_BUS > function code in it. The alternative is to put the drive on a separate > power supply. You were claiming it was the machine reset. I was suggesting a software method of machine reset to take the undebounced reset switch out of the equation. I'm *not* claiming it *is* the SCSI reset, I'm merely claiming that I don't believe that an undebounced reset switch is any more likely than a SCSI reset, and that there's a method we can use to verify or impugn the undebounced reset switch theory. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 10:56:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA29591 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 10:56:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA29528 for ; Mon, 19 Oct 1998 10:56:00 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id NAA14672; Mon, 19 Oct 1998 13:55:03 -0400 (EDT) Date: Mon, 19 Oct 1998 13:55:03 -0400 (EDT) From: "Matthew N. Dodd" To: "Kenneth D. Merry" cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <199810191736.LAA23839@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 19 Oct 1998, Kenneth D. Merry wrote: > Matthew N. Dodd wrote... > > On Fri, 16 Oct 1998, Kenneth D. Merry wrote: > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): NOT READY asc:4,2 > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): Logical unit not ready, initializing cmd. required > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): fatal error, failed to attach to device(da2:bt0:0:2:0): removing device entry > > > > When I boot with media in the drive. > > > > Most annoying this behavior. I'm not sure why it thinks it needs to > > remove the device entry. > > Did the patch I sent fix that problem? I believe so. I get a panic every time when the media is in the drive though. :) dasendorderedtag or something like that. I've got problems with my serial console right now so I can't capture the error. > Well, I've taken a look through the spec (yes, the whole thing), and I > didn't really see anything that would indicate what the problem is. That was my thought as well. They went a good ways towards documenting the whole of the SCSI spec in that doc didn't they. :) > So, I've got a couple of ideas: > > - Hook it up to an NT box (or some other platform that HP supports) > and see whether it works. I know this is distasteful, and you > might have to install some HP drivers to make it work, but it > would tell us whether there is a hardware problem or not. I've got a Win95 box so I'll see if I can get it to work. > - If it works under NT, send me the changer and I'll try to get it > to work. We've got SCSI analyzers here and can send bus traces > to HP if necessary. This is a rather large unit. :) UPS probably won't take it as its around 100 lbs. I've got 2 of them so I've really got no problems shipping one to you otherwise. Let me play with it a bit more and pull one of them apart and see if I can get it working standalone outside the changer. It may be that the drive is just really dirty and needs cleaning. (sensors obscured etc.) Though it is rather odd that both units exhibit the same errors. Where are gyou guys located anyway? -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 11:11:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01855 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 11:11:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01845; Mon, 19 Oct 1998 11:11:33 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id MAA06527; Mon, 19 Oct 1998 12:10:50 -0600 (MDT) Message-Id: <199810191810.MAA06527@pluto.plutotech.com> To: Terry Lambert cc: julian@whistle.com, guido@gvr.org, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Mon, 19 Oct 1998 17:47:39 -0000." <199810191747.KAA28054@usr02.primenet.com> Date: Mon, 19 Oct 1998 12:04:00 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >Perhaps they realized that the mpst likely event after a power >> >fluctuation was a bus reset, and figured "why bother?". >> >> And why is this relevant? The only reasons allowed for cache contents >> never making it to the disk are power loss and hardware failure. A >> bus reset (assuming the hard reset alternative is in effect) only clears >> any transactions that have not been reported as completed to the host. >> >> Perhaps you should add the SCSI II and SCSI II specs to your list of things >> to read. > >Feel free to engage in Ad Hominim attacks... If it was an attack, it was self-inflicted. You should know better than to make statements on topics you do not fully comprehend. It is blatantly obvious to anyone who has read the spec that you either have not read the spec or did not comprehend it. It is only fair to ensure that the less informed people on this list know that you are anything but an expert on SCSI and they should take you comments as uninformed supposition at best. If you don't want to be 'attacked' stop throwing FUD around on our lists. >, *after* you explain why >Don Lewis is seeing the empirical behaviour he is seeing, in >contradiction to your claims of what's possible and not. I've already given my opinion on this. I believe the Hawk is seeing a power glitch or temporary power loss when the reset switch is hit and so the contents of the cache are lost. I have never said that the behavior that Don Lewis is seeing is 'not possible', only that, for the drive in question, the reset causing cache corruption is not likely. Pluto has validated the Hawk for use in our RAID 3 systems, and part of this validation includes spurious bus resets. This behavior was never encountered in our tests. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 11:41:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05186 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 11:41:00 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05165 for ; Mon, 19 Oct 1998 11:40:51 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id MAA24201; Mon, 19 Oct 1998 12:40:13 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810191840.MAA24201@panzer.plutotech.com> Subject: Re: Strange error In-Reply-To: from "Matthew N. Dodd" at "Oct 19, 98 01:55:03 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Mon, 19 Oct 1998 12:40:13 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Mon, 19 Oct 1998, Kenneth D. Merry wrote: > > Matthew N. Dodd wrote... > > > On Fri, 16 Oct 1998, Kenneth D. Merry wrote: > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): NOT READY asc:4,2 > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): Logical unit not ready, initializing cmd. required > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): fatal error, failed to attach to device(da2:bt0:0:2:0): removing device entry > > > > > > When I boot with media in the drive. > > > > > > Most annoying this behavior. I'm not sure why it thinks it needs to > > > remove the device entry. > > > > Did the patch I sent fix that problem? > > I believe so. I get a panic every time when the media is in the drive > though. :) dasendorderedtag or something like that. I've got problems > with my serial console right now so I can't capture the error. That's not good. Send me a stack trace when you get your serial console working. > > Well, I've taken a look through the spec (yes, the whole thing), and I > > didn't really see anything that would indicate what the problem is. > > That was my thought as well. They went a good ways towards documenting > the whole of the SCSI spec in that doc didn't they. :) Yeah, some vendors have a tendency to do that. It comes in handy sometimes, since you don't have to look at both their docs and the scsi spec. There is a lot of vendor-specific stuff that's documented in there, though. > > So, I've got a couple of ideas: > > > > - Hook it up to an NT box (or some other platform that HP supports) > > and see whether it works. I know this is distasteful, and you > > might have to install some HP drivers to make it work, but it > > would tell us whether there is a hardware problem or not. > > I've got a Win95 box so I'll see if I can get it to work. Yeah, sounds like a good idea. > > - If it works under NT, send me the changer and I'll try to get it > > to work. We've got SCSI analyzers here and can send bus traces > > to HP if necessary. > > This is a rather large unit. :) UPS probably won't take it as its around > 100 lbs. I've got 2 of them so I've really got no problems shipping one > to you otherwise. Well, I dunno about UPS, but I've seen FedEx take large packages before. (like Pluto VideoSpace boxes, Ampex DST drives, etc.) > Let me play with it a bit more and pull one of them apart and see if I can > get it working standalone outside the changer. It may be that the drive > is just really dirty and needs cleaning. (sensors obscured etc.) Though > it is rather odd that both units exhibit the same errors. > > Where are gyou guys located anyway? Boulder, CO. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 12:12:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08222 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 12:12:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08204; Mon, 19 Oct 1998 12:12:07 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA06015; Mon, 19 Oct 1998 12:11:43 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd005996; Mon Oct 19 12:11:40 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA02817; Mon, 19 Oct 1998 12:11:26 -0700 (MST) From: Terry Lambert Message-Id: <199810191911.MAA02817@usr02.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 19 Oct 1998 19:11:26 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, guido@gvr.org, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810191810.MAA06527@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 19, 98 12:04:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> Perhaps you should add the SCSI II and SCSI II specs to your list of things > >> to read. > > > >Feel free to engage in Ad Hominim attacks... > > If it was an attack, it was self-inflicted. You should know better > than to make statements on topics you do not fully comprehend. It > is blatantly obvious to anyone who has read the spec that you either > have not read the spec or did not comprehend it. It is only fair > to ensure that the less informed people on this list know that you > are anything but an expert on SCSI and they should take you comments > as uninformed supposition at best. > > If you don't want to be 'attacked' stop throwing FUD around on our lists. I am not presuming to be an expert on SCSI. I *am* presuming to tell you that Don's experiences, and my own, contradict your interpretation of the spec. This is not to say your interpretation is wrong, but it could easily be the case that the drive or controller is not 100% compliant. Jumping down my throat about intepretation of the spec. because the empirically observed behaviour contradicts your knowledge of the spec. (I do not question that your knowledge of the spec. far exceeds mine) resolves nothing. > >, *after* you explain why > >Don Lewis is seeing the empirical behaviour he is seeing, in > >contradiction to your claims of what's possible and not. > > I've already given my opinion on this. I believe the Hawk is seeing > a power glitch or temporary power loss when the reset switch is hit and > so the contents of the cache are lost. I have never said that the > behavior that Don Lewis is seeing is 'not possible', only that, for > the drive in question, the reset causing cache corruption is not likely. > Pluto has validated the Hawk for use in our RAID 3 systems, and part of > this validation includes spurious bus resets. This behavior was never > encountered in our tests. I personally still think it has something to do with what happens when the controller POSTs. I would like to see the following from Don before we simply accept a "magic power glitch": 1) Reset via software instead of via the reset switch 2) Use of a seperate power supply for the drive during reset This will decisively localize it to one side or the other of the bus. If the problem still occurs after 1 but doesn't after 2, then it's time to put a scope on the supply line to the drive. As a datapoint, I have an NCR controller, and the problem occurs on my external SyJet 1.5G drive, which, by definition, has its own power supply, which I would be hard pressed to believe was affected by my hitting the front panel reset but on my seperately supplied computer. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 12:25:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09710 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 12:25:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09703; Mon, 19 Oct 1998 12:25:47 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id NAA10003; Mon, 19 Oct 1998 13:24:58 -0600 (MDT) Message-Id: <199810191924.NAA10003@pluto.plutotech.com> To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), julian@whistle.com, guido@gvr.org, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Mon, 19 Oct 1998 19:11:26 -0000." <199810191911.MAA02817@usr02.primenet.com> Date: Mon, 19 Oct 1998 13:18:07 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I am not presuming to be an expert on SCSI. I *am* presuming to >tell you that Don's experiences, and my own, contradict your >interpretation of the spec. No. You are throwing FUD, unrelated to Don's 'experiences' onto the list. One of the comments I was complaining about was this: >Perhaps they realized that the mpst likely event after a power >fluctuation was a bus reset, and figured "why bother?". This has nothing to do with Don's issue at all. It is also completely faulty logic. >Jumping down my throat about intepretation of the spec. because >the empirically observed behaviour contradicts your knowledge >of the spec. (I do not question that your knowledge of the spec. >far exceeds mine) resolves nothing. The behavior does not contradict my 'interpretation of the spec'. Devices violate the spec all the time, but that is a totally different issue. >I personally still think it has something to do with what happens >when the controller POSTs. > >I would like to see the following from Don before we simply accept >a "magic power glitch": Unless you insist on being argumenative about this, it doesn't matter why or how the cache is invalidated because Don has already decided to turn off his cache. As far as I'm concerned there is nothing more to be gained by this discussion, so I'm going to ignore anything else on this thread. >As a datapoint, I have an NCR controller, and the problem occurs >on my external SyJet 1.5G drive, which, by definition, has its own >power supply, which I would be hard pressed to believe was affected >by my hitting the front panel reset but on my seperately supplied >computer. I do not know what the NCR chips do on POST, nor do I have any experience with the SyJet to know if it has reasonable firmware. This is not a 'datapoint' for Don's experience because it is a totally unrelated device. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 17:48:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA13010 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 17:48:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13000 for ; Mon, 19 Oct 1998 17:48:20 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt2-215.HiWAAY.net [208.147.148.215]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id TAA28649; Mon, 19 Oct 1998 19:47:47 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id TAA00702; Mon, 19 Oct 1998 19:15:51 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199810200015.TAA00702@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Kris Kirby cc: scsi@FreeBSD.ORG From: David Kelly Subject: Re: 2.2.7-RELEASE + CAM = mt.o problem? In-reply-to: Message from Kris Kirby of "Sun, 18 Oct 1998 20:30:42 CDT." <362A9642.703ADA9F@airnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Oct 1998 19:15:51 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kirby writes: > I've decided to go 3.0-RELEASE. This is the only machine that would > directly benefit from the upgrade. PIIX3 + Advansys SCSI, the new pcm > code... I'm really beginning to like FreeBSD. Thanks for the help, > though. *WHAT* !!! "...I'm really beginning to like FreeBSD..." You little nerd, you've been running FreeBSD since 2.0.5, or maybe 2.0.0. I forgot what was on pinky, the 8MB 386DX33 I "loaned" you two or three years ago. But since then you've had the religion as bad as any Linuxian. :-) Ok, maybe pinky had 2.1.0 installed. Same argument applies. Personally I think I'll change my 2.2.8 subscription to the 3.0 line before I make a mess of a running system. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 20:39:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29990 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 20:39:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from f03n03.cac.psu.edu (f03n03-fddi.cac.psu.edu [146.186.157.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29985 for ; Mon, 19 Oct 1998 20:39:18 -0700 (PDT) (envelope-from keefe@cse.psu.edu) Received: from whistle (keefe.bitstream.net [206.144.239.50]) by f03n03.cac.psu.edu (8.8.7/8.6.12) with SMTP id WAA247090 for ; Mon, 19 Oct 1998 22:58:37 -0400 From: "Thomas F. Keefe" To: "FreeBSD Mailing List" Subject: Sequential Disk I/O Date: Mon, 19 Oct 1998 22:00:13 -0500 Message-ID: <000201bdfbd5$c21984a0$0100a8c0@whistle.bitstream.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am trying to write the logging portion of a database and have had trouble getting good performance. I am trying to avoid seek and rotational latency by writing consecutive 512 byte blocks to the disk. Here are some details. I am using Mach/Lites, with the drivers for the Adaptec aic7xxx controller ported from FreeBSD (the version from around 9/97). I am using an Adaptec 2940UW with a Western Digital Enterprise 2G wide SCSI drive (I have tried some other drives as well.) The writing is done by two tasks (processes) so that the next write should always be ready when the previous one finishes. I am able to verify that multiple SCSI requests are in the adapter concurrently. I have also verified that the SCSI write requests are to consecutive logical blocks. However, even with 8 requests in the controller, the average time to complete a request is about 4ms. This amounts to a few sectors written per revolution. I get similar results with iozone under FreeBSD. When the block size is 512 bytes, the throughput is about 50KB/sec. (for a raw device). When the block size is large the bandwidth hits several MB/sec. Is it possible to achieve sequential I/O rates (i.e., no seek latency and no rotational latency) with small write requests? Any insight you can provide will be appreciated. Thanks. Tom Keefe keefe@cse.psu.edu Dept. of Computer Science and Eng. Penn State To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 21:21:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03513 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 21:21:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03507 for ; Mon, 19 Oct 1998 21:21:34 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id WAA01524; Mon, 19 Oct 1998 22:21:00 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810200421.WAA01524@panzer.plutotech.com> Subject: Re: Sequential Disk I/O In-Reply-To: <000201bdfbd5$c21984a0$0100a8c0@whistle.bitstream.net> from "Thomas F. Keefe" at "Oct 19, 98 10:00:13 pm" To: keefe@cse.psu.edu (Thomas F. Keefe) Date: Mon, 19 Oct 1998 22:21:00 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thomas F. Keefe wrote... > I am trying to write the logging portion > of a database and have had trouble getting > good performance. I am trying to avoid seek > and rotational latency by writing consecutive > 512 byte blocks to the disk. You'd get better performance by writing larget blocks, most likely. > Here are some details. I am using > Mach/Lites, with the drivers for the Adaptec > aic7xxx controller ported from FreeBSD > (the version from around 9/97). Is this with the old or new SCSI layer? The SCSI layer in FreeBSD was replaced in mid-September with a new, CAM-based SCSI layer. > I am using > an Adaptec 2940UW with a Western Digital > Enterprise 2G wide SCSI drive (I have tried > some other drives as well.) The controller is okay, but I've seen reports of very poor performance from Western Digital drives when tagged queueing is enabled. In fact, in the new CAM SCSI layer, we've disabled tagged queueing for those drives because one user reported getting 1.5MB/sec performance when tagged queueing was enabled and 8MB/sec when it was disabled. > The writing is done by two tasks (processes) > so that the next write should always be ready when > the previous one finishes. I am able to verify > that multiple SCSI requests are in the adapter > concurrently. I have also verified that the > SCSI write requests are to consecutive logical blocks. > > However, even with 8 requests in the controller, > the average time to complete a request is about > 4ms. This amounts to a few sectors written > per revolution. I get similar results with iozone > under FreeBSD. When the block size is 512 bytes, > the throughput is about 50KB/sec. (for a raw device). > When the block size is large the bandwidth hits > several MB/sec. > > Is it possible to achieve sequential I/O rates > (i.e., no seek latency and no rotational latency) > with small write requests? Any insight you can > provide will be appreciated. Thanks. One thing to keep in mind is that you won't be able to achieve very good performance at all with small block sizes unless you're able to get a large number of tagged transactions to the drive at one time. I don't know what your SCSI subsystem is based on (you only mentioned porting the Adaptec driver, not which Adaptec driver or what your SCSI subsystem is like), but if it is based on the old FreeBSD SCSI subsystem, you'll only be able to have 4 transactions outstanding to the disk at once. Another problem is that your disk supposedly has horrible tagged queueing performance. If you're trying to get good throughput with small transactions, I'd suggest using a drive that behaves a little better. Most IBM and Seagate disks work pretty well. For instance, I've got an IBM Ultrastar 9ZX (9G, 10000RPM). Running iozone with 512 byte blocks for a 256MB file, I get: IOZONE performance measurements: 8054322 bytes/second for writing the file 14070326 bytes/second for reading the file With 64K blocks, I get: IOZONE performance measurements: 14559211 bytes/second for writing the file 15929410 bytes/second for reading the file This is on a filesystem of course, not a raw device. And this is with CAM, not the old SCSI subsystem. So it is possible to get better performance with small block sizes. You probably just need to get a better disk and make sure you can handle more outstanding tagged transactions. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 21:28:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03976 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 21:28:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from f03n03.cac.psu.edu (f03n03-fddi.cac.psu.edu [146.186.157.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03969 for ; Mon, 19 Oct 1998 21:28:08 -0700 (PDT) (envelope-from keefe@cse.psu.edu) Received: from whistle (keefe.bitstream.net [206.144.239.50]) by f03n03.cac.psu.edu (8.8.7/8.6.12) with SMTP id XAA164990 for ; Mon, 19 Oct 1998 23:45:03 -0400 From: "Thomas F. Keefe" To: "FreeBSD Mailing List" Subject: Sequential Disk I/O Date: Mon, 19 Oct 1998 22:46:40 -0500 Message-ID: <000f01bdfbdc$3ee7d6c0$0100a8c0@whistle.bitstream.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am trying to write the logging portion of a database and have had trouble getting good performance. I am trying to avoid seek and rotational latency by writing consecutive 512 byte blocks to the disk. Here are some details. I am using Mach/Lites, with the drivers for the Adaptec aic7xxx controller ported from FreeBSD (the version from around 9/97). I am using an Adaptec 2940UW with a Western Digital Enterprise 2G wide SCSI drive (I have tried some other drives as well.) The writing is done by two tasks (processes) so that the next write should always be ready when the previous one finishes. I am able to verify that multiple SCSI requests are in the adapter concurrently. I have also verified that the SCSI write requests are to consecutive logical blocks. However, even with 8 requests in the controller, the average time to complete a request is about 4ms. This amounts to a few sectors written per revolution. I get similar results with iozone under FreeBSD. When the block size is 512 bytes, the throughput is about 50KB/sec. (for a raw device). When the block size is large the bandwidth hits several MB/sec. Is it possible to achieve sequential I/O rates (i.e., no seek latency and no rotational latency) with small write requests? Any insight you can provide will be appreciated. Thanks. Tom Keefe keefe@cse.psu.edu Dept. of Computer Science and Eng. Penn State To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 22:16:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07017 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 22:16:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07012 for ; Mon, 19 Oct 1998 22:16:54 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id GAA07093; Tue, 20 Oct 1998 06:15:06 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id HAA01214; Tue, 20 Oct 1998 07:07:42 +0200 (CEST) (envelope-from andreas) Message-ID: <19981020070742.A908@klemm.gtn.com> Date: Tue, 20 Oct 1998 07:07:42 +0200 From: Andreas Klemm To: de-bsd-questions@DE.FreeBSD.ORG Cc: freebsd-scsi@FreeBSD.ORG Subject: what do you need in FreeBSD 2.2.7 kernel to burn cd's using cdrecord ? Reply-To: de-bsd-questions@DE.FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, andreas@klemm.gtn.com, andreas.klemm.ak@bayer-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2i X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 2.2.7-STABLE SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ! I think I'm something missing to get CD's burned with cdrecord from Jörg Schilling. The tool tells me, that there is a device missing and now I tried almost everything, but didn't get it to fly :-/ I use Cdrecord release 1.8a5 Copyright (C) 1995-1998 Jörg Schilling root{103} ~ cdrecord -scanbus -v Cdrecord release 1.8a5 Copyright (C) 1995-1998 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '0,6,0' scsibus: 0 target: 6 lun: 0 cdrecord: No such file or directory. Cannot open SCSI driver. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What drivers do I need additionally ???? I have 2 CD-Roms, a normal one and the burner on the first scsi bus on ID 6 ... Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.7-STABLE #0: Tue Oct 20 02:39:07 CEST 1998 root@titan.klemm.gtn.com:/usr/src/sys/compile/TITAN CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff real memory = 83886080 (81920K bytes) avail memory = 79806464 (77936K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 vga0 rev 1 int a irq 14 on pci0:11:0 xl0 <3Com 3c900 Etherlink XL 10BaseT Combo> rev 0 int a irq 14 on pci0:12:0 xl0: Ethernet address: 00:60:97:aa:3a:db xl0: selecting 10baseT transceiver, half duplex ahc0 rev 0 int a irq 11 on pci0:13:0 ahc0: aic7880 Single Channel, SCSI Id=7, 16/255 SCBs ahc0 waiting for scsi devices to settle ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "IBM DORS-32160 WA6A" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2063MB (4226725 512 byte sectors) sd0(ahc0:0:0): with 6703 cyls, 5 heads, and an average 126 sectors/track (ahc0:4:0): "TANDBERG TDC 4222 =07:" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x0, 512-byte blocks, write-enabled (ahc0:5:0): "TOSHIBA CD-ROM XM-5701TA 3136" type 5 removable SCSI 2 cd0(ahc0:5:0): CD-ROM cd present [329195 x 2048 byte records] (ahc0:6:0): "TEAC CD-R55S 1.0K" type 5 removable SCSI 2 cd1(ahc0:6:0): CD-ROM cd present [400000 x 2048 byte records] ahc1 rev 3 int a irq 15 on pci0:14:0 ahc1: aic7870 Single Channel, SCSI Id=7, 16/255 SCBs ahc1 waiting for scsi devices to settle ahc1: target 1 Tagged Queuing Device (ahc1:1:0): "IBM DORS-32160 WA6A" type 0 fixed SCSI 2 sd1(ahc1:1:0): Direct-Access 2063MB (4226725 512 byte sectors) sd1(ahc1:1:0): with 6703 cyls, 5 heads, and an average 126 sectors/track ahc1: target 2 Tagged Queuing Device (ahc1:2:0): "IBM DORS-32160 WA6A" type 0 fixed SCSI 2 sd2(ahc1:2:0): Direct-Access 2063MB (4226725 512 byte sectors) sd2(ahc1:2:0): with 6703 cyls, 5 heads, and an average 126 sectors/track Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <8 virtual consoles, flags=0x0> ed0 at 0x280-0x29f irq 10 maddr 0xd0000 msize 16384 on isa ed0: address 00:00:c0:5a:98:2a, type WD8013EPC (16 bit) sio0 at 0x3f8-0x3ff irq 4 flags 0x20 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: model Generic PS/2 mouse, device ID 0 pcm0 at 0x220 irq 5 drq 1 on isa WARNING: sb: misconfigured secondary DMA channel pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in isic0 at 0xd80 irq 9 flags 0x4 on isa isic0: Teles S0/16.3 isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x960) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x160, AddrB=0x560) npx0 flags 0x1 on motherboard npx0: INT 16 interface ccd0-3: Concatenated disk drivers i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 4 ISDN trace device(s) attached IP packet filtering initialized, divert enabled, logging limited to 500 packets/entry DUMMYNET initialized (980901) -- size dn_pkt 48 changing root device to sd0s2a isppp0: phase establish i4b-L2-i4b_tei_assign: tx TEI ID_Request i4b-L2-i4b_T202_timeout: unit 0, N202 = 3 i4b-L2-i4b_tei_assign: tx TEI ID_Request i4b-L2-i4b_tei_rx_frame: TEI ID Assign - TEI = 65 isppp0: phase authenticate isppp0: phase network isppp0: phase terminate isppp0: phase dead # # titan uniprocessor kernel # machine "i386" cpu "I686_CPU" ident TITAN maxusers 128 options SHOW_BUSYBUFS # busy buffers on shutdown ? options INET #InterNETworking options DUMMYNET options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about dropped packets options "IPFIREWALL_VERBOSE_LIMIT=500" #limit verbosity options IPDIVERT #divert sockets options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" options FFS #Berkeley Fast Filesystem options MFS #Memory File System options PROCFS #Process filesystem options CFS #CODA filesystem. options "CD9660" #ISO 9660 filesystem options MSDOSFS #MS DOS File System options PROCFS #Process filesystem options KERNFS #Kernel filesystem options NSWAPDEV=3 #Allow this many swap-devices. # misc options options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options SYSVSHM,SYSVSEM,SYSVMSG #shared memory (X11) options COMPAT_LINUX # Linux Binary compatibility options "MD5" config kernel root on sd1 # ISA and PCI BUS support controller isa0 controller pci0 # Floppy Disk Controller controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 # SCSI Devices # AHA 2940U controller ahc0 controller scbus0 at ahc0 disk sd0 at scbus0 target 0 unit 0 disk sd3 at scbus0 target 1 unit 0 tape st0 at scbus0 target 4 device cd0 at scbus0 target 5 unit 0 device pt0 at scbus0 target 6 unit 0 #device worm0 at scbus0 target 6 unit 0 # AHA 2940 controller ahc1 controller scbus1 at ahc1 disk sd1 at scbus1 target 1 unit 0 disk sd2 at scbus1 target 2 unit 0 options SCSI_DELAY=8 # Be pessimistic about Joe SCSI device options AHC_TAGENABLE # tagged command queueing options AHC_ALLOW_MEMIO options AHC_SCBPAGING_ENABLE options SCSI_REPORT_GEOMETRY # SCO compatible system console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr options MAXCONS=8 # number of virtual consoles options SC_HISTORY_SIZE=200 # number of history buffer lines # floating point unit device npx0 at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr # serial devices on mainboard # `flags' for serial drivers that support consoles (only for sio now): # 0x10 enable console support for this unit. The other console flags # are ignored unless this is set. Enabling console support does # not make the unit the preferred console - boot with -h or set # the 0x20 flag for that. Currently, at most one unit can have # console support; the first one (in config file order) with # this flag set is preferred. Setting this flag for sio0 gives # the old behaviour. # 0x20 force this unit to be the console (unless there is another # higher priority console). This replaces the COMCONSOLE option. # 0x40 reserve this unit for low level console operations. Do not # device sio0 at isa? port "IO_COM1" tty irq 4 flags 0x20 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr # parallel device on mainboard device lpt0 at isa? port? tty irq 7 vector lptintr # PS/2 mouse on mainboard device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr options "PSM_ACCEL=1" # PS/2 mouse acceleration # Network 3COM PCI device xl0 device vx0 device ed0 at isa? port 0x280 net irq 10 iomem 0xd0000 vector edintr # New Sound code device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x0 vector pcmintr device pca0 at isa? port IO_TIMER1 tty # Pseudo devices pseudo-device loop #Network loopback device pseudo-device ether #Generic Ethernet pseudo-device vn 1 #Vnode driver (turns a file into a dev.) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. pseudo-device disc #Discard device pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device pty 16 #Pseudo ttys - can go as high as 256 pseudo-device gzip # Exec gzipped a.out's pseudo-device ccd 4 #Concatenated disk driver pseudo-device tun 1 #Tunnel driver (user process ppp(8)) pseudo-device su #scsi user pseudo-device ssc #super scsi pseudo-device ppp 1 #Point-to-point protocol options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options PPP_FILTER #enable bpf filtering (needs bpfilter) # Size of the kernel message buffer. Should be N * pagesize. options "MSGBUF_SIZE=40960" # i4b passive ISDN cards support (isic - I4b Siemens Isdn Chipset driver) # Teles S0/16.3 options "TEL_S0_16_3" device isic0 at isa? port 0xd80 net irq 9 flags 0x04 vector isicintr # i4b passive cards D channel handling # Q.921 pseudo-device "i4bq921" # Q.931 pseudo-device "i4bq931" # common passive and active layer 4 # layer 4 pseudo-device "i4b" # userland driver to do ISDN tracing (for passive cards oly) pseudo-device "i4btrc" 4 # userland driver to control the whole thing pseudo-device "i4bctl" # userland driver for access to raw B channel pseudo-device "i4brbch" 4 # userland driver for telephony pseudo-device "i4btel" 2 # network driver for IP over raw HDLC ISDN pseudo-device "i4bipr" 4 # enable VJ header compression detection for ipr i/f options IPR_VJ # network driver for sync PPP over ISDN pseudo-device "i4bisppp" 4 pseudo-device sppp 4 -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 22:21:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07437 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 22:21:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (castles150.castles.com [208.214.165.150]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07431 for ; Mon, 19 Oct 1998 22:21:28 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id WAA00377; Mon, 19 Oct 1998 22:25:40 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810200525.WAA00377@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: de-bsd-questions@DE.FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, andreas@klemm.gtn.com, andreas.klemm.ak@bayer-ag.de Subject: Re: what do you need in FreeBSD 2.2.7 kernel to burn cd's using cdrecord ? In-reply-to: Your message of "Tue, 20 Oct 1998 07:07:42 +0200." <19981020070742.A908@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 19 Oct 1998 22:25:40 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id WAA07433 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi ! > > I think I'm something missing to get CD's burned with cdrecord from > Jörg Schilling. The tool tells me, that there is a device missing > and now I tried almost everything, but didn't get it to fly :-/ > > I use > Cdrecord release 1.8a5 Copyright (C) 1995-1998 Jörg Schilling > > root{103} ~ cdrecord -scanbus -v > Cdrecord release 1.8a5 Copyright (C) 1995-1998 Jörg Schilling > TOC Type: 1 = CD-ROM > scsidev: '0,6,0' > scsibus: 0 target: 6 lun: 0 > cdrecord: No such file or directory. Cannot open SCSI driver. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > What drivers do I need additionally ???? I think you're missing the /dev/scgx symlink. Create it and connect it to almost anything SCSI-related; /dev/rcd0.ctl is a common choice. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 23:14:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12108 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 23:14:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12098 for ; Mon, 19 Oct 1998 23:14:18 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id HAA11931; Tue, 20 Oct 1998 07:01:35 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id HAA02739; Tue, 20 Oct 1998 07:57:44 +0200 (CEST) (envelope-from andreas) Message-ID: <19981020075743.A2732@klemm.gtn.com> Date: Tue, 20 Oct 1998 07:57:43 +0200 From: Andreas Klemm To: Mike Smith , de-bsd-questions@DE.FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, andreas.klemm.ak@bayer-ag.de Subject: Re: what do you need in FreeBSD 2.2.7 kernel to burn cd's using cdrecord ? References: <19981020070742.A908@klemm.gtn.com> <199810200525.WAA00377@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199810200525.WAA00377@dingo.cdrom.com>; from Mike Smith on Mon, Oct 19, 1998 at 10:25:40PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 2.2.7-STABLE SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Oct 19, 1998 at 10:25:40PM -0700, Mike Smith wrote: > > > > What drivers do I need additionally ???? > > I think you're missing the /dev/scgx symlink. Create it and connect it > to almost anything SCSI-related; /dev/rcd0.ctl is a common choice. And what driver do I have to compile in for the burner ? Which of these ? device cd0 at scbus0 target 6 unit 0 device pt0 at scbus0 target 6 unit 0 device worm0 at scbus0 target 6 unit 0 and additionally these ? pseudo-device su #scsi user pseudo-device ssc #super scsi please note, I'm not running CAM, stock 2.2.7-STABLE. Thanks for your help ! -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 19 23:26:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12922 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 23:26:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (castles150.castles.com [208.214.165.150]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12912 for ; Mon, 19 Oct 1998 23:26:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id XAA02327; Mon, 19 Oct 1998 23:30:46 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810200630.XAA02327@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andreas Klemm cc: de-bsd-questions@DE.FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: what do you need in FreeBSD 2.2.7 kernel to burn cd's using cdrecord ? In-reply-to: Your message of "Tue, 20 Oct 1998 07:57:43 +0200." <19981020075743.A2732@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Oct 1998 23:30:45 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Mon, Oct 19, 1998 at 10:25:40PM -0700, Mike Smith wrote: > > > > > > What drivers do I need additionally ???? > > > > I think you're missing the /dev/scgx symlink. Create it and connect it > > to almost anything SCSI-related; /dev/rcd0.ctl is a common choice. > > And what driver do I have to compile in for the burner ? > Which of these ? > device cd0 at scbus0 target 6 unit 0 > device pt0 at scbus0 target 6 unit 0 > device worm0 at scbus0 target 6 unit 0 None of them, with the caveat that what you link /dev/scgx to must be configured. > and additionally these ? > > pseudo-device su #scsi user > pseudo-device ssc #super scsi Shouldn't need either. If the scsi(8) command works, cdrecord should too. > please note, I'm not running CAM, stock 2.2.7-STABLE. Yes, I noticed (for once 8). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 01:11:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA20543 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 01:11:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA20538 for ; Tue, 20 Oct 1998 01:11:44 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id EAA23176; Tue, 20 Oct 1998 04:11:18 -0400 (EDT) Date: Tue, 20 Oct 1998 04:11:18 -0400 (EDT) From: "Matthew N. Dodd" To: "Kenneth D. Merry" cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <199810191840.MAA24201@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I finally got annoyed enough to stay up and work on this 'strange error'. After liberating the drive from the library (no small feat) I set it up sans-case (just the mechanics and electronics sitting on a shelf) and attempted to introduce it to Win95. Win95, being its normal reliable self, froze up and attempted to make good time towards a blue screen. It appears that Win95 will retry a 'START UNIT' command followed by a 'TEST UNIT READY forever, until success. As Peter da Silva is wont to say "Bugger Bill Gates with a woodchuck." I was not pleased. My problem now looks like a hardware problem and if any of you have ever opened up a HP Magneto Optical unit you know the depths of my despair. Listening to the drive attempt to spin up a cart gave me the bright idea that the drive may have some sort of start capacitor, which, being flaky or smokeless, is causing these problems. Undaunted by the sheer complexity and small ribbon strips in the drive, I disassembled most of the major components and re-assembled them, checking contacts etc. I did not find my fabled start capacitor. (Screwy direct drive stepper.) My efforts were rewarded with the same noise, plus a rather unhealthy 'click'. Not good. I happen to recall my old, dead C1716T (the drive in question is a C1716C) and figure "what the heck, I'll keep going until I hit the pacific or I let the smoke out." I swap the good controller assy. onto the motor frame and -nothing-. Knowing the state of the unfortunate donor drive I grit my teeth and pull the ejector frame sled and perform the swap. *Presto* 30 minutes later and a library nearly full of happy MO carts I can finally see the disks, mount data and the whole nine yards. There are a few outstanding CAM problems I need to track down for Kenneth but Yippie! my cool cat scaring surplus store reject works. I wonder if I can convince the other unit to show some signs of life now. Kenneth, thanks for all the help and suggestions and thanks to everyone else who put up with my complete waste of bandwidth during my attempts to get this blasted piece of hardware working. The new CAM stuff rules alot; I'm really happy with it. Far less hoop-jumping than the last time I had to get MO hardware running under FreeBSD. On Mon, 19 Oct 1998, Kenneth D. Merry wrote: > Matthew N. Dodd wrote... > > On Mon, 19 Oct 1998, Kenneth D. Merry wrote: > > > Matthew N. Dodd wrote... > > > > On Fri, 16 Oct 1998, Kenneth D. Merry wrote: > > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): NOT READY asc:4,2 > > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): Logical unit not ready, initializing cmd. required > > > > Oct 14 17:56:23 eisa-test /kernel: (da2:bt0:0:2:0): fatal error, failed to attach to device(da2:bt0:0:2:0): removing device entry > > > > > > > > When I boot with media in the drive. > > > > > > > > Most annoying this behavior. I'm not sure why it thinks it needs to > > > > remove the device entry. > > > > > > Did the patch I sent fix that problem? > > > > I believe so. I get a panic every time when the media is in the drive > > though. :) dasendorderedtag or something like that. I've got problems > > with my serial console right now so I can't capture the error. > > That's not good. Send me a stack trace when you get your serial console > working. > > > > Well, I've taken a look through the spec (yes, the whole thing), and I > > > didn't really see anything that would indicate what the problem is. > > > > That was my thought as well. They went a good ways towards documenting > > the whole of the SCSI spec in that doc didn't they. :) > > Yeah, some vendors have a tendency to do that. It comes in handy > sometimes, since you don't have to look at both their docs and the scsi > spec. There is a lot of vendor-specific stuff that's documented in there, > though. > > > > So, I've got a couple of ideas: > > > > > > - Hook it up to an NT box (or some other platform that HP supports) > > > and see whether it works. I know this is distasteful, and you > > > might have to install some HP drivers to make it work, but it > > > would tell us whether there is a hardware problem or not. > > > > I've got a Win95 box so I'll see if I can get it to work. > > Yeah, sounds like a good idea. > > > > - If it works under NT, send me the changer and I'll try to get it > > > to work. We've got SCSI analyzers here and can send bus traces > > > to HP if necessary. > > > > This is a rather large unit. :) UPS probably won't take it as its around > > 100 lbs. I've got 2 of them so I've really got no problems shipping one > > to you otherwise. > > Well, I dunno about UPS, but I've seen FedEx take large packages before. > (like Pluto VideoSpace boxes, Ampex DST drives, etc.) > > > Let me play with it a bit more and pull one of them apart and see if I can > > get it working standalone outside the changer. It may be that the drive > > is just really dirty and needs cleaning. (sensors obscured etc.) Though > > it is rather odd that both units exhibit the same errors. > > > > Where are gyou guys located anyway? > > Boulder, CO. > > Ken > -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 01:36:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22490 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 01:36:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA22484 for ; Tue, 20 Oct 1998 01:36:25 -0700 (PDT) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl1.philips.com with ESMTP id KAA09852 for ; Tue, 20 Oct 1998 10:35:46 +0200 (MEST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.8.5/8.6.10-1.2.2m-970826) with SMTP id KAA26779 for ; Tue, 20 Oct 1998 10:35:45 +0200 (MET DST) Received: (qmail 12059 invoked by uid 666); 20 Oct 1998 08:36:06 -0000 Date: Tue, 20 Oct 1998 10:36:06 +0200 From: Jos Backus To: freebsd-scsi@FreeBSD.ORG Subject: Re: what do you need in FreeBSD 2.2.7 kernel to burn cd's using cdrecord ? Message-ID: <19981020103606.A11331@hal.mpn.cp.philips.com> References: <19981020075743.A2732@klemm.gtn.com> <199810200630.XAA02327@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.10i In-Reply-To: <199810200630.XAA02327@dingo.cdrom.com>; from Mike Smith on Mon, Oct 19, 1998 at 11:30:45PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Oct 19, 1998 at 11:30:45PM -0700, Mike Smith wrote: > None of them, with the caveat that what you link /dev/scgx to must be > configured. As of 1.6.1a1, cdrecord apparently allows you to do away with this er, hack: - New feature of the scsi open code allows to use cdrecord on *BSD without the hacky symbolic link /dev/scgx Use dev=devicename:target,lun Cheers, -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.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 Tue Oct 20 04:43:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA07087 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 04:43:44 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA07081 for ; Tue, 20 Oct 1998 04:43:42 -0700 (PDT) (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca9-115.ix.netcom.com [209.109.236.115]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id EAA16057 for ; Tue, 20 Oct 1998 04:43:05 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.8.8/8.6.9) id EAA17327; Tue, 20 Oct 1998 04:43:02 -0700 (PDT) Date: Tue, 20 Oct 1998 04:43:02 -0700 (PDT) Message-Id: <199810201143.EAA17327@silvia.hip.berkeley.edu> To: scsi@FreeBSD.ORG Subject: for i in disks From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi folks, I'm thinking about implementing an "autorun"-like mechanism for disks. The idea is to have a script with a known name on a known position (say, partition `a' on the first BSD slice) which is called during boot. The script does something to set up the disk (mount some other partition, or set up a ccd, or something like that). However, to do this, I need to be able to write a loop in /etc/rc* to iterate through all available disks. I guess devfs when fully implemented will make this easy ("/devfs/da[0-9]*s?a"?) but my understanding is that it is not ready yet. I could try mounting all the nodes in /dev (the ones that are not available will presumably just fail) but with up to 96 disks per system, that could be a lot of failures. I could do something like grep 'da[^ ]* at ahc' /var/run/dmesg.boot but it sometimes overlaps other messages and it also appears to be very incomplete on some machines. === >> grep 'da[^ ]* at ahc' /var/run/dmesg.boot | sort WARNING: / was not properly dida12 at ahc0 bus 0 target 12 lun 0 da0 at ahc0 bus 0 target 0 lun 0 da1 at ahc0 bus 0 target 1 lun 0 da10 at ahc0 bus 0 target 10 lun 0 da11 at ahc0 bus 0 target 11 lun 0 da13 at ahc0 bus 0 target 13 lun 0 da14 at ahc0 bus 0 target 14 lun 0 da15 at ahc0 bus 0 target 15 lun 0 da2 at ahc0 bus 0 target 2 lun 0 da3 at ahc0 bus 0 target 3 lun 0 da4 at ahc0 bus 0 target 4 lun 0 da5 at ahc0 bus 0 target 5 lun 0 da64 at ahc4 bus 0 target 0 lun 0 da75 at ahc4 bus 0 target 11 lun 0 da8 at ahc0 bus 0 target 8 lun 0 da9 at ahc0 bus 0 target 9 lun 0 === (There are 42 disks on this machine.) Any ideas? Satoshi (I know I know, one of these days I'll actually implement something) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 08:49:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA28613 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 08:49:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cse.psu.edu (claven.cse.psu.edu [130.203.3.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA28606 for ; Tue, 20 Oct 1998 08:49:45 -0700 (PDT) (envelope-from keefe@cse.psu.edu) Received: from remulak.cse.psu.edu (keefe@remulak.cse.psu.edu [130.203.30.18]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id LAA06177; Tue, 20 Oct 1998 11:48:46 -0400 (EDT) From: Thomas F Keefe Received: (from keefe@localhost) by remulak.cse.psu.edu (8.8.8/8.8.7) id LAA18346; Tue, 20 Oct 1998 11:48:45 -0400 (EDT) Date: Tue, 20 Oct 1998 11:48:45 -0400 (EDT) Message-Id: <199810201548.LAA18346@remulak.cse.psu.edu> To: ken@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Sequential Disk I/O Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Thomas F. Keefe wrote... > > I am trying to write the logging portion > > of a database and have had trouble getting > > good performance. I am trying to avoid seek > > and rotational latency by writing consecutive > > 512 byte blocks to the disk. > > You'd get better performance by writing larget blocks, most likely. Yes, and I may eventually need to do this. However, I want to understand why the performance is so much worse. I can see that there will be more overhead involved, but it seems that if the requests are submitted in order and in time the throughput should approach what I would get writing large blocks. > > Here are some details. I am using > > Mach/Lites, with the drivers for the Adaptec > > aic7xxx controller ported from FreeBSD > > (the version from around 9/97). > > Is this with the old or new SCSI layer? The SCSI layer in FreeBSD was > replaced in mid-September with a new, CAM-based SCSI layer. This is the pre-CAM driver that I ported. I moved the portion of the driver specific to the adapter. (That is, the code under /usr/src/sys/i386/scsi/aic7xxx.[ch] and a few other files.) > > Is it possible to achieve sequential I/O rates > > (i.e., no seek latency and no rotational latency) > > with small write requests? Any insight you can > > provide will be appreciated. Thanks. > > One thing to keep in mind is that you won't be able to achieve very good > performance at all with small block sizes unless you're able to get a large > number of tagged transactions to the drive at one time. I can understand the need for a large number of requests for random access patterns, but if the best possible request (the adjacent sector) is available to the adapter (and perhaps the drive) why are more needed? > I don't know what your SCSI subsystem is based on (you only mentioned > porting the Adaptec driver, not which Adaptec driver or what your SCSI > subsystem is like), but if it is based on the old FreeBSD SCSI subsystem, > you'll only be able to have 4 transactions outstanding to the disk at once. I am using the SCSI layer from Mach, but have modified it to allow more than one outstanding request per target. The modifications are based loosely on the pre-CAM SCSI layer used in FreeBSD (i.e., each target has a number of openings and requests are started if the openings for the target have not been exhausted). > Another problem is that your disk supposedly has horrible tagged queueing > performance. If you're trying to get good throughput with small > transactions, I'd suggest using a drive that behaves a little better. Most > IBM and Seagate disks work pretty well. > > For instance, I've got an IBM Ultrastar 9ZX (9G, 10000RPM). Running iozone > with 512 byte blocks for a 256MB file, I get: > > IOZONE performance measurements: > 8054322 bytes/second for writing the file > 14070326 bytes/second for reading the file > > With 64K blocks, I get: > > IOZONE performance measurements: > 14559211 bytes/second for writing the file > 15929410 bytes/second for reading the file > > This is on a filesystem of course, not a raw device. And this is with CAM, > not the old SCSI subsystem. So it is possible to get better performance > with small block sizes. You probably just need to get a better disk and > make sure you can handle more outstanding tagged transactions. I also get better performance when using the file system. I guess that is because the writes shipped to the controller are actually 8Kbytes blocks. Do these disks have write caching turned on? I have shut mine off and this makes a big difference in the throughput. I can get several MB/sec with it turned on and only about 50KB/sec with it off. Thanks for your response. Tom Keefe keefe@cse.psu.edu > Ken > -- > Kenneth Merry > ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 10:28:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10480 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 10:28:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA10472 for ; Tue, 20 Oct 1998 10:28:47 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id LAA04393; Tue, 20 Oct 1998 11:28:16 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810201728.LAA04393@panzer.plutotech.com> Subject: Re: Sequential Disk I/O In-Reply-To: <199810201548.LAA18346@remulak.cse.psu.edu> from Thomas F Keefe at "Oct 20, 98 11:48:45 am" To: keefe@cse.psu.edu (Thomas F Keefe) Date: Tue, 20 Oct 1998 11:28:16 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thomas F Keefe wrote... > > Thomas F. Keefe wrote... > > > I am trying to write the logging portion > > > of a database and have had trouble getting > > > good performance. I am trying to avoid seek > > > and rotational latency by writing consecutive > > > 512 byte blocks to the disk. > > > > You'd get better performance by writing larget blocks, most likely. > > Yes, and I may eventually need to do this. > However, I want to understand why the performance is > so much worse. I can see that there will be more overhead > involved, but it seems that if the requests are submitted > in order and in time the throughput should approach > what I would get writing large blocks. > > > > Here are some details. I am using > > > Mach/Lites, with the drivers for the Adaptec > > > aic7xxx controller ported from FreeBSD > > > (the version from around 9/97). > > > > Is this with the old or new SCSI layer? The SCSI layer in FreeBSD was > > replaced in mid-September with a new, CAM-based SCSI layer. > > This is the pre-CAM driver that I ported. > I moved the portion of the driver specific to the adapter. > (That is, the code under /usr/src/sys/i386/scsi/aic7xxx.[ch] > and a few other files.) Ahh, okay. > > > Is it possible to achieve sequential I/O rates > > > (i.e., no seek latency and no rotational latency) > > > with small write requests? Any insight you can > > > provide will be appreciated. Thanks. > > > > One thing to keep in mind is that you won't be able to achieve very good > > performance at all with small block sizes unless you're able to get a large > > number of tagged transactions to the drive at one time. > > I can understand the need for a large number of requests > for random access patterns, but if the best possible request > (the adjacent sector) is available to the adapter (and perhaps > the drive) why are more needed? You need to "fill the pipe". i.e., there should be a constant stream of requests to the drive. If you've only got a few requests outstanding to the drive at any one time, the drive may be sitting idle for a time. This is because there is a certain amount of latency involved in actually getting transactions to and from the drive. Another thing to keep in mind is that the disk will be less efficient when writing tiny amounts of data at a time. It may be more efficient if it can write a number of adjacent smaller blocks at a time. (i.e. coalesce them into larger blocks) > > I don't know what your SCSI subsystem is based on (you only mentioned > > porting the Adaptec driver, not which Adaptec driver or what your SCSI > > subsystem is like), but if it is based on the old FreeBSD SCSI subsystem, > > you'll only be able to have 4 transactions outstanding to the disk at once. > > I am using the SCSI layer from Mach, but have modified it > to allow more than one outstanding request per target. The > modifications are based loosely on the pre-CAM SCSI layer > used in FreeBSD (i.e., each target has a number of openings > and requests are started if the openings for the target have > not been exhausted). Well, hopefully the number of openings is large enough. (by large enough, I mean around 64 per device) > > Another problem is that your disk supposedly has horrible tagged queueing > > performance. If you're trying to get good throughput with small > > transactions, I'd suggest using a drive that behaves a little better. Most > > IBM and Seagate disks work pretty well. > > > > For instance, I've got an IBM Ultrastar 9ZX (9G, 10000RPM). Running iozone > > with 512 byte blocks for a 256MB file, I get: > > > > IOZONE performance measurements: > > 8054322 bytes/second for writing the file > > 14070326 bytes/second for reading the file > > > > With 64K blocks, I get: > > > > IOZONE performance measurements: > > 14559211 bytes/second for writing the file > > 15929410 bytes/second for reading the file > > > > This is on a filesystem of course, not a raw device. And this is with CAM, > > not the old SCSI subsystem. So it is possible to get better performance > > with small block sizes. You probably just need to get a better disk and > > make sure you can handle more outstanding tagged transactions. > > I also get better performance when using the file system. I guess > that is because the writes shipped to the controller are > actually 8Kbytes blocks. Actually, on my system, it looks like they vary between 55KB and 64KB. Note that I do have softupdates on the filesystem in question, and that may have some impact on performance. > Do these disks have write caching turned on? I have shut mine > off and this makes a big difference in the throughput. > I can get several MB/sec with it turned on and only about > 50KB/sec with it off. Oddly enough, that's with write caching turned off. I generally run with write caching turned on, but I've never modified the write cache enable settings on this disk. (most of my Quantum disks come with write caching turned on) Here are the numbers with write caching turned on: ============================== 256MB file, 512 byte blocks: IOZONE performance measurements: 8289442 bytes/second for writing the file 14316557 bytes/second for reading the file 256MB file, 64KB blocks: IOZONE performance measurements: 8481791 bytes/second for writing the file 15877882 bytes/second for reading the file ============================== Oddly enough, write performance with the larger block sizes isn't nearly as good with write caching turned on. I'm not sure whether this is the disk, or an effect of softupdates' caching policy, or what. I'm sure Terry will have a theory. I suppose if I disabled softupdates and then re-ran the test, I could find out for sure. Here are numbers with write caching and softupdates turned off: ============================== 256MB file, 512 byte blocks: IOZONE performance measurements: 8423569 bytes/second for writing the file 14310594 bytes/second for reading the file It looked like most of the 512 byte blocks still got coalesced into 55-64KB blocks, even with softupdates turned off. 256MB file, 64KB blocks: IOZONE performance measurements: 13580924 bytes/second for writing the file 15981273 bytes/second for reading the file ============================== Here are the numbers with write caching on, and softupdates off: ============================== 256MB file, 512 byte blocks: IOZONE performance measurements: 8492273 bytes/second for writing the file 14394528 bytes/second for reading the file 256MB file, 64KB blocks: IOZONE performance measurements: 12408717 bytes/second for writing the file 15988710 bytes/second for reading the file ============================== The numbers you should probably look at are the ones with write caching and softupdates turned off. I would certainly recommend getting a better disk, since I think that may be a big reason behind your poor performance. One interesting thing that can be gleaned from the numbers above is that write caching and softupdates seem to screw each other up a little bit for sequential I/O with large block sizes. (write performance with 64KB block sizes was decent in all cases except when both softupdates and write caching were enabled) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 12:19:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21540 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 12:19:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21535 for ; Tue, 20 Oct 1998 12:19:09 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA00566; Tue, 20 Oct 1998 12:22:56 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810201922.MAA00566@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: asami@cs.berkeley.edu (Satoshi Asami) cc: scsi@FreeBSD.ORG Subject: Re: for i in disks In-reply-to: Your message of "Tue, 20 Oct 1998 04:43:02 PDT." <199810201143.EAA17327@silvia.hip.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Oct 1998 12:22:55 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi folks, > > I'm thinking about implementing an "autorun"-like mechanism for disks. > The idea is to have a script with a known name on a known position > (say, partition `a' on the first BSD slice) which is called during > boot. The script does something to set up the disk (mount some other > partition, or set up a ccd, or something like that). > > However, to do this, I need to be able to write a loop in /etc/rc* to > iterate through all available disks. I guess devfs when fully > implemented will make this easy ("/devfs/da[0-9]*s?a"?) but my > understanding is that it is not ready yet. I could try mounting all > the nodes in /dev (the ones that are not available will presumably > just fail) but with up to 96 disks per system, that could be a lot of > failures. Nah, it's actually pretty trivial. I would, indeed, just iterate over the available nodes in /dev. When devfs comes along, it'll just get more efficient. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 13:13:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA27479 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 13:13:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA27467 for ; Tue, 20 Oct 1998 13:13:49 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id QAA29491; Tue, 20 Oct 1998 16:13:07 -0400 (EDT) Date: Tue, 20 Oct 1998 16:13:07 -0400 (EDT) From: "Matthew N. Dodd" To: Satoshi Asami cc: scsi@FreeBSD.ORG Subject: Re: for i in disks In-Reply-To: <199810201143.EAA17327@silvia.hip.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Oct 1998, Satoshi Asami wrote: > Any ideas? camcontrol devlist \ | grep da \ | awk -F , '{print $2}' \ | ed s/\)\$//g \ | sort \ A bit busy but it appears to work here. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 13:20:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA28177 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 13:20:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28172 for ; Tue, 20 Oct 1998 13:20:26 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id OAA05203; Tue, 20 Oct 1998 14:19:54 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810202019.OAA05203@panzer.plutotech.com> Subject: Re: for i in disks In-Reply-To: <199810201143.EAA17327@silvia.hip.berkeley.edu> from Satoshi Asami at "Oct 20, 98 04:43:02 am" To: asami@cs.berkeley.edu (Satoshi Asami) Date: Tue, 20 Oct 1998 14:19:54 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi Asami wrote... > Hi folks, > > I'm thinking about implementing an "autorun"-like mechanism for disks. > The idea is to have a script with a known name on a known position > (say, partition `a' on the first BSD slice) which is called during > boot. The script does something to set up the disk (mount some other > partition, or set up a ccd, or something like that). > > However, to do this, I need to be able to write a loop in /etc/rc* to > iterate through all available disks. I guess devfs when fully > implemented will make this easy ("/devfs/da[0-9]*s?a"?) but my > understanding is that it is not ready yet. I could try mounting all > the nodes in /dev (the ones that are not available will presumably > just fail) but with up to 96 disks per system, that could be a lot of > failures. > > I could do something like > > grep 'da[^ ]* at ahc' /var/run/dmesg.boot > > but it sometimes overlaps other messages and it also appears to be > very incomplete on some machines. [ ... ] > (There are 42 disks on this machine.) > > Any ideas? > > Satoshi (I know I know, one of these days I'll actually implement something) Well, there are several ways you can do this. The first question is whether you want to do this for just CAM-accessible disks, or for all disks in the system. If you just want a listing of CAM-accessible disks, I've attached a program that will do that. 'camcontrol devlist' will also list all CAM devices. The attached program takes as arguments the peripheral names you're interested in. e.g.: {roadwarrior:/usr/home/ken/src/camtest:41:0} ./devmatch da da0 da1 {roadwarrior:/usr/home/ken/src/camtest:42:0} ./devmatch da cd da0 da1 cd0 {roadwarrior:/usr/home/ken/src/camtest:43:0} ./devmatch da cd pass da0 da1 cd0 pass0 pass1 pass2 It's also available here: ftp://ftp.kdm.org/pub/FreeBSD/cam/devmatch.c Notice that the peripheral names passed in are ORed in and compsed into a matching expression. You can also do much more complicated matching expressions if you want. (You can even match against inquiry patterns, just like the kernel quirk matching code does.) I plan on adding code similar to 'devmatch.c' to camcontrol at some point. It'll hopefully take advantage of more of the transport layer matching functionality, though. If you want to get a listing of all disks, SCSI, IDE, etc., you'll need to get that from the devstat(9) code. There's a program here to dump out all the devstat structures: ftp://ftp.kdm.org/pub/FreeBSD/cam/ds.c The devstat structures have the device name and unit number for each device. They also have flags indicating what type of device it is (direct access, sequential access, cdrom), the interface (IDE, SCSI or other), and whether or not it's a passthrough device. (The passthrough device flag allows you to figure out what the underlying device type is, rather than just that the peripheral driver in question is a passthrough driver.) iostat(8), systat(1) and vmstat(8) use matching code from the devstat(3) library to build matching expressions. You can probably look at the ds.c program above, iostat, and the devstat library to get an idea of how to do what you want to do using the devstat code. So, depending on whether you want just SCSI disks, or all disks, there are different alternatives you can use. And, unlike grepping through the dmesg information, these actually give deterministic results. :) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 13:22:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA28411 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 13:22:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28401 for ; Tue, 20 Oct 1998 13:22:12 -0700 (PDT) (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca9-115.ix.netcom.com [209.109.236.115]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id NAA16548; Tue, 20 Oct 1998 13:21:42 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.8.8/8.6.9) id NAA19725; Tue, 20 Oct 1998 13:21:39 -0700 (PDT) Date: Tue, 20 Oct 1998 13:21:39 -0700 (PDT) Message-Id: <199810202021.NAA19725@silvia.hip.berkeley.edu> To: mike@smith.net.au CC: scsi@FreeBSD.ORG In-reply-to: <199810201922.MAA00566@dingo.cdrom.com> (message from Mike Smith on Tue, 20 Oct 1998 12:22:55 -0700) Subject: Re: for i in disks From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Nah, it's actually pretty trivial. I would, indeed, just iterate over * the available nodes in /dev. When devfs comes along, it'll just get * more efficient. Well yes, but what I meant to say was that there are 96 available nodes in /dev due to wired down devices, but the number in each machine could be as little as 16. That's not very efficient. ;) Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 13:26:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA28888 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 13:26:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28883 for ; Tue, 20 Oct 1998 13:26:03 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id OAA05317; Tue, 20 Oct 1998 14:25:30 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810202025.OAA05317@panzer.plutotech.com> Subject: Re: for i in disks In-Reply-To: from ken at "Oct 20, 98 02:19:54 pm" To: ken@panzer.plutotech.com (ken) Date: Tue, 20 Oct 1998 14:25:30 -0600 (MDT) Cc: asami@cs.berkeley.edu, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM908915130-5283-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM908915130-5283-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote... > If you just want a listing of CAM-accessible disks, I've attached a program > that will do that. 'camcontrol devlist' will also list all CAM devices. > The attached program takes as arguments the peripheral names you're > interested in. e.g.: I neglected to attach the program. Here it is, and it's also available here: ftp://ftp.kdm.org/pub/FreeBSD/cam/devmatch.c Ken -- Kenneth Merry ken@plutotech.com --ELM908915130-5283-0_ Content-Type: text/plain Content-Disposition: attachment; filename=devmatch.c Content-Description: devmatch.c Content-Transfer-Encoding: 7bit /* * Copyright (c) 1998 Kenneth D. Merry. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id$ */ #include #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char **argv) { union ccb ccb; int bufsize, i, opt; struct periph_match_pattern *match_pat; int fd; if ((fd = open("/dev/xpt0", O_RDWR)) == -1) err(1, "couldn't open /dev/xpt0"); bzero(&(&ccb.ccb_h)[1], sizeof(struct ccb_dev_match)); ccb.ccb_h.func_code = XPT_DEV_MATCH; bufsize = sizeof(struct dev_match_result) * 100; ccb.cdm.match_buf_len = bufsize; ccb.cdm.matches = (struct dev_match_result *)malloc(bufsize); ccb.cdm.num_matches = 0; if (argc == 1) { ccb.cdm.num_patterns = 1; ccb.cdm.pattern_buf_len = sizeof(struct dev_match_pattern); ccb.cdm.patterns = (struct dev_match_pattern *)malloc( sizeof(struct dev_match_pattern)); ccb.cdm.patterns[0].type = DEV_MATCH_PERIPH; match_pat = &ccb.cdm.patterns[0].pattern.periph_pattern; match_pat->flags = PERIPH_MATCH_ANY; } else { ccb.cdm.pattern_buf_len = sizeof(struct dev_match_pattern) * (argc - 1); ccb.cdm.patterns = (struct dev_match_pattern *)malloc( ccb.cdm.pattern_buf_len); for (i = 0; (i < 100) && (--argc > 0); i++) { ccb.cdm.num_patterns++; ccb.cdm.patterns[i].type = DEV_MATCH_PERIPH; match_pat = &ccb.cdm.patterns[i].pattern.periph_pattern; match_pat->flags = PERIPH_MATCH_NAME; snprintf(match_pat->periph_name, DEV_IDLEN, "%s", argv[argc]); } } do { if (ioctl(fd, CAMIOCOMMAND, &ccb) == -1) err(1, "error sending CAMIOCOMMAND ioctl"); if ((ccb.ccb_h.status != CAM_REQ_CMP) || ((ccb.cdm.status != CAM_DEV_MATCH_LAST) && (ccb.cdm.status != CAM_DEV_MATCH_MORE))) { fprintf(stderr, "got CAM error %#x, CDM error %d\n", ccb.ccb_h.status, ccb.cdm.status); exit(1); } for (i = 0; i < ccb.cdm.num_matches; i++) { switch(ccb.cdm.matches[i].type) { case DEV_MATCH_PERIPH: { struct periph_match_result *periph_result; periph_result = &ccb.cdm.matches[i].result.periph_result; fprintf(stdout, "%s%d\n", periph_result->periph_name, periph_result->unit_number); break; } default: fprintf(stderr, "unknown match type %#x\n", ccb.cdm.matches[i].type); break; } } /* re-set the number of matches */ ccb.cdm.num_matches = 0; } while ((ccb.ccb_h.status == CAM_REQ_CMP) && (ccb.cdm.status == CAM_DEV_MATCH_MORE)); close(fd); return(0); } --ELM908915130-5283-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 20 13:28:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA29263 for freebsd-scsi-outgoing; Tue, 20 Oct 1998 13:28:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA29250; Tue, 20 Oct 1998 13:28:34 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA00961; Tue, 20 Oct 1998 13:32:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810202032.NAA00961@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: asami@FreeBSD.ORG (Satoshi Asami) cc: mike@smith.net.au, scsi@FreeBSD.ORG Subject: Re: for i in disks In-reply-to: Your message of "Tue, 20 Oct 1998 13:21:39 PDT." <199810202021.NAA19725@silvia.hip.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Oct 1998 13:32:51 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > * Nah, it's actually pretty trivial. I would, indeed, just iterate over > * the available nodes in /dev. When devfs comes along, it'll just get > * more efficient. > > Well yes, but what I meant to say was that there are 96 available > nodes in /dev due to wired down devices, but the number in each > machine could be as little as 16. That's not very efficient. ;) I wouldn't be losing any sleep over as few as 80 failed system calls. How many times do you call select()? Seriously; trying to find any "better" solution is just silly. It's not as if it takes any time for the system to work out that the disk you've tried to open doesn't exist. If you get ENXIO then it's either not there or not online and you move on. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 21 06:36:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17766 for freebsd-scsi-outgoing; Wed, 21 Oct 1998 06:36:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17756 for ; Wed, 21 Oct 1998 06:36:31 -0700 (PDT) (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sjx-ca115-21.ix.netcom.com [207.223.162.85]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id FAA17712; Wed, 21 Oct 1998 05:57:05 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.8.8/8.6.9) id FAA27266; Wed, 21 Oct 1998 05:57:02 -0700 (PDT) Date: Wed, 21 Oct 1998 05:57:02 -0700 (PDT) Message-Id: <199810211257.FAA27266@silvia.hip.berkeley.edu> To: ken@plutotech.com CC: ken@panzer.plutotech.com, scsi@FreeBSD.ORG In-reply-to: <199810202025.OAA05317@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: for i in disks From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * I neglected to attach the program. Here it is, and it's also available * here: Thanks, I tried it but it doesn't compile here (system is too old, I guess). Until I upgrade the system (which I plan to do soon), I'll just try mounting them all. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 21 06:45:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19150 for freebsd-scsi-outgoing; Wed, 21 Oct 1998 06:45:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA19135 for ; Wed, 21 Oct 1998 06:45:04 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id NAA05267; Wed, 21 Oct 1998 13:00:21 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id HAA16820; Wed, 21 Oct 1998 07:02:47 +0200 (CEST) (envelope-from andreas) Message-ID: <19981021070246.B16559@klemm.gtn.com> Date: Wed, 21 Oct 1998 07:02:46 +0200 From: Andreas Klemm To: Mike Smith Cc: de-bsd-questions@DE.FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: what do you need in FreeBSD 2.2.7 kernel to burn cd's using cdrecord ? References: <19981020075743.A2732@klemm.gtn.com> <199810200630.XAA02327@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.93.2i In-Reply-To: <199810200630.XAA02327@dingo.cdrom.com>; from Mike Smith on Mon, Oct 19, 1998 at 11:30:45PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 2.2.7-STABLE SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I forgot to append an s behind tsize, so I tried to write hundreds of Mbyte onto some MB's ... Thanks to you, ktrace and Jörg Schilling ! -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 21 09:16:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA05409 for freebsd-scsi-outgoing; Wed, 21 Oct 1998 09:16:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA05402; Wed, 21 Oct 1998 09:16:36 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id KAA09830; Wed, 21 Oct 1998 10:16:09 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810211616.KAA09830@panzer.plutotech.com> Subject: Re: for i in disks In-Reply-To: <199810211257.FAA27266@silvia.hip.berkeley.edu> from Satoshi Asami at "Oct 21, 98 05:57:02 am" To: asami@FreeBSD.ORG (Satoshi Asami) Date: Wed, 21 Oct 1998 10:16:09 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi Asami wrote... > * I neglected to attach the program. Here it is, and it's also available > * here: > > Thanks, I tried it but it doesn't compile here (system is too old, I > guess). Until I upgrade the system (which I plan to do soon), I'll > just try mounting them all. You can still do something with the devstat information. That code has been in the cam tree since last year... Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 21 09:47:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08950 for freebsd-scsi-outgoing; Wed, 21 Oct 1998 09:47:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tbuswell.ne.mediaone.net (tbuswell.ne.mediaone.net [24.128.24.62]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA08942; Wed, 21 Oct 1998 09:47:18 -0700 (PDT) (envelope-from tbuswell@tbuswell.ne.mediaone.net) Received: (from tbuswell@localhost) by tbuswell.ne.mediaone.net (8.9.1/8.8.8) id MAA00848; Wed, 21 Oct 1998 12:45:54 -0400 (EDT) (envelope-from tbuswell) From: Ted Buswell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 Oct 1998 12:45:54 -0400 (EDT) To: asami@FreeBSD.ORG (Satoshi Asami) Cc: scsi@FreeBSD.ORG Subject: Re: for i in disks In-Reply-To: <199810211257.FAA27266@silvia.hip.berkeley.edu> References: <199810202025.OAA05317@panzer.plutotech.com> <199810211257.FAA27266@silvia.hip.berkeley.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13870.3656.235875.122481@tbuswell.ne.mediaone.net> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I haven't been following this thread closely, but unless I'm missing something, I think the Disk_Names() function from libdisk(3) is what you're looking for.. [assuming compiled C code is OK]. -Ted /* gcc x.c -ldisk */ extern char **Disk_Names(); main() { char **p = Disk_Names(); while(*p) puts(*p++); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 21 13:09:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03745 for freebsd-scsi-outgoing; Wed, 21 Oct 1998 13:09:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from second.dialup.access.net (lsmarso.dialup.access.net [166.84.254.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03732 for ; Wed, 21 Oct 1998 13:09:38 -0700 (PDT) (envelope-from larry@marso.com) Received: (from larry@localhost) by second.dialup.access.net (8.9.1/8.8.8) id QAA23579 for freebsd-scsi@freebsd.org; Wed, 21 Oct 1998 16:07:05 -0400 (EDT) (envelope-from larry) Date: Wed, 21 Oct 1998 16:07:05 -0400 From: "Larry S. Marso" To: freebsd-scsi@FreeBSD.ORG Subject: 8 bit external devices, 2940UW Message-ID: <19981021160705.B23158@marso.com> Mime-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary=v9Ux+11Zm5mwPlX6 X-Mailer: Mutt 0.94.13i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-encrypted Version: 1 --v9Ux+11Zm5mwPlX6 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: /AFhBuz9B5iBrxpo6nXALC/pOUmUezXK hQEMA8uecfyBRpbdAQf/cBgpziVUDWMLvvfrio6Sv/7eAEbZruOYEBxe+9pmbgfS +xehMDW1LuKki8jQd4ZIOmZlozFzisgCEscUWk40iPUuOZSujXF1EwGXzkd7gRdA NoUEobiG31MclEG25qrxwut7tGut9RyR4l3YusbouBVPylNVV3WfNpBM7YExIXcI 08fMkpd+27R3AYsmXtZwQ4ZaBn5tLjuVa46wIaGZtZFV2RaIfNoc7L0unIUdX1yU m73Q3EDQ2R/1drlXpWcjH1AQQSuZZsZfXWhGEwGGEh8DYpTVOzFIlhhMWYxZtjNF 3PcFW3EYzVn913mbdMA4Qw4+YiPDAOfAtsY4RysvfoUBDAO48TIXcJ2JYQEH/iL1 PcedS93nAug6sG/0ktupZwhtRfB60Qtkuw2vUxW/W3CPpf4iC5I0gyu+/tcTCSLq AU/+uuVe6Lnc5FTt00XWzJwVqJHPeRYU1DBt/kGFx0nO7a6xcT0aUfW1wAnms4NR 2eG2VLy7AI4cd7WYCZSAWHDwpzvXyEaDgrR7ErjtyqqgQmOzcPEQx9R32WdN0IgL 2MIsJwFw+DtQVS0jUQBEsq7GBHlCvyGwqJev0IWAtXsNjcarjJocY9uBv4LeuoCk UK9Xf1WdWFq6LupJRFBtQ/HP0K4G18+V26K4fSro2+10yzAnG53Ybc8FSHBHXW5g rVf7KG5nIcSDutdTOZOlAQDvmBdBx1I6VM47Yo2fuRy5SLv3W6ylpPm9+d+cC20S Pss6wEduzNLrCx0/+NIhwlZcPlceh6IXIKr6Cs4qSKVvhOqOhzNSgOJFEKRF5QDp iUQULsHSydesbMdJhItjjVBMcbd3JeU/QiL6KBK+IBYjtjAQQyu4bhhmMZjqhMmx jH6u/o+kZMQGoUGYzpPwfeBKINiApOCSBg8pUQmCzQGEyt6FauEwu4p3BGmJlhCG aOt+H/Pr2toiKtlhaFno5Otp4d+0yhRlNs2IT76scFF6KcDdck2PhI4IpkZOcder lpOnG9FibX0ZtFCcXQPtKC/OLB89klJdgelysvBMhD6Q =tsYs -----END PGP MESSAGE----- --v9Ux+11Zm5mwPlX6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 21 16:03:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA24057 for freebsd-scsi-outgoing; Wed, 21 Oct 1998 16:03:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA24052 for ; Wed, 21 Oct 1998 16:03:01 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA02693; Wed, 21 Oct 1998 16:06:49 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810212306.QAA02693@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: geoff@ugc.ab.ca cc: scsi@FreeBSD.ORG Subject: Re: Unable to install 3.0-RELEASE with an AHA1542 ! In-reply-to: Your message of "Wed, 21 Oct 1998 16:50:51." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Oct 1998 16:06:49 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I've encountered the same problem with a 1540B. it would appear to be a timing > issue. If I put lots of debug messages in and boot verbose then it will > some times see the card. > This is a machine that has been ruuning Freebsd CURRENT > for some time. About a week ago I picked up the latest patches and now new > kernel's will not see the controller. This is filed as PR/8340 You want to be talking to Warner Losh about this; moved to -scsi where it belongs. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 00:47:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA06960 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 00:47:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA06951 for ; Thu, 22 Oct 1998 00:47:48 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zWFRq-0001gH-00; Thu, 22 Oct 1998 01:46:18 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id BAA09786; Thu, 22 Oct 1998 01:46:13 -0600 (MDT) Message-Id: <199810220746.BAA09786@harmony.village.org> To: Mike Smith Subject: Re: Unable to install 3.0-RELEASE with an AHA1542 ! Cc: geoff@ugc.ab.ca, scsi@FreeBSD.ORG In-reply-to: Your message of "Wed, 21 Oct 1998 16:06:49 PDT." <199810212306.QAA02693@dingo.cdrom.com> References: <199810212306.QAA02693@dingo.cdrom.com> Date: Thu, 22 Oct 1998 01:46:13 -0600 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199810212306.QAA02693@dingo.cdrom.com> Mike Smith writes: : You want to be talking to Warner Losh about this; moved to -scsi where : it belongs. Yes. I've been able to kinda recreate Geoff's problem. I've had problems with the 1542B that I got from FTL when writing to scsi disks, but reads from scsi cdroms work fine. Geogg's problem, as he communicated it to me, was that sometimes it would not even detect correctly. Justing gave me several ideas on how to correct this problem. I'm looking into it as time allows... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 00:48:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA07033 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 00:48:26 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA07021 for ; Thu, 22 Oct 1998 00:48:22 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zWFTH-0001gL-00; Thu, 22 Oct 1998 01:47:47 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id BAA09813; Thu, 22 Oct 1998 01:48:22 -0600 (MDT) Message-Id: <199810220748.BAA09813@harmony.village.org> To: Mike Smith Subject: Re: Unable to install 3.0-RELEASE with an AHA1542 ! Cc: freebsd@magnet.geophysik.tu-freiberg.de, freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Wed, 21 Oct 1998 11:32:12 PDT." <199810211832.LAA01141@dingo.cdrom.com> References: <199810211832.LAA01141@dingo.cdrom.com> Date: Thu, 22 Oct 1998 01:48:22 -0600 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199810211832.LAA01141@dingo.cdrom.com> Mike Smith writes: : The 1542 is supported by the 'aha' driver, and this driver will search : all of the supported locations for the 1542. The problem, I think, is that older 1542's don't like the probe code in the aha driver. It appears to be a timing related issue. Warenr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 03:28:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA17983 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 03:28:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA17978 for ; Thu, 22 Oct 1998 03:28:23 -0700 (PDT) (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sjx-ca115-21.ix.netcom.com [207.223.162.85]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id DAA18942; Thu, 22 Oct 1998 03:27:53 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.8.8/8.6.9) id DAA21738; Thu, 22 Oct 1998 03:27:50 -0700 (PDT) Date: Thu, 22 Oct 1998 03:27:50 -0700 (PDT) Message-Id: <199810221027.DAA21738@silvia.hip.berkeley.edu> To: tbuswell@mediaone.net CC: scsi@FreeBSD.ORG In-reply-to: <13870.3656.235875.122481@tbuswell.ne.mediaone.net> (message from Ted Buswell on Wed, 21 Oct 1998 12:45:54 -0400 (EDT)) Subject: Re: for i in disks From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * I haven't been following this thread closely, but unless I'm * missing something, I think the Disk_Names() function from libdisk(3) * is what you're looking for.. [assuming compiled C code is OK]. * -Ted * * /* gcc x.c -ldisk */ * extern char **Disk_Names(); * main() { * char **p = Disk_Names(); * while(*p) puts(*p++); * } Oooh. This is very nice and simple. :) It works on my recent CAM system but not on my old one. Thanks though. By the way, in case anyone is interested, this is what I came up with. I can now move disks around and still have them mounted correctly. :) /etc/rc.disk (called from /etc/rc, right after clean_var): === # # disk setups # # $Id$ # dir=/mnt echo "setting up disks" found=0 for i in /dev/sd*a; do if ! mount -o ro $i $dir 2>/dev/null; then continue fi if [ -f $dir/autorun.sh ]; then echo "running $i's autorun script" found=1 sh $dir/autorun.sh $dir $i fi if ! umount $dir; then echo "error unmounting $i" exit 1 fi done if [ $found = 1 -a -f /var/run/autorun.sh ]; then echo "running /var/run/autorun.sh" sh /var/run/autorun.sh fi echo "done" === For a simple mount, this will be the autorun.sh: === #!/bin/sh unit=$(/usr/bin/printf "%02x" $(echo $2 | sed -e 's./dev/sd..' -e 's/a$//')) fsck -p /dev/dsk/sd${unit}h || exit 1 mount /dev/dsk/sd${unit}h /MOUNTPOINT === The black magic about unit and /dev/dsk is our peciluar setup -- I have all disks wired to "B * 16 + I" where B is bus number and I is SCSI ID, and have a bunch of symlinks from /dev/dsk/sd* to /dev/sd* to make them easier to read. The links in /dev/dsk/sd* are named as "sdBIP" where I is represented in hexadecimal (0-f) and P is the partition name. For a ccd array, use this one: === #!/bin/sh unit=$(/usr/bin/printf "%02x" $(echo $2 | sed -e 's./dev/sd..' -e 's/a$//')) echo /dev/dsk/sd${unit}h > /tmp/$(cat $1/diskid)-$(cat $1/ccdno) cp $1/mountpoint /tmp/$(cat $1/ccdno)-mountpoint cp $1/var-autorun.sh /var/run/autorun.sh === and this var-autorun.sh: === #!/bin/sh for ccd in 0 1; do if [ $(echo $(echo /tmp/*-ccd$ccd | wc -w)) = 13 ]; then echo "found 13 disks, making ccd" echo -n "ccd$ccd 128 none " > /tmp/ccd.conf echo $(cat /tmp/*-ccd$ccd) >> /tmp/ccd.conf ccdconfig -Cv -f /tmp/ccd.conf fsck -p /dev/ccd${ccd}c mount /dev/ccd${ccd}c $(cat /tmp/ccd${ccd}-mountpoint) rm -f /tmp/ccd.conf /tmp/ccd${ccd}-mountpoint rm -f /tmp/*-ccd${ccd} else echo "error" fi done === Obviously things like "13" and "128" should be on the disks somewhere, we need better error handling, but it's a start. :) Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 04:42:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA23583 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 04:42:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from magnet.geophysik.tu-freiberg.de (magnet.geophysik.tu-freiberg.de [139.20.128.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA23573 for ; Thu, 22 Oct 1998 04:42:27 -0700 (PDT) (envelope-from freebsd@magnet.geophysik.tu-freiberg.de) Received: (from freebsd@localhost) by magnet.geophysik.tu-freiberg.de (8.9.1/8.7.3) id NAA01966; Thu, 22 Oct 1998 13:41:23 +0200 (CEST) From: Holm Tiffe Message-Id: <199810221141.NAA01966@magnet.geophysik.tu-freiberg.de> Subject: Re: Unable to install 3.0-RELEASE with an AHA1542 ! In-Reply-To: <199810220747.BAA09802@harmony.village.org> from Warner Losh at "Oct 22, 98 01:47:26 am" To: imp@village.org (Warner Losh) Date: Thu, 22 Oct 1998 13:41:23 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG Reply-To: freebsd@magnet.geophysik.tu-freiberg.de X-Mailer: ELM [version 2.4ME+ PL26 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <199810210714.JAA02191@magnet.geophysik.tu-freiberg.de> Holm Tiffe writes: > : system (Gigabyte GA-6BA w. 128MB SDRAM) and an old 1542. > > How oldis the 1542? Is it a 1542A or B? If a B, what are your jumper > settings? I've had two reports of older 1542 cards not probing now... > > Warner > In my case (the first mail came from me) this is an 1542B with the newer 64 Head BIOS. The Settings are 0x330,0xcc00,irq11,drq5, floppy disabled. After some manual fiddeling the the port,irq and drq in the kernels config (in cli mode) the card is working. The autodetect is failing badly. Holm -- ******************************************************************************* * Holm Tiffe holm@geophysik.tu-freiberg.de * * Freiberger Strasse 24 * * 09600 Kleinschirma, Germany Microsoft is not the Answer - * * Tel.: 49 3731 74233 Microsoft is the Question, * * UUCP: 49 3731 73719 unicorn!holm and the Answer is no ! * ******************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 07:32:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA07133 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 07:32:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mojo.calyx.net (mojo.calyx.net [208.132.136.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA07113 for ; Thu, 22 Oct 1998 07:32:30 -0700 (PDT) (envelope-from rjb@netpr.com) Received: (qmail 20534 invoked by uid 1005); 22 Oct 1998 14:31:56 -0000 Date: Thu, 22 Oct 1998 07:31:56 -0700 (PDT) From: "Robert J. Brown" X-Sender: rjb@mojo.calyx.net To: freebsd-scsi@FreeBSD.ORG Subject: Panic in 3.0 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 Issue: bt0 driver crashes the kernel FreeBSD Version: 3.0-RELEASE Hardware: Buslogic BT-958 (Firmware 5.07B, BIOS 4.96I) Kernel: Default kernel that ships with 3.0-RELEASE Reproducable: Intermittently How it happened: I did a "find / -perm -4000 -print > SUID" and it caused a panic. Details: Ok, the first time this happened I didn't have savecore enabled. The first panic produced this message: panic bt0: too few mailboxes or to many ccbs syncing disks... 263 263 263 263 263 263 263 263 263 263 263 263 263 263 giving up So I rebooted, did the same find command, and it crashed again with the same panic message, but this time it produced a screenful of information along with it. Unfortunately, I couldn't get it captured before it automatically rebooted (it said it would wait for a keypress but it didn't.) I tried a few more times, and it completed the find command successfully without panicing the system. Unfortunately I didn't have savecore turned on when this happened (it's on now.) Anyway, here's a small breakdown of the hardware: 400MHz Intel PII (the real, boxed chip) Asus P2B Motherboard Mylex BT-958 PCI Quantum Atlas QM39100TD-SW 9GB UW Drive at ID 0 Sony SDT-9000 DAT Drive at ID 4 CDROM at ID 2 (2) Intel EtherExpress Pro 100B PCI NIC cards After a few days, I did get the following messages: (da0:bt0:0:0:0): CCB 0xf56c1b80 - timed out (da0:bt0:0:0:0): CCB 0xf56c1b80 - timed out bt0: No longer in timeout (da0:bt0:0:0:0): CCB 0xf56c2380 - timed out (da0:bt0:0:0:0): CCB 0xf56c2380 - timed out bt0: No longer in timeout Not quite sure what they mean. Anyway, I know this isn't much help but at least it identifies that a possible problem does exist :) Once I get a savecore, I'll post a backtrace and a location to grab my newly compiled kernel (I recompiled against -current, but it doesn't look like the bt stuff has changed.) One interesting thing is that this BT-958 came with newer firmware and bios revisions than the publicly availble flashed versions (5.07b/4.96i is what it came with.) I don't know if that is significant, but it did make me wonder... -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 08:44:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12377 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 08:44:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA12369 for ; Thu, 22 Oct 1998 08:44:15 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zWMta-0001uy-00; Thu, 22 Oct 1998 09:43:26 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id JAA11868; Thu, 22 Oct 1998 09:44:04 -0600 (MDT) Message-Id: <199810221544.JAA11868@harmony.village.org> To: freebsd@magnet.geophysik.tu-freiberg.de Subject: Re: Unable to install 3.0-RELEASE with an AHA1542 ! Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Thu, 22 Oct 1998 13:41:23 +0200." <199810221141.NAA01966@magnet.geophysik.tu-freiberg.de> References: <199810221141.NAA01966@magnet.geophysik.tu-freiberg.de> Date: Thu, 22 Oct 1998 09:44:04 -0600 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199810221141.NAA01966@magnet.geophysik.tu-freiberg.de> Holm Tiffe writes: : In my case (the first mail came from me) this is an 1542B with the : newer 64 Head BIOS. The Settings are 0x330,0xcc00,irq11,drq5, floppy disabled. : After some manual fiddeling the the port,irq and drq in the kernels config : (in cli mode) the card is working. The autodetect is failing badly. What, exactly, did you change in the kernel config stuff? Also, and I know this is asking a lot, can you tell me what jumpers you have enabled/disabled on your card? I'm starting to think that these failures may be related to some of the more obscure jumpers on the board being set differently than the card that I have here for testing. I'm curious, what devices do you have on the scsi bus and how well are they working? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 09:08:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA14980 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 09:08:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cse.psu.edu (claven.cse.psu.edu [130.203.3.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14972 for ; Thu, 22 Oct 1998 09:08:47 -0700 (PDT) (envelope-from keefe@cse.psu.edu) Received: from remulak.cse.psu.edu (keefe@remulak.cse.psu.edu [130.203.30.18]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id MAA27281; Thu, 22 Oct 1998 12:08:03 -0400 (EDT) From: Thomas F Keefe Received: (from keefe@localhost) by remulak.cse.psu.edu (8.8.8/8.8.7) id MAA05083; Thu, 22 Oct 1998 12:08:02 -0400 (EDT) Date: Thu, 22 Oct 1998 12:08:02 -0400 (EDT) Message-Id: <199810221608.MAA05083@remulak.cse.psu.edu> To: patton@sysnet.net Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Sequential Disk I/O Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > if you study how the big boys liek Oracle do it, they use block sizes in > excess of 8kb. Depending on how big your disks are 32kb blocks are > considered more reasonable. What they do is fit multiple database "blocks" > or records into a logical block. I suggest a vastly bigger blocksize than > 512bytes if you're serious about performance. By using large blocks I can approximate the performance of sequentail access. I may have a seek and rotation penalty at the beginning of the transfer, but that one penalty is amortized over a large number of sectors. This may be my only choice if I cannot solve this problem. At this point I have spent a lot of time and become very curious about this. What I was hoping to get from this group, was something like: (1) It is impossible to avoid the rotational latency when issuing writes to adjacent sectors on a SCSI disk because the time required between the completion of one command and the start of the next is a significant fraction of the time it takes for a 5400RPM disk platter to rotate. Thus, even with large strides, the next command comes to late. This, makes only one access per revolution possible. or; (2) Modern SCSI drives (by default) access an entire track on both reads and writes. Thus, only one access is possible per revolution. This default behavior can be disabled through the mode page as follows ... or; (3) I have done this, the trick is to ... If anyone could rule out (1) or (2) above, that would also help a lot. Any enlightenment you can offer on this topic will be appreciated. Tom Keefe Dept. of Computer Science and Engineering Penn State keefe@cse.psu.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 09:34:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18131 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 09:34:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from chuq.com ([209.220.44.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18124 for ; Thu, 22 Oct 1998 09:34:29 -0700 (PDT) (envelope-from chuq@chuq.com) Received: from chuq.com (localhost [127.0.0.1]) by chuq.com (8.8.8/8.8.8) with ESMTP id JAA07616 for ; Thu, 22 Oct 1998 09:33:54 -0700 (PDT) From: Chuck Silvers To: freebsd-scsi@FreeBSD.ORG Subject: problem with plextor cdrom Date: Thu, 22 Oct 1998 09:33:54 -0700 Message-ID: <7613.909074034@chuq.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hiya, I'm getting this error when trying to mount a windows98 cd on my freebsd-current (of the 17th) pc with a Plextor PX-32TSi cdrom drive: # mount -t cd9660 /dev/cd0c /mnt cd9660: /dev/cd0c: Invalid argument at the same time, I get this message in the syslog: Oct 22 09:27:02 pc /kernel: dscheck: negative b_blkno -1090556912 The scsi controller is the onboard AIC7890 of an ASUS P2B-S motherboard. Mounting this same cd worked just fine using an older Sony scsi cdrom on the same machine before I got the plextor drive. The plextor drive can mount this cd just fine when the drive is hooked up to a sparc. anyone seen this before? -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 09:58:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA20980 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 09:58:29 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA20974 for ; Thu, 22 Oct 1998 09:58:27 -0700 (PDT) (envelope-from moorthy@cs.unc.edu) Received: from buzzard.cs.unc.edu (moorthy@buzzard.cs.unc.edu [152.2.129.17]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id MAA28939 for ; Thu, 22 Oct 1998 12:57:56 -0400 (EDT) Date: Thu, 22 Oct 1998 12:57:55 -0400 (EDT) From: Arun Moorthy To: scsi@FreeBSD.ORG Subject: CAM driver problem ? 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 Greetings. I've been using 19980716 Snapshot(2.2.7 CAM) for a while now on multiple machines with absolutely no problems. This morning 4 of my machines (identical and freebsd installed on the same day) are giving me a "Data-path parity error at seqaddr=0x17d" and rebooting/panicing. I saw mail on this issue in freebsd-scsi, but couldnt find a solution to the problem anywhere. Is there a solution? If so, could someone send me a pointer? Also, Pls CC a reply to my email. Any suggestions would be much appreciated. TIA, -arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 10:44:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28592 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 10:44:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28577 for ; Thu, 22 Oct 1998 10:44:20 -0700 (PDT) (envelope-from moorthy@cs.unc.edu) Received: from buzzard.cs.unc.edu (moorthy@buzzard.cs.unc.edu [152.2.129.17]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id NAA01021 for ; Thu, 22 Oct 1998 13:43:48 -0400 (EDT) Date: Thu, 22 Oct 1998 13:43:48 -0400 (EDT) From: Arun Moorthy To: freebsd-scsi@FreeBSD.ORG Subject: CAM driver problem ? 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 [Sent this message to scsi@freebsd.org. Actually wanted to send to freebsd-scsi@freebsd.org. If they're the same, apologies for the second copy.] Greetings. I've been using 19980716 Snapshot(2.2.7 CAM) for a while now on multiple machines with absolutely no problems. This morning 4 of my machines (identical and freebsd installed on the same day) are giving me a "Data-path parity error at seqaddr=0x17d" and rebooting/panicing. I saw mail on this issue in freebsd-scsi, but couldnt find a solution to the problem anywhere. Is there a solution? If so, could someone send me a pointer? Also, Pls CC a reply to my email. Any suggestions would be much appreciated. TIA, -arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 12:11:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11463 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 12:11:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11458 for ; Thu, 22 Oct 1998 12:11:06 -0700 (PDT) (envelope-from George_Morgan@BayNetworks.COM) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/09/30-E) with ESMTP id MAA12918 for ; Thu, 22 Oct 1998 12:10:26 -0700 (PDT) Received: from ns2.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id PAA05381 for ; Thu, 22 Oct 1998 15:10:18 -0400 (EDT) Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com) by ns2.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA26383; Thu, 22 Oct 98 15:10:19 EDT for freebsd-scsi@freebsd.org Received: from gmorgan-pc (gmorgan-pc.corpwest.baynetworks.com [134.177.69.176]) by sc-mail2.corpwest.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for ; Thu, 22 Oct 1998 12:10:05 -0700 From: George_Morgan@BayNetworks.COM (George Morgan) To: freebsd-scsi@FreeBSD.ORG Date: Thu, 22 Oct 1998 12:07:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Support for Buslogic BT-930... X-Mailer: Pegasus Mail for Win32 (v3.01b) Message-Id: <19981022191005.AAA18160@sc-mail2.corpwest.BayNetworks.com@gmorgan-pc.corpwest.baynetworks.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone know if the Buslogic driver supports the BT-930??? George Morgan Bay Networks gmorgan@baynetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 12:38:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16000 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 12:38:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15992 for ; Thu, 22 Oct 1998 12:38:11 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id NAA10825; Thu, 22 Oct 1998 13:30:32 -0600 (MDT) Date: Thu, 22 Oct 1998 13:30:32 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810221930.NAA10825@narnia.plutotech.com> To: "Robert J. Brown" cc: scsi@FreeBSD.ORG Subject: Re: Panic in 3.0 Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Issue: bt0 driver crashes the kernel > FreeBSD Version: 3.0-RELEASE > Hardware: Buslogic BT-958 (Firmware 5.07B, BIOS 4.96I) > Kernel: Default kernel that ships with 3.0-RELEASE > Reproducable: Intermittently > How it happened: I did a "find / -perm -4000 -print > SUID" and it caused a > panic. > Details: > > Ok, the first time this happened I didn't have savecore enabled. The first > panic produced this message: > > panic bt0: too few mailboxes or to many ccbs Hmm. Where there any other messages leading up to this? This is almost certainly a firmware bug. The card has mailbox space for 192 concurrent commands, your device configuration will allow at most ~68 concurrent commands, yet we ran into a mailbox that was left in the 'busy' state which should never happen. Leonard Zubkoff's BusLogic page also lists your firmware as problematic. Take a look at: http://www.dandelion.com/Linux/BusLogic.html for more information. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 12:39:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16195 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 12:39:48 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA16184 for ; Thu, 22 Oct 1998 12:39:45 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id NAA10833; Thu, 22 Oct 1998 13:32:22 -0600 (MDT) Date: Thu, 22 Oct 1998 13:32:22 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810221932.NAA10833@narnia.plutotech.com> To: Arun Moorthy cc: scsi@FreeBSD.ORG Subject: Re: CAM driver problem ? Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > This morning 4 of my machines (identical and freebsd installed on the same > day) are giving me a "Data-path parity error at seqaddr=0x17d" and > rebooting/panicing. You need the change from rev 1.2 of ahc_pci.c in current. I'm working on a new 2.2-stable CAM snapshot and hope to release it this weekend. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 15:28:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12601 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 15:28:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA12587 for ; Thu, 22 Oct 1998 15:28:48 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA01402; Thu, 22 Oct 1998 15:31:39 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810222231.PAA01402@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Thomas F Keefe cc: patton@sysnet.net, freebsd-scsi@FreeBSD.ORG Subject: Re: Sequential Disk I/O In-reply-to: Your message of "Thu, 22 Oct 1998 12:08:02 EDT." <199810221608.MAA05083@remulak.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Oct 1998 15:31:39 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > if you study how the big boys liek Oracle do it, they use block sizes in > > excess of 8kb. Depending on how big your disks are 32kb blocks are > > considered more reasonable. What they do is fit multiple database "blocks" > > or records into a logical block. I suggest a vastly bigger blocksize than > > 512bytes if you're serious about performance. > > By using large blocks I can approximate the > performance of sequentail access. I may have > a seek and rotation penalty at the beginning > of the transfer, but that one penalty is > amortized over a large number of sectors. > This may be my only choice if I cannot > solve this problem. At this point I have > spent a lot of time and become very curious > about this. It looks like you're suffering from some major misconceptions about the relative performance and behaviour of the I/O subsystem. This makes it difficult to relate to your questions, because they're deeply founded on these misconceptions. To start with, you have to understand that I/O transactions move along queues, and the behaviour of each of these queues is different, and many of these behaviours are dependant upon other factors. > > What I was hoping to get from this group, was > something like: > (1) It is impossible to avoid the rotational > latency when issuing writes to adjacent > sectors on a SCSI disk because the time > required between the completion of one command > and the start of the next is a significant > fraction of the time it takes for a 5400RPM disk > platter to rotate. Thus, even with large > strides, the next command comes to late. > This, makes only one access per revolution > possible. Issues of rotational latency are completely irrelevant. The decoupling between the system and the media on a SCSI disk is complete. > or; > > (2) Modern SCSI drives (by default) access an > entire track on both reads and writes. > Thus, only one access is possible per revolution. > This default behavior can be disabled through > the mode page as follows ... The second does not follow from the first, but again, this is completely irrelevant. > Any enlightenment you can offer on this topic will be > appreciated. Without meaning offense, the amount of "enlightenment" required to correct your understandings on the topic is beyond the scope of any single email, and will probably only be gathered over a number of years of experience. To answer what I recall as being your original question as succinctly as possible; there is an effectively fixed overhead involved in any given I/O transaction. So in moving data, there are two costs: - tD, the time taken to move the data itself. - tO, the overhead. tD is directly proportional to the amount of data involved, so for any given amount of data, tD is constant. tO is effectively fixed per transaction. Thus, if you move the data in small chunks, total tO is proportionally larger than if you use large chunks. When you come to compute throughput for a single consumer, there's another cost: - tL, the latency time (time between making the response and receiving an answer which is not accounted for in tO). tL varies significantly depending on load, but it also has a fixed component per transaction. Thus, again, smaller chunks mean a larger total tL. tO and tL are significant for many of the queues, and so the system does what it can to coalesce as many read/write operations as possible, as well as caching, etc. in order reduce them where possible. However, it is in your application that you can make the best performance optimisations because only your application can know its access behaviour in advance. If you're interested in pursuing this further, you might want to start by studying the FreeBSD I/O subsystem. Then you'll want to look at how SCSI works, starting with a typical SCSI host adapter, the SCSI standard and perhaps some high-level documentation for a SCSI disk. Please don't think you can apply something like the early-70's vintage disk theory from eg. Tanenbaum to modern disk systems; this will only confuse you. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 17:13:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26597 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 17:13:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26590; Thu, 22 Oct 1998 17:13:41 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id RAA07804; Thu, 22 Oct 1998 17:13:12 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id RAA12923; Thu, 22 Oct 1998 17:13:11 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA19305; Thu, 22 Oct 1998 17:13:09 -0700 (PDT) From: Don Lewis Message-Id: <199810230013.RAA19305@salsa.gv.tsc.tdk.com> Date: Thu, 22 Oct 1998 17:13:09 -0700 X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 14, 9:01am, Nate Williams wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Bottom line is that by default FreeBSD w/SoftUpdates is more *unstable* } now with CAM than it was w/out CAM for 99% of the users. That's certainly not my experience. Once the initiate_write_filepage and newdirrem panics were fixed, my system has been completely stable. Since then only filesystem damage that has happened is when I had write caching enabled and I was playing with the reset button. I'm very anxious to upgrade our pre-CAM systems here because of stability problems I've been having with them. On Oct 14, 9:02am, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Neither the old SCSI code nor the } new CAM code has ever modified the caching behavior of the devices attached } on the bus. My position on this is that we should *never* modify device } mode parameters unless instructed to do so by the end user. I agree. } If the user } community insists that we add a warning about the cache being enabled, now, } after years of silently ignoring the effects of the cache on filesystem } integrity, so be it. My opinion is that if this was a problem in practice, } we'd have heard about it by now from our user community. I think much of the user community is uneducated on some of the finer points and also has low expectations. On Oct 14, 9:18am, Nate Williams wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Up till this point, we never had any FS code that attempted to deal with } 'crashing' robustly. Not true. Unless you were using async mounts, the filesystem code was careful to order certain writes so that there would not be any unrecoverable damage. } I for one knew that if my machine crashed, an fsck } was expected and it was going to repair my disk. It still is necessary to recover lost resources, though in theory it could be done after the filesystem is mounted. With softupdates, it isn't strictly necessary to do it before mount time because blocks are no longer marked free in the bitmaps before they have been deallocated. The traditional code wasn't quite so careful in the interest of performance, since fsck could easily fix the bitmaps. } This is no longer the } case with SoftUpdates, so what was previously attributed to 'the crash' } can now be more fine-tuned to 'write caching screwed up' or 'I have a } bad power supply which breaks my drive when I hit the reset button' or } even simply 'when I lose power, write-caching spams my disk'. These problems can damage the filesystem in ways that fsck can't recover without data loss. On May 13, 5:54pm, "Christopher R. Bowman" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } At 11:08 AM 10/14/98 -0700, Julian Elischer wrote: } >7/ to allow for this to be achieved easily, there should be an easy way to } >ensure that the write cache is turned off. Possibly as simple as } >a good example in camctl.8 . ... and a note in the handbook reminding folks of the importance of doing this when building a system or adding new disks. } Could we make this a mount time option, say if -wc to turn write caching on, } -nowc to turn it off, and if neither flag is present use whatever the drive is } already set for. My initial request was for the opposite, a warning if write caching was on, to keep folks from silently shooting themselves in the foot. This avoids the problems that Justin mentioned in his reply. This could even be tweaked to warn you if write caching was not in the state you desired. However, I now think this isn't the way to go. See below. On Oct 14, 4:54pm, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } The moral of this story is that everyone should decide what kinds of } performance/safety tradeoffs they are willing to make and design their } systems accordingly. Yes, this sounds like an issue that should be discussed in the handbook. On Oct 14, 7:15pm, David Kelly wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Before you fight it too much more, replace the power supply. I've cured } a number of "impossible" problems with a new power supply. One } spectacular example was a Power Mac 7200/120. Crash, crash, crash. } Sometimes it would run for 30 minutes. Sometimes overnight. Technician } replaced everything several times over a couple of weeks. Everything } but the plastic case and the power supply. I insisted on a new PS the } last time back. And it worked like a charm. In normal operation, the system is absolutely stable. The only problem occurs when I hit reset while the system is busy. If I turn off write caching, I haven't gotten any filesystem damage even then. } Power supply filter capacitors age with heat. And lose their ability to } be good capacitors. No telling what kind of noise is on your DC power } wires inside the case. Your PS could be generating a spike of its own } on RESET when/if something suddenly demands a lot of current. Or if } something suddenly quits demanding the current it was using. The capacitors "should" be good since the system is fairly new and has generally only been lightly used. If the problem was load regulation, then I'd expect the problem to also occur during heavy use, but I haven't seen any problems like that. One can never be sure though. On Oct 14, 11:19pm, Dan Nelson wrote: } Subject: Re: filesystem safety and SCSI disk write caching } I humbly submit the following script, to be added to /etc/security, or } periodic/weekly, /etc/rc, or wherever. It's dependant on the exact } output of "camcontrol inquiry" and "camcontrol modepage", but does the } job. Ah, a positive contribution to this thread! I was coming to the conclusion that a script to check this was probably the way to go when I saw your message. You can also use something like this to check some of the other SCSI control bits to make sure things like error recovery are also properly configured. I'd also combine this with a scan for new grown defects. I'd recommend running the script both at boot time and from cron to detect any potential problems. Using a script also avoids kernel bloat. On Oct 16, 6:09am, David Kelly wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Why not? It might be interesting to put a recording voltmeter such as a } digital storage oscilloscope on the HD power leads when Don is punching } the reset. No telling what kind of voltage surges are generated when } the load on the power supply is altered. Ok, so the chapter in the handbook about SCSI write caching will recommend connecting a recording voltmeter to the power supply and monitoring it under varying load (including when the reset button is hit) to make sure there are no problems before enabling write caching? Repeat this procedure after adding new hardware and periodically as the power supply capacitors age. And you still can't prove that you don't have a power supply problem lurking, since you can't prove a negative. All you can state is that the power looks clean under the conditions that you tested. Problems still might occur when the machine is placed in service. On Oct 16, 7:26pm, Ollivier Robert wrote: } Subject: Re: filesystem safety and SCSI disk write caching } I agree. HP-UX has a kernel option to enable write caching and it is off by } default. Not that I'd advocate to do things like HP-SUX but I think it is } better to be safe. I think you are thinking of NFS write caching. An NFS server isn't supposed to tell the NFS client that the write has completed until the data is on stable storage (so the client can retry the write if the server crashes and reboots before the write is done). This badly hurts performance unless the client is able to handle a lot of outstanding write requests. } A lot if not all of the modern drives are shipped with WCE == 1 though. That didn't use to be the case. I think this changed a few years ago. Benchmarkitis no doubt. I didn't even think to check this since I haven't been putting too many new drives in service lately. On Oct 17, 1:48pm, Bill Vermillion wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Guido van Rooij recently said: } > I always thought a drive will always be able to flush its write cache } > to disk, even when power fails. } } Not all do. The high-end IBM's do/did. They used the inertia of } the spinnging platters to generate enough current to flush the } buffers to disk. There aren't a lot of drives that do it. That could be pretty hard to do with the sizeable caches on drives these days. Quite a few seeks could be necessary which are expensive in terms of power. I also suspect that the necessary circuitry to recover the energy from the platters to power the rest of the drive adds a significant amount of cost to the drive, and the drive manufacturers are under quite a lot of cost pressure these days. This would be a disincentive to include a seldom used feature. On Oct 19, 12:04pm, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } >, *after* you explain why } >Don Lewis is seeing the empirical behaviour he is seeing, in } >contradiction to your claims of what's possible and not. } } I've already given my opinion on this. I believe the Hawk is seeing } a power glitch or temporary power loss when the reset switch is hit and } so the contents of the cache are lost. I have never said that the } behavior that Don Lewis is seeing is 'not possible', only that, for } the drive in question, the reset causing cache corruption is not likely. If this problem caused by a load related power glitch, then it is possible to get silent filesystem corruption in normal operation if write caching is enabled, since cached writes could get lost and the driver might never notice. Without write caching, the driver would see transactions timing out and it would have an opportunity to retry the writes, preventing filesystem damage and data loss, and the driver would no doubt complain verbosely. This would alert the operator to the hardware problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 20:40:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA15281 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 20:40:26 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA15276; Thu, 22 Oct 1998 20:40:25 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id VAA25994; Thu, 22 Oct 1998 21:39:53 -0600 (MDT) Message-Id: <199810230339.VAA25994@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Thu, 22 Oct 1998 17:13:09 PDT." <199810230013.RAA19305@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Oct 1998 21:33:03 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} I've already given my opinion on this. I believe the Hawk is seeing >} a power glitch or temporary power loss when the reset switch is hit and >} so the contents of the cache are lost. I have never said that the >} behavior that Don Lewis is seeing is 'not possible', only that, for >} the drive in question, the reset causing cache corruption is not likely. > >If this problem caused by a load related power glitch, then it is >possible to get silent filesystem corruption in normal operation if >write caching is enabled, since cached writes could get lost and the >driver might never notice. The driver will notice as the drive will notice an issue a Unit Attention response the next time you touch it. Or is your point that you won't necessarily access the device again and so never see that the device saw a loss in power? There has been quite a bit of debate on how UAs should be handled. The original CAM driver was *very* conservative and returned all pending I/O with EIO, marked the pack invalid, and refused to take any I/O unless the device cycled through final close. This ensures that if the device or pack is replaced that you don't spam different media or even if the media is the same, make the problem worse by attempting to continue after some transactions were irrevocably lost. This was considered too disruptive and since a permanent solution could not be developed for 3.0R, the UA code was disabled. The correct solution likely requires better communication to the FS or user layer so that pack validation of some sort can occur. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 22:10:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21437 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 22:10:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21428; Thu, 22 Oct 1998 22:10:37 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA09885; Thu, 22 Oct 1998 22:10:06 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA17645; Thu, 22 Oct 1998 22:10:05 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA19810; Thu, 22 Oct 1998 22:10:04 -0700 (PDT) From: Don Lewis Message-Id: <199810230510.WAA19810@salsa.gv.tsc.tdk.com> Date: Thu, 22 Oct 1998 22:10:03 -0700 In-Reply-To: "Justin T. Gibbs" "Re: filesystem safety and SCSI disk write caching" (Oct 22, 9:33pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Justin T. Gibbs" , Don Lewis Subject: Re: filesystem safety and SCSI disk write caching Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 22, 9:33pm, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } The driver will notice as the drive will notice an issue a Unit Attention } response the next time you touch it. Or is your point that you won't } necessarily access the device again and so never see that the device } saw a loss in power? I forgot about Unit Attention. At least it will be obvious that the filesystem is potentially corrupted and there is a hardware problem that needs fixing. } There has been quite a bit of debate on how UAs should be handled. The } original CAM driver was *very* conservative and returned all pending } I/O with EIO, marked the pack invalid, and refused to take any I/O unless } the device cycled through final close. This ensures that if the device } or pack is replaced that you don't spam different media or even if the } media is the same, make the problem worse by attempting to continue after } some transactions were irrevocably lost. This was considered too } disruptive and since a permanent solution could not be developed for } 3.0R, the UA code was disabled. The correct solution likely requires } better communication to the FS or user layer so that pack validation } of some sort can occur. If write caching is disabled and if it is possible to verify that the media is the same, it should be safe to retry all the lost I/O transactions. If write caching is off and softupdates is in use, your original solution still works ok even if someone yanks the media out of the drive. The filesystem will still be intact, though it might not be totally up to date. If write caching is on, you're basically SOL if you see a Unit Attention. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 22:16:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22105 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 22:16:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22095; Thu, 22 Oct 1998 22:16:54 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id XAA29829; Thu, 22 Oct 1998 23:16:23 -0600 (MDT) Message-Id: <199810230516.XAA29829@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: "Justin T. Gibbs" , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Thu, 22 Oct 1998 22:10:03 PDT." <199810230510.WAA19810@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Oct 1998 23:09:33 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} There has been quite a bit of debate on how UAs should be handled. The >} original CAM driver was *very* conservative and returned all pending >} I/O with EIO, marked the pack invalid, and refused to take any I/O unless >} the device cycled through final close. This ensures that if the device >} or pack is replaced that you don't spam different media or even if the >} media is the same, make the problem worse by attempting to continue after >} some transactions were irrevocably lost. This was considered too >} disruptive and since a permanent solution could not be developed for >} 3.0R, the UA code was disabled. The correct solution likely requires >} better communication to the FS or user layer so that pack validation >} of some sort can occur. > >If write caching is disabled and if it is possible to verify that the >media is the same, it should be safe to retry all the lost I/O >transactions. You can't retry the transactions without first determining that the media is the same as before. We can't do that right now without manual intervention which shouldn't be the case. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 22 23:17:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27801 for freebsd-scsi-outgoing; Thu, 22 Oct 1998 23:17:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from magnet.geophysik.tu-freiberg.de (magnet.geophysik.tu-freiberg.de [139.20.128.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27793 for ; Thu, 22 Oct 1998 23:17:19 -0700 (PDT) (envelope-from freebsd@magnet.geophysik.tu-freiberg.de) Received: (from freebsd@localhost) by magnet.geophysik.tu-freiberg.de (8.9.1/8.7.3) id IAA04424; Fri, 23 Oct 1998 08:16:28 +0200 (CEST) From: Holm Tiffe Message-Id: <199810230616.IAA04424@magnet.geophysik.tu-freiberg.de> Subject: Re: Unable to install 3.0-RELEASE with an AHA1542 ! In-Reply-To: <199810221544.JAA11868@harmony.village.org> from Warner Losh at "Oct 22, 98 09:44:04 am" To: imp@village.org (Warner Losh) Date: Fri, 23 Oct 1998 08:16:27 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG Reply-To: freebsd@magnet.geophysik.tu-freiberg.de X-Mailer: ELM [version 2.4ME+ PL26 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <199810221141.NAA01966@magnet.geophysik.tu-freiberg.de> Holm Tiffe writes: > : In my case (the first mail came from me) this is an 1542B with the > : newer 64 Head BIOS. The Settings are 0x330,0xcc00,irq11,drq5, floppy disabled. > : After some manual fiddeling the the port,irq and drq in the kernels config > : (in cli mode) the card is working. The autodetect is failing badly. > > What, exactly, did you change in the kernel config stuff? Hmm ok, port aha0 0x330 irq aha0 11 drq aha0 5 dis ... most of network cards, psm0, mcd0, scd0, matcdc0, wcd0, wcd1, wt0 etc. irq ed0 9 q y > > Also, and I know this is asking a lot, can you tell me what jumpers > you have enabled/disabled on your card? I'm starting to think that > these failures may be related to some of the more obscure jumpers on > the board being set differently than the card that I have here for > testing. Grml, lots of work ! :-) Let's try... Pin 1 on the left side J7: :|::::|: (You got it ?) J5: |::::::|:|:|: J6: |:::| J8: :|:|:|:: J9: :|:::|::::|::: The Terminators and the Fuse are installed. Currently this is an "updated" 1542B with the bios version 3.20 to work with the ncr like C/H/S translation. I have another one with version 3.10, the same behavior. There is also no difference, when I use the cards on my old test board with an ST486/80 Processor and only 8 Meg of RAM. > I'm curious, what devices do you have on the scsi bus and how well are > they working? The only connected target is currently an 400MB Disk from Seagate (from a SUN SparcII) the ST1480N. How well working ? Like an very old disk :-) (I can hear the workers in the drive loudly) But the drive is ok and was working flawlessly in the SparcII. It was only replaced because of the noisy spindle motor it has. Holm -- ******************************************************************************* * Holm Tiffe holm@geophysik.tu-freiberg.de * * Freiberger Strasse 24 * * 09600 Kleinschirma, Germany Microsoft is not the Answer - * * Tel.: 49 3731 74233 Microsoft is the Question, * * UUCP: 49 3731 73719 unicorn!holm and the Answer is no ! * ******************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 01:44:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA08216 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 01:44:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from newsguy.com (smtp.newsguy.com [207.211.168.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA08208 for ; Fri, 23 Oct 1998 01:44:36 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com ([133.8.10.23]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id BAA16570 for ; Fri, 23 Oct 1998 01:44:00 -0700 (PDT) Message-ID: <3630426F.92CA4267@newsguy.com> Date: Fri, 23 Oct 1998 17:46:39 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: RAID SCSI cards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can anyone send me a list of the SCSI cards supporting RAID level 1 and 5 for which a driver is available on FreeBSD? Because of CAM, both 2.7-STABLE and 3.0 answers are welcome. Please cc any answers to this question directly to me (dcs@newsguy.com), since I do not subscribe to this list. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 08:05:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07398 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 08:05:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mojo.calyx.net (mojo.calyx.net [208.132.136.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA07393 for ; Fri, 23 Oct 1998 08:05:55 -0700 (PDT) (envelope-from rjb@netpr.com) Received: (qmail 11419 invoked by uid 1005); 23 Oct 1998 15:05:14 -0000 Date: Fri, 23 Oct 1998 08:05:14 -0700 (PDT) From: "Robert J. Brown" X-Sender: rjb@mojo.calyx.net To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: Panic in 3.0 In-Reply-To: <199810221930.NAA10825@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Ok, the first time this happened I didn't have savecore enabled. The first > > panic produced this message: > > > > panic bt0: too few mailboxes or to many ccbs > > Hmm. Where there any other messages leading up to this? Nope. I was sitting at console, did the find command, and boom it just panic'd with that message. It happened that one time, I rebooted, it happened again (that's when it printed a screenful of info I couldn't capture), and it hasn't happened since. That doesn't say much because the machine is idle and isn't in production yet. > This is almost certainly a firmware bug. The card has mailbox > space for 192 concurrent commands, your device configuration will > allow at most ~68 concurrent commands, yet we ran into a mailbox > that was left in the 'busy' state which should never happen. > Leonard Zubkoff's BusLogic page also lists your firmware as > problematic. Take a look at: Hmm interesting. I'm going to move back to 5.06J firmware and give that a shot. I've used FreeBSD on 5.06I in the past and it's been very solid. Of course, that was pre-3.0. Thanks for the information. -Rob -- Robert J. Brown Phone: 310-737-0096 Network Presence, LLC Fax: 310-737-0196 Computer Security Consultant Email: rjb@netpr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 09:20:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15937 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 09:20:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp-gw.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15927 for ; Fri, 23 Oct 1998 09:20:11 -0700 (PDT) (envelope-from George_Morgan@BayNetworks.COM) Received: from mailhost.BayNetworks.COM ([141.251.211.49]) by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/09/30-E) with ESMTP id JAA13363 for ; Fri, 23 Oct 1998 09:16:23 -0700 (PDT) Received: from ns2.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id SAA05859 for ; Fri, 23 Oct 1998 18:15:45 +0200 (MET DST) Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com) by ns2.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA27143; Fri, 23 Oct 98 12:15:46 EDT for freebsd-scsi@freebsd.org Received: from gmorgan-pc (gmorgan-pc.corpwest.baynetworks.com [134.177.69.176]) by sc-mail2.corpwest.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for ; Fri, 23 Oct 1998 09:15:32 -0700 From: George_Morgan@BayNetworks.COM (George Morgan) To: freebsd-scsi@FreeBSD.ORG Date: Fri, 23 Oct 1998 09:13:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Buslogic BT-930 support... X-Mailer: Pegasus Mail for Win32 (v3.01b) Message-Id: <19981023161532.AAA4224@sc-mail2.corpwest.BayNetworks.com@gmorgan-pc.corpwest.baynetworks.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does the Buslogic driver in FreeBSD 2.2.7 (or later) support the BT- 930?? ***Is this question off topic?*** George Morgan Bay Networks gmorgan@baynetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 09:56:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19490 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 09:56:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19483 for ; Fri, 23 Oct 1998 09:56:52 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id KAA22752; Fri, 23 Oct 1998 10:56:11 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810231656.KAA22752@panzer.plutotech.com> Subject: Re: Buslogic BT-930 support... In-Reply-To: <19981023161532.AAA4224@sc-mail2.corpwest.BayNetworks.com@gmorgan-pc.corpwest.baynetworks.com> from George Morgan at "Oct 23, 98 09:13:19 am" To: George_Morgan@BayNetworks.COM (George Morgan) Date: Fri, 23 Oct 1998 10:56:11 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org George Morgan wrote... > Does the Buslogic driver in FreeBSD 2.2.7 (or later) support the BT- > 930?? No, sorry. I think support is planned for the flashpoint cards at some point, but I don't know when that will happen. > ***Is this question off topic?*** Nope. It's just that most people don't know the answer. (I had to look in the man page..) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 11:28:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27685 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 11:28:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27680 for ; Fri, 23 Oct 1998 11:28:47 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA00498; Fri, 23 Oct 1998 11:32:27 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810231832.LAA00498@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Daniel C. Sobral" cc: freebsd-scsi@FreeBSD.ORG Subject: Re: RAID SCSI cards In-reply-to: Your message of "Fri, 23 Oct 1998 17:46:39 +0900." <3630426F.92CA4267@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Oct 1998 11:32:26 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Can anyone send me a list of the SCSI cards supporting RAID level 1 > and 5 for which a driver is available on FreeBSD? Because of CAM, both > 2.7-STABLE and 3.0 answers are welcome. > > Please cc any answers to this question directly to me > (dcs@newsguy.com), since I do not subscribe to this list. You probably want to look at cards from DPT, or alternatively any SCSI:SCSI RAID controller. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 14:43:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13990 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 14:43:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from second.dialup.access.net (lsmarso.dialup.access.net [166.84.254.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13983; Fri, 23 Oct 1998 14:43:36 -0700 (PDT) (envelope-from larry@marso.com) Received: (from larry@localhost) by second.dialup.access.net (8.9.1/8.8.8) id RAA03053; Fri, 23 Oct 1998 17:40:49 -0400 (EDT) (envelope-from larry) Date: Fri, 23 Oct 1998 17:40:49 -0400 From: "Larry S. Marso" To: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: solved: writing multisession cd9660 Message-ID: <19981023174049.A3035@marso.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.13i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I didn't find a clear explanation in the mailing list archives or elsewhere of how to create a multisession ISO_9660 CD. I succeeded as follows: #1 Create the first session mkisofs -R -o cdimage.raw /dir1 ^^^^^ The directory of files you're backing up ^^^^^^^^^^^ The first iso_9660 image file cdrecord -v -multi dev=2,0 speed=2 cdimage.raw ^^^^^ instructs cdrecord to anticipate multiple sessions so that disk fix permits later additions I've found it's important to **save** the cdimage.raw file (which is downright inconvenient ... please share with me any alternatives you uncover), #2 Create the second image You need to feed mkisofs information on the most recently recorded session, in order to create the next session. This is an *undocumented* mkisofs command. cdrecord -msinfo dev=2,0 This command outputs the 2048 block information on the most recent session. E.g.: 0,15715 mkisofs -R -M cdimage.raw -C 0,15715 -o cdimage2.raw /dir2 ^^ An undocumented option. Include the range of the most recent session ^^ mkisofs seems to require that you feed it the actual image from the most recent session. If that's days or weeks ago, this is pretty inefficient. I couldn't satisfy mkisofs by offering it the mounted cd session created with cdimage.raw. Maybe there's a way to recreate cdimage.raw from the mounted disk? Solutions appreciated! You can now: cdrecord -v -multi dev=2,0 speed=2 cdimage2.raw #3 Mounting the resulting sessions You can use tosha -i or cdcontrol info to get the start sectors of the included sessions. Then mount as follows: mount_cd9660 -s 15716 /dev/cd0c /mnt ^^^^^^^^ This is the start sector of the second session, which is hereby mounted. Limitations: - You can't mount more than one session simultaneously - There's no support I've found for creating some sort of directory of all sessions. Best of luck! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 23 18:31:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01653 for freebsd-scsi-outgoing; Fri, 23 Oct 1998 18:31:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01647 for ; Fri, 23 Oct 1998 18:31:42 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.1/8.9.1) with SMTP id SAA02064 for ; Fri, 23 Oct 1998 18:31:11 -0700 (PDT) Date: Fri, 23 Oct 1998 18:31:10 -0700 (PDT) From: Chris Timmons To: freebsd-scsi@FreeBSD.ORG Subject: Thrashing CAM on SMP 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 tried recently to reproduce the problems Mark Murray has with CAM & SMP (panic with X going and lots of filesystem activity.) I couldn't panic, but I did have the machine wedge with recurring, non-recoverable device tiemouts on the system and swap disks. The machine is a server and doesn't have a workstation video card. Of course, I forgot BREAK_TO_DEBUGGER, so I couldn't get a dump. Using an SMP -CURRENT from just before the 3.0 release, I set up 3 256M bonnies on different spindles, an md5 of a 280MB file, and a 'make -j 12 buildworld' - all in loops to repeat over and over. The buildworld also unmounted, newfs-ed and remounted /usr/obj after each turn. The machine is a dual-PII 266 tyan tiger. The system lasted for a couple days with a load average between 5 and 12. The activity lights on the 3 bonnie drives were almost always solid green and the box sounded like a popcorn popper. at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus1 target 0 lun 0 (pass2,da2) at scbus1 target 1 lun 0 (pass3,da3) at scbus1 target 4 lun 0 (pass4,da4) During the time it was alive, the bonnies were running on da2, da3, and da4. The only trouble I had were device timeouts on the firmware-buggy Atlas-II, and an occasional hiccup on the SEAGATES. I'm using 40MHZ xfer rates and adaptec cables with the active terminators - drive termination off. midtest3:/root#> grep BDR /var/log/messages Oct 21 04:16:13 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 21 05:27:29 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 21 14:44:18 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 21 17:10:31 midtest3 /kernel: (da3:ahc1:0:1:0): BDR message in message buffer Oct 21 17:11:31 midtest3 /kernel: (da3:ahc1:0:1:0): BDR message in message buffer Oct 21 17:12:30 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 21 19:47:07 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 21 20:04:24 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 01:38:54 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 02:51:36 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 04:10:12 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 05:51:51 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 07:41:04 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 07:47:00 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 09:22:32 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 10:50:59 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 11:06:40 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 13:34:20 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 15:12:07 midtest3 /kernel: (da2:ahc1:0:0:0): BDR message in message buffer Oct 22 15:13:07 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 15:28:40 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 15:43:34 midtest3 /kernel: (da2:ahc1:0:0:0): BDR message in message buffer Oct 22 15:44:34 midtest3 /kernel: (da2:ahc1:0:0:0): BDR message in message buffer Oct 22 15:45:34 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 16:18:28 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB Oct 22 17:06:45 midtest3 /kernel: (da4:ahc1:0:4:0): Queuing a BDR SCB When it finally died, I'd swear it was telling me that da0 and/or da1 kept timing out - messages to the serial console which I of course didn't trap. The machine would respond to pings and print out the BDR timeout messages, but would not do anything else, so it was apparantly stuck at a fairly high spl. I'm getting up-to-date, noticing Ken's mega-commit recently. I'll be able to break in with ddb now, and can take a dump if the situation re-occurs. The system is in a mega rack-mount case with multiple cooling fans blowing directly on the drives which were cool to the touch during the middle of the run, so I don't think we overheated. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 24 05:54:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA09656 for freebsd-scsi-outgoing; Sat, 24 Oct 1998 05:54:07 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA09640; Sat, 24 Oct 1998 05:54:04 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt3-227.HiWAAY.net [208.147.146.227]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id HAA19730; Sat, 24 Oct 1998 07:53:29 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id HAA19254; Sat, 24 Oct 1998 07:24:19 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199810241224.HAA19254@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Message from Don Lewis of "Thu, 22 Oct 1998 17:13:09 PDT." <199810230013.RAA19305@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Oct 1998 07:24:19 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis writes: > On Oct 16, 6:09am, David Kelly wrote: > } Subject: Re: filesystem safety and SCSI disk write caching > > } Why not? It might be interesting to put a recording voltmeter such as a > } digital storage oscilloscope on the HD power leads when Don is punching > } the reset. No telling what kind of voltage surges are generated when > } the load on the power supply is altered. > > Ok, so the chapter in the handbook about SCSI write caching will recommend > connecting a recording voltmeter to the power supply and monitoring it > under varying load (including when the reset button is hit) to make sure > there are no problems before enabling write caching? Repeat this procedure > after adding new hardware and periodically as the power supply capacitors > age. > > And you still can't prove that you don't have a power supply problem > lurking, since you can't prove a negative. All you can state is that > the power looks clean under the conditions that you tested. Problems > still might occur when the machine is placed in service. I do not suggest use of a recording voltmeter or storage oscilloscope be mentioned in the handbook. My point is that in this day of generic PC parts the quality control aspect is getting skipped. While an individual PS may be tested for UL compliance, and the MB for FCC emissions, the system as a package gets skipped. The Mom & Pop PC Shop doesn't have a clue other than, "We sold 100 systems this month and you are the only one complaining." Testing for FCC emissions levels and UL safety on entire systems are nil. For data loss on reset you can prove a negative if you can reproduce the failure during your measurements. If you sample the voltage often enough thru the event then you can prove there was not a slower voltage spike causing the problem. My 50 MHz DSO says it samples at 100 MHz. Its much harder to monitor current as your power leads would have to be cut or some other inline calibrated very low value resistor inserted. But to do a complete job current should be monitored also. Current measurements will tell you if the load on the PS is changing. If current doesn't change significantly thru a RESET, then this is not a boundary condition. Problems are usually found at the boundaries. My suggestion of monitoring the power supply came from the nature of this list and its participants where skills and tools are above average. And the result is a product which is well above average and suitable for use by those who never give it a second thought. A handbook entry on SCSI caching is a attempt to cause such as second thought in more than would have in the first place. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 24 07:32:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA15591 for freebsd-scsi-outgoing; Sat, 24 Oct 1998 07:32:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cs.tku.edu.tw (power.cs.tku.edu.tw [163.13.128.241]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA15586 for ; Sat, 24 Oct 1998 07:32:04 -0700 (PDT) (envelope-from winsdom@gmail.gcn.net.tw) Received: from adagio by cs.tku.edu.tw (SMI-8.6/SMI-SVR4) id WAA04808; Sat, 24 Oct 1998 22:22:47 +0800 Message-Id: <199810241422.WAA04808@cs.tku.edu.tw> From: "Winsdom Chen" To: freebsd-scsi@FreeBSD.ORG Date: Sat, 24 Oct 1998 22:28:29 +0800 Subject: Re: Buslogic BT-930 support... In-reply-to: <199810231656.KAA22752@panzer.plutotech.com> References: <19981023161532.AAA4224@sc-mail2.corpwest.BayNetworks.com@gmorgan-pc.corpwest.baynetworks.com> from George Morgan at "Oct 23, 98 09:13:19 am" X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > George Morgan wrote... > > Does the Buslogic driver in FreeBSD 2.2.7 (or later) support the BT- > > 930?? > > No, sorry. I think support is planned for the flashpoint cards at some > point, but I don't know when that will happen. Well,Linux has suppored BT-930 since kernel 2.0.29(perhaps). Could core team port that from Linux? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 24 09:54:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23491 for freebsd-scsi-outgoing; Sat, 24 Oct 1998 09:54:48 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA23486 for ; Sat, 24 Oct 1998 09:54:46 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id KAA00129; Sat, 24 Oct 1998 10:47:21 -0600 (MDT) Date: Sat, 24 Oct 1998 10:47:21 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810241647.KAA00129@narnia.plutotech.com> To: "Winsdom Chen" cc: scsi@FreeBSD.ORG Subject: Re: Buslogic BT-930 support... Newsgroups: pluto.freebsd.scsi In-Reply-To: <19981023161532.AAA4224@sc-mail2.corpwest.BayNetworks.com@gmorgan-pc.corpwest.baynetworks.com> <199810241422.WAA04808@cs.tku.edu.tw> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199810241422.WAA04808@cs.tku.edu.tw> you wrote: >> George Morgan wrote... >> > Does the Buslogic driver in FreeBSD 2.2.7 (or later) support the BT- >> > 930?? >> >> No, sorry. I think support is planned for the flashpoint cards at some >> point, but I don't know when that will happen. > > Well,Linux has suppored BT-930 since kernel 2.0.29(perhaps). > Could core team port that from Linux? The main thing holding this back right now is that I haven't received hardware from Mylex yet. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 24 18:55:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24948 for freebsd-scsi-outgoing; Sat, 24 Oct 1998 18:55:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24941; Sat, 24 Oct 1998 18:55:13 -0700 (PDT) (envelope-from a0074@netcologne.de) Received: from bsd3.scs-koeln.de (dial5-108.netcologne.de [194.8.195.108]) by mail2.netcologne.de (8.8.8/8.8.8) with SMTP id CAA00500; Sun, 25 Oct 1998 02:54:38 +0100 (MET) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 25 Oct 1998 02:41:16 +0100 (CET) From: "R. Luettgen" To: freebsd-bugs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: problems with release 3.0 and SCSI Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, this night I update my box ( K6, 64 MB, 2 GB SCSI Seagate, 1 GB Nec ) from release 2.2.7 to 3.0. The old one runs very good and secure. I use a boot disk. when I boot the box with the 3.0 boot disk it hangs during reprobing. My NEC disk has the ID 0 and the Seagate Barracude has ID 1. I changed the disks and then the machine boots and I can install the whole release. After that I want to fdisk the nec disk, but I cannot. I try : fdisk /dev/rda1 Then the system hangs without any error message. Nothing works. The only thing I can do is turn off the power. The model of the NEC disk is : NEC D3845 0307 ( from dmesg ) Is this a bug ? ---------------------------------- E-Mail: R. Luettgen Date: 25-Oct-98 Time: 02:41:16 This message was sent by XF-Mail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message