From owner-freebsd-scsi Sun Mar 21 2:20:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id A377D14F9B for ; Sun, 21 Mar 1999 02:20:54 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA23639; Sun, 21 Mar 1999 11:20:34 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id LAA49523; Sun, 21 Mar 1999 11:05:10 +0100 (MET) (envelope-from j) Message-ID: <19990321110510.38582@uriah.heep.sax.de> Date: Sun, 21 Mar 1999 11:05:10 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: ken@plutotech.com Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <199903141441.PAA71438@qix> <199903142053.NAA13995@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903142053.NAA13995@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 01:53:10PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > The issue isn't really whether it's "poor performance" or "poor for a wide > drive", but whether the performance you're getting out of the drive is what > the drive is capable of. Just FWIW, i've finally applied Ken's patches to camcontrol (*), and tested my DCAS 34330 with various tagged queuing parameters. The results seem to basically confirm the results in the audit-trail of PR 10398, except i think the best balanced results are for 2 tags on my drive. Note that the following is running on my /tmp partition which is at about 80 % offset from the beginning of the drive. This probably explains why the figures are slower than those in PR 10398 although the raw data rate on the outer tracks (dd if=/dev/rda1 of=/dev/null) is about the same. So 1 or 2 tags, i don't care that much after seeing this. NCR 53C810 10 MHz 8 bit IBM DCAS-34330 S65A -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU t=32,qm=0 100 3969 96.7 4435 39.1 1891 21.0 4079 94.5 5754 47.5 84.2 6.6 t=32,qm=1 100 3806 93.4 3167 27.4 1899 21.3 3911 91.1 5102 42.0 84.9 6.7 t=2,qam=0 100 3889 97.1 5500 45.4 2184 23.2 4125 95.8 5748 47.5 84.1 6.7 t=2,qam=1 100 3968 96.6 5408 46.8 2224 24.5 4209 97.6 5403 44.5 74.5 6.1 t=1,qam=0 100 3975 96.7 5446 43.8 1875 19.7 4175 97.2 5663 45.3 78.5 6.2 `t' - number of tags `qm', `qam' - queue algorithm modifier (0 - restricted reordering, 1 - unrestricted reordering allowed; mode page 10) WCE = 1 for all tests (PR 10398 already confirms violently enough that disabling the write cache is not a good idea) (*) In order to prevent camcontrol from coredumping on my SONY SMO, i had to apply this patch: --- camcontrol.c.orig Sun Mar 21 10:22:53 1999 +++ camcontrol.c Sun Mar 21 10:58:14 1999 @@ -1926,9 +1926,11 @@ fprintf(stdout, "%ssync parameter: %d\n", pathstr, cts->sync_period); - freq = scsi_calc_syncsrate(cts->sync_period); - fprintf(stdout, "%sfrequencey: %d.%03dMHz\n", pathstr, - freq / 1000, freq % 1000); + if (cts->sync_period != 0) { + freq = scsi_calc_syncsrate(cts->sync_period); + fprintf(stdout, "%sfrequencey: %d.%03dMHz\n", pathstr, + freq / 1000, freq % 1000); + } } if (cts->valid & CCB_TRANS_SYNC_OFFSET_VALID) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 2:22: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 3504615100 for ; Sun, 21 Mar 1999 02:21:59 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA23659 for scsi@FreeBSD.ORG; Sun, 21 Mar 1999 11:21:40 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id LAA49805; Sun, 21 Mar 1999 11:20:50 +0100 (MET) (envelope-from j) Message-ID: <19990321112050.05515@uriah.heep.sax.de> Date: Sun, 21 Mar 1999 11:20:50 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Reply-To: Joerg Wunsch References: <199903210039.RAA20800@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903210039.RAA20800@narnia.plutotech.com>; from Justin T. Gibbs on Sat, Mar 20, 1999 at 05:39:47PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Justin T. Gibbs wrote: > The only thing I recall about this was whether we should return > ENOSPC or continually return 0 on EOM/EOT. If we decide to simply > "pause" at EOM (i.e. return a short write or a 0 length write), > then this is fine by me. So we are in violent agreement then? :) > I still believe that returning a real > error at EOT is correct. I could live with ENOSPC, but only iff no data have been written at all in a particular request. Iff something has been written, the `short write' is IMHO the correct way that's compatible with other usage of write(2) throughout Unix, so the caller can be notified that their request only partially succeeded (but succeeded so far). > dump understands ENOSPC, and should work correctly if ENOSPC > is still returned at EOM or EOT. Probably. I think part of the problem dump's algorithm doesn't (didn't?) is that EIO has been reported, as opposed to ENOSPC. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 6:17:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.iol.ie (mail1.mail.iol.ie [194.125.2.192]) by hub.freebsd.org (Postfix) with ESMTP id 37CB1150F1 for ; Sun, 21 Mar 1999 06:17:37 -0800 (PST) (envelope-from nick@iol.ie) Received: from beckett.earlsfort.iol.ie (beckett.earlsfort.iol.ie [194.125.21.2]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id OAA07352; Sun, 21 Mar 1999 14:17:16 GMT Received: (from nick@localhost) by beckett.earlsfort.iol.ie Sendmail (v8.8.8) id OAA28733; Sun, 21 Mar 1999 14:17:14 GMT From: Nick Hilliard Message-Id: <199903211417.OAA28733@beckett.earlsfort.iol.ie> Subject: Re: dpt raid-5 performance To: grog@lemis.com (Greg Lehey) Date: Sun, 21 Mar 1999 14:17:13 +0000 (GMT) Cc: tom@sdf.com, nick@iol.ie, freebsd-scsi@FreeBSD.ORG In-Reply-To: <19990321084436.Z429@lemis.com> from "Greg Lehey" at Mar 21, 99 08:44:36 am X-NCC-RegID: ie.iol Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I haven't yet replied to Nick's message because I wanted to check > something here first, and I've been too busy so far. But I'll come > back with some comparisons. I'm going to run some benchmarks over the next few days and see what they throw up. My instinct was that 512K was a "good" interleave size in some sense of the word, mainly because of the fact that it would cause so many fewer disk io ops in most circumstances -- in fact, all circumstances except where you're doing piles of tiny io ops. The bonnie results seem to shatter this illusion. Does anyone know if a 2044W card creates exactly the same RAID structure on a disk array as a 3334UW? I have both cards lying around the place at the moment, and it would trivial to run benchmarks for both systems just by replacing the card on the machine. Nick Hilliard Ireland On-Line System Operations To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 8:21: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id A33D415043 for ; Sun, 21 Mar 1999 08:21:06 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id RAA27944 for freebsd-scsi@FreeBSD.ORG; Sun, 21 Mar 1999 17:20:46 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id QAA07555; Sun, 21 Mar 1999 16:52:45 +0100 (MET) (envelope-from j) Message-ID: <19990321165244.06249@uriah.heep.sax.de> Date: Sun, 21 Mar 1999 16:52:44 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch References: <199903180448.VAA37060@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903180448.VAA37060@panzer.plutotech.com>; from Kenneth D. Merry on Wed, Mar 17, 1999 at 09:48:27PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > > Any chance that camcontrol could gaing the ability to remove a > > device from the system? 'camcontrol detach' maybe? > I suppose that's possible, but I'd rather just fix things so that the > da driver attaches properly. Nevertheless, `camcontrol detach' would be a great option. One of my machines at work is (often) used to test random SCSI equipment before shipping it to customers. A `detach' option would be nice there, since it allowed for just making the device unknown again i've only attached for the test, without affecting anything else. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 8:21:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 4C561150F7 for ; Sun, 21 Mar 1999 08:21:08 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id RAA27945 for freebsd-scsi@FreeBSD.ORG; Sun, 21 Mar 1999 17:20:49 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id QAA07567; Sun, 21 Mar 1999 16:56:07 +0100 (MET) (envelope-from j) Message-ID: <19990321165607.23205@uriah.heep.sax.de> Date: Sun, 21 Mar 1999 16:56:07 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch References: <199903180624.XAA39730@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903180624.XAA39730@panzer.plutotech.com>; from Kenneth D. Merry on Wed, Mar 17, 1999 at 11:24:02PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > > eisa-test# disklabel -R -r da5 foo > > disklabel: No space left on device > > It's probably giving you that because you've already got a label on the > device and you're trying to write a new one. Well, i think that's the slice code. ENOSPC is IMHO one of the responses the slice code could cause (albeit i think it's a confusing one). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 11:28: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from elmls02.ce.mediaone.net (elmls02.ce.mediaone.net [24.131.128.27]) by hub.freebsd.org (Postfix) with ESMTP id 0592A1519A for ; Sun, 21 Mar 1999 11:28:06 -0800 (PST) (envelope-from DrXyzzy@mediaone.net) Received: from gamera.hws (rm01-24-29-193-109.ce.mediaone.net [24.29.193.109]) by elmls02.ce.mediaone.net (8.8.7/8.8.7) with ESMTP id NAA01770; Sun, 21 Mar 1999 13:27:46 -0600 (CST) Received: (from hal@localhost) by gamera.hws (8.9.1/8.9.1) id NAA00267; Sun, 21 Mar 1999 13:27:45 -0600 (CST) (envelope-from DrXyzzy@mediaone.net) To: scsi@freebsd.org Subject: 3.0 installs, 3.1 won't MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Hal Snyder Date: 21 Mar 1999 13:27:44 -0600 Message-ID: <87vhfuhccv.fsf@gamera.hws> Lines: 41 User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) Emacs/20.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm sending this in on behalf of a friend; it seems to be a SCSI problem. The motherboard and peripherals are about 1 year old. The Walnut Creek FreeBSD-3.0 CD installs/runs just fine. NT4Sp4 runs, well, as well as you'd expect it to. Copying files from the 3.1 CD seems to be almost twice as fast as the install from 3.0, but after about 30% of the way into /bin it stalls with repeated occurrences of "Unexpected busfree. LASTPHASE == 0xa0", never recovering. Hardware: 1. Tyan S1696-DLUA motherboard (dual P-II 300's, Adaptec 7895 dual UWSCSI, etc.) AMI BIOS Adaptec BIOS V1.32 Note: control-A related settings follow: AIC-7895 @ BUS: 00h Device: 0Fh Channel: A IRQ10 E800h AIC-7895 @ BUS: 00h Device: 0Fh Channel: B IRQ11 EC00h H/A SCSI ID=7 Termination = Auto Parity = Enabled Sync = Yes Tranfer rate 40MB/sec max. Initiate Wide = Yes Reset SCSI at IC Init = Enabled Extended BIOS Translation = Enabled Host Adapter BIOS = Enabled Removable Support = Boot Only BIOS Support for Bootable CD = Enabled BIOS Support for INT13 Extensions = Enabled 2. IBM DGVS09U UltraStar 9ZX 9.1GB 10,000 rpm UWSCSI drive On channel B as SCSI ID 0 (wide) 3. Plextor PX-32i Ultraplex USCSI interface CD drive On channel A as SCSI ID 2 (narrow) Ideas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 11:47:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 953D314D1E for ; Sun, 21 Mar 1999 11:47:18 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA03112; Sun, 21 Mar 1999 11:46:48 -0800 Date: Sun, 21 Mar 1999 11:46:48 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: SCSI resets in CAM during startup.... In-Reply-To: <199903191931.MAA15479@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 > > I'd like to make a request- I'd like the initial SCSI reset done currently > > by the CAM probe framework to be: > > > > a) The responsibility/discretion of the hba driver to perform. > > Hmm. I've added the ability for the HBA to request that the initial > bus reset not occur a little while ago. Take a look at the PIM_NOBUSRESET > flag for the path inquiry ccb. This flag only effects bus reset requests > during initial probe situations. I added it for target mode. Missed that. > > > b) Config option'ed off (for a CAM_MULTI_INITIATOR) option. > > I agree that you should be able to indicate that a particular bus > is connected to multiple initiators, but I don't know that a single > option switch affecting all busses is the right solution. Before > anything can happen here, the probe code in cam_xpt needs to be > modified so that, in the case of no bus reset, the controller is > told to perform negotiation with the first command on the bus. Otherwise > outstanding transfer negotiations left over by the BIOS will screw things > up. This is on my white board. Okay. > > > One reason for #a is that the Fibre Channel equivalent of this is > > pretty heavy weight. > > For Fiber Channel, the initial bus reset is not necessary as no > transfer negotiation ever occurs. The proper solution here is for > the code in cam_xpt.c to query the controller to see if negotiation > is possible on that controller and to only perform the bus reset > if there is the posiblity of a stale negotiation. This should be > an easy thing to fix. Or the PIM_NOBUSRESET will work. It's probably okay for later resets since that's done only as a last extreme. >,.. > > > > Opinions? > > Perhaps we need to have a larger 'reset' vocabulary? For Fibre-Channel, > these are only going to occur in the event of error recovery or an explicit > user request, but even so, you should be able to better express what you > are attempting to achieve with the reset. Well, we have 'reset device' and 'reset bus'. I'm not sure others are needed until the semantics are worked out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14: 0: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with SMTP id 1FDAD1510C for ; Sun, 21 Mar 1999 14:00:03 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with esmtp (Exim 1.82 #3) id 10OpEn-0006Jh-00; Sun, 21 Mar 1999 12:54:25 -0800 Date: Sun, 21 Mar 1999 12:54:23 -0800 (PST) From: Tom To: Greg Lehey Cc: Nick Hilliard , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance In-Reply-To: <19990321084436.Z429@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, Greg Lehey wrote: > > FreeBSD will likely never send IOs big enough for the strip size of > > 512kb to ever be useful. > > It does. The largest I/O transfer is 64 kB. You don't want to > fragment requests, because that increases the I/O load on the array. At the cost of single-process performance. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14: 4:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with SMTP id 607E915207 for ; Sun, 21 Mar 1999 14:04:21 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with esmtp (Exim 1.82 #3) id 10OpJ1-0006Jz-00; Sun, 21 Mar 1999 12:58:47 -0800 Date: Sun, 21 Mar 1999 12:58:46 -0800 (PST) From: Tom To: Nick Hilliard Cc: Greg Lehey , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance In-Reply-To: <199903211417.OAA28733@beckett.earlsfort.iol.ie> 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 Mar 1999, Nick Hilliard wrote: > > I haven't yet replied to Nick's message because I wanted to check > > something here first, and I've been too busy so far. But I'll come > > back with some comparisons. > > I'm going to run some benchmarks over the next few days and see what they > throw up. > > My instinct was that 512K was a "good" interleave size in some sense of the > word, mainly because of the fact that it would cause so many fewer disk io > ops in most circumstances -- in fact, all circumstances except where you're > doing piles of tiny io ops. The bonnie results seem to shatter this > illusion. Uhh... no. Large stripe sizes for good for lots of parallel processes. Bonnie is only a single process, so you would want to break each disk i/o into multiple requests to maximize its performance (after all the array doesn't have anything else to do). Optimizing for multi-user is very different from single-user. > Does anyone know if a 2044W card creates exactly the same RAID structure on > a disk array as a 3334UW? I have both cards lying around the place at the > moment, and it would trivial to run benchmarks for both systems just by > replacing the card on the machine. The 3334UW has a faster processor. The I/Os per second can be looked up. > Nick Hilliard > Ireland On-Line System Operations Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14:30:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 82DED15058 for ; Sun, 21 Mar 1999 14:30:37 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA13601; Mon, 22 Mar 1999 09:00:16 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA07195; Mon, 22 Mar 1999 09:00:15 +1030 (CST) Message-ID: <19990322090015.S429@lemis.com> Date: Mon, 22 Mar 1999 09:00:15 +1030 From: Greg Lehey To: Tom Cc: Nick Hilliard , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance References: <19990321084436.Z429@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Tom on Sun, Mar 21, 1999 at 12:54:23PM -0800 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 Sunday, 21 March 1999 at 12:54:23 -0800, Tom wrote: > > On Sun, 21 Mar 1999, Greg Lehey wrote: > >>> FreeBSD will likely never send IOs big enough for the strip size of >>> 512kb to ever be useful. >> >> It does. The largest I/O transfer is 64 kB. You don't want to >> fragment requests, because that increases the I/O load on the array. > > At the cost of single-process performance. I don't know what you mean here. Can you explain that statement? Greg -- See complete headers for address, home page 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 Sun Mar 21 14:36:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 34D3C14E3E for ; Sun, 21 Mar 1999 14:36:02 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id RAA29287; Sun, 21 Mar 1999 17:35:16 -0500 (EST) Date: Sun, 21 Mar 1999 17:35:15 -0500 (EST) From: "Matthew N. Dodd" To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990321165607.23205@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, J Wunsch wrote: > As Kenneth D. Merry wrote: > > > eisa-test# disklabel -R -r da5 foo > > > disklabel: No space left on device > > It's probably giving you that because you've already got a label on the > > device and you're trying to write a new one. > > Well, i think that's the slice code. ENOSPC is IMHO one of the > responses the slice code could cause (albeit i think it's a confusing > one). No slice code running on the box (if we're talking about the same slice code). This isn't a hardware problem because I fed the cart in question to my library and it doesn't like it either. I suspect fdisk may not be doing the right thing but I'll be damned if I know what its doing wrong. I have 0'ed out the entire disk and confirmed with 'hd' before re-fdisking. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14:43:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with SMTP id B95DF14EF7 for ; Sun, 21 Mar 1999 14:43:48 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with esmtp (Exim 1.82 #3) id 10Opv8-0006ML-00; Sun, 21 Mar 1999 13:38:10 -0800 Date: Sun, 21 Mar 1999 13:38:09 -0800 (PST) From: Tom To: Greg Lehey Cc: Nick Hilliard , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance In-Reply-To: <19990322090015.S429@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Greg Lehey wrote: > On Sunday, 21 March 1999 at 12:54:23 -0800, Tom wrote: > > > > On Sun, 21 Mar 1999, Greg Lehey wrote: > > > >>> FreeBSD will likely never send IOs big enough for the strip size of > >>> 512kb to ever be useful. > >> > >> It does. The largest I/O transfer is 64 kB. You don't want to > >> fragment requests, because that increases the I/O load on the array. > > > > At the cost of single-process performance. > > I don't know what you mean here. Can you explain that statement? Small strip sizes are good for single-user situations (like running Bonnie), because the IO load will be split over all drives. Large strip sizes are good for multi-user situations, where the extra overhead of the transactions becomes a problem. DPT starts with a default of 16KB for the strip size. Until recently, it couldn't be increased over 64KB. I've used these cards quite extensively under FreeBSD. Remember what is good for DPT cards is not always what is good for other systems, particularly software solutions. > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14:50:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 512E214EF7 for ; Sun, 21 Mar 1999 14:50:22 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id PAA93193; Sun, 21 Mar 1999 15:50:02 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903212250.PAA93193@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dave Marquardt Cc: scsi@FreeBSD.org, ken@plutotech.com Subject: Re: kern/10663: hpscan doesn't like 3.1's pt device In-reply-to: Your message of "21 Mar 1999 13:31:43 CST." <85yakqskps.fsf@localhost.zilker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Mar 1999 15:41:01 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Andrew Cagney writes: >> Workaround: >> >> Switch to the ``sane'' scanner but then find that that has >> other problems (do I really need ``chmod a+rw /dev/xpt0''? ;-). > >No, just create a `scanner' group, put yourself in it, then > > chgrp scanner /dev/xpt0 > chmod 660 /dev/xpt0 We can probably make some of the ioctls provided by the xpt device accessable to users who only have read permissions on the device. SANE likely uses the device matching and listing functions which can't be used to compromise the system. Of course, some may feel that being able to list the types of SCSI devices in the system is a security hole, so we'd probably continue to ship the XPT device as r/w only by root. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14:52:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 2484814EF7; Sun, 21 Mar 1999 14:52:08 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA13703; Mon, 22 Mar 1999 09:21:48 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA07220; Mon, 22 Mar 1999 09:21:47 +1030 (CST) Message-ID: <19990322092147.T429@lemis.com> Date: Mon, 22 Mar 1999 09:21:47 +1030 From: Greg Lehey To: Nick Hilliard Cc: tom@sdf.com, freebsd-scsi@FreeBSD.ORG, FreeBSD Hackers Subject: Re: dpt raid-5 performance References: <19990321084436.Z429@lemis.com> <199903211417.OAA28733@beckett.earlsfort.iol.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199903211417.OAA28733@beckett.earlsfort.iol.ie>; from Nick Hilliard on Sun, Mar 21, 1999 at 02:17:13PM +0000 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 [copying -hackers, since this is of relevance beyond -scsi] On Sunday, 21 March 1999 at 14:17:13 +0000, Nick Hilliard wrote: >> I haven't yet replied to Nick's message because I wanted to check >> something here first, and I've been too busy so far. But I'll come >> back with some comparisons. > > I'm going to run some benchmarks over the next few days and see what they > throw up. > > My instinct was that 512K was a "good" interleave size in some sense > of the word, mainly because of the fact that it would cause so many > fewer disk io ops in most circumstances -- in fact, all > circumstances except where you're doing piles of tiny io ops. The > bonnie results seem to shatter this illusion. I have found a similar tendency with my testing with vinum. *However*, I also looked at the number of I/O requests issued, and they are very varied. There could be a cache interaction problem here. One of the things is that bonnie doesn't measure raw disk throughput, and that's what we're really trying to measure. The figures don't make any sense. Here are the preliminary results. They were all done with a 1.6 GB volume with one plex spread over four ancient CDC drives (thus the poor overall performance; the comparisons should be valid, however). -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU Writes Reads Mblock Mstripe ufs 100 582 13.8 479 3.0 559 5.2 1121 24.6 1124 5.2 45.4 2.6 s1k 100 156 15.4 150 12.3 108 3.7 230 6.7 230 2.7 36.3 3.4 311848 328587 619009 138783 s8k 100 1492 44.8 1478 18.4 723 8.1 1466 34.0 1467 8.2 115.4 8.0 38913 41065 56152 9337 s64k 100 1723 48.6 1581 18.6 1021 11.8 1792 39.5 1827 11.1 115.3 8.8 17238 8231 1294 333 s256k 100 1717 47.2 1629 19.0 937 11.2 1469 32.2 1467 8.7 95.9 7.8 16982 9272 2001 494 s512k 100 1772 48.8 1621 18.0 732 8.3 1256 27.4 1254 7.4 115.4 8.8 16157 7564 155 37 r512k 100 379 14.9 385 8.9 360 4.5 1122 24.7 1258 7.4 80.9 6.7 38339 46453 521 793 s4m/16 100 1572 52.8 1336 18.6 612 6.1 1139 25.2 1142 5.6 97.9 7.1 20434 8028 17 7 s4m/17 100 1431 44.8 1234 16.9 613 6.1 1145 25.4 1147 5.6 97.3 7.0 19922 8101 113 31 Sorry for the format; I'll probably remove some of the bonnie columns when I'm done. The "Machine" indicates the type and stripe size of the plex (r: RAID-5, s: striped, ufs: straight ufs partition for comparison purposes). The additional columns at the end are the writes and reads at plex level, the number of multiblock transfers (combined read and write), and the number of multistripe transfers (combined read and write). A multiblock transfer is one which requires two separate I/Os to satisfy, and a multistripe transfer is one which requires accessing two different stripes. They're the main cause of degraded performance with small stripes. I tried two different approaches with the 4 MB stripes: with a default newfs, I got 16 cylinders per cylinder group and cylinder groups of 32 MB, which placed all the superblocks on the first disk. The second time I tried with 17 cylinders per super group, which put successive superblocks on a different disk. Some of the things that seem to come out of these results are: - Performance with 1 kB stripes is terrible. Performance with 8 kB stripes is much better, but a further increase stripe size helps. - Block read and random seek performance increases dramatically up to a stripe size of about 64 kB, after which it drops off again. - Block write performance increases up to a stripe size of 512 kB, after which it drops off again. - Peak write performance is about 3.5 times that of a straight UFS file system. This is due to buffer cache: the writes are asynchronous to the process, and can thus overlap. I'm quite happy with this particular figure, since it's relatively close to the theoretical maximum of a 4x performance improvement. - Peak read performance is about 1.6 times that of a straight UFS file system. - RAID-5 read performance is comparable to striped read performance. Write performance is about 24% of striped write performance. Note that there is a *decrease* in CPU time for RAID-5 writes: the reason for the performance decrease is that there are many more I/O operations (compare the Reads and Writes columns). The trouble with these results is that they don't make sense. Although we can see some clear trends, there are also obvious anomalies: - On a striped volume, the mapping of reads and writes is identical. Why should reads peak at 64 kB and writes at 512 kB? - The number of multiblock and multistripe transfers for s4m/17 is 8 times that for s4m/16. The number of writes for s4m/17 is lower than for s4m/16. The number of writes should be the number of raw writes to the device (volume) plus the number of multiblock and multistripe transfers; in other words, s4m/17 should have *more* transfers, not less. There's obviously something else here, and I suspect cache. - The random seek performance is pretty constant for s8k, s64k and s512k. Since bonnie performs 8k transfers, this seems reasonable. On the other hand, the performance was much worse for s256k, which I did last. Again, I suspect that there are other issues here which are clouding the results. In addition, bonnie does not simulate true file system performance well. The character I/O benchmarks are not of relevance for what we're looking at, and the block I/O benchmarks all use 8 kB transfers. True file system performance includes transfers of between 1 and 120 sectors of 512 bytes, with an average apparently in the order of 8kB. In real life, the performance benefits of large stripes will be greater. I'm currently thinking of writing a program which will be able to simulate this behaviour and get more plausible measurements. To add to this theory, I've just re-run the 64 kB test under what look to me like identical conditions. Here are the results. The first line is a copy of the one I did yesterday (above), the second one are the new results: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU Writes Reads Mblock Mstripe s64k 100 1723 48.6 1581 18.6 1021 11.8 1792 39.5 1827 11.1 115.3 8.8 17238 8231 1294 333 s64k 100 1711 48.4 1633 18.9 983 11.5 1778 39.6 1815 11.3 95.8 7.8 16495 8029 7952 1986 In other words, there are significant differences in the way vinum was accessed in each case, and in particular we can assume that the differences in random seek performance are, well, random. Getting back to your results which started this thread, however, there are some significant differences: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 541 7.5 491 1.7 458 2.3 4293 59.1 4335 16.2 193.6 6.8 100 379 14.9 385 8.9 360 4.5 1122 24.7 1258 7.4 80.9 6.7 Comparing the block write and block read performances, vinum gets about 30% of the read performance on writes. Your DPT write results show only 11% of the read performance, and are in fact only slightly faster than vinum with the ancient disks, so I can't see that this could be due to the faster disks. So yes, I suspect there is something wrong here. It's possible that DPT doesn't DTRT with large slices: Vinum only accesses that part of a slice which is necessary for the transfers. It's possible that DPT accesses the complete 512 kB block on each transfer, in which case, of course, it would be detrimental to use a stripe size in excess of about 64 kB, and you might even get better performance with 32 kB. If this is the case, however, it's a bug with DPT's implementation, not a general principle. Greg -- See complete headers for address, home page 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 Sun Mar 21 14:52:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 920A515259 for ; Sun, 21 Mar 1999 14:52:17 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id RAA86788; Sun, 21 Mar 1999 17:49:45 -0500 (EST) Date: Sun, 21 Mar 1999 17:49:45 -0500 (EST) From: Chuck Robey To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG, ken@plutotech.com Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <19990321110510.38582@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, J Wunsch wrote: > NCR 53C810 10 MHz 8 bit > IBM DCAS-34330 S65A > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > t=32,qm=0 100 3969 96.7 4435 39.1 1891 21.0 4079 94.5 5754 47.5 84.2 6.6 > t=32,qm=1 100 3806 93.4 3167 27.4 1899 21.3 3911 91.1 5102 42.0 84.9 6.7 > t=2,qam=0 100 3889 97.1 5500 45.4 2184 23.2 4125 95.8 5748 47.5 84.1 6.7 > t=2,qam=1 100 3968 96.6 5408 46.8 2224 24.5 4209 97.6 5403 44.5 74.5 6.1 > t=1,qam=0 100 3975 96.7 5446 43.8 1875 19.7 4175 97.2 5663 45.3 78.5 6.2 Huh. I tried using Ken's camcontrol patches, but when I did that (and thus enabled tagged queueing) the drive hung within 10 seconds of beginning bonnie. Now I'm somewhat surprised, because without queueing turned on, here's what I get from bonnie: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 6229 80.9 6213 34.9 2250 13.5 5711 79.7 6390 25.6 85.2 4.6 This looks quite a bit better than yours, so I'm wondering if I'd doing something to skew the results? I have a 5400 RPM DCAS 34330W: da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number F3TX1813 da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) This was on a 100MB bonnie test. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 14:56:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 29D6314E11 for ; Sun, 21 Mar 1999 14:56:48 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA13734; Mon, 22 Mar 1999 09:26:28 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA07239; Mon, 22 Mar 1999 09:26:28 +1030 (CST) Message-ID: <19990322092628.V429@lemis.com> Date: Mon, 22 Mar 1999 09:26:28 +1030 From: Greg Lehey To: Tom , Nick Hilliard Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance References: <199903211417.OAA28733@beckett.earlsfort.iol.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Tom on Sun, Mar 21, 1999 at 12:58:46PM -0800 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 Sunday, 21 March 1999 at 12:58:46 -0800, Tom wrote: > > On Sun, 21 Mar 1999, Nick Hilliard wrote: > >>> I haven't yet replied to Nick's message because I wanted to check >>> something here first, and I've been too busy so far. But I'll come >>> back with some comparisons. >> >> I'm going to run some benchmarks over the next few days and see what they >> throw up. >> >> My instinct was that 512K was a "good" interleave size in some sense of the >> word, mainly because of the fact that it would cause so many fewer disk io >> ops in most circumstances -- in fact, all circumstances except where you're >> doing piles of tiny io ops. The bonnie results seem to shatter this >> illusion. > > Uhh... no. Large stripe sizes for good for lots of parallel > processes. We're still out on that one. > Bonnie is only a single process, Bonnie's random seek test runs three parallel processes. No, you can't change the number short of modifying the code. > so you would want to break each disk i/o into multiple requests to > maximize its performance (after all the array doesn't have anything > else to do). This is incorrect. You'd still slow things down. Greg -- See complete headers for address, home page 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 Sun Mar 21 15: 2: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 312F714E11 for ; Sun, 21 Mar 1999 15:02:03 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA13723; Mon, 22 Mar 1999 09:24:17 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA07228; Mon, 22 Mar 1999 09:24:17 +1030 (CST) Message-ID: <19990322092417.U429@lemis.com> Date: Mon, 22 Mar 1999 09:24:17 +1030 From: Greg Lehey To: Tom Cc: Nick Hilliard , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance References: <19990322090015.S429@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Tom on Sun, Mar 21, 1999 at 01:38:09PM -0800 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 Sunday, 21 March 1999 at 13:38:09 -0800, Tom wrote: > > On Mon, 22 Mar 1999, Greg Lehey wrote: > >> On Sunday, 21 March 1999 at 12:54:23 -0800, Tom wrote: >>> >>> On Sun, 21 Mar 1999, Greg Lehey wrote: >>> >>>>> FreeBSD will likely never send IOs big enough for the strip size of >>>>> 512kb to ever be useful. >>>> >>>> It does. The largest I/O transfer is 64 kB. You don't want to >>>> fragment requests, because that increases the I/O load on the array. >>> >>> At the cost of single-process performance. >> >> I don't know what you mean here. Can you explain that statement? > > Small strip sizes are good for single-user situations (like running > Bonnie), because the IO load will be split over all drives. Did you read my message refuting this claim? If so, what are your arguments against it? > Large strip sizes are good for multi-user situations, where the > extra overhead of the transactions becomes a problem. What does that mean? Which transaction? We're talking disk transfers here. > DPT starts with a default of 16KB for the strip size. Until > recently, it couldn't be increased over 64KB. I've used these cards > quite extensively under FreeBSD. Remember what is good for DPT > cards is not always what is good for other systems, particularly > software solutions. Yes, that's what I suggest in my long performance analysis message. Greg -- See complete headers for address, home page 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 Sun Mar 21 15: 8:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id 54ED314BE2 for ; Sun, 21 Mar 1999 15:08:38 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id SAA10709; Sun, 21 Mar 1999 18:08:11 -0500 (EST) (envelope-from cao) Date: Sun, 21 Mar 1999 18:08:11 -0500 From: "Chuck O'Donnell" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: error messages from bt driver Message-ID: <19990321180811.A10641@milf18.bus.net> References: <19990318195209.A27547@milf18.bus.net> <199903210116.SAA77696@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199903210116.SAA77696@pluto.plutotech.com>; from Justin T. Gibbs on Sat, Mar 20, 1999 at 06:07:27PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Mar 20, 1999 at 06:07:27PM -0700, Justin T. Gibbs wrote: > >I've had no disk errors since we made the quirk entries. If my > >understanding is correct, the quirk entries were made because the > >controller didn't handle SCSI_STATUS_QUEUE_FULL correctly (in > >cam_periph.c)? > > > >But now I see the following, which I understand to be only > >informational messages, but still curious as to the source: > > > >Mar 16 11:20:17 fern /kernel: (pass0:bt0:0:0:0): tagged openings now 32 > >Mar 16 11:20:23 fern /kernel: (pass0:bt0:0:0:0): tagged openings now 2 > > My guess is that the controller is returning a data run error with a > residual of 0. See the comment at ~ line 1613 of sys/dev/buslogic/bt.c > or just search for "QUEUE_FULL" until you find the comment. If you > could stick a printf in there to verify this, that would be great. > In the mean time, I'm going to try to get some information out of > Mylex on this issue. > I inserted a printf in bt.c, please see patch below to verify it will print the necessary info. If it's not right, let me know and I'll make whatever adjustments you like. I don't know if it's important or not, but my bt.c was apparently somewhat older. I cvsup'ed the latest rev today before inserting the printf. Unfortunately, I didn't save a copy of the version I had before I ran cvsup, so I don't really know what changes were made. I know that my last previous cvsup/make world was March 6, and I *think* the date on the bt.c I was running was Dec 21. Anyway, I thought I should mention it in case any changes have been made in bt.c that would affect things that we're looking at now. I will send along any pertinent kernel output when it occurs. Thanks Justin. Chuck ------------------------------------------------------------------------------ *** bt.c.orig Sun Mar 21 17:15:01 1999 --- bt.c Sun Mar 21 18:01:19 1999 *************** *** 1608,1613 **** --- 1608,1616 ---- /* An error occured */ switch(bccb->hccb.btstat) { case BTSTAT_DATARUN_ERROR: + xpt_print_path(csio->ccb_h.path); + printf("BTSTAT_DATARUN_ERROR: data_len == %d\n", + bccb->hccb.data_len); if (bccb->hccb.data_len == 0) { /* * At least firmware 4.22, does this ------------------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 15:27:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 4619214CB6 for ; Sun, 21 Mar 1999 15:27:10 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id QAA22633; Sun, 21 Mar 1999 16:17:44 -0700 (MST) Date: Sun, 21 Mar 1999 16:17:44 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903212317.QAA22633@narnia.plutotech.com> To: Joerg Wunsch Cc: scsi@FreeBSD.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199903210039.RAA20800@narnia.plutotech.com> <19990321112050.05515@uriah.heep.sax.de> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19990321112050.05515@uriah.heep.sax.de> you wrote: > As Justin T. Gibbs wrote: > >> The only thing I recall about this was whether we should return >> ENOSPC or continually return 0 on EOM/EOT. If we decide to simply >> "pause" at EOM (i.e. return a short write or a 0 length write), >> then this is fine by me. > > So we are in violent agreement then? :) Yes. >> I still believe that returning a real >> error at EOT is correct. > > I could live with ENOSPC, but only iff no data have been written at > all in a particular request. Iff something has been written, the > `short write' is IMHO the correct way that's compatible with other > usage of write(2) throughout Unix, so the caller can be notified that > their request only partially succeeded (but succeeded so far). Yes. If anything is written, you must return the amount of data successfully written. The program will see the ENOSPC on the next attempted write. >> dump understands ENOSPC, and should work correctly if ENOSPC >> is still returned at EOM or EOT. > > Probably. I think part of the problem dump's algorithm doesn't > (didn't?) is that EIO has been reported, as opposed to ENOSPC. Yes, I modified dump around the time that CAM was integrated into the tree. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 16:26:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 10A1314D3D for ; Sun, 21 Mar 1999 16:26:14 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id TAA00711; Sun, 21 Mar 1999 19:25:49 -0500 (EST) Date: Sun, 21 Mar 1999 19:25:48 -0500 (EST) From: "Matthew N. Dodd" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903191941.MAA12517@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Justin T. Gibbs wrote: > >Seems kind of redundant. Unless of course CAM does this: > > > > at scbus2 target 5 lun 0 (pass15,pt0,se0) > > > >Which I hope it does. > > Which is what it will do. Indeed it did. (camcontrol devlist) at scbus2 target 5 lun 0 (se0,pass15,pt0) (dmesg) pt0 at dpt0 bus 0 target 5 lun 0 pt0: Fixed Processor SCSI-0 device se0 at dpt0 bus 0 target 5 lun 0 se0: Fixed Processor SCSI-0 device se0: Ethernet address: 00:00:1d:08:23:0c (ifconfig) se0: flags=8803 mtu 1500 inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:00:1d:08:23:0c Is there any way to issue multiple CCBs when I'm in XXstart? Currently I'm running the 'get_addr' command but would like to issue the 'add_proto' commands to enable IP etc (though the NetBSD driver adds protocols in the if IOCTL routine which I suppose I could do as well. Any reason I might see a panic in cam_periph_getccb() when called from XXregister()? (Actually the panic was in tsleep()). I attribute this to the device not actually having completed the XXregister routine and returning CAM_REQ_CMP. Is this the case? I'm not sure I completly understand the role of XXstart and XXdone. Am I to understand that all CCBs are dispatched and completed via these routines? Thanks. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 16:41:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 6BEA114CC3 for ; Sun, 21 Mar 1999 16:41:18 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id RAA94615; Sun, 21 Mar 1999 17:40:56 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903220040.RAA94615@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Sun, 21 Mar 1999 19:25:48 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Mar 1999 17:31:55 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Is there any way to issue multiple CCBs when I'm in XXstart? No. You must reschedule your device for I/O ccbs and wait for your start routine to be called again. >Currently I'm running the 'get_addr' command but would like to issue the >'add_proto' commands to enable IP etc (though the NetBSD driver adds >protocols in the if IOCTL routine which I suppose I could do as well. It should probably occur only once the device is enabled via an if IOCTL. >Any reason I might see a panic in cam_periph_getccb() when called from >XXregister()? (Actually the panic was in tsleep()). I attribute this to >the device not actually having completed the XXregister routine and >returning CAM_REQ_CMP. Is this the case? No. XXregister can be (and usually is) called from an interrupt context. You can't tsleep in an interrupt context. cam_periph_getccb() is intended for use in peripheral ioctl routines where you have a process context and need to wait for both a non-immediate CCB resource to perform your action and the action to complete (see cam_periph_runccb()) before returning/ completing the ioctl request. For most requests, you will be using CCB resources that our granted to you by the transport layer's resource scheduler (see xpt_schedule()) which are passed into your XXstart routine. >I'm not sure I completly understand the role of XXstart and XXdone. Am I >to understand that all CCBs are dispatched and completed via these >routines? Not all. Only ccbs with non-immediate opcodes are scheduled and so wind up in your XXstart and XXdone routine. This is to ensure card/bus/device/memory resource fairness for operations that consume these resources. The most commonly used non-immediate opcode is XPT_SCSI_IO, but there are others for bus or lun scanning and target mode that also fall into this category. Immediate operations can be performed by allocating a CCB of the appropriate type on the stack, filling in the CCB, executing it with xpt_action(), and then pulling status and other information from the CCB. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 16:48:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 48CB014F88 for ; Sun, 21 Mar 1999 16:48:16 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA63051; Sun, 21 Mar 1999 17:47:52 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903220047.RAA63051@panzer.plutotech.com> Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: from "Matthew N. Dodd" at "Mar 21, 1999 7:25:48 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Sun, 21 Mar 1999 17:47:52 -0700 (MST) Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Fri, 19 Mar 1999, Justin T. Gibbs wrote: > > >Seems kind of redundant. Unless of course CAM does this: > > > > > > at scbus2 target 5 lun 0 (pass15,pt0,se0) > > > > > >Which I hope it does. > > > > Which is what it will do. > > Indeed it did. > > (camcontrol devlist) > at scbus2 target 5 lun 0 (se0,pass15,pt0) > > (dmesg) > pt0 at dpt0 bus 0 target 5 lun 0 > pt0: Fixed Processor SCSI-0 device > se0 at dpt0 bus 0 target 5 lun 0 > se0: Fixed Processor SCSI-0 device > se0: Ethernet address: 00:00:1d:08:23:0c > > (ifconfig) > se0: flags=8803 mtu 1500 > inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 > ether 00:00:1d:08:23:0c Looks good. > Is there any way to issue multiple CCBs when I'm in XXstart? > > Currently I'm running the 'get_addr' command but would like to issue the > 'add_proto' commands to enable IP etc (though the NetBSD driver adds > protocols in the if IOCTL routine which I suppose I could do as well. What I would do, if you want to issue more than one SCSI command before completing the probe phase, is do a multi-state probe. i.e., when the first probe command completes successfully, just xpt_schedule() yourself again. You'll need to keep some state in the softc (generally softc->state) to know which probe phase you're in. When you complete all of the commands you want to issue in your probe phase, you can announce yourself. > Any reason I might see a panic in cam_periph_getccb() when called from > XXregister()? (Actually the panic was in tsleep()). I attribute this to > the device not actually having completed the XXregister routine and > returning CAM_REQ_CMP. Is this the case? No. The problem is that you cannot tsleep inside an interrupt handler. If you want a CCB, schedule yourself, via xpt_schedule(), to get a CCB. > I'm not sure I completly understand the role of XXstart and XXdone. Am I > to understand that all CCBs are dispatched and completed via these > routines? Not necessarily. That is one path that things can go in. In a disk driver, for instance, the upper level code calls the strategy routine. Then the strategy routine schedules the peripheral driver to get a CCB. When a slot becomes available, the driver's start routine is called, the driver dequeues the I/O transaction, stuffs it into a CCB, and then calls xpt_action(). When the I/O is done, the transport layer calls the peripheral driver's done() routine with the completed CCB. Another way to do things, if you have a process context (e.g., in your open(), ioctl(), and close() routines) is to use cam_periph_getccb() to get a CCB, and then run cam_periph_ccbwait() to wait for it to complete. The passthrough driver uses that strategy, as does the CD driver in its ioctl routines. The changer driver does most of its I/O via its ioctl routine. It only uses the start/done routines on probe. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 17:12:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 079FD15155 for ; Sun, 21 Mar 1999 17:12:53 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id UAA01139; Sun, 21 Mar 1999 20:12:33 -0500 (EST) Date: Sun, 21 Mar 1999 20:12:33 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903220047.RAA63051@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, Kenneth D. Merry wrote: > Not necessarily. That is one path that things can go in. In a disk > driver, for instance, the upper level code calls the strategy routine. > Then the strategy routine schedules the peripheral driver to get a CCB. > When a slot becomes available, the driver's start routine is called, the > driver dequeues the I/O transaction, stuffs it into a CCB, and then calls > xpt_action(). > > When the I/O is done, the transport layer calls the peripheral driver's > done() routine with the completed CCB. > > Another way to do things, if you have a process context (e.g., in your > open(), ioctl(), and close() routines) is to use cam_periph_getccb() to get > a CCB, and then run cam_periph_ccbwait() to wait for it to complete. The > passthrough driver uses that strategy, as does the CD driver in its ioctl > routines. > > The changer driver does most of its I/O via its ioctl routine. It only > uses the start/done routines on probe. Humm... Let me tell you what I'm trying to do and how I think I need to go about doing it and you guys can tell me if I've got an incomplete understanding of how things work. (simple port... not!) Sending a packet: The network layer calls ifp->if_start, which in my case is a routeine called 'se_if_start'. se_if_start() loops on IF_DEQUEUE() if the interface is currently up and not already IFF_OACTIVE. For each packet I aggregate the data into an linear tx buffer if it setup a ether_send CCB and somehow schedule it to be run (its not important that it be run 'now') This is the bit I'm fuzzy on. I can hang the aggregated buffers (1 per packet) off of a softc queue and xpt_schedule() myself and setup the CCBs in my se_cam_start() routine, issuing xpt_schedule()'s until there are not more tx buffers in the queue. Once the scsi ether_send CCBs complete I can free the tx buffers (having alread freed the mbufs the system passed the packetes to me in se_if_start()) or I can add them back to the queue and reschedule a transmit if the command failed. Is this the correct way to do things? I'll talk about the receive routine once I've got a good understanding of the flow of the TX routines. Thanks for the patience. The learning curve on CAM isn't as bad as I thought but its still not cake either. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 18: 7:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F9D15220 for ; Sun, 21 Mar 1999 18:05:55 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA63565; Sun, 21 Mar 1999 19:05:33 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903220205.TAA63565@panzer.plutotech.com> Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: from "Matthew N. Dodd" at "Mar 21, 1999 8:12:33 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Sun, 21 Mar 1999 19:05:33 -0700 (MST) Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > Humm... > > Let me tell you what I'm trying to do and how I think I need to go about > doing it and you guys can tell me if I've got an incomplete understanding > of how things work. (simple port... not!) > > Sending a packet: > > The network layer calls ifp->if_start, which in my case is a > routeine called 'se_if_start'. > > se_if_start() loops on IF_DEQUEUE() if the interface is currently > up and not already IFF_OACTIVE. > > For each packet I aggregate the data into an linear tx buffer if > it setup a ether_send CCB and somehow schedule it to be run (its > not important that it be run 'now') This is the bit I'm fuzzy on. > I can hang the aggregated buffers (1 per packet) off of a softc > queue and xpt_schedule() myself and setup the CCBs in my > se_cam_start() routine, issuing xpt_schedule()'s until there are > not more tx buffers in the queue. That sounds reasonable, I suppose. I guess you should call xpt_schedule() once for each transaction you need to send. > Once the scsi ether_send CCBs complete I can free the tx buffers > (having alread freed the mbufs the system passed the packetes to > me in se_if_start()) or I can add them back to the queue and > reschedule a transmit if the command failed. I'll show my ignorance about network drivers here... It looks/sounds like you can get multiple packets per invocation of se_if_start(). Each packet consists of one or more mbufs. You then cram the mbufs into one big buffer, that you have allocated, per packet. I think it might be better to wait until you have a CCB to send the buffer in before freeing the mbufs. It seems like it might be fairly easy for the system to queue lots of packets to the interface, and for you to fall behind in sending them. You may want to queue the *mbufs*, then schedule yourself for a CCB. In your CAM start() routine, you can grab one of your TX buffer(s), copy the data in, setup the CCB and xpt_action() the CCB. Does this thing support tagged queueing? You didn't include the transfer negotiation line in the dmesg output in your previous message. If it doesn't support tagged queueing, it will make things much easier, since you'll only have to have one transmit buffer to copy things into. (You'll only be able to have one oustanding transaction at a time.) I suppose this is a unique device, since you need driver-local storage space to put transactions in. > I'll talk about the receive routine once I've got a good understanding of > the flow of the TX routines. I'm curious to hear about the receive end of things. Unless this thing can act as an initiator as well as a target (and your HBA can do both as well), you'll have to be polling for incoming packets one way or another. > Thanks for the patience. The learning curve on CAM isn't as bad as I > thought but its still not cake either. Yeah, it isn't too bad. It'll eventually all make sense, you just have to understand what the various functions do. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 18:13: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D58415406 for ; Sun, 21 Mar 1999 18:13:07 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA63607; Sun, 21 Mar 1999 19:12:42 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903220212.TAA63607@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <19990321110510.38582@uriah.heep.sax.de> from J Wunsch at "Mar 21, 1999 11: 5:10 am" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 21 Mar 1999 19:12:42 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... > As Kenneth D. Merry wrote: > > > The issue isn't really whether it's "poor performance" or "poor for a wide > > drive", but whether the performance you're getting out of the drive is what > > the drive is capable of. > > Just FWIW, i've finally applied Ken's patches to camcontrol (*), and > tested my DCAS 34330 with various tagged queuing parameters. The > results seem to basically confirm the results in the audit-trail of PR > 10398, except i think the best balanced results are for 2 tags on my > drive. > > Note that the following is running on my /tmp partition which is at > about 80 % offset from the beginning of the drive. This probably > explains why the figures are slower than those in PR 10398 although > the raw data rate on the outer tracks (dd if=/dev/rda1 of=/dev/null) > is about the same. > > So 1 or 2 tags, i don't care that much after seeing this. > > NCR 53C810 10 MHz 8 bit > IBM DCAS-34330 S65A > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > t=32,qm=0 100 3969 96.7 4435 39.1 1891 21.0 4079 94.5 5754 47.5 84.2 6.6 > t=32,qm=1 100 3806 93.4 3167 27.4 1899 21.3 3911 91.1 5102 42.0 84.9 6.7 > t=2,qam=0 100 3889 97.1 5500 45.4 2184 23.2 4125 95.8 5748 47.5 84.1 6.7 > t=2,qam=1 100 3968 96.6 5408 46.8 2224 24.5 4209 97.6 5403 44.5 74.5 6.1 > t=1,qam=0 100 3975 96.7 5446 43.8 1875 19.7 4175 97.2 5663 45.3 78.5 6.2 > > `t' - number of tags > `qm', `qam' - queue algorithm modifier (0 - restricted reordering, > 1 - unrestricted reordering allowed; mode page 10) > > WCE = 1 for all tests (PR 10398 already confirms violently enough that > disabling the write cache is not a good idea) One question I have is this -- when you say 1 tag, did you do disable tagged queueing like this: camcontrol negotiate -n da -u 3 -T disable Otherwise, you won't be able to disable tagged queueing. Also, you'll probably want to make sure that the size of the file that bonnie writes out is somewhat larger than your RAM, to eliminate the effects of FreeBSD's cache... > (*) In order to prevent camcontrol from coredumping on my SONY SMO, i > had to apply this patch: > > --- camcontrol.c.orig Sun Mar 21 10:22:53 1999 > +++ camcontrol.c Sun Mar 21 10:58:14 1999 > @@ -1926,9 +1926,11 @@ > > fprintf(stdout, "%ssync parameter: %d\n", pathstr, > cts->sync_period); > - freq = scsi_calc_syncsrate(cts->sync_period); > - fprintf(stdout, "%sfrequencey: %d.%03dMHz\n", pathstr, > - freq / 1000, freq % 1000); > + if (cts->sync_period != 0) { > + freq = scsi_calc_syncsrate(cts->sync_period); > + fprintf(stdout, "%sfrequencey: %d.%03dMHz\n", pathstr, > + freq / 1000, freq % 1000); > + } > } > > if (cts->valid & CCB_TRANS_SYNC_OFFSET_VALID) > What does it print out for the sync parameter? My guess is that it must be 0 or something... From looking at scsi_calc_syncsrate(), it can't handle a sync paramter of 0. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 18:16: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id EFC5415119 for ; Sun, 21 Mar 1999 18:15:57 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA63620; Sun, 21 Mar 1999 19:15:16 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903220215.TAA63620@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: from Chuck Robey at "Mar 21, 1999 5:49:45 pm" To: chuckr@mat.net (Chuck Robey) Date: Sun, 21 Mar 1999 19:15:16 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chuck Robey wrote... > On Sun, 21 Mar 1999, J Wunsch wrote: > > > NCR 53C810 10 MHz 8 bit > > IBM DCAS-34330 S65A > > -------Sequential Output-------- ---Sequential Input-- --Random-- > > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > > t=32,qm=0 100 3969 96.7 4435 39.1 1891 21.0 4079 94.5 5754 47.5 84.2 6.6 > > t=32,qm=1 100 3806 93.4 3167 27.4 1899 21.3 3911 91.1 5102 42.0 84.9 6.7 > > t=2,qam=0 100 3889 97.1 5500 45.4 2184 23.2 4125 95.8 5748 47.5 84.1 6.7 > > t=2,qam=1 100 3968 96.6 5408 46.8 2224 24.5 4209 97.6 5403 44.5 74.5 6.1 > > t=1,qam=0 100 3975 96.7 5446 43.8 1875 19.7 4175 97.2 5663 45.3 78.5 6.2 > > Huh. I tried using Ken's camcontrol patches, but when I did that (and > thus enabled tagged queueing) the drive hung within 10 seconds of > beginning bonnie. Now I'm somewhat surprised, because without queueing > turned on, here's what I get from bonnie: > > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 6229 80.9 6213 34.9 2250 13.5 5711 79.7 6390 25.6 85.2 4.6 > > This looks quite a bit better than yours, so I'm wondering if I'd doing > something to skew the results? I have a 5400 RPM DCAS 34330W: Joerg did say that he was doing his test a good ways down the disk (like 80%). That could easily explain the difference in performance. > da1 at ncr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: Serial Number F3TX1813 > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > This was on a 100MB bonnie test. Caching can also explain things, depending on how much RAM you've got in your system. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 18:22:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AA3015171 for ; Sun, 21 Mar 1999 18:22:42 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA63695; Sun, 21 Mar 1999 19:22:18 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903220222.TAA63695@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990321165244.06249@uriah.heep.sax.de> from J Wunsch at "Mar 21, 1999 4:52:44 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 21 Mar 1999 19:22:18 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... > As Kenneth D. Merry wrote: > > > > Any chance that camcontrol could gaing the ability to remove a > > > device from the system? 'camcontrol detach' maybe? > > > I suppose that's possible, but I'd rather just fix things so that the > > da driver attaches properly. > > Nevertheless, `camcontrol detach' would be a great option. One of my > machines at work is (often) used to test random SCSI equipment before > shipping it to customers. A `detach' option would be nice there, > since it allowed for just making the device unknown again i've only > attached for the test, without affecting anything else. If you remove the device from the SCSI bus (assuming your bus topology can support it), camcontrol rescan will detect that the device has gone, and all peripheral driver instances that were attached to the device will go away. The passthrough device attaches to any device that will respond to an inquiry. So even if you don't have a 'normal' device compiled into the system that will attach to a given device, you can always talk to it via the pass(4) device. Justin and I talked a bit yesterday about making the da driver a little more lenient about what errors it will allow on attach. I'm not sure I'm convinced we should. We'll have to discuss it a little more. The only problem you're having, really, is that you've got a weird device that doesn't attach under certain circumstances. I think the only oustanding issue with that MO drive is getting the da driver to attach to it when the media isn't spun up. The patches I sent out fixed (at least for Matthew Dodd) the case where there's no media in the drive, and it worked ok when there was spinning media in the drive. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 18:27: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 6817D14BF8 for ; Sun, 21 Mar 1999 18:27:00 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id VAA03646; Sun, 21 Mar 1999 21:25:14 -0500 (EST) Date: Sun, 21 Mar 1999 21:25:14 -0500 (EST) From: Chuck Robey To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <199903220215.TAA63620@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, Kenneth D. Merry wrote: > > This looks quite a bit better than yours, so I'm wondering if I'd doing > > something to skew the results? I have a 5400 RPM DCAS 34330W: > > Joerg did say that he was doing his test a good ways down the disk (like > 80%). That could easily explain the difference in performance. > > > da1 at ncr0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: Serial Number F3TX1813 > > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > > > This was on a 100MB bonnie test. > > Caching can also explain things, depending on how much RAM you've got in > your system. OK, that's very likely, it's a 64M system. Would it be possible to compile (for test only) a kernel that only recognized, say, 12M, and run bonnie on that? Would setting MAXMEM in the kernel configuration do that? Would 12M be a reasonable value? Should I do the test in single-user, or multiuser? I'm offering to wedge my machine again, I must be drinking too much coffee! As far as where the file sits: /dev/da2e 1961715 898304 906474 50% /usr/local as you can see, it's only half full. What might I do to make the test more fair (as compared to Jorg's results? (private to Jorg: I don't know how to tickle the keyboard to get the diuresis(sp?), I can't spell your name any closer.) ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 18:40:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id A91A914FF4 for ; Sun, 21 Mar 1999 18:40:30 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA63860; Sun, 21 Mar 1999 19:39:53 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903220239.TAA63860@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: from Chuck Robey at "Mar 21, 1999 9:25:14 pm" To: chuckr@mat.net (Chuck Robey) Date: Sun, 21 Mar 1999 19:39:53 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chuck Robey wrote... > On Sun, 21 Mar 1999, Kenneth D. Merry wrote: > > > > This looks quite a bit better than yours, so I'm wondering if I'd doing > > > something to skew the results? I have a 5400 RPM DCAS 34330W: > > > > Joerg did say that he was doing his test a good ways down the disk (like > > 80%). That could easily explain the difference in performance. > > > > > da1 at ncr0 bus 0 target 1 lun 0 > > > da1: Fixed Direct Access SCSI-2 device > > > da1: Serial Number F3TX1813 > > > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > > > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > > > > > This was on a 100MB bonnie test. > > > > Caching can also explain things, depending on how much RAM you've got in > > your system. > > OK, that's very likely, it's a 64M system. Would it be possible to > compile (for test only) a kernel that only recognized, say, 12M, and run > bonnie on that? Would setting MAXMEM in the kernel configuration do > that? Would 12M be a reasonable value? Should I do the test in > single-user, or multiuser? I'm offering to wedge my machine again, I > must be drinking too much coffee! > > As far as where the file sits: > > /dev/da2e 1961715 898304 906474 50% /usr/local > > as you can see, it's only half full. What might I do to make the test > more fair (as compared to Jorg's results? You don't have to decrease the amount of RAM in your system. You should just try increasing the size of the file that bonnie writes out. The -s argument allows you to specify the size of the file in megabytes. As far as where you are in the disk, well, you're 50% down that partition, which is half the size of the disk. If that's the last partition you have on the disk, you're probably about 75% down the disk, which is close to where Joerg was. > (private to Jorg: I don't know how to tickle the keyboard to get the > diuresis(sp?), I can't spell your name any closer.) I used to be able to do it by typing alt-something, but alt doesn't seem to have any effect any more. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 19:11:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 021E914C24 for ; Sun, 21 Mar 1999 19:11:07 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id EAA14429 for freebsd-scsi@FreeBSD.ORG; Mon, 22 Mar 1999 04:10:47 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 0DE95884B; Mon, 22 Mar 1999 01:11:12 +0100 (CET) Date: Mon, 22 Mar 1999 01:11:12 +0100 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Message-ID: <19990322011112.A61015@keltia.freenix.fr> Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <19990321110510.38582@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: ; from Chuck Robey on Sun, Mar 21, 1999 at 05:49:45PM -0500 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5130 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Chuck Robey: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 6229 80.9 6213 34.9 2250 13.5 5711 79.7 6390 25.6 85.2 4.6 OK, here are my results, unfortunately for the IBM, the partition is not empty and not at the best place... I've tried with 2 & 32 tags and with WC (write cache) on & off. In truth, I'm fairly disappointed by the IBM drive... especially compared to the Conner one. NCR-810 card, K6/200 -=-=-=-=-=-=- Conner CFP1080S narrow, 31 tags (as reported by camcontrol), 5400 rpm -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1080S 100 4305 53.9 4194 15.6 2138 8.0 4298 34.2 4371 9.2 81.8 3.0 NCR-875 card (32 tags max.), K6/200. -=-=-=-=-=-=-=-=-=-=-=-=-=- DCAS-34330W, 32 tags, WCE=0, 5400 rpm -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 34330W 100 2604 33.0 2169 8.4 1910 8.1 5547 44.9 5362 12.9 116.8 4.0 DCAS-34330W, 32 tags, WCE=1 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 34330W 100 2927 37.1 2382 9.4 1933 8.3 5588 45.0 5724 13.9 116.0 3.9 DCAS-34330W, 2 tags, WCE=0 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 34330W 100 2021 25.4 1697 6.7 1989 8.1 5532 44.8 5661 13.6 117.4 3.8 DCAS 34330W, 2 tags, WCE=1 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 34330W 100 5358 69.2 5208 22.4 2348 9.4 5592 45.0 5717 13.8 116.4 3.7 Adaptec 7880 UW found on an Intel Providence card, 2x PPro. -=-=-=-=-=-=- Viking II, 63 tags, WCE=0, 7200 rpm -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU VikingII 128 8799 93.5 8318 34.6 3504 15.0 9497 91.8 10720 24.8 140.5 5.3 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 22:18:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B8A014D5C for ; Sun, 21 Mar 1999 22:18:44 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA03578; Mon, 22 Mar 1999 01:18:23 -0500 (EST) Date: Mon, 22 Mar 1999 01:18:22 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903220205.TAA63565@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, Kenneth D. Merry wrote: > That sounds reasonable, I suppose. I guess you should call xpt_schedule() > once for each transaction you need to send. After reading the rest of this post I need to xpt_schedule() in my if_start() and then in my cam_done() routine, since I shouldn't bother trying to setup multiple CCBs as they must be executed serialy. Is there any way of handing the CAM subsystem a list of CCBs to be executed or adding a CCB to the queue of runable CCBs? I'd like to submit CCBs to the queue, xpt_schedule() then pull the next available CCB to be executed, clean up after it in se_cam_done() and call xpt_schedule() again if there are still runable CCBs in the queue. > > Once the scsi ether_send CCBs complete I can free the tx buffers > > (having alread freed the mbufs the system passed the packetes to > > me in se_if_start()) or I can add them back to the queue and > > reschedule a transmit if the command failed. > > I'll show my ignorance about network drivers here... > > It looks/sounds like you can get multiple packets per invocation of > se_if_start(). Each packet consists of one or more mbufs. You then cram > the mbufs into one big buffer, that you have allocated, per packet. > > I think it might be better to wait until you have a CCB to send the buffer > in before freeing the mbufs. It seems like it might be fairly easy for the > system to queue lots of packets to the interface, and for you to fall > behind in sending them. That really depends on how much work I want to do at splnet() vs. splbio(). My thought was to de-queue and process the mbufs and return them to the system since I'll be able to allocate a buffer of the correct size for each packet. Its unfortunate that I can't get CAM to do a scatter/gather type thing and pass it a descriptor list that describes the location and length of each mbuf data element. Regardless, all I need do in se_cam_start() is setup the command (which involves calling cam_fill_csio() and call xpt_action() and I'm done with the packet. > You may want to queue the *mbufs*, then schedule yourself for a CCB. In your > CAM start() routine, you can grab one of your TX buffer(s), copy the data > in, setup the CCB and xpt_action() the CCB. I was planning on malloc()'ing them on the fly since I'll know how long they need to be. > Does this thing support tagged queueing? You didn't include the transfer > negotiation line in the dmesg output in your previous message. If it > doesn't support tagged queueing, it will make things much easier, since > you'll only have to have one transmit buffer to copy things into. (You'll > only be able to have one oustanding transaction at a time.) This is a fairly stupid device. No tagged queueing. > I suppose this is a unique device, since you need driver-local storage > space to put transactions in. Indeed. The NetBSD driver has one big horking buffer it doesn't free which I'm beginning to see the sense of. > > I'll talk about the receive routine once I've got a good understanding of > > the flow of the TX routines. > > I'm curious to hear about the receive end of things. Unless this > thing can act as an initiator as well as a target (and your HBA can do > both as well), you'll have to be polling for incoming packets one way > or another. Heh. Polling. The device has space for 10 packets of 1500 bytes each, but only 10 packets (regardless of size will be buffered) It will start dropping packets if the system can't keep up (poll and issue ether_recv commands fast enough). I've got a few ideas on how to implement this polling behavior but I'm afraid I can't convey them coherntly enough at this hour. Some manner of adaptive polling rate that takes into account # of packets returned by each ether_recv command, and the size of the packets. I'm not sure how I'm going to calculate overhead and interrupt latency but something will come to me or I'll settle for a gross hack or something. After all, this device really isn't all that pretty and is only serving as a diversion from working on Other Things. (eventually I have to get off my ass and resurrect my token ring test box and figure out my problems with the TMS380 driver.) > > Thanks for the patience. The learning curve on CAM isn't as bad as I > > thought but its still not cake either. > > Yeah, it isn't too bad. It'll eventually all make sense, you just have to > understand what the various functions do. But I never wanted to be a SCSI hacker! I just want to... to... -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 21 23:23: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caern.limax.com (we-24-130-40-67.we.mediaone.net [24.130.40.67]) by hub.freebsd.org (Postfix) with ESMTP id D397A14FE3; Sun, 21 Mar 1999 23:22:30 -0800 (PST) (envelope-from obrien@leonardo.net) Received: from mobrien.ni.net (localhost [127.0.0.1]) by caern.limax.com (8.9.2/8.9.2) with ESMTP id XAA00414; Sun, 21 Mar 1999 23:23:40 -0800 (PST) (envelope-from obrien@leonardo.net) Message-Id: <199903220723.XAA00414@caern.limax.com> To: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Subject: Odd messages Date: Sun, 21 Mar 1999 23:23:40 -0800 From: "Mike O'Brien" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ever since I upgraded to 3.1-RELEASE, I've occasionally been seeing bursts like this: Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): SCB 0x18 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Mar 21 20:01:22 caern /kernel: Unexpected busfree. LASTPHASE == 0xa0 Mar 21 20:01:22 caern /kernel: SEQADDR == 0x151 Mar 21 20:02:22 caern /kernel: (da0:ahc0:0:0:0): SCB 0xf - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Mar 21 20:02:22 caern /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Mar 21 20:02:22 caern /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Mar 21 20:02:22 caern /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Mar 21 20:02:22 caern /kernel: Unexpected busfree. LASTPHASE == 0xa0 Mar 21 20:02:22 caern /kernel: SEQADDR == 0x151 Mar 21 23:09:47 caern /kernel: (da0:ahc0:0:0:0): SCB 0x4 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc This is my hardware: Mar 21 23:15:30 caern /kernel: da0 at ahc0 bus 0 target 0 lun 0 Mar 21 23:15:30 caern /kernel: da0: Fixed Direct Access SCSI-2 device Mar 21 23:15:30 caern /kernel: da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled Mar 21 23:15:30 caern /kernel: da0: 2103MB (4308352 512 byte sectors: 64H 32S/T 2103C) Mar 21 23:15:30 caern /kernel: da1 at ahc0 bus 0 target 1 lun 0 Mar 21 23:15:30 caern /kernel: da1: Fixed Direct Access SCSI-2 device Mar 21 23:15:30 caern /kernel: da1: 10.0MB/s transfers (10.0MHz, offset 8) Mar 21 23:15:30 caern /kernel: da1: 1042MB (2134305 512 byte sectors: 64H 32S/T 1042C) It's an Adaptec 2940 with two drives as shown. Mostly, it happens while the system is idle and when I get back, everything is OK. This last time, the disk system was frozen and I had to Hit The Big Black Button. Things rebooted normally. Ordinarily I'd say the drive is wonky, but my suspicions are aroused: things ran fine under 2.2.6, and this bad stuff started happening as soon as I installed 3.1. Any takers? Mike O'Brien To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 1:57:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id E37EA15097 for ; Mon, 22 Mar 1999 01:56:23 -0800 (PST) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id LAA25810; Mon, 22 Mar 1999 11:02:53 +0100 (CET) Message-Id: <199903221002.LAA25810@rt2.synx.com> Date: Mon, 22 Mar 1999 10:54:34 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: cvs commit: src/sys/cam cam_xpt.c To: roberto@keltia.freenix.fr Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <19990322011112.A61015@keltia.freenix.fr> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22 Mar, Ollivier Robert wrote: > According to Chuck Robey: >> -------Sequential Output-------- ---Sequential Input-- --Random-- >> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- >> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU >> 100 6229 80.9 6213 34.9 2250 13.5 5711 79.7 6390 25.6 85.2 4.6 > > OK, here are my results, unfortunately for the IBM, the partition is not > empty and not at the best place... I've tried with 2 & 32 tags and with WC > (write cache) on & off. > > In truth, I'm fairly disappointed by the IBM drive... especially compared > to the Conner one. > The DCAS-34330xxx are the poorest disks money can buy. Your numbers are correct. RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 2: 1: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 9C92D151C0 for ; Mon, 22 Mar 1999 02:00:49 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 20329 invoked by uid 1001); 22 Mar 1999 10:00:26 +0000 (GMT) To: remy@synx.com Cc: roberto@keltia.freenix.fr, freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 22 Mar 1999 10:54:34 +0100 (CET)" References: <199903221002.LAA25810@rt2.synx.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 22 Mar 1999 11:00:26 +0100 Message-ID: <20327.922096826@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > In truth, I'm fairly disappointed by the IBM drive... especially compared > > to the Conner one. > > The DCAS-34330xxx are the poorest disks money can buy. Your numbers are > correct. I have to disagree. These drives were very good when they first came out. That doesn't mean I'd buy them today :-) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 2:14:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id 0E8D614BD0 for ; Mon, 22 Mar 1999 02:14:00 -0800 (PST) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id LAA25887; Mon, 22 Mar 1999 11:20:37 +0100 (CET) Message-Id: <199903221020.LAA25887@rt2.synx.com> Date: Mon, 22 Mar 1999 11:12:19 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: cvs commit: src/sys/cam cam_xpt.c To: sthaug@nethelp.no Cc: roberto@keltia.freenix.fr, freebsd-scsi@FreeBSD.ORG In-Reply-To: <20327.922096826@verdi.nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22 Mar, sthaug@nethelp.no wrote: >> > In truth, I'm fairly disappointed by the IBM drive... especially compared >> > to the Conner one. >> >> The DCAS-34330xxx are the poorest disks money can buy. Your numbers are >> correct. > > I have to disagree. These drives were very good when they first came > out. That doesn't mean I'd buy them today :-) > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no Hum.... I have to check the release date but, in the mean time i got 10 of them, i was using DGVS 9ZX/10K and Seagate 18G/10K and that was another music... (However, i found seagate far to be reliable). I'm now building an experimental machine with 12x18G Ultrastar2 (with 4MB cache) and ccd. Honestly, DCAS and DDRS series are suffering from slow SCSI processing and poor tagged-qeueing. Softupdate and Write-cacheing helps a lot (I know. I wouldn't be using WC with SoftUpdates). PS: I also updated Adaptec BIOS to 1.34.2 on a machine that periodically crashed and problems disapeared. I do not understand why since i always believed that the aic driver takes full control of the card. Can someone explain ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 9:55:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id 4F4A614CC9; Mon, 22 Mar 1999 09:55:06 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id MAA05667; Mon, 22 Mar 1999 12:48:11 -0500 (EST) Message-ID: <36F681D6.E2234C61@enc.edu> Date: Mon, 22 Mar 1999 12:45:58 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG Subject: fix for amanda chg-chio script to eject tape References: <36F67829.6C6CB4CA@enc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In order to get chg-chio from amanda 2.4.1p1 to work happily under FreeBSD-3_stable I had to add a few statements to the Unload subroutine to eject the tape prior to calling the chio command to move it back to its slot. Did the ch(4) driver used to handle the tape ejection step itself? If not, then I'm not sure I understand how the chio-script ever worked, since _somehow_ the st/sa tape driver needs to be told to release the tape before the changer can play with it. If this is true (that the ch(4) driver used to, but no longer does, handle the eject step) then the chio-chg as present in the amanda distribution probably should be patched... or at least the FreeBSD amanda port should include the patch to be applied at build time. Here's the diff to chg-chio: 240a241,244 > system ("/usr/bin/mt -f $tapeDevice rew"); > system ("/usr/bin/mt -f $tapeDevice offl"); > sleep(1); > I'm not sure if the sleep or separate rewind and offl steps are needed, just thought I'd be careful. Thoughts? --- ------------------------------------------------------------------------- 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 Mon Mar 22 10: 5:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id B88791531F for ; Mon, 22 Mar 1999 10:05:30 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id LAA31827; Mon, 22 Mar 1999 11:04:57 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903221804.LAA31827@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Kenneth D. Merry" , gibbs@plutotech.com, scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Sun, 21 Mar 1999 20:12:33 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Mar 1999 10:55:56 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Humm... > >Let me tell you what I'm trying to do and how I think I need to go about >doing it and you guys can tell me if I've got an incomplete understanding >of how things work. (simple port... not!) > >Sending a packet: > > The network layer calls ifp->if_start, which in my case is a > routeine called 'se_if_start'. > > se_if_start() loops on IF_DEQUEUE() if the interface is currently > up and not already IFF_OACTIVE. > > For each packet I aggregate the data into an linear tx buffer if > it setup a ether_send CCB and somehow schedule it to be run (its > not important that it be run 'now') This is the bit I'm fuzzy on. > I can hang the aggregated buffers (1 per packet) off of a softc > queue and xpt_schedule() myself and setup the CCBs in my > se_cam_start() routine, issuing xpt_schedule()'s until there are > not more tx buffers in the queue. Although in NetBSD there is a requirement for you to aggregate the data into a linear buffer as that is all that the SCSI subsystem understands, this should not be required in CAM. CAM allows you to specify an S/G list representing your data as either virtual addresses or 'bus addresses'. The virtual segment list is not currently implemented in all drivers, but I'd be happy to do it if you have an application that can test the code. This should be much more efficient than copying the data again. As for scheduling, you should schedule yourself in your ether_start routine as new work is queued and in your cam peripheral start routine after sending off some work and determining that you still have work left to perform. > Once the scsi ether_send CCBs complete I can free the tx buffers > (having alread freed the mbufs the system passed the packetes to > me in se_if_start()) or I can add them back to the queue and > reschedule a transmit if the command failed. If the command failed, you can simply reuse both the CCB and the tx buffers immediately. If the command succeeds, you must release the CCB back to the XPT CCB scheduler (xpt_release_ccb) to allow for fairness. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 10: 8:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id 1210214C3E for ; Mon, 22 Mar 1999 10:08:20 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id NAA06381; Mon, 22 Mar 1999 13:01:31 -0500 (EST) Message-ID: <36F684F6.FF645E3B@enc.edu> Date: Mon, 22 Mar 1999 12:59:19 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, kingsled@enc.edu Subject: ch(4) driver is noisy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Every time I use the chio command to control my tape library (MediaLogic) I get a kernal message or the sort Mar 22 12:29:42 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail != count I'm not exactly sure what's causing this and was hoping someone here more familiar with the ch(4) code could comment. ch(4) and chio(1) seem to work find except for filling my logs with this error message. Is this likely to be a bug in ch(4) or a deficiency in the way my tape changer implements support for the associated SCSI commands? If the latter, what's the best way to quiet these error messages (assuming I can't get the company to fix it). This isn't the end of the world... just annoying... Here's the output of chio status picker 0: slot 0: slot 1: slot 2: slot 3: slot 4: slot 5: slot 6: slot 7: slot 8: slot 9: slot 10: slot 11: slot 12: slot 13: slot 14: slot 15: slot 16: slot 17: slot 18: slot 19: slot 20: slot 21: slot 22: slot 23: slot 24: slot 25: slot 26: slot 27: portal 0: drive 0: 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 Mon Mar 22 10: 9:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from linteuto.teuto.de (linteuto.teuto.de [194.77.23.26]) by hub.freebsd.org (Postfix) with ESMTP id 3341015626 for ; Mon, 22 Mar 1999 10:08:37 -0800 (PST) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [212.8.203.81]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id TAA21823 for ; Mon, 22 Mar 1999 19:08:13 +0100 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id TAA01105 for scsi@FreeBSD.ORG; Mon, 22 Mar 1999 19:08:15 +0100 (MET) From: Martin Husemann Message-Id: <199903221808.TAA01105@rumolt.teuto.de> Subject: Quirk entry for Caliper tape drive To: scsi@FreeBSD.ORG Date: Mon, 22 Mar 1999 19:08:14 +0100 (MET) Organization: Crusaders Catering Services Inc. ;-) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I tried to boot FreeBSD 3.1-19990220-STABLE on a machine - which panics the kernel (division by zero) while probing for SCSI devices (I reported this here a few weeks ago). Joerg Wunsch suggested the appended patch, which solves the problem on this machine by removing the cause - if someone want's to look at the symptom (i.e. the division) so the kernel can cope with this kind of devices without quirks, I can easily try patches... Martin *** cam_xpt.c.orig Thu Jan 21 00:00:31 1999 --- cam_xpt.c Mon Mar 22 11:37:12 1999 *************** *** 400,409 **** --- 400,419 ---- " TDC 3600", "U07:" }, CAM_QUIRK_NOSERIAL, /*mintags*/0, /*maxtags*/0 }, { + /* + * Would repond to all LUNs if asked for. + */ + { + T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "CALIPER", + "CP150", "*" + }, + CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 + }, + { /* Default tagged queuing parameters for all devices */ { T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED, /*vendor*/"*", /*product*/"*", /*revision*/"*" }, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 10:16:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 1A05614BD4 for ; Mon, 22 Mar 1999 10:16:56 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id LAA32198; Mon, 22 Mar 1999 11:16:30 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903221816.LAA32198@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Kenneth D. Merry" , gibbs@plutotech.com, scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Mon, 22 Mar 1999 01:18:22 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Mar 1999 11:07:29 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Is there any way of handing the CAM subsystem a list of CCBs to be >executed or adding a CCB to the queue of runable CCBs? I'd like to submit >CCBs to the queue, xpt_schedule() then pull the next available CCB to be >executed, clean up after it in se_cam_done() and call xpt_schedule() again >if there are still runable CCBs in the queue. xpt_schedule() doesn't schedule the I/O to the controller, it schedules you to receive CCB resources. It seems that the networking stack already provides you with a convenient queue of packets for you to consume as CCBs become available. So, instead of doing what a conventional ethernet driver does in it's ether-start routine, simply call xpt_schedule(). In your CAM peripheral start routine, remove a single packet, stuff it into a CCB, send it with xpt_action(), and reschedule yourself if the packet queue is not empty. >That really depends on how much work I want to do at splnet() vs. >splbio(). You won't be doing any work at splbio(). You should register your device as a 'network device' with CAM and use splnet() at all times. I had ethernet devices in mind when I setup the interrupt framework for CAM. >My thought was to de-queue and process the mbufs and return them to the >system since I'll be able to allocate a buffer of the correct size for >each packet. Its unfortunate that I can't get CAM to do a scatter/gather >type thing and pass it a descriptor list that describes the location and >length of each mbuf data element. But you can. Give me a little time, and I'll finish the support for this in the bus dma framework and hook it up in the controller drivers. You will need to set the CAM_SCATTER_VALID flag in the ccb-ccb_h.flags and not set the CAM_SG_LIST_PHYS flag. S/G lists with physical addresses (really bus addresses) are already supported by all controllers. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 10:22:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EF65814D68; Mon, 22 Mar 1999 10:22:27 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA19617; Mon, 22 Mar 1999 10:21:49 -0800 Date: Mon, 22 Mar 1999 10:21:49 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Charles Owens Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG, Brian Topping Subject: Re: fix for amanda chg-chio script to eject tape In-Reply-To: <36F681D6.E2234C61@enc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What did the code in amanda used to be? At any rate, the 3.X SA driver does a PREVENT at open time, and an ALLOW at close- pretty much unconditionally. Some changers allow you to eject the tape whether the drive has it prevented or not, so which changers are you referring to? Also, an 'offline' does a 'rewind' too, so you only have to do one- but now that I think about it- *this* particular bit of additional code can cause you some problems for the changers that may be (incorrectly) strapped to then sequentially load the next cardtridge. So- could you give a couple more details as to what h/w you're working with, and maybe use a CAMDEBUG kernel and do a camcontrol -Ic on the tape and/or changer device to see why you needed to get the tape ejected? > In order to get chg-chio from amanda 2.4.1p1 to work happily under > FreeBSD-3_stable I had to add a few statements to the Unload subroutine to > eject the tape prior to calling the chio command to move it back to its slot. > > Did the ch(4) driver used to handle the tape ejection step itself? If not, > then I'm not sure I understand how the chio-script ever worked, since > _somehow_ the st/sa tape driver needs to be told to release the tape before > the changer can play with it. > > If this is true (that the ch(4) driver used to, but no longer does, handle > the eject step) then the chio-chg as present in the amanda distribution > probably should be patched... or at least the FreeBSD amanda port should > include the patch to be applied at build time. > > Here's the diff to chg-chio: > > 240a241,244 > > system ("/usr/bin/mt -f $tapeDevice rew"); > > system ("/usr/bin/mt -f $tapeDevice offl"); > > sleep(1); > > > > I'm not sure if the sleep or separate rewind and offl steps are needed, just > thought I'd be careful. > > Thoughts? > --- > ------------------------------------------------------------------------- > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 11: 8: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 59B27152A1 for ; Mon, 22 Mar 1999 11:08:01 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA19802; Mon, 22 Mar 1999 11:07:22 -0800 Date: Mon, 22 Mar 1999 11:07:22 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Martin Husemann Cc: scsi@FreeBSD.ORG Subject: Re: Quirk entry for Caliper tape drive In-Reply-To: <199903221808.TAA01105@rumolt.teuto.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Do you know where (in which routine) it paniced? On Mon, 22 Mar 1999, Martin Husemann wrote: > I tried to boot FreeBSD 3.1-19990220-STABLE on a machine - which panics the > kernel (division by zero) while probing for SCSI devices (I reported this > here a few weeks ago). > > Joerg Wunsch suggested the appended patch, which solves the problem on > this machine by removing the cause - if someone want's to look at the > symptom (i.e. the division) so the kernel can cope with this kind of > devices without quirks, I can easily try patches... > > > Martin > > *** cam_xpt.c.orig Thu Jan 21 00:00:31 1999 > --- cam_xpt.c Mon Mar 22 11:37:12 1999 > *************** > *** 400,409 **** > --- 400,419 ---- > " TDC 3600", "U07:" > }, > CAM_QUIRK_NOSERIAL, /*mintags*/0, /*maxtags*/0 > }, > { > + /* > + * Would repond to all LUNs if asked for. > + */ > + { > + T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "CALIPER", > + "CP150", "*" > + }, > + CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 > + }, > + { > /* Default tagged queuing parameters for all devices */ > { > T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED, > /*vendor*/"*", /*product*/"*", /*revision*/"*" > }, > > > 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 Mar 22 11: 9:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id EE8FA15074 for ; Mon, 22 Mar 1999 11:09:16 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA10259; Mon, 22 Mar 1999 14:08:52 -0500 (EST) Date: Mon, 22 Mar 1999 14:08:52 -0500 (EST) From: "Matthew N. Dodd" To: "Justin T. Gibbs" Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903221816.LAA32198@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Justin T. Gibbs wrote: > >That really depends on how much work I want to do at splnet() vs. > >splbio(). > > You won't be doing any work at splbio(). You should register your > device as a 'network device' with CAM and use splnet() at all times. Ah. Sounds like a plan. I wondered what sort of silliness I would run into trying to run different parts of the driver at different priority levels. > I had ethernet devices in mind when I setup the interrupt framework > for CAM. You're sick man. :) > >My thought was to de-queue and process the mbufs and return them to the > >system since I'll be able to allocate a buffer of the correct size for > >each packet. Its unfortunate that I can't get CAM to do a scatter/gather > >type thing and pass it a descriptor list that describes the location and > >length of each mbuf data element. > > But you can. Give me a little time, and I'll finish the support for this > in the bus dma framework and hook it up in the controller drivers. You > will need to set the CAM_SCATTER_VALID flag in the ccb-ccb_h.flags and > not set the CAM_SG_LIST_PHYS flag. S/G lists with physical addresses > (really bus addresses) are already supported by all controllers. Where might I see examples of this in action, or better yet, docs describing its use? This ability will greatly reduce the overhead of transmitting a packet. (Not that this device doesn't suck in other ways.) -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 11:12:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 5F20B15074 for ; Mon, 22 Mar 1999 11:12:25 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id MAA26990; Mon, 22 Mar 1999 12:02:58 -0700 (MST) Date: Mon, 22 Mar 1999 12:02:58 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903221902.MAA26990@narnia.plutotech.com> To: Charles Owens Cc: scsi@FreeBSD.org Subject: Re: ch(4) driver is noisy X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <36F684F6.FF645E3B@enc.edu> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <36F684F6.FF645E3B@enc.edu> you wrote: > Every time I use the chio command to control my tape library > (MediaLogic) I get a kernal message or the sort > > Mar 22 12:29:42 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail != count Hmm. This will take a little more investigation on my part to see how the code is supposed to work. It seems that chio is not requesting the same number of elements to be reported as known to your changer device. Can you apply this patch which will instrument the code and help me figure out what is going on. -- Justin ==== //depot/cam/sys/cam/scsi/scsi_ch.c#18 - /a/perforce/src/sys/cam/scsi/scsi_ch.c ==== *** /tmp/tmp.26982.0 Mon Mar 22 12:02:10 1999 --- /a/perforce/src/sys/cam/scsi/scsi_ch.c Mon Mar 22 12:02:02 1999 *************** *** 1189,1195 **** if (avail != cesr->cesr_element_count) { xpt_print_path(periph->path); ! printf("warning, READ ELEMENT STATUS avail != count\n"); } user_data = (struct changer_element_status *) --- 1189,1196 ---- if (avail != cesr->cesr_element_count) { xpt_print_path(periph->path); ! printf("warning, READ ELEMENT STATUS avail(%d) != count(%d)\n", ! avail, cesr->cesr_element_count); } user_data = (struct changer_element_status *) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 11:22: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rs4s1.datacenter.cha.cantv.net (rs4s1.datacenter.cha.cantv.net [200.44.32.54]) by hub.freebsd.org (Postfix) with ESMTP id 33F7E14C26 for ; Mon, 22 Mar 1999 11:04:43 -0800 (PST) (envelope-from alvaro@cantv.net) Received: from aec.cantv.net (ws-67.chacao-01.int.cantv.net [200.44.44.83]) by rs4s1.datacenter.cha.cantv.net (8.9.1a/8.9.1/1.0) with SMTP id PAA17770 for ; Mon, 22 Mar 1999 15:04:21 -0400 (VET) Message-Id: <3.0.1.32.19990322145829.0302c7a0@pop.cantv.net> X-Sender: alvaro@pop.cantv.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 22 Mar 1999 14:58:29 -0400 To: freebsd-scsi@freebsd.org From: Alvaro Carvajal Subject: Tag Enable on an Adaptec 2944UW Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. We have setup various FreeBSd boxes running 2.2.6, connected to BoxHill Turbo 5300 RAID Systems. We're using Adaptec 2944UW scsi cards to connect to the RAID Systems and have the following options set on the kernel file: options AHC_TAGENABLE options AHC_ALLOW_MEMIO We were looking for an option to control the number of scsi commands that can be queued. I know that in Solaris 2.6, you can do it by modifying the /etc/system file, adding this line: set sd:sd_max_throttle = 32 Is there a way to do the same on FreeBSD? Thanks in advance. -alvaro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 11:34:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id D04EA150D2; Mon, 22 Mar 1999 11:34:13 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id OAA11489; Mon, 22 Mar 1999 14:27:16 -0500 (EST) Message-ID: <36F6990E.1E5026DD@enc.edu> Date: Mon, 22 Mar 1999 14:25:03 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG, Brian Topping Subject: Re: fix for amanda chg-chio script to eject tape References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > What did the code in amanda used to be? Below is the Unload subroutine from the chg-chio script (Perl). I inserted my commands to eject the tape just before the 'if' statement. sub Unload { my($tape) = @_; # # Unload the tape from drive 0 and put it into the slot specified by # $tape. # if ( system("/bin/chio -f $changerDevice move drive 0 slot ".($tape-1)." ") ) { print "$progname: cannot '/bin/chio -f $changerDevice move' tape $tape from drive 0\n"; exit(2); } } > At any rate, the 3.X SA driver does a PREVENT at open time, and an ALLOW > at close- pretty much unconditionally. > > Some changers allow you to eject the tape whether the drive has it > prevented or not, so which changers are you referring to? > Wow... is the SA driver okay with a changer dong this? I'd made an assumption that this wasn't cool. Okay... then the chg-chio code as is makes sense for this sort of changer... but not mine. The system I'm using is a 28-tape changer from a company called MediaLogic. It has a Sony AIT-1 drive (which, since sa(4) doesn't know the AIT extended features, is being treated like just a big 8mm drive). Once a tape is inserted into the drive it is completely beyond the reach of the changer. When the tape is ejected by the OS, it hangs out in this intermediate space from which the changer may come by and grab it. > > Also, an 'offline' does a 'rewind' too, so you only have to do one- but > now that I think about it- *this* particular bit of additional code can > cause you some problems for the changers that may be (incorrectly) > strapped to then sequentially load the next cardtridge. > > So- could you give a couple more details as to what h/w you're working > with, and maybe use a CAMDEBUG kernel and do a camcontrol -Ic on the tape > and/or changer device to see why you needed to get the tape ejected? Is what I've told you above good for now? Let me know if you need more and I'll do this camcontrol thing (but it'll take me a bit). Thanks! Charles > > > In order to get chg-chio from amanda 2.4.1p1 to work happily under > > FreeBSD-3_stable I had to add a few statements to the Unload subroutine to > > eject the tape prior to calling the chio command to move it back to its slot. > > > > Did the ch(4) driver used to handle the tape ejection step itself? If not, > > then I'm not sure I understand how the chio-script ever worked, since > > _somehow_ the st/sa tape driver needs to be told to release the tape before > > the changer can play with it. > > > > If this is true (that the ch(4) driver used to, but no longer does, handle > > the eject step) then the chio-chg as present in the amanda distribution > > probably should be patched... or at least the FreeBSD amanda port should > > include the patch to be applied at build time. > > > > Here's the diff to chg-chio: > > > > 240a241,244 > > > system ("/usr/bin/mt -f $tapeDevice rew"); > > > system ("/usr/bin/mt -f $tapeDevice offl"); > > > sleep(1); > > > > > > > I'm not sure if the sleep or separate rewind and offl steps are needed, just > > thought I'd be careful. > > > > Thoughts? > > --- > > ------------------------------------------------------------------------- > > 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 > > -- --- ------------------------------------------------------------------------- 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 Mon Mar 22 12:47:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 69B9E1519C for ; Mon, 22 Mar 1999 12:47:28 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id NAA68154; Mon, 22 Mar 1999 13:46:56 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903222046.NAA68154@panzer.plutotech.com> Subject: Re: Tag Enable on an Adaptec 2944UW In-Reply-To: <3.0.1.32.19990322145829.0302c7a0@pop.cantv.net> from Alvaro Carvajal at "Mar 22, 1999 2:58:29 pm" To: alvaro@cantv.net (Alvaro Carvajal) Date: Mon, 22 Mar 1999 13:46:56 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alvaro Carvajal wrote... > Hello. > > We have setup various FreeBSd boxes running 2.2.6, connected > to BoxHill Turbo 5300 RAID Systems. We're using Adaptec 2944UW > scsi cards to connect to the RAID Systems and have the > following options set on the kernel file: > > options AHC_TAGENABLE > options AHC_ALLOW_MEMIO > > We were looking for an option to control the number of scsi > commands that can be queued. > > I know that in Solaris 2.6, you can do it by modifying the > /etc/system file, adding this line: > > set sd:sd_max_throttle = 32 > > Is there a way to do the same on FreeBSD? Sort of, although it's a hard coded value in the sd driver. It would be a lot easier if you upgrade to FreeBSD 3.1. FreeBSD 3.1 will queue as many commands to the RAID array as it can handle. 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 Mar 22 13: 4:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3815515177 for ; Mon, 22 Mar 1999 13:04:10 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id VAA00794; Mon, 22 Mar 1999 21:03:50 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA05087; Mon, 22 Mar 1999 14:03:27 -0700 (MST) Message-Id: <199903222103.OAA05087@harmony.village.org> To: "Matthew N. Dodd" Subject: Re: CAM entry point for SCSI-to-Ethernet device. Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Mar 1999 14:08:52 EST." References: Date: Mon, 22 Mar 1999 14:03:27 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message "Matthew N. Dodd" writes: : > I had ethernet devices in mind when I setup the interrupt framework : > for CAM. : : You're sick man. :) I wonder if terminal devices would fit into this framework... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 14: 2:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id C62AD155CB for ; Mon, 22 Mar 1999 14:02:14 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA68733; Mon, 22 Mar 1999 15:01:41 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903222201.PAA68733@panzer.plutotech.com> Subject: Re: 3.0 installs, 3.1 won't In-Reply-To: <87vhfuhccv.fsf@gamera.hws> from Hal Snyder at "Mar 21, 1999 1:27:44 pm" To: DrXyzzy@mediaone.net (Hal Snyder) Date: Mon, 22 Mar 1999 15:01:41 -0700 (MST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hal Snyder wrote... > I'm sending this in on behalf of a friend; it seems to be a SCSI problem. > > The motherboard and peripherals are about 1 year old. The Walnut > Creek FreeBSD-3.0 CD installs/runs just fine. NT4Sp4 runs, well, as > well as you'd expect it to. > > Copying files from the 3.1 CD seems to be almost twice as fast as the > install from 3.0, but after about 30% of the way into /bin it stalls > with repeated occurrences of "Unexpected busfree. LASTPHASE == 0xa0", > never recovering. > > Hardware: > > 1. Tyan S1696-DLUA motherboard (dual P-II 300's, Adaptec 7895 dual UWSCSI, etc.) > AMI BIOS > Adaptec BIOS V1.32 > Note: control-A related settings follow: > AIC-7895 @ BUS: 00h Device: 0Fh Channel: A IRQ10 E800h > AIC-7895 @ BUS: 00h Device: 0Fh Channel: B IRQ11 EC00h > H/A SCSI ID=7 > Termination = Auto > Parity = Enabled > Sync = Yes > Tranfer rate 40MB/sec max. > Initiate Wide = Yes > Reset SCSI at IC Init = Enabled > Extended BIOS Translation = Enabled > Host Adapter BIOS = Enabled > Removable Support = Boot Only > BIOS Support for Bootable CD = Enabled > BIOS Support for INT13 Extensions = Enabled > > 2. IBM DGVS09U UltraStar 9ZX 9.1GB 10,000 rpm UWSCSI drive > On channel B as SCSI ID 0 (wide) > > 3. Plextor PX-32i Ultraplex USCSI interface CD drive > On channel A as SCSI ID 2 (narrow) - This could be cabling or termination. - It could be that the drive is dying. - It could be a driver bug. Does FreeBSD 3.0 still install okay? Perhaps it would be better to install 3.0 and update via cvsup/make buildworld/make installworld to the latest -stable. There have been some Adaptec driver fixes since 3.1 went out. If you'd rather go with a release/snapshot, you could try the latest 3.1-STABLE snapshot from here: ftp://releng3.FreeBSD.ORG/pub/FreeBSD/snapshots/i386/ 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 Mar 22 14:16:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D21714E6F; Mon, 22 Mar 1999 14:16:37 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA68834; Mon, 22 Mar 1999 15:16:05 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903222216.PAA68834@panzer.plutotech.com> Subject: Re: Odd messages In-Reply-To: <199903220723.XAA00414@caern.limax.com> from "Mike O'Brien" at "Mar 21, 1999 11:23:40 pm" To: obrien@leonardo.net (Mike O'Brien) Date: Mon, 22 Mar 1999 15:16:05 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike O'Brien wrote... > Ever since I upgraded to 3.1-RELEASE, I've occasionally been > seeing bursts like this: > > Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): SCB 0x18 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB > Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent > Mar 21 20:01:22 caern /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Mar 21 20:01:22 caern /kernel: Unexpected busfree. LASTPHASE == 0xa0 > Mar 21 20:01:22 caern /kernel: SEQADDR == 0x151 [ ... ] > > Mar 21 23:15:30 caern /kernel: da0 at ahc0 bus 0 target 0 lun 0 > Mar 21 23:15:30 caern /kernel: da0: Fixed Direct Access SCSI-2 device > Mar 21 23:15:30 caern /kernel: da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > Mar 21 23:15:30 caern /kernel: da0: 2103MB (4308352 512 byte sectors: 64H 32S/T 2103C) [ ... ] > It's an Adaptec 2940 with two drives as shown. > > Mostly, it happens while the system is idle and when I get > back, everything is OK. This last time, the disk system was frozen > and I had to Hit The Big Black Button. Things rebooted normally. > > Ordinarily I'd say the drive is wonky, but my suspicions are > aroused: things ran fine under 2.2.6, and this bad stuff started > happening as soon as I installed 3.1. Any takers? This is most likely a drive firmware problem, although it could be cabling or termination. And the system wasn't completely idle when it happened. The 'timed out while idle' message means that a command from the da(4) driver timed out and there was nothing else going on at the time. The timeout for reads and writes from the da driver is 60 seconds. So if the drive doesn't respond in that period of time, something is definitely wrong. What is a VP32210? I don't see that anywhere on Quantum's web site listing of various model numbers. Probably the reason it happens on 3.1 and not on 2.2.6 is that CAM loads the disks a whole lot more than the old SCSI layer did. I suspect that this is a firmware problem, since I've seen other Quantum disks with the same symptoms. The most famous example is the Quantum Atlas II with LXY4 or older firmware. (They fixed that problem in the LYK8 firmware.) 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 Mar 22 14:32:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from shadows.aeon.net (shadows.aeon.net [195.197.32.30]) by hub.freebsd.org (Postfix) with ESMTP id 2705915033 for ; Mon, 22 Mar 1999 14:32:43 -0800 (PST) (envelope-from bsdscsi@shadows.aeon.net) Received: (from bsdscsi@localhost) by shadows.aeon.net (8.9.1/8.8.3) id AAA05925 for freebsd-scsi@freebsd.org; Tue, 23 Mar 1999 00:33:22 +0200 (EET) From: mika ruohotie Message-Id: <199903222233.AAA05925@shadows.aeon.net> Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903160625.XAA23822@panzer.plutotech.com> from "Kenneth D. Merry" at "Mar 15, 1999 11:25:17 pm" To: freebsd-scsi@freebsd.org Date: Tue, 23 Mar 1999 00:33:22 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Justin has reproduced the problem (with a lot of help from Tor Egge) and > has a PCI bus trace showing the problem. > > He said that there may be a bug in the 7890 that causes it to hang in > certain circumstances; he has mailed Adaptec asking for information. > > Since he's not in town at the moment, I wouldn't expect any response from > him on this for a few days. question, what is the status for this now? any patches i could try? i mean, like, i'm ready to try anything at the moment, but linux, to solve this thing... i have several machines i can use for testing. so far i've twiddled with timings and stuff, the code is from last week, but as far as i can tell (i read "all" the major lists including cvs-all) nothing has been committed into the tree... mickey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 14:52:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id C130714C41 for ; Mon, 22 Mar 1999 14:52:42 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA69062; Mon, 22 Mar 1999 15:52:14 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903222252.PAA69062@panzer.plutotech.com> Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903222233.AAA05925@shadows.aeon.net> from mika ruohotie at "Mar 23, 1999 0:33:22 am" To: bsdscsi@shadows.aeon.net (mika ruohotie) Date: Mon, 22 Mar 1999 15:52:14 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mika ruohotie wrote... > > Justin has reproduced the problem (with a lot of help from Tor Egge) and > > has a PCI bus trace showing the problem. > > > > He said that there may be a bug in the 7890 that causes it to hang in > > certain circumstances; he has mailed Adaptec asking for information. > > > > Since he's not in town at the moment, I wouldn't expect any response from > > him on this for a few days. > > question, what is the status for this now? > > any patches i could try? i mean, like, i'm ready to try anything > at the moment, but linux, to solve this thing... Tor Egge came up with a work-around that seems to solve the problem most of the time. It isn't a fix. As far as I know, Justin has not heard back from Adaptec yet. Justin said that he is planning on checking in Tor's work-around until he can get a real fix. He said he would try to check it in later on tonight, but that may or may not happen, since he is busy. > i have several machines i can use for testing. so far i've twiddled > with timings and stuff, the code is from last week, but as far as i > can tell (i read "all" the major lists including cvs-all) nothing > has been committed into the tree... Well, here's Tor's patch. I don't think he'll mind if I give it out: http://www.FreeBSD.ORG/~ken/tor.adaptec_patch.031799 I upgraded a number of machines this weekend, and I had the same hang problem on a system with an onboard 7890. I fixed it with the above patch. Send some mail to the list once you try the patch and let people know whether it works for you or not. 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 Mar 22 15: 1:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id A999915283 for ; Mon, 22 Mar 1999 15:01:22 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id PAA16475; Mon, 22 Mar 1999 15:00:45 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA231403645; Mon, 22 Mar 1999 15:00:45 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id PAA07823; Mon, 22 Mar 1999 15:00:44 -0800 (PST) Message-Id: <199903222300.PAA07823@mina.sr.hp.com> To: DrXyzzy@mediaone.net (Hal Snyder), scsi@FreeBSD.ORG Subject: Re: 3.0 installs, 3.1 won't Reply-To: Darryl Okahata In-Reply-To: Your message of "Mon, 22 Mar 1999 15:01:41 MST." <199903222201.PAA68733@panzer.plutotech.com> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Mon, 22 Mar 1999 15:00:43 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" wrote: > Hal Snyder wrote... > > > 2. IBM DGVS09U UltraStar 9ZX 9.1GB 10,000 rpm UWSCSI drive > > On channel B as SCSI ID 0 (wide) > > > > 3. Plextor PX-32i Ultraplex USCSI interface CD drive > > On channel A as SCSI ID 2 (narrow) > > - This could be cabling or termination. > - It could be that the drive is dying. > - It could be a driver bug. Another, lesser, possibility is that the 9ZX UltraStar is really an LVD drive running in SE mode. I've had mail-order companies ship me LVD drives when I've ordered plain F/W SCSI drives (I've ordered plain F/W UltraStar 9ES drives, but received LVD UltraStar 9ES drives instead). The difference is that LVD drives running in SE mode need an external terminator. Look for the white label on the drive. My LVD UltraStar 9ES drive has an "lvd" marking in the lower-right quadrant, and, if you have an LVD drive, you may see a similar one. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 15:44:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by hub.freebsd.org (Postfix) with ESMTP id 7504615253; Mon, 22 Mar 1999 15:44:19 -0800 (PST) (envelope-from girgen@partitur.se) Received: from d1o62.telia.com (root@d1o62.telia.com [195.198.198.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id AAA01720; Tue, 23 Mar 1999 00:43:59 +0100 (CET) Received: from stordatan.telia.com (t5o62p12.telia.com [195.198.199.12]) by d1o62.telia.com (8.8.8/8.8.5) with ESMTP id AAA07016; Tue, 23 Mar 1999 00:43:57 +0100 (MET) Received: from partitur.se (localhost [127.0.0.1]) by stordatan.telia.com (8.9.2/8.9.1) with ESMTP id AAA00673; Tue, 23 Mar 1999 00:43:55 +0100 (CET) (envelope-from girgen@partitur.se) Message-ID: <36F6D5BB.1F46625F@partitur.se> Date: Tue, 23 Mar 1999 00:43:55 +0100 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: sv, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Subject: Travan-20 tape streamer: unit not ready Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I just got a brand new Seagate Travan 20G . I have previously used a Seagate "Hornet", Travan 4G, and is has worked fine (well, it has some quirks, but it does its job). The new streamer won't work. I have connected it and it show up fine: #camcontrol devlist ... at scbus1 target 3 lun 0 (pass5,sa0) at scbus1 target 5 lun 0 (pass6,sa1) but: # mt -f /dev/nrsa1 stat mt: /dev/nrsa1: Device not configured # camcontrol tur -n sa -u 1 Unit is not ready # camcontrol reset 1 Reset of bus 1 was successful # camcontrol tur -n sa -u 1 Unit is not ready in messages, the mt command gives the following "clues": Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): ILLEGAL REQUEST asc:4,3 Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not ready, manual intervention required Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): REWIND. CDB: 1 0 0 0 0 0 Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): NOT READY asc:4,3 Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not ready, manual intervention required I have all devs made: # ls -laF /dev/*sa1* /dev/pass6 crw-rw---- 2 root operator 14, 18 22 Mar 15:54 /dev/ersa1 crw-rw---- 2 root operator 14, 18 22 Mar 15:54 /dev/ersa1.0 crw-rw---- 1 root operator 14, 22 22 Mar 15:54 /dev/ersa1.1 crw-rw---- 1 root operator 14, 26 22 Mar 15:54 /dev/ersa1.2 crw-rw---- 1 root operator 14, 30 22 Mar 15:54 /dev/ersa1.3 crw-rw---- 2 root operator 14, 17 22 Mar 15:54 /dev/nrsa1 crw-rw---- 2 root operator 14, 17 22 Mar 15:54 /dev/nrsa1.0 crw-rw---- 1 root operator 14, 21 22 Mar 15:54 /dev/nrsa1.1 crw-rw---- 1 root operator 14, 25 22 Mar 15:54 /dev/nrsa1.2 crw-rw---- 1 root operator 14, 29 22 Mar 15:54 /dev/nrsa1.3 crw------- 1 root operator 31, 6 18 Mar 00:13 /dev/pass6 crw-rw---- 2 root operator 14, 16 22 Mar 15:54 /dev/rsa1 crw-rw---- 2 root operator 14, 16 22 Mar 15:54 /dev/rsa1.0 crw-rw---- 1 root operator 14, 20 22 Mar 15:54 /dev/rsa1.1 crw-rw---- 1 root operator 14, 24 22 Mar 15:54 /dev/rsa1.2 crw-rw---- 1 root operator 14, 28 22 Mar 15:54 /dev/rsa1.3 crw-rw---- 1 root operator 14, 0x20000010 22 Mar 15:54 /dev/rsa1.ctl #uname -a FreeBSD trumpet.partitur.se 3.1-STABLE FreeBSD 3.1-STABLE #0: Fri Mar 19 02:54:46 CET 1999 girgen@tb303.partitur.se:/usr/src/sys/compile/TRUMPET i386 What's happening? Any ideas? /Palle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 15:45:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 6865A152AE for ; Mon, 22 Mar 1999 15:45:05 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id SAA13378; Mon, 22 Mar 1999 18:44:35 -0500 (EST) Date: Mon, 22 Mar 1999 18:44:35 -0500 (EST) From: "Matthew N. Dodd" To: Warner Losh Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903222103.OAA05087@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Warner Losh wrote: > I wonder if terminal devices would fit into this framework... That depends on how well your SCSI terminsl server is documented. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 16:30: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from is2.net.ohio-state.edu (is2.net.ohio-state.edu [128.146.48.9]) by hub.freebsd.org (Postfix) with SMTP id D4BC414FAA for ; Mon, 22 Mar 1999 16:30:03 -0800 (PST) (envelope-from maf@base.net.ohio-state.edu) Received: (qmail 15936 invoked from network); 22 Mar 1999 21:42:46 -0000 Received: from base.net.ohio-state.edu (128.146.222.126) by is2.net.ohio-state.edu with SMTP; 22 Mar 1999 21:42:46 -0000 Received: (qmail 16027 invoked by uid 4454); 22 Mar 1999 21:42:46 -0000 Date: Mon, 22 Mar 1999 16:42:45 -0500 From: Mark Fullmer To: freebsd-scsi@freebsd.org Subject: Mylex DAC960SX question Message-ID: <19990322164245.A16014@net.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.15i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The DAC960SX presents each logical drive to the host controller as a logical unit. This appears to work, except the transfer rate is reported as 3.300MB/s for LUN's 0-6. LUN7 reports 40MB/s. Why is the transfer rate different on the first 7 LUN's? da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: 3.300MB/s transfers, Tagged Queueing Enabled da1: 246673MB (505186304 512 byte sectors: 255H 63S/T 31446C) (da2:ahc0:0:1:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da2:ahc0:0:1:1): ILLEGAL REQUEST asc:25,0 (da2:ahc0:0:1:1): Logical unit not supported da2 at ahc0 bus 0 target 1 lun 1 da2: Fixed Direct Access SCSI2 device (offline) da2: 3.300MB/s transfers, Tagged Queueing Enabled da2: Attempt to query device size, failed ... repeats for the unconfigured drives which the Mylex probably shouldn't be reporting. I assume the controller is doing this to help OS's which can't rescan the SCSI bus after boot. (da8:ahc0:0:1:7): READ CAPACITY. CDB: 25 e0 0 0 0 0 0 0 0 0 (da8:ahc0:0:1:7): ILLEGAL REQUEST asc:25,0 (da8:ahc0:0:1:7): Logical unit not supported da8 at ahc0 bus 0 target 1 lun 7 da8: Fixed Direct Access SCSI2 device (offline) da8: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da8: Attempt to query device size, failed -- mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 16:39:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id F2A31152C2 for ; Mon, 22 Mar 1999 16:39:29 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA19330; Mon, 22 Mar 1999 16:38:30 -0800 (PST) Message-Id: <199903230038.QAA19330@implode.root.com> To: Mark Fullmer Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Mylex DAC960SX question In-reply-to: Your message of "Mon, 22 Mar 1999 16:42:45 EST." <19990322164245.A16014@net.ohio-state.edu> From: David Greenman Reply-To: dg@root.com Date: Mon, 22 Mar 1999 16:38:30 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Looks like the DAC960SX is misconfigured. I use that RAID controller on wcarchive and it works fine if properly configured. It shouldn't be reporting unused LUNs for one thing. Also, you might try changing something in the Adaptec SCSI BIOS config and saving the results. I've found that there seems to be an parameter initialization problem (with FreeBSD) on new ahc boards if you don't do this first. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project >The DAC960SX presents each logical drive to the host controller as >a logical unit. This appears to work, except the transfer rate >is reported as 3.300MB/s for LUN's 0-6. LUN7 reports 40MB/s. >Why is the transfer rate different on the first 7 LUN's? > >da1 at ahc0 bus 0 target 1 lun 0 >da1: Fixed Direct Access SCSI2 device >da1: 3.300MB/s transfers, Tagged Queueing Enabled >da1: 246673MB (505186304 512 byte sectors: 255H 63S/T 31446C) > >(da2:ahc0:0:1:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 >(da2:ahc0:0:1:1): ILLEGAL REQUEST asc:25,0 >(da2:ahc0:0:1:1): Logical unit not supported >da2 at ahc0 bus 0 target 1 lun 1 >da2: Fixed Direct Access SCSI2 device (offline) >da2: 3.300MB/s transfers, Tagged Queueing Enabled >da2: Attempt to query device size, failed > >... repeats for the unconfigured drives which the Mylex probably >shouldn't be reporting. I assume the controller is doing this to >help OS's which can't rescan the SCSI bus after boot. > >(da8:ahc0:0:1:7): READ CAPACITY. CDB: 25 e0 0 0 0 0 0 0 0 0 >(da8:ahc0:0:1:7): ILLEGAL REQUEST asc:25,0 >(da8:ahc0:0:1:7): Logical unit not supported >da8 at ahc0 bus 0 target 1 lun 7 >da8: Fixed Direct Access SCSI2 device (offline) >da8: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled >da8: Attempt to query device size, failed > >-- >mark > > >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 Mar 22 17:28:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B57515177 for ; Mon, 22 Mar 1999 17:28:38 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id RAA21126; Mon, 22 Mar 1999 17:27:58 -0800 Date: Mon, 22 Mar 1999 17:27:57 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Palle Girgensohn Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <36F6D5BB.1F46625F@partitur.se> 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 (removing freebsd-hardware from list). > in messages, the mt command gives the following "clues": > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): LOAD UNLOAD. CDB: 1b > 0 0 0 1 0 > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): ILLEGAL REQUEST > asc:4,3 > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > ready, manual intervention required > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): REWIND. CDB: 1 0 0 0 > 0 0 > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): NOT READY asc:4,3 > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > ready, manual intervention required I just ordered an HP 20GB 'travan like' drive. It'll be interesting to see if this is also that broken. And this is with the unit there *and* a tape inserted? Wow! That is *really* fantastically broken that a tape drive that has a tape inserted supports *neither* a load (to BOT) command or a REWIND. The load is optional. The rewind is mandatory. That's amazing. I think I'll have to invent a new quirk for someething this broken. The code that this is breaking on is the following in samount: /* * *Very* first off, make sure we're loaded to BOT. */ scsi_load_unload(&ccb->csio, 2, sadone, MSG_SIMPLE_Q_TAG, FALSE, FALSE, FALSE, 1, SSD_FULL_SIZE, 60000); error = cam_periph_runccb(ccb, saerror, 0, SF_QUIET_IR, &softc->device_stats); if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) cam_release_devq(ccb->ccb_h.path, 0, 0, 0, FALSE); /* * In case this doesn't work, do a REWIND instead */ if (error) { scsi_rewind(&ccb->csio, 5, sadone, MSG_SIMPLE_Q_TAG, FALSE, SSD_FULL_SIZE, (SA_REWIND_TIMEOUT) * 60 * 1000); error = cam_periph_runccb(ccb, saerror, 0, 0, &softc->device_stats); } if (error) { xpt_release_ccb(ccb); goto exit; } When you're trying to mount a tape, make sure you're at BOT. If the rewind is failing- it's hard for me to really be sure I'm not overwriting something I shouldn't be, but if this drive really is that busted, I'll guss I'll quirk it so it doesn't matter. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 18:30:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 181DE152BA for ; Mon, 22 Mar 1999 18:30:55 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id DAA02784 for freebsd-scsi@freebsd.org; Tue, 23 Mar 1999 03:30:36 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10PFM9-000WyXC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Tue, 23 Mar 1999 01:47:45 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Crash: what happened? Date: 23 Mar 1999 01:47:42 +0100 Message-ID: <7d6obe$ne4$1@mips.rhein-neckar.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Our favorite unstable 2.2.8 box crashed with the following. Any idea what could have caused this? ncr0:1: ERROR (1:0) (8-0-800) (8/13) @ (mem 159e0:00000000). ncr0: regdump: da 10 80 13 47 08 00 1f 35 08 80 af 00 00 0f 02. ncr0: have to clear fifos. ncr0: restart (fatal error). sd5(ncr0:1:0): COMMAND FAILED (9 ff) @f29fa000. sd4(ncr0:0:0): COMMAND FAILED (9 ff) @f29fa400. ncr0: timeout ccb=f29fa000 (skip) ncr0: timeout ccb=f29fa400 (skip) swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 swap_pager: indefinite wait buffer: device: 1065, blkno: 85352, size: 8192 swap_pager: indefinite wait buffer: device: 1065, blkno: 208, size: 24576 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffa03b01 fault code = supervisor write, page not present instruction pointer = 0x8:0xf01cd742 stack pointer = 0x10:0xefbffe5c frame pointer = 0x10:0xefbffe68 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 173 (httpd) interrupt mask = net tty bio cam panic: page fault syncing disks... 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 giving up Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de 100+ SF Book Reviews: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 18:36:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from is2.net.ohio-state.edu (is2.net.ohio-state.edu [128.146.48.9]) by hub.freebsd.org (Postfix) with SMTP id B9CF51530D for ; Mon, 22 Mar 1999 18:36:53 -0800 (PST) (envelope-from maf@dev1.net.ohio-state.edu) Received: (qmail 20484 invoked from network); 23 Mar 1999 02:36:33 -0000 Received: from dev1.net.ohio-state.edu (128.146.222.3) by is2.net.ohio-state.edu with SMTP; 23 Mar 1999 02:36:33 -0000 Received: (qmail 20792 invoked by uid 4454); 23 Mar 1999 02:36:33 -0000 Message-ID: <19990322213633.A20664@net.ohio-state.edu> Date: Mon, 22 Mar 1999 21:36:33 -0500 From: Mark Fullmer To: dg@root.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Mylex DAC960SX question References: <19990322164245.A16014@net.ohio-state.edu> <199903230038.QAA19330@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199903230038.QAA19330@implode.root.com>; from David Greenman on Mon, Mar 22, 1999 at 04:38:30PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Looks like the DAC960SX is misconfigured. I use that RAID controller on > wcarchive and it works fine if properly configured. It shouldn't be reporting The unused LUN's don't show up under the Adaptec disk utilities menu. "Vendor Unique TUR" looks like the only option that could cause this to happen on the Mylex side. Unfortunately it's not available from the front panel controls. > unused LUNs for one thing. Also, you might try changing something in the > Adaptec SCSI BIOS config and saving the results. I've found that there seems > to be an parameter initialization problem (with FreeBSD) on new ahc boards if > you don't do this first. Tried that, no difference. ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 32/255 SCBs (probe1:ahc0:0:1:1): MODE SENSE(06). CDB: 1a 20 a 0 14 0 (probe1:ahc0:0:1:1): ILLEGAL REQUEST asc:25,0 (probe1:ahc0:0:1:1): Logical unit not supported (probe1:ahc0:0:1:2): MODE SENSE(06). CDB: 1a 40 a 0 14 0 (probe1:ahc0:0:1:2): ILLEGAL REQUEST asc:25,0 (probe1:ahc0:0:1:2): Logical unit not supported (probe1:ahc0:0:1:3): MODE SENSE(06). CDB: 1a 60 a 0 14 0 (probe1:ahc0:0:1:3): ILLEGAL REQUEST asc:25,0 (probe1:ahc0:0:1:3): Logical unit not supported (probe1:ahc0:0:1:4): MODE SENSE(06). CDB: 1a 80 a 0 14 0 (probe1:ahc0:0:1:4): ILLEGAL REQUEST asc:25,0 (probe1:ahc0:0:1:4): Logical unit not supported (probe0:ahc0:0:1:5): MODE SENSE(06). CDB: 1a a0 a 0 14 0 (probe0:ahc0:0:1:5): ILLEGAL REQUEST asc:25,0 (probe0:ahc0:0:1:5): Logical unit not supported (probe0:ahc0:0:1:6): MODE SENSE(06). CDB: 1a c0 a 0 14 0 (probe0:ahc0:0:1:6): ILLEGAL REQUEST asc:25,0 (probe0:ahc0:0:1:6): Logical unit not supported (probe0:ahc0:0:1:7): MODE SENSE(06). CDB: 1a e0 a 0 14 0 (probe0:ahc0:0:1:7): ILLEGAL REQUEST asc:25,0 (probe0:ahc0:0:1:7): Logical unit not supported Off to build a RAIDfx boot floppy... -- mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 18:55:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 33E921531F for ; Mon, 22 Mar 1999 18:55:13 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-94.dialup.HiWAAY.net [216.180.15.94]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id UAA23361 for ; Mon, 22 Mar 1999 20:54:48 -0600 (CST) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id UAA10919 for ; Mon, 22 Mar 1999 20:54:41 -0600 (CST) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199903230254.UAA10919@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-reply-to: Message from sthaug@nethelp.no of "Mon, 22 Mar 1999 11:00:26 +0100." <20327.922096826@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Mar 1999 20:54:41 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no writes: > > > In truth, I'm fairly disappointed by the IBM drive... especially compared > > > to the Conner one. > > > > The DCAS-34330xxx are the poorest disks money can buy. Your numbers are > > correct. > > I have to disagree. These drives were very good when they first came > out. That doesn't mean I'd buy them today :-) I agree. Years ago, before I installed my new narrow DCAS on a FreeBSD system I tried it first on an SGI Indy R5000. With a fresh XFS filesystem on one each, DCAS (5400 RPM) and Seagate ST15150N (7200 RPM) the DCAS handily beat the Seagate on a: % time dd if=/dev/zero bs=1024k count=1024 of=file_on_disk Think the Seagate did just shy of 7MB/second when the DCAS did a tad over 8MB/minute. The Indy only had fast SCSI. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 19:37:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from outreach.wolfnet.org (outreach.wolfnet.org [207.173.133.202]) by hub.freebsd.org (Postfix) with ESMTP id BBECD14DC8 for ; Mon, 22 Mar 1999 19:37:50 -0800 (PST) (envelope-from jkf@wolfnet.org) Received: from outreach.wolfnet.org ([207.173.133.202]) by outreach.wolfnet.org with esmtp (Exim 2.12 #1) id 10PI0F-000KW2-00; Mon, 22 Mar 1999 19:37:19 -0800 Date: Mon, 22 Mar 1999 19:37:19 -0800 (PST) From: "Jason K. Fritcher" To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903222252.PAA69062@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Kenneth D. Merry wrote: > Well, here's Tor's patch. I don't think he'll mind if I give it out: > > http://www.FreeBSD.ORG/~ken/tor.adaptec_patch.031799 > > I upgraded a number of machines this weekend, and I had the same hang > problem on a system with an onboard 7890. I fixed it with the above patch. > > Send some mail to the list once you try the patch and let people know > whether it works for you or not. I tried this patch a couple days ago, and it didn't do any good for my machine. -- Jason K. Fritcher jkf@wolfnet.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 21:57:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caern.limax.com (we-24-130-40-67.we.mediaone.net [24.130.40.67]) by hub.freebsd.org (Postfix) with ESMTP id D031714CC9; Mon, 22 Mar 1999 21:57:20 -0800 (PST) (envelope-from obrien@leonardo.net) Received: from mobrien.ni.net (localhost [127.0.0.1]) by caern.limax.com (8.9.2/8.9.2) with ESMTP id VAA00370; Mon, 22 Mar 1999 21:58:26 -0800 (PST) (envelope-from obrien@leonardo.net) Message-Id: <199903230558.VAA00370@caern.limax.com> To: "Kenneth D. Merry" Cc: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Odd messages In-reply-to: Your message of "Mon, 22 Mar 1999 15:16:05 MST." <199903222216.PAA68834@panzer.plutotech.com> Date: Mon, 22 Mar 1999 21:58:20 -0800 From: "Mike O'Brien" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth Merry sez: > What is a VP32210? I don't see that anywhere on Quantum's web site listing > of various model numbers. Beats me. That's what Fry's was selling that week as a Quantum 2-gig SCSI drive. Thanks for your response. I'll check cabling and termination. If there's a way to upgrade drive firmware, I sure don't know what it is. Mike O'Brien To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 22: 8:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 15E6514CB3; Mon, 22 Mar 1999 22:08:27 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA71440; Mon, 22 Mar 1999 23:07:56 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903230607.XAA71440@panzer.plutotech.com> Subject: Re: Odd messages In-Reply-To: <199903230558.VAA00370@caern.limax.com> from "Mike O'Brien" at "Mar 22, 1999 9:58:20 pm" To: obrien@leonardo.net (Mike O'Brien) Date: Mon, 22 Mar 1999 23:07:56 -0700 (MST) Cc: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike O'Brien wrote... > Kenneth Merry sez: > > What is a VP32210? I don't see that anywhere on Quantum's web site listing > > of various model numbers. > > Beats me. That's what Fry's was selling that week as a Quantum > 2-gig SCSI drive. > > Thanks for your response. I'll check cabling and termination. > If there's a way to upgrade drive firmware, I sure don't know what it is. Quantum has firmware and a firmware loader on their FTP site. The thing is, I dunno what sort of drive you have. 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 Mar 22 22:29:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sloth.metonymy.com (max3-243.aip.realtime.net [205.238.179.243]) by hub.freebsd.org (Postfix) with ESMTP id F2C8614CC9; Mon, 22 Mar 1999 22:29:19 -0800 (PST) (envelope-from khym@bga.com) Received: from localhost (localhost [[UNIX: localhost]]) by sloth.metonymy.com (8.8.8/8.8.7) with ESMTP id AAA18204; Tue, 23 Mar 1999 00:28:41 -0600 (CST) X-Authentication-Warning: sloth.metonymy.com: khym owned process doing -bs Date: Tue, 23 Mar 1999 00:28:36 -0600 (CST) From: Dave Huang X-Sender: khym@sloth.metonymy.com To: "Mike O'Brien" Cc: "Kenneth D. Merry" , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Odd messages In-Reply-To: <199903230558.VAA00370@caern.limax.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Mike O'Brien wrote: > Kenneth Merry sez: > > What is a VP32210? I don't see that anywhere on Quantum's web site listing > > of various model numbers. > > Beats me. That's what Fry's was selling that week as a Quantum > 2-gig SCSI drive. It's a Quantum Capella... 5400rpm, Fast10 drive. I've had the 2gig version in my machine for around 4 years or so... -- Name: Dave Huang | Mammal, mammal / their names are called / INet: khym@bga.com | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 23 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 22:36:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sloth.metonymy.com (max3-243.aip.realtime.net [205.238.179.243]) by hub.freebsd.org (Postfix) with ESMTP id 3425515032; Mon, 22 Mar 1999 22:36:18 -0800 (PST) (envelope-from khym@bga.com) Received: from localhost (localhost [[UNIX: localhost]]) by sloth.metonymy.com (8.8.8/8.8.7) with ESMTP id AAA18216; Tue, 23 Mar 1999 00:35:50 -0600 (CST) X-Authentication-Warning: sloth.metonymy.com: khym owned process doing -bs Date: Tue, 23 Mar 1999 00:35:46 -0600 (CST) From: Dave Huang X-Sender: khym@sloth.metonymy.com To: "Mike O'Brien" Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Odd messages In-Reply-To: <199903230558.VAA00370@caern.limax.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Mike O'Brien wrote: > Thanks for your response. I'll check cabling and termination. > If there's a way to upgrade drive firmware, I sure don't know what it is. Whoops, forgot to mention that the firmware is on ftp.quantum.com, in the /Disk_Firmware/Capella directory. I think /Utilities/Qshr_ldr.zip is the program that updates the firmware; you'll need DOS and ASPI drivers. Latest firmware is L915 (at least that's what's on quantum's site). IIRC, the C1*.FUP files are for the 1gig version and the C2*.FUP files are for the 2gig. The ones with "W" are for the wide versions. sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 22:54:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caern.limax.com (we-24-130-40-67.we.mediaone.net [24.130.40.67]) by hub.freebsd.org (Postfix) with ESMTP id 576AF14D40; Mon, 22 Mar 1999 22:54:45 -0800 (PST) (envelope-from obrien@leonardo.net) Received: from mobrien.ni.net (localhost [127.0.0.1]) by caern.limax.com (8.9.2/8.9.2) with ESMTP id WAA00509; Mon, 22 Mar 1999 22:55:53 -0800 (PST) (envelope-from obrien@leonardo.net) Message-Id: <199903230655.WAA00509@caern.limax.com> To: Dave Huang Cc: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Odd messages In-reply-to: Your message of "Tue, 23 Mar 1999 00:35:46 CST." Date: Mon, 22 Mar 1999 22:55:53 -0800 From: "Mike O'Brien" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > ...IIRC, the C1*.FUP files are for the 1gig version and the C2*.FUP files > are for the 2gig. The ones with "W" are for the wide versions. Sounds dangerous. How can I check this info before rendering my drive useless by loading bogus firmware? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 23:21:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 0742715371 for ; Mon, 22 Mar 1999 23:21:01 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA01844 for freebsd-scsi@FreeBSD.ORG; Tue, 23 Mar 1999 08:20:42 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA24321; Tue, 23 Mar 1999 08:19:01 +0100 (MET) (envelope-from j) Message-ID: <19990323081900.52443@uriah.heep.sax.de> Date: Tue, 23 Mar 1999 08:19:00 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <199903220215.TAA63620@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: ; from Chuck Robey on Sun, Mar 21, 1999 at 09:25:14PM -0500 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Chuck Robey wrote: > As far as where the file sits: > > /dev/da2e 1961715 898304 906474 50% /usr/local > > as you can see, it's only half full. What might I do to make the test > more fair (as compared to Jorg's results? Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 3742 92.4 6102 49.6 2743 29.7 3951 92.0 7431 62.1 78.5 6.2 This is for my /usr partition which is at the beginning of the drive. However, the partition is 3 GB in total and 3/4 full. Nevertheless, i think it's visible that the numbers increase on the outer tracks. > (private to Jorg: I don't know how to tickle the keyboard to get the > diuresis(sp?), I can't spell your name any closer.) Well, there are something like three options: . Your keyboard offers those characters. :-) Sure no solution for you, but that's how it works for me. . Your X11 client uses the left Alt key as a `Meta' key which adds 0x80 to all chars. Then, `ö' is Alt-v. . Your Xserver and clients can make use of a `compose' key. For me, this is the ScrollLock key, so by typing -"-o, i also get an `ö', or -`-e gives an `è' etc. This is done in the xkb mapping by assigning ScrLk to Multi_key (which is default for my German layout). . Your Emacs supports it by using the iso-insert library, where the compose key is C-x-8, so the `ö' is C-x-8-"-o: ö. Terrible, but works. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 23:22: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sloth.metonymy.com (max2-158.aip.realtime.net [205.238.153.158]) by hub.freebsd.org (Postfix) with ESMTP id 18DC6153B2; Mon, 22 Mar 1999 23:21:50 -0800 (PST) (envelope-from khym@bga.com) Received: from localhost (localhost [[UNIX: localhost]]) by sloth.metonymy.com (8.8.8/8.8.7) with ESMTP id BAA18344; Tue, 23 Mar 1999 01:21:20 -0600 (CST) X-Authentication-Warning: sloth.metonymy.com: khym owned process doing -bs Date: Tue, 23 Mar 1999 01:21:11 -0600 (CST) From: Dave Huang X-Sender: khym@sloth.metonymy.com To: "Mike O'Brien" Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Odd messages In-Reply-To: <199903230655.WAA00509@caern.limax.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999, Mike O'Brien wrote: > Sounds dangerous. How can I check this info before rendering > my drive useless by loading bogus firmware? That I don't know... however, there is an "Atlas-I/migrate.txt" which has a table describing which file goes with which drive, and the naming convention is very similar to the Capella's. Also, I think the qshr_ldr utility will let you see which drives a firmware file is for (as well as print info about your drive). Sorry I'm not very specific :) It's been a while since I updated my drives... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 23:22:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 9E4C8153AB for ; Mon, 22 Mar 1999 23:21:49 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA01854 for freebsd-scsi@FreeBSD.ORG; Tue, 23 Mar 1999 08:21:29 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA24282; Tue, 23 Mar 1999 08:08:08 +0100 (MET) (envelope-from j) Message-ID: <19990323080808.54827@uriah.heep.sax.de> Date: Tue, 23 Mar 1999 08:08:08 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <19990321110510.38582@uriah.heep.sax.de> <199903220212.TAA63607@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903220212.TAA63607@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 21, 1999 at 07:12:42PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > One question I have is this -- when you say 1 tag, did you do disable > tagged queueing like this: > > camcontrol negotiate -n da -u 3 -T disable No, this doesn't change anything for me: uriah # camcontrol negotiate -n da -u 1 -T disable Current Parameters: (pass3:ncr1:0:1:0): sync parameter: 25 (pass3:ncr1:0:1:0): frequencey: 10.000MHz (pass3:ncr1:0:1:0): offset: 8 (pass3:ncr1:0:1:0): bus width: 8 bits (pass3:ncr1:0:1:0): disconnection is enabled (pass3:ncr1:0:1:0): tagged queueing is enabled I was only able to reduce the number of tagged openings to 1. (Patch to prevent a SIGFPE coredump.) > What does it print out for the sync parameter? My guess is that it > must be 0 or something... Yes, 0. Sure, the numbers don't make sense with the patch either, but at least camcontrol doesn't dump core. uriah # camcontrol negotiate -n da -u 2 Current Parameters: (pass4:ncr1:0:3:0): sync parameter: 0 (pass4:ncr1:0:3:0): offset: 0 (pass4:ncr1:0:3:0): bus width: 8 bits (pass4:ncr1:0:3:0): disconnection is enabled (pass4:ncr1:0:3:0): tagged queueing is disabled (Perhaps it should just say `asynchronous' instead? That's the ancient SONY MO drive.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 23:22:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 454E4153CA for ; Mon, 22 Mar 1999 23:22:12 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA01858 for freebsd-scsi@FreeBSD.ORG; Tue, 23 Mar 1999 08:21:53 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA24294; Tue, 23 Mar 1999 08:09:02 +0100 (MET) (envelope-from j) Message-ID: <19990323080902.11661@uriah.heep.sax.de> Date: Tue, 23 Mar 1999 08:09:02 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <19990321110510.38582@uriah.heep.sax.de> <199903220212.TAA63607@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903220212.TAA63607@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 21, 1999 at 07:12:42PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (Btw...) As Kenneth D. Merry wrote: > Also, you'll probably want to make sure that the size of the file > that bonnie writes out is somewhat larger than your RAM, to > eliminate the effects of FreeBSD's cache... Yep, for my tests, it's 100 MB file vs. 32 MB RAM. That should be enough. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 22 23:37:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CF314D6D; Mon, 22 Mar 1999 23:37:10 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id AAA71954; Tue, 23 Mar 1999 00:36:26 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903230736.AAA71954@panzer.plutotech.com> Subject: Re: Odd messages In-Reply-To: <199903230655.WAA00509@caern.limax.com> from "Mike O'Brien" at "Mar 22, 1999 10:55:53 pm" To: obrien@leonardo.net (Mike O'Brien) Date: Tue, 23 Mar 1999 00:36:26 -0700 (MST) Cc: khym@bga.com, freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike O'Brien wrote... > > ...IIRC, the C1*.FUP files are for the 1gig version and the C2*.FUP files > > are for the 2gig. The ones with "W" are for the wide versions. > > Sounds dangerous. How can I check this info before rendering > my drive useless by loading bogus firmware? IIRC, their loader either doesn't let you load the wrong firmware, or will tell you which drives the firmware is for. I always just do a 'strings' on the firmware binary first. You'll see the byte-swapped model numbers that the firmware is intended for. For instance, this is from the Atlas II DAGNLYK8.FUP firmware file (which is intended for the 4G Atlas II drives): PX4355S0 ==> XP34550S UFCPtsnIof ==> FUPCstInfo FE>+ PX4355W0 ==>XP34550W PX4355W0 D ==>XP34550WD PX4355J0 ==>XP34550J Easy enough. 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 Mar 23 0:21:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id C4DE414D6D; Tue, 23 Mar 1999 00:20:07 -0800 (PST) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id JAA21132; Tue, 23 Mar 1999 09:22:52 +0100 (MET) Date: Tue, 23 Mar 1999 09:19:42 +0100 (MET) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Charles Owens Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, freebsd-scsi@FreeBSD.ORG, Brian Topping Subject: Re: fix for amanda chg-chio script to eject tape In-Reply-To: <36F6990E.1E5026DD@enc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The system I'm using is a 28-tape changer from a company called MediaLogic. It has > a Sony AIT-1 drive (which, since sa(4) doesn't know the AIT extended features, is > being treated like just a big 8mm drive). > > Once a tape is inserted into the drive it is completely beyond the reach of the > changer. When the tape is ejected by the OS, it hangs out in this intermediate > space from which the changer may come by and grab it. Here it shows. In the case of the Sony TSL 7000, the logic is in the tape drive and the arm needs to be in front of the drive when it ejects the tape. So it probably considers moving something that requires an eject. But an eject won't hurt I agree. Will post an update to the Amanda people. -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 0:36:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (Postfix) with ESMTP id 3471214D2C; Tue, 23 Mar 1999 00:34:08 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id JAA19900; Tue, 23 Mar 1999 09:33:48 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.6.9) id JAA00480; Tue, 23 Mar 1999 09:36:34 +0100 (CET) Date: Tue, 23 Mar 1999 09:36:34 +0100 From: Stefan Esser To: Christian Weisgerber Cc: freebsd-scsi@freebsd.org, Stefan Esser Subject: Re: Crash: what happened? Message-ID: <19990323093634.A425@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: <7d6obe$ne4$1@mips.rhein-neckar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.4i In-Reply-To: <7d6obe$ne4$1@mips.rhein-neckar.de>; from Christian Weisgerber on Tue, Mar 23, 1999 at 01:47:42AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-03-23 01:47 +0100, Christian Weisgerber wrote: > Our favorite unstable 2.2.8 box crashed with the following. Any idea > what could have caused this? > > ncr0:1: ERROR (1:0) (8-0-800) (8/13) @ (mem 159e0:00000000). This looks like a memory read error (or the delayed result thereof) ... In the error message above (1:0) = (dstat:sist). dstat=1 (Illegal Instruction) sist=0 Offset of next instruction is 0x159e0 (way outside the "official" NCR SCRIPTS code). At that address, a value of 0 was read, which is not a valid instruction for the CPU in the NCR chip. It stopped working, and the driver did not manage to recover from that state. (It is possible, that the memory range holding the "micro-code" was corrupted. I can't tell, what made the NCR jump to that invalid address where the "Illegal Instruction Detected" interrupt made it stop. (It may have been a soft error, just had one a few days ago, when one bit flipped during a kernel build ...) Since I assume that this is a single occurence in an otherwise reliable system, I'd not consider this to be a major problem. If something like that happens again, I'd rather guess it is hardware going bad than software. (I have heard of NCR chips fail after years of reliable operation, and this may also be a memory chip running under marginal conditions ...) Gruß, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 8:34:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C001814D15 for ; Tue, 23 Mar 1999 08:34:14 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id QAA03782; Tue, 23 Mar 1999 16:33:55 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA02400; Tue, 23 Mar 1999 09:33:26 -0700 (MST) Message-Id: <199903231633.JAA02400@harmony.village.org> To: Joerg Wunsch Subject: Re: cvs commit: src/sys/cam cam_xpt.c Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Tue, 23 Mar 1999 08:19:00 +0100." <19990323081900.52443@uriah.heep.sax.de> References: <19990323081900.52443@uriah.heep.sax.de> <199903220215.TAA63620@panzer.plutotech.com> Date: Tue, 23 Mar 1999 09:33:26 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990323081900.52443@uriah.heep.sax.de> J Wunsch writes: : > (private to Jorg: I don't know how to tickle the keyboard to get the : > diuresis(sp?), I can't spell your name any closer.) That's why you can use oe rather than ö. This is true for the german umlaut, but I don't know about other languages. I know english uses this character as a sounding que (as in cooperate, you'll sometimes see it coöperate), so this isn't always an option. : Well, there are something like three options: [ four options deleted ] Or you could do it the hard way in emacs, if it doesn't support the compose key: C-q 3 6 6 :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 9:14:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 29B5814BDC for ; Tue, 23 Mar 1999 09:14:28 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA74205; Tue, 23 Mar 1999 10:13:58 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903231713.KAA74205@panzer.plutotech.com> Subject: Re: Mylex DAC960SX question In-Reply-To: <19990322213633.A20664@net.ohio-state.edu> from Mark Fullmer at "Mar 22, 1999 9:36:33 pm" To: maf@net.ohio-state.edu (Mark Fullmer) Date: Tue, 23 Mar 1999 10:13:58 -0700 (MST) Cc: dg@root.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Fullmer wrote... > > Looks like the DAC960SX is misconfigured. I use that RAID controller on > > wcarchive and it works fine if properly configured. It shouldn't be reporting > > The unused LUN's don't show up under the Adaptec disk utilities menu. > "Vendor Unique TUR" looks like the only option that could cause this > to happen on the Mylex side. Unfortunately it's not available from the > front panel controls. > > > unused LUNs for one thing. Also, you might try changing something in the > > Adaptec SCSI BIOS config and saving the results. I've found that there seems > > to be an parameter initialization problem (with FreeBSD) on new ahc boards if > > you don't do this first. > > Tried that, no difference. > > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 32/255 SCBs > > (probe1:ahc0:0:1:1): MODE SENSE(06). CDB: 1a 20 a 0 14 0 > (probe1:ahc0:0:1:1): ILLEGAL REQUEST asc:25,0 > (probe1:ahc0:0:1:1): Logical unit not supported > (probe1:ahc0:0:1:2): MODE SENSE(06). CDB: 1a 40 a 0 14 0 > (probe1:ahc0:0:1:2): ILLEGAL REQUEST asc:25,0 > (probe1:ahc0:0:1:2): Logical unit not supported > (probe1:ahc0:0:1:3): MODE SENSE(06). CDB: 1a 60 a 0 14 0 > (probe1:ahc0:0:1:3): ILLEGAL REQUEST asc:25,0 > (probe1:ahc0:0:1:3): Logical unit not supported Those messages won't show up if you don't boot with -v. 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 Mar 23 9:18:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 8349514C59 for ; Tue, 23 Mar 1999 09:18:33 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA74235; Tue, 23 Mar 1999 10:18:07 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903231718.KAA74235@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <19990323080808.54827@uriah.heep.sax.de> from J Wunsch at "Mar 23, 1999 8: 8: 8 am" To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 23 Mar 1999 10:18:07 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... > As Kenneth D. Merry wrote: > > > One question I have is this -- when you say 1 tag, did you do disable > > tagged queueing like this: > > > > camcontrol negotiate -n da -u 3 -T disable > > No, this doesn't change anything for me: > > uriah # camcontrol negotiate -n da -u 1 -T disable > Current Parameters: > (pass3:ncr1:0:1:0): sync parameter: 25 > (pass3:ncr1:0:1:0): frequencey: 10.000MHz > (pass3:ncr1:0:1:0): offset: 8 > (pass3:ncr1:0:1:0): bus width: 8 bits > (pass3:ncr1:0:1:0): disconnection is enabled > (pass3:ncr1:0:1:0): tagged queueing is enabled > > I was only able to reduce the number of tagged openings to 1. Right. But to get it to 1, you have to disable tagged queueing. > (Patch to prevent a SIGFPE coredump.) > > > What does it print out for the sync parameter? My guess is that it > > must be 0 or something... > > Yes, 0. Sure, the numbers don't make sense with the patch either, but > at least camcontrol doesn't dump core. > > uriah # camcontrol negotiate -n da -u 2 > Current Parameters: > (pass4:ncr1:0:3:0): sync parameter: 0 > (pass4:ncr1:0:3:0): offset: 0 > (pass4:ncr1:0:3:0): bus width: 8 bits > (pass4:ncr1:0:3:0): disconnection is enabled > (pass4:ncr1:0:3:0): tagged queueing is disabled > > (Perhaps it should just say `asynchronous' instead? That's the > ancient SONY MO drive.) Yeah, I think it should. xpt_announce_periph() (the kernel function that prints out sync rates, etc.) checks the offset against 0 before passing the sync period into scsi_calc_syncsrate(). I probably need to do the same thing. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 9:33: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 870E814D65 for ; Tue, 23 Mar 1999 09:33:02 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id SAA01149 for freebsd-scsi@freebsd.org; Tue, 23 Mar 1999 18:32:43 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10PSgW-000WyXC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Tue, 23 Mar 1999 16:01:40 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Crash: what happened? Date: 23 Mar 1999 16:01:36 +0100 Message-ID: <7d8acg$t0k$1@mips.rhein-neckar.de> References: <7d6obe$ne4$1@mips.rhein-neckar.de> <19990323093634.A425@dialup124.mi.uni-koeln.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser wrote: > > ncr0:1: ERROR (1:0) (8-0-800) (8/13) @ (mem 159e0:00000000). > > This looks like a memory read error (or the delayed result > thereof) ... In the error message above (1:0) = (dstat:sist). Hmm. > Since I assume that this is a single occurence in an otherwise > reliable system, I'd not consider this to be a major problem. Actually, that system has been giving us hell for the last few weeks now. It crashes every couple of days (for a period about twice a day but it seems to have stabilized somewhat since), for varying reasons. It's just that we usually aren't quite sure what the respective cause was. > If something like that happens again, I'd rather guess it is > hardware going bad than software. We're pretty sure its a hardware problem. Which doesn't help at all in narrowing it down. Current wisdom here seems to converge on the idea that one of the disks (there's a total of six, four on a 2940, two on a NCR) is bad. Personally, I rather suspect bad memory. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de See another pointless homepage at . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 10:55:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 37907153AB; Tue, 23 Mar 1999 10:55:41 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA24237; Tue, 23 Mar 1999 10:54:58 -0800 Date: Tue, 23 Mar 1999 10:54:58 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Charles Owens Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG, Brian Topping Subject: Re: fix for amanda chg-chio script to eject tape In-Reply-To: <36F6990E.1E5026DD@enc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the delay. I'm still ill with this cold ("I feel like a military school. Parts of me keep passing in and out"). > > What did the code in amanda used to be? > > Below is the Unload subroutine from the chg-chio script (Perl). I inserted my > commands to eject the tape just before the 'if' statement. Okay. > > At any rate, the 3.X SA driver does a PREVENT at open time, and an ALLOW > > at close- pretty much unconditionally. > > > > Some changers allow you to eject the tape whether the drive has it > > prevented or not, so which changers are you referring to? > > > > Wow... is the SA driver okay with a changer dong this? I'd made an assumption that > this wasn't cool. Okay... then the chg-chio code as is makes sense for this sort > of changer... but not mine. Some changers have extra wires going into the drive to force the eject. The LAGO datawheel (an ancient changer) comes to mind. So does the (Archive/Connor/Seagate) Python DAT changer. The SCSI changer model is a bit passive in this area- you get bits for an element that tell you whether the element is 'accessable'- but it's left to implementation or device as to *how* to make the element accessable when it isn't. How you can map this to usage of perl wrapped around chio I dunno- grep for ACCES I guess? > The system I'm using is a 28-tape changer from a company called MediaLogic. It has > a Sony AIT-1 drive (which, since sa(4) doesn't know the AIT extended features, is > being treated like just a big 8mm drive). (send me a manual and do some testing for me and the 'advanced' features may become available- *I* don't have 10-20K$ to buy one....) > > Once a tape is inserted into the drive it is completely beyond the reach of the > changer. When the tape is ejected by the OS, it hangs out in this intermediate > space from which the changer may come by and grab it. That's what I mean. You have to make it 'accessable'. I believe that amanda must not have worked with this kind of changer before. You'd get the same effect with an Exabyte 210. *Or* you need to use the 'eject on close' tape device for FreeBSD- that will save you from having to issue the 'mt offl'- but I don't know whether you are trying to use multiple tape files or not on a tape - that could be a problem, yup... > > > > > Also, an 'offline' does a 'rewind' too, so you only have to do one- but > > now that I think about it- *this* particular bit of additional code can > > cause you some problems for the changers that may be (incorrectly) > > strapped to then sequentially load the next cardtridge. > > > > So- could you give a couple more details as to what h/w you're working > > with, and maybe use a CAMDEBUG kernel and do a camcontrol -Ic on the tape > > and/or changer device to see why you needed to get the tape ejected? > > Is what I've told you above good for now? Let me know if you need more and I'll do > this camcontrol thing (but it'll take me a bit). > I'm still not sure whether there's a bug in either chio or sa. Surprise surprise- I don't think so in this case. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 11:17:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from posgate.acis.com.au (posgate.acis.com.au [203.14.230.14]) by hub.freebsd.org (Postfix) with ESMTP id 43AFB14E47; Tue, 23 Mar 1999 11:17:07 -0800 (PST) (envelope-from andymac@bullseye.apana.org.au) Received: from bullseye.apana.org.au (uucp@localhost) by posgate.acis.com.au (8.9.2/8.9.2/Debian/GNU) with UUCP id GAA26442; Wed, 24 Mar 1999 06:05:57 +1100 (EST) Received: from bullseye.apana.org.au (central.apana.org.au [203.9.107.245]) by bullseye.apana.org.au (8.8.8/8.8.8) with SMTP id UAA11569; Tue, 23 Mar 1999 20:19:11 +1100 (EST) (envelope-from andymac@bullseye.apana.org.au) Date: Tue, 23 Mar 1999 20:16:11 +1100 (EDT) From: Andrew MacIntyre To: "Kenneth D. Merry" Cc: "Mike O'Brien" , freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Odd messages In-Reply-To: <199903222216.PAA68834@panzer.plutotech.com> Message-ID: X-X-Sender: andymac@bullseye.apana.org.au 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 Mar 1999, Kenneth D. Merry wrote: {...} > > Mar 21 23:15:30 caern /kernel: da0 at ahc0 bus 0 target 0 lun 0 > > Mar 21 23:15:30 caern /kernel: da0: Fixed Direct Access SCSI-2 device > > Mar 21 23:15:30 caern /kernel: da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > > Mar 21 23:15:30 caern /kernel: da0: 2103MB (4308352 512 byte sectors: 64H 32S/T 2103C) {...} > What is a VP32210? I don't see that anywhere on Quantum's web site listing > of various model numbers. Its a Quantum Capella IIRC. I've one with the same firmware rev, but its on a NCR 810 controller in a 2.2.6 box. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andrew.macintyre@aba.gov.au (work) | Snail: PO Box 370 andymac@bullseye.apana.org.au (play) | Belconnen ACT 2616 Fido: Andrew MacIntyre, 3:620/243.18 | Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 12:23:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id DD096153E6; Tue, 23 Mar 1999 12:23:38 -0800 (PST) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id PAA18439; Tue, 23 Mar 1999 15:23:04 -0500 (EST) To: Charles Owens Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG Subject: Re: fix for amanda chg-chio script to eject tape References: <36F67829.6C6CB4CA@enc.edu> <36F681D6.E2234C61@enc.edu> From: Chris Shenton Date: 23 Mar 1999 15:23:04 -0500 In-Reply-To: Charles Owens's message of "Mon, 22 Mar 1999 12:45:58 -0500" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.45/Emacs 20.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Mar 1999 12:45:58 -0500, Charles Owens said: Charles> In order to get chg-chio from amanda 2.4.1p1 to work happily Charles> under FreeBSD-3_stable I had to add a few statements to the Charles> Unload subroutine to eject the tape prior to calling the chio Charles> command to move it back to its slot. Charles> Did the ch(4) driver used to handle the tape ejection step Charles> itself? If not, then I'm not sure I understand how the Charles> chio-script ever worked, since _somehow_ the st/sa tape Charles> driver needs to be told to release the tape before the Charles> changer can play with it. I haven't noticed any problem with this. I'm using 3.1-S, Amanda 2.4.1p1, and the Perl chg-chio script which the port installed into /usr/local/libexec/amanda/. I've got an Archive/Connor/Seagate Python 4xDDS2 changer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 13:36:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id D02FF14E1B; Tue, 23 Mar 1999 13:36:50 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id QAA28756; Tue, 23 Mar 1999 16:29:33 -0500 (EST) Message-ID: <36F8073C.93168FDA@enc.edu> Date: Tue, 23 Mar 1999 16:27:25 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG, Brian Topping , "Snyder, Hal" Subject: Re: fix for amanda chg-chio script to eject tape References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > Sorry for the delay. I'm still ill with this cold ("I feel like a military > school. Parts of me keep passing in and out"). > > > > What did the code in amanda used to be? > > > > Below is the Unload subroutine from the chg-chio script (Perl). I inserted my > > commands to eject the tape just before the 'if' statement. > > Okay. > > > > At any rate, the 3.X SA driver does a PREVENT at open time, and an ALLOW > > > at close- pretty much unconditionally. > > > > > > Some changers allow you to eject the tape whether the drive has it > > > prevented or not, so which changers are you referring to? > > > > > > > Wow... is the SA driver okay with a changer dong this? I'd made an assumption that > > this wasn't cool. Okay... then the chg-chio code as is makes sense for this sort > > of changer... but not mine. > > Some changers have extra wires going into the drive to force the eject. > The LAGO datawheel (an ancient changer) comes to mind. So does the > (Archive/Connor/Seagate) Python DAT changer. > > The SCSI changer model is a bit passive in this area- you get bits for an > element that tell you whether the element is 'accessable'- but it's left > to implementation or device as to *how* to make the element accessable > when it isn't. How you can map this to usage of perl wrapped around chio I > dunno- grep for ACCES I guess? > Well... one question is whether there is any _problem_ for changers that CAN force an eject IF we have an explicit eject command (mt offl) before the tape handling command (chio move ...). If not, then great. If this IS a problem, then perhaps we could create a new amanda.conf parameter (e.g. "tpchanger_explicit_eject=yes") to control whether the 'mt offl' happens or not. Comments? Nick: it seems you're of the opinion that having explicit eject command will _not_ cause difficulty with any changers? (fine by me... as long as owners of can-force-eject changers all agree) > > > The system I'm using is a 28-tape changer from a company called MediaLogic. It has > > a Sony AIT-1 drive (which, since sa(4) doesn't know the AIT extended features, is > > being treated like just a big 8mm drive). > > (send me a manual and do some testing for me and the 'advanced' features > may become available- *I* don't have 10-20K$ to buy one....) > The AIT drives themselves are more like 3-5K$. I do actually have access to a manual which describes the added SCSI commands. Myself and another AIT drive owner have been looking at the problem a bit. So... yeah... we'd be more than happy to look at any code you'd come up with and/or have you examine ours. Are you serious about this? > > > > > Once a tape is inserted into the drive it is completely beyond the reach of the > > changer. When the tape is ejected by the OS, it hangs out in this intermediate > > space from which the changer may come by and grab it. > > That's what I mean. You have to make it 'accessable'. I believe that > amanda must not have worked with this kind of changer before. You'd get > the same effect with an Exabyte 210. > > *Or* you need to use the 'eject on close' tape device for FreeBSD- that > will save you from having to issue the 'mt offl'- but I don't know whether > you are trying to use multiple tape files or not on a tape - that could be > a problem, yup... I don't think the eject-on-close tape device is an option, as each partition that amanda is backing up results in a separate dump file... with amanda cramming as many on each tape as possible. > > > > > > > > > Also, an 'offline' does a 'rewind' too, so you only have to do one- but > > > now that I think about it- *this* particular bit of additional code can > > > cause you some problems for the changers that may be (incorrectly) > > > strapped to then sequentially load the next cardtridge. > > > > > > So- could you give a couple more details as to what h/w you're working > > > with, and maybe use a CAMDEBUG kernel and do a camcontrol -Ic on the tape > > > and/or changer device to see why you needed to get the tape ejected? > > > > Is what I've told you above good for now? Let me know if you need more and I'll do > > this camcontrol thing (but it'll take me a bit). > > > > I'm still not sure whether there's a bug in either chio or sa. Surprise > surprise- I don't think so in this case. > > -matt Yeah... I'm thinking you're right. Just differences in hardware behavior. -- --- ------------------------------------------------------------------------- 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 Tue Mar 23 13:53:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 63940154A7; Tue, 23 Mar 1999 13:52:49 -0800 (PST) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-139.skylink.it [194.177.113.139]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id WAA31399; Tue, 23 Mar 1999 22:50:58 +0100 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id XAA02618; Tue, 23 Mar 1999 23:50:24 +0100 (CET) Date: Tue, 23 Mar 1999 23:50:24 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Charles Owens Cc: mjacob@feral.com, cwt@FreeBSD.ORG, kingsled@enc.edu, freebsd-scsi@FreeBSD.ORG, Brian Topping , "Snyder, Hal" Subject: Re: fix for amanda chg-chio script to eject tape In-Reply-To: <36F8073C.93168FDA@enc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I assume that if the eject and move commands are separate, there is an offload space for the tape. If not, and the commands are given in the wrong order, or there is a timing problem, then the tape gets stuck somewhere and the drive has to be opened. Does not sound very likely. I'm online... just a minute... Don't you love unix? to be able work from home? well, maybe not, no... come on... In the TSL-7000 Sony drive we have this has actually a problematic effect: [root@mda07 toor]# chio status picker 0: slot 0: slot 1: slot 2: ... [root@mda07 toor]# mt -f /dev/nrst0 offline [root@mda07 toor]# chio status picker 0: slot 0: slot 1: slot 2: slot 3: ... It forwards me to the next tape. Gravity stacker, and then the next command fails. So maybe the reqest for an extra flag is better. I'll do that tomorrow. Cheers, Nick On Tue, 23 Mar 1999, Charles Owens wrote: > Nick: it seems you're of the opinion that having explicit eject command will _not_ cause > difficulty with any changers? (fine by me... as long as owners of can-force-eject > changers all agree) -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 14: 0:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id 611FF14CB8 for ; Tue, 23 Mar 1999 14:00:07 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id QAA29798; Tue, 23 Mar 1999 16:53:07 -0500 (EST) Message-ID: <36F80CC3.6FDE916C@enc.edu> Date: Tue, 23 Mar 1999 16:50:59 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, nick.hibma@jrc.it Subject: amanda changer.c: strange pclose/wait4 result code handling 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 guessing that this is a good place for me to discuss a FreeBSD-specific (I think) amanda problem. If not... sorry. This was first posted to the amanda-hackers list with no response. ] I've been having some trouble getting the chg_chio changer script to work happily from amtape (v2.4.1p1). This is on a FreeBSD 3-stable system... using a MediaLogic AIT tape library. Calling the chg-chio script by hand works fine. But when called through amtape, some of the amtape subcommands (at least: show, taper, current) produce the error: amtape: could not get changer info: 28 1 I traced the problem to the changer_command subroutine and how the exit code being produced by the changer script is being handled. Here's a snippet from changer_command() in changer.c, starting just after we get done waiting for the changer script to finish. exitcode = pclose(cmdpipe); cmdpipe = NULL; /* mark out-of-control changers as fatal error */ if(WIFSIGNALED(exitcode)) { ap_snprintf(number, sizeof(number), "%d", WTERMSIG(exitcode)); cmd = newvstralloc(cmd, " ", changer_resultstr, " (got signal ", number, ")", NULL); amfree(changer_resultstr); changer_resultstr = cmd; cmd = NULL; exitcode = 2; } else { exitcode = WEXITSTATUS(exitcode); } After the pclose call (first line), exitcode is set to what appears to me to be the PID of the exiting child... which from my read of the wait4(2) man pages means that things are happy. As expected WIFSIGNALED(exitcode) returns false. WEXITSTATUS(exitcode) should return the exit code returned by the exiting child (in this case chg-chio). I expect it to be zero, but for some reason I get 141 every time (but from looking at chg-chio code I'm pretty sure it's not returning 141). changer_command returning a non-zero exit code gives the calling routines the impression that the changer isn't happy somehow. As an experiement I replaced the WEXITSTATUS line with exitcode = 0; After doing this amtape sub-commands taper, show, etc. work fine! So, any ideas as to what's really going on here? Anyone else seen this? Is this a FreeBSD 3.x thing? From what I can tell from the FreeBSD man pages it should work as is, but it doesn't. 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 Tue Mar 23 14: 2:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 7EC2314E2D for ; Tue, 23 Mar 1999 14:02:19 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA14682 for freebsd-scsi@FreeBSD.ORG; Tue, 23 Mar 1999 23:02:00 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id WAA25760; Tue, 23 Mar 1999 22:54:41 +0100 (MET) (envelope-from j) Message-ID: <19990323225441.54729@uriah.heep.sax.de> Date: Tue, 23 Mar 1999 22:54:41 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Umlauts [was: Re: cvs commit: src/sys/cam cam_xpt.c] Reply-To: Joerg Wunsch References: <19990323081900.52443@uriah.heep.sax.de> <199903220215.TAA63620@panzer.plutotech.com> <19990323081900.52443@uriah.heep.sax.de> <199903231633.JAA02400@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: <199903231633.JAA02400@harmony.village.org>; from Warner Losh on Tue, Mar 23, 1999 at 09:33:26AM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Warner Losh wrote: > That's why you can use oe rather than ö. This is true for the > german umlaut, but I don't know about other languages. Yep, e transcriptions are quite common here (`ß' is transcripted as `ss' then), as well as the LaTeX transcriptions like "a for ä. I don't think other languages use anything like this, so in case you can't spell Søren Schmidt correctly, it's IMHO best to call him Soren instead. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 14: 2:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 3D684153D2 for ; Tue, 23 Mar 1999 14:02:25 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id XAA14683 for freebsd-scsi@FreeBSD.ORG; Tue, 23 Mar 1999 23:02:06 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id WAA25783; Tue, 23 Mar 1999 22:57:56 +0100 (MET) (envelope-from j) Message-ID: <19990323225755.29776@uriah.heep.sax.de> Date: Tue, 23 Mar 1999 22:57:55 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <19990323080808.54827@uriah.heep.sax.de> <199903231718.KAA74235@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903231718.KAA74235@panzer.plutotech.com>; from Kenneth D. Merry on Tue, Mar 23, 1999 at 10:18:07AM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > > I was only able to reduce the number of tagged openings to 1. > > Right. But to get it to 1, you have to disable tagged queueing. Hmm. Now that you name it -- i can't get it below 2 at all. Using `camcontrol negotiate ... -T disable' doesn't seem to have any effect for me. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 14: 3:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id D1BF2153D2 for ; Tue, 23 Mar 1999 14:03:34 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id QAA29921; Tue, 23 Mar 1999 16:55:55 -0500 (EST) Message-ID: <36F80D6B.72DA5D45@enc.edu> Date: Tue, 23 Mar 1999 16:53:47 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: ch(4) driver is noisy References: <199903221902.MAA26990@narnia.plutotech.com> Content-Type: multipart/alternative; boundary="------------3B23D7ECAB1B5BEB245AD9E6" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --------------3B23D7ECAB1B5BEB245AD9E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Justin, After applying your patch... this is what I get... whadaya think? Mar 23 16:41:09 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail(2) != count(1) Mar 23 16:41:09 r2s3 /kernel: ch: warning: could not map element source address 19190d to a valid element type Thanks, Charles "Justin T. Gibbs" wrote: > In article <36F684F6.FF645E3B@enc.edu> you wrote: > > Every time I use the chio command to control my tape library > > (MediaLogic) I get a kernal message or the sort > > > > Mar 22 12:29:42 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail != count > > Hmm. This will take a little more investigation on my part to see how > the code is supposed to work. It seems that chio is not requesting > the same number of elements to be reported as known to your changer > device. Can you apply this patch which will instrument the code and > help me figure out what is going on. > > -- > Justin > > ==== //depot/cam/sys/cam/scsi/scsi_ch.c#18 - /a/perforce/src/sys/cam/scsi/scsi_ch.c ==== > *** /tmp/tmp.26982.0 Mon Mar 22 12:02:10 1999 > --- /a/perforce/src/sys/cam/scsi/scsi_ch.c Mon Mar 22 12:02:02 1999 > *************** > *** 1189,1195 **** > > if (avail != cesr->cesr_element_count) { > xpt_print_path(periph->path); > ! printf("warning, READ ELEMENT STATUS avail != count\n"); > } > > user_data = (struct changer_element_status *) > --- 1189,1196 ---- > > if (avail != cesr->cesr_element_count) { > xpt_print_path(periph->path); > ! printf("warning, READ ELEMENT STATUS avail(%d) != count(%d)\n", > ! avail, cesr->cesr_element_count); > } > > user_data = (struct changer_element_status *) -- --- ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- --------------3B23D7ECAB1B5BEB245AD9E6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Justin,

After applying your patch... this is what I get... whadaya think? 

Mar 23 16:41:09 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail(2) != count(1)
Mar 23 16:41:09 r2s3 /kernel: ch: warning: could not map element source address 19190d to a valid element type
Thanks,

Charles

"Justin T. Gibbs" wrote:

In article <36F684F6.FF645E3B@enc.edu> you wrote:
> Every time I use the chio command to control my tape library
> (MediaLogic) I get a kernal message or the sort
>
> Mar 22 12:29:42 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail != count

Hmm.  This will take a little more investigation on my part to see how
the code is supposed to work.  It seems that chio is not requesting
the same number of elements to be reported as known to your changer
device.  Can you apply this patch which will instrument the code and
help me figure out what is going on.

--
Justin

==== //depot/cam/sys/cam/scsi/scsi_ch.c#18 - /a/perforce/src/sys/cam/scsi/scsi_ch.c ====
*** /tmp/tmp.26982.0    Mon Mar 22 12:02:10 1999
--- /a/perforce/src/sys/cam/scsi/scsi_ch.c      Mon Mar 22 12:02:02 1999
***************
*** 1189,1195 ****

        if (avail != cesr->cesr_element_count) {
                xpt_print_path(periph->path);
!               printf("warning, READ ELEMENT STATUS avail != count\n");
        }

        user_data = (struct changer_element_status *)
--- 1189,1196 ----

        if (avail != cesr->cesr_element_count) {
                xpt_print_path(periph->path);
!               printf("warning, READ ELEMENT STATUS avail(%d) != count(%d)\n",
!                      avail, cesr->cesr_element_count);
        }

        user_data = (struct changer_element_status *)

--
---
-------------------------------------------------------------------------
  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
-------------------------------------------------------------------------
  --------------3B23D7ECAB1B5BEB245AD9E6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 14:50:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id D41E61540E for ; Tue, 23 Mar 1999 14:50:24 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA75976; Tue, 23 Mar 1999 15:50:01 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903232250.PAA75976@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <19990323225755.29776@uriah.heep.sax.de> from J Wunsch at "Mar 23, 1999 10:57:55 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 23 Mar 1999 15:50:01 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... > As Kenneth D. Merry wrote: > > > > I was only able to reduce the number of tagged openings to 1. > > > > Right. But to get it to 1, you have to disable tagged queueing. > > Hmm. Now that you name it -- i can't get it below 2 at all. Using > `camcontrol negotiate ... -T disable' doesn't seem to have any effect > for me. Well, don't worry about the number once you disable tagged queueing. It is disabled. The number of tags only applies when tagged queueing is enabled. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 17:48:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 46FB214E16; Tue, 23 Mar 1999 17:48:34 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id CAA05343; Wed, 24 Mar 1999 02:48:15 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10Pcj0-000WyPC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Wed, 24 Mar 1999 02:44:54 +0100 (CET) Message-Id: Date: Wed, 24 Mar 1999 02:44:54 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) To: freebsd-scsi@freebsd.org Cc: freebsd-chat@freebsd.org Reply-To: freebsd-chat@freebsd.org Subject: Re: Umlauts In-Reply-To: <19990323225441.54729@uriah.heep.sax.de> References: <19990323081900.52443@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote: [ German umlauted vowel -> vowel + 'e' substitution ] > I don't think other languages use anything like this, It depends on the language. The French just leave off their various diacritical marks if unavailable. > so in case you can't spell Søren Schmidt correctly, it's IMHO best to > call him Soren instead. I can't speak for Søren, but unless he tells me differently, I will consider "Soeren" to be more polite. Check out some dk.* groups with Deja News. It takes about a minute to find several people who use "oe" in their e-mail address or header version of their name but 'ø' in their signature. That 'æ' is expanded to "ae" shouldn't come as a surprise, and 'å' becomes "aa". (Let's move this to -chat.) -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de >H Deutsche Transhumanismus-Mailingliste echo 'subscribe trans-de' | mail majordomo@lists.rhein-neckar.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 23 20:14:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from is2.net.ohio-state.edu (is2.net.ohio-state.edu [128.146.48.9]) by hub.freebsd.org (Postfix) with SMTP id 6FCDE15474 for ; Tue, 23 Mar 1999 20:14:01 -0800 (PST) (envelope-from maf@dev1.net.ohio-state.edu) Received: (qmail 8997 invoked from network); 24 Mar 1999 04:13:42 -0000 Received: from dev1.net.ohio-state.edu (128.146.222.3) by is2.net.ohio-state.edu with SMTP; 24 Mar 1999 04:13:42 -0000 Received: (qmail 24468 invoked by uid 4454); 24 Mar 1999 04:13:41 -0000 Message-ID: <19990323231341.A24357@net.ohio-state.edu> Date: Tue, 23 Mar 1999 23:13:41 -0500 From: Mark Fullmer To: dg@root.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Mylex DAC960SX question References: <19990322164245.A16014@net.ohio-state.edu> <199903230038.QAA19330@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199903230038.QAA19330@implode.root.com>; from David Greenman on Mon, Mar 22, 1999 at 04:38:30PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Looks like the DAC960SX is misconfigured. I use that RAID controller on > wcarchive and it works fine if properly configured. It shouldn't be reporting > unused LUNs for one thing. Also, you might try changing something in the > Adaptec SCSI BIOS config and saving the results. I've found that there seems > to be an parameter initialization problem (with FreeBSD) on new ahc boards if > you don't do this first. Something was confused, I'm not sure what though. After creating a DOS boot floppy with the Adaptec ASPI drivers on it and rebuilding the array with RAIDfx everything appears normal. da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 246673MB (505186304 512 byte sectors: 255H 63S/T 31446C) /dev/da1s1e 503089182 2 462842046 0% /home/crunch1/c Thanks. -- mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 5:33:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (Postfix) with ESMTP id 3031D14C19 for ; Wed, 24 Mar 1999 05:33:13 -0800 (PST) (envelope-from owensc@enc.edu) Received: from enc.edu ([10.1.20.106]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id IAA17569; Wed, 24 Mar 1999 08:25:33 -0500 (EST) Message-ID: <36F8E74F.FC6BA467@enc.edu> Date: Wed, 24 Mar 1999 08:23:28 -0500 From: Charles Owens Organization: Eastern Nazarene College X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: ch(4) driver is noisy References: <199903221902.MAA26990@narnia.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ someone commented that I posted this as HTML... sorry... this should be plain text now ] Justin, After applying your patch... this is what I get... whadaya think? Mar 23 16:41:09 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ ELEMENT STATUS avail(2) != count(1) Mar 23 16:41:09 r2s3 /kernel: ch: warning: could not map element source address 19190d to a valid element type Thanks, Charles "Justin T. Gibbs" wrote: > In article <36F684F6.FF645E3B@enc.edu> you wrote: > > Every time I use the chio command to control my tape library > > (MediaLogic) I get a kernal message or the sort > > > > Mar 22 12:29:42 r2s3 /kernel: (ch0:ahc0:0:5:0): warning, READ > ELEMENT STATUS avail != count > > Hmm. This will take a little more investigation on my part to see how > > the code is supposed to work. It seems that chio is not requesting > the same number of elements to be reported as known to your changer > device. Can you apply this patch which will instrument the code and > help me figure out what is going on. > > -- > Justin > > ==== //depot/cam/sys/cam/scsi/scsi_ch.c#18 - > /a/perforce/src/sys/cam/scsi/scsi_ch.c ==== > *** /tmp/tmp.26982.0 Mon Mar 22 12:02:10 1999 > --- /a/perforce/src/sys/cam/scsi/scsi_ch.c Mon Mar 22 12:02:02 > 1999 > *************** > *** 1189,1195 **** > > if (avail != cesr->cesr_element_count) { > xpt_print_path(periph->path); > ! printf("warning, READ ELEMENT STATUS avail != > count\n"); > } > > user_data = (struct changer_element_status *) > --- 1189,1196 ---- > > if (avail != cesr->cesr_element_count) { > xpt_print_path(periph->path); > ! printf("warning, READ ELEMENT STATUS avail(%d) != > count(%d)\n", > ! avail, cesr->cesr_element_count); > } > > user_data = (struct changer_element_status *) -- --- ------------------------------------------------------------------------- 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 Wed Mar 24 5:47:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5B63114C0B for ; Wed, 24 Mar 1999 05:47:24 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id OAA95835; Wed, 24 Mar 1999 14:47:03 +0100 (CET) (envelope-from des) To: scsi@freebsd.org Subject: Sony AIT streamers / changers From: Dag-Erling Smorgrav Date: 24 Mar 1999 14:47:02 +0100 Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anybody have any experience with Sony AIT streamers and autoloaders? Specifically, do they work as expected with the CAM st0 / ch0 drivers, and are they as reliable as Sony claims they are? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 9:13:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from shadows.aeon.net (shadows.aeon.net [195.197.32.30]) by hub.freebsd.org (Postfix) with ESMTP id 9AC5415495 for ; Wed, 24 Mar 1999 09:10:00 -0800 (PST) (envelope-from bsdscsi@shadows.aeon.net) Received: (from bsdscsi@localhost) by shadows.aeon.net (8.9.1/8.8.3) id TAA11456; Wed, 24 Mar 1999 19:08:50 +0200 (EET) From: mika ruohotie Message-Id: <199903241708.TAA11456@shadows.aeon.net> Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903222252.PAA69062@panzer.plutotech.com> from "Kenneth D. Merry" at "Mar 22, 1999 3:52:14 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 24 Mar 1999 19:08:50 +0200 (EET) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > any patches i could try? i mean, like, i'm ready to try anything > Tor Egge came up with a work-around that seems to solve the problem most of cool. > I upgraded a number of machines this weekend, and I had the same hang > problem on a system with an onboard 7890. I fixed it with the above patch. > > Send some mail to the list once you try the patch and let people know > whether it works for you or not. i think it worked. i mean, i have a collection of 9 machines running march 14th current and those gave me problems... (cloned from one disk into each 8 others) today i cvsuped (i checked that the patch had been committed) and made kernel for one of the machines. (just kernel, bad idea but since it didnt break top/w/ps i didnt bother to make world) no hangs in that machine ever since. then i copied the kernel into the other machines, didnt compile it in those 8 others which share the same binaries. for some reason the first boot in some of them hanged, none of the following reboots hanged any of them. i tested multiple boots after some downtime, and rebooting when machine is warm. so i can claim it worked for me too. thanx to everyone who were involved. but i keep myself ready for any additional testing... =) > Ken mickey ps. anyone wondering, yes, a production environment... :> (but i have an experience running current on production from like '94, i think i know what i do, so far been "safe") To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 9:15:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id BD5C215495 for ; Wed, 24 Mar 1999 09:15:48 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA80363; Wed, 24 Mar 1999 10:15:24 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903241715.KAA80363@panzer.plutotech.com> Subject: Re: Sony AIT streamers / changers In-Reply-To: from Dag-Erling Smorgrav at "Mar 24, 1999 2:47: 2 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Wed, 24 Mar 1999 10:15:24 -0700 (MST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote... > Does anybody have any experience with Sony AIT streamers and > autoloaders? Specifically, do they work as expected with the CAM st0 / > ch0 drivers, and are they as reliable as Sony claims they are? Yes, they work. We've got a Qualstar 4210 with an AIT-1 drive on board: at scbus1 target 5 lun 0 (pass4,sa0) at scbus1 target 6 lun 0 (pass5,ch0) As far as reliability, I haven't noticed any problems with the drive. But then we've only been using it for a couple of months. I think the tapes are expensive, but I suppose the price is to be expected. The changer occasionally gets confused/jammed when putting tapes in the drive, but that hasn't happened very often. Qualstar is: http://www.qualstar.com Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 11:42:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id 7818C14A14 for ; Wed, 24 Mar 1999 11:42:35 -0800 (PST) (envelope-from mikko@dynas.se) Received: (qmail 9556 invoked from network); 24 Mar 1999 19:42:14 -0000 Received: from spirit.sto.dynas.se (HELO spirit) (172.16.1.10) by karon.dynas.se with SMTP; 24 Mar 1999 19:42:14 -0000 Received: by spirit (Smail3.1.28.1 #32) id m10PtXa-000iSCC; Wed, 24 Mar 99 20:42:14 +0100 Date: Wed, 24 Mar 1999 20:42:13 +0100 (MET) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-Sender: mikko@spirit.dynas.se Reply-To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= To: freebsd-scsi@freebsd.org Subject: ZIP drive probe problems 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 Hello, My SCSI ZIP drive does not always get probed correctly at initial boot, and *never* if there is no ZIP inserted. This is on 3.1-STABLE as of March 22nd. I have an ncr810 is the first scsi-bus, with two disks and a CD, and an aha1542B is the second bus, with an external ZIP and sometimes a scanner. Cables are almost new, hopefully not of too crappy quality. And the same hardware worked with 2.2.8 (w/o CAM). Dmesg output for the Adaptec controller looks like: aha0 at 0x330-0x333 irq 9 drq 6 on isa aha0: AHA-1540/1542 64 head BIOS FW Rev. 1.2 (ID=41) SCSI Host Adapter, SCSI ID 7, 16 CCBs [...] (da2:aha0:0:5:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:aha0:0:5:0): error code 0 (da2:aha0:0:5:0): fatal error, failed to attach to device (da2:aha0:0:5:0): lost device (da2:aha0:0:5:0): removing device entry So, I think I can locate the place in scsi_da.c where this comes from, but then what... :( A "camcontrol rescan 1" will locate the drive, as will rebooting with a ZIP inside. Anybody else seeing this? Hints, suggestions or patches are welcome. BTW: Is there any way to get CAM to attach a device, other than pass, to a device after boot? /Mikko Mikko Tyo"la"ja"rvi________________________________mikko@securitydynamics.com SecurityDynamics To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 11:51: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 02B0814DF6 for ; Wed, 24 Mar 1999 11:51:03 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA17849; Wed, 24 Mar 1999 20:12:06 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id TAA00981; Wed, 24 Mar 1999 19:56:43 +0100 (CET) From: Wilko Bulte Message-Id: <199903241856.TAA00981@yedi.iaf.nl> Subject: Re: Sony AIT streamers / changers In-Reply-To: from Dag-Erling Smorgrav at "Mar 24, 1999 2:47: 2 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Wed, 24 Mar 1999 19:56:43 +0100 (CET) Cc: scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Dag-Erling Smorgrav wrote ... > Does anybody have any experience with Sony AIT streamers and > autoloaders? Specifically, do they work as expected with the CAM st0 / > ch0 drivers, and are they as reliable as Sony claims they are? I played with a standalone one once. Worked OK. And fast too. I can borrow one from the company and try it on a 4.0-current system if you like. Will take a bit of time though. We don't have any loaders for AIT. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 15:29: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from www1.asacomputers.com (unknown [204.153.176.244]) by hub.freebsd.org (Postfix) with ESMTP id A26E414C0B for ; Wed, 24 Mar 1999 15:29:00 -0800 (PST) (envelope-from kedar@asacomputers.com) Received: from kedar.asacomputers.com (kedar.asacomputers.com [204.153.176.86]) by www1.asacomputers.com (8.8.8/8.8.8) with SMTP id PAA11780 for ; Wed, 24 Mar 1999 15:39:07 -0800 (PST) (envelope-from kedar@asacomputers.com) Message-Id: <2.2.32.19990324232401.00c8f530@gw1> X-Sender: rajadnya@gw1 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Mar 1999 15:24:01 -0800 To: freebsd-scsi@freebsd.org From: Kedar Rajadnya Subject: DPT Ultra2-SCSI RAID? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Would anybody happen to know if there are drivers in the works for DPT Ultra2 RAID controller?. TIA, Kedar. Take care, Kedar Rajadnya. ASA Computers, Inc. 200 East Trimble Road. San Jose, CA 95131. TEL: (408)232-5999 ext201 CELL: (408)799-7263 TOLL FREE:(877)538-1272 FAX: (408)232-5959 ***************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 16:13:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fxp.dhs.org (cx19313-a.nwptn1.va.home.com [24.2.49.151]) by hub.freebsd.org (Postfix) with ESMTP id 7872F15006 for ; Wed, 24 Mar 1999 16:13:48 -0800 (PST) (envelope-from jedgar@fxp.dhs.org) Received: from earth.fxp.dhs.org (earth.fxp.dhs.org [192.168.1.21]) by fxp.dhs.org (8.9.2/8.9.2) with ESMTP id TAA63692; Wed, 24 Mar 1999 19:13:16 -0500 (EST) (envelope-from jedgar@fxp.dhs.org) Date: Wed, 24 Mar 1999 19:13:16 -0500 (EST) From: "Chris D. Faulhaber" To: Dag-Erling Smorgrav Cc: scsi@FreeBSD.ORG Subject: Re: Sony AIT streamers / changers 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 24 Mar 1999, Dag-Erling Smorgrav wrote: > Does anybody have any experience with Sony AIT streamers and > autoloaders? Specifically, do they work as expected with the CAM st0 / > ch0 drivers, and are they as reliable as Sony claims they are? > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > I have access to a Sony SDX-300C (AIT) drive on current and stable systems if you need anything specific...no changer though. -------------------------------------------------------------- | All the true gurus I've met never | Chris D. Faulhaber | | claimed they were one, and always | | | pointed to someone better. | | -------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 17:19:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by hub.freebsd.org (Postfix) with ESMTP id 132DB14EFC for ; Wed, 24 Mar 1999 17:19:47 -0800 (PST) (envelope-from steve@gordian.com) X-bait: aablmeh@gordian.com,mmblmeh@gordian.com,zzblmeh@gordian.com Received: from delphi.gordian.com (delphi.gordian.com [192.73.220.125]) by gordius.gordian.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id RAA07349 for ; Wed, 24 Mar 1999 17:19:28 -0800 (PST) Received: from gordian.com (asclepius [192.73.220.254]) by delphi.gordian.com (8.7.2/8.6.9) with ESMTP id RAA03732 for ; Wed, 24 Mar 1999 17:19:26 -0800 (PST) Message-ID: <36F98F1E.638638D1@gordian.com> Date: Wed, 24 Mar 1999 17:19:26 -0800 From: Steve Khoo Organization: Gordian; Santa Ana Heights, CA X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.8-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT SmartRAID V Century References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone know what the status of DPT SmartRAID V driver project is? Is it close to release? Simon Shapiro wrote: > > Andre Oppermann, On 20-Jan-99 you wrote: > > Simon Shapiro wrote: > > > Greg Lehey, On 19-Jan-99 you wrote: > > -snip- > > > > SmartRAID III and SmartRAID IV. Shimon's working on a driver for > > > > the > > > > V, but it'll be a while yet. > > > > > > Yup. Some good news: > > > > > > * I should be able to devote some more time to it. > > > * I am making good progress > > > * I received some great great help > > > * A way to release the drivers in source is crystalizing > > > > Cool! But how does that translate into release dates? I have to build > > a box within the next 2-3 weeks... > > If you need to deploy a mission critical DPT solution, until further > notice, use the SmartCache IV. It will be few weeks before coding is done > on the V series, and even then it will have to go through weeks of testing, > stress-testing and more testing. RAID solutions are typically deployed > when one really hates data loss. Use a proven technology until I gather > the courage and confidence to recommend the new generation. > > Sincerely Yours, Shimon@Simon-Shapiro.ORG > 770.265.7340 > Simon Shapiro > > Unwritten code has no bugs and executes at twice the speed of mouth > > 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 Wed Mar 24 17:44:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns2.michweb.net (ns2.michweb.net [208.246.108.3]) by hub.freebsd.org (Postfix) with SMTP id EADDB14FAE for ; Wed, 24 Mar 1999 17:44:39 -0800 (PST) (envelope-from matt@ns2.michweb.net) Received: (qmail 19080 invoked by uid 101); 25 Mar 1999 01:44:19 -0000 Date: Wed, 24 Mar 1999 20:44:19 -0500 (EST) From: Matt Simerson To: Steve Khoo Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT SmartRAID V Century In-Reply-To: <36F98F1E.638638D1@gordian.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Mar 1999, Steve Khoo wrote: > Does anyone know what the status of DPT SmartRAID V driver project is? Is it > close to release? You were just told it in his email. Simon is "The MAN" when it comes to DPT drivers for FreeBSD and if if I'm not mistaken, also for BSDI. I have a half a dozen DPT RAID controllers in machines floating around that I admin and and some were on the bleeding edge of driver-dom. RAID installations are no place for beta testing drivers. Listen to Simon. Simon says use SmartRAID IV for a while. Matt > Simon Shapiro wrote: > > > > Andre Oppermann, On 20-Jan-99 you wrote: > > > Simon Shapiro wrote: > > > > Greg Lehey, On 19-Jan-99 you wrote: > > > -snip- > > > > > SmartRAID III and SmartRAID IV. Shimon's working on a driver for > > > > > the > > > > > V, but it'll be a while yet. > > > > > > > > Yup. Some good news: > > > > > > > > * I should be able to devote some more time to it. > > > > * I am making good progress > > > > * I received some great great help > > > > * A way to release the drivers in source is crystalizing > > > > > > Cool! But how does that translate into release dates? I have to build > > > a box within the next 2-3 weeks... > > > > If you need to deploy a mission critical DPT solution, until further > > notice, use the SmartCache IV. It will be few weeks before coding is done > > on the V series, and even then it will have to go through weeks of testing, > > stress-testing and more testing. RAID solutions are typically deployed > > when one really hates data loss. Use a proven technology until I gather > > the courage and confidence to recommend the new generation. > > > > Sincerely Yours, Shimon@Simon-Shapiro.ORG > > 770.265.7340 > > Simon Shapiro > > > > Unwritten code has no bugs and executes at twice the speed of mouth > > > > 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 > > `````````````````````````````````````````````````````````````````` Matt Simerson http://users.michweb.net/~matt MichWeb Inc. - President http://www.michweb.net The Art Farm - Technical Wizard http://www.theartfarm.com Better to dare Mighty Things and fail, than to live in __o a gray twilight where there is neither victory or _-\<,_ defeat. -- attributed to Theodore Roosevelt ......(_)/ (_) `````````````````````````````````````````````````````````````````` To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 17:57:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (Postfix) with ESMTP id 7585014C30 for ; Wed, 24 Mar 1999 17:57:24 -0800 (PST) (envelope-from girgen@partitur.se) Received: from d1o62.telia.com (root@d1o62.telia.com [195.198.198.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id CAA20564; Thu, 25 Mar 1999 02:56:52 +0100 (CET) Received: from stordatan.telia.com (t5o62p13.telia.com [195.198.199.13]) by d1o62.telia.com (8.8.8/8.8.5) with ESMTP id CAA29314; Thu, 25 Mar 1999 02:56:50 +0100 (MET) Received: from partitur.se (localhost [127.0.0.1]) by stordatan.telia.com (8.9.2/8.9.1) with ESMTP id CAA10850; Thu, 25 Mar 1999 02:56:51 +0100 (CET) (envelope-from girgen@partitur.se) Message-ID: <36F997E3.8C27650@partitur.se> Date: Thu, 25 Mar 1999 02:56:51 +0100 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: sv, en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi matt! Thanks for your response. So, what do you suggest? Seems ridiculous for a tape device not to support rewind! If I can't rewind it, it gets silly. I tried inserting the tape and make an mt fsf 1 right away; still problem, but I guess cam still tries to load the tape first, running samount... I guess one could just comment away the exit part in the code below, and see what happens... I don't have much experience with tape devices, apart from my old travan TR-4. This new tape is brand new, and I might be able to return it. Maybe I should get another piece of hardware? Suggestions? I've only heard bad opinions about DAT, but maybe they're better than the travan stuff? Anything has cheaper tapes than tr, too... I can't get them for less than close to $40 a piece here, and we're resellers... :( /Palle Matthew Jacob wrote: > > (removing freebsd-hardware from list). > > > in messages, the mt command gives the following "clues": > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): LOAD UNLOAD. CDB: 1b > > 0 0 0 1 0 > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): ILLEGAL REQUEST > > asc:4,3 > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > > ready, manual intervention required > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): REWIND. CDB: 1 0 0 0 > > 0 0 > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): NOT READY asc:4,3 > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > > ready, manual intervention required > > I just ordered an HP 20GB 'travan like' drive. It'll be interesting to see > if this is also that broken. > > And this is with the unit there *and* a tape inserted? Wow! That is > *really* fantastically broken that a tape drive that has a tape inserted > supports *neither* a load (to BOT) command or a REWIND. The load is > optional. The rewind is mandatory. That's amazing. > > I think I'll have to invent a new quirk for someething this broken. > The code that this is breaking on is the following in samount: > > /* > * *Very* first off, make sure we're loaded to BOT. > */ > scsi_load_unload(&ccb->csio, 2, sadone, MSG_SIMPLE_Q_TAG, FALSE, > FALSE, FALSE, 1, SSD_FULL_SIZE, 60000); > error = cam_periph_runccb(ccb, saerror, 0, SF_QUIET_IR, > &softc->device_stats); > if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) > cam_release_devq(ccb->ccb_h.path, 0, 0, 0, FALSE); > /* > * In case this doesn't work, do a REWIND instead > */ > if (error) { > scsi_rewind(&ccb->csio, 5, sadone, MSG_SIMPLE_Q_TAG, > FALSE, SSD_FULL_SIZE, > (SA_REWIND_TIMEOUT) * 60 * 1000); > error = cam_periph_runccb(ccb, saerror, 0, 0, > &softc->device_stats); > } > if (error) { > xpt_release_ccb(ccb); > goto exit; > } > > When you're trying to mount a tape, make sure you're at BOT. If the > rewind is failing- it's hard for me to really be sure I'm not overwriting > something I shouldn't be, but if this drive really is that busted, I'll > guss I'll quirk it so it doesn't matter. > > -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 18:33:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CF7CA14E78; Wed, 24 Mar 1999 18:33:53 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id SAA06088; Wed, 24 Mar 1999 18:33:20 -0800 Date: Wed, 24 Mar 1999 18:33:19 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Charles Owens Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG, Brian Topping , "Snyder, Hal" Subject: Re: fix for amanda chg-chio script to eject tape In-Reply-To: <36F8073C.93168FDA@enc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Well... one question is whether there is any _problem_ for changers that > CAN force an eject IF we have an explicit eject command (mt offl) before > the tape handling command (chio move ...). If not, then great. If this > IS a problem, then perhaps we could create a new amanda.conf parameter > (e.g. "tpchanger_explicit_eject=yes") to control whether the 'mt offl' > happens or not. Comments? > > Nick: it seems you're of the opinion that having explicit eject command > will _not_ cause difficulty with any changers? (fine by me... as long > as owners of can-force-eject changers all agree) Per nick's experience, I'd say yes. Like I said, a lot of changers have options that you set whether they autoload the next in a sequence- but it's better to let people set it. > > > > The system I'm using is a 28-tape changer from a company called MediaLogic. It has > > > a Sony AIT-1 drive (which, since sa(4) doesn't know the AIT extended features, is > > > being treated like just a big 8mm drive). > > > > (send me a manual and do some testing for me and the 'advanced' features > > may become available- *I* don't have 10-20K$ to buy one....) > > > > The AIT drives themselves are more like 3-5K$. I do actually have > access to a manual which describes the added SCSI commands. Myself > and another AIT drive owner have been looking at the problem a bit. > So... yeah... we'd be more than happy to look at any code you'd come up > with and/or have you examine ours. Are you serious about this? Sort of, but it's a low priority over getting to actually fix real problems for others (mostly for QIC drives right now). Which. I. Will. Do. Very. Soon. Now. That. I. Am. Almost. Over. This. Darn. Cold... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 24 21:32:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id DB7D41518D for ; Wed, 24 Mar 1999 21:32:27 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id VAA01253; Wed, 24 Mar 1999 21:25:58 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199903250525.VAA01253@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Darren Reed Cc: scsi@freebsd.org Subject: Re: scsi floppy drives. In-reply-to: Your message of "Thu, 25 Mar 1999 01:04:21 +1100." <199903241404.BAA22142@cheops.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Mar 1999 21:25:58 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > has anyone had any luck getting a floppy drive connected through a > scsi adapater ? i came across a floppy drive connect to something > which shows up as this: Yup, I've got one out of an old Decstation. > Mar 23 20:55:03 freebsd /kernel: (ahc0:0:0): "TEAC FC-1 HF 11 RV J" type 0 > removable SCSI 1 > Mar 23 20:55:03 freebsd /kernel: sd0(ahc0:0:0): Direct-Access > Mar 23 20:55:03 freebsd /kernel: sd0(ahc0:0:0): NOT READY asc:4,0 > Mar 23 20:55:03 freebsd /kernel: sd0(ahc0:0:0): Logical unit not ready, cause n > ot reportable > Mar 23 20:55:03 freebsd /kernel: sd0: could not get size > Mar 23 20:55:03 freebsd /kernel: > Mar 23 20:55:03 freebsd /kernel: sd0(ahc0:0:0): ILLEGAL REQUEST asc:26,0 Invalid > field in parameter list > Mar 23 20:55:03 freebsd /kernel: sd0 could not mode sense (4). Using fictitious > geometry > Mar 23 20:55:03 freebsd /kernel: 0MB (0 512 byte sectors) > > I've no idea whether it is a 720k or 1.4MB floppy - it is a 3.5" unit. This is normal; you don't have any media in it. Stick a disk in and DD to/from it - it ought to work. You probably wanted to send this to scsi@freebsd.org; I've redirected the reply accordingly. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 7:45:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from relay2.mail.uk.psi.net (relay2.mail.uk.psi.net [154.32.107.6]) by hub.freebsd.org (Postfix) with ESMTP id 07CB814D4E for ; Thu, 25 Mar 1999 07:45:34 -0800 (PST) (envelope-from amobbs@allstor-sw.co.uk) Received: from mail.plasmon.co.uk ([193.115.5.217]) by relay2.mail.uk.psi.net with smtp (Exim 2.02 #3) id 10QCJj-0000pv-00 for freebsd-scsi@freebsd.org; Thu, 25 Mar 1999 15:45:11 +0000 Received: by mail.plasmon.co.uk(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 8025673F.00564568 ; Thu, 25 Mar 1999 15:42:18 +0000 X-Lotus-FromDomain: PLASNOTES From: amobbs@allstor-sw.co.uk To: freebsd-scsi@freebsd.org Message-ID: <8025673F.0056448A.00@mail.plasmon.co.uk> Date: Thu, 25 Mar 1999 15:42:15 +0000 Subject: CAM flags Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Could somebody please explain what effect "CAM_DEV_QFRZDIS" has, beyond "Disable DEV Q freezing", i.e. what is "DEV Q freezing", do I want it disabled, and if so, why? In general, what flags should I use? I'm writing a driver to use the passthrough device driver, for both control and I/O. I've got CAM_PASS_ERR_RECOVER and the appropriate direction flag for a given command, is there anything else I should be aware of? Thanks, Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 8:48:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id DEFDF14CF6 for ; Thu, 25 Mar 1999 08:48:42 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id JAA86680; Thu, 25 Mar 1999 09:48:15 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903251648.JAA86680@panzer.plutotech.com> Subject: Re: CAM flags In-Reply-To: <8025673F.0056448A.00@mail.plasmon.co.uk> from "amobbs@allstor-sw.co.uk" at "Mar 25, 1999 3:42:15 pm" To: amobbs@allstor-sw.co.uk Date: Thu, 25 Mar 1999 09:48:15 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org amobbs@allstor-sw.co.uk wrote... > > Could somebody please explain what effect "CAM_DEV_QFRZDIS" has, beyond > "Disable DEV Q freezing", i.e. what is "DEV Q freezing", do I want it > disabled, and if so, why? Whenever an error occurs for a SCSI CCB, the command queue for the device in question is frozen until error recovery actions have completed. If you're writing an application that goes through the passthrough driver, and you want to do your own error recovery, you'll probably want to disable queue freezing since you control your own queue of commands, and can do your own error recovery. Otherwise, you'll have to unfreeze the queue if an error occurs. You can tell if the queue has been frozen by looking at the CAM_DEV_QFRZN bit of the status field in the CCB header. This only applies when autosense is enabled, which is the default. If autosense is disabled (CAM_DIS_AUTOSENSE), the controller won't freeze the queue in case of an error. > In general, what flags should I use? I'm writing a driver to use the > passthrough device driver, for both control and I/O. I've got > CAM_PASS_ERR_RECOVER and the appropriate direction flag for a given > command, is there anything else I should be aware of? Well, you'll only need to set the direction flag if you're using cam_fill_csio(), since all of the CCB building functions automatically set the direction flags properly. Remember to use CAM_DIR_NONE if the command does not transfer any data. (like Test Unit Ready) The CAM_PASS_ERR_RECOVER flag causes the kernel to do error recovery actions for commands that fail. For instance, if a device returns 0x04,0x02 (logical unit not ready, initializing command required), the error recovery code will issue a start unit command to try to spin it up. If the device returns 0x04,{0x00,0x01}, the error recovery code will send a test unit ready command every .5 seconds for a minute before giving up on the device becoming ready. Turning on the kernel's error recovery code is also necessary for retry counts to be honored at all. Without error recovery turned on, a command will not be retried. (since that is, by definition, a form of error recovery) If you want to do something other than the default kernel error recovery actions, you should disable queue freezing, and don't use the kernel's error recovery. It all depends on how simple or complex your application is. If you're writing a complex application, you may want to do your own error recovery. If it's a simple application (e.g. camcontrol), the kernel's error recovery may be sufficient. As for which flags to use, I think that pretty much covers it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 11: 4:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id AB4F714DBC for ; Thu, 25 Mar 1999 11:04:18 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA35035; Thu, 25 Mar 1999 11:54:47 -0700 (MST) Date: Thu, 25 Mar 1999 11:54:47 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903251854.LAA35035@narnia.plutotech.com> To: "Kenneth D. Merry" Cc: scsi@FreeBSD.org Subject: Re: CAM flags X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199903251648.JAA86680@panzer.plutotech.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199903251648.JAA86680@panzer.plutotech.com> you wrote: > amobbs@allstor-sw.co.uk wrote... >> >> Could somebody please explain what effect "CAM_DEV_QFRZDIS" has, beyond >> "Disable DEV Q freezing", i.e. what is "DEV Q freezing", do I want it >> disabled, and if so, why? > > Whenever an error occurs for a SCSI CCB, the command queue for the device > in question is frozen until error recovery actions have completed. > > If you're writing an application that goes through the passthrough driver, > and you want to do your own error recovery, you'll probably want to disable > queue freezing since you control your own queue of commands, and can do > your own error recovery. The choice of disabling freezing the queue really depends on how you do your error recovery. Having the queue frozen is almost essential for an application that uses overlapped commands regardless of whether they are a userland peripheral driver or one in the kernel. Without queue freezing, it is possible for a command queued after the one that received the error to be sent to the device before your error recovery routines can intervene. Without overlapped commands, you may feel that having to issue an extra ccb to unfreeze the queue for every error you encounter to be cumbersome. We actually added the flag for use by applications that have no concept of a frozen device queue, like cdrecord, at least until the application can be modified to understand the way CAM works. > Otherwise, you'll have to unfreeze the queue if an error occurs. You can > tell if the queue has been frozen by looking at the CAM_DEV_QFRZN bit of > the status field in the CCB header. > > This only applies when autosense is enabled, which is the default. If > autosense is disabled (CAM_DIS_AUTOSENSE), the controller won't freeze > the queue in case of an error. Not true. The queue will be frozen on any error unless the command requested that this feature be disabled. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 11:12:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (Postfix) with ESMTP id 416FA14C2D for ; Thu, 25 Mar 1999 11:12:55 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by atlrel2.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id OAA01742 for ; Thu, 25 Mar 1999 14:12:19 -0500 (EST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA131059154; Thu, 25 Mar 1999 11:12:34 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA20911 for ; Thu, 25 Mar 1999 11:12:33 -0800 (PST) Message-Id: <199903251912.LAA20911@mina.sr.hp.com> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 25 Mar 1999 02:56:51 +0100." <36F997E3.8C27650@partitur.se> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Mar 1999 11:12:33 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Palle Girgensohn and mjacob@feral.com wrote: > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): LOAD UNLOAD. CDB: 1b > > > 0 0 0 1 0 > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): ILLEGAL REQUEST > > > asc:4,3 > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > > > ready, manual intervention required > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): REWIND. CDB: 1 0 0 0 > > > 0 0 > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): NOT READY asc:4,3 > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > > > ready, manual intervention required > > > > I just ordered an HP 20GB 'travan like' drive. It'll be interesting to see > > if this is also that broken. Just FYI, the new OnStream 30GB ADR SCSI drive (see http://www.onstream.com) does similar things (under 3.1-RELEASE): (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:3:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc0:0:3:0): Invalid field in CDB (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc0:0:3:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc0:0:3:0): Invalid field in CDB The problem isn't restricted to travan drives only. ;-( -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 11:20:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id DDFCA14DF0 for ; Thu, 25 Mar 1999 11:20:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA09187; Thu, 25 Mar 1999 11:16:15 -0800 Date: Thu, 25 Mar 1999 11:16:15 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <199903251912.LAA20911@mina.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yes, somebody else has noticed this. What I want to know is why these units accept neither a LOAD to BOT or a REWIND. Is media loaded? On Thu, 25 Mar 1999, Darryl Okahata wrote: > Palle Girgensohn and mjacob@feral.com wrote: > > > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): LOAD UNLOAD. CDB: 1b > > > > 0 0 0 1 0 > > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): ILLEGAL REQUEST > > > > asc:4,3 > > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > > > > ready, manual intervention required > > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): REWIND. CDB: 1 0 0 0 > > > > 0 0 > > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): NOT READY asc:4,3 > > > > Mar 23 00:33:19 trumpet /kernel: (sa1:aha0:0:5:0): Logical unit not > > > > ready, manual intervention required > > > > > > I just ordered an HP 20GB 'travan like' drive. It'll be interesting to see > > > if this is also that broken. > > Just FYI, the new OnStream 30GB ADR SCSI drive (see > http://www.onstream.com) does similar things (under 3.1-RELEASE): > > (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > (sa0:ahc0:0:3:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc0:0:3:0): Invalid field in CDB > (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc0:0:3:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc0:0:3:0): Invalid field in CDB > > The problem isn't restricted to travan drives only. ;-( > > -- > Darryl Okahata > darrylo@sr.hp.com > > DISCLAIMER: this message is the author's personal opinion and does not > constitute the support, opinion, or policy of Hewlett-Packard, or of the > little green men that have been following him all day. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 11:44:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 0155614D1D for ; Thu, 25 Mar 1999 11:44:30 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id LAA09594; Thu, 25 Mar 1999 11:44:06 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA155631045; Thu, 25 Mar 1999 11:44:05 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA21406; Thu, 25 Mar 1999 11:44:04 -0800 (PST) Message-Id: <199903251944.LAA21406@mina.sr.hp.com> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 25 Mar 1999 11:16:15 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Mar 1999 11:44:04 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > Yes, somebody else has noticed this. It may have been me. I originally posted this message to freebsd-hardware, and then posted it to -scsi when there were no comments. > What I want to know is why these > units accept neither a LOAD to BOT or a REWIND. Is media loaded? Yes, although the media was "initialized" under Windows. I'm starting to wonder if this drive needs some very special driver support (in the same way that a win-modem or a win-printer needs special driver support). I may play with it some more, tonight, if I have the time. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 11:51:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id DBCAC1520A for ; Thu, 25 Mar 1999 11:51:20 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA09432; Thu, 25 Mar 1999 11:50:44 -0800 Date: Thu, 25 Mar 1999 11:50:44 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Palle Girgensohn Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <36F997E3.8C27650@partitur.se> 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 matt! Thanks for your response. > > So, what do you suggest? Seems ridiculous for a tape device not to > support rewind! If I can't rewind it, it gets silly. I tried inserting > the tape and make an mt fsf 1 right away; still problem, but I guess cam > still tries to load the tape first, running samount... I guess one could > just comment away the exit part in the code below, and see what > happens... > > I don't have much experience with tape devices, apart from my old travan > TR-4. This new tape is brand new, and I might be able to return it. > Maybe I should get another piece of hardware? Suggestions? I've only > heard bad opinions about DAT, but maybe they're better than the travan > stuff? Anything has cheaper tapes than tr, too... I can't get them for > less than close to $40 a piece here, and we're resellers... :( > Somebody else has had troubles too. I'm confused aboutt his drive. I think DAT is better than this stuff! It's hard to get good cheap drives though. I'm mostly a fan of DLT, but that's hard to get cheap too. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 11:55:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 603D214FF7 for ; Thu, 25 Mar 1999 11:55:50 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA09441; Thu, 25 Mar 1999 11:52:09 -0800 Date: Thu, 25 Mar 1999 11:52:09 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <199903251944.LAA21406@mina.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Yes, somebody else has noticed this. > > It may have been me. I originally posted this message to > freebsd-hardware, and then posted it to -scsi when there were no > comments. Uh- nope: Palle Girgensohn had the same trouble.. > > > What I want to know is why these > > units accept neither a LOAD to BOT or a REWIND. Is media loaded? > > Yes, although the media was "initialized" under Windows. I'm > starting to wonder if this drive needs some very special driver support > (in the same way that a win-modem or a win-printer needs special driver > support). > > I may play with it some more, tonight, if I have the time. > Well- this is a new one for me. I'm wondering whether the media has to be formatted- sort of like what the older Sony Beta units had to have happen. Try using camcontrol to run format on the media- maybe that'd work? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 12: 4:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 31CDC150CA for ; Thu, 25 Mar 1999 12:04:44 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id MAA19672; Thu, 25 Mar 1999 12:04:22 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA163542261; Thu, 25 Mar 1999 12:04:21 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id MAA21578; Thu, 25 Mar 1999 12:04:20 -0800 (PST) Message-Id: <199903252004.MAA21578@mina.sr.hp.com> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 25 Mar 1999 11:52:09 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Mar 1999 12:04:20 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > Uh- nope: > > Palle Girgensohn > > had the same trouble.. Oh, I thought he was having problems with a Travan-like drive. > Well- this is a new one for me. I'm wondering whether the media has to be > formatted- sort of like what the older Sony Beta units had to have happen. > Try using camcontrol to run format on the media- maybe that'd work? You may have touched upon something. The drive responds differently when you put in a blank tape vs an "initialized" tape. However, I tried the tests with an initialized tape, although the tape was initialized under Windows. I wonder if the "Invalid field in CDB" error is meaningful. If I find the time, I'll play with camcontrol to send different LOAD UNLOAD CDBs to the drive. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 12: 7:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EA1514C49 for ; Thu, 25 Mar 1999 12:07:53 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id NAA88036; Thu, 25 Mar 1999 13:07:26 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903252007.NAA88036@panzer.plutotech.com> Subject: Re: CAM flags In-Reply-To: <199903251854.LAA35035@narnia.plutotech.com> from "Justin T. Gibbs" at "Mar 25, 1999 11:54:47 am" To: gibbs@pluto.plutotech.com Date: Thu, 25 Mar 1999 13:07:26 -0700 (MST) Cc: scsi@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin T. Gibbs wrote... > In article <199903251648.JAA86680@panzer.plutotech.com> you wrote: > > Otherwise, you'll have to unfreeze the queue if an error occurs. You can > > tell if the queue has been frozen by looking at the CAM_DEV_QFRZN bit of > > the status field in the CCB header. > > > > This only applies when autosense is enabled, which is the default. If > > autosense is disabled (CAM_DIS_AUTOSENSE), the controller won't freeze > > the queue in case of an error. > > Not true. The queue will be frozen on any error unless the command > requested that this feature be disabled. That's not he case in the Adaptec driver. (Justin and I just discussed this, and it appears that in the other CAM drivers this is the case, and the Adaptec driver should be freezing the queue in the case of an error, even if autosense is disabled.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 12:43:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by hub.freebsd.org (Postfix) with ESMTP id 9D545153CB for ; Thu, 25 Mar 1999 12:43:10 -0800 (PST) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by melete.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA13598 for ; Thu, 25 Mar 1999 13:42:51 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id NAA16449 for ; Thu, 25 Mar 1999 13:42:49 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id PAA14888; Thu, 25 Mar 1999 15:42:48 -0500 (EST) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14074.40903.652186.642090@hip186.ch.intel.com> Date: Thu, 25 Mar 1999 13:42:47 -0700 (MST) To: freebsd-scsi@freebsd.org Subject: need confirmation of 53C810 (DC-310) support in 3.x X-Mailer: VM 6.70 under Emacs 19.34.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I'm shopping for an "in-expensive" (yet supported!) SCSI card to hook a scanner up to. I think I've settled on one based upon the 53C810 Symbios chipset. The particular OEM card is from Tekram--the model is "DC-310". When the release notes say that there is support for the 53C810 does that imply support for all cards based upon this chip? Specifically are people using this DC-310 card under 3.1 (and -current)? I hope so 'cuz it's nice and cheap ($39 from http://www.hypermicro.com/). Thanks, -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 12:46:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E3C69153CD for ; Thu, 25 Mar 1999 12:46:14 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA09705; Thu, 25 Mar 1999 12:42:42 -0800 Date: Thu, 25 Mar 1999 12:42:42 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <199903252004.MAA21578@mina.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Matthew Jacob wrote: > > > Uh- nope: > > > > Palle Girgensohn > > > > had the same trouble.. > > Oh, I thought he was having problems with a Travan-like drive. I'm sorry- you're right, but the symptoms are the same! > > > Well- this is a new one for me. I'm wondering whether the media has to be > > formatted- sort of like what the older Sony Beta units had to have happen. > > Try using camcontrol to run format on the media- maybe that'd work? > > You may have touched upon something. The drive responds > differently when you put in a blank tape vs an "initialized" tape. > However, I tried the tests with an initialized tape, although the tape > was initialized under Windows. > > I wonder if the "Invalid field in CDB" error is meaningful. If I > find the time, I'll play with camcontrol to send different LOAD UNLOAD > CDBs to the drive. The CDB for load is very straightforward: 0 opcode (0x1b) 1 Immed 2 3 4 EOT|RETEN|LOAD 5 Basically, we either set LOAD (to load to BOT) or clear LOAD (to unload the tape). We don't fool around with immediate, EOT or Retension. The LOAD command is 'optional'. The Rewind command is mandatory. What disturbs me more is the rejection of the Rewind command. What this means is that these devices are *so* broken likely that if you issue a 'load' command, it sends the device into the weeds. Try commenting out the Load and lemme know what happens. Man, the quality of tape devices is getting worse and worse. I'm almost inclined to *not* try and support these devices because if they're this bad, why should you trust your data to them? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 12:59:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 699B115548 for ; Thu, 25 Mar 1999 12:59:30 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id MAA26785; Thu, 25 Mar 1999 12:59:08 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA189225547; Thu, 25 Mar 1999 12:59:08 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id MAA22040; Thu, 25 Mar 1999 12:59:07 -0800 (PST) Message-Id: <199903252059.MAA22040@mina.sr.hp.com> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 25 Mar 1999 12:42:42 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Mar 1999 12:59:06 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > > Oh, I thought he was having problems with a Travan-like drive. > > I'm sorry- you're right, but the symptoms are the same! Yes, that is what's scary. We have two different types of drives, from two different manufacturers, with very similar problems. [ Actually, on further thought, it may not be so scary. I think it is possible that the developers didn't strictly follow the SCSI specs, but only implemented just enough to get the various PC backup programs to work. It wouldn't surprise me if these PC backup programs don't send REWIND, etc. ] > The CDB for load is very straightforward: Yes, I have the SCSI doc that talks about the various CDBs. I was going to try setting the immed bit. > Man, the > quality of tape devices is getting worse and worse. I'm almost inclined to > *not* try and support these devices because if they're this bad, why > should you trust your data to them? You could be right, but it's unclear if the quality is suffering. They may be violating the specs, but if the data reliability is good .... The jury's still out but, if these drives are reliable, I'd be willing to live with an ugly userland driver (as long as I can use something to pipe stuff to and from dump(1)). The price point's just too good. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 15: 1:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 61A9514D21 for ; Thu, 25 Mar 1999 15:01:13 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA89185; Thu, 25 Mar 1999 16:00:39 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903252300.QAA89185@panzer.plutotech.com> Subject: Re: ZIP drive probe problems In-Reply-To: from =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= at "Mar 24, 1999 8:42:13 pm" To: mikko@dynas.se Date: Thu, 25 Mar 1999 16:00:39 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM922402839-89075-0_ Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM922402839-89075-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mikko Työläjärvi wrote... > > Hello, > > My SCSI ZIP drive does not always get probed correctly at initial > boot, and *never* if there is no ZIP inserted. > > This is on 3.1-STABLE as of March 22nd. > > I have an ncr810 is the first scsi-bus, with two disks and a CD, > and an aha1542B is the second bus, with an external ZIP and > sometimes a scanner. Cables are almost new, hopefully not of too > crappy quality. And the same hardware worked with 2.2.8 (w/o CAM). > > Dmesg output for the Adaptec controller looks like: > > aha0 at 0x330-0x333 irq 9 drq 6 on isa > aha0: AHA-1540/1542 64 head BIOS FW Rev. 1.2 (ID=41) SCSI Host Adapter, SCSI ID 7, 16 CCBs > [...] > (da2:aha0:0:5:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da2:aha0:0:5:0): error code 0 > (da2:aha0:0:5:0): fatal error, failed to attach to device > (da2:aha0:0:5:0): lost device > (da2:aha0:0:5:0): removing device entry > > > So, I think I can locate the place in scsi_da.c where this comes from, > but then what... :( Can you try the attached patch for scsi_da.c? I want to see why the drive isn't attaching. That error message doesn't tell me. It may be that I need to tweak the error printing code a bit. > A "camcontrol rescan 1" will locate the drive, as will rebooting with > a ZIP inside. > > Anybody else seeing this? Hints, suggestions or patches are welcome. > > BTW: Is there any way to get CAM to attach a device, other than > pass, to a device after boot? Not currently, unless you take it off the bus, rescan, and then put it back on the bus and rescan again. When a device is seen by the transport layer, it is broadcasted once to all of the peripheral drivers. It is up to the peripheral driver to 1. decide whether it is interested in that type of device and 2., do whatever it wants to decide whether to attach. In the case of the da and cd drivers, they send a read capacity to the device before attaching. The read capacity is allowed to fail with certain understandable error codes and the attach will still succeed. In your case, the controller tells us that we have valid sense data, but it appars that there actually is no sense data returned. The patch will help me figure out what is going on. Ken -- Kenneth Merry ken@plutotech.com --ELM922402839-89075-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=scsi_da.c.status_patch.032599 Content-Description: scsi_da.c.status_patch.032599 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_da.c#97 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c ==== *** /tmp/tmp.97479.0 Thu Mar 25 15:44:44 1999 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c Thu Mar 25 15:44:31 1999 *************** *** 1400,1405 **** --- 1400,1411 ---- if (have_sense) scsi_sense_print( &done_ccb->csio); + xpt_print_path(periph->path); + printf("got CAM status %#x\n", + done_ccb->ccb_h.status); + xpt_print_path(periph->path); + printf("SCSI status %#x\n", + done_ccb->csio.scsi_status); else { xpt_print_path(periph->path); printf("got CAM status %#x\n", --ELM922402839-89075-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 16:14:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 320C614D03 for ; Thu, 25 Mar 1999 16:14:26 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA89750; Thu, 25 Mar 1999 17:13:57 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903260013.RAA89750@panzer.plutotech.com> Subject: Re: ZIP drive probe problems In-Reply-To: <199903252300.QAA89185@panzer.plutotech.com> from "Kenneth D. Merry" at "Mar 25, 1999 4: 0:39 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Thu, 25 Mar 1999 17:13:57 -0700 (MST) Cc: mikko@dynas.se, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM922407237-89734-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM922407237-89734-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Oops, that last patch had a little syntax problem. Try this one instead. Ken -- Kenneth Merry ken@plutotech.com --ELM922407237-89734-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=scsi_da.c.status_patch.032599 Content-Description: scsi_da.c.status_patch.032599 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_da.c#97 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c ==== *** /tmp/tmp.98520.0 Thu Mar 25 17:12:51 1999 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c Thu Mar 25 17:12:17 1999 *************** *** 1397,1406 **** scsi_sense_desc(asc,ascq, &cgd.inq_data)); else { ! if (have_sense) scsi_sense_print( &done_ccb->csio); ! else { xpt_print_path(periph->path); printf("got CAM status %#x\n", done_ccb->ccb_h.status); --- 1397,1412 ---- scsi_sense_desc(asc,ascq, &cgd.inq_data)); else { ! if (have_sense) { scsi_sense_print( &done_ccb->csio); ! xpt_print_path(periph->path); ! printf("got CAM status %#x\n", ! done_ccb->ccb_h.status); ! xpt_print_path(periph->path); ! printf("SCSI status %#x\n", ! done_ccb->csio.scsi_status); ! } else { xpt_print_path(periph->path); printf("got CAM status %#x\n", done_ccb->ccb_h.status); --ELM922407237-89734-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 19:10:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id E364B15031 for ; Thu, 25 Mar 1999 19:10:24 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id TAA20418; Thu, 25 Mar 1999 19:10:04 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA091647803; Thu, 25 Mar 1999 19:10:03 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id TAA28367; Thu, 25 Mar 1999 19:10:02 -0800 (PST) Message-Id: <199903260310.TAA28367@mina.sr.hp.com> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 25 Mar 1999 12:42:42 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Mar 1999 19:10:02 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > The CDB for load is very straightforward: Ick. I've been playing around, and setting the "immed" bit makes things work. Both "LOAD UNLOAD" and "REWIND" work if the immed bit is set. However, "MODE SENSE(10)" isn't implemented, and I can't get "MODE SENSE(6)" to work. All the mode page codes I've tried (including pages 10h & 3fh), except for page 0, result in the usual "illegal request/parameter not supported" error. If I try page 0, I get a lovely: =============================================================================== (pass0:ahc0:0:3:0): SCB 0x4 - timed out in command phase, SEQADDR == 0x154 (pass0:ahc0:0:3:0): BDR message in message buffer (pass0:ahc0:0:3:0): no longer in timeout, status = 353 Unexpected busfree. LASTPHASE == 0x80 SEQADDR == 0x154 =============================================================================== Whee. Unless OnStream coughs up some documentation (or the Linux folks produce drivers in source form), I think this drive is a lost cause. Pity. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 19:27: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B943150D5 for ; Thu, 25 Mar 1999 19:27:04 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id TAA11500; Thu, 25 Mar 1999 19:23:10 -0800 Date: Thu, 25 Mar 1999 19:23:10 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <199903260310.TAA28367@mina.sr.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Very interesting. Usually things break if the Immediate bit is *set*. I wouldn't expect Mode Sense(10) to be set- and it's quite conceivable that a SCSI-1 Mode Sense (6) might work. What's the ANSI conformance level from the Inquiry data again? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 25 22:16:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 8FA0414F29 for ; Thu, 25 Mar 1999 22:16:17 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id WAA29106; Thu, 25 Mar 1999 22:15:56 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA033618955; Thu, 25 Mar 1999 22:15:56 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id WAA02323; Thu, 25 Mar 1999 22:15:55 -0800 (PST) Message-Id: <199903260615.WAA02323@mina.sr.hp.com> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 25 Mar 1999 19:23:10 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Mar 1999 22:15:54 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > Very interesting. Usually things break if the Immediate bit is *set*. > > I wouldn't expect Mode Sense(10) to be set- and it's quite conceivable > that a SCSI-1 Mode Sense (6) might work. What's the ANSI conformance level > from the Inquiry data again? SCSI-2. Heh. Here's the relevant dmesg stuff: sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.0MB/s transfers (10.0MHz, offset 7) Well, as I've said, I couldn't get mode sense (6) to work. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 26 11:24: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 76A3214E70 for ; Fri, 26 Mar 1999 11:24:05 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id LAA00626; Fri, 26 Mar 1999 11:16:08 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199903261916.LAA00626@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: Darryl Okahata , freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-reply-to: Your message of "Thu, 25 Mar 1999 19:23:10 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Mar 1999 11:16:07 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Very interesting. Usually things break if the Immediate bit is *set*. > > I wouldn't expect Mode Sense(10) to be set- and it's quite conceivable > that a SCSI-1 Mode Sense (6) might work. What's the ANSI conformance level > from the Inquiry data again? I just got off the phone with Jim Jonez at Onstream about the Onstream drive; they are working as we speak on pruning their sensitive intellectual property out of their hardware manual so they can make it available. I also took the opportunity to make the point that tape drives are meant to behave like tape drives, ie. that we shouldn't need their damn manual to talk to the drive in the first place. Overall things were pretty positive; I hope to hear from him later again today, and it sounds like we should be able to put documentation in various peoples' hands by the end of next week. I'll also try to arrange a backchannel for us to flame their developers directly. If anyone has any contacts with HP that would allow us to do similar things with their tape people, that'd be useful. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 26 11:37:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 58F2314FBA for ; Fri, 26 Mar 1999 11:37:37 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA14373; Fri, 26 Mar 1999 11:28:30 -0800 Date: Fri, 26 Mar 1999 11:28:29 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Mike Smith Cc: Darryl Okahata , freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-Reply-To: <199903261916.LAA00626@dingo.cdrom.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 > > If anyone has any contacts with HP that would allow us to do similar > things with their tape people, that'd be useful. > Which tape people? Look- I'm planning (still) to do the TapeAlert stuff. I have had a positive reaction from the HP folks about this. Other than that there's HP/Bristol (that's their DAT/Changer folks) and HP/Greeley which I believe is their Travan stuff... big company.... Err, umm- Darryl, maybe you can tell us (after all, you *are* hp.com...) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 26 12:13:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id E6B3115140 for ; Fri, 26 Mar 1999 12:13:15 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA00905; Fri, 26 Mar 1999 12:05:22 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199903262005.MAA00905@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: Darryl Okahata , freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-reply-to: Your message of "Fri, 26 Mar 1999 11:28:29 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Mar 1999 12:05:22 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > If anyone has any contacts with HP that would allow us to do similar > > things with their tape people, that'd be useful. > > > > Which tape people? Whichever ones are responsible for the drive in question. 8) > Look- I'm planning (still) to do the TapeAlert stuff. I have had a > positive reaction from the HP folks about this. > > Other than that there's HP/Bristol (that's their DAT/Changer folks) and > HP/Greeley which I believe is their Travan stuff... big company.... > > Err, umm- Darryl, maybe you can tell us (after all, you *are* hp.com...) Hmm, good point. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 26 13: 9:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 2C61E14E44 for ; Fri, 26 Mar 1999 13:09:13 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id NAA05579; Fri, 26 Mar 1999 13:08:43 -0800 (PST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA184282523; Fri, 26 Mar 1999 13:08:43 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id NAA19393; Fri, 26 Mar 1999 13:08:42 -0800 (PST) Message-Id: <199903262108.NAA19393@mina.sr.hp.com> To: mjacob@feral.com Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 26 Mar 1999 11:28:29 PST." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Mar 1999 13:08:42 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > Err, umm- Darryl, maybe you can tell us (after all, you *are* hp.com...) Err, I've got some old public documents for some old HP DAT drives (the 1533, at least), but that's about it. [ These documents cover hardware switch settings, as well as low-level SCSI commands. ] I'll see if I can dig up anything about the Travan drives, but I wouldn't hold your breath. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 27 2:44:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from miles.lambdawerks.org (dlci096.isomedia.com [209.102.112.96]) by hub.freebsd.org (Postfix) with ESMTP id 7C62614F82 for ; Sat, 27 Mar 1999 02:44:16 -0800 (PST) (envelope-from reggie@lambdawerks.org) Received: from trane.lambdawerks.org (trane.lambdawerks.org [209.102.113.58]) by miles.lambdawerks.org (8.9.2/8.9.3) with ESMTP id CAA00542 for ; Sat, 27 Mar 1999 02:44:37 -0800 (PST) (envelope-from reggie@lambdawerks.org) Received: from localhost (localhost [127.0.0.1]) by trane.lambdawerks.org (8.9.3/8.9.3) with ESMTP id CAA00720 for ; Sat, 27 Mar 1999 02:43:58 -0800 (PST) (envelope-from reggie@trane.lambdawerks.org) Message-Id: <199903271043.CAA00720@trane.lambdawerks.org> Prev-Resent: Sat, 27 Mar 1999 02:22:44 -0800 Prev-Resent: "freebsd-scsi@FreeBSD.ORG " Prev-Resent: Sat, 27 Mar 1999 02:18:54 -0800 Prev-Resent: "freebsd-scsi@FreeBSD.ORG " Reply-To: reggie@lambdawerks.org X-Mailer: MH 6.8.4 To: freebsd-scsi@FreeBSD.ORG Subject: Is this a problem with the card? Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 27 Mar 1999 02:10:59 -0800 From: "Reginald S. Perry" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, I am running -current built on the 19th of this month. I am concerend about my Buslogic 958. On boot I get these messages which I attach to this message. The machine is a dual pentium 166MMX system using a tyan tomcat III motherboard. I have 128MB of memory. My kernel config file is attached. The question is: is this a driver issue or a problem with the card. The reboot before I updated the machine looked normal. Thanks. -Reggie Mar 27 01:49:31 trane /kernel: bt0: rev 0x08 int a irq 17 on pci0.19.0 Mar 27 01:49:31 trane /kernel: bt0: BT-958 FW Rev. 5.06I Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs Mar 27 01:49:32 trane /kernel: sa0 at bt0 bus 0 target 5 lun 0 Mar 27 01:49:32 trane /kernel: sa0: Removable Sequential Access SCSI-2 device Mar 27 01:49:32 trane /kernel: bt0: btfetchtransinfo - Inquire Sync Info Failed 0x7 Mar 27 01:49:32 trane /kernel: sa0: 3.300MB/s transfers Mar 27 01:49:32 trane /kernel: da0 at bt0 bus 0 target 0 lun 0 Mar 27 01:49:32 trane /kernel: da0: Fixed Direct Access SCSI-2 device Mar 27 01:49:32 trane /kernel: bt0: bt_cmd: Timeout waiting for adapter ready, status = 0x4 Mar 27 01:49:32 trane /kernel: bt0: btfetchtransinfo - Inquire Setup Info Failed Mar 27 01:49:32 trane /kernel: da0: 3.300MB/s transfers Mar 27 01:49:32 trane /kernel: da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Mar 27 01:49:32 trane /kernel: da1 at bt0 bu Mar 27 01:49:32 trane /kernel: s 0 target 4 lun 0 Mar 27 01:49:32 trane /kernel: da1: Fixed Direct Access SCSI-2 device Mar 27 01:49:32 trane /kernel: bt0: bt_cmd: Timeout waiting for adapter ready, status = 0x4 Mar 27 01:49:32 trane /kernel: bt0: btfetchtransinfo - Inquire Setup Info Failed Mar 27 01:49:32 trane /kernel: da1: 3.300MB/s transfers Mar 27 01:49:32 trane /kernel: da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Mar 27 01:49:32 trane /kernel: changing root device to da0s1a Mar 27 01:49:32 trane /kernel: (cd0:bt0:0:1:0): CCB 0xc5666340 - timed out Mar 27 01:49:32 trane /kernel: (cd0:bt0:0:1:0): CCB 0xc5666340 - timed out Mar 27 01:49:32 trane /kernel: bt0: No longer in timeout Mar 27 01:49:32 trane /kernel: cd0 at bt0 bus 0 target 1 lun 0 Mar 27 01:49:32 trane /kernel: cd0: Removable CD-ROM SCSI-2 device Mar 27 01:49:32 trane /kernel: cd0: 10.000MB/s transfers (10.000MHz, offset 8) Mar 27 01:49:32 trane /kernel: cd0: cd present [251805 x 2048 byte records] # # TRANE -- Config file for Dual P5 166MMX w/ BT UW SCSI # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.108 1998/04/22 18:18:12 mjacob Exp $ machine "i386" cpu "I586_CPU" ident TRANE maxusers 64 # Mandatory: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SCSI_DELAY=15000 # Options for the VM subsystem options PQ_LARGECACHE # color for 512k/16k cache # # These three options provide support for System V Interface # Definition-style interprocess communication, in the form of shared # memory, semaphores, and message queues, respectively. # options SYSVSHM options SYSVSEM options SYSVMSG # # This option includes a MD5 routine in the kernel, this is used for # various authentication and privacy uses. # options "MD5" # # Allow processes to switch to vm86 mode, as well as enabling direct # user-mode access to the I/O port space. This option is necessary for # the doscmd emulator to run. # options "VM86" options VESA # needs VM86 defined too!! #options COMPAT_LINUX ##################################################################### # DEBUGGING OPTIONS # # Enable the kernel debugger. # options DDB options BREAK_TO_DEBUGGER #a BREAK on a comconsole goes to #DDB, if available. # # PERFMON causes the driver for Pentium/Pentium Pro performance counters # to be compiled. See perfmon(4) for more information. # options PERFMON config kernel root on wd0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus #options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM device wfd0 #IDE Floppy (e.g. LS-120) # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. #controller ncr0 #controller ahb0 #controller ahc0 #controller adv0 at isa? port ? cam irq ? controller bt0 at isa? port ? cam irq ? #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr controller scbus0 device da0 device sa0 device pass0 device cd0 #Only need one of these, the code dynamically grows # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? tty #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # `flags' for serial drivers that support consoles (only for sio now): # 0x10 enable console support for this unit. The other console flags # are ignored unless this is set. Enabling console support does # not make the unit the preferred console - boot with -h or set # the 0x20 flag for that. Currently, at most one unit can have # console support; the first one (in config file order) with # this flag set is preferred. Setting this flag for sio0 gives # the old behaviour. # 0x20 force this unit to be the console (unless there is another # higher priority console). This replaces the COMCONSOLE option. # 0x40 reserve this unit for low level console operations. Do not # access the device in any normal way. device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 9 vector siointr device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr options CONSPEED=19200 #default speed for serial console (default 9600) # Parallel port device ppc0 at isa? port? tty irq 7 controller ppbus0 device lpt0 at ppbus? device plip0 at ppbus? device ppi0 at ppbus? #controller vpo0 at ppbus? # Enable PnP support in the kernel. This allows you to automaticly # attach to PnP cards for drivers that support it and allows you to # configure cards from USERCONFIG. See pnp(4) for more info. controller pnp0 # Controls all "VOXWARE" driver sound devices. See Luigi's driver # below for an alternate which may work better for some cards. # controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 device awe0 at isa? port 0x620 # Luigi's snd code (use INSTEAD of snd0 and all VOXWARE drivers!). # You may also wish to enable the pnp controller with this, for pnp # sound cards. # #device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x15 vector pcmintr device ed0 at isa? port 0x280 net irq 10 iomem 0xc0000 # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 device fxp0 #device xl0 pseudo-device loop pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # # The INVARIANTS option is used in a number of source files to enable # extra sanity checking of internal structures. This support is not # enabled by default because of the extra time it would take to check # for these conditions, which can only occur as a result of # programming errors. # options INVARIANTS # # The INVARIANT_SUPPORT option makes us compile in support for # verifying some of the internal structures. It is a prerequisite for # 'INVARIANTS', as enabling 'INVARIANTS' will make these functions be # called. The intent is that you can set 'INVARIANTS' for single # source files (by changing the source file or specifying it on the # command line) if you have 'INVARIANT_SUPPORT' enabled. # options INVARIANT_SUPPORT # POSIX P1003.1B # Real time extensions added int the 1993 Posix # P1003_1B: Infrastructure # _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING # _KPOSIX_VERSION: Version kernel is built for options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 27 15:56:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 081851517F for ; Sat, 27 Mar 1999 15:55:58 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id QAA90534; Sat, 27 Mar 1999 16:55:35 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903272355.QAA90534@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Mon, 22 Mar 1999 14:08:52 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Mar 1999 16:46:25 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I had ethernet devices in mind when I setup the interrupt framework >> for CAM. > >You're sick man. :) Nah. I just noticed that NetBSD had such a driver and planned accordingly. >> But you can. Give me a little time, and I'll finish the support for this >> in the bus dma framework and hook it up in the controller drivers. You >> will need to set the CAM_SCATTER_VALID flag in the ccb-ccb_h.flags and >> not set the CAM_SG_LIST_PHYS flag. S/G lists with physical addresses >> (really bus addresses) are already supported by all controllers. > >Where might I see examples of this in action, or better yet, docs >describing its use? This ability will greatly reduce the overhead of >transmitting a packet. (Not that this device doesn't suck in other ways.) There really isn't a good document for this other than the CAM and bus dma header files (sys/cam/cam_ccb.h and sys/machine/include/bus.h). If you wish to use bus addresses, allocate an array of bus_dma_segment_ts, fill them in, send the address of the list in the data pointer of the SCSI I/O CCB, set the CCB segment count, and set the SG and SG_PHYS flags in the CCB. For KVA segments, the interface will be similar with the substitution of struct iovec for bus_dma_segment_t, but this hasn't been implemented yet. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 27 16: 0: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 33C0A14E6F for ; Sat, 27 Mar 1999 15:59:54 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id QAA90546; Sat, 27 Mar 1999 16:56:02 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903272356.QAA90546@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: "Matthew N. Dodd" , "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Mon, 22 Mar 1999 14:03:27 MST." <199903222103.OAA05087@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Mar 1999 16:46:51 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >: You're sick man. :) > >I wonder if terminal devices would fit into this framework... > >Warner With about 20 lines of code, yes. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message