From owner-freebsd-scsi Sun Jun 21 04:08:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA05910 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 04:08:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA05865 for ; Sun, 21 Jun 1998 04:08:47 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA27420; Sun, 21 Jun 1998 06:42:48 -0400 (EDT) From: Peter Dufault Message-Id: <199806211042.GAA27420@hda.hda.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806210305.VAA20485@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 20, 98 09:05:37 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 21 Jun 1998 06:42:48 -0400 (EDT) Cc: jonny@jonny.eng.br, ken@plutotech.com, mjacob@feral.com, julian@whistle.com, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > > Isn't this what /dev/xxx.ctl does ? > > My guess is that that is what it was supposed to do in theory, but > in practice, I don't think it does. I looked at the open routines in the > current cd, sd and st drivers, and none of them check to see if it was the > control device that was opened. So if no media is in the drive, the open > will fail. Take a look at scsi_open. All opens go through there first, and that is where it checks to see if it is the control device. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 04:19:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA07949 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 04:19:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA07936 for ; Sun, 21 Jun 1998 04:19:12 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA27439; Sun, 21 Jun 1998 06:52:33 -0400 (EDT) From: Peter Dufault Message-Id: <199806211052.GAA27439@hda.hda.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806210307.VAA20507@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 20, 98 09:07:42 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 21 Jun 1998 06:52:33 -0400 (EDT) Cc: darrylo@sr.hp.com, ken@plutotech.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Darryl Okahata wrote... > > "Kenneth D. Merry" wrote: > > > > > - How many more programs use this (scsireq) interface? > > > > Does /sbin/scsi work (or has it been ported)? If so, great. I've > > got some perl scripts that fdisk/disklabel/newfs arbitrary disks, and > > they rely upon scsi(8). > > Well, scsi(8) has not been ported, it has been replaced by > camcontrol. camcontrol should be able to do everything that scsi(8) did, > and more. People can also dig up "scsinew.tgz" which is a slicing-dicing version of scsi(8) that is a superset but can run as a server, generate Tcl data structures, and has better abilities for command scripts, can generate code stubs from the ascii CDB description, etc: > # ndefects plist glist > ndefects "37 0 0:3 {plist} v:1 {vlist} v:1 5:3 0 0 0 0 4:i2 0" \ > -i 4 "*i2 {Defect list length} i2" > > # defects plist glist size > defects "37 0 0:3 {plist} v:1 {vlist} v:1 5:3 0 0 0 0 {xfer} v:i2 0" \ > -i v "s4 ( {Cylinder} i3 {Head} i1 {Sector} i4)" This lets scsi(8) recognize commands such as this when set to Tcl output mode: > rt# ./scsinew -f sd0 -S tcl -C caps -I > scsi> ndefects 1 1 > 0 {80} > scsi> defects 84 1 1 84 > 0 {{771 0 18} {771 0 19} {1671 4 87} {1703 3 80} {1704 3 80} {1704 3 81} {1866 1 95} {1922 0 47} {1932 3 33} {2184 3 8} } > scsi> Or this for code output: > scsi> ndefects > errval dev_ndefects(struct scsi_link *sc_link, const int input_arg0, > const int input_arg1, int *output_arg0) > { > int ret; > static const u_char cdb_tmplt[] = > {0x37,0x00,0x05,0x00,0x00,0x00,0x00,0x00,0x04,0x00,}; > u_char cdb[sizeof(cdb_tmplt)]; > u_char data[4]; > memcpy(cdb, cdb_tmplt, sizeof(cdb)); > scsi_bits_set(cdb + 2, input_arg0, 1, 3); /* "plist" get b1 */ > scsi_bits_set(cdb + 2, input_arg1, 1, 4); /* "vlist" get b1 */ > if ( (ret = scsi_scsi_cmd(sc_link, > (const struct scsi_generic *)cdb, > sizeof(cdb), > data, > 4, > dev_retries, > 2000, > NULL, > SCSI_DATA_IN)) == 0) > { > *output_arg0=scsi_2_byte(data + 2); /* "Defect list length" put i2 */ > > } > return ret; >} I don't know where it is archived now. There wasn't much interest in this the last time I showed it around. As I've said in the past, IMHO programs are better than libraries. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 11:13:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12360 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 11:13:34 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12350 for ; Sun, 21 Jun 1998 11:13:29 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id PAA25621; Sun, 21 Jun 1998 15:13:11 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806211813.PAA25621@roma.coe.ufrj.br> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806210305.VAA20485@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 20, 98 09:05:37 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 21 Jun 1998 15:13:11 -0300 (EST) Cc: jonny@jonny.eng.br, ken@plutotech.com, mjacob@feral.com, julian@whistle.com, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (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 #define quoting(Kenneth D. Merry) // From ken@panzer.plutotech.com Sun Jun 21 00:06:01 1998 // From: "Kenneth D. Merry" // Message-Id: <199806210305.VAA20485@panzer.plutotech.com> // Subject: Re: Rolling CAM in, what is still needed? // In-Reply-To: <199806191742.OAA02683@roma.coe.ufrj.br> from Joao Carlos Mendes Luis at "Jun 19, 98 02:42:45 pm" // To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) // Date: Sat, 20 Jun 1998 21:05:37 -0600 (MDT) // Cc: ken@plutotech.com, mjacob@feral.com, julian@whistle.com, // jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG // X-Mailer: ELM [version 2.4ME+ PL28s (25)] // Joao Carlos Mendes Luis wrote... // > #define quoting(Kenneth D. Merry) // > // - the problem is that with the old SCSI code, to send SCSI commands // > // directly to a device, you opened the device itself (/dev/rcd0a or // > // whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does // > // things differently, primarily because users may want to send // > // commands to device, even though the device's open() routine may // > // fail. For instance, you can't open a CD device if there is no // > // media inserted. But the user may want to send an INQUIRY command // > // to the drive, whether or not there's a CD in the drive. So, to // > // solve this, you have two choices: (that I can think of offhand) // > // - have a special control minor number for each device, and // > // have the open call ignore failures in read capacity, test // > // unit ready, etc. // > // - have a separate passthrough driver that doesn't have to // > // have any commands succeed to attach or open. // > // > Isn't this what /dev/xxx.ctl does ? // // My guess is that that is what it was supposed to do in theory, but // in practice, I don't think it does. I looked at the open routines in the // current cd, sd and st drivers, and none of them check to see if it was the // control device that was opened. So if no media is in the drive, the open // will fail. I had a problem recently, in which my CD drive booted locked, with or without a disk inside. With a disk inside I could just send the cdcontrol command to eject it, but without a disk inside I had to use scsi(8) commands, and they only worked with /dev/rcd0.ctl, failing at other devices because it could not open the device without a disk inside. I think that this is behaving as you expected. Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 12:43:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA20106 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 12:43:16 -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 MAA20101 for ; Sun, 21 Jun 1998 12:43:11 -0700 (PDT) (envelope-from j@jette.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id VAA09489; Sun, 21 Jun 1998 21:43:07 +0200 (CEST) (envelope-from j@jette.heep.sax.de) Received: (from j@localhost) by jette.heep.sax.de (8.8.5/8.8.5) id TAA00422; Sun, 21 Jun 1998 19:49:55 +0200 (CEST) Message-ID: <19980621194949.YQ56000@jette.heep.sax.de> Date: Sun, 21 Jun 1998 19:49:49 +0200 From: j@jette.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: robert@chalmers.com.au Subject: Re: scsiformat reporting different speed to disklabel References: <357CAD4C.16055D8A@chalmers.com.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 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 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <357CAD4C.16055D8A@chalmers.com.au>; from Robert Chalmers on Jun 9, 1998 13:34:36 +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Robert Chalmers wrote: > using scsiformat -p d sd1 reports a > Medium rotation Rate of 6400. This is supposed to be the correct number. > Is this the rpm: that is reported by disklabel? disklabel only and always defaults to 3600, nothing else, unless you've actually created the label using an entry in /etc/disktab, or at least edited the value with disklabel -e. This value in the disklabel historically has been used for layout-based access optimizations, but this is no longer really applicable for modern disks, so the value's meaningless these days. > Also: on the same thing, reported information, the number of actual > sectors calculated is different to the total sectors reported? The SCSI mode page reports the total amount of blocks. Depending on the actual strategy, you aren't able to use all of them (e.g. due to prehistoric assumptions of fdisk slices being aligned to something like a cylinder boundary). The difference in your case is weirdly large, however. -- bye, J"org ...just travelling around. Don't try reaching me except by mail. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 14:00:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28489 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 14:00:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28477 for ; Sun, 21 Jun 1998 14:00:42 -0700 (PDT) (envelope-from jambi@nlanr.net) Received: from localhost (jambi@localhost) by nlanr.net (8.8.6/8.8.6) with SMTP id NAA20325; Sun, 21 Jun 1998 13:59:21 -0700 (PDT) Date: Sun, 21 Jun 1998 13:59:21 -0700 (PDT) From: Jambi To: "Kenneth D. Merry" cc: darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG Subject: ccd bug? In-Reply-To: <199806210307.VAA20507@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 Hey all, Back from USENIX which means time to get back to work. We have been doing some testing with disk to see which disk is the best for our purposes (writting continuouisly to disk). We were using ccd to do some writing test when we noticed that we got now error messages when the disk was full. I haven't looked at the code yet, but before I plunge into that I was wondering if anyone encountered this before? Regards, Jambi _______________________________________________ Jambi Ganbar | (619) 8220938 | jambi@nlanr.net San Diego SuperComputer Center ________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 15:10:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10230 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 15:10:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nanguo.chalmers.com.au (gateway.chalmers.com.au [203.1.96.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA09557 for ; Sun, 21 Jun 1998 15:07:50 -0700 (PDT) (envelope-from robert@chalmers.com.au) Received: from chalmers.com.au (carbon.chalmers.com.au [203.1.96.26]) by nanguo.chalmers.com.au (8.8.8/8.8.8) with ESMTP id IAA05027; Mon, 22 Jun 1998 08:06:34 +1000 (EST) Message-ID: <358D868B.A4751765@chalmers.com.au> Date: Mon, 22 Jun 1998 08:17:47 +1000 From: Robert Chalmers Reply-To: robert@chalmers.com.au Organization: chalmers.com.au X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Joerg Wunsch CC: freebsd-scsi@FreeBSD.ORG Subject: Re: scsiformat reporting different speed to disklabel References: <357CAD4C.16055D8A@chalmers.com.au> <19980621194949.YQ56000@jette.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, thanks for the info. I have managed to work it all out, and can now disklabel a disk using only the disktab entry and the command "disklabel -r -w /dev/rsd1c C2490A sd1s1", C2490A being the appropriate disktab. The one thing I can't get rid of however, is the warning from the kernel, /kernel: sd1: invalid primary partition table: no magic Remember, this is a second hard disk drive, dedicated to freeBSD. The Primary/root hdd is also a fully dedicated Freebsd system. I tried doing a disklabel -B sd1, but of course that created a boot block, and FreeBSD then tried to boot of both disks.... a near disaster.... So, as soon as I figure out how to get reid of that message, I'll have the complete details of how to build a second (or more ) hadrd disk and can write it up. I'm trying to get this done without using fdisk.... but it seems fbsd doesn't work that way. I don't know. Thanks for your help, cheers Robert J Wunsch wrote: > > As Robert Chalmers wrote: > > > using scsiformat -p d sd1 reports a > > Medium rotation Rate of 6400. > > This is supposed to be the correct number. > > > Is this the rpm: that is reported by disklabel? > > disklabel only and always defaults to 3600, nothing else, unless > you've actually created the label using an entry in /etc/disktab, > or at least edited the value with disklabel -e. > > This value in the disklabel historically has been used for > layout-based access optimizations, but this is no longer really > applicable for modern disks, so the value's meaningless these days. > > > Also: on the same thing, reported information, the number of actual > > sectors calculated is different to the total sectors reported? > > The SCSI mode page reports the total amount of blocks. Depending on > the actual strategy, you aren't able to use all of them (e.g. due to > prehistoric assumptions of fdisk slices being aligned to something > like a cylinder boundary). The difference in your case is weirdly > large, however. > > -- > bye, J"org > > ...just travelling around. Don't try reaching me except by mail. :) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Support Whirled Peas. Business in China? China House robert@chalmers.com.au ph:61 7 49440357 fx:61 7 49578425 China House Uses Webposition to ensure Top Spot in Searches http://www.chalmers.com.au/ChinaHouse/Business/webposition To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 15:12:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10601 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 15:12:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10589 for ; Sun, 21 Jun 1998 15:12:09 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA24248; Sun, 21 Jun 1998 16:11:15 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806212211.QAA24248@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806211042.GAA27420@hda.hda.com> from Peter Dufault at "Jun 21, 98 06:42:48 am" To: dufault@hda.com (Peter Dufault) Date: Sun, 21 Jun 1998 16:11:15 -0600 (MDT) Cc: ken@plutotech.com, jonny@jonny.eng.br, mjacob@feral.com, julian@whistle.com, ckempf@enigami.com, 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 Peter Dufault wrote... > > > Isn't this what /dev/xxx.ctl does ? > > > > My guess is that that is what it was supposed to do in theory, but > > in practice, I don't think it does. I looked at the open routines in the > > current cd, sd and st drivers, and none of them check to see if it was the > > control device that was opened. So if no media is in the drive, the open > > will fail. > > Take a look at scsi_open. All opens go through there first, and > that is where it checks to see if it is the control device. Ahh, you're correct. I should have looked more closely. 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 Jun 21 15:28:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13644 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 15:28:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13610 for ; Sun, 21 Jun 1998 15:28:28 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA24363; Sun, 21 Jun 1998 16:27:00 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806212227.QAA24363@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806211052.GAA27439@hda.hda.com> from Peter Dufault at "Jun 21, 98 06:52:33 am" To: dufault@hda.com (Peter Dufault) Date: Sun, 21 Jun 1998 16:27:00 -0600 (MDT) Cc: ken@plutotech.com, darrylo@sr.hp.com, 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 Peter Dufault wrote... > > Darryl Okahata wrote... > > > "Kenneth D. Merry" wrote: > > > > > > > - How many more programs use this (scsireq) interface? > > > > > > Does /sbin/scsi work (or has it been ported)? If so, great. I've > > > got some perl scripts that fdisk/disklabel/newfs arbitrary disks, and > > > they rely upon scsi(8). > > > > Well, scsi(8) has not been ported, it has been replaced by > > camcontrol. camcontrol should be able to do everything that scsi(8) did, > > and more. > > People can also dig up "scsinew.tgz" which is a slicing-dicing version > of scsi(8) that is a superset but can run as a server, generate > Tcl data structures, and has better abilities for command scripts, > can generate code stubs from the ascii CDB description, etc: Hmm, sounds interesting. > This lets scsi(8) recognize commands such as this when set to Tcl > output mode: [ ... ] > Or this for code output: [ ... ] > I don't know where it is archived now. There wasn't much interest > in this the last time I showed it around. Well, I would be interested in taking a look at it. I may be able to incorporate some of the ideas/features into the CAM userland stuff. I've already incorporated the buffer parsing code from libscsi into libcam, and I've put the mode page editing code from scsi(8) into camcontrol. (neither is in the currently released snapshot, but both will be in the next snapshot) One thing I'll probably do is make hardlinks to camcontrol so that there are several different programs you can call, rather than trying to remember command line switches that sometimes don't really resemble the functions they perform. i.e.: scsi_tur, scsi_start, scsi_stop, scsi_read_defects, scsi_inquiry, scsi_cmd, scsi_mode_page, scsi_rescan, and so on. > As I've said in the past, IMHO programs are better than libraries. Well, I think it's a good idea to put code in a library if it could be generally useful. Thus the idea behind libscsi and libcam -- there are some interface routines that more programs than scsi(8) and camcontrol(8) would want to use. 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 Jun 21 16:21:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23759 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 16:21:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA23721 for ; Sun, 21 Jun 1998 16:21:22 -0700 (PDT) (envelope-from jmz@cabri.obs-besancon.fr) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA10744; Mon, 22 Jun 98 01:25:02 +0200 Date: Mon, 22 Jun 98 01:25:02 +0200 Message-Id: <9806212325.AA10744@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: ken@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199806191730.LAA12458@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: Rolling CAM in, what is still needed? X-Mailer: Emacs Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> Kenneth D Merry writes: > Right, that's what I'm interested in. I talked to Julian this > morning (in person, actually!) and that's the question I had. So I'll say > it so everyone can see: > - How many more programs use this (scsireq) interface? /usr/ports/sysutils/cd-write/ > - Are people going to yell and scream loudly if it goes away when CAM > is integrated into the tree?? Not if the new interface is well documented ;-) Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 16:42:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27147 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 16:42:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27087 for ; Sun, 21 Jun 1998 16:42:27 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id TAA28473; Sun, 21 Jun 1998 19:15:33 -0400 (EDT) From: Peter Dufault Message-Id: <199806212315.TAA28473@hda.hda.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806212227.QAA24363@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 21, 98 04:27:00 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 21 Jun 1998 19:15:33 -0400 (EDT) Cc: dufault@hda.com, ken@plutotech.com, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > > I don't know where it is archived now. There wasn't much interest > > in this the last time I showed it around. > > Well, I would be interested in taking a look at it. I may be able > to incorporate some of the ideas/features into the CAM userland stuff. It is at least in my home directory on freefall, and is someplace else. I've lost track of what the incoming elves do to files uploaded to incoming. I poked around on the FreeBSD home page and didn't find out. If you don't see it I can upload another copy. > I've already incorporated the buffer parsing code from libscsi into libcam, > and I've put the mode page editing code from scsi(8) into camcontrol. > (neither is in the currently released snapshot, but both will be in the > next snapshot) Good - then you may like the newer stuff. I didn't incorporate it into scsi(8) because I didn't want an sbin binary to grow. I don't know what your plans are for camcontrol, however, you'll probably want to keep the sbin-ness in mind. The server ability would be good even for a program in sbin to support remote support on some sort of embedded scsi device. > One thing I'll probably do is make hardlinks to camcontrol so that > there are several different programs you can call, rather than trying to > remember command line switches that sometimes don't really resemble the > functions they perform. i.e.: scsi_tur, scsi_start, scsi_stop, > scsi_read_defects, scsi_inquiry, scsi_cmd, scsi_mode_page, scsi_rescan, and > so on. I don't like this - this boils down to "scsi_tur" versus "scsi tur". > > As I've said in the past, IMHO programs are better than libraries. > > Well, I think it's a good idea to put code in a library if it could > be generally useful. Thus the idea behind libscsi and libcam -- there are > some interface routines that more programs than scsi(8) and camcontrol(8) > would want to use. Yes, there is always a baseline that should be at least designed as if it is in a library that a command will be based on, and that should be formally placed in a library. Since you have less control over what people do with your library and pretty much full control over the interface to your program, and because a programs interface is typically higher level and easier to change, I'm a bigger fan of a program interface than a library interface. Porting scsi programs over is the only place I see a library useful. The notion behind scsinew is you prototype using the command interface and that have it spit out code if you need it. Just to show I'm not a stickler about high level interfaces, I think that in addition to preserving the current ioctl interface (which I think should be done) it would be good to support the Linux SCSI interface thus extending the Linux binary support. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 18:49:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA17597 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 18:49:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA17592 for ; Sun, 21 Jun 1998 18:49:15 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id WAA02248 for scsi@freebsd.org; Sun, 21 Jun 1998 22:49:17 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806220149.WAA02248@roma.coe.ufrj.br> Subject: CAM floppy, where is it ??? To: scsi@FreeBSD.ORG Date: Sun, 21 Jun 1998 22:49:17 -0300 (EST) X-Mailer: ELM [version 2.4ME+ PL40 (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 The subject says it all. I've looked at pub/FreeBSD/cam at cdrom.com, but it's not there. Nor could I find it in the list archives. TIA, Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 21 21:41:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10552 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 21:41:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10539 for ; Sun, 21 Jun 1998 21:40:59 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id WAA25738; Sun, 21 Jun 1998 22:40:51 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806220440.WAA25738@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806212315.TAA28473@hda.hda.com> from Peter Dufault at "Jun 21, 98 07:15:33 pm" To: dufault@hda.com (Peter Dufault) Date: Sun, 21 Jun 1998 22:40:50 -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 Peter Dufault wrote... > > > I don't know where it is archived now. There wasn't much interest > > > in this the last time I showed it around. > > > > Well, I would be interested in taking a look at it. I may be able > > to incorporate some of the ideas/features into the CAM userland stuff. > > It is at least in my home directory on freefall, and is someplace > else. I've lost track of what the incoming elves do to files > uploaded to incoming. I poked around on the FreeBSD home page and didn't > find out. If you don't see it I can upload another copy. I don't have an account on freefall, and I don't see it in the incoming directory. Could you upload it again? > > I've already incorporated the buffer parsing code from libscsi into libcam, > > and I've put the mode page editing code from scsi(8) into camcontrol. > > (neither is in the currently released snapshot, but both will be in the > > next snapshot) > > Good - then you may like the newer stuff. I didn't incorporate > it into scsi(8) because I didn't want an sbin binary to grow. I don't > know what your plans are for camcontrol, however, you'll probably > want to keep the sbin-ness in mind. The server ability would be > good even for a program in sbin to support remote support on some > sort of embedded scsi device. Hmm, yeah, I'll have to keep the size in mind. The current version of camcontrol is only about 100K, which is smaller than many of the programs in /sbin. I'll have to take a look at this server capability, it sounds interesting. > > One thing I'll probably do is make hardlinks to camcontrol so that > > there are several different programs you can call, rather than trying to > > remember command line switches that sometimes don't really resemble the > > functions they perform. i.e.: scsi_tur, scsi_start, scsi_stop, > > scsi_read_defects, scsi_inquiry, scsi_cmd, scsi_mode_page, scsi_rescan, and > > so on. > > I don't like this - this boils down to "scsi_tur" versus "scsi tur". Good point. I guess I could just do it that way. Basically, the problem I have now is that camcontrol is starting to get optionitis. I can just continue to use more option letters, or I can try doing something to make it a little more sane. Here's what the current usage statement looks like: usage: camcontrol [ optional args ] camcontrol -l [-n dev_name] [-u unit] camcontrol -t [ optional args ] camcontrol -i [-D] [-S] [-R] [ optional args ] camcontrol -s <0|1> [-j] [ optional args ] camcontrol -r camcontrol -d -f format [-P] [-G] [ optional args ] camcontrol -m page [-p pagectl] [-e] [-B] [ optional args ] camcontrol -c cmd [opt. args] <-I len fmt|-O len fmt [args]> Specify one of the following options: -l list all CAM devices attached to a device -t send a test unit ready to the named device -i send a SCSI inquiry command to the named device -s <0|1> send a Start or Stop Unit command to the device -r rescan the given bus, or bus/target/lun -d read the defect list of the specified device -m page display or edit (-e) the given mode page -c cmd send the given scsi command, needs -I or -O as well Optional arguments: -v be verbose, print out sense information -T timeout command timeout in seconds, overrides default timeout -n dev_name specify device name (default is da) -u unit specify unit number (default is 0) -E have the kernel attempt to perform SCSI error recovery -C count specify the SCSI command retry count (needs -E to work) -e edit the specified mode page (used only with -m) -B disable block descriptors for mode sense (used with -m) -p pgctl page control field 0-3 (used with -m) -j load or eject media -- can only be used with -s -f format specify defect list format (block, bfi or phys) -G get the grown defect list (used only with -d) -P get the permanant defect list (used only with -d) -D get the standard inquiry data (used only with -i) -S get the serial number (can only be used with -i) -R get the transfer rate, etc. (used only with -i) -I fmt specify input data and input data format (used with -c) -O fmt specify output data and output data fmt (used with -c) Fair number of options, 'eh? Maybe what you're saying would work better, i.e.: camcontrol inquiry -S da0 (I may try putting in support for just specifying devices like that instead of -n da -u 0 if I end up re-working the command line options.) A complicating factor to all this is all the arguments for the command line CDB parsing code. > Just to show I'm not a stickler about high level interfaces, I > think that in addition to preserving the current ioctl interface > (which I think should be done) it would be good to support > the Linux SCSI interface thus extending the Linux binary support. That is an option, although I'd have to look at it and see what it would entail. Linux binary support is good, since it allows us to run commercial applications that haven't been ported to FreeBSD. The question is, what sort of application base are we talking about here? Are there lots of binary-only Linux applications (or even just one major application) that need SCSI passthrough support? I'm still not convinced it's absolutely necessary to support even the current ioctl interface, since I haven't really heard of many programs that would be affected. The current list is: cd-write, SANE, and cdd. (cdrecord, tosha and xmcd have been ported) That certainly isn't an insurmountable list, and once those are ported, it'll be a simple matter of rebuilding the port once we switch over to CAM. You say that you think we should support the current ioctl interface. Other folks have said we should support it for one release, and then take it out, and others have said they don't care as long as the new interface is documented. I'm really not opposed to any of these approaches, but I'd like to know why you think we ought to continue to support the current interface. As far as applications go, I haven't seen that there are any really sticky problems so far. I think that supporting the current interface for one release might be a good idea, although people will probably still scream when we remove it in FreeBSD 3.1 or 4.0. Anyway, I'm just trying to get a feel for what your reasoning is. I'm not opposed to doing it, but I haven't really seen a good argument for continuing to support 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 Sun Jun 21 22:00:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA13099 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 22:00:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA13044 for ; Sun, 21 Jun 1998 22:00:23 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 29760 invoked by uid 1000); 22 Jun 1998 05:01:00 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 22 Jun 1998 01:01:00 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: alex@nac.net Subject: RE: DPT support binaries - How to Setup Cc: freebsd-SCSI@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, Chris Parry , Tom Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 21-Jun-98 alex@nac.net wrote: > > Search the archives; there are about 10 instances of this in the past 2 > months. READ the archives. > It is when the array is in degraded mode, and you try to boot. No, it is not. It is when the array is in DEAD/Rebuilding mode, and then only with firmware 7mo, which was never certified by me and was alerted against. >> > > What does the DPT do in case of disk failure? >> > >> > Usually kernel panic on bootup, but thats irrelevant. >> >> Of course, thats just you. I don't see this at all, and I've tried >> the fail/rebuild procedure many times. Please either read the code, provide exact kernel dumps to document the point of failure, or stop this nonsense. I have said and demonstrated many times before; I am willing and eager to help those who want to be helped. I have neither the time nor the desire to dive into undocumented wild geese chase, nor this verbal sparring you enjoy so much. If you know of a better RAID solotion, post it here. If you want to write a better DPT driver, please do. Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 00:47:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA10573 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 00:47:12 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from top.worldcontrol.com (surf52.cruzers.com [205.215.232.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA10562 for ; Mon, 22 Jun 1998 00:47:04 -0700 (PDT) (envelope-from brian@worldcontrol.com) From: brian@worldcontrol.com Received: (qmail 2590 invoked by uid 100); 22 Jun 1998 07:47:05 -0000 Message-ID: <19980622004701.A2547@top.worldcontrol.com> Date: Mon, 22 Jun 1998 00:47:01 -0700 To: freebsd-questions@FreeBSD.ORG Cc: freebsd-scsi@FreeBSD.ORG Subject: cdrecord and aic7880 broken! (works with aic7870) Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.91i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Summary: Using the 2940UW (aic 7880) controller burns fail 100% of the time. Using the 2940W (aic 7870) controller burns succeed 100% of the time. Details: I have a -current SMP 2xPP150 system with two Adaptec 2940 SCSI controllers (one is Wide, the other is UltraWide). I recently purchased a Ricoh 6200S CD-RW and have been failing to sucessfully burn a CD. When the CD-R is connected to the 2940UW (aic 7880) as follows: Jun 21 13:54:53 bls2 ahc0: rev 0x01 int a irq 18 on pci0.12.0 Jun 21 13:54:53 bls2 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Jun 21 13:54:53 bls2 ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers Jun 21 13:54:53 bls2 /kernel: cd0 at scbus0 target 1 lun 0 Jun 21 13:54:53 bls2 cd0: type 5 removable SCSI 2 Jun 21 13:54:53 bls2 cd0: CD-ROM cd present [400000 x 2048 byte records] the CD burns consistently fail (100% failure in 10 tries) at some time during the burn. The failure is included below. The timeout can occur at any point in the burn. Once it happened on block 416 out of 449. The failures occur in -dummy and in real burns. HOWEVER, when the CD-R is connected to the 2940W (aic 7870) as follows: Jun 21 14:46:22 bls2 ahc0: rev 0x03 int a irq 16 on pci0.14.0 Jun 21 14:46:22 bls2 ahc0: aic7870 Wide Channel, SCSI Id=7, 16 SCBs Jun 21 14:46:22 bls2 ahc0: waiting for scsi devices to settle Jun 21 14:46:22 bls2 /kernel: scbus0 at ahc0 bus 0 Jun 21 14:46:22 bls2 /kernel: sd0 at scbus0 target 0 lun 0 Jun 21 14:46:22 bls2 ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers Jun 21 14:46:22 bls2 /kernel: cd0 at scbus0 target 1 lun 0 Jun 21 14:46:22 bls2 cd0: type 5 removable SCSI 2 Jun 21 14:46:22 bls2 cd0: CD-ROM cd present [400000 x 2048 byte records] The burns and -dummy burns work reliably 100% (6 tries) of the time. Here is the error that occurs when using the 2940UW (aic 7880): Cdrecord release 1.6 Copyright (C) 1995-1998 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '0,1,0' scsibus: 0 target: 1 lun: 0 Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : Vendor_info : 'RICOH ' Identifikation : 'MP6200S ' Revision : '2.20' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Track 01: data 442 MB Total size: 508 MB (50:22.68) = 226701 sectors Lout start: 508 MB (50:24/51) = 226701 sectors ATIP info from disk: Indicated writing power: 6 Is not unrestricted Is not erasable ATIP start of lead in: -11597 (97:27/28) ATIP start of lead out: 336601 (74:50/01) Disk type: Phthalocyanine or similar Manufacturer: Princo Corporation Blocks total: 336601 Blocks remaining: 336601 Starting to write CD at speed 2 in write mode for single session. Last chance to quit, starting real write in 1 seconds. Waiting for reader process to fill input-buffer ... input-buffer ready. Starting new track at sector: 0 Track 01: 0 of 442 MB written. ... Track 01: 416 of 442 MB written (fifo 100%). cdrecord: Undefined error: 0. write_g1: scsi sendcmd: cmd timeout after 42.033 (40) s CDB: 2A 00 00 03 40 26 00 00 1E 00 resid: 61440 cmd finished after 42.033s timeout 40s cdrecord: Undefined error: 0. request_sense: scsi sendcmd: cmd timeout after 42.036 (40) s write track data: error after 436285440 bytes CDB: 03 00 00 00 12 00 resid: 18 cmd finished after 42.036s timeout 40s cdrecord: Undefined error: 0. flush cache: scsi sendcmd: retryable error status: 0x2 (CHECK CONDITION) CDB: 35 00 00 00 00 00 00 00 00 00 Sense Bytes: 70 00 06 00 00 00 00 0A 00 00 00 00 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x6 Unit Attention, Segment 0 Sense Code: 0x29 Qual 0x00 (power on, reset, or bus device reset occurred) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.012s timeout 120s Trouble flushing the cache Writing time: 1514.012s Fixating... cdrecord: Undefined error: 0. close track/session: scsi sendcmd: retryable error status: 0x2 (CHECK CONDITION) CDB: 5B 00 02 00 00 00 00 00 00 00 Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 71 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x71 Qual 0x04 (decompression exception long algorithm id) [No matching qualifier] Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.008s timeout 480s cdrecord: fifo had 7169 puts and 7102 gets. cdrecord: fifo was 0 times empty and 7088 times full, min fill was 89%. Fixating time: 0.011s -- Brian Litzinger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 03:18:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA05346 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 03:18:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nt5.spline.net (nt5.ipi.kiev.ua [194.44.182.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA05289 for ; Mon, 22 Jun 1998 03:18:18 -0700 (PDT) (envelope-from tat@Spline.NET) Received: from localhost (tat@localhost) by nt5.spline.net (8.8.8/8.8.7) with SMTP id NAA08351; Mon, 22 Jun 1998 13:17:59 +0300 (EEST) Date: Mon, 22 Jun 1998 13:17:59 +0300 (EEST) From: Alexander Tatmaniants To: Joao Carlos Mendes Luis cc: scsi@FreeBSD.ORG Subject: Re: CAM floppy, where is it ??? In-Reply-To: <199806220149.WAA02248@roma.coe.ufrj.br> Message-ID: Replay-To: tat@spline.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Jun 1998, Joao Carlos Mendes Luis wrote: > Date: Sun, 21 Jun 1998 22:49:17 -0300 (EST) > From: Joao Carlos Mendes Luis > To: scsi@FreeBSD.ORG > Subject: CAM floppy, where is it ??? > > The subject says it all. I've looked at pub/FreeBSD/cam at > cdrom.com, but it's not there. Nor could I find it in the > list archives. It's at http://www.freebsd.org/~abial > > TIA, > > Jonny > > -- > Joao Carlos Mendes Luis M.Sc. Student > jonny@jonny.eng.br Universidade Federal do Rio de Janeiro > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 04:05:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA11136 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 04:05:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11099 for ; Mon, 22 Jun 1998 04:04:58 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA00170; Mon, 22 Jun 1998 06:39:32 -0400 (EDT) From: Peter Dufault Message-Id: <199806221039.GAA00170@hda.hda.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806220440.WAA25738@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 21, 98 10:40:50 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Mon, 22 Jun 1998 06:39:32 -0400 (EDT) Cc: dufault@hda.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > I don't have an account on freefall, and I don't see it in the > incoming directory. Could you upload it again? Yes. To compile properly on a recent system you'll have to sprinkle in some includes courtesy of advances in reducing system include nesting. I won't have time to do that so heads up. (...) > > I don't like this - this boils down to "scsi_tur" versus "scsi tur". > > Good point. I guess I could just do it that way. Basically, the > problem I have now is that camcontrol is starting to get optionitis. I can > just continue to use more option letters, or I can try doing something to > make it a little more sane. Here's what the current usage statement looks > like: > > usage: camcontrol [ optional args ] ... (And now I cut out an argument for needing more lines in syscons...) > > Fair number of options, 'eh? Maybe what you're saying would work > better, i.e.: > > camcontrol inquiry -S da0 It is also extensible in the ASCII config file so more creeping options aren't needed and instead of sending magic command lines you can send a config snippet. > (I may try putting in support for just specifying devices like that instead > of -n da -u 0 if I end up re-working the command line options.) A > complicating factor to all this is all the arguments for the command line > CDB parsing code. Can you provide a look up table for device nicknames between scsi(8) and camcontrol? The newer one at least knows how to go from sd0 to /dev/rsd0.ctl. > > Just to show I'm not a stickler about high level interfaces, I > > think that in addition to preserving the current ioctl interface > > (which I think should be done) it would be good to support > > the Linux SCSI interface thus extending the Linux binary support. > > That is an option, although I'd have to look at it and see what it > would entail. Linux binary support is good, since it allows us to run > commercial applications that haven't been ported to FreeBSD. The question > is, what sort of application base are we talking about here? Are there > lots of binary-only Linux applications (or even just one major application) > that need SCSI passthrough support? There are many that already have FreeBSD native interfaces. It is a question of deciding whether to commit to that part of the Linux ABI. It is far more important to support the clean cutover for the FreeBSD installed base, and time is better spent ensuring that than any Linux adventure. > I'm still not convinced it's absolutely necessary to support > even the current ioctl interface, since I haven't really heard of many > programs that would be affected. The current list is: cd-write, SANE, and > cdd. (cdrecord, tosha and xmcd have been ported) That certainly isn't an > insurmountable list, and once those are ported, it'll be a simple matter of > rebuilding the port once we switch over to CAM. You've provided the important one from my point of view which is the command interface. The point is that in the last few months I've had three groups contacting me about embedded SCSI in FreeBSD. Some are going on their own and I've pointed all of them at you folk. However, the current CAM versus "classic" and the issue of volatility for the next two years is a murky one. My opinion is that policy should be "we shall make it painless until it is a non-issue" and never "you shall be assimilated" (which snuck out earlier - Hi Mike). Public statements should be weighed against ensuring this aspect is a non-issue. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 04:24:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14803 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 04:24:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA14795 for ; Mon, 22 Jun 1998 04:24:48 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA00230; Mon, 22 Jun 1998 06:59:23 -0400 (EDT) From: Peter Dufault Message-Id: <199806221059.GAA00230@hda.hda.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806220440.WAA25738@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 21, 98 10:40:50 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Mon, 22 Jun 1998 06:59:22 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > Peter Dufault wrote... > > > > I don't know where it is archived now. There wasn't much interest > > > > in this the last time I showed it around. > > > > > > Well, I would be interested in taking a look at it. I may be able > > > to incorporate some of the ideas/features into the CAM userland stuff. > > > > It is at least in my home directory on freefall, and is someplace > > else. I've lost track of what the incoming elves do to files > > uploaded to incoming. I poked around on the FreeBSD home page and didn't > > find out. If you don't see it I can upload another copy. > > I don't have an account on freefall, and I don't see it in the > incoming directory. Could you upload it again? > > > > I've already incorporated the buffer parsing code from libscsi into libcam, > > > and I've put the mode page editing code from scsi(8) into camcontrol. > > > (neither is in the currently released snapshot, but both will be in the > > > next snapshot) > > > > Good - then you may like the newer stuff. I didn't incorporate > > it into scsi(8) because I didn't want an sbin binary to grow. I don't > > know what your plans are for camcontrol, however, you'll probably > > want to keep the sbin-ness in mind. The server ability would be > > good even for a program in sbin to support remote support on some > > sort of embedded scsi device. > > Hmm, yeah, I'll have to keep the size in mind. The current version > of camcontrol is only about 100K, which is smaller than many of the > programs in /sbin. I'll have to take a look at this server capability, it > sounds interesting. > > > > > One thing I'll probably do is make hardlinks to camcontrol so that > > > there are several different programs you can call, rather than trying to > > > remember command line switches that sometimes don't really resemble the > > > functions they perform. i.e.: scsi_tur, scsi_start, scsi_stop, > > > scsi_read_defects, scsi_inquiry, scsi_cmd, scsi_mode_page, scsi_rescan, and > > > so on. > > > > I don't like this - this boils down to "scsi_tur" versus "scsi tur". > > Good point. I guess I could just do it that way. Basically, the > problem I have now is that camcontrol is starting to get optionitis. I can > just continue to use more option letters, or I can try doing something to > make it a little more sane. Here's what the current usage statement looks > like: > > usage: camcontrol [ optional args ] > camcontrol -l [-n dev_name] [-u unit] > camcontrol -t [ optional args ] > camcontrol -i [-D] [-S] [-R] [ optional args ] > camcontrol -s <0|1> [-j] [ optional args ] > camcontrol -r > camcontrol -d -f format [-P] [-G] [ optional args ] > camcontrol -m page [-p pagectl] [-e] [-B] [ optional args ] > camcontrol -c cmd [opt. args] <-I len fmt|-O len fmt [args]> > Specify one of the following options: > -l list all CAM devices attached to a device > -t send a test unit ready to the named device > -i send a SCSI inquiry command to the named device > -s <0|1> send a Start or Stop Unit command to the device > -r rescan the given bus, or bus/target/lun > -d read the defect list of the specified device > -m page display or edit (-e) the given mode page > -c cmd send the given scsi command, needs -I or -O as well > Optional arguments: > -v be verbose, print out sense information > -T timeout command timeout in seconds, overrides default timeout > -n dev_name specify device name (default is da) > -u unit specify unit number (default is 0) > -E have the kernel attempt to perform SCSI error recovery > -C count specify the SCSI command retry count (needs -E to work) > -e edit the specified mode page (used only with -m) > -B disable block descriptors for mode sense (used with -m) > -p pgctl page control field 0-3 (used with -m) > -j load or eject media -- can only be used with -s > -f format specify defect list format (block, bfi or phys) > -G get the grown defect list (used only with -d) > -P get the permanant defect list (used only with -d) > -D get the standard inquiry data (used only with -i) > -S get the serial number (can only be used with -i) > -R get the transfer rate, etc. (used only with -i) > -I fmt specify input data and input data format (used with -c) > -O fmt specify output data and output data fmt (used with -c) > > Fair number of options, 'eh? Maybe what you're saying would work > better, i.e.: > > camcontrol inquiry -S da0 > > (I may try putting in support for just specifying devices like that instead > of -n da -u 0 if I end up re-working the command line options.) A > complicating factor to all this is all the arguments for the command line > CDB parsing code. > > > Just to show I'm not a stickler about high level interfaces, I > > think that in addition to preserving the current ioctl interface > > (which I think should be done) it would be good to support > > the Linux SCSI interface thus extending the Linux binary support. > > That is an option, although I'd have to look at it and see what it > would entail. Linux binary support is good, since it allows us to run > commercial applications that haven't been ported to FreeBSD. The question > is, what sort of application base are we talking about here? Are there > lots of binary-only Linux applications (or even just one major application) > that need SCSI passthrough support? > > I'm still not convinced it's absolutely necessary to support > even the current ioctl interface, since I haven't really heard of many > programs that would be affected. The current list is: cd-write, SANE, and > cdd. (cdrecord, tosha and xmcd have been ported) That certainly isn't an > insurmountable list, and once those are ported, it'll be a simple matter of > rebuilding the port once we switch over to CAM. > > You say that you think we should support the current ioctl > interface. Other folks have said we should support it for one release, and > then take it out, and others have said they don't care as long as the new > interface is documented. I'm really not opposed to any of these > approaches, but I'd like to know why you think we ought to continue to > support the current interface. As far as applications go, I haven't seen > that there are any really sticky problems so far. > > I think that supporting the current interface for one release might > be a good idea, although people will probably still scream when we remove > it in FreeBSD 3.1 or 4.0. > > Anyway, I'm just trying to get a feel for what your reasoning is. > I'm not opposed to doing it, but I haven't really seen a good argument for > continuing to support 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 > -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 04:35:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA15662 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 04:35:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA15655 for ; Mon, 22 Jun 1998 04:35:38 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id HAA10327 for ; Mon, 22 Jun 1998 07:35:34 -0400 (EDT) Date: Mon, 22 Jun 1998 07:35:34 -0400 (EDT) From: The Hermit Hacker To: scsi@FreeBSD.ORG Subject: hub security check output (fwd) 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 Can someone explain to me what the following means? Is this something I should be concerned with (ie. drive is dying?) :( hub kernel log messages: > pid 6405 (pine), uid 10: exited on signal 6 (core dumped) > (da2:ahc1:0:1:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR == 0x115 > SSTAT1 == 0x13 > (da1:ahc1:0:0:0): SCB 0x3b - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR == 0x115 > SSTAT1 == 0x13 > (da1:ahc1:0:0:0): BDR message in message buffer > (da1:ahc1:0:0:0): SCB 0x3b - timed out in dataout phase, SCSISIGI == 0xf6 > SEQADDR == 0x115 > SSTAT1 == 0x13 > (da1:ahc1:0:0:0): no longer in timeout, status = 34b > ahc1: Issued Channel A Bus Reset. 31 SCBs aborted > (da1:ahc1:0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > SEQADDR == 0x18b > SSTAT1 == 0x0 > (da1:ahc1:0:0:0): Queuing a BDR SCB > (da1:ahc1:0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > SEQADDR == 0x18b > SSTAT1 == 0x0 > (da1:ahc1:0:0:0): no longer in timeout, status = 34b > ahc1: Issued Channel A Bus Reset. 25 SCBs aborted > (da1:ahc1:0:0:0): WRITE(10). CDB: 2a 0 0 64 eb 50 0 0 10 0 > (da1:ahc1:0:0:0): UNIT ATTENTION asc:29,2 > (da1:ahc1:0:0:0): Scsi bus reset occurred > free inode /news/54690 had 832 blocks > pid 22604 (httpd), uid 0: exited on signal 6 > pid 5979 (vi), uid 1098: exited on signal 11 (core dumped) > pid 6043 (vi), uid 1098: exited on signal 11 (core dumped) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 09:07:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24622 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 09:07:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from enigami.com (enigami.com [208.140.182.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA24597 for ; Mon, 22 Jun 1998 09:07:36 -0700 (PDT) (envelope-from ckempf@enigami.com) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by enigami.com (8.9.0/8.9.0) with ESMTP id MAA18823; Mon, 22 Jun 1998 12:06:18 -0400 (EDT) Received: (from ckempf@localhost) by singularity.enigami.com (8.9.0/8.9.0) id MAA22329; Mon, 22 Jun 1998 12:05:14 -0400 (EDT) To: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: CAM & SANE... References: <199806182045.OAA08675@panzer.plutotech.com> From: Cory Kempf Date: 22 Jun 1998 12:05:13 -0400 In-Reply-To: "Kenneth D. Merry"'s message of "Thu, 18 Jun 1998 14:45:23 -0600 (MDT)" Message-ID: Lines: 31 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" writes: > > What is still needed before the CAM stuff can become part of the main > > body of code? At least w.r.t. -current? > > We don't yet have: > - SANE I have been planning on purchasing a scanner... I can take a pot shot at this one. Not sure how much time I can put in on it though, so if someone with lots of free time :-) wants to pick it up, I won't be offended. I have looked at the source briefly, and it looks like this might already have been done for DEC's unix? So, this brings me to a question: I am intersted in purchasing a 600 dpi, 30+ bit SCSI scanner. There are several on the market. Any clues as to which vendors have been most helpful / willing to provide (SCSI-level) support / documentation? +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 Mon Jun 22 13:26:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12950 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 13:26:44 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA12848 for ; Mon, 22 Jun 1998 13:26:20 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yoCec-0000dL-00; Mon, 22 Jun 1998 12:53:26 -0700 Date: Mon, 22 Jun 1998 12:53:17 -0700 (PDT) From: Tom To: alex@nac.net cc: Simon Shapiro , Chris Parry , freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Jun 1998 alex@nac.net wrote: > Search the archives; there are about 10 instances of this in the past 2 > months. I've been on freebsd-scsi list a long time. The only instance was your system as I recall. > It is when the array is in degraded mode, and you try to boot. No. Done that here several times. However, you can't boot if the array is dead (RAID5 with two failed drives) but that goes without saying. I've seen an interesting scenario where a rebuild caused a marginal drive to fail, so you always want to try at least two simulated failures before bringing a new server online. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 13:42:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15833 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 13:42:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15776 for ; Mon, 22 Jun 1998 13:42:11 -0700 (PDT) (envelope-from laotzu@juniper.net) Received: from leaf.juniper.net (leaf.juniper.net [208.197.169.211]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id NAA29307; Mon, 22 Jun 1998 13:41:38 -0700 (PDT) Received: from localhost (laotzu@localhost) by leaf.juniper.net (8.8.8/8.7.3) with SMTP id NAA18281; Mon, 22 Jun 1998 13:41:38 -0700 (PDT) Date: Mon, 22 Jun 1998 13:41:38 -0700 (PDT) From: Chris Parry To: Tom cc: alex@nac.net, Simon Shapiro , freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup 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 > > It is when the array is in degraded mode, and you try to boot. > > No. Done that here several times. > > However, you can't boot if the array is dead (RAID5 with two failed > drives) but that goes without saying. I've seen an interesting scenario > where a rebuild caused a marginal drive to fail, so you always want to try > at least two simulated failures before bringing a new server online. It was my understanding that Alex was talking about a RAID-0 array (originally), which is the concatenated array (no redunancy). I definitely plan to trash this machine and see how it responds before bringing online for production work :) Anyway I'd like to bounce that architechure off of the group. First my goal is to have a RAID-1 mirror cvs depsitory for my company and want this machine to be rock stable. As I understand it, I can't really take two disks, install dos on one of them and then mirror them. So I was going to take two identical IDE drives, install DOS on a small partition, and then the FreeBSD OS on the rest of it. On the second IDE controller (so they are both masters on thier respective channels) have this disk be the target of a daily lowlevel dd of the the first disk. Then have the DPT controller be doing real RAID-1 on the cvs repository. Is there another way you all would recommend? Perhaps just doing everything from floppy and then RAID-1 the scsi drives (and just forget IDE), then install DOS and Freebsd? Also, when a drive fails (or I unplug it), will it only log to /var/log/messages? Anyone have an automated response mechanism installed to notify of disk failure? Thanks, -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 13:59:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18912 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 13:59:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tempest.nac.net (tempest.nac.net [209.123.20.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA18839 for ; Mon, 22 Jun 1998 13:58:59 -0700 (PDT) (envelope-from alex@nac.net) From: alex@nac.net Received: (qmail 14441 invoked from network); 22 Jun 1998 16:52:35 -0400 Received: from iago.nac.net (alex@209.123.20.5) by tempest.nac.net with SMTP; 22 Jun 1998 16:52:35 -0400 Date: Mon, 22 Jun 1998 16:58:19 -0400 (EDT) To: Tom cc: Simon Shapiro , Chris Parry , freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Jun 1998, Tom wrote: > > On Sun, 21 Jun 1998 alex@nac.net wrote: > > > Search the archives; there are about 10 instances of this in the past 2 > > months. > > I've been on freebsd-scsi list a long time. The only instance was your > system as I recall. Funny; I never posted anything on it. You need to hone your searching tools a little :-) > > It is when the array is in degraded mode, and you try to boot. > > No. Done that here several times. > > However, you can't boot if the array is dead (RAID5 with two failed > drives) but that goes without saying. I've seen an interesting scenario > where a rebuild caused a marginal drive to fail, so you always want to try > at least two simulated failures before bringing a new server online. Duh. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 14:20:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23778 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 14:20:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tor-dev1.nbc.netcom.ca (tor-dev1.nbc.netcom.ca [207.181.89.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23601 for ; Mon, 22 Jun 1998 14:19:02 -0700 (PDT) (envelope-from dacole@netcom.ca) Received: from localhost (dacole@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) with SMTP id RAA28409 for ; Mon, 22 Jun 1998 17:18:32 -0400 (EDT) X-Authentication-Warning: tor-dev1.nbc.netcom.ca: dacole owned process doing -bs Date: Mon, 22 Jun 1998 17:18:32 -0400 (EDT) From: Dave Cole X-Sender: dacole@tor-dev1.nbc.netcom.ca To: freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806221059.GAA00230@hda.hda.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 Just a quick question.. When might CAM be rolled in? If it isn't likely any time soon, is there another snapshot coming up? ---------------------------------------------------------------- Dave Cole (DC1110) | dacole@netcom.ca Systems Administrator |* dacole@rik.net * | office/~dacole/ Netcom Canada |* www.rik.net/~dacole/ * 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 15:55:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13968 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 15:55:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13918 for ; Mon, 22 Jun 1998 15:55:12 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA00149; Mon, 22 Jun 1998 16:55:09 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806222255.QAA00149@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: from Dave Cole at "Jun 22, 98 05:18:32 pm" To: dacole@netcom.ca (Dave Cole) Date: Mon, 22 Jun 1998 16:55:09 -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 Dave Cole wrote... > Just a quick question.. When might CAM be rolled in? If it isn't > likely any time soon, is there another snapshot coming up? Umm, I answered your first question (when will CAM be rolled in) last week in my first response to this thread. As for when another snapshot is coming out, I don't know. It depends on when Justin feels like it, has time, etc. (time is the critical issue right now) My guess is that it'll be a week at least. 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 Jun 22 16:23:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA19830 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 16:23:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA19795 for ; Mon, 22 Jun 1998 16:23:36 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 3757 invoked by uid 1000); 22 Jun 1998 23:24:18 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 22 Jun 1998 19:24:18 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Tom Subject: RE: DPT support binaries - How to Setup Cc: freebsd-SCSI@FreeBSD.ORG, Chris Parry , alex@nac.net Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22-Jun-98 Tom wrote: > > On Sun, 21 Jun 1998 alex@nac.net wrote: > >> Search the archives; there are about 10 instances of this in the past 2 >> months. > > I've been on freebsd-scsi list a long time. The only instance was your > system as I recall. > >> It is when the array is in degraded mode, and you try to boot. > > No. Done that here several times. > > However, you can't boot if the array is dead (RAID5 with two failed > drives) but that goes without saying. I've seen an interesting scenario > where a rebuild caused a marginal drive to fail, so you always want to > try > at least two simulated failures before bringing a new server online. About 2 out of 5 builds failed with firmware 7M0. The same hardware later revealed a bad disk shelf (one of the busses alarms continually). We moved the disks to another bay (SE rather than Differential) and controller, and the failure re-occured. This time changing a damaged cable cured it. I think you are right about the build process exposing weaknesses in the drives. I also think there is some sensitivity in the firmware. I have traced and verified the driver and am of the opinion that it is not FreeBSD (or driver) related. To change my mind, provide me with a core dump, and/or a trace that shows the nature of the crash. Otherwise, I'll quote my bootcamp seargant; ``talk is cheap''. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 16:30:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21403 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 16:30:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA21387 for ; Mon, 22 Jun 1998 16:30:46 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 3855 invoked by uid 1000); 22 Jun 1998 23:31:29 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 22 Jun 1998 19:31:29 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Chris Parry Subject: RE: DPT support binaries - How to Setup Cc: freebsd-SCSI@FreeBSD.ORG, alex@nac.net, Tom Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22-Jun-98 Chris Parry wrote: >> > It is when the array is in degraded mode, and you try to boot. >> >> No. Done that here several times. >> >> However, you can't boot if the array is dead (RAID5 with two failed >> drives) but that goes without saying. I've seen an interesting scenario >> where a rebuild caused a marginal drive to fail, so you always want to >> try >> at least two simulated failures before bringing a new server online. > > It was my understanding that Alex was talking about a RAID-0 array > (originally), which is the concatenated array (no redunancy). I > definitely plan to trash this machine and see how it responds before > bringing online for production work :) Ah. RAID-0 is definitely ``all or nothing'' proposition. BTW, RAID-0 is NOT concatenated. It is striped; Every N kilobytes the data shifts to another drive. This is why, in case of failure of a single drive you can get almost nothing useful out. Were it to be concatenated, only a disk-size single hole would have existed. AS it is, RAID-0 failure leaves your data looking like a shotgun target. > Anyway I'd like to bounce that architechure off of the group. First my > goal is to have a RAID-1 mirror cvs depsitory for my company and want > this > machine to be rock stable. As I understand it, I can't really take two > disks, install dos on one of them and then mirror them. So I was going > to > take two identical IDE drives, install DOS on a small partition, and then > the FreeBSD OS on the rest of it. On the second IDE controller (so they > are both masters on thier respective channels) have this disk be the > target of a daily lowlevel dd of the the first disk. Then have the DPT > controller be doing real RAID-1 on the cvs repository. IDE is not SCSI :-) What you want is doable, but you will not have automatic switchover, and you will be copying a lot of ``empty'' junk. The copy will not be efficient, as all the data will travel from the disk to userspace and back to disk. Also, note that changes occuring during the update will probably NOT end up in the mirror disk the way you like/think them to be. This can mean ``corrupted'' mirror. > Is there another way you all would recommend? Perhaps just doing > everything from floppy and then RAID-1 the scsi drives (and just forget > IDE), then install DOS and Freebsd? Yup. If you use a mirroring/RAID controller (they ARE available for IDE), then the O/S, and even the BIOS are not aware of the mirror, and the copying is done automatically. > Also, when a drive fails (or I unplug it), will it only log to > /var/log/messages? Anyone have an automated response mechanism installed > to notify of disk failure? I do, but it is not released yet. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 18:08:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA08234 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 18:08:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA08221 for ; Mon, 22 Jun 1998 18:08:40 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 28269 invoked from network); 23 Jun 1998 01:08:41 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 23 Jun 1998 01:08:41 -0000 Date: Mon, 22 Jun 1998 18:08:41 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: Chris Parry cc: Tom , alex@nac.net, Simon Shapiro , freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup 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 There might be a simpler solution, a company ARCIDE or something like that just released a RAID-1 IDE disk controller that's OS independent, and looks like a normal IDE drive. It uses a slot for power, but that's it. Might be worth checking into, as the tester at the magazine said it handled everything he threw at it. Note it is IDE only, not SCSI. It was about $250 as I recall. I will try to find the URL for it, but it was just reviewed in one of the popular PC mag's online. On Mon, 22 Jun 1998, Chris Parry wrote: > > > It is when the array is in degraded mode, and you try to boot. > > > > No. Done that here several times. > > > > However, you can't boot if the array is dead (RAID5 with two failed > > drives) but that goes without saying. I've seen an interesting scenario > > where a rebuild caused a marginal drive to fail, so you always want to try > > at least two simulated failures before bringing a new server online. > > It was my understanding that Alex was talking about a RAID-0 array > (originally), which is the concatenated array (no redunancy). I > definitely plan to trash this machine and see how it responds before > bringing online for production work :) > > Anyway I'd like to bounce that architechure off of the group. First my > goal is to have a RAID-1 mirror cvs depsitory for my company and want this > machine to be rock stable. As I understand it, I can't really take two > disks, install dos on one of them and then mirror them. So I was going to > take two identical IDE drives, install DOS on a small partition, and then > the FreeBSD OS on the rest of it. On the second IDE controller (so they > are both masters on thier respective channels) have this disk be the > target of a daily lowlevel dd of the the first disk. Then have the DPT > controller be doing real RAID-1 on the cvs repository. > > Is there another way you all would recommend? Perhaps just doing > everything from floppy and then RAID-1 the scsi drives (and just forget > IDE), then install DOS and Freebsd? > > Also, when a drive fails (or I unplug it), will it only log to > /var/log/messages? Anyone have an automated response mechanism installed > to notify of disk failure? > > Thanks, > -chris > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 18:15:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA09410 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 18:15:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA09375 for ; Mon, 22 Jun 1998 18:15:37 -0700 (PDT) (envelope-from perry@zso.dec.com) Received: from rust.zso.dec.com (rust.zso.dec.com [16.64.0.1]) by mail12.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id VAA04328 for ; Mon, 22 Jun 1998 21:15:38 -0400 (EDT) Received: from yakko.zso.dec.com by rust.zso.dec.com (5.65/DECwest-CLUSTRIX-mwd-12Dec94) id AA13334; Mon, 22 Jun 1998 18:15:36 -0700 Received: by yakko.zso.dec.com (5.65v4.0/1.1.10.5/11Jul97-1112AM) id AA26218; Mon, 22 Jun 1998 18:15:36 -0700 Message-Id: <199806230115.AA26218@yakko.zso.dec.com> Reply-To: perry@zso.dec.com X-Mailer: MH 6.8.4 To: freebsd-scsi@FreeBSD.ORG Subject: Confusion about message from CAM Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 22 Jun 1998 18:15:35 -0700 From: "Reginald S. Perry" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, I have installed 3.0-980520-SNAP and cam-980520. except for the inline .vs __inline issue in bt.c, everything went fine. My problem comes from what CAM is telling me about my disks. I have 2 IBM DCAS-34330W 4.33GB Ultra Wide SCSI drives. I have some questions. Why does da0 report 3.300MB/s transfers and da1 report 10.0MB/s transfers? Why is this not 20.0MB/s since they are ultra wide drives? Is this a problem? If so, how can I correct this? Here is what CAM tells me: Jun 22 17:46:47 dot /kernel: da0 at bt0 bus 0 target 0 lun 0 Jun 22 17:46:47 dot /kernel: da0: Fixed Direct Access SCSI2 device Jun 22 17:46:47 dot /kernel: da0: Serial Number F35M1972 Jun 22 17:46:47 dot /kernel: da0: 3.300MB/s transfers , Tagged Queueing Enabled Jun 22 17:46:47 dot /kernel: da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Jun 22 17:46:47 dot /kernel: da1 at bt0 bus 0 Jun 22 17:46:47 dot /kernel: target 4 lun 0 Jun 22 17:46:47 dot /kernel: da1: Fixed Direct Access SCSI2 device Jun 22 17:46:47 dot /kernel: da1: Serial Number B30V9885 Jun 22 17:46:47 dot /kernel: da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled Jun 22 17:46:47 dot /kernel: da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Thanks. -Reggie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 22 23:31:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA01511 for freebsd-scsi-outgoing; Mon, 22 Jun 1998 23:31:07 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA01501 for ; Mon, 22 Jun 1998 23:31:03 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.0/8.9.0) with ESMTP id PAA08388; Tue, 23 Jun 1998 15:44:54 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id PAA00397; Tue, 23 Jun 1998 15:43:47 +0930 (CST) Message-ID: <19980623154334.A392@freebie.lemis.com> Date: Tue, 23 Jun 1998 15:43:34 +0930 From: Greg Lehey To: "Kenneth D. Merry" , Joao Carlos Mendes Luis Cc: mjacob@feral.com, julian@whistle.com, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? References: <199806191742.OAA02683@roma.coe.ufrj.br> <199806210305.VAA20485@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806210305.VAA20485@panzer.plutotech.com>; from Kenneth D. Merry on Sat, Jun 20, 1998 at 09:05:37PM -0600 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 20 June 1998 at 21:05:37 -0600, Kenneth D. Merry wrote: > Joao Carlos Mendes Luis wrote... >> #define quoting(Kenneth D. Merry) >>> - the problem is that with the old SCSI code, to send SCSI commands >>> directly to a device, you opened the device itself (/dev/rcd0a or >>> whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does >>> things differently, primarily because users may want to send >>> commands to device, even though the device's open() routine may >>> fail. For instance, you can't open a CD device if there is no >>> media inserted. But the user may want to send an INQUIRY command >>> to the drive, whether or not there's a CD in the drive. So, to >>> solve this, you have two choices: (that I can think of offhand) >>> - have a special control minor number for each device, and >>> have the open call ignore failures in read capacity, test >>> unit ready, etc. >>> - have a separate passthrough driver that doesn't have to >>> have any commands succeed to attach or open. >> >> Isn't this what /dev/xxx.ctl does ? > > My guess is that that is what it was supposed to do in theory, but > in practice, I don't think it does. I looked at the open routines in the > current cd, sd and st drivers, and none of them check to see if it was the > control device that was opened. So if no media is in the drive, the open > will fail. This matches my experience. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 03:24:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA12109 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 03:24:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12021 for ; Tue, 23 Jun 1998 03:24:27 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA03226; Tue, 23 Jun 1998 05:57:52 -0400 (EDT) From: Peter Dufault Message-Id: <199806230957.FAA03226@hda.hda.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <19980623154334.A392@freebie.lemis.com> from Greg Lehey at "Jun 23, 98 03:43:34 pm" To: grog@lemis.com (Greg Lehey) Date: Tue, 23 Jun 1998 05:57:51 -0400 (EDT) Cc: ken@plutotech.com, jonny@jonny.eng.br, mjacob@feral.com, julian@whistle.com, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > > My guess is that that is what it was supposed to do in theory, but > > in practice, I don't think it does. I looked at the open routines in the > > current cd, sd and st drivers, and none of them check to see if it was the > > control device that was opened. So if no media is in the drive, the open > > will fail. > > This matches my experience. Check again and log it as a bug. The ctl device is intercepted at the top in scsi_open at a single point and should be completely reliable. Much of the work I did involved pulling duplicated code into a common point. Unfortunately it tends to sneak back in - a good reason for an occasional rewrite (with a commitment to backward support of user interfaces). Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 03:33:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA14014 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 03:33:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA14004 for ; Tue, 23 Jun 1998 03:33:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id KAA22628; Tue, 23 Jun 1998 10:32:09 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA16988; Tue, 23 Jun 1998 12:32:02 +0200 (MET DST) Message-ID: <19980623123201.24882@follo.net> Date: Tue, 23 Jun 1998 12:32:01 +0200 From: Eivind Eklund To: shimon@simon-shapiro.org, Chris Parry Cc: freebsd-SCSI@FreeBSD.ORG, alex@nac.net, Tom Subject: Re: DPT support binaries - How to Setup References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Simon Shapiro on Mon, Jun 22, 1998 at 07:31:29PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 22, 1998 at 07:31:29PM -0400, Simon Shapiro wrote: > > Is there another way you all would recommend? Perhaps just doing > > everything from floppy and then RAID-1 the scsi drives (and just forget > > IDE), then install DOS and Freebsd? > > Yup. If you use a mirroring/RAID controller (they ARE available for IDE), > then the O/S, and even the BIOS are not aware of the mirror, and the > copying is done automatically. Here are the two I've found - if someone else has a source, please come with it :-) Tekram (PCI, $102 to $116, depending on outlet): http://www.shopper.com/prdct/657/24.html Note: A whole series of adapters are described at http://www.tekram.com/hot_products.asp?Product=DC-600_Series These controllers also do caching, and require a minimum of 4MB cache. They are available in ISA, EISA, and PCI versions. There is somewhat conflicting descriptions on the web site as to how transparent they are (both references to the "Windows NT driver" and "totally transparent to the operating system") Data Technology (IDE, $78 to $91 depending on outlet): http://www.shopper.com/prdct/049/28.html Note: Data Technology no longer advertise this product on their webpages, which may mean it is being discontinued. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 12:58:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA24101 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 12:58:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA23916 for ; Tue, 23 Jun 1998 12:56:56 -0700 (PDT) (envelope-from laotzu@juniper.net) Received: from leaf.juniper.net (leaf.juniper.net [208.197.169.211]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id MAA15683; Tue, 23 Jun 1998 12:55:25 -0700 (PDT) Received: from localhost (laotzu@localhost) by leaf.juniper.net (8.8.8/8.7.3) with SMTP id MAA21640; Tue, 23 Jun 1998 12:55:25 -0700 (PDT) Date: Tue, 23 Jun 1998 12:55:25 -0700 (PDT) From: Chris Parry To: Simon Shapiro cc: freebsd-SCSI@FreeBSD.ORG, alex@nac.net, Tom Subject: RE: DPT support binaries - How to Setup 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 Thanks for the suggestion, have it up as a single RAID-1 device with dos and FreeBSD on it, worked like a charm. > > Also, when a drive fails (or I unplug it), will it only log to > > /var/log/messages? Anyone have an automated response mechanism installed > > to notify of disk failure? > > I do, but it is not released yet. So there is *nothing* software wise that happens when the dpt detects a failed drive? I saw nothing in /var/log nor anything from syslog *.debug. Has anyone tried to run the sco 'broadcaster' that comes with it with ibcs2 emulation? Thanks, -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 13:04:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24868 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 13:04:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from priscilla.mu.org (paul@priscilla.mu.org [206.156.231.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24801 for ; Tue, 23 Jun 1998 13:03:50 -0700 (PDT) (envelope-from paul@priscilla.mu.org) Received: (from paul@localhost) by priscilla.mu.org (8.8.8/8.8.8) id PAA04024; Tue, 23 Jun 1998 15:03:06 -0500 (CDT) (envelope-from paul) Message-ID: <19980623150306.A4019@mu.org> Date: Tue, 23 Jun 1998 15:03:06 -0500 From: Paul Saab To: freebsd-scsi@FreeBSD.ORG Subject: Adaptec Supports Linux.. :P Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org http://www.redhat.com/news/news-details.phtml?id=97 Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 14:08:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA06988 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 14:08:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA06913 for ; Tue, 23 Jun 1998 14:08:03 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id PAA05522; Tue, 23 Jun 1998 15:05:42 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806232105.PAA05522@panzer.plutotech.com> Subject: Re: Confusion about message from CAM In-Reply-To: <199806230115.AA26218@yakko.zso.dec.com> from "Reginald S. Perry" at "Jun 22, 98 06:15:35 pm" To: perry@zso.dec.com Date: Tue, 23 Jun 1998 15:05:42 -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 Reginald S. Perry wrote... > Hi there, > I have installed 3.0-980520-SNAP and cam-980520. except for the > inline .vs __inline issue in bt.c, everything went fine. My problem > comes from what CAM is telling me about my disks. I have 2 IBM > DCAS-34330W 4.33GB Ultra Wide SCSI drives. > > I have some questions. Why does da0 report 3.300MB/s transfers and da1 > report 10.0MB/s transfers? Why is this not 20.0MB/s since they are > ultra wide drives? Is this a problem? If so, how can I correct this? It's a bug in the BusLogic driver, Justin says it'll be fixed before the next snapshot goes out. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 14:38:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13387 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 14:38:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from iworks.interworks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13314 for ; Tue, 23 Jun 1998 14:38:23 -0700 (PDT) (envelope-from deischen@iworks.interworks.org) Received: (from deischen@localhost) by iworks.interworks.org (8.8.7/8.8.7) id QAA01120; Tue, 23 Jun 1998 16:38:31 -0500 (CDT) Date: Tue, 23 Jun 1998 16:38:31 -0500 (CDT) From: "Daniel M. Eischen" Message-Id: <199806232138.QAA01120@iworks.interworks.org> To: freebsd-scsi@FreeBSD.ORG, paul@mu.org Subject: Re: Adaptec Supports Linux... 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 > http://www.redhat.com/news/news-details.phtml?id=97 They're supporting FreeBSD also, though you can't tell from that link. Dan Eischen deischen@iworks.InterWorks.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 16:17:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01053 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 16:17:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00975 for ; Tue, 23 Jun 1998 16:17:11 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id XAA17268; Tue, 23 Jun 1998 23:17:04 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA19622; Wed, 24 Jun 1998 01:17:03 +0200 (MET DST) Message-ID: <19980624011703.06277@follo.net> Date: Wed, 24 Jun 1998 01:17:03 +0200 From: Eivind Eklund To: Paul Saab , freebsd-scsi@FreeBSD.ORG Subject: Re: Adaptec Supports Linux.. :P References: <19980623150306.A4019@mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980623150306.A4019@mu.org>; from Paul Saab on Tue, Jun 23, 1998 at 03:03:06PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 23, 1998 at 03:03:06PM -0500, Paul Saab wrote: > http://www.redhat.com/news/news-details.phtml?id=97 This is just hype. I got most of the information they're boasting about by just asking back in 1994. The only new part is 'will /investigate/ open-source distribution of hardware abstraction layers' which is not a true commitment. (Emphasis is mine). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 17:17:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11918 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 17:17:48 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11877 for ; Tue, 23 Jun 1998 17:17:36 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id SAA06568; Tue, 23 Jun 1998 18:17:24 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806240017.SAA06568@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806221039.GAA00170@hda.hda.com> from Peter Dufault at "Jun 22, 98 06:39:32 am" To: dufault@hda.com (Peter Dufault) Date: Tue, 23 Jun 1998 18:17:24 -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 Peter Dufault wrote... > > (I may try putting in support for just specifying devices like that instead > > of -n da -u 0 if I end up re-working the command line options.) A > > complicating factor to all this is all the arguments for the command line > > CDB parsing code. > > Can you provide a look up table for device nicknames between > scsi(8) and camcontrol? The newer one at least knows how to go > from sd0 to /dev/rsd0.ctl. Well, the CAM library can already do that. Basically, cam_open_device() will try to map almost any string you give it to the correct device name and unit number. For instance, if you give it: /dev/rsd0.ctl It will translate that into "da" and 0. Then it asks the kernel for the passthrough device that corresponds to that physical device. There really isn't any way to have a static lookup table, unless the user hardwires passthrough devices in their kernel. Passthrough device unit numbers are assigned (in the non-hardwired case) in the order that devices are found. > > > Just to show I'm not a stickler about high level interfaces, I > > > think that in addition to preserving the current ioctl interface > > > (which I think should be done) it would be good to support > > > the Linux SCSI interface thus extending the Linux binary support. > > > > That is an option, although I'd have to look at it and see what it > > would entail. Linux binary support is good, since it allows us to run > > commercial applications that haven't been ported to FreeBSD. The question > > is, what sort of application base are we talking about here? Are there > > lots of binary-only Linux applications (or even just one major application) > > that need SCSI passthrough support? > > There are many that already have FreeBSD native interfaces. It is > a question of deciding whether to commit to that part of the Linux > ABI. Right. One thing I'd like to know, though, is are there any Linux programs that are binary-only and do SCSI pass-through? If not, I don't see the point of hacking it in. > It is far more important to support the clean cutover for the > FreeBSD installed base, and time is better spent ensuring that than > any Linux adventure. I think a clean cutover for the FreeBSD installed base can probably be achieved (even without providing the old interface in the kernel) if we: 1. Document the new interface thoroughly. 2. Make sure that all known ports that use SCSI passthrough commands are ported, so that when 3.0 goes out, users can either make the port or install the package and be up and running. Any remaining problems that show up will be a result of one of the following: 1. The user is using a program like xmcd, tosha, etc., and hasn't recompiled it. 2. The user is using some program that does SCSI passthrough that we don't know about. I'm more concerned about #2 than #1. > > I'm still not convinced it's absolutely necessary to support > > even the current ioctl interface, since I haven't really heard of many > > programs that would be affected. The current list is: cd-write, SANE, and > > cdd. (cdrecord, tosha and xmcd have been ported) That certainly isn't an > > insurmountable list, and once those are ported, it'll be a simple matter of > > rebuilding the port once we switch over to CAM. > > You've provided the important one from my point of view which is the > command interface. The point is that in the last few months I've > had three groups contacting me about embedded SCSI in FreeBSD. > Some are going on their own and I've pointed all of them at you folk. > > However, the current CAM versus "classic" and the issue of volatility > for the next two years is a murky one. My opinion is that policy > should be "we shall make it painless until it is a non-issue" and > never "you shall be assimilated" (which snuck out earlier - Hi > Mike). Public statements should be weighed against ensuring > this aspect is a non-issue. Well, how about this: - we provide the SCIOCCOMMAND/scsireq/libscsi interface as a compatibility interface for some period of time, with the (documented in the man pages) understanding that it will eventually go away. - we put a "nag" printf in the kernel that prints out once per boot (whenever someone uses the SCIOCCOMMAND ioctl) to tell the user that they're using a deprecated interface. That should take care of problem users #1 and #2 above, since it would provide binary compatibility. It will also nag them so that they know they're using an outdated interface and they can take steps to port their software to the new interface. I certainly don't want to leave people high and dry when we switch over to CAM. Thus the reason we're waiting on putting it in the tree until more hardware is supported. I'm not averse to providing a compatibility interface, but I'd like to avoid keeping the code in there indefinitely. Comments? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 17:19:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12393 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 17:19:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12376 for ; Tue, 23 Jun 1998 17:19:22 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id SAA06581; Tue, 23 Jun 1998 18:19:16 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806240019.SAA06581@panzer.plutotech.com> Subject: Re: CAM & SANE... In-Reply-To: from Cory Kempf at "Jun 22, 98 12:05:13 pm" To: ckempf@enigami.com (Cory Kempf) Date: Tue, 23 Jun 1998 18:19:16 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cory Kempf wrote... > "Kenneth D. Merry" writes: > > > > What is still needed before the CAM stuff can become part of the main > > > body of code? At least w.r.t. -current? > > > > We don't yet have: > > - SANE > > I have been planning on purchasing a scanner... I can take a pot shot > at this one. Let me know if you need any help. If they've got a DEC UNIX CAM interface in there, the FreeBSD CAM interface should be similar. The first place to look for example code is camcontrol, then the xmcd port on the ftp sites. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 18:23:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA21081 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 18:23:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA21051 for ; Tue, 23 Jun 1998 18:22:39 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 13490 invoked by uid 1000); 23 Jun 1998 22:36:36 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 23 Jun 1998 18:36:36 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Chris Parry Subject: RE: DPT support binaries - How to Setup Cc: Tom , alex@nac.net, freebsd-SCSI@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23-Jun-98 Chris Parry wrote: > Thanks for the suggestion, have it up as a single RAID-1 device with dos > and FreeBSD on it, worked like a charm. > > >> > Also, when a drive fails (or I unplug it), will it only log to >> > /var/log/messages? Anyone have an automated response mechanism >> > installed >> > to notify of disk failure? >> >> I do, but it is not released yet. > > So there is *nothing* software wise that happens when the dpt detects a > failed drive? I saw nothing in /var/log nor anything from syslog > *.debug. > Has anyone tried to run the sco 'broadcaster' that comes with it with > ibcs2 emulation? There is nothing that the software sees when a failure happens. Unless the array is DEAD. As long as the array is capable of delivering and accepting the data, it will look like a perfect disk to the O/S. This is the whole point behind such devices. The SCSO executables will probably not work correctly as I have not finished the IOCTL emulation yet. In any case, the 2.2 DPT driver is missing much of this emulation. The 3.0 driver has it, but not fully debugged. It is much difficult work to thoroughly debug this, and I have yet to get the sources from DPT, so I can reasonably debug this emulation. This emulation issue has nothing to do with emulating SCSO Unix so that SCO binaries run correctly. This emulation may or may not work well enouth. What I amtalking about here is emulating the DPT driver for SCO so that ioctl system calls top the driver are interpreted correctly. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 23 21:12:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19797 for freebsd-scsi-outgoing; Tue, 23 Jun 1998 21:12:08 -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 VAA19696 for ; Tue, 23 Jun 1998 21:11:10 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id WAA00518; Tue, 23 Jun 1998 22:06:09 -0600 (MDT) Date: Tue, 23 Jun 1998 22:06:09 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199806240406.WAA00518@narnia.plutotech.com> To: Eivind Eklund cc: scsi@FreeBSD.ORG Subject: Re: Adaptec Supports Linux.. :P Newsgroups: pluto.freebsd.scsi In-Reply-To: <19980623150306.A4019@mu.org> <19980624011703.06277@follo.net> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19980624011703.06277@follo.net> you wrote: > On Tue, Jun 23, 1998 at 03:03:06PM -0500, Paul Saab wrote: >> http://www.redhat.com/news/news-details.phtml?id=97 > > This is just hype. I got most of the information they're boasting > about by just asking back in 1994. > > The only new part is 'will /investigate/ open-source distribution of > hardware abstraction layers' which is not a true commitment. > (Emphasis is mine). Actually, Doug Ledford has the CHIM code right now. He stupidly signed an NDA to get it, but his understanding of the situation is that Adaptec will release the CHIM under a less restrictive license soon. Adaptec technical marketing has made similar promises to me, but I've made it quite clear that going from a full source situation to a setup without firmware source would be a step backwards for many current users of this code (e.g. no target mode). > Eivind. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 24 07:02:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA09540 for freebsd-scsi-outgoing; Wed, 24 Jun 1998 07:02:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.hcol.net (val@ns.hcol.net [205.152.99.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA09535; Wed, 24 Jun 1998 07:02:36 -0700 (PDT) (envelope-from val@ns.hcol.net) Received: from localhost (val@localhost) by ns.hcol.net (8.8.6/8.8.6) with SMTP id JAA19926; Wed, 24 Jun 1998 09:02:31 -0500 (CDT) Date: Wed, 24 Jun 1998 09:02:31 -0500 (CDT) From: Val To: freebsd-questions@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG Subject: Adaptec AAA-131 raid controller In-Reply-To: <199806220055.UAA17637@lucy.bedford.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 I have an AAA-131 controller and it seems to work just like usual scsi card with raid functions disabled. I can configure all drives in an array, but freebsd still sees them separate and handles them just fine that way. This is all just as it is described in docs. Now, if someone has a driver that needs to be tested for raid functions of this card I would be glad to test it, since the controller just sits on the shelf. Val. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 24 17:58:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10639 for freebsd-scsi-outgoing; Wed, 24 Jun 1998 17:58:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail-atm.tampabay.rr.com (ns.tampabay.rr.com [24.92.0.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10491 for ; Wed, 24 Jun 1998 17:57:06 -0700 (PDT) (envelope-from kmcrae1@tampabay.rr.com) Received: from Administrator (dt101n45.tampabay.rr.com [24.92.181.69]) by mail-atm.tampabay.rr.com (8.8.7/8.8.8) with SMTP id UAA23937 for ; Wed, 24 Jun 1998 20:52:54 -0400 (EDT) Message-ID: <000a01bd9fd3$d49b3820$45b55c18@tampabay.rr.com> From: "Scott McRae" To: "Freebsd SCSI" Date: Wed, 24 Jun 1998 20:54:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe freebsd-scsi kmcrae1@tampabay.rr.com subscribe freebsd-questions kmcrae1@tampabay.rr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 24 18:09:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12437 for freebsd-scsi-outgoing; Wed, 24 Jun 1998 18:09:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail-atm.tampabay.rr.com (ns.tampabay.rr.com [24.92.0.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12270 for ; Wed, 24 Jun 1998 18:07:46 -0700 (PDT) (envelope-from kmcrae1@tampabay.rr.com) Received: from Administrator (dt101n45.tampabay.rr.com [24.92.181.69]) by mail-atm.tampabay.rr.com (8.8.7/8.8.8) with SMTP id VAA26740 for ; Wed, 24 Jun 1998 21:03:42 -0400 (EDT) Message-ID: <002c01bd9fd5$5713ae80$45b55c18@tampabay.rr.com> From: "Scott McRae" To: "Freebsd SCSI" Subject: Dual Adaptec SCSI controlers Date: Wed, 24 Jun 1998 21:05:24 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01BD9FB3.CE786140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0029_01BD9FB3.CE786140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to install FreeBSD off of the FTP site. I have a DELL = Workstation 410 machine with 2 onboard Adaptec scsi controllers One = AHA-7890 and a AHA-7880. the 90 has my hard drive, and the 80 has my two = CD-ROM drives. They are both on the same IRQ and memory address. When I = configure the Adaptec controller from the setup disk, it only detects = the 80 controller which has the CD-ROMs, and it won't install because it = doesn't see my hard drive. Is there any way I can install a second = Adaptec scsi controller during setup? ------=_NextPart_000_0029_01BD9FB3.CE786140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to install FreeBSD off = of the FTP=20 site. I have a DELL Workstation 410 machine with 2 onboard Adaptec scsi=20 controllers One AHA-7890 and a AHA-7880. the 90 has my hard drive, and = the 80=20 has my two CD-ROM drives. They are both on the same IRQ and memory = address. When=20 I configure the Adaptec controller from the setup disk, it only detects = the 80=20 controller which has the CD-ROMs, and it won't install because it = doesn't see my=20 hard drive. Is there any way I can install a second Adaptec scsi = controller=20 during setup?
------=_NextPart_000_0029_01BD9FB3.CE786140-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 24 22:03:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA18738 for freebsd-scsi-outgoing; Wed, 24 Jun 1998 22:03:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA18728; Wed, 24 Jun 1998 22:03:33 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.5/8.8.8) with SMTP id WAA10668; Wed, 24 Jun 1998 22:03:30 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Wed, 24 Jun 1998 22:03:29 -0700 (PDT) From: Doug White To: Val cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Adaptec AAA-131 raid controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Jun 1998, Val wrote: > I have an AAA-131 controller and it seems to work just like usual scsi > card with raid functions disabled. I can configure all drives in an > array, but freebsd still sees them separate and handles them just fine > that way. This is all just as it is described in docs. > Now, if someone has a driver that needs to be tested for raid functions of > this card I would be glad to test it, since the controller just sits on > the shelf. There is no driver that supports the Adapted RAID controlers at this time that I'm aware of. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 25 00:54:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA15304 for freebsd-scsi-outgoing; Thu, 25 Jun 1998 00:54:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA15292 for ; Thu, 25 Jun 1998 00:54:26 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 6694 invoked by uid 1000); 24 Jun 1998 15:55:07 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 24 Jun 1998 11:55:07 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: FreeBSD-SCSI@FreeBSD.ORG Subject: FW: RE: DPT raid rebuild Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This may be of interwst to others. Good to put in the FAQ too. Simon -----FW: RE: DPT raid rebuild----- Date: Wed, 24 Jun 1998 11:15:57 -0400 (EDT) From: Simon Shapiro To: Ray Bellis Subject: RE: DPT raid rebuild Ray, would you kindly agree to forward your message and my reply to freebsd-scsi? It is of general interest. On 24-Jun-98 Ray Bellis wrote: > Hi Simon, we're half way through building a set of 6 servers using DPT > SmartRAID IV controllers, and a few things have come up that we hope you > might be able to advise on. Each of our systems has four disks, > configured > as a three disk RAID5 and a hot spare. > > We're not using DPT (or DEC) caddies and therefore get no notification > when > a disk is replaced. The system does manage to swap onto the hot spare OK > when a disk is pulled but it doesn't manage to create a new hot spare > when a > replacement disk is inserted. Yup. It has no way of knowing that the disk was inserted. Actually, it does not know the disk was removed. It simply tries to access it and fails, thus marking it DEAD and going after the hot spare. > The system is also incapable of rebuilding a 3 disk RAID5 (without hot > swap) > when a new disk is inserted. Shouldn't it should be possible to send an > EATA command to tell the DPT to start rebuilding in these circumstances? Yes, but my understanding of the situation is that these are proprietary commands and only available throu dptmgr, which is only distributed in binary form. > Do you have any information about how soon the DPTMGR application will be > available for FreeBSD? I have started working on that, but got pulled away by the need to port the DPT driver to CAM. This has taken massive amounts of my time. I will look into adding the array rebuild option into the current driver. Simon ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 --------------End of forwarded message------------------------- ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 25 01:01:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA16044 for freebsd-scsi-outgoing; Thu, 25 Jun 1998 01:01:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from casimir.easynet.fr (casimir.easynet.fr [195.114.64.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15956 for ; Thu, 25 Jun 1998 01:00:17 -0700 (PDT) (envelope-from rama@casimir.easynet.fr) Received: (from rama@localhost) by casimir.easynet.fr (8.8.8/8.8.8) id JAA09432; Thu, 25 Jun 1998 09:59:57 +0200 (CEST) (envelope-from rama) Message-ID: <19980625095957.C9341@easynet.fr> Date: Thu, 25 Jun 1998 09:59:57 +0200 From: David Ramahefason To: "Scott McRae" , "Freebsd SCSI" Subject: Re: Dual Adaptec SCSI controlers Reply-To: David Ramahefason References: <002c01bd9fd5$5713ae80$45b55c18@tampabay.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.8 In-Reply-To: <002c01bd9fd5$5713ae80$45b55c18@tampabay.rr.com>; from Scott McRae on Wed, Jun 24, 1998 at 09:05:24PM -0400 Organization: Systems Team Easynet France SA X-Operating-System: FreeBSD Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jun 24, 1998 at 09:05:24PM -0400, Scott McRae wrote: > I am trying to install FreeBSD off of the FTP site. I have a DELL Workstation 410 machine with 2 onboard Adaptec scsi controllers One AHA-7890 and a AHA-7880. the 90 has my hard drive, and the 80 has my two CD-ROM drives. They are both on the same IRQ and memory address. When I configure the Adaptec controller from the setup disk, it only detects the 80 controller which has the CD-ROMs, and it won't install because it doesn't see my hard drive. Is there any way I can install a second Adaptec scsi controller during setup? ---end quoted text--- I think that you need CAM to have your 7890 working... -- /David Ramahefason Administrateur Systeme/Reseau/ /rama@easynet.fr Easynet France SA / /0144547031 ICQ: 14292822 / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 25 22:41:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11910 for freebsd-scsi-outgoing; Thu, 25 Jun 1998 22:41:23 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11892 for ; Thu, 25 Jun 1998 22:41:16 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id XAA19348; Thu, 25 Jun 1998 23:41:06 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806260541.XAA19348@panzer.plutotech.com> Subject: Re: Dual Adaptec SCSI controlers In-Reply-To: <002c01bd9fd5$5713ae80$45b55c18@tampabay.rr.com> from Scott McRae at "Jun 24, 98 09:05:24 pm" To: kmcrae1@tampabay.rr.com (Scott McRae) Date: Thu, 25 Jun 1998 23:41:06 -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 Scott McRae wrote... > I am trying to install FreeBSD off of the FTP site. I have a DELL Workstation 410 machine with 2 onboard Adaptec scsi controllers One AHA-7890 and a AHA-7880. the 90 has my hard drive, and the 80 has my two CD-ROM drives. They are both on the same IRQ and memory address. When I configure the Adaptec controller from the setup disk, it only detects the 80 controller which has the CD-ROMs, and it won't install because it doesn't see my hard drive. Is there any way I can install a second Adaptec scsi controller during setup? The 7890 is only supported under CAM. See: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/cam/README So, what you need to do is put your hard disk on the 7880 along with your CDROM drives. Install FreeBSD from the CD's. Then upgrade to either 2.2-stable or -current and install the CAM patches as described in the README file above. Once you're running CAM, you can swap your hard disk back to the 7890 controller. 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 Jun 26 00:30:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA24674 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 00:30:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from net.kitel.co.kr ([210.102.35.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA24637 for ; Fri, 26 Jun 1998 00:30:33 -0700 (PDT) (envelope-from swjeong@net.kitel.co.kr) Received: (from swjeong@localhost) by net.kitel.co.kr (8.8.8H1/8.8.8) id QAA16123 for freebsd-scsi@FreeBSD.ORG; Fri, 26 Jun 1998 16:01:59 +0900 (KST) Date: Fri, 26 Jun 1998 16:01:59 +0900 (KST) From: swjeong Message-Id: <199806260701.QAA16123@net.kitel.co.kr> To: freebsd-scsi@FreeBSD.ORG Subject: [Q] Which OS ver. + SCSI adpater is most stable with CAM ? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Q1. What OS environment is most stable for CAM ? I am planning to use CAM. 'FreeBSD-stable + CAM' or 'current-980624-SNAP + CAM-980520' or 'current-980523-SNAP + CAM-980520' or the other ? Q2. What SCSI-adapter is most stable with double ended environment and CAM ? I am planning to use double-ending as follows ? SCSC-adapter HDD HDD HDD .... HDD SCSI-adapter | | | | | | +------+----------------+------+------+---------+----------+--------+ | | Term. Term. SymBios 8951SP (based on 53C875) or ... Adaptec 2940UW or 3940UW ? --------------------------------------- Jeong Sung Won swjeong@kitel.co.kr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 06:22:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA05257 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 06:22:07 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tata.research.rockwell.cz (tata.research.rockwell.cz [193.85.154.66]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA05219 for ; Fri, 26 Jun 1998 06:21:51 -0700 (PDT) (envelope-from mira@rockwell.cz) Received: from rockwell.cz (aja.research.rockwell.cz [193.85.154.75]) by tata.research.rockwell.cz (8.6.9/8.6.5) with ESMTP id PAA00295 for ; Fri, 26 Jun 1998 15:31:15 +0200 Message-ID: <3593A308.1BB560DF@rockwell.cz> Date: Fri, 26 Jun 1998 15:32:56 +0200 From: Miroslav Kes X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: 2.2.6 stable CAM installation help?! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to install -stable with CAM on my box with Adaptec 2940U2W. I spent the whole week trying to apply following strategy: Insert another IDE disk to the box. Install 2.2.6 release, upgrade it to -stable (thanks Justin again for the hint) apply CAM patches and get -stable with CAM working on the IDE disk so I could see also the 2940U2W controller and SCSI disks. So far I suceeded. Then I wanted to use /stand/sysinstall to install 2.2.6 release on one SCSI disk, copy the kernel from IDE to the SCSI disk, boot from the scsi so I could upgrade to -stable and apply CAM. Unfortunately even if I selected da0 and da1 as disks where the installation should be performed the /stand/sysinstall started copying files to the wd0 and overwrote the -stable patch (I was quite unhappy :-[ ) so I had to do the perform show on the IDE again. Then I tried another way. I used the boot.flp from the www.freebsd.org/~abial and here I suceeded to install the 2.2.6 release. Now I felt to be close. I have compiled new kernel on the IDE setting kernel root on da0 then I mounted /da0s1a and copied the kernel (using also chflags). Now the problem is that if I boot the kernel on the da0 it still tries to look for / on wd0 and if it fail it hangs. Some steps I described above I did in several iterations learning from my mistakes but now I have no idea what to try next. Any help is greatly welcome. Mira -- ----------------------------------------------------------- | Miroslav Kes | |---------------------------------------------------------| | Rockwell Automation Ltd. | tel.: (+420) 2 2425 6913 | | Research Center Prague | fax: (+420) 2 250467 | | Americka 22 | e-mail: mira@rockwell.cz | | 120 00 Praha 2 - Vinohrady | | | Czech Republic | | ----------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 07:12:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA12019 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 07:12:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA11969 for ; Fri, 26 Jun 1998 07:12:00 -0700 (PDT) (envelope-from owensc@enc.edu) Received: from itsdsv2.enc.edu (itsdsv2.enc.edu [10.1.1.9]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id KAA04784 for ; Fri, 26 Jun 1998 10:09:51 -0400 (EDT) Date: Fri, 26 Jun 1998 10:09:50 -0400 (EDT) From: Charles Owens To: freebsd-scsi@FreeBSD.ORG Subject: any resolution to Adaptec Rev E issue? 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 Hi, About a month ago there was discussion on this list of a problem seen consitently with Adaptec 2940 boards labeled "Rev E". As of the last posting, Justin Gibbs was apparantly going to try to reproduce the problem. Is there any news on this issue? Justin, were you able to reproduce the problem? Any ideas about a fix? I'm about to (today, I hope) place an order for 8 new PII servers, all with 2940 or 3940 controllers. My supplier has indicated that the boards he has are indeed Rev E. I'm a bit nervous about this. Another supplier that I spoke with indicated that in general Adaptec has been becoming increasingly less open with technical details on their boards, which has resulted in drivers in the various open-source OS's (FreeBSD, Linux, etc.) lagging behind product changes and being of generally poorer quality. As such, the supplier (one of the bigger Linux-oriented suppliers) on longer builds systems with Adaptec controllers! What's the feeling on this here? _Should_ I avoid the Adaptec boards? If so, what's the preferred alternative? An NCR-chipset board from, say, Symbois? Buslogic? Thanks for any and all input! Please be sure to cc: any replies to me directly, as I'm not subscribed to this list. Thanks, --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is a man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 09:11:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03026 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 09:11:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cx25450-a.dt1.sdca.home.com (cx25450-a.dt1.sdca.home.com [24.0.129.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA02953 for ; Fri, 26 Jun 1998 09:11:21 -0700 (PDT) (envelope-from schwarz@cx25450-a.dt1.sdca.home.com) Received: (from schwarz@localhost) by cx25450-a.dt1.sdca.home.com (8.8.7/8.8.7) id JAA21129; Fri, 26 Jun 1998 09:11:18 -0700 (PDT) (envelope-from schwarz) Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.1.p0.FreeBSD:980626091117:375=_" Date: Fri, 26 Jun 1998 08:43:13 -0700 (PDT) Organization: ISI Design Center From: Steven Schwarz To: freebsd-scsi@FreeBSD.ORG, "Steven T. Schwarz" Subject: 980513 CAM, /dev/(r)fd0, vnode pseudo-device Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format --_=XFMail.1.1.p0.FreeBSD:980626091117:375=_ Content-Type: text/plain; charset=us-ascii I haven't reported in on my CAM experiences for awhile, but I just integrated the 980513 snapshot onto my machine and wanted to report on that. The machine involved is a dual-pentium II (with two 233's) running the SMP kernel from the 3.0-980520-SNAP, with the CAM patches applied, and one other small set of patches which I have attached. The mother- board is a Tyan S1696DLUA Thunder 2 ATX, which has onboard 2-channel Adaptec AIC-7895 UW. There are three scsi devices, two on the 7895 (an IBM hard drive and an Iomega internal Jaz drive) and the third an Iomega parallel port zip drive. Getting the ppbus stuff to work with CAM, and hence support for my zip drive, is what led to the "other small set of patches". Someone (I don't remember the name at this moment) posted a very helpful ppbus patch, which was dated before the 980513 snapshot of CAM and out of date by the time of that shapshot. Mine "works" for the zip drive, but I did no more than "get it to work" -- it maybe could use a walk-through to clean it up. So I've attached my patches. [The patch applies to /usr/src/sys/dev/ppbus/vpo.[ch] and should be applied localy in /usr/src/sys/dev/ppbus. It would be real nice if the future CAM snapshots could preserve the ppbus stuff in working order, especially, as it would seem to require very little incremental effort to do so.] Two things of note to report: [1] This message devstat_end_transaction: HELP!! busy_count is < 0! is spammed to syslog whenever any attempt is made to use the floppy device /dev/(r)fd0 (mounting, reading, writing). (Operations do seem to succeed, you just get the space-filling message.) Is this related to CAM? [2] In the process of using this machine to make a picoBSD kernel (for, needless to say, another box to run :->), I noticed that if I place the sources and do this build on my IBM hard drive, the scsi bus resets during the build at the point where the build wants to use the vnode pseudo-device ("treat any file like a disk") during the manufacture of the bootable floppy. If I move the sources to my IDE drive, the whole thing works just fine. Again, does vnode need work to play with CAM? Everything else that I have tried is pretty much working fine. Thanks for all the great work on CAM. sts --_=XFMail.1.1.p0.FreeBSD:980626091117:375=_ Content-Type: text/plain; charset=us-ascii; name=mydiffs; SizeOnDisk=21879 Content-Description: mydiffs Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mydiffs" *** vpo.c.orig Wed Jun 24 08:02:08 1998 --- vpo.c Wed Jun 24 09:00:46 1998 *************** *** 36,50 **** #include #endif /* KERNEL */ ! #include ! #include #ifdef KERNEL #include #endif /*KERNEL */ #include - #include /* -------------------------------------------------------------------- * HERE ARE THINGS YOU MAY HAVE/WANT TO CHANGE --- 36,57 ---- #include #endif /* KERNEL */ ! ! #include ! #include ! #include ! #include ! #include ! ! #include ! #include ! #include #ifdef KERNEL #include #endif /*KERNEL */ #include /* -------------------------------------------------------------------- * HERE ARE THINGS YOU MAY HAVE/WANT TO CHANGE *************** *** 63,108 **** * -------------------------------------------------------------------- */ ! static inline int vpoio_do_scsi(struct vpo_data *, int, int, char *, int, ! char *, int, int *, int *); ! static int32_t vpo_scsi_cmd(struct scsi_xfer *); ! static void vpominphys(struct buf *); ! static u_int32_t vpo_adapter_info(int); static int vpo_detect(struct vpo_data *vpo); static int nvpo = 0; #define MAXVP0 8 /* XXX not much better! */ static struct vpo_data *vpodata[MAXVP0]; #ifdef KERNEL - static struct scsi_adapter vpo_switch = - { - vpo_scsi_cmd, - vpominphys, - 0, - 0, - vpo_adapter_info, - "vpo", - { 0, 0 } - }; - - /* - * The below structure is so we have a default dev struct - * for out link struct. - */ - static struct scsi_device vpo_dev = - { - NULL, /* Use default error handler */ - NULL, /* have a queue, served by this */ - NULL, /* have no async handler */ - NULL, /* Use default 'done' routine */ - "vpo", - 0, - { 0, 0 } - }; - /* * Make ourselves visible as a ppbus driver --- 70,169 ---- * -------------------------------------------------------------------- */ ! #define VP0_INITIATOR 0x7 ! ! #define VP0_SECTOR_SIZE 512 ! #define VP0_BUFFER_SIZE 0x12000 ! ! #define VP0_ESELECT_TIMEOUT 1 ! #define VP0_ECMD_TIMEOUT 2 ! #define VP0_ECONNECT 3 ! #define VP0_ESTATUS_TIMEOUT 4 ! #define VP0_EDATA_OVERFLOW 5 ! #define VP0_EDISCONNECT 6 ! #define VP0_EPPDATA_TIMEOUT 7 ! #define VP0_ENOPORT 9 ! #define VP0_EINITFAILED 10 ! #define VP0_EINTR 12 ! ! #define VP0_EOTHER 13 ! ! #define VP0_OPENNINGS 1 ! ! #define n(flags) (~(flags) & (flags)) ! ! /* ! * VP0 timings. ! */ ! #define MHZ_16_IO_DURATION 62 ! ! #define VP0_SPP_WRITE_PULSE 253 ! #define VP0_NIBBLE_READ_PULSE 486 ! ! /* ! * VP0 connections. ! */ ! #define H_AUTO n(AUTOFEED) ! #define H_nAUTO AUTOFEED ! #define H_STROBE n(STROBE) ! #define H_nSTROBE STROBE ! #define H_BSY n(nBUSY) ! #define H_nBSY n_BUSY ! #define H_SEL SELECT ! #define H_nSEL n(SELECT) ! #define H_ERR ERROR ! #define H_nERR n(ERROR) ! #define H_ACK nACK ! #define H_nACK n(nACK) ! #define H_FLT nFAULT ! #define H_nFLT n(nFAULT) ! #define H_SELIN n(SELECTIN) ! #define H_nSELIN SELECTIN ! #define H_INIT nINIT ! #define H_nINIT n(nINIT) ! ! struct vpo_sense { ! struct scsi_sense cmd; ! unsigned int stat; ! unsigned int count; ! }; ! ! struct vpo_data { ! unsigned short vpo_unit; ! ! int vpo_stat; ! int vpo_count; ! int vpo_error; ! ! struct cam_sim *sim; ! struct cam_path *path; ! struct vpo_sense vpo_sense; ! ! unsigned char vpo_buffer[VP0_BUFFER_SIZE]; ! ! struct ppb_device vpo_dev; ! }; ! ! /* vpo control operations */ ! static int vpoio_do_scsi(struct vpo_data *, int, int, char *, int, ! char *, int, int *, int *); ! static int vpoio_disconnect(struct vpo_data *vpo); ! static int vpoio_connect(struct vpo_data *vpo, int how); ! static int vpoio_in_disk_mode(struct vpo_data *vpo); ! static void vpoio_reset(struct vpo_data *vpo); static int vpo_detect(struct vpo_data *vpo); + /* cam related functions */ + static void vpo_action(struct cam_sim *sim, union ccb *ccb); + static void vpo_poll(struct cam_sim *sim); + static int nvpo = 0; #define MAXVP0 8 /* XXX not much better! */ static struct vpo_data *vpodata[MAXVP0]; #ifdef KERNEL /* * Make ourselves visible as a ppbus driver *************** *** 116,122 **** }; DATA_SET(ppbdriver_set, vpodriver); - #endif /* KERNEL */ static u_int32_t --- 177,182 ---- *************** *** 182,193 **** struct scsibus_data *scbus; struct vpo_data *vpo = vpodata[dev->id_unit]; ! ! vpo->sc_link.adapter_unit = vpo->vpo_unit; ! vpo->sc_link.adapter_targ = VP0_INITIATOR; ! vpo->sc_link.adapter = &vpo_switch; ! vpo->sc_link.device = &vpo_dev; ! vpo->sc_link.opennings = VP0_OPENNINGS; /* * Report ourselves --- 242,248 ---- struct scsibus_data *scbus; struct vpo_data *vpo = vpodata[dev->id_unit]; ! struct cam_devq *devq; /* * Report ourselves *************** *** 196,226 **** dev->id_unit, dev->ppb->ppb_link->adapter_unit); /* ! * Prepare the scsibus_data area for the upperlevel ! * scsi code. ! */ ! scbus = scsi_alloc_bus(); ! if(!scbus) return (0); - scbus->adapter_link = &vpo->sc_link; ! scsi_attachdevs(scbus); ! return (1); ! } ! static void ! vpominphys(struct buf *bp) ! { ! if (bp->b_bcount > VP0_BUFFER_SIZE) ! bp->b_bcount = VP0_BUFFER_SIZE; ! return; } #ifdef VP0_WARNING ! static inline void vpo_warning(struct vpo_data *vpo, struct scsi_xfer *xs, int timeout) { --- 251,314 ---- dev->id_unit, dev->ppb->ppb_link->adapter_unit); /* ! ** Now tell the generic SCSI layer ! ** about our bus. ! */ ! devq = cam_simq_alloc(16); ! ! if (devq == 0) return (0); ! vpo->sim = ! cam_sim_alloc(/* sim_action */ vpo_action, ! /* sim_poll */ vpo_poll, ! /* sim_name */ "vpo", ! /* softc */ vpo, ! /* unit */ vpo->vpo_unit, ! /* max_dev_transactions */ 1, ! /* max_tagged_dev_transactions */ 0, ! /* queue */ devq); ! if (vpo->sim == 0) ! return (0); ! vpo->sim->sim_action = vpo_action; ! vpo->sim->sim_poll = vpo_poll; ! vpo->sim->sim_name = "vpo"; ! vpo->sim->softc = vpo; ! /* ! ** Don't care what our path id is - If we were the boot ! ** device we'd set it to 0???? ! */ ! vpo->sim->path_id = (u_int32_t)-1; ! vpo->sim->unit_number = vpo->vpo_unit; ! vpo->sim->bus_id = 0; ! vpo->sim->base_transfer_speed = 93; /* Async transfer rate in kB/s */ ! /* ! vpo->sim->max_tagged_dev_transactions = 0; ! vpo->sim->max_dev_transactions = 1; ! vpo->sim->max_openings = 1; ! */ ! ! if (xpt_bus_register(vpo->sim, 0) != CAM_SUCCESS) { ! free(vpo->sim, M_DEVBUF); ! return (0); ! } ! ! if (xpt_create_path(&vpo->path, /*periph*/NULL, ! vpo->sim->path_id, CAM_TARGET_WILDCARD, ! CAM_LUN_WILDCARD) != CAM_REQ_CMP) { ! xpt_bus_deregister(vpo->sim->path_id); ! free(vpo->sim, M_DEVBUF); ! return (0); ! } ! return (1); } #ifdef VP0_WARNING ! static void vpo_warning(struct vpo_data *vpo, struct scsi_xfer *xs, int timeout) { *************** *** 267,290 **** #endif /* VP0_WARNING */ /* ! * vpointr() */ ! static inline void ! vpointr(struct vpo_data *vpo, struct scsi_xfer *xs) { ! int errno; /* error in errno.h */ ! if (xs->datalen && !(xs->flags & SCSI_DATA_IN)) ! bcopy(xs->data, vpo->vpo_buffer, xs->datalen); ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, ! xs->sc_link->target, (char *)xs->cmd, xs->cmdlen, ! vpo->vpo_buffer, xs->datalen, &vpo->vpo_stat, &vpo->vpo_count); #ifdef VP0_DEBUG printf("vpo_do_scsi = %d, status = 0x%x, count = %d, vpo_error = %d\n", errno, vpo->vpo_stat, vpo->vpo_count, vpo->vpo_error); #endif if (errno) { --- 355,385 ---- #endif /* VP0_WARNING */ /* ! * vpo_intr() */ ! static void ! vpo_intr(struct vpo_data *vpo, struct ccb_scsiio *csio) { ! int i, errno; /* error in errno.h */ ! int s; ! s = splcam(); ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, csio->ccb_h.target_id, ! (char *)&csio->cdb_io.cdb_bytes, csio->cdb_len, ! (char *)csio->data_ptr, csio->dxfer_len, ! &vpo->vpo_stat, &vpo->vpo_count); #ifdef VP0_DEBUG printf("vpo_do_scsi = %d, status = 0x%x, count = %d, vpo_error = %d\n", errno, vpo->vpo_stat, vpo->vpo_count, vpo->vpo_error); + + /* dump of command */ + for (i=0; icdb_len; i++) + printf("%x ", ((char *)&csio->cdb_io.cdb_bytes)[i]); + + printf("\n"); #endif if (errno) { *************** *** 292,298 **** log(LOG_WARNING, "vpo%d: errno = %d\n", vpo->vpo_unit, errno); #endif /* connection to ppbus interrupted */ ! xs->error = XS_DRIVER_STUFFUP; goto error; } --- 387,393 ---- log(LOG_WARNING, "vpo%d: errno = %d\n", vpo->vpo_unit, errno); #endif /* connection to ppbus interrupted */ ! csio->ccb_h.status = CAM_CMD_TIMEOUT; goto error; } *************** *** 301,391 **** #ifdef VP0_WARNING vpo_warning(vpo, xs, vpo->vpo_error); #endif ! xs->error = XS_TIMEOUT; goto error; } ! #define RESERVED_BITS_MASK 0x3e /* 00111110b */ ! #define NO_SENSE 0x0 ! #define CHECK_CONDITION 0x02 ! switch (vpo->vpo_stat & RESERVED_BITS_MASK) { ! case NO_SENSE: ! break; ! case CHECK_CONDITION: ! vpo->vpo_sense.cmd.op_code = REQUEST_SENSE; ! vpo->vpo_sense.cmd.length = sizeof(xs->sense); vpo->vpo_sense.cmd.control = 0; ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, ! xs->sc_link->target, (char *)&vpo->vpo_sense.cmd, ! sizeof(vpo->vpo_sense.cmd), ! (char *)&xs->sense, sizeof(xs->sense), &vpo->vpo_sense.stat, &vpo->vpo_sense.count); ! if (errno) ! /* connection to ppbus interrupted */ ! xs->error = XS_DRIVER_STUFFUP; ! else ! xs->error = XS_SENSE; ! goto error; ! default: /* BUSY or RESERVATION_CONFLICT */ ! xs->error = XS_TIMEOUT; ! goto error; ! } ! if (xs->datalen && (xs->flags & SCSI_DATA_IN)) ! bcopy(vpo->vpo_buffer, xs->data, xs->datalen); ! done: ! xs->resid = 0; ! xs->error = XS_NOERROR; error: ! xs->flags |= ITSDONE; ! scsi_done(xs); return; } ! static int32_t ! vpo_scsi_cmd(struct scsi_xfer *xs) { ! int s; ! if (xs->sc_link->lun > 0) { ! xs->error = XS_DRIVER_STUFFUP; ! return TRY_AGAIN_LATER; } ! if (xs->flags & SCSI_DATA_UIO) { ! printf("UIO not supported by vpo_driver !\n"); ! xs->error = XS_DRIVER_STUFFUP; ! return TRY_AGAIN_LATER; } #ifdef VP0_DEBUG ! printf("vpo_scsi_cmd(): xs->flags = 0x%x, "\ ! "xs->data = 0x%x, xs->datalen = %d\ncommand : %*D\n", ! xs->flags, xs->data, xs->datalen, ! xs->cmdlen, xs->cmd, " " ); #endif ! if (xs->flags & SCSI_NOMASK) { ! vpointr(vpodata[xs->sc_link->adapter_unit], xs); ! return COMPLETE; } ! s = VP0_SPL(); ! vpointr(vpodata[xs->sc_link->adapter_unit], xs); ! splx(s); ! return SUCCESSFULLY_QUEUED; } #define vpoio_d_pulse(vpo,b) { \ --- 396,583 ---- #ifdef VP0_WARNING vpo_warning(vpo, xs, vpo->vpo_error); #endif ! csio->ccb_h.status = CAM_CMD_TIMEOUT; goto error; } ! /* check scsi status */ ! if (vpo->vpo_stat != SCSI_STATUS_OK) { ! csio->scsi_status = vpo->vpo_stat; ! /* check if we have to sense the drive */ ! if ((vpo->vpo_stat & SCSI_STATUS_CHECK_COND) != 0) { ! ! vpo->vpo_sense.cmd.opcode = REQUEST_SENSE; ! vpo->vpo_sense.cmd.length = csio->sense_len; vpo->vpo_sense.cmd.control = 0; ! errno = vpoio_do_scsi(vpo, VP0_INITIATOR, csio->ccb_h.target_id, ! (char *)&vpo->vpo_sense.cmd, sizeof(vpo->vpo_sense.cmd), ! (char *)&csio->sense_data, csio->sense_len, &vpo->vpo_sense.stat, &vpo->vpo_sense.count); ! #ifdef VP0_DEBUG ! printf("(sense) vpo_do_scsi = %d, status = 0x%x, count = %d, vpo_error = %d\ n", ! errno, vpo->vpo_sense.stat, vpo->vpo_sense.count, vpo->vpo_error); ! #endif ! ! /* check sense return status */ ! if (errno == 0 && vpo->vpo_sense.stat == SCSI_STATUS_OK) { ! /* sense ok */ ! csio->ccb_h.status = CAM_AUTOSNS_VALID | CAM_SCSI_STATUS_ERROR; ! csio->sense_resid = csio->sense_len - vpo->vpo_sense.count; ! #ifdef VP0_DEBUG ! /* dump of sense info */ ! printf("(sense) "); ! for (i=0; ivpo_sense.count; i++) ! printf("%x ", ((char *)&csio->sense_data)[i]); ! printf("\n"); ! #endif ! } else { ! /* sense failed */ ! csio->ccb_h.status = CAM_AUTOSENSE_FAIL; ! ! } ! } else { ! ! /* no sense */ ! csio->ccb_h.status = CAM_SCSI_STATUS_ERROR; ! } ! ! goto error; ! } ! ! csio->resid = csio->dxfer_len - vpo->vpo_count; ! csio->ccb_h.status = CAM_REQ_CMP; error: ! splx(s); return; } ! static void ! vpo_action(struct cam_sim *sim, union ccb *ccb) { ! struct vpo_data *vpo = (struct vpo_data *)sim->softc; ! ! switch (ccb->ccb_h.func_code) { ! case XPT_SCSI_IO: ! { ! struct ccb_scsiio *csio; ! ! csio = &ccb->csio; ! ! #ifdef VP0_DEBUG ! printf("vpo%d: XPT_SCSI_IO (0x%x) request\n", ! vpo->vpo_unit, csio->cdb_io.cdb_bytes[0]); ! #endif ! ! vpo_intr(vpo, csio); ! ! xpt_done(ccb); ! break; } + case XPT_CALC_GEOMETRY: + { + struct ccb_calc_geometry *ccg; + u_int32_t size_mb; + u_int32_t secs_per_cylinder; + + ccg = &ccb->ccg; + size_mb = ccg->volume_size + / ((1024L * 1024L) / ccg->block_size); + + #ifdef VP0_DEBUG + printf("vpo%d: XPT_CALC_GEOMETRY (%d, %d) request\n", + vpo->vpo_unit, ccg->volume_size, ccg->block_size); + #endif + + ccg->heads = 64; + ccg->secs_per_track = 32; + + secs_per_cylinder = ccg->heads * ccg->secs_per_track; + ccg->cylinders = ccg->volume_size / secs_per_cylinder; ! ccb->ccb_h.status = CAM_REQ_CMP; ! xpt_done(ccb); ! break; } + case XPT_RESET_BUS: /* Reset the specified SCSI bus */ + { + + #ifdef VP0_DEBUG + printf("vpo%d: XPT_RESET_BUS request\n", vpo->vpo_unit); + #endif + /* first, connect to the drive */ + if (vpoio_connect(vpo, PPB_WAIT|PPB_INTR) || + (vpoio_in_disk_mode(vpo) == 0)) { + + /* release ppbus */ + vpoio_disconnect(vpo); + + ccb->ccb_h.status = CAM_REQ_CMP_ERR; + xpt_done(ccb); + return; + } + + /* reset the SCSI bus */ + vpoio_reset(vpo); + + /* then disconnect */ + vpoio_disconnect(vpo); + ccb->ccb_h.status = CAM_REQ_CMP; + xpt_done(ccb); + break; + } + case XPT_PATH_INQ: /* Path routing inquiry */ + { + struct ccb_pathinq *cpi = &ccb->cpi; + #ifdef VP0_DEBUG ! printf("vpo%d: XPT_PATH_INQ request\n", vpo->vpo_unit); #endif + cpi->version_num = 1; /* XXX??? */ + cpi->max_target = 7; + cpi->max_lun = 0; + cpi->initiator_id = VP0_INITIATOR; + cpi->bus_id = sim->bus_id; + strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); + strncpy(cpi->hba_vid, "Iomega", HBA_IDLEN); + strncpy(cpi->dev_name, sim->sim_name, DEV_IDLEN); + cpi->unit_number = sim->unit_number; ! cpi->ccb_h.status = CAM_REQ_CMP; ! xpt_done(ccb); ! break; ! } ! default: ! ccb->ccb_h.status = CAM_REQ_INVALID; ! xpt_done(ccb); ! break; } ! return; ! } ! ! static void ! vpo_poll(struct cam_sim *sim) ! { ! /* The ZIP is actually always polled throw vpo_action() */ ! #ifdef VP0_DEBUG ! printf("vpo%d: entering vpo_poll()\n", sim->unit_number); ! #endif ! return; } #define vpoio_d_pulse(vpo,b) { \ *************** *** 516,522 **** } /* send SCSI reset signal */ ! vpoio_reset (vpo); vpoio_disconnect(vpo); --- 708,714 ---- } /* send SCSI reset signal */ ! vpoio_reset(vpo); vpoio_disconnect(vpo); *************** *** 694,700 **** return (error); } ! static inline char vpoio_select(struct vpo_data *vpo, int initiator, int target) { --- 886,892 ---- return (error); } ! static char vpoio_select(struct vpo_data *vpo, int initiator, int target) { *************** *** 708,714 **** k = 0; while (!(ppb_rstr(&vpo->vpo_dev) & 0x40) && (k++ < VP0_SELTMO)) ! barrier(); if (k >= VP0_SELTMO) return (VP0_ESELECT_TIMEOUT); --- 900,906 ---- k = 0; while (!(ppb_rstr(&vpo->vpo_dev) & 0x40) && (k++ < VP0_SELTMO)) ! ; if (k >= VP0_SELTMO) return (VP0_ESELECT_TIMEOUT); *************** *** 721,727 **** * * H_SELIN must be low. */ ! static inline char vpoio_wait(struct vpo_data *vpo, int tmo) { --- 913,919 ---- * * H_SELIN must be low. */ ! static char vpoio_wait(struct vpo_data *vpo, int tmo) { *************** *** 737,743 **** k = 0; while (!((r = ppb_rstr(&vpo->vpo_dev)) & nBUSY) && (k++ < tmo)) ! barrier(); /* * Return some status information. --- 929,935 ---- k = 0; while (!((r = ppb_rstr(&vpo->vpo_dev)) & nBUSY) && (k++ < tmo)) ! ; /* * Return some status information. *************** *** 752,758 **** return (0); /* command timed out */ } ! static inline int vpoio_do_scsi(struct vpo_data *vpo, int host, int target, char *command, int clen, char *buffer, int blen, int *result, int *count) { --- 944,950 ---- return (0); /* command timed out */ } ! static int vpoio_do_scsi(struct vpo_data *vpo, int host, int target, char *command, int clen, char *buffer, int blen, int *result, int *count) { *************** *** 787,797 **** */ ppb_wctr(&vpo->vpo_dev, H_AUTO | H_nSELIN | H_INIT | H_STROBE); - #ifdef VP0_DEBUG - printf("vpo%d: drive selected, now sending the command...\n", - vpo->vpo_unit); - #endif - for (k = 0; k < clen; k++) { if (vpoio_wait(vpo, VP0_FAST_SPINTMO) != (char)0xe0) { vpo->vpo_error = VP0_ECMD_TIMEOUT; --- 979,984 ---- *************** *** 803,818 **** } } - #ifdef VP0_DEBUG - printf("vpo%d: command sent, now completing the request...\n", - vpo->vpo_unit); - #endif - /* * Completion ... */ ! rw = ((command[0] == READ_COMMAND) || (command[0] == READ_BIG) || ! (command[0] == WRITE_COMMAND) || (command[0] == WRITE_BIG)); *count = 0; for (;;) { --- 990,1000 ---- } } /* * Completion ... */ ! rw = ((command[0] == READ_6) || (command[0] == READ_10) || ! (command[0] == WRITE_6) || (command[0] == WRITE_10)); *count = 0; for (;;) { *** vpo.h.orig Sat Aug 16 07:05:38 1997 --- vpo.h Wed Jun 24 08:02:33 1998 *************** *** 1,110 **** - /*- - * Copyright (c) 1997 Nicolas Souchu - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * $Id: vpo.h,v 1.2 1997/08/16 14:05:38 msmith Exp $ - * - */ - #ifndef __VP03_H - #define __VP03_H - - #define barrier() __asm__("": : :"memory") - - #define VP0_INITIATOR 0x7 - - #define VP0_SECTOR_SIZE 512 - #define VP0_BUFFER_SIZE 0x12000 - - #define VP0_SPL() splbio() - - #define VP0_ESELECT_TIMEOUT 1 - #define VP0_ECMD_TIMEOUT 2 - #define VP0_ECONNECT 3 - #define VP0_ESTATUS_TIMEOUT 4 - #define VP0_EDATA_OVERFLOW 5 - #define VP0_EDISCONNECT 6 - #define VP0_EPPDATA_TIMEOUT 7 - #define VP0_ENOPORT 9 - #define VP0_EINITFAILED 10 - #define VP0_EINTR 12 - - #define VP0_EOTHER 13 - - #define VP0_OPENNINGS 1 - - #define n(flags) (~(flags) & (flags)) - - /* - * VP0 timings. - */ - #define MHZ_16_IO_DURATION 62 - - #define VP0_SPP_WRITE_PULSE 253 - #define VP0_NIBBLE_READ_PULSE 486 - - /* - * VP0 connections. - */ - #define H_AUTO n(AUTOFEED) - #define H_nAUTO AUTOFEED - #define H_STROBE n(STROBE) - #define H_nSTROBE STROBE - #define H_BSY n(nBUSY) - #define H_nBSY n_BUSY - #define H_SEL SELECT - #define H_nSEL n(SELECT) - #define H_ERR ERROR - #define H_nERR n(ERROR) - #define H_ACK nACK - #define H_nACK n(nACK) - #define H_FLT nFAULT - #define H_nFLT n(nFAULT) - #define H_SELIN n(SELECTIN) - #define H_nSELIN SELECTIN - #define H_INIT nINIT - #define H_nINIT n(nINIT) - - struct vpo_sense { - struct scsi_sense cmd; - unsigned int stat; - unsigned int count; - }; - - struct vpo_data { - unsigned short vpo_unit; - - int vpo_stat; - int vpo_count; - int vpo_error; - - struct ppb_status vpo_status; - struct vpo_sense vpo_sense; - - unsigned char vpo_buffer[VP0_BUFFER_SIZE]; - - struct ppb_device vpo_dev; - struct scsi_link sc_link; - }; - - #endif --- 0 ---- --_=XFMail.1.1.p0.FreeBSD:980626091117:375=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 12:45:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15648 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 12:45:07 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15564 for ; Fri, 26 Jun 1998 12:44:39 -0700 (PDT) (envelope-from jambi@nlanr.net) Received: from localhost (jambi@localhost) by nlanr.net (8.8.6/8.8.6) with SMTP id MAA17781 for ; Fri, 26 Jun 1998 12:44:34 -0700 (PDT) Date: Fri, 26 Jun 1998 12:44:34 -0700 (PDT) From: Jambi To: scsi@FreeBSD.ORG Subject: ccd questions. In-Reply-To: <199806240406.WAA00518@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all, I have been trying to run a few test with ccd and squid cache. Squid requires a great deal of random access and seek operations as the data is spread all over the squid cache partitions. I was planning on using 3 IBM DDRS-39130W S92A connected in a chain to a 2940UW. I decided to use ccd and see how it compares to just having 3 disks mounted seperatly. Here are the questions: a) ccdconfig -v ccd0 65536 0x02 /dev/sd0c /dev/sd1c /dev/sd2c is the command I use to make the device. I can mount it then at an place on the file system (say mount /dev/ccd0c /mnt) but I can't write, ls, cd or do anything to that partition. Am I missing something here? b) when trying to look at the size of the ccd (with df -k) I see that the system shows the size on one disk, not all three of them (every disk is 9.1GB). From the man page I understood that the 0x02 flag will add the disks together so I was expecting to find a 27GB disk not one 9GB disk. advise, explanation? add to FAQ? 10x Jambi _______________________________________________ Jambi Ganbar | (619) 8220938 | jambi@nlanr.net San Diego SuperComputer Center ________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 14:06:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01920 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 14:06:31 -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 OAA01803 for ; Fri, 26 Jun 1998 14:05:57 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id PAA06346; Fri, 26 Jun 1998 15:00:59 -0600 (MDT) Date: Fri, 26 Jun 1998 15:00:59 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199806262100.PAA06346@narnia.plutotech.com> To: Charles Owens cc: scsi@FreeBSD.ORG Subject: Re: any resolution to Adaptec Rev E issue? Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > Hi, > > About a month ago there was discussion on this list of a problem seen > consitently with Adaptec 2940 boards labeled "Rev E". As of the last > posting, Justin Gibbs was apparantly going to try to reproduce the > problem. > > Is there any news on this issue? Justin, were you able to reproduce the > problem? Any ideas about a fix? I have been able to reproduce the problem, but I do not have a fix yet. I will post to this list when a fix becomes available. > I'm about to (today, I hope) place an order for 8 new PII servers, all > with 2940 or 3940 controllers. My supplier has indicated that the boards > he has are indeed Rev E. I'm a bit nervous about this. I would be too. > Another supplier that I spoke with indicated that in general Adaptec has > been becoming increasingly less open with technical details on their > boards, which has resulted in drivers in the various open-source OS's > (FreeBSD, Linux, etc.) lagging behind product changes and being of > generally poorer quality. As such, the supplier (one of the bigger > Linux-oriented suppliers) on longer builds systems with Adaptec > controllers! That supplier is just complaining because the Linux driver port of my work always lags by several months and the Linux mid-level SCSI layer is so poor that they have to put tons of hacks in the code in a lame attempt to make it work correctly with things like tagged queuing. The FreeBSD driver actually outperforms the Adaptec NT driver by quite a bit. > Please be sure to cc: any replies to me directly, as I'm not subscribed to > this list. Please join the list instead. That way the people busy trying to fix the problems your asking about don't have to repeat themselves all the time. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 15:00:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14235 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 15:00:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14066 for ; Fri, 26 Jun 1998 14:59:36 -0700 (PDT) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.7/8.7.3) id OAA08993; Fri, 26 Jun 1998 14:59:25 -0700 (PDT) Date: Fri, 26 Jun 1998 14:59:25 -0700 (PDT) Message-Id: <199806262159.OAA08993@vader.cs.berkeley.edu> To: jambi@nlanr.net CC: scsi@FreeBSD.ORG In-reply-to: (message from Jambi on Fri, 26 Jun 1998 12:44:34 -0700 (PDT)) Subject: Re: ccd questions. From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Date: Fri, 26 Jun 1998 12:44:34 -0700 (PDT) * From: Jambi * * Hey all, * I have been trying to run a few test with ccd and squid cache. * Squid requires a great deal of random access and seek operations as the * data is spread all over the squid cache partitions. I was planning on * using 3 IBM DDRS-39130W S92A connected in a chain to a 2940UW. * I decided to use ccd and see how it compares to just having 3 disks * mounted seperatly. * Here are the questions: * a) ccdconfig -v ccd0 65536 0x02 /dev/sd0c /dev/sd1c /dev/sd2c is the * command I use to make the device. I can mount it then at an place on the * file system (say mount /dev/ccd0c /mnt) but I can't write, ls, cd or do * anything to that partition. Am I missing something here? Did you do a newfs? * b) when trying to look at the size of the ccd (with df -k) I see that the * system shows the size on one disk, not all three of them (every disk is * 9.1GB). From the man page I understood that the 0x02 flag will add the * disks together so I was expecting to find a 27GB disk not one 9GB disk. That means you probably have an old disklabel lying around from when you tested your configuration with only one 9GB disk as a ccd. Delete the old disklabel and try again. The commands should be something like: === # cat > /etc/ccd.conf ccd0 65536 0x02 /dev/sd0c /dev/sd1c /dev/sd2c ^D # dd if=/dev/zero of=/dev/rsd0c bs=512 count=20 --- * # ccdconfig -Cv # newfs /dev/rccd0c === The command marked with "*" may delete your whole partition table if you are using "dedicated" disks. (I don't know since I don't use them -- conventional disks are safe as long as you leave a few sectors before the BSD partition.) In which case, you may need to re-disklabel sd0 before you run the ccdconfig command. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 15:18:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA16601 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 15:18:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from lithium.elemental.org (daleg@lithium.elemental.org [204.91.240.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA16573 for ; Fri, 26 Jun 1998 15:18:28 -0700 (PDT) (envelope-from daleg@lithium.elemental.org) Received: from localhost (daleg@localhost) by lithium.elemental.org (8.8.8/8.8.4) with SMTP id SAA17778; Fri, 26 Jun 1998 18:12:56 -0400 Date: Fri, 26 Jun 1998 18:12:56 -0400 (EDT) From: Dale Ghent Reply-To: Dale Ghent To: Jambi cc: scsi@FreeBSD.ORG Subject: Re: ccd questions. In-Reply-To: Message-ID: X-President-Clinton: On Crack X-LART: Homelite Chainsaw 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, 26 Jun 1998, Jambi wrote: | a) ccdconfig -v ccd0 65536 0x02 /dev/sd0c /dev/sd1c /dev/sd2c is the | command I use to make the device. I can mount it then at an place on the | file system (say mount /dev/ccd0c /mnt) but I can't write, ls, cd or do | anything to that partition. Am I missing something here? Did you newfs it? newfs /dev/rccd0c Also be sure your /etc/ccd.conf is set up correctly for when you boot up. -Dale G. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 26 20:58:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA06133 for freebsd-scsi-outgoing; Fri, 26 Jun 1998 20:58:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA06127 for ; Fri, 26 Jun 1998 20:58:39 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id VAA24473; Fri, 26 Jun 1998 21:58:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806270358.VAA24473@panzer.plutotech.com> Subject: Re: 980513 CAM, /dev/(r)fd0, vnode pseudo-device In-Reply-To: from Steven Schwarz at "Jun 26, 98 08:43:13 am" To: schwarz@cx25450-a.dt1.sdca.home.com (Steven Schwarz) Date: Fri, 26 Jun 1998 21:58:34 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM898919914-24390-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM898919914-24390-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steven Schwarz wrote... > I haven't reported in on my CAM experiences for awhile, but I just > integrated the 980513 snapshot onto my machine and wanted to report > on that. [ ... ] > [The patch applies to > > /usr/src/sys/dev/ppbus/vpo.[ch] > > and should be applied localy in > > /usr/src/sys/dev/ppbus. > > It would be real nice if the future CAM snapshots could preserve the > ppbus stuff in working order, especially, as it would seem to require > very little incremental effort to do so.] I'll try to take a look at it. I guess it wouldn't hurt anything to just apply it and leave it in the tree. We don't have any parallel port zip drives to test it with, though. > Two things of note to report: > > [1] This message > > devstat_end_transaction: HELP!! busy_count is < 0! > > is spammed to syslog whenever any attempt is made to use the floppy > device /dev/(r)fd0 (mounting, reading, writing). (Operations do seem > to succeed, you just get the space-filling message.) Is this related > to CAM? This is sort-of related to CAM. There is a new statistics tracking system called "devstat" that replaces the old dkstat code. The devstat code in the floppy driver is broken -- I fixed it after the last snapshot. I have attached a patch, hopefully it'll apply cleanly. In any case, it will be fixed in the next snapshot. The message is harmless -- basically it indicates that there were more devstat_end_transaction() calls than devstat_start_transaction() calls. There should be a one to one correspondence between the two; the busy count should be zero when there are no outstanding transactions. > [2] In the process of using this machine to make a picoBSD kernel > (for, needless to say, another box to run :->), I noticed that if I > place the sources and do this build on my IBM hard drive, the scsi bus > resets during the build at the point where the build wants to use the > vnode pseudo-device ("treat any file like a disk") during the > manufacture of the bootable floppy. If I move the sources to my IDE > drive, the whole thing works just fine. Again, does vnode need work > to play with CAM? Hmm, I believe there were some bugfixes to the Adaptec driver between the May 13th and May 20th snapshot that had to do with IBM drives. You may be running into one of those problems. I think that the folks who were having problems actually got a panic, though, not a bus reset. Ken -- Kenneth Merry ken@plutotech.com --ELM898919914-24390-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=fd.devstat.diffs Content-Description: fd.devstat.diffs Content-Transfer-Encoding: 7bit *** src/sys/i386/isa/fd.c.orig --- src/sys/i386/isa/fd.c *************** *** 1284,1289 **** --- 1284,1293 ---- s = splbio(); bufqdisksort(&fdc->head, bp); untimeout(fd_turnoff, (caddr_t)fdu, fd->toffhandle); /* a good idea */ + + /* Tell devstat we are starting on the transaction */ + devstat_start_transaction(&fd->device_stats); + fdstart(fdcu); splx(s); return; *************** *** 1766,1772 **** devstat_end_transaction(&fd->device_stats, bp->b_bcount - bp->b_resid, DEVSTAT_TAG_NONE, ! (bp->b_flags & B_READ) ? DEVSTAT_READ : DEVSTAT_WRITE); biodone(bp); fdc->fd = (fd_p) 0; fdc->fdu = -1; --- 1770,1777 ---- devstat_end_transaction(&fd->device_stats, bp->b_bcount - bp->b_resid, DEVSTAT_TAG_NONE, ! (bp->b_flags & B_READ) ? ! DEVSTAT_READ : DEVSTAT_WRITE); biodone(bp); fdc->fd = (fd_p) 0; fdc->fdu = -1; *************** *** 1876,1885 **** struct subdev *sd; fdc_p fdc = fdc_data + fdcu; register struct buf *bp; - #ifdef SLICE struct fd_data *fd; int fdu; - #endif bp = bufq_first(&fdc->head); --- 1881,1888 ---- *************** *** 1890,1896 **** if(fd->options & FDOPT_NORETRY) goto fail; #else ! if(fd_data[FDUNIT(minor(bp->b_dev))].options & FDOPT_NORETRY) goto fail; #endif switch(fdc->retry) --- 1893,1902 ---- if(fd->options & FDOPT_NORETRY) goto fail; #else ! fdu = FDUNIT(minor(bp->b_dev)); ! fd = fd_data + fdu; ! ! if(fd_data[fdu].options & FDOPT_NORETRY) goto fail; #endif switch(fdc->retry) *************** *** 1939,1944 **** --- 1945,1957 ---- bp->b_error = EIO; bp->b_resid += bp->b_bcount - fdc->fd->skip; bufq_remove(&fdc->head, bp); + + /* Tell devstat we have finished with the transaction */ + devstat_end_transaction(&fd->device_stats, + bp->b_bcount - bp->b_resid, + DEVSTAT_TAG_NONE, + (bp->b_flags & B_READ) ? DEVSTAT_READ : + DEVSTAT_WRITE); fdc->fd->skip = 0; biodone(bp); fdc->state = FINDWORK; --ELM898919914-24390-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message