From owner-freebsd-scsi Sun Oct 11 06:35:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA26279 for freebsd-scsi-outgoing; Sun, 11 Oct 1998 06:35:48 -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 GAA26264; Sun, 11 Oct 1998 06:35:41 -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 OAA24603; Sun, 11 Oct 1998 14:30:06 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id PAA06890; Sun, 11 Oct 1998 15:09:29 +0200 (CEST) (envelope-from andreas) Message-ID: <19981011150929.A4699@klemm.gtn.com> Date: Sun, 11 Oct 1998 15:09:29 +0200 From: Andreas Klemm To: de-bsd-questions@DE.FreeBSD.ORG Cc: scsi@FreeBSD.ORG, joerg@FreeBSD.ORG Subject: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 ! Finally I bought a TEAC CD burner. Had not much time to look, if it's good supported under FreeBSD, and since it was a gift from a company, I hoped that it rocks well... But, of course, it doesn't ;-) It's only recognized as cdrom under FreeBSD 2.2.7-STABLE. I started hacking two files: --- scsi/scsiconf.c.old Sun Oct 11 14:37:25 1998 +++ scsi/scsiconf.c Sun Oct 11 14:37:56 1998 @@ -431,6 +431,10 @@ "worm", SC_ONE_LU }, { + T_READONLY, T_WORM, T_REMOV, "TEAC", "CD-R55S", "*", + "worm", SC_ONE_LU + }, + { /* That's the Philips drive, in case anybody wonders... */ T_READONLY, T_WORM, T_REMOV, "IMS", "CDD2000*", "*", "worm", SC_ONE_LU --- scsi/worm.c.old Sun Oct 11 14:34:20 1998 +++ scsi/worm.c Sun Oct 11 14:35:20 1998 @@ -206,6 +206,11 @@ hp4020i_prepare_disk, hp4020i_prepare_track, hp4020i_finalize_track, hp4020i_finalize_disk }, + { + "TEAC", "CD-R55S", + hp4020i_prepare_disk, hp4020i_prepare_track, + hp4020i_finalize_track, hp4020i_finalize_disk + }, {0} }; Now it's recognized as (ahc0:6:0): "TEAC CD-R55S 1.0K" type 5 removable SCSI 2 worm0(ahc0:6:0): Write-Once But it doesn't seem to work right as a "HP" device ;-)) Using the example burn script I get these results... root{170} ~andreas sh /usr/share/examples/worm/burncd.sh root.iso dummy Place CD in the worm drive now and press return: wormcontrol: ioctl(WORMIOCPREPDISK): Device not configured wormcontrol: ioctl(WORMIOCPREPTRACK): Device not configured 1894 kilobytes, 1 seconds dd: /dev/rworm0: Device not configured team: guy pid 6879: error on upstream receive team: stop remaining 1 guys team: guy had error wormcontrol: ioctl(WORMIOFIXATION): Device not configured What to do next ? Call TEAC and ask for manuals ??? How can I help ? Andreas /// -- 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 Sun Oct 11 07:09:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28138 for freebsd-scsi-outgoing; Sun, 11 Oct 1998 07:09:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from emmi.physik.TU-Berlin.DE (emmi.physik.TU-Berlin.DE [130.149.160.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA28130; Sun, 11 Oct 1998 07:09:30 -0700 (PDT) (envelope-from ibex@emmi.physik.TU-Berlin.DE) Received: (from ibex@localhost) by emmi.physik.TU-Berlin.DE (8.9.1/8.9.1) id QAA22314; Sun, 11 Oct 1998 16:09:04 +0200 (CEST) (envelope-from ibex) Message-ID: <19981011160904.A22293@physik.TU-Berlin.DE> Date: Sun, 11 Oct 1998 16:09:04 +0200 From: Dirk Froemberg To: Andreas Klemm , de-bsd-questions@DE.FreeBSD.ORG Cc: scsi@FreeBSD.ORG, joerg@FreeBSD.ORG Subject: Re: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work References: <19981011150929.A4699@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <19981011150929.A4699@klemm.gtn.com>; from Andreas Klemm on Sun, Oct 11, 1998 at 03:09:29PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Oct 11, 1998 at 03:09:29PM +0200, Andreas Klemm wrote: > Finally I bought a TEAC CD burner. Had not much time to look, > if it's good supported under FreeBSD, and since it was a gift > from a company, I hoped that it rocks well... > > But, of course, it doesn't ;-) > > It's only recognized as cdrom under FreeBSD 2.2.7-STABLE. > > [...] > > What to do next ? Call TEAC and ask for manuals ??? > How can I help ? Hello Andreas! I use the same device. I would leave the worm device alone since CD-R are no WORM. Have a look at /usr/ports/sysutils/cdrecord instead. It works like a charm. Best regards Dirk -- e-mail: ibex@physik.tu-berlin.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Oct 11 13:25:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA02746 for freebsd-scsi-outgoing; Sun, 11 Oct 1998 13:25:44 -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 NAA02431 for ; Sun, 11 Oct 1998 13:24:16 -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 WAA01432; Sun, 11 Oct 1998 22:23:28 +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 WAA13947; Sun, 11 Oct 1998 22:00:03 +0200 (MET DST) (envelope-from j) Message-ID: <19981011220003.45970@uriah.heep.sax.de> Date: Sun, 11 Oct 1998 22:00:03 +0200 From: J Wunsch To: Andreas Klemm Cc: scsi@FreeBSD.ORG Subject: Re: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work Reply-To: Joerg Wunsch References: <19981011150929.A4699@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19981011150929.A4699@klemm.gtn.com>; from Andreas Klemm on Sun, Oct 11, 1998 at 03:09:29PM +0200 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 Andreas Klemm wrote: > Finally I bought a TEAC CD burner. Had not much time to look, > if it's good supported under FreeBSD, and since it was a gift > from a company, I hoped that it rocks well... Your way didn't have much of a chance to succeed. In order to add support for a new drive to worm(4), you need a little more information about the drive. Stay with cdrecord by now. Kenneth Merry (sp?) once told me that he's going to move worm(4) to CAM some day, this will also be a good chance to rethink some of the original design ideas, and at least the SCSI-3 MMC standard should be supported then, too. (When worm(4) was written, there was no sign of any common standard among the CD-R drive vendors). Given all the other TODO's with CAM, i guess this won't happen really soon now. -- 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 Sun Oct 11 13:26:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03050 for freebsd-scsi-outgoing; Sun, 11 Oct 1998 13:26:56 -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 NAA03030 for ; Sun, 11 Oct 1998 13:26:53 -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 WAA01457; Sun, 11 Oct 1998 22:25:36 +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 WAA13956; Sun, 11 Oct 1998 22:03:23 +0200 (MET DST) (envelope-from j) Message-ID: <19981011220323.59444@uriah.heep.sax.de> Date: Sun, 11 Oct 1998 22:03:23 +0200 From: J Wunsch To: Dirk Froemberg Cc: Andreas Klemm , scsi@FreeBSD.ORG Subject: Re: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work Reply-To: Joerg Wunsch References: <19981011150929.A4699@klemm.gtn.com> <19981011160904.A22293@physik.TU-Berlin.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19981011160904.A22293@physik.TU-Berlin.DE>; from Dirk Froemberg on Sun, Oct 11, 1998 at 04:09:04PM +0200 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 Dirk Froemberg wrote: > I use the same device. I would leave the worm device alone since CD-R > are no WORM. Sure, but then don't forget that worm(4) is just a misnamed CD-R driver only. It has never been designed to support the ancient WORM-type devices at all. The misnomer has historical reasons, since many of the first-generation CD-R devices announced theirselves as `type write-once'. (There was no common standard for them back in 1995, and even now, a CD-ROM drive ``with multi-media extensions'' is nothing i would immediately assume to be a CD-R device, so the poor naming continues.) -- 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 Sun Oct 11 16:56:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07829 for freebsd-scsi-outgoing; Sun, 11 Oct 1998 16:56:18 -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 QAA07817 for ; Sun, 11 Oct 1998 16:56:16 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id RAA19045; Sun, 11 Oct 1998 17:55:53 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810112355.RAA19045@panzer.plutotech.com> Subject: Re: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work In-Reply-To: <19981011220003.45970@uriah.heep.sax.de> from J Wunsch at "Oct 11, 98 10:00:03 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 11 Oct 1998 17:55:53 -0600 (MDT) Cc: andreas@klemm.gtn.com, 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 J Wunsch wrote... > As Andreas Klemm wrote: > > > Finally I bought a TEAC CD burner. Had not much time to look, > > if it's good supported under FreeBSD, and since it was a gift > > from a company, I hoped that it rocks well... > > Your way didn't have much of a chance to succeed. In order to add > support for a new drive to worm(4), you need a little more information > about the drive. > > Stay with cdrecord by now. Kenneth Merry (sp?) once told me that he's > going to move worm(4) to CAM some day, this will also be a good chance > to rethink some of the original design ideas, and at least the SCSI-3 > MMC standard should be supported then, too. (When worm(4) was > written, there was no sign of any common standard among the CD-R drive > vendors). Yeah, I've got a CAM port of the worm(4) driver 70% written, but it struck me that that probably wasn't the right thing to do. (to just blindly port it without re-thinking it) It'll certainly take some thought to figure out how to best support CD-R, CD-RW, and DVD drives natively. I'm pretty sure the support for these drives will probably be through the CD driver, though, and not a worm driver. The "easy" thing to do will be to support the newer drives that conform to the standards, but the more difficult thing to do will be to figure out whether to bother with supporting the older drives that don't really conform to any standards. For now, cdrecord supports a far broader range of hardware than even the old scsi layer supported. (it only supported HP/Philips and Plasmon drives) > Given all the other TODO's with CAM, i guess this won't happen really > soon now. Right. I'm not sure when this will happen. My post-3.0 roadmap is a bit fuzzy right now, so I definitely can't say when it'll happen. 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 11 23:25:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12027 for freebsd-scsi-outgoing; Sun, 11 Oct 1998 23:25:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from silic.one.sci.fi (silic.one.sci.fi [195.74.8.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12022 for ; Sun, 11 Oct 1998 23:25:28 -0700 (PDT) (envelope-from anttik@silic.one.sci.fi) Received: (from anttik@localhost) by silic.one.sci.fi (8.8.8/8.8.8) id JAA24274; Mon, 12 Oct 1998 09:25:14 +0300 (EEST) (envelope-from anttik) To: freebsd-scsi@FreeBSD.ORG Subject: RAID experiences From: Antti Kaipila Date: 12 Oct 1998 09:25:14 +0300 Message-ID: Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm planning on building a ~20GB disk system. And I want to have hardware RAID5 on it. I'm mailing to ask about your experiences with various RAID controllers with FreeBSD. Cuase I'd like to "get it right the first time". Any recomendations for controller? Cc me, I'm not on the list. Thanks. -- Antti Kaipila To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 12 04:25:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA10976 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 04:25:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from asterix.webaffairs.net (port178.bonn.ndh.net [195.94.93.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA10970 for ; Mon, 12 Oct 1998 04:25:50 -0700 (PDT) (envelope-from stefhe@gmx.net) Received: from obelix (obelix.webaffairs.net [192.168.10.3]) by asterix.webaffairs.net (8.8.8/8.8.8) with SMTP id NAA19101; Mon, 12 Oct 1998 13:25:34 +0200 (CEST) (envelope-from stefhe@gmx.net) From: "Stefan Herrmann" To: "Joerg Wunsch" Cc: Subject: RE: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work Date: Mon, 12 Oct 1998 13:24:32 +0200 Message-ID: <000201bdf5d2$e2100580$030aa8c0@obelix.webaffairs.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <19981011220003.45970@uriah.heep.sax.de> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Finally I bought a TEAC CD burner. Had not much time to look, > > if it's good supported under FreeBSD, and since it was a gift > > from a company, I hoped that it rocks well... > > [...] > Stay with cdrecord by now. Kenneth Merry (sp?) once told me that he's > going to move worm(4) to CAM some day, this will also be a good chance > to rethink some of the original design ideas, and at least the SCSI-3 > MMC standard should be supported then, too. (When worm(4) was > written, there was no sign of any common standard among the CD-R drive > vendors). Kenneth Merry has also made a CAM driver for cdrecord, which is already in the 1.6.1a? alpha version: ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/ Since I don't have 3.0 running, I couldn't test it yet. Ciao Stefan -- --- Communications powered by FreeBSD --- Stefan Herrmann Löwenburgstr. 81 D-53229 Bonn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 12 06:22:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20240 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 06:22:08 -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 GAA20235; Mon, 12 Oct 1998 06:22:07 -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 GAA12095; Mon, 12 Oct 1998 06:18:46 -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 GAA14367; Mon, 12 Oct 1998 06:18:45 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id GAA09733; Mon, 12 Oct 1998 06:18:43 -0700 (PDT) From: Don Lewis Message-Id: <199810121318.GAA09733@salsa.gv.tsc.tdk.com> Date: Mon, 12 Oct 1998 06:18:43 -0700 In-Reply-To: Eivind Eklund "Re: filesystem safety and SCSI disk write caching" (Oct 4, 3:25pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Eivind Eklund , Mike Smith , Bruce Evans Subject: Re: filesystem safety and SCSI disk write caching Cc: Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com, tlambert@primenet.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 4, 3:25pm, Eivind Eklund wrote: } Subject: Re: filesystem safety and SCSI disk write caching } On Sun, Oct 04, 1998 at 12:06:15AM -0700, Mike Smith wrote: } > > >> Yes, the default configuration may be much slower than mine. } > > > } > > >I can definitely back your basic point ('make world' is CPU bound) up. } > > >On a 4-way Xeon system with slow disks we were still able to get down } > > >around 40 minutes. } > > } > > Er, that shows that it is i/o bound on systems with so much CPU. I } > > got it down to 75 minutes on 1-way K6-233 with 1 IDE disk before it } > > was bloated by perl5 and transition to elf. } > } > Moving to an MFS only saved about 15% of the build time. My point was } > that a faster CPU let you go faster. If the build was I/O bound, it } > wouldn't. } } My hypothesis is that for the high end boxes, 'make world' is mostly } bound by memory bandwidth. This is what seems to best match the speed } patterns people have been reporting. I don't think that's it either. One would certainly hope that a 4-way Xeon system would have more than twice as much memory bandwidth as a K6-233. I'm getting times down around 92 minutes with a Pentium II - 266 and a single Seagate Hawk when building FreeBSD post elf and perl5. That should get the times down to under 60 minutes with a Pentium II - 450. My conclusion is that running FreeBSD on a 4-way Xeon is not a cost effective way to get buildworld to run faster ... Here are some statistics that I gathered by varying the mount options on /usr/obj and rerunning make buildworld. It now looks like enabling SCSI write caching makes even less difference in the timing than I originally thought (a maximum of about 4 minutes with standard mount options, and a maximum of about 1 minute with either softupdates or async, typically much less). Also, softupdates is generally faster than async. I haven't yet had time to try to track down why "make -j4 buildworld" fails with the standard mount options. make -j1 -j2 -j3 -j4 -j6 -j8 -j12 /usr/obj mount options + SCSI write caching standard 158:04 133:33 129:56 FAIL *126:09 127:58 128:42 standard+write-cache 154:54 131:58 126:13 FAIL *115:44 123:44 126:24 softupdates 126:23 96:36 93:33 92:38 92:02 91:50 92:12 softupdates+write-cache 125:58 95:10 92:32 91:54 91:18 91:10 91:35 async 127:06 96:40 93:27 92:45 91:59 92:07 92:15 async+write-cache 125:18 95:54 92:56 92:05 91:26 91:24 91:36 Times in MMM:SS. All "make buildworld" runs started with a full object tree except: * partial object tree because of failure during previous run Hardware: Pentium II - 266 64 MB RAM Adaptec 2940UW Seagate ST-32151N Hawk 2XL Fast SCSI-2 (10.0MB/s transfer rate) Software: FreeBSD 3.0-BETA from September 26 with softupdates fixes and CAM. The softupdates times may be somewhat pessimistic because the code still has a number of sanity checks that I inserted to track down the newdirrem panic. All partitions mounted with standard mount options except /tmp which used mfs (and "setenv TMPDIR /tmp") and /usr/obj whose mount options were varied. All partitions were on the same spindle. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 12 06:26:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20840 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 06:26:31 -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 GAA20835; Mon, 12 Oct 1998 06:26:30 -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 GAA12141; Mon, 12 Oct 1998 06:26:08 -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 GAA14505; Mon, 12 Oct 1998 06:26:07 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id GAA09753; Mon, 12 Oct 1998 06:26:06 -0700 (PDT) From: Don Lewis Message-Id: <199810121326.GAA09753@salsa.gv.tsc.tdk.com> Date: Mon, 12 Oct 1998 06:26:05 -0700 In-Reply-To: "Justin T. Gibbs" "Re: filesystem safety and SCSI disk write caching" (Oct 4, 9:51pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Justin T. Gibbs" , Terry Lambert Subject: Re: filesystem safety and SCSI disk write caching Cc: julian@whistle.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 4, 9:51pm, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } >> >I told you so. } >> } >> You told me some things that were in-correct and some things that } >> I already knew. Par for the course. } > } >Feel free to make his setup work with SCSI write caching enabled. } } I gave the recipe for this on freebsd-alpha near the end of september. } } 1) Use a UPS. Even with an UPS, a large percentage of our unclean shutdowns are power related. Most of these are due to power outages that last longer than our UPS batteries. I don't think there is enough room in our building to store enough UPS batteries to last through our typical winter power outages. I don't think we'll be getting a backup generator anytime soon, and even then I've heard quite a few stories on freebsd-isp about problems getting generators to reliably start. } 2) Use a drive with non-bogus firmware. Recent Seagate and IBM } drives should work just fine. I haven't validated any Quantum } drives in this regard yet. But how can tell if the firmware is non-bogus? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 12 07:08:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26460 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 07:08:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26434; Mon, 12 Oct 1998 07:08:16 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from urdarbrunni.ifi.uio.no (2602@urdarbrunni.ifi.uio.no [129.240.64.184]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id QAA27138; Mon, 12 Oct 1998 16:07:52 +0200 (MET DST) Received: (from dag-erli@localhost) by urdarbrunni.ifi.uio.no ; Mon, 12 Oct 1998 16:07:51 +0200 (MET DST) Mime-Version: 1.0 To: Don Lewis Cc: "Justin T. Gibbs" , Terry Lambert , julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching References: <199810121326.GAA09753@salsa.gv.tsc.tdk.com> Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-other-addresses: 'finger dag-erli@ifi.uio.no' for a list X-disclaimer-1: The views expressed in this article are mine alone, and do X-disclaimer-2: not necessarily coincide with those of any organisation or X-disclaimer-3: company with which I am or have been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 12 Oct 1998 16:07:50 +0200 In-Reply-To: Don Lewis's message of "Mon, 12 Oct 1998 06:26:05 -0700" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id HAA26449 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis writes: > On Oct 4, 9:51pm, "Justin T. Gibbs" wrote: > > 1) Use a UPS. > Even with an UPS, a large percentage of our unclean shutdowns are power > related. Most of these are due to power outages that last longer than > our UPS batteries. 1.5) When the UPS reports that the battery is running low, shut everything down. DES -- Dag-Erling Smørgrav - dag-erli@ifi.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 12 08:43:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11354 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 08:43:57 -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 IAA11345; Mon, 12 Oct 1998 08:43:55 -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 JAA01328; Mon, 12 Oct 1998 09:43:19 -0600 (MDT) Message-Id: <199810121543.JAA01328@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) cc: Don Lewis , "Justin T. Gibbs" , Terry Lambert , julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "12 Oct 1998 16:07:50 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 12 Oct 1998 09:36:33 -0600 From: "Justin T. Gibbs" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id IAA11350 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Don Lewis writes: >> On Oct 4, 9:51pm, "Justin T. Gibbs" wrote: >> > 1) Use a UPS. >> Even with an UPS, a large percentage of our unclean shutdowns are power >> related. Most of these are due to power outages that last longer than >> our UPS batteries. > >1.5) When the UPS reports that the battery is running low, shut > everything down. Exactly. -- 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 12 08:58:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14299 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 08:58:09 -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 IAA14196; Mon, 12 Oct 1998 08:58:01 -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 JAA04320; Mon, 12 Oct 1998 09:57:28 -0600 (MDT) Message-Id: <199810121557.JAA04320@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: "Justin T. Gibbs" , Terry Lambert , julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Mon, 12 Oct 1998 06:26:05 PDT." <199810121326.GAA09753@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Oct 1998 09:50:42 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} 2) Use a drive with non-bogus firmware. Recent Seagate and IBM >} drives should work just fine. I haven't validated any Quantum >} drives in this regard yet. > >But how can tell if the firmware is non-bogus? Ask Terry since he has stated that he 'doesn't have any drives with non-bogus firmware'. Seriously, the major complaint I've heard about firmware has to do with it not properly flushing the cache on a bus reset. I've never seen that failure mode here, and I've done quite a bit of "external bus reset" testing. You'll need sophisticated tools in order to perform these kinds of tests: 1) Find a paper clip 2) Find a ribbon cable that has enough connectors to attach to the device you want to test and the controller with a connector spare. 3) Start lots of writes 4) Ground pin 40 to pin 39 using the paper clip from step 1. 5) Verify data 6) goto 3 -- 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 12 08:59:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14659 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 08:59:13 -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 IAA14636; Mon, 12 Oct 1998 08:59:10 -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 JAA04452; Mon, 12 Oct 1998 09:58:32 -0600 (MDT) Message-Id: <199810121558.JAA04452@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: Don Lewis , Terry Lambert , julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Mon, 12 Oct 1998 09:50:42 MDT." <199810121557.JAA04320@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Oct 1998 09:51:46 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This assumes a Single Ended SCSI configuration... >1) Find a paper clip > >2) Find a ribbon cable that has enough connectors to attach to the device >you want to test and the controller with a connector spare. > >3) Start lots of writes > >4) Ground pin 40 to pin 39 using the paper clip from step 1. > >5) Verify data > >6) goto 3 > >-- >Justin > > > -- 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 12 10:20:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26690 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 10:20:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from artorius.sunflower.com (artorius.sunflower.com [24.124.0.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26655 for ; Mon, 12 Oct 1998 10:20:05 -0700 (PDT) (envelope-from scsi@artorius.sunflower.com) Received: from artorius.sunflower.com (artorius.sunflower.com [24.124.0.6]) by artorius.sunflower.com (8.8.8/8.8.7) with SMTP id MAA03817 for ; Mon, 12 Oct 1998 12:19:22 -0500 (CDT) (envelope-from scsi@artorius.sunflower.com) Date: Mon, 12 Oct 1998 12:19:22 -0500 (CDT) From: "Stephen D. Spencer" To: freebsd-scsi@FreeBSD.ORG Subject: CAM error report 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 The server didn't die. There was a grand enough pause that caused some connections to drop, but it recovered quite nicely and continued plugging along. Any comments or observations concerning these messages would be appreciated. [begin editorial plug] I just wanted to say that other than having to replace a run of bad Baracuda UW 9 gigs, I am extrordinarily happy with FreeBSD and the new CAM system. Currently at 13 days uptime on a moderately busy news server, the system has surpassed the maximum uptime of the SGI server that usenet was running on by 250%. On behalf of myself (no more getting paged to come revive the news erver) and the 400+ cable modem subscribers (who can't live without their nudie pics... er.. I mean the loads of solid technical data available on usenet) I tip my hat to the FreeBSD core team and specifically to Justin and Mike for their skills, time and support in making FreeBSD what it is. [end editorial plug] Regards, Stephen Spencer Sunflower Datavision (http://www.sunflower.com/data) Lawrence, KS ---------------- System: FreeBSD 2.2-980705-SNAP #0: Wed Aug 26 17:25:50 CDT 1998 root@grendel.sunflower.com:/usr/src/sys/compile/GRENDEL (+CAM) Purpose: Running INND 1.7.2 Controllers: ahc0 rev 1 int a irq 11 on pci0:16:0 ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs [3 of the following] ahc1 rev 1 int a irq 9 on pci0:17:0 ahc1: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Drives: da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: Serial Number LA801256 da1: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da1: 8683MB (17783112 512 byte sectors: 64H 32S/T 8683C) da3 at ahc0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI2 device da3: Serial Number LAG63523 da3: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da3: 8683MB (17783112 512 byte sectors: 64H 32S/T 8683C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number 332805272671 da0: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da0: 2051MB (4201304 512 byte sectors: 64H 32S/T 2051C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI2 device da2: Serial Number HK0473250W9L7R da2: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da2: 4340MB (8888924 512 byte sectors: 64H 32S/T 4340C) da4 at ahc0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI2 device da4: Serial Number HD0306380FPLZ0 da4: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da4: 4148MB (8496884 512 byte sectors: 64H 32S/T 4148C) [drives 5-11 are of the following type] da10 at ahc3 bus 0 target 2 lun 0 da10: Fixed Direct Access SCSI2 device da10: Serial Number RE085568 da10: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da10: 8715MB (17850000 512 byte sectors: 64H 32S/T 8715C) [dmesg] QADDR == 0x10d SSTAT1 == 0x2 (da1:ahc0:0:1:0): SCB 0x7e - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10d SSTAT1 == 0x2 (da1:ahc0:0:1:0): SCB 0x6 - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10d SSTAT1 == 0x2 (da1:ahc0:0:1:0): SCB 0x4b - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10d SSTAT1 == 0x2 (da1:ahc0:0:1:0): SCB 0x87 - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10d SSTAT1 == 0x2 (da1:ahc0:0:1:0): SCB 0x88 - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10d SSTAT1 == 0x2 [quite a bit more of this] . . . (da3:ahc0:0:3:0): BDR message in message buffer (da3:ahc0:0:3:0): SCB 0x25 - timed out in datain phase, SCSISIGI == 0x54 SEQADDR == 0x10d SSTAT1 == 0x2 (da3:ahc0:0:3:0): no longer in timeout, status = 34b ahc0: target 0 using asynchronous transfers ahc0: target 1 using asynchronous transfers ahc0: target 2 using asynchronous transfers ahc0: target 3 using asynchronous transfers ahc0: target 4 using asynchronous transfers ahc0: Issued Channel A Bus Reset. 61 SCBs aborted ahc0: target 0 synchronous at 20.0MHz, offset = 0xf ahc0: target 3 synchronous at 20.0MHz, offset = 0xf ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 20.0MHz, offset = 0xf ahc0: target 3 using asynchronous transfers ahc0: target 3 synchronous at 20.0MHz, offset = 0xf ahc0: target 1 synchronous at 20.0MHz, offset = 0xf ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset = 0xf ahc0: target 4 synchronous at 20.0MHz, offset = 0xf ahc0: target 4 using asynchronous transfers ahc0: target 4 synchronous at 20.0MHz, offset = 0xf ahc0: target 2 synchronous at 20.0MHz, offset = 0xf ahc0: target 2 using asynchronous transfers ahc0: target 2 synchronous at 20.0MHz, offset = 0xf (da1:ahc0:0:1:0): SCB 0x10 - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10e SSTAT1 == 0x2 (da3:ahc0:0:3:0): SCB 0x79 - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x10e SSTAT1 == 0x2 (da3:ahc0:0:3:0): BDR message in message buffer (da3:ahc0:0:3:0): SCB 0x79 - timed out in datain phase, SCSISIGI == 0x54 SEQADDR == 0x10d SSTAT1 == 0x2 (da3:ahc0:0:3:0): no longer in timeout, status = 34b ahc0: target 0 using asynchronous transfers ahc0: target 1 using asynchronous transfers ahc0: target 2 using asynchronous transfers ahc0: target 3 using asynchronous transfers ahc0: target 4 using asynchronous transfers ahc0: Issued Channel A Bus Reset. 2 SCBs aborted ahc0: target 0 synchronous at 20.0MHz, offset = 0xf ahc0: target 1 synchronous at 20.0MHz, offset = 0xf ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 20.0MHz, offset = 0xf ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset = 0xf ahc0: target 3 synchronous at 20.0MHz, offset = 0xf ahc0: target 3 using asynchronous transfers ahc0: target 3 synchronous at 20.0MHz, offset = 0xf ahc0: target 4 synchronous at 20.0MHz, offset = 0xf ahc0: target 4 using asynchronous transfers ahc0: target 4 synchronous at 20.0MHz, offset = 0xf ahc0: target 2 synchronous at 20.0MHz, offset = 0xf ahc0: target 2 using asynchronous transfers ahc0: target 2 synchronous at 20.0MHz, offset = 0xf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Oct 12 10:39:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00292 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 10:39:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (castles238.castles.com [208.214.165.238]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00285 for ; Mon, 12 Oct 1998 10:39:14 -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 KAA06909; Mon, 12 Oct 1998 10:43:31 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810121743.KAA06909@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Stefan Herrmann" cc: "Joerg Wunsch" , scsi@FreeBSD.ORG Subject: Re: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work In-reply-to: Your message of "Mon, 12 Oct 1998 13:24:32 +0200." <000201bdf5d2$e2100580$030aa8c0@obelix.webaffairs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 12 Oct 1998 10:43:30 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id KAA00287 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Kenneth Merry has also made a CAM driver for cdrecord, which is already > in the 1.6.1a? alpha version: > > ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/ > > Since I don't have 3.0 running, I couldn't test it yet. Hmm, the version at ftp.freebsd.org in the development/cam directory bombs out for me trying to access unit -1. This was on a fresh kernel/ libcam as of yesterday. 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 Mon Oct 12 12:05:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14682 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 12:05:43 -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 MAA14669 for ; Mon, 12 Oct 1998 12:05:38 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id NAA25985; Mon, 12 Oct 1998 13:05:00 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810121905.NAA25985@panzer.plutotech.com> Subject: Re: TEAC CD-R55S not recognized as worm, hacked a bit, but still doesn't work In-Reply-To: <199810121743.KAA06909@dingo.cdrom.com> from Mike Smith at "Oct 12, 98 10:43:30 am" To: mike@smith.net.au (Mike Smith) Date: Mon, 12 Oct 1998 13:05:00 -0600 (MDT) Cc: stefhe@gmx.net, joerg_wunsch@uriah.heep.sax.de, 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 Mike Smith wrote... > > Kenneth Merry has also made a CAM driver for cdrecord, which is already > > in the 1.6.1a? alpha version: > > > > ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/ > > > > Since I don't have 3.0 running, I couldn't test it yet. > > Hmm, the version at ftp.freebsd.org in the development/cam directory > bombs out for me trying to access unit -1. This was on a fresh kernel/ > libcam as of yesterday. 8( Don't use that version, it's definitely not the latest/greatest. I'll see if I can get Justin to nuke it... Use the version in the ports tree, or from the cdrecord ftp site mentioned above. Let me know if you still have problems when using the latest version... 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 12 12:51:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25618 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 12:51:47 -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 MAA25566 for ; Mon, 12 Oct 1998 12:51:36 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id NAA07293; Mon, 12 Oct 1998 13:44:35 -0600 (MDT) Date: Mon, 12 Oct 1998 13:44:35 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810121944.NAA07293@narnia.plutotech.com> To: "Stephen D. Spencer" cc: scsi@FreeBSD.ORG Subject: Re: CAM error report 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: > > The server didn't die. There was a grand enough pause that caused > some connections to drop, but it recovered quite nicely and continued > plugging along. Any comments or observations concerning these messages > would be appreciated. The timeout in CAM is now 60 seconds. Timeouts in general are always a tradeoff. If we lower the timeout, it may catch situations that are not really a problem. The longer the timeout the longer the system waits before attempting recovery. You can reduce the timeout to something smaller if it suits your needs through the DA_DEFAULT_TIMEOUT kernel config option. > QADDR == 0x10d > SSTAT1 == 0x2 > (da1:ahc0:0:1:0): SCB 0x7e - timed out in datain phase, SCSISIGI == 0x44 This looks like a termination or cable issue. The controller is waiting for a Req from the drive or the drive is waiting for an Ack from the controller, but one of these signals was lost on the wire. -- 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 12 15:47:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01799 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 15:47:39 -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 PAA01773; Mon, 12 Oct 1998 15:47:24 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA28425; Mon, 12 Oct 1998 15:47:06 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd028394; Mon Oct 12 15:47:03 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA10583; Mon, 12 Oct 1998 15:46:58 -0700 (MST) From: Terry Lambert Message-Id: <199810122246.PAA10583@usr02.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Mon, 12 Oct 1998 22:46:57 +0000 (GMT) Cc: gibbs@plutotech.com, tlambert@primenet.com, julian@whistle.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810121326.GAA09753@salsa.gv.tsc.tdk.com> from "Don Lewis" at Oct 12, 98 06:26:05 am 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 > } 1) Use a UPS. > > Even with an UPS, a large percentage of our unclean shutdowns are power > related. Most of these are due to power outages that last longer than > our UPS batteries. I don't think there is enough room in our building > to store enough UPS batteries to last through our typical winter power > outages. I don't think we'll be getting a backup generator anytime soon, > and even then I've heard quite a few stories on freebsd-isp about problems > getting generators to reliably start. The point of a UPS is to give you room to perform an orderly shutdown prior to UPS failure. This requires using a UPS that support monitoring and software control of power-on-state and running a monitoring daemon capable of powering down the UPS. > } 2) Use a drive with non-bogus firmware. Recent Seagate and IBM > } drives should work just fine. I haven't validated any Quantum > } drives in this regard yet. > > But how can tell if the firmware is non-bogus? Someone you trust tells you it is non-bogus. 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 12 15:59:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04001 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 15:59: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 PAA03916; Mon, 12 Oct 1998 15:58:48 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA12815; Mon, 12 Oct 1998 15:58:30 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd012733; Mon Oct 12 15:58:20 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA11377; Mon, 12 Oct 1998 15:58:15 -0700 (MST) From: Terry Lambert Message-Id: <199810122258.PAA11377@usr02.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 12 Oct 1998 22:58:15 +0000 (GMT) Cc: Don.Lewis@tsc.tdk.com, gibbs@plutotech.com, tlambert@primenet.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810121557.JAA04320@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 12, 98 09:50:42 am 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 > >} 2) Use a drive with non-bogus firmware. Recent Seagate and IBM > >} drives should work just fine. I haven't validated any Quantum > >} drives in this regard yet. > > > >But how can tell if the firmware is non-bogus? > > Ask Terry since he has stated that he 'doesn't have any drives with > non-bogus firmware'. A) Run soft updates B) Press "reset" occasionally C) Note any anomalies in the resulting fsck when the machine comes back up D) if count < 200, goto B E) if # of anomalies > 0, print "bad firmware". > Seriously, the major complaint I've heard about firmware has to do with it > not properly flushing the cache on a bus reset. I've never seen that > failure mode here, and I've done quite a bit of "external bus reset" > testing. You'll need sophisticated tools in order to perform these kinds > of tests: > > 1) Find a paper clip > > 2) Find a ribbon cable that has enough connectors to attach to the device > you want to test and the controller with a connector spare. > > 3) Start lots of writes > > 4) Ground pin 40 to pin 39 using the paper clip from step 1. > > 5) Verify data > > 6) goto 3 It's very hard to do this in software, without providing a mechanism to actually break into the latency link between the derive reporting a write cached operation has been written, and the actual writing. Such a latency link only exists on drives which Justin has identified as having broken firmware due to the behaviour reported by Don Lewis. I would be much more interested in knowing what drives and firmware revisions of those drives Justin has, since both mine and Don Lewis's are demonstrably broken. The drives I can demonstrate breakage on are a 9G IBM drive, a 2.1G Quantum drive, and two .5G DEC drives. I can get exact model numbers if necessary, but it seems to me, from empirical evidence so far, that the number of "broken firmware" drives, as defined by Justin, outnumber the number of non-broken firmware drives. This means that a "known good" table would be smaller than a "known rogues" table, and thus a better mechanism for implementing the decision about whether write caching should be enabled on the drive, or not. I'll be happy (well, actually I won't) to have it proven to me that my and Don Lewis' drives are the exceptions, rather than the rule. 8-(. 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 12 22:11:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00661 for freebsd-scsi-outgoing; Mon, 12 Oct 1998 22:11:49 -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 WAA00656; Mon, 12 Oct 1998 22:11:48 -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 WAA22177; Mon, 12 Oct 1998 22:11:28 -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 WAA00543; Mon, 12 Oct 1998 22:11:27 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA14457; Mon, 12 Oct 1998 21:33:54 -0700 (PDT) From: Don Lewis Message-Id: <199810130433.VAA14457@salsa.gv.tsc.tdk.com> Date: Mon, 12 Oct 1998 21:33:53 -0700 In-Reply-To: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) "Re: filesystem safety and SCSI disk write caching" (Oct 12, 4:07pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ), Don Lewis Subject: Re: filesystem safety and SCSI disk write caching Cc: "Justin T. Gibbs" , Terry Lambert , julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 12, 4:07pm, Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= wrote: } Subject: Re: filesystem safety and SCSI disk write caching } Don Lewis writes: } > On Oct 4, 9:51pm, "Justin T. Gibbs" wrote: } > > 1) Use a UPS. } > Even with an UPS, a large percentage of our unclean shutdowns are power } > related. Most of these are due to power outages that last longer than } > our UPS batteries. } } 1.5) When the UPS reports that the battery is running low, shut } everything down. I'd like to do that at some point. I'd have to rig up some way of broadcasting that info on our network, since the UPS lives two floors below. So far as I know, it's not network aware. I haven't seen any info on how to interface to it, but then I haven't really looked, either. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 00:06:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA11454 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 00:06:11 -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 AAA11449; Tue, 13 Oct 1998 00:06:09 -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 BAA12205; Tue, 13 Oct 1998 01:05:50 -0600 (MDT) Message-Id: <199810130705.BAA12205@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Mon, 12 Oct 1998 22:58:15 -0000." <199810122258.PAA11377@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Oct 1998 00:59:05 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >} 2) Use a drive with non-bogus firmware. Recent Seagate and IBM >> >} drives should work just fine. I haven't validated any Quantum >> >} drives in this regard yet. >> > >> >But how can tell if the firmware is non-bogus? >> >> Ask Terry since he has stated that he 'doesn't have any drives with >> non-bogus firmware'. > >A) Run soft updates >B) Press "reset" occasionally >C) Note any anomalies in the resulting fsck when the machine > comes back up >D) if count < 200, goto B >E) if # of anomalies > 0, print "bad firmware". You're missing a large step here. You can't prove that the 'anomaly' is related to the drive firmware without a trace of all transactions on the SCSI bus. It could well be a missing dependency in the soft update code. I'd be more than happy to reproduce your failure scenario while recording a SCSI bus trace so that the fault is easy to interpret. Just send me any *modern* drive that you think fails. You should also ensure that your reset button does not cause any power spikes on the drive power lines. That would be cheating. >It's very hard to do this in software, without providing a mechanism >to actually break into the latency link between the drive reporting >a write cached operation has been written, and the actual writing. If you can cause this a failure to occur by hitting your reset button, I should be able to cause it to occur by using a paper-clip if the reset condition (cased by the SCSI card BIOS in the reset button case) is the event that causes cache corruption. Both are non-deterministic methods of error injection. >Such a latency link only exists on drives which Justin has identified >as having broken firmware due to the behaviour reported by Don Lewis. I'm still unclear as to whether Don was turning off power or hitting what I consider the reset button. His comment about UPSes use makes me think he was testing power outage scenarios. >I would be much more interested in knowing what drives and firmware >revisions of those drives Justin has, since both mine and Don Lewis's >are demonstrably broken. Since you were able to test 4 drives so quickly, I'd love to see well documented information on exactly how the file system was inconsistent in the failure cases. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 00:22:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13178 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 00:22:35 -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 AAA13172; Tue, 13 Oct 1998 00:22:34 -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 AAA23196; Tue, 13 Oct 1998 00:22:16 -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 AAA02758; Tue, 13 Oct 1998 00:22:15 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id AAA14971; Tue, 13 Oct 1998 00:22:13 -0700 (PDT) From: Don Lewis Message-Id: <199810130722.AAA14971@salsa.gv.tsc.tdk.com> Date: Tue, 13 Oct 1998 00:22:12 -0700 In-Reply-To: "Justin T. Gibbs" "Re: filesystem safety and SCSI disk write caching" (Oct 13, 12:59am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Justin T. Gibbs" , Terry Lambert Subject: Re: filesystem safety and SCSI disk write caching Cc: Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 13, 12:59am, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } I'm still unclear as to whether Don was turning off power or hitting what I } consider the reset button. His comment about UPSes use makes me think he } was testing power outage scenarios. I was hitting the reset button to test the softupdates code because I thought that write caching on the drive was disabled. It wasn't until I got the unexpected filesystem inconsistency that I actually checked the state of the write caching bit. Once I disable write caching, I didn't get any more unexpected inconsistencies, though I didn't repeat this experiment enough to totally convince myself that my results were conclusive. With write caching disabled, I'd expect the same results with either the reset button or the power switch, but I didn't test the latter since it's a lot rougher on the hardware. If the inconsistency was due to a missing softupdates dependency, I'd expect to see more inconsistencies in the many panics I provoked in some other testing I was doing. With the exception of some inconsistencies created by bugs in fsck that corrupted the filesystem while attempting to fix it, I did not see any unexpected inconsistencies caused by these panics. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 09:33:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13638 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 09:33:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ocsnt4.ocsny.com (ocsnt4.ocsny.com [204.107.76.113]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13632 for ; Tue, 13 Oct 1998 09:33:30 -0700 (PDT) (envelope-from pcollins@ocsny.com) Received: from SCAN by ocsnt4.ocsny.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id 43R48XSS; Tue, 13 Oct 1998 12:32:10 -0400 Message-ID: <36238127.F7EF6818@ocsny.com> Date: Tue, 13 Oct 1998 12:34:47 -0400 From: pete collins X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: adaptec aic 7890 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i have this controller and want to know what to do to install freebsd 2.2.7 stable thanks pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 16:59:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA25240 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 16:59:29 -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 QAA25212; Tue, 13 Oct 1998 16:59:26 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA17796; Tue, 13 Oct 1998 16:59:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd017768; Tue Oct 13 16:59:04 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA18137; Tue, 13 Oct 1998 16:58:59 -0700 (MST) From: Terry Lambert Message-Id: <199810132358.QAA18137@usr08.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Tue, 13 Oct 1998 23:58:59 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810130705.BAA12205@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 13, 98 00:59:05 am 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 > >> Ask Terry since he has stated that he 'doesn't have any drives with > >> non-bogus firmware'. > > > >A) Run soft updates > >B) Press "reset" occasionally > >C) Note any anomalies in the resulting fsck when the machine > > comes back up > >D) if count < 200, goto B > >E) if # of anomalies > 0, print "bad firmware". > > You're missing a large step here. You can't prove that the 'anomaly' > is related to the drive firmware without a trace of all transactions > on the SCSI bus. It could well be a missing dependency in the soft > update code. If I turn off write caching on the drive, and repeat the test, and the evaluation (E) results in a "# of anomalies == 0", where with write caching enabled, the number was > 0, then I can say with high confidence that it's the write caching. This is the experiment Don Lewis ran. > I'd be more than happy to reproduce your failure scenario > while recording a SCSI bus trace so that the fault is easy to interpret. > Just send me any *modern* drive that you think fails. Sure; just define "modern" for me, since my personal definition is "not IDE". > You should also ensure that your reset button does not cause any power > spikes on the drive power lines. That would be cheating. It doesn't, since "# of anomalies == 0" with write caching disabled. > >It's very hard to do this in software, without providing a mechanism > >to actually break into the latency link between the drive reporting > >a write cached operation has been written, and the actual writing. > > If you can cause this a failure to occur by hitting your reset button, I > should be able to cause it to occur by using a paper-clip if the reset > condition (cased by the SCSI card BIOS in the reset button case) is the > event that causes cache corruption. Both are non-deterministic methods of > error injection. I'm not very confident that this will break in at the fragile point in the transaction. > >Such a latency link only exists on drives which Justin has identified > >as having broken firmware due to the behaviour reported by Don Lewis. > > I'm still unclear as to whether Don was turning off power or hitting what I > consider the reset button. His comment about UPSes use makes me think he > was testing power outage scenarios. Well, I know that this might sound insane, but we could ask Don, and I could get out of the middle of this whole thing... ;-). > >I would be much more interested in knowing what drives and firmware > >revisions of those drives Justin has, since both mine and Don Lewis's > >are demonstrably broken. > > Since you were able to test 4 drives so quickly, I'd love to see well > documented information on exactly how the file system was inconsistent > in the failure cases. There were directory dependencies which were committed out of order (the modified fsck reports these as soft dependency errors...). 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 Tue Oct 13 17:08:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA27157 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 17:08:06 -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 RAA27098; Tue, 13 Oct 1998 17:07:58 -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 SAA02391; Tue, 13 Oct 1998 18:07:37 -0600 (MDT) Message-Id: <199810140007.SAA02391@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Tue, 13 Oct 1998 23:58:59 -0000." <199810132358.QAA18137@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Oct 1998 18:00:52 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> You're missing a large step here. You can't prove that the 'anomaly' >> is related to the drive firmware without a trace of all transactions >> on the SCSI bus. It could well be a missing dependency in the soft >> update code. > >If I turn off write caching on the drive, and repeat the test, and >the evaluation (E) results in a "# of anomalies == 0", where with >write caching enabled, the number was > 0, then I can say with >high confidence that it's the write caching. I disagree. You have demonstrable varied the rate at which write completions as seen by FreeBSD occur which means that the test is anything but conclusive. >> I'd be more than happy to reproduce your failure scenario >> while recording a SCSI bus trace so that the fault is easy to interpret. >> Just send me any *modern* drive that you think fails. > >Sure; just define "modern" for me, since my personal definition is >"not IDE". A drive manufactured within the last 3 years. >> You should also ensure that your reset button does not cause any power >> spikes on the drive power lines. That would be cheating. > >It doesn't, since "# of anomalies == 0" with write caching disabled. This doesn't follow. If the cache is disabled, it doesn't matter if the drive loses power due to hitting the reset button. We already know that losing power on a drive that cached data will not work. >> I'm still unclear as to whether Don was turning off power or hitting what I >> consider the reset button. His comment about UPSes use makes me think he >> was testing power outage scenarios. > >Well, I know that this might sound insane, but we could ask Don, and >I could get out of the middle of this whole thing... ;-). Well, if your offering, I'd be more than happy to take you up on your offer. >> Since you were able to test 4 drives so quickly, I'd love to see well >> documented information on exactly how the file system was inconsistent >> in the failure cases. > >There were directory dependencies which were committed out of order >(the modified fsck reports these as soft dependency errors...). Can you be more specific? Are you positive that the transactions were committed out of order or could it be that some transactions were never committed at all? What was the size of the directory. Was the failure in directory creation or destruction? Which portion of the dependency graph was violated? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 17:49:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA03907 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 17:49:58 -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 RAA03888; Tue, 13 Oct 1998 17:49:55 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA04271; Tue, 13 Oct 1998 17:49:40 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd004237; Tue Oct 13 17:49:37 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA20004; Tue, 13 Oct 1998 17:49:31 -0700 (MST) From: Terry Lambert Message-Id: <199810140049.RAA20004@usr08.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Wed, 14 Oct 1998 00:49:31 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810140007.SAA02391@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 13, 98 06:00: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 > >It doesn't, since "# of anomalies == 0" with write caching disabled. > > This doesn't follow. If the cache is disabled, it doesn't matter if > the drive loses power due to hitting the reset button. We already > know that losing power on a drive that cached data will not work. We do? If writes are committed in dependency order, and the write is cached and there is no reordering of subsequent writes (ie: writes occur in tag order, even if they are cached), then I think this satisifies soft updates. > >> I'm still unclear as to whether Don was turning off power or hitting what I > >> consider the reset button. His comment about UPSes use makes me think he > >> was testing power outage scenarios. > > > >Well, I know that this might sound insane, but we could ask Don, and > >I could get out of the middle of this whole thing... ;-). > > Well, if your offering, I'd be more than happy to take you up on your > offer. No need; he's spoken up: He was using the front panel reset, not power loss. > >> Since you were able to test 4 drives so quickly, I'd love to see well > >> documented information on exactly how the file system was inconsistent > >> in the failure cases. > > > >There were directory dependencies which were committed out of order > >(the modified fsck reports these as soft dependency errors...). > > Can you be more specific? Are you positive that the transactions > were committed out of order or could it be that some transactions > were never committed at all? Transactions were committed out of order. If the transactions that had been committed had been committed in order, then the loss of cached transactions would only result in a rewind of state of the drive to a previous state. The previous state, by definition, must also be consistent. In other words, transaction dependency order as required for soft updates must cause commits to the drives to occur in dependency order, and the problem is the reordering of consecutive write requests by the drive itself if there is *ever* a case where the state is ever inconsistent. The only alternative is a dependency order bug, and such a bug would be very easy to reproduce using a break-to-debugger or a reset+fsck. This is not the case, from all observable data, so it *must* be that the soft updates code is being given the go-ahead on another transaction before the previous transaction on which it depends has been committed to stable storage, and the drive is subsequently committing them out of order. There is no other explanation for a soft dependency inconsistency, so long as dependencies are both correctly modelled and enqueued (which we believe to be the case). > What was the size of the directory. For me, it was a large directory; it was the full X11R6 source tree from the XFree86 distribution (this is what Julian has used as one of his tests at Whistle, so I did the same at home). > Was the failure in directory creation or destruction? Which portion > of the dependency graph was violated? I would have to manually examine the data on the disk after getting the fsck report to answer this. Unfortunately, fsck is a tool for returning the disk to a known stable state, and if the dependency order is not enforced by synchronous writes and/or soft update dependency order being honored by the drive, then I would need to be able to intuit what the correct state should have been vs. what the current state was (in other words, guess the outstanding cached transactions remaining uncommitted, and determine if they would be rolled forward or backward by fsck). My *hunch* from what I was doing at the time (rm -rf) is "destruction", but since I started this before all the creations were committed to stable storage (only enqueued in the dependency queue), I can't really say for sure what operation was in effect when I hit the reset button. Maybe Don can elaborate on what he was doing when he hit reset? 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 Tue Oct 13 21:40:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05988 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 21:40:17 -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 VAA05980; Tue, 13 Oct 1998 21:40:12 -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 VAA09333; Tue, 13 Oct 1998 21:39:53 -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 VAA23764; Tue, 13 Oct 1998 21:39:52 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA17463; Tue, 13 Oct 1998 21:39:50 -0700 (PDT) From: Don Lewis Message-Id: <199810140439.VAA17463@salsa.gv.tsc.tdk.com> Date: Tue, 13 Oct 1998 21:39:50 -0700 In-Reply-To: "Justin T. Gibbs" "Re: filesystem safety and SCSI disk write caching" (Oct 13, 6:00pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Justin T. Gibbs" , Terry Lambert Subject: Re: filesystem safety and SCSI disk write caching Cc: Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 13, 6:00pm, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } >> I'd be more than happy to reproduce your failure scenario } >> while recording a SCSI bus trace so that the fault is easy to interpret. } >> Just send me any *modern* drive that you think fails. } > } >Sure; just define "modern" for me, since my personal definition is } >"not IDE". } } A drive manufactured within the last 3 years. The drive in my experiment is: da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da0: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C) I don't know when it was manufactured, but I've only had access to it for less than a year. } >> You should also ensure that your reset button does not cause any power } >> spikes on the drive power lines. That would be cheating. } > } >It doesn't, since "# of anomalies == 0" with write caching disabled. } } This doesn't follow. If the cache is disabled, it doesn't matter if } the drive loses power due to hitting the reset button. We already } know that losing power on a drive that cached data will not work. I didn't hear the sound of any mechanical things spinning down. The machine just started going through its boot sequence. } >> I'm still unclear as to whether Don was turning off power or hitting what I } >> consider the reset button. His comment about UPSes use makes me think he } >> was testing power outage scenarios. } > } >Well, I know that this might sound insane, but we could ask Don, and } >I could get out of the middle of this whole thing... ;-). } } Well, if your offering, I'd be more than happy to take you up on your } offer. I was only playing with the reset button. Justin was the first to mention an UPS as the solution. } >> Since you were able to test 4 drives so quickly, I'd love to see well } >> documented information on exactly how the file system was inconsistent } >> in the failure cases. } > } >There were directory dependencies which were committed out of order } >(the modified fsck reports these as soft dependency errors...). } } Can you be more specific? Are you positive that the transactions } were committed out of order or could it be that some transactions } were never committed at all? What was the size of the directory. } Was the failure in directory creation or destruction? Which portion } of the dependency graph was violated? The symptom was a directory entry that referenced an unallocated inode. When creating a new file (or adding a link), softupdates writes the new inode to disk (and waits for the driver to tell it the write is complete) before writing the block containing the new directory entry to disk. When doing an unlink, softupdates clears the directory entry, writes the directory block to disk, and waits for the driver to tell it the directory block has been written before writing the inode to disk (either cleared or just with decreased reference count as appropriate). If the writes that actually ended up on the platters were done in the correct order, the only inconsistency that could result from a failure to commit all the transactions would be an unreferenced inode on disk that might get reconnected under lost+found by fsck. The problem I saw indicates that the writes to the platters were done in the wrong order and not all of them were completed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 22:05:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09465 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 22:05:30 -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 WAA09454; Tue, 13 Oct 1998 22:05:28 -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 WAA09465; Tue, 13 Oct 1998 22:05:09 -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 WAA24188; Tue, 13 Oct 1998 22:05:08 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA17506; Tue, 13 Oct 1998 22:05:07 -0700 (PDT) From: Don Lewis Message-Id: <199810140505.WAA17506@salsa.gv.tsc.tdk.com> Date: Tue, 13 Oct 1998 22:05:06 -0700 In-Reply-To: Terry Lambert "Re: filesystem safety and SCSI disk write caching" (Oct 14, 12:49am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , gibbs@plutotech.com (Justin T. Gibbs) Subject: Re: filesystem safety and SCSI disk write caching Cc: Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 14, 12:49am, Terry Lambert wrote: } Subject: Re: filesystem safety and SCSI disk write caching } > >It doesn't, since "# of anomalies == 0" with write caching disabled. } > } > This doesn't follow. If the cache is disabled, it doesn't matter if } > the drive loses power due to hitting the reset button. We already } > know that losing power on a drive that cached data will not work. } } We do? I think we do. } If writes are committed in dependency order, and the write is cached } and there is no reordering of subsequent writes (ie: writes occur in } tag order, even if they are cached), then I think this satisifies soft } updates. I believe the situation is that if you have write caching enabled, the drive will reorder the writes and it will tell you that the writes are done before they have been really gotten all the way to the platters. This might allow softupdates to issue more writes that might actually end up on the platters before the writes that they are dependent on. If the host CPU panics, this is still ok, because the combination of the pending writes in the drive cache and the data on the platters is in a safe state from the standpoint of what softupdates expects, and if the drive is not perturbed (by shutting off its power or doing something else that causes it to fail to commit the pending writes to stable storage), all the pending writes will complete and the bits on the platters will eventually end up in a "good enough" if not consistent state. } > What was the size of the directory. } } For me, it was a large directory; it was the full X11R6 source tree } from the XFree86 distribution (this is what Julian has used as one } of his tests at Whistle, so I did the same at home). I don't know in my case. } > Was the failure in directory creation or destruction? Which portion } > of the dependency graph was violated? } My *hunch* from what I was doing at the time (rm -rf) is "destruction", } but since I started this before all the creations were committed to } stable storage (only enqueued in the dependency queue), I can't } really say for sure what operation was in effect when I hit the reset } button. Maybe Don can elaborate on what he was doing when he hit } reset? I was doing the usual buildworld. I don't remember if it was in a creation or destruction phase when I hit reset. This was a couple weeks ago. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 22:18:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA10720 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 22:18:53 -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 WAA10712; Tue, 13 Oct 1998 22:18:49 -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 XAA15040; Tue, 13 Oct 1998 23:18:26 -0600 (MDT) Message-Id: <199810140518.XAA15040@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Wed, 14 Oct 1998 00:49:31 -0000." <199810140049.RAA20004@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Oct 1998 23:11:41 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >It doesn't, since "# of anomalies == 0" with write caching disabled. >> >> This doesn't follow. If the cache is disabled, it doesn't matter if >> the drive loses power due to hitting the reset button. We already >> know that losing power on a drive that cached data will not work. > >We do? Of course we do. Why do you think my position on this subject has always been, "Write caching is fine so long as you use a UPS"? >If writes are committed in dependency order, and the write is cached >and there is no reordering of subsequent writes (ie: writes occur in >tag order, even if they are cached), then I think this satisifies soft >updates. You have no guarantee that the writes will be committed to the media in the order that they were reported as completed to the host if you use write caching. You do have a guarantee, however, that the cache contents are always consistent and if you allow the drive to flush it's cache, the media will eventually be consistent as well. >> >There were directory dependencies which were committed out of order >> >(the modified fsck reports these as soft dependency errors...). >> >> Can you be more specific? Are you positive that the transactions >> were committed out of order or could it be that some transactions >> were never committed at all? > >Transactions were committed out of order. If the transactions that >had been committed had been committed in order, then the loss of cached >transactions would only result in a rewind of state of the drive to >a previous state. The previous state, by definition, must also be >consistent. This is consistent with losing transactions. Certainly the writes could have been written out of order, but the failure should only occur if the drive loses transactions that were considered complete by the host. This should only happen by way of a power loss or power spike. >In other words, transaction dependency order as required for soft >updates must cause commits to the drives to occur in dependency >order, and the problem is the reordering of consecutive write >requests by the drive itself if there is *ever* a case where the >state is ever inconsistent. This is why you must have a UPS. I thought we already went over this before... >The only alternative is a dependency order bug, and such a bug >would be very easy to reproduce using a break-to-debugger or a >reset+fsck. Only if your break or reset+fsck hits at exactly the right time. You've used this argument yourself. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 22:23:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11353 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 22:23:31 -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 WAA11344; Tue, 13 Oct 1998 22:23:29 -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 XAA15206; Tue, 13 Oct 1998 23:23:12 -0600 (MDT) Message-Id: <199810140523.XAA15206@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: "Justin T. Gibbs" , Terry Lambert , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Tue, 13 Oct 1998 21:39:50 PDT." <199810140439.VAA17463@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Oct 1998 23:16:27 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} This doesn't follow. If the cache is disabled, it doesn't matter if >} the drive loses power due to hitting the reset button. We already >} know that losing power on a drive that cached data will not work. > >I didn't hear the sound of any mechanical things spinning down. The >machine just started going through its boot sequence. The drive will reinitialize to the 'power on state' if the power fluctuates into a zone that might invalidate it's run-time state. It doesn't take a very long spike for the drive's power-glitch sensor to go off. In this case, dropping cached contents on the floor is much safer than attempting to continue from an unknown state. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 22:59:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15224 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 22:59:51 -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 WAA15215; Tue, 13 Oct 1998 22:59:45 -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 WAA09857; Tue, 13 Oct 1998 22:59:27 -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 WAA25064; Tue, 13 Oct 1998 22:59:26 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA17612; Tue, 13 Oct 1998 22:59:24 -0700 (PDT) From: Don Lewis Message-Id: <199810140559.WAA17612@salsa.gv.tsc.tdk.com> Date: Tue, 13 Oct 1998 22:59:24 -0700 In-Reply-To: "Justin T. Gibbs" "Re: filesystem safety and SCSI disk write caching" (Oct 13, 11:16pm) 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: Terry Lambert , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 13, 11:16pm, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } >} This doesn't follow. If the cache is disabled, it doesn't matter if } >} the drive loses power due to hitting the reset button. We already } >} know that losing power on a drive that cached data will not work. } > } >I didn't hear the sound of any mechanical things spinning down. The } >machine just started going through its boot sequence. } } The drive will reinitialize to the 'power on state' if the power fluctuates } into a zone that might invalidate it's run-time state. It doesn't take a } very long spike for the drive's power-glitch sensor to go off. In this } case, dropping cached contents on the floor is much safer than attempting } to continue from an unknown state. If that's the reason for the problem that I saw, then the UPS the system was plugged into wasn't sufficient to prevent the problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 13 23:08:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16596 for freebsd-scsi-outgoing; Tue, 13 Oct 1998 23:08:58 -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 XAA16591; Tue, 13 Oct 1998 23:08:56 -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 AAA16953; Wed, 14 Oct 1998 00:08:38 -0600 (MDT) Message-Id: <199810140608.AAA16953@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: "Justin T. Gibbs" , Terry Lambert , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Tue, 13 Oct 1998 22:59:24 PDT." <199810140559.WAA17612@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 00:01:53 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} The drive will reinitialize to the 'power on state' if the power fluctuates >} into a zone that might invalidate it's run-time state. It doesn't take a >} very long spike for the drive's power-glitch sensor to go off. In this >} case, dropping cached contents on the floor is much safer than attempting >} to continue from an unknown state. > >If that's the reason for the problem that I saw, then the UPS the >system was plugged into wasn't sufficient to prevent the problem. Why is that? Do you have gremlins walking around hitting the reset buttons on your machines? The UPS should isolate the machine from any drop in power that would cause it to lose its brain other than that caused by a hardware failure or an administrator hitting the reset or power switch. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 08:02:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03021 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 08:02:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03010; Wed, 14 Oct 1998 08:02:15 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA05240; Wed, 14 Oct 1998 09:01:47 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA04936; Wed, 14 Oct 1998 09:01:46 -0600 Date: Wed, 14 Oct 1998 09:01:46 -0600 Message-Id: <199810141501.JAA04936@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Terry Lambert , Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810140518.XAA15040@pluto.plutotech.com> References: <199810140049.RAA20004@usr08.primenet.com> <199810140518.XAA15040@pluto.plutotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >If writes are committed in dependency order, and the write is cached > >and there is no reordering of subsequent writes (ie: writes occur in > >tag order, even if they are cached), then I think this satisifies soft > >updates. > > You have no guarantee that the writes will be committed to the media in the > order that they were reported as completed to the host if you use write > caching. You do have a guarantee, however, that the cache contents are > always consistent and if you allow the drive to flush it's cache, the > media will eventually be consistent as well. ... > This is why you must have a UPS. I thought we already went over this > before... 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. You can argue all day long that people have broken firmware, crappy power supplies, or sun spots, but the bottom line is that CAM is making it so people's file systems are hosed when they don't have to be. Architecturally it would be nice if everyone had a UPS, a great power supply that didn't 'spike' the power line, and perfect firmware but this isn't a perfect world. Far from it. We live in an imperfect world and that won't change just because CAM likes perfection. IMO, CAM should disable write caching by default, and allow people to add it back by hand if they know how. I don't know how this would be done, but it's *ALWAYS* a better idea to be safe than to be sorry. Never optimize when the optimizations are a pessisimization for most of the users. Nate ps. I have both good firmware and a appropriately configured UPS that correctly powers down the system, so don't be yelling at me for having bad hardware. But, I'm an exception to the norm, in many ways. :) :) :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 08:09:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04181 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 08:09: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 IAA04169; Wed, 14 Oct 1998 08:09:50 -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 JAA07471; Wed, 14 Oct 1998 09:09:26 -0600 (MDT) Message-Id: <199810141509.JAA07471@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: "Justin T. Gibbs" , Terry Lambert , Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Wed, 14 Oct 1998 09:01:46 MDT." <199810141501.JAA04936@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 09:02:41 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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. Please don't add any more FUD to this thread than there is already. CAM has nothing to do with this issue. 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. 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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 08:19:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05537 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 08:19:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA05529; Wed, 14 Oct 1998 08:19:18 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA05367; Wed, 14 Oct 1998 09:18:57 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA05051; Wed, 14 Oct 1998 09:18:56 -0600 Date: Wed, 14 Oct 1998 09:18:56 -0600 Message-Id: <199810141518.JAA05051@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Terry Lambert , Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810141509.JAA07471@pluto.plutotech.com> References: <199810141501.JAA04936@mt.sri.com> <199810141509.JAA07471@pluto.plutotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >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. > > Please don't add any more FUD to this thread than there is already. > > CAM has nothing to do with this issue. Neither the old SCSI code nor the > new CAM code has ever modified the caching behavior of the devices attached > on the bus. Previous email imply that it has the ability to disable/enable write-caching the addition of quirks entries for certain devices. > My position on this is that we should *never* modify device > mode parameters unless instructed to do so by the end user. 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. Up till this point, we never had any FS code that attempted to deal with 'crashing' robustly. I for one knew that if my machine crashed, an fsck was expected and it was going to repair my disk. 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'. With better information more informed decisions can be made. (Now is that a redundant statement or what? *grin*) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 11:15:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01913 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 11:15:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01907; Wed, 14 Oct 1998 11:15:56 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA08932; Wed, 14 Oct 1998 11:08:18 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdXn8918; Wed Oct 14 18:08:11 1998 Date: Wed, 14 Oct 1998 11:08:05 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: Terry Lambert , Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810140518.XAA15040@pluto.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 Hey everybody.. look, we're in violent agreement here but haven't noticed it.... 1/ Soft updates produces a consistent view of the filesystem at the level where reported completions are generated. 2/ If there is another layer below that (a write cache) then if the transactions are re-ordered in that layer, then lower layers may not get a consistent view of the filesystem at every instant. 3/ Given time and power, the layer that generates the completion reports will sync down to the lower layers making them consistent. Lack of either will have the lower layers in an inconsitent state. 4/ Drives that do not sync down after there is a scsi reset are in danger of producing corrupted filesystems after a warm reboot. This should be considered a firmware bug. 5/ Systems that run without UPS, or want to be able to withstand more drastic failures (e.g. PSU explodes) should run without write caching, or should ensure that writes to media occur in the same order as completions are generated (not neccesarily the same as write requests as they could be re-ordered before the completions are issued). Since the latter is unlikely, the former is preferable. 6/ Since Softupdates makes all writes asychronous, the penalty for turning off write caching is very minimal. My experiments show a 1% difference in normal operation. THere are some applications however where this is not true, and these application should not consider soft updates alone to be a guarantee of FS consitency. They should have some way of guaranteeing 'time and power' (and good firmware). 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 . julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 11:53:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08201 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 11:53:33 -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 LAA08194; Wed, 14 Oct 1998 11:53:31 -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 LAA21952; Wed, 14 Oct 1998 11:53:01 -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 LAA07794; Wed, 14 Oct 1998 11:53:00 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id LAA19279; Wed, 14 Oct 1998 11:52:59 -0700 (PDT) From: Don Lewis Message-Id: <199810141852.LAA19279@salsa.gv.tsc.tdk.com> Date: Wed, 14 Oct 1998 11:52:59 -0700 In-Reply-To: "Justin T. Gibbs" "Re: filesystem safety and SCSI disk write caching" (Oct 14, 12:01am) 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: Terry Lambert , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Oct 14, 12:01am, "Justin T. Gibbs" wrote: } Subject: Re: filesystem safety and SCSI disk write caching } >} The drive will reinitialize to the 'power on state' if the power fluctuates } >} into a zone that might invalidate it's run-time state. It doesn't take a } >} very long spike for the drive's power-glitch sensor to go off. In this } >} case, dropping cached contents on the floor is much safer than attempting } >} to continue from an unknown state. } > } >If that's the reason for the problem that I saw, then the UPS the } >system was plugged into wasn't sufficient to prevent the problem. } } Why is that? Do you have gremlins walking around hitting the reset } buttons on your machines? The UPS should isolate the machine from } any drop in power that would cause it to lose its brain other than } that caused by a hardware failure or an administrator hitting the } reset or power switch. >From my point of view, I can cut the run time of something like "make buildworld" by about 25 percent by turning on softupdates. If I disable write caching on the drive, it increases the time by about 1 percent, but I don't have to worry about filesystem corruption caused by: gremlins hitting the reset button power glitches that cause the drive to forget uncommitted transactions firmware bugs that cause the drive to forget uncommitted transactions when the drive sees a SCSI reset the power supply fuse blowing the power cord getting knocked loose the UPS shutting down before the system does a clean shutdown Having an UPS and wiring it so that the system does a clean shutdown before the UPS shuts down is pretty desirable, but there are enough other common failure modes that can result in a corrupted filesystem if write caching is enabled that I don't feel it's worth the minimal performance gain that I see. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 14:54:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03096 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 14:54:34 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from quark.ChrisBowman.com (crbowman.erols.com [209.122.47.155]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA03089; Wed, 14 Oct 1998 14:54:31 -0700 (PDT) (envelope-from crb@ChrisBowman.com) Received: from fermion (fermion [10.0.1.2]) by quark.ChrisBowman.com (8.8.8/8.8.8) with SMTP id SAA17170; Wed, 14 Oct 1998 18:13:35 -0500 (EST) (envelope-from crb@ChrisBowman.com) Message-Id: <199810142313.SAA17170@quark.ChrisBowman.com> X-Sender: crb@quark X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 13 May 1998 17:54:00 -0400 To: Julian Elischer From: "Christopher R. Bowman" Subject: Re: filesystem safety and SCSI disk write caching Cc: "Justin T. Gibbs" , Terry Lambert , Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: References: <199810140518.XAA15040@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 . > > >julian 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. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.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 14 14:59:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03692 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 14:59:25 -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 OAA03687; Wed, 14 Oct 1998 14:59:23 -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 PAA00513; Wed, 14 Oct 1998 15:58:31 -0600 (MDT) Message-Id: <199810142158.PAA00513@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Christopher R. Bowman" cc: Julian Elischer , "Justin T. Gibbs" , Terry Lambert , Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Wed, 13 May 1998 17:54:00 EDT." <199810142313.SAA17170@quark.ChrisBowman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 15:51:41 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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. There is no facility to pass mount flags all the way down to a device driver. This also is not a per mount instance type of feature since several mountable partitions may reside on the same device. CAM currently lacks code to modify mode pages and maintain those modifications across bus reset and BDR events. This could be added, but it would be IMHO lots of complexity for limited gain. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 15:29:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08019 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 15:29:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dt053nb4.san.rr.com (dt053nb4.san.rr.com [204.210.34.180]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07994; Wed, 14 Oct 1998 15:28:39 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from gorean.org (Studded@localhost [127.0.0.1]) by dt053nb4.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA08969; Wed, 14 Oct 1998 15:28:11 -0700 (PDT) (envelope-from Studded@gorean.org) Message-ID: <3625257B.B7C3B935@gorean.org> Date: Wed, 14 Oct 1998 15:28:11 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.5b2 [en] (X11; I; FreeBSD 2.2.7-STABLE-1009 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" CC: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching References: <199810141509.JAA07471@pluto.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 "Justin T. Gibbs" wrote: > 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. Which user community are you referring to? Has this write caching always been present, or was it introduced by CAM? If you're referring to the community of all freebsd users, I think your statement is reasonable. If you are referring to the community of CAM users, that is an extremely small subset of freebsd's installed base, so expecting serious problems introduced in CAM to have all cropped up now is not reasonable. Please note that nothing in this post should be construed as critical to the CAM team. It's a huge undertaking and all signs are that it will be a very beneficial addition to freebsd. Doug -- *** Chief Operations Officer, DALnet IRC network *** Go PADRES! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 15:55:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12543 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 15:55:05 -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 PAA12538; Wed, 14 Oct 1998 15:55:03 -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 QAA04647; Wed, 14 Oct 1998 16:54:39 -0600 (MDT) Message-Id: <199810142254.QAA04647@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Studded 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 "Wed, 14 Oct 1998 15:28:11 PDT." <3625257B.B7C3B935@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 16:47:49 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Which user community are you referring to? All of FreeBSD. >Has this write caching always been present, or was it introduced by CAM? It has always been present. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 15:56:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12938 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 15:56:29 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from primenet.com (usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA12517 for ; Wed, 14 Oct 1998 15:54:56 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Date: Wed, 14 Oct 1998 15:54:56 -0700 (PDT) From: tlambert@usr04.primenet.com Message-Id: <199810142254.PAA12517@hub.freebsd.org> To: undisclosed-recipients:; Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >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. > > > > Please don't add any more FUD to this thread than there is already. > > > > CAM has nothing to do with this issue. Neither the old SCSI code nor the > > new CAM code has ever modified the caching behavior of the devices attached > > on the bus. > > Previous email imply that it has the ability to disable/enable > write-caching the addition of quirks entries for certain devices. Actually, the write-caching discussion is orthogonal, and has to do with a seperate series on: o How to enable write caching o Write caching is bad o No it's not o Yes it is o No it's not o Yes it is, and here's an example of where it breaks things o Machines don't reset except when they lose power o Yes they do o No they don't, and write caching isn't bad, it's the bogus assumptions by soft updates that are bad o No it isn't o Yes it is o No it isn't, because a sync mounted filesystem makes the same assumptions about queue-order completion Ok, ok, I've gone a little farther down the thread than the thread has currently done, but it's really what's coming. Terry Lambert terry@lambert.org From: Terry Lambert Message-Id: <199810142251.PAA02490@usr04.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: nate@mt.sri.com (Nate Williams) Date: Wed, 14 Oct 1998 22:51:30 +0000 (GMT) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810141518.JAA05051@mt.sri.com> from "Nate Williams" at Oct 14, 98 09:18:56 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > >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. > > > > Please don't add any more FUD to this thread than there is already. > > > > CAM has nothing to do with this issue. Neither the old SCSI code nor the > > new CAM code has ever modified the caching behavior of the devices attached > > on the bus. > > Previous email imply that it has the ability to disable/enable > write-caching the addition of quirks entries for certain devices. Actually, the write-caching discussion is orthogonal, and has to do with a seperate series on: o How to enable write caching o Write caching is bad o No it's not o Yes it is o No it's not o Yes it is, and here's an example of where it breaks things o Machines don't reset except when they lose power o Yes they do o No they don't, and write caching isn't bad, it's the bogus assumptions by soft updates that are bad o No it isn't o Yes it is o No it isn't, because a sync mounted filesystem makes the same assumptions about queue-order completion Ok, ok, I've gone a little farther down the thread than the thread has currently done, but it's really what's coming. Terry Lambert terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 16:01:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13766 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 16:01:42 -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 QAA13761; Wed, 14 Oct 1998 16:01:40 -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 RAA06139; Wed, 14 Oct 1998 17:01:12 -0600 (MDT) Message-Id: <199810142301.RAA06139@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Wed, 14 Oct 1998 22:40:09 -0000." <199810142240.PAA01660@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 16:54:22 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I think the moral of this story is that you can't rely on UPS's, >and instead should only rely on single-state-transition based >finite state automatons if you need to be able to rely on anything. 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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 18:07:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01683 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 18:07:13 -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 SAA01655; Wed, 14 Oct 1998 18:07:09 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt1-47.HiWAAY.net [208.147.147.47]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id UAA31706; Wed, 14 Oct 1998 20:06:50 -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 TAA12721; Wed, 14 Oct 1998 19:15:36 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199810150015.TAA12721@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: 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 "Tue, 13 Oct 1998 22:59:24 PDT." <199810140559.WAA17612@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 19:15:36 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis writes: > On Oct 13, 11:16pm, "Justin T. Gibbs" wrote: > } Subject: Re: filesystem safety and SCSI disk write caching > } >} This doesn't follow. If the cache is disabled, it doesn't matter if > } >} the drive loses power due to hitting the reset button. We already > } >} know that losing power on a drive that cached data will not work. > } > > } >I didn't hear the sound of any mechanical things spinning down. The > } >machine just started going through its boot sequence. > } > } The drive will reinitialize to the 'power on state' if the power fluctuates > } into a zone that might invalidate it's run-time state. It doesn't take a > } very long spike for the drive's power-glitch sensor to go off. In this > } case, dropping cached contents on the floor is much safer than attempting > } to continue from an unknown state. > > If that's the reason for the problem that I saw, then the UPS the > system was plugged into wasn't sufficient to prevent the problem. 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. 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. Switching power supplies need to be able to run thru a missed cycle or so. Or at least for 4 milliseconds. Inexpensive UPS's are "on-demand" and can take as long as 4 milliseconds to detect dropped power and come to the rescue. Otherwise on-demand UPS's are doing nothing. They might be acting as "surge suppressors". Bought a Best Power Inc, FerrUPS 700 a couple of years ago at a hamfest for $125. This UPS uses a ferro-resonant autotransformer and is online 100%. My voltmeter says its putting out 125VAC while my line voltage is 119. It also keeps my feet warm. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 18:07:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01714 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 18:07:17 -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 SAA01651; Wed, 14 Oct 1998 18:07:06 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt1-47.HiWAAY.net [208.147.147.47]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id UAA00627; Wed, 14 Oct 1998 20:06:48 -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 TAA12754; Wed, 14 Oct 1998 19:32:40 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199810150032.TAA12754@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: 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 Julian Elischer of "Wed, 14 Oct 1998 11:08:05 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 19:32:40 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > Hey everybody.. > look, we're in violent agreement here but haven't noticed it.... [...] > 3/ Given time and power, the layer that generates the completion reports > will sync down to the lower layers making them consistent. Lack of either > will have the lower layers in an inconsitent state. > > 4/ Drives that do not sync down after there is a scsi reset are in danger > of producing corrupted filesystems after a warm reboot. This should be > considered a firmware bug. This reminds me of PowerMac thing that cropped up a couple of years ago. MacUser and MacWorld published "comparison" tests of HD's and would happily rate Brand A's superior to Brand B's when both were the same HD simply because A's was faster in their benchmarks. Then people blindly bought the "superior" package over the other. So vendors shipped drives to maximize benchmark performance. Including enable of whatever write caching the drive could do internally. The problem that cropped up was that PowerMacs can turn themselves off. Including the internal HD. And on shutdown would turn themselves off so fast the HD lost unwritten cached data. About the last thing a Mac writes to a disk on shutdown is its clean flag. Users were being reminded on reboot that they were supposed to do a "Shutdown from the Special... menu" rather than yank the power. Eventually the driver writers (Apple's SCSI driver won't talk to non-Apple OEM'ed HD's) implemented a flush on final close. So the driver busy-waited until it thought the data was synced. If somebody is punching the CPU RESET, then there isn't much software can do to overcome deficiencies of firmware. Users with external HD's didn't have this "problem" because they had to turn off their HD's manually. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Oct 14 21:20:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA29232 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 21:20:03 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA29178; Wed, 14 Oct 1998 21:19:56 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.1/8.9.1) id XAA18802; Wed, 14 Oct 1998 23:19:26 -0500 (CDT) Date: Wed, 14 Oct 1998 23:19:25 -0500 From: Dan Nelson To: Julian Elischer , "Justin T. Gibbs" Cc: Terry Lambert , Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <19981014231925.A18446@emsphone.com> References: <199810140518.XAA15040@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=HlL+5n6rz5pIUxbD X-Mailer: Mutt 0.94.3i In-Reply-To: ; from "Julian Elischer" on Wed Oct 14 11:08:05 GMT 1998 X-OS: FreeBSD 2.2.7-STABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii In the last episode (Oct 14), Julian Elischer said: > Hey everybody.. > look, we're in violent agreement here but haven't noticed it.... > > 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 . 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. -Dan Nelson dnelson@emsphone.com --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cachecheck #! /bin/sh echo Checking SCSI drives for write-cache: numbad=0 # get a list of direct-access devices known to the system units=$(camcontrol devlist | sed -n -e "/,da[0-9]*/s/.*,da\(.*\))/\1/p") for i in $units do result=$(camcontrol modepage -m 8 -P 3 -u $i 2> /dev/null | grep WCE) if [ "$result" = "WCE: 1 " ] ; then camcontrol devlist | grep ",da${i})" numbad=$(($numbad + 1)) fi done if [ $numbad -gt 0 ] ; then s= [ $numbad -ne 1 ] && s=s echo " $numbad device$s with WCE set. To reset, run \"camcontrol modepage -e -P 3 -m 8 -u \" where is the disk number (i.e. da0 is unit #0), and set WCE to 0." fi echo --HlL+5n6rz5pIUxbD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 01:13:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA21402 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 01:13:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA21397; Thu, 15 Oct 1998 01:13:32 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA03171; Thu, 15 Oct 1998 01:10:45 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdze3167; Thu Oct 15 08:10:40 1998 Date: Thu, 15 Oct 1998 01:10:37 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: Studded , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810142254.QAA04647@pluto.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 The reason it comes up now is because the promise of soft updates to make a 'safer and faster filesystem' is threatenned by it. Inthe pas the 'sync' filesystem was known to have problem with crashes. and everybody just took that in their stride and didn't try find a reason for it. However with soft updates, there is a theoretical behaviour that is easy to understand and when a filesystem doesn't behae that way it become obvious.. the difference between 45 filesystem eros and 47 is not that great. The difference between 0 and 2 is much more noticeable, even though it's still only 2 errors. These problems have probably always occured. they were just not so obvious. On Wed, 14 Oct 1998, Justin T. Gibbs wrote: > > Which user community are you referring to? > > All of FreeBSD. > > >Has this write caching always been present, or was it introduced by CAM? > > It has always been present. > > -- > Justin > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 03:49:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA03469 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 03:49:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA03463 for ; Thu, 15 Oct 1998 03:49:19 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.8.8/8.8.8) id LAA15067 for freebsd-scsi@freebsd.org; Thu, 15 Oct 1998 11:48:59 +0100 (BST) (envelope-from joe) Message-ID: <19981015114859.A13964@pavilion.net> Date: Thu, 15 Oct 1998 11:48:59 +0100 From: Josef Karthauser To: freebsd-scsi@FreeBSD.ORG Subject: Official way to detect CAM? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-1273-607072 Fax: +44-1273-607073 Mobile: +44-403-596893 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm working on Amanda so that it natively works with the new ch0 definitions which had changed during the CAM insertion. Can someone point me to the official way to detect whether CAM is installed. Making assumptions about version 2.2.X vs 3.X isn't good enough because it breaks for people running the CAM kit. Thanks, Joe -- Josef Karthauser Technical Manager FreeBSD: The power to serve (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 06:04:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17760 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 06:04:03 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17706 for ; Thu, 15 Oct 1998 06:04:01 -0700 (PDT) (envelope-from ckempf@singularity.enigami.com) Received: (from ckempf@localhost) by singularity.enigami.com (8.9.1/8.9.1) id JAA14508; Thu, 15 Oct 1998 09:03:43 -0400 (EDT) To: Josef Karthauser , freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? References: <19981015114859.A13964@pavilion.net> X-Copyright: Copyright (C) 1998 Cory Kempf. All Rights Reserved X-PGP-Fingerprint: 191E 2FB7 E27D 76C3 8E79 4D26 2B3B B20F 2A9C 1E1A X-PGP-Keyloc: ; finger ckempf@enigami.com From: Cory Kempf Date: 15 Oct 1998 09:03:42 -0400 In-Reply-To: Josef Karthauser's message of "Thu, 15 Oct 1998 11:48:59 +0100" Message-ID: Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Josef Karthauser writes: >Can someone point me to the official way to detect whether CAM is >installed. Making assumptions about version 2.2.X vs 3.X isn't >good enough because it breaks for people running the CAM kit. Check for the presense of /usr/include/camlib.h. If the file exists, the system is CAM (or really messed up!) This is how I was told to detect in SANE. +C -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: Cory Kempf Macintosh / Unix Consulting & Software Development ckempf@enigami.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 15 06:49:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23133 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 06:49:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA23125 for ; Thu, 15 Oct 1998 06:49:45 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id PAA22306; Thu, 15 Oct 1998 15:49:00 +0200 (MET DST) Date: Thu, 15 Oct 1998 15:48:58 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Cory Kempf cc: Josef Karthauser , freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Or execute camcontrol periphlist and look for '^ch[0-9]:' Makes it possible to at the same time present a menu if multiple changers are present. Just my 0.02ECU worth. Nick > >Can someone point me to the official way to detect whether CAM is > >installed. Making assumptions about version 2.2.X vs 3.X isn't > >good enough because it breaks for people running the CAM kit. > > Check for the presense of /usr/include/camlib.h. If the file exists, > the system is CAM (or really messed up!) > > This is how I was told to detect in SANE. > > +C > -- > Thinking of purchasing RAM from the Chip Merchant? > Please read this first: > > Cory Kempf Macintosh / Unix Consulting & Software Development > ckempf@enigami.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > -- building: 27A address: STA-ISIS, T.P.270, Joint Research Centre, 21020 Ispra, Italy tel.: +39 332 78 9549 fax.: +39 332 78 9185 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 07:38:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01686 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 07:38:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA01678 for ; Thu, 15 Oct 1998 07:38:27 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.8.8/8.8.8) id PAA26303; Thu, 15 Oct 1998 15:37:52 +0100 (BST) (envelope-from joe) Message-ID: <19981015153752.B20149@pavilion.net> Date: Thu, 15 Oct 1998 15:37:52 +0100 From: Josef Karthauser To: Nick Hibma , Cory Kempf Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Nick Hibma on Thu, Oct 15, 1998 at 03:48:58PM +0200 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-1273-607072 Fax: +44-1273-607073 Mobile: +44-403-596893 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Oct 15, 1998 at 03:48:58PM +0200, Nick Hibma wrote: > > Or execute > > camcontrol periphlist > > and look for '^ch[0-9]:' > > Makes it possible to at the same time present a menu if multiple > changers are present. That looks like a better solution. The first one was simpler for the purposes of the amanda configure script though, the goal being that Amanda could compile out of the box on FreeBSD-3.x, which it currently can't. For now they will use the command line chio program with a perl wrapper until someone gets around to modifying the scsi-chg program to use the new structures. Cheers, Joe -- Josef Karthauser Technical Manager FreeBSD: The power to serve (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 08:24:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07412 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 08:24:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07403 for ; Thu, 15 Oct 1998 08:24:12 -0700 (PDT) (envelope-from randy@psg.com) Received: from localhost (836 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Thu, 15 Oct 1998 08:23:54 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #1 built 1998-Oct-13) Message-Id: Date: Thu, 15 Oct 1998 08:23:54 -0700 (PDT) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Josef Karthauser Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? References: <19981015153752.B20149@pavilion.net> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Or execute >> camcontrol periphlist >> and look for '^ch[0-9]:' >> Makes it possible to at the same time present a menu if multiple >> changers are present. > That looks like a better solution. foux:/root# camcontrol periphlist pass0: generation: 4 index: 1 status: MORE da0: generation: 4 index: 2 status: LAST bit i know think i am running cam and so did dmesg. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 08:57:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11860 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 08:57: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 IAA11843 for ; Thu, 15 Oct 1998 08:56:58 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id JAA17897; Thu, 15 Oct 1998 09:55:57 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810151555.JAA17897@panzer.plutotech.com> Subject: Re: Official way to detect CAM? In-Reply-To: from Nick Hibma at "Oct 15, 98 03:48:58 pm" To: nick.hibma@jrc.it Date: Thu, 15 Oct 1998 09:55:57 -0600 (MDT) Cc: ckempf@enigami.com, joe@pavilion.net, 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 Nick Hibma wrote... > > Or execute > > camcontrol periphlist > > and look for '^ch[0-9]:' > > Makes it possible to at the same time present a menu if multiple > changers are present. Well, that probably won't do what you want. The 'periphlist' function just prints out the list of peripherals attached to the given device. e.g.: {roadwarrior:/usr/home/ken:1:0} camcontrol periphlist -n da -u 1 pass1: generation: 4 index: 1 status: MORE da1: generation: 4 index: 2 status: LAST {roadwarrior:/usr/home/ken:2:0} camcontrol periphlist pass0: generation: 4 index: 1 status: MORE da0: generation: 4 index: 2 status: LAST You'll probably want to use 'camcontrol devlist' piped through a script to find all of the changers. (i.e. something like Dan Nelson's script) Sometime or another it might be nice to add command line pattern matching code to camcontrol. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 11:22:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA04663 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 11:22: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 LAA04633; Thu, 15 Oct 1998 11:22:24 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA21062; Thu, 15 Oct 1998 11:22:02 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd021045; Thu Oct 15 11:21:58 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA15497; Thu, 15 Oct 1998 11:21:55 -0700 (MST) From: Terry Lambert Message-Id: <199810151821.LAA15497@usr02.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: dkelly@hiwaay.net (David Kelly) Date: Thu, 15 Oct 1998 18:21:55 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810150015.TAA12721@nospam.hiwaay.net> from "David Kelly" at Oct 14, 98 07:15:36 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 > > If that's the reason for the problem that I saw, then the UPS the > > system was plugged into wasn't sufficient to prevent the problem. > > Before you fight it too much more, replace the power supply. I've cured > a number of "impossible" problems with a new power supply. Uh, you won't cure "Don punching the reset button to simulate a particular set of hardware failures" with a new supply. 8-). 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 Thu Oct 15 13:03:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20769 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 13:03:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20764 for ; Thu, 15 Oct 1998 13:03:35 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA22133; Thu, 15 Oct 1998 12:45:31 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdX22131; Thu Oct 15 19:45:29 1998 Date: Thu, 15 Oct 1998 12:45:26 -0700 (PDT) From: Julian Elischer To: "Kenneth D. Merry" cc: nick.hibma@jrc.it, ckempf@enigami.com, joe@pavilion.net, freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? In-Reply-To: <199810151555.JAA17897@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 Are there no sysctl tunables for cam? that would be definative.. On Thu, 15 Oct 1998, Kenneth D. Merry wrote: > Nick Hibma wrote... > > > > Or execute > > > > camcontrol periphlist > > > > and look for '^ch[0-9]:' > > > > Makes it possible to at the same time present a menu if multiple > > changers are present. > > Well, that probably won't do what you want. The 'periphlist' function just > prints out the list of peripherals attached to the given device. e.g.: > > {roadwarrior:/usr/home/ken:1:0} camcontrol periphlist -n da -u 1 > pass1: generation: 4 index: 1 status: MORE > da1: generation: 4 index: 2 status: LAST > > {roadwarrior:/usr/home/ken:2:0} camcontrol periphlist > pass0: generation: 4 index: 1 status: MORE > da0: generation: 4 index: 2 status: LAST > > You'll probably want to use 'camcontrol devlist' piped through a script to > find all of the changers. (i.e. something like Dan Nelson's script) > > Sometime or another it might be nice to add command line pattern matching > code to camcontrol. > > Ken > -- > Kenneth Merry > ken@plutotech.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 13:11:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21882 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 13:11:07 -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 NAA21877 for ; Thu, 15 Oct 1998 13:11:06 -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 NAA20826; Thu, 15 Oct 1998 13:10:03 -0700 (PDT) Date: Thu, 15 Oct 1998 13:10:03 -0700 (PDT) From: Chris Timmons To: Josef Karthauser cc: Nick Hibma , Cory Kempf , freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? In-Reply-To: <19981015153752.B20149@pavilion.net> 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 Actually the slightly dated port of amanda24 in the ports collection compiles and runs just fine on 3.0-current ELF, but I have the changer functions stubbed out. Please be sure to submit your changes back to the amanda team, and let me know, too - I'll update the port some more. I think the first test for cam should be to look for camlib.h; after that, if you find it - then use camcontrol. We want to make sure that amanda compiles and runs on 2.2.x which may or may not have CAM... regards, -Chris On Thu, 15 Oct 1998, Josef Karthauser wrote: > On Thu, Oct 15, 1998 at 03:48:58PM +0200, Nick Hibma wrote: > > > > Or execute > > > > camcontrol periphlist > > > > and look for '^ch[0-9]:' > > > > Makes it possible to at the same time present a menu if multiple > > changers are present. > > That looks like a better solution. The first one was simpler for > the purposes of the amanda configure script though, the goal being > that Amanda could compile out of the box on FreeBSD-3.x, which it > currently can't. For now they will use the command line chio > program with a perl wrapper until someone gets around to modifying > the scsi-chg program to use the new structures. > > Cheers, > Joe > -- > Josef Karthauser > Technical Manager FreeBSD: The power to serve (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 13:54:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA29878 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 13:54:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA29835 for ; Thu, 15 Oct 1998 13:54:24 -0700 (PDT) (envelope-from rsi@mindspring.com) Received: from kamikaze.mindspring.com (pool-207-205-162-97.nwrk.grid.net [207.205.162.97]) by camel7.mindspring.com (8.8.5/8.8.5) with ESMTP id QAA29479 for ; Thu, 15 Oct 1998 16:53:29 -0400 (EDT) Received: (from rsi@localhost) by kamikaze.mindspring.com (8.9.1/8.8.7) id QAA00765; Thu, 15 Oct 1998 16:53:39 -0400 (EDT) (envelope-from rsi) Message-Id: <199810152053.QAA00765@kamikaze.mindspring.com> To: freebsd-scsi@FreeBSD.ORG Subject: Frequent failures with ncr0 From: Rajappa Iyer Date: 15 Oct 1998 16:52:58 -400 Reply-To: rajappa@mindspring.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been getting frequent failures with ncr0 after upgrading to CAM. I saw from the mailing archives that others are experiencing similar problems, but did not see any resolution. Is there any work around for this? Please help. FYI, this is a Tekram-390F card. Thanks, Rajappa Here's the message I get: Oct 15 14:33:52 kamikaze /kernel: ncr0:0: ERROR (0:4) (8-0-0) (f/1b) @ (script 73c:190000de). Oct 15 14:33:52 kamikaze /kernel: ncr0: script cmd = 89030000 Oct 15 14:33:52 kamikaze /kernel: ncr0: regdump: da 00 80 1b 47 0f 00 07 03 08 80 00 80 00 01 0a. Oct 15 14:33:52 kamikaze /kernel: ncr0: have to clear fifos. Oct 15 14:33:52 kamikaze /kernel: ncr0:0: ERROR (0:c1) (e-ae-0) (f/1b) @ (script c0:1e000000). Oct 15 14:33:52 kamikaze /kernel: ncr0: script cmd = 60000008 Oct 15 14:33:52 kamikaze /kernel: ncr0: regdump: da 10 80 1b 47 0f 00 07 00 0e 80 ae 00 00 06 08. Oct 15 14:33:52 kamikaze /kernel: ncr0: have to clear fifos. Oct 15 14:33:52 kamikaze /kernel: ncr0: restart (fatal error). Oct 15 14:33:52 kamikaze /kernel: (da0:ncr0:0:0:0): COMMAND FAILED (9 ff) @0xf08e6c00. Oct 15 14:33:52 kamikaze /kernel: (da0:ncr0:0:0:0): COMMAND FAILED (9 ff) @0xf08e6e00. # dmesg [...] Probing for devices on PCI bus 0: chip0: rev 0x00 on pci0.0.0 chip1: rev 0x00 on pci0.1.0 wdc0: rev 0x02 int a irq 14 on pci0.2.0 ncr0: rev 0x03 int a irq 10 on pci0.3.0 vga0: rev 0x00 int a irq 11 on pci0.4.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x260-0x27f irq 5 on isa ed0: address 00:40:05:1e:ec:be, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 flags 0x10 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 lpt1 not found fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: CMD640B workaround enabled wdc0: unit 0 (wd0): wd0: 814MB (1667232 sectors), 1654 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, intr, iordy wcd0: 689Kb/sec, 128Kb cache, audio play, 255 volume levels, ejectable tray wcd0: 120mm data disc loaded, unlocked npx0 on motherboard npx0: INT 16 interface Intel Pentium F00F detected, installing workaround Waiting 15 seconds for SCSI devices to settle changing root device to wd0s1a da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 20.0MB/s transfers (10.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C) # uname -a FreeBSD kamikaze.mindspring.com 3.0-BETA FreeBSD 3.0-BETA #1: Wed Oct 14 19:48:39 EDT 1998 root@kamikaze.mindspring.com:/a/kamikaze/homes/kamikaze/src/sys/compile/KAMIKAZE i386 -- a.k.a. Rajappa Iyer. New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 13:59:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00988 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 13:59: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 NAA00970 for ; Thu, 15 Oct 1998 13:59:41 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id OAA19882; Thu, 15 Oct 1998 14:59:11 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810152059.OAA19882@panzer.plutotech.com> Subject: Re: Official way to detect CAM? In-Reply-To: from Julian Elischer at "Oct 15, 98 12:45:26 pm" To: julian@whistle.com (Julian Elischer) Date: Thu, 15 Oct 1998 14:59: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 Julian Elischer wrote... > Are there no sysctl tunables for cam? > that would be definative.. The only sysctl variables are for the CD driver, and you wouldn't be able to detect that unless you've got the CD driver in your kernel. Checking for camlib.h is probably the best way, since most userland SCSI applications won't be able to compile without it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 14:26:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA09335 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 14:26:17 -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 OAA09226 for ; Thu, 15 Oct 1998 14:26:05 -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 RAA21973 for ; Thu, 15 Oct 1998 17:25:43 -0400 (EDT) Date: Thu, 15 Oct 1998 17:25:43 -0400 (EDT) From: "Matthew N. Dodd" To: scsi@FreeBSD.ORG Subject: Strange error 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 eisa-test# dmesg | grep da2 da2 at bt0 bus 0 target 2 lun 0 da2: Removable Direct Access SCSI2 device da2: 5.0MB/s transfers (5.0MHz, offset 8) da2: Attempt to query device size failed: NOT READY, Medium not present (I've booted with no media in the drive.) 'chio status' (after a 'chio move slot 15 drive 0') ... drive 0: eisa-test# camcontrol tur -n da -u 2 -v Unit is not ready (pass3:bt0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass3:bt0:0:2:0): NOT READY asc:4,2 (pass3:bt0:0:2:0): Logical unit not ready, initializing cmd. required Ok, that seems reasonable enough... eisa-test# camcontrol start -n da -u 2 -v Error received from start unit command (pass3:bt0:0:2:0): STOP START UNIT. CDB: 1b 0 0 0 1 0 (pass3:bt0:0:2:0): HARDWARE FAILURE asc:44,0 (pass3:bt0:0:2:0): Internal target failure sks:80,2 WTF does 'sks:80,2' tell me? -- | 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 Thu Oct 15 15:14:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA16897 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 15:14:46 -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 PAA16883 for ; Thu, 15 Oct 1998 15:14:37 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id QAA07631; Thu, 15 Oct 1998 16:07:11 -0600 (MDT) Date: Thu, 15 Oct 1998 16:07:11 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810152207.QAA07631@narnia.plutotech.com> To: rajappa@mindspring.com cc: scsi@FreeBSD.ORG Subject: Re: Frequent failures with ncr0 Newsgroups: pluto.freebsd.scsi In-Reply-To: <199810152053.QAA00765@kamikaze.mindspring.com> 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 <199810152053.QAA00765@kamikaze.mindspring.com> you wrote: > I've been getting frequent failures with ncr0 after upgrading to CAM. > I saw from the mailing archives that others are experiencing similar > problems, but did not see any resolution. Is there any work around > for this? Please help. FYI, this is a Tekram-390F card. > > Thanks, > Rajappa > > Here's the message I get: > > Oct 15 14:33:52 kamikaze /kernel: ncr0:0: ERROR (0:4) (8-0-0) (f/1b) @ (script 73c:190000de). If I'm decifering this correctly, it seems that the SCSI bus is hung with REQ active. Could be a cabling or termination problem brought out by the higher transactional loads that CAM can produce. -- 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 15 15:37:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20862 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 15:37:08 -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 PAA20848 for ; Thu, 15 Oct 1998 15:37:03 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA20556; Thu, 15 Oct 1998 16:36:32 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810152236.QAA20556@panzer.plutotech.com> Subject: Re: Strange error In-Reply-To: from "Matthew N. Dodd" at "Oct 15, 98 05:25:43 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Thu, 15 Oct 1998 16:36:32 -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... > > eisa-test# dmesg | grep da2 > da2 at bt0 bus 0 target 2 lun 0 > da2: Removable Direct Access SCSI2 device > da2: 5.0MB/s transfers (5.0MHz, offset 8) > da2: Attempt to query device size failed: NOT READY, Medium not present > > (I've booted with no media in the drive.) > > 'chio status' (after a 'chio move slot 15 drive 0') > ... > drive 0: Your changer shouldn't have any effect on a removable media drive... > eisa-test# camcontrol tur -n da -u 2 -v > Unit is not ready > (pass3:bt0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass3:bt0:0:2:0): NOT READY asc:4,2 > (pass3:bt0:0:2:0): Logical unit not ready, initializing cmd. required > > Ok, that seems reasonable enough... Yep, it wants to be spun up. > eisa-test# camcontrol start -n da -u 2 -v > Error received from start unit command > (pass3:bt0:0:2:0): STOP START UNIT. CDB: 1b 0 0 0 1 0 > (pass3:bt0:0:2:0): HARDWARE FAILURE asc:44,0 > (pass3:bt0:0:2:0): Internal target failure sks:80,2 > > WTF does 'sks:80,2' tell me? It's a sense key specific error. In this case, the "0x80" part means that the sense key specific value is valid. The "2" part is the "actual retry count". Here's a quote from the SCSI 2 spec: ================= The actual retry count field returns implementation-specific information on the actual number of retries of the recovery algorithm used in attempting to recover an error or exception condition. NOTE 88 This field should relate to the retry count fields within the error recovery page of the MODE SELECT command. ================= Did you have a disk in the drive at the time? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 15:45:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21535 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 15:45:44 -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 PAA21529 for ; Thu, 15 Oct 1998 15:45:41 -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 SAA22902; Thu, 15 Oct 1998 18:45:20 -0400 (EDT) Date: Thu, 15 Oct 1998 18:45:20 -0400 (EDT) From: "Matthew N. Dodd" To: "Kenneth D. Merry" cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <199810152236.QAA20556@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 Thu, 15 Oct 1998, Kenneth D. Merry wrote: > > 'chio status' (after a 'chio move slot 15 drive 0') > > ... > > drive 0: > > Your changer shouldn't have any effect on a removable media drive... I'm using this to verify that a media unit is loaded into the drive. > Yep, it wants to be spun up. Which is odd as auto-spinup is enabled. > > WTF does 'sks:80,2' tell me? > > It's a sense key specific error. In this case, the "0x80" part means that > the sense key specific value is valid. The "2" part is the "actual retry > count". Here's a quote from the SCSI 2 spec: > > ================= > The actual retry count field returns implementation-specific information on > the actual number of retries of the recovery algorithm used in attempting to > recover an error or exception condition. > > NOTE 88 This field should relate to the retry count fields within the > error recovery page of the MODE SELECT command. > ================= > > Did you have a disk in the drive at the time? Yep, see above. I'll pull this unit and try my spare when I get home. -- | 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 Thu Oct 15 15:50:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22115 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 15:50:20 -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 PAA22102 for ; Thu, 15 Oct 1998 15:50:12 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA20702; Thu, 15 Oct 1998 16:49:46 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810152249.QAA20702@panzer.plutotech.com> Subject: Re: Strange error In-Reply-To: from "Matthew N. Dodd" at "Oct 15, 98 06:45:20 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Thu, 15 Oct 1998 16:49:46 -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 Thu, 15 Oct 1998, Kenneth D. Merry wrote: > > > 'chio status' (after a 'chio move slot 15 drive 0') > > > ... > > > drive 0: > > > > Your changer shouldn't have any effect on a removable media drive... > > I'm using this to verify that a media unit is loaded into the drive. What sort of device is this? A removable disk changer? > > Did you have a disk in the drive at the time? > > Yep, see above. > > I'll pull this unit and try my spare when I get home. Yeah, it may be having hardware trouble of some sort. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 18:00:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA08771 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 18:00:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA08685 for ; Thu, 15 Oct 1998 18:00:06 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.8.8/8.8.8/SNNS-1.02) id TAA10370 for scsi@freebsd.org; Thu, 15 Oct 1998 19:59:46 -0500 (CDT) From: Joe Greco Message-Id: <199810160059.TAA10370@aurora.sol.net> Subject: ncrcontrol-like utility for CAM? To: scsi@FreeBSD.ORG Date: Thu, 15 Oct 1998 19:59:46 -0500 (CDT) 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 Will there be an ncrcontrol-like utility for CAM? I'm mainly interested in statistics, and was unable to find anything obvious after looking over the CAM stuff in 3.0-19981015-BETA. It'd be a nice addition, and it was a feature I had always missed with the ahc (and others) driver. In either case, CAM appears to be working very well on one of my big machines, with an NCR and an AHA3940. Very nice work! ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 18:28:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12383 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 18:28:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from laker.net (jet.laker.net [205.245.74.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12378 for ; Thu, 15 Oct 1998 18:28:44 -0700 (PDT) (envelope-from sfriedri@laker.net) Received: from nt (digital-pbi-130.laker.net [208.0.233.30]) by laker.net (8.9.0/8.9.LAKERNET.NO-SPAM.SPAMMERS.AND.RELAYS.WILL.BE.TRACKED.AND.PROSECUTED.) with SMTP id VAA03092; Thu, 15 Oct 1998 21:28:18 -0400 Message-Id: <199810160128.VAA03092@laker.net> From: "Steve Friedrich" To: "Julian Elischer" , "Kenneth D. Merry" Cc: "freebsd-scsi@FreeBSD.ORG" Date: Thu, 15 Oct 1998 21:27:22 -0400 Reply-To: "Steve Friedrich" X-Mailer: PMMail 98 Professional (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Official way to detect CAM? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Oct 1998 14:59:11 -0600 (MDT), Kenneth D. Merry wrote: >Julian Elischer wrote... >> Are there no sysctl tunables for cam? >> that would be definative.. > >The only sysctl variables are for the CD driver, and you wouldn't be able >to detect that unless you've got the CD driver in your kernel. > >Checking for camlib.h is probably the best way, since most userland SCSI >applications won't be able to compile without it. That creates a dependancy on source. Not good programming practice, IMHO. Unix systems measure "uptime" in years, Winblows measures it in minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 19:39:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21021 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 19:39: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 TAA21014 for ; Thu, 15 Oct 1998 19:38:54 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id UAA22128; Thu, 15 Oct 1998 20:38:32 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810160238.UAA22128@panzer.plutotech.com> Subject: Re: Official way to detect CAM? In-Reply-To: <199810160128.VAA03092@laker.net> from Steve Friedrich at "Oct 15, 98 09:27:22 pm" To: SteveFriedrich@Hot-Shot.com Date: Thu, 15 Oct 1998 20:38:32 -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 Steve Friedrich wrote... > On Thu, 15 Oct 1998 14:59:11 -0600 (MDT), Kenneth D. Merry wrote: > > >Julian Elischer wrote... > >> Are there no sysctl tunables for cam? > >> that would be definative.. > > > >The only sysctl variables are for the CD driver, and you wouldn't be able > >to detect that unless you've got the CD driver in your kernel. > > > >Checking for camlib.h is probably the best way, since most userland SCSI > >applications won't be able to compile without it. > > That creates a dependancy on source. Not good programming practice, > IMHO. Well, when you're compiling source code, you're going to have to depend on various header files being there... If those headers aren't there, your application won't compile. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 19:43:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21549 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 19:43:29 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dewdrop2.mindspring.com (dewdrop2.mindspring.com [207.69.200.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21542 for ; Thu, 15 Oct 1998 19:43:24 -0700 (PDT) (envelope-from rsi@mindspring.com) Received: from kamikaze.mindspring.com (pool-207-205-163-216.nwrk.grid.net [207.205.163.216]) by dewdrop2.mindspring.com (8.8.5/8.8.5) with ESMTP id WAA15943; Thu, 15 Oct 1998 22:42:31 -0400 (EDT) Received: (from rsi@localhost) by kamikaze.mindspring.com (8.9.1/8.8.7) id WAA01636; Thu, 15 Oct 1998 22:42:27 -0400 (EDT) (envelope-from rsi) Message-Id: <199810160242.WAA01636@kamikaze.mindspring.com> To: "Justin T. Gibbs" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Frequent failures with ncr0 References: <199810152207.QAA07631@narnia.plutotech.com> From: Rajappa Iyer Date: 15 Oct 1998 22:41:45 -400 Reply-To: rajappa@mindspring.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: > > > > Here's the message I get: > > > > Oct 15 14:33:52 kamikaze /kernel: ncr0:0: ERROR (0:4) (8-0-0) (f/1b) @ (script 73c:190000de). > > If I'm decifering this correctly, it seems that the SCSI bus is hung > with REQ active. Could be a cabling or termination problem brought out > by the higher transactional loads that CAM can produce. You may be right since the problem seems to occur only when I'm doing heavy i/o on the disk. However, it's unlikely to be a cabling problem as I did try two other cables, but to no avail. FWIW, I'm using a SCA device with an adapter that is supposed to provide active termination... I'm not sure how to verify if this is a termination problem. Any suggestions? Thanks, Rajappa -- a.k.a. Rajappa Iyer. New York, New York. We're too busy mopping the floor to turn off the faucet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 19:46:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22051 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 19:46:30 -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 TAA22031 for ; Thu, 15 Oct 1998 19:46:22 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id UAA22162; Thu, 15 Oct 1998 20:44:33 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810160244.UAA22162@panzer.plutotech.com> Subject: Re: ncrcontrol-like utility for CAM? In-Reply-To: <199810160059.TAA10370@aurora.sol.net> from Joe Greco at "Oct 15, 98 07:59:46 pm" To: jgreco@solaria.sol.net (Joe Greco) Date: Thu, 15 Oct 1998 20:44:33 -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 Joe Greco wrote... > Will there be an ncrcontrol-like utility for CAM? I'm mainly interested > in statistics, and was unable to find anything obvious after looking over > the CAM stuff in 3.0-19981015-BETA. It'd be a nice addition, and it was > a feature I had always missed with the ahc (and others) driver. What kind of statistics? Most interesting statistics should be available through systat(1), iostat(8) and vmstat(8). There are other stats that are recorded in the devstat(9) system, but that aren't displayed in the stats-display utilities. (like the number of ordered tags, number of outstanding transactions) There's a program on my ftp site that will dump out the contents of all the devstat(9) structures in the system: ftp://ftp.kdm.org/pub/FreeBSD/cam/ds.c If there are stats that aren't available that you'd like to see, let me know so I can keep them in mind for future enhancements. > In either case, CAM appears to be working very well on one of my big > machines, with an NCR and an AHA3940. Very nice work! Thanks! Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 21:18:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04420 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 21:18:11 -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 VAA04415 for ; Thu, 15 Oct 1998 21:18:08 -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 AAA26127; Fri, 16 Oct 1998 00:17:49 -0400 (EDT) Date: Fri, 16 Oct 1998 00:17:49 -0400 (EDT) From: "Matthew N. Dodd" To: "Kenneth D. Merry" cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <199810152249.QAA20702@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 Thu, 15 Oct 1998, Kenneth D. Merry wrote: > What sort of device is this? A removable disk changer? A Magneto Optical Jukebox. da2 at bt0 bus 0 target 0 lun 0 da2: Removable Optical SCSI2 device da2: 5.0MB/s transfers (5.0MHz, offset 8) da2: Attempt to query device size failed: NOT READY, Medium not present ch0 at bt0 bus 0 target 1 lun 0 ch0: Removable Changer SCSI2 device ch0: 3.300MB/s transfers ch0: 16 slots, 1 drive, 1 picker, 1 portal > > I'll pull this unit and try my spare when I get home. > > Yeah, it may be having hardware trouble of some sort. No such luck. Same exact error. I've got to be doing something wrong but I can't figure out what. The drive is set to auto-spinup media on a load from the picker. The unit passes all onboard self tests as well. I suspect I need to format the media but that command fails as well. What other initializing command can I issue the drive other than 'START UNIT'? 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. -- | 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 Thu Oct 15 23:03:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16819 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 23:03:34 -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 XAA16814 for ; Thu, 15 Oct 1998 23:03:32 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id AAA23269; Fri, 16 Oct 1998 00:03:10 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810160603.AAA23269@panzer.plutotech.com> Subject: Re: Strange error In-Reply-To: from "Matthew N. Dodd" at "Oct 16, 98 00:17:49 am" To: winter@jurai.net (Matthew N. Dodd) Date: Fri, 16 Oct 1998 00:03:10 -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 Thu, 15 Oct 1998, Kenneth D. Merry wrote: > > What sort of device is this? A removable disk changer? > > A Magneto Optical Jukebox. > > da2 at bt0 bus 0 target 0 lun 0 > da2: Removable Optical SCSI2 device > da2: 5.0MB/s transfers (5.0MHz, offset 8) > da2: Attempt to query device size failed: NOT READY, Medium not present > ch0 at bt0 bus 0 target 1 lun 0 > ch0: Removable Changer SCSI2 device > ch0: 3.300MB/s transfers > ch0: 16 slots, 1 drive, 1 picker, 1 portal Ahh, interesting. A portal, even. Hmm. > > > I'll pull this unit and try my spare when I get home. > > > > Yeah, it may be having hardware trouble of some sort. > > No such luck. Same exact error. > > I've got to be doing something wrong but I can't figure out what. > > The drive is set to auto-spinup media on a load from the picker. The unit > passes all onboard self tests as well. > > I suspect I need to format the media but that command fails as well. What command did you use to try to format it? > What other initializing command can I issue the drive other than 'START > UNIT'? Hmm, dunno. Test unit ready and start unit are the normal commands to send. I guess you could try a read capacity. Have you tried booting the machine with a disk in the drive? (the da driver issues a read capacity command at probe time) > 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? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 23:14:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17633 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 23:14: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 XAA17628 for ; Thu, 15 Oct 1998 23:14:51 -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 CAA27358; Fri, 16 Oct 1998 02:14:28 -0400 (EDT) Date: Fri, 16 Oct 1998 02:14:28 -0400 (EDT) From: "Matthew N. Dodd" To: "Kenneth D. Merry" cc: scsi@FreeBSD.ORG Subject: Re: Strange error In-Reply-To: <199810160603.AAA23269@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 Fri, 16 Oct 1998, Kenneth D. Merry wrote: > > ch0: 16 slots, 1 drive, 1 picker, 1 portal > > Ahh, interesting. A portal, even. Hmm. Indeed. A mammal media door. > What command did you use to try to format it? 'camcontrol cmd -n pass -u X -v -c "4 0 0 0 0 0"' > Hmm, dunno. Test unit ready and start unit are the normal commands to > send. I guess you could try a read capacity. Have you tried booting the > machine with a disk in the drive? (the da driver issues a read capacity > command at probe time) 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. > > 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) ftp://ftp.jurai.net/users/winter/C1716_scsi.pdf HP SureStore support was kind of anal about giving it to me and put it up on their ftp site in a hidden directory and removed it after I downloaded it so I'm not sure how keen they are to have this info broadbanded but its of limited use to anyone without the drive (well, not quite limited use) and they shipped a hardcopy of this thing with all the units they sold through 3rd parties back when. Oh, and they didn't tell me I couldn't. So have at. > 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. -- | 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 Thu Oct 15 23:41:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20506 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 23:41: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 XAA20497 for ; Thu, 15 Oct 1998 23:41:50 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id AAA23571; Fri, 16 Oct 1998 00:41:25 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810160641.AAA23571@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: Fri, 16 Oct 1998 00:41:25 -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: > > > ch0: 16 slots, 1 drive, 1 picker, 1 portal > > > > Ahh, interesting. A portal, even. Hmm. > > Indeed. A mammal media door. 'Eh? You mean like a marsupial or... > > What command did you use to try to format it? > > 'camcontrol cmd -n pass -u X -v -c "4 0 0 0 0 0"' > > > Hmm, dunno. Test unit ready and start unit are the normal commands to > > send. I guess you could try a read capacity. Have you tried booting the > > machine with a disk in the drive? (the da driver issues a read capacity > > command at probe time) > > 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. That's pretty lame. Typical of HP, though. I've got an HP WORM drive that does something similar when there's no media in it. (returns 0x04,0x00 instead of 0x3a,0x00) > Most annoying this behavior. I'm not sure why it thinks it needs to > remove the device entry. Because we got a fatal error back on the probe. If the da driver gets a fatal error back, it just assumes that it can't talk to the device. I've attached a patch that should make it attach for you. > > > 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) > > ftp://ftp.jurai.net/users/winter/C1716_scsi.pdf Downloading it now, thanks. ...and the font is pretty crappy. It looks like they scanned the thing in or something. > HP SureStore support was kind of anal about giving it to me and put it up > on their ftp site in a hidden directory and removed it after I downloaded > it so I'm not sure how keen they are to have this info broadbanded but its > of limited use to anyone without the drive (well, not quite limited use) > and they shipped a hardcopy of this thing with all the units they sold > through 3rd parties back when. > > Oh, and they didn't tell me I couldn't. Stupid vendors. I wish all SCSI vendors would just put full specs on their web site... > So have at. > > > 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. Hmm. Of course that still doesn't preclude the possibility that they've gotten broken in the intervening time period. > 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. My guess is that you'd have more luck with NetBSD, but probably not any more than you'd have with FreeBSD/CAM. (our changer driver is a port of theirs, but I'm not sure whether they have optical disk support or not) Anyway, I'll try to look through the spec a bit sometime and see if I can find anything incriminating. Try out the attached patch, it'll at least let the da driver attach to the thing. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 15 23:42:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20721 for freebsd-scsi-outgoing; Thu, 15 Oct 1998 23:42:49 -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 XAA20714 for ; Thu, 15 Oct 1998 23:42:44 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id AAA23596; Fri, 16 Oct 1998 00:42:24 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810160642.AAA23596@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: Fri, 16 Oct 1998 00:42:24 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM908520144-23458-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM908520144-23458-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Oops, forgot the patch. Here it is. Ken -- Kenneth Merry ken@plutotech.com --ELM908520144-23458-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=scsi_da.0x04.diffs Content-Description: scsi_da.0x04.diffs Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_da.c#87 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c ==== *** /tmp/tmp.23409.0 Fri Oct 16 00:22:54 1998 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c Fri Oct 16 00:22:39 1998 *************** *** 1311,1317 **** * the error is anything else, though, we * shouldn't attach. */ ! if ((have_sense) && (asc == 0x3a) && (error_code == SSD_CURRENT_ERROR)) sprintf(announce_buf, "Attempt to query device " --- 1311,1318 ---- * the error is anything else, though, we * shouldn't attach. */ ! if ((have_sense) ! && ((asc == 0x3a) || (asc == 0x04)) && (error_code == SSD_CURRENT_ERROR)) sprintf(announce_buf, "Attempt to query device " --ELM908520144-23458-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 16 04:09:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14689 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 04:09:45 -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 EAA14672; Fri, 16 Oct 1998 04:09:39 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt4-28.HiWAAY.net [208.166.127.28]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id GAA30422; Fri, 16 Oct 1998 06:09:18 -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 GAA16802; Fri, 16 Oct 1998 06:09:15 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199810161109.GAA16802@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert 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 Terry Lambert of "Thu, 15 Oct 1998 18:21:55 -0000." <199810151821.LAA15497@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Oct 1998 06:09:15 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert writes: > > > If that's the reason for the problem that I saw, then the UPS the > > > system was plugged into wasn't sufficient to prevent the problem. > > > > Before you fight it too much more, replace the power supply. I've cured > > a number of "impossible" problems with a new power supply. > > Uh, you won't cure "Don punching the reset button to simulate a > particular set of hardware failures" with a new supply. > > 8-). 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. No telling *if* there are changes in the PS load when reset is punched either. Think my PPro-166 CPU pulls 10A. If it suddenly stops pulling that much current when RESET is active then what does the PS do? -- 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 Fri Oct 16 05:48:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA21455 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 05:48:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA21450 for ; Fri, 16 Oct 1998 05:48:24 -0700 (PDT) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id FAA05529; Fri, 16 Oct 1998 05:48:00 -0700 (PDT) Date: Fri, 16 Oct 1998 05:48:00 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199810161248.FAA05529@math.berkeley.edu> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Official way to detect CAM? Cc: dan@math.berkeley.edu Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a way to detect CAM using only definitions in a C-language header file that is present (under ther same name) in both release 2.X and 3.X systems? I don't like elaborate pre-installation configuration scripts. I really really hate them. Also, is there any documentation for cam beyond the camcontrol man page? The camcontrol man page lists "cam(3), pass(4), cam(9), xpt(9)" but there are no such man pages (on 3.0-19981003-BETA). Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 16 06:45:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA28727 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 06:45:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from laker.net (jet.laker.net [205.245.74.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA28722 for ; Fri, 16 Oct 1998 06:45:19 -0700 (PDT) (envelope-from sfriedri@laker.net) Received: from nt (digital-pbi-146.laker.net [208.0.233.46]) by laker.net (8.9.0/8.9.LAKERNET.NO-SPAM.SPAMMERS.AND.RELAYS.WILL.BE.TRACKED.AND.PROSECUTED.) with SMTP id JAA24236; Fri, 16 Oct 1998 09:44:54 -0400 Message-Id: <199810161344.JAA24236@laker.net> From: "Steve Friedrich" To: "Kenneth D. Merry" Cc: "freebsd-scsi@FreeBSD.ORG" Date: Fri, 16 Oct 1998 09:43:37 -0400 Reply-To: "Steve Friedrich" X-Mailer: PMMail 98 Professional (2.01.1600) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Official way to detect CAM? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Oct 1998 20:38:32 -0600 (MDT), Kenneth D. Merry wrote: >Steve Friedrich wrote... >> On Thu, 15 Oct 1998 14:59:11 -0600 (MDT), Kenneth D. Merry wrote: >> >> >Julian Elischer wrote... >> >> Are there no sysctl tunables for cam? >> >> that would be definative.. >> > >> >The only sysctl variables are for the CD driver, and you wouldn't be able >> >to detect that unless you've got the CD driver in your kernel. >> > >> >Checking for camlib.h is probably the best way, since most userland SCSI >> >applications won't be able to compile without it. >> >> That creates a dependancy on source. Not good programming practice, >> IMHO. > >Well, when you're compiling source code, you're going to have to depend on >various header files being there... If those headers aren't there, your >application won't compile. I may have misunderstood... I thought the discussion was regarding detecting CAM while running an application, not building it... So sorry 8o) Unix systems measure "uptime" in years, Winblows measures it in minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 16 07:53:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA07642 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 07:53:27 -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 HAA07637 for ; Fri, 16 Oct 1998 07:53:22 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id IAA25084; Fri, 16 Oct 1998 08:52:59 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810161452.IAA25084@panzer.plutotech.com> Subject: Re: Official way to detect CAM? In-Reply-To: <199810161248.FAA05529@math.berkeley.edu> from Dan Strick at "Oct 16, 98 05:48:00 am" To: dan@math.berkeley.edu (Dan Strick) Date: Fri, 16 Oct 1998 08:52:59 -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 Dan Strick wrote... > Is there a way to detect CAM using only definitions in a C-language > header file that is present (under ther same name) in both release > 2.X and 3.X systems? I don't like elaborate pre-installation > configuration scripts. I really really hate them. Nope, there really isn't another way. You could use the FreeBSD release variable/macro, but you can have a 2.x machine running CAM. There really wasn't an obvious place to put such a define. > Also, is there any documentation for cam beyond the camcontrol man > page? The camcontrol man page lists "cam(3), pass(4), cam(9), xpt(9)" > but there are no such man pages (on 3.0-19981003-BETA). There are a number of new man pages that have been added in the past few days. (and you'll notice that the camcontrol man page mentions that most of the cross-references don't exist) The documentation isn't anywhere near completion, but it's better than it was. 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 16 09:33:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA20667 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 09:33:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mushi.colo.neosoft.com (mushi.colo.neosoft.com [206.109.6.82]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA20652 for ; Fri, 16 Oct 1998 09:33:21 -0700 (PDT) (envelope-from peter@taronga.com) Received: (qmail 19095 invoked from network); 16 Oct 1998 16:33:01 -0000 Received: from bonkers.neosoft.com (HELO bonkers.taronga.com) (root@206.109.2.48) by mushi.colo.neosoft.com with SMTP; 16 Oct 1998 16:33:01 -0000 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id LAA10179; Fri, 16 Oct 1998 11:32:57 -0500 Date: Fri, 16 Oct 1998 11:32:57 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199810161632.LAA10179@bonkers.taronga.com> To: scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810141501.JAA04936@mt.sri.com> References: <199810140049.RAA20004@usr08.primenet.com><199810140518.XAA15040@pluto.plutotech.com>,<199810140518.XAA15040@pluto.plutotech.com> Organization: none Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199810141501.JAA04936@mt.sri.com>, Nate Williams wrote: >IMO, CAM should disable write caching by default, and allow people to >add it back by hand if they know how. I don't know how this would be >done, but it's *ALWAYS* a better idea to be safe than to be sorry. This seems like a no-brainer to me. Does write-caching actually improve performance measurably? I would have assumed that FreeBSD would do a better job than any drive could, and it certainly has more resources available. Write-caching always seemed to be one of those Windows-oriented optimizations that were better avoided with real operating systems... unless the write-cache is something like the 128MB battery-backed cache in our Storageworks RAID box down the hall from me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 16 10:30:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA29145 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 10:30:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA29027 for ; Fri, 16 Oct 1998 10:29:57 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id TAA09523 for scsi@FreeBSD.ORG; Fri, 16 Oct 1998 19:29:37 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id 331891462; Fri, 16 Oct 1998 19:26:44 +0200 (CEST) Date: Fri, 16 Oct 1998 19:26:44 +0200 From: Ollivier Robert To: scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <19981016192644.A5762@keltia.freenix.fr> Mail-Followup-To: scsi@FreeBSD.ORG References: <199810140049.RAA20004@usr08.primenet.com><199810140518.XAA15040@pluto.plutotech.com>,<199810140518.XAA15040@pluto.plutotech.com> <199810141501.JAA04936@mt.sri.com> <199810161632.LAA10179@bonkers.taronga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.4i In-Reply-To: <199810161632.LAA10179@bonkers.taronga.com>; from Peter da Silva on Fri, Oct 16, 1998 at 11:32:57AM -0500 X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4724 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Peter da Silva: > This seems like a no-brainer to me. 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. A lot if not all of the modern drives are shipped with WCE == 1 though. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #4: Thu Oct 15 01:36:57 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 16 12:36:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23906 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 12:36:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from localhost.localdomain (ppp-100-45.villette.club-internet.fr [194.158.100.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA23858 for ; Fri, 16 Oct 1998 12:36:39 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (groudier@localhost) by localhost.localdomain (8.8.4/8.8.4) with SMTP id UAA00660; Fri, 16 Oct 1998 20:44:53 +0200 X-Authentication-Warning: localhost.localdomain: groudier owned process doing -bs Date: Fri, 16 Oct 1998 20:44:52 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Rajappa Iyer cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Frequent failures with ncr0 In-Reply-To: <199810152053.QAA00765@kamikaze.mindspring.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 15 Oct 1998, Rajappa Iyer wrote: > I've been getting frequent failures with ncr0 after upgrading to CAM. > I saw from the mailing archives that others are experiencing similar > problems, but did not see any resolution. Is there any work around > for this? Please help. FYI, this is a Tekram-390F card. > > Thanks, > Rajappa > > Here's the message I get: > > Oct 15 14:33:52 kamikaze /kernel: ncr0:0: ERROR (0:4) (8-0-0) (f/1b) @ (script 73c:190000de). 4=bit2 of SIST0 I/O register indicates that an UNEXPECTED SCSI BUS DISCONNECTION has been detected by the SCSI chip. > Oct 15 14:33:52 kamikaze /kernel: ncr0: script cmd = 89030000 > Oct 15 14:33:52 kamikaze /kernel: ncr0: regdump: da 00 80 1b 47 0f 00 07 03 08 80 00 80 00 01 0a. > Oct 15 14:33:52 kamikaze /kernel: ncr0: have to clear fifos. > Oct 15 14:33:52 kamikaze /kernel: ncr0:0: ERROR (0:c1) (e-ae-0) (f/1b) @ (script c0:1e000000). 1=bit0 of SIST0 indicates a SCSI PARITY ERROR. 0x80 means PHASE MISMATCH, 0x40 means FUNCTION COMPLETE (not an error). This may be a spurious parity error due to the SCSI chip having checked SCSI parity while the SCSI BUS data and parity lines were no more properly driven by the device that just disconnected the bus (not sure). For example, the C code that dumped registers for the previous error did read the SBDL register (SCSI BUS DATA LINES), and so may have triggerred such a spurious SCSI PARITY error. > Oct 15 14:33:52 kamikaze /kernel: ncr0: script cmd = 60000008 > Oct 15 14:33:52 kamikaze /kernel: ncr0: regdump: da 10 80 1b 47 0f 00 07 00 0e 80 ae 00 00 06 08. Regards, Gerard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 16 12:58:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA28319 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 12:58:52 -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 MAA28285; Fri, 16 Oct 1998 12:58:41 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id MAA21313; Fri, 16 Oct 1998 12:58:22 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd021284; Fri Oct 16 12:58:18 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA24426; Fri, 16 Oct 1998 12:58:17 -0700 (MST) From: Terry Lambert Message-Id: <199810161958.MAA24426@usr04.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: dkelly@hiwaay.net (David Kelly) Date: Fri, 16 Oct 1998 19:58:17 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810161109.GAA16802@nospam.hiwaay.net> from "David Kelly" at Oct 16, 98 06:09:15 am 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 > 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. > > No telling *if* there are changes in the PS load when reset is punched > either. Think my PPro-166 CPU pulls 10A. If it suddenly stops pulling > that much current when RESET is active then what does the PS do? 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. 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 Fri Oct 16 16:50:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA17680 for freebsd-scsi-outgoing; Fri, 16 Oct 1998 16:50: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 QAA17567; Fri, 16 Oct 1998 16:49: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 RAA11679; Fri, 16 Oct 1998 17:49:25 -0600 (MDT) Message-Id: <199810162349.RAA11679@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: dkelly@hiwaay.net (David Kelly), freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 16 Oct 1998 19:58:17 -0000." <199810161958.MAA24426@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Oct 1998 17:42:34 -0600 From: "Justin T. Gibbs" 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. -- 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 17 00:21:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA07250 for freebsd-scsi-outgoing; Sat, 17 Oct 1998 00:21:17 -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 AAA07245 for ; Sat, 17 Oct 1998 00:21:15 -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 JAA28963 for scsi@FreeBSD.ORG; Sat, 17 Oct 1998 09:20:53 +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 IAA01988; Sat, 17 Oct 1998 08:51:00 +0200 (MET DST) (envelope-from j) Message-ID: <19981017085100.15382@uriah.heep.sax.de> Date: Sat, 17 Oct 1998 08:51:00 +0200 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: Strange error Reply-To: Joerg Wunsch References: <199810152249.QAA20702@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew N. Dodd on Fri, Oct 16, 1998 at 12:17:49AM -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: > 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. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 17 06:31:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA11755 for freebsd-scsi-outgoing; Sat, 17 Oct 1998 06:31:38 -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 GAA11740 for ; Sat, 17 Oct 1998 06:31:36 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA18421 (5.67b/IDA-1.5); Sat, 17 Oct 1998 15:18:43 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id MAA01923; Sat, 17 Oct 1998 12:23:05 +0200 (CEST) From: Wilko Bulte Message-Id: <199810171023.MAA01923@yedi.iaf.nl> Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810161632.LAA10179@bonkers.taronga.com> from Peter da Silva at "Oct 16, 98 11:32:57 am" To: peter@taronga.com (Peter da Silva) Date: Sat, 17 Oct 1998 12:23:04 +0200 (CEST) Cc: 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 Peter da Silva wrote... > In article <199810141501.JAA04936@mt.sri.com>, > Nate Williams wrote: > >IMO, CAM should disable write caching by default, and allow people to > >add it back by hand if they know how. I don't know how this would be > >done, but it's *ALWAYS* a better idea to be safe than to be sorry. > > This seems like a no-brainer to me. > > Does write-caching actually improve performance measurably? I would have > assumed that FreeBSD would do a better job than any drive could, and it > certainly has more resources available. Write-caching always seemed to be > one of those Windows-oriented optimizations that were better avoided with > real operating systems... unless the write-cache is something like the > 128MB battery-backed cache in our Storageworks RAID box down the hall > from me. Your Storageworks box uses it's cache for more than just caching. What type of HSZ controller does it have BTW? 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 Sat Oct 17 10:18:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03912 for freebsd-scsi-outgoing; Sat, 17 Oct 1998 10:18:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA03906; Sat, 17 Oct 1998 10:18:37 -0700 (PDT) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id TAA13178; Sat, 17 Oct 1998 19:17:58 +0200 (MET DST) Message-ID: <19981017191758.A13174@gvr.org> Date: Sat, 17 Oct 1998 19:17:58 +0200 From: Guido van Rooij To: Terry Lambert , David Kelly Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching References: <199810161109.GAA16802@nospam.hiwaay.net> <199810161958.MAA24426@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199810161958.MAA24426@usr04.primenet.com>; from Terry Lambert on Fri, Oct 16, 1998 at 07:58:17PM +0000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 17 19:03:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18872 for freebsd-scsi-outgoing; Sat, 17 Oct 1998 19:03:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18866; Sat, 17 Oct 1998 19:03:52 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA08821; Sat, 17 Oct 1998 18:59:48 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdwZ8817; Sun Oct 18 01:59:48 1998 Date: Sat, 17 Oct 1998 18:59:41 -0700 (PDT) From: Julian Elischer To: Guido van Rooij cc: Terry Lambert , David Kelly , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <19981017191758.A13174@gvr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 17 Oct 1998, Guido van Rooij wrote: > 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. > > -Guido > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 17 21:54:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07567 for freebsd-scsi-outgoing; Sat, 17 Oct 1998 21:54:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ninbox.ml.org (hsv1-68.airnet.net [207.242.81.68]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07551 for ; Sat, 17 Oct 1998 21:54:33 -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 XAA03199 for ; Sat, 17 Oct 1998 23:52:26 -0500 (CDT) (envelope-from kris@airnet.net) Message-ID: <3629740A.AAA48013@airnet.net> Date: Sat, 17 Oct 1998 23:52:26 -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 = Error Code 1? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org /usr/src/lib/libcam/camlib.c:632: redefinition of `struct cam_devequiv' /usr/src/lib/libcam/camlib.c:637: redefinition of `devmatchtable' /usr/src/lib/libcam/camlib.c:48: `devmatchtable' previously defined here /usr/src/lib/libcam/camlib.c:655: redefinition of `cam_send_ccb' /usr/src/lib/libcam/camlib.c:66: `cam_send_ccb' previously defined here /usr/src/lib/libcam/camlib.c:664: redefinition of `cam_getccb' /usr/src/lib/libcam/camlib.c:75: `cam_getccb' previously defined here /usr/src/lib/libcam/camlib.c:683: redefinition of `cam_freeccb' /usr/src/lib/libcam/camlib.c:94: `cam_freeccb' previously defined here /usr/src/lib/libcam/camlib.c:710: redefinition of `cam_get_device' /usr/src/lib/libcam/camlib.c:121: `cam_get_device' previously defined here /usr/src/lib/libcam/camlib.c:903: redefinition of `cam_open_device' /usr/src/lib/libcam/camlib.c:314: `cam_open_device' previously defined here /usr/src/lib/libcam/camlib.c:934: redefinition of `cam_open_spec_device' /usr/src/lib/libcam/camlib.c:345: `cam_open_spec_device' previously defined here /usr/src/lib/libcam/camlib.c:968: redefinition of `cam_real_open_device' /usr/src/lib/libcam/camlib.c:379: `cam_real_open_device' previously defined here /usr/src/lib/libcam/camlib.c:1095: redefinition of `cam_close_device' /usr/src/lib/libcam/camlib.c:506: `cam_close_device' previously defined here /usr/src/lib/libcam/camlib.c:1107: redefinition of `cam_close_spec_device' /usr/src/lib/libcam/camlib.c:518: `cam_close_spec_device' previously defined her e /usr/src/lib/libcam/camlib.c:1117: redefinition of `cam_path_string' /usr/src/lib/libcam/camlib.c:528: `cam_path_string' previously defined here /usr/src/lib/libcam/camlib.c:1140: redefinition of `cam_device_dup' /usr/src/lib/libcam/camlib.c:551: `cam_device_dup' previously defined here /usr/src/lib/libcam/camlib.c:1161: redefinition of `cam_device_copy' /usr/src/lib/libcam/camlib.c:572: `cam_device_copy' previously defined here *** Error code 1 Stop. Did I miss something? The base is 2.2.7-RELEASE /usr/src. The 2.2 patches were applied on top... -- 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 Sat Oct 17 23:18:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13552 for freebsd-scsi-outgoing; Sat, 17 Oct 1998 23:18:39 -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 XAA13534 for ; Sat, 17 Oct 1998 23:18:36 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id AAA13444; Sun, 18 Oct 1998 00:18:11 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810180618.AAA13444@panzer.plutotech.com> Subject: Re: 2.2.7-RELEASE + CAM = Error Code 1? In-Reply-To: <3629740A.AAA48013@airnet.net> from Kris Kirby at "Oct 17, 98 11:52:26 pm" To: kris@airnet.net (Kris Kirby) Date: Sun, 18 Oct 1998 00:18:11 -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... > /usr/src/lib/libcam/camlib.c:1140: redefinition of `cam_device_dup' > /usr/src/lib/libcam/camlib.c:551: `cam_device_dup' previously defined > here > /usr/src/lib/libcam/camlib.c:1161: redefinition of `cam_device_copy' > /usr/src/lib/libcam/camlib.c:572: `cam_device_copy' previously defined > here > *** Error code 1 > > Stop. > > Did I miss something? The base is 2.2.7-RELEASE /usr/src. The 2.2 > patches were applied on top... 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. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message