From owner-freebsd-scsi Tue Jul 1 18:45:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA06245 for freebsd-scsi-outgoing; Tue, 1 Jul 1997 18:45:45 -0700 (PDT) Received: from tok.qiv.com ([204.214.141.211]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA06240 for ; Tue, 1 Jul 1997 18:45:42 -0700 (PDT) Received: (from uucp@localhost) by tok.qiv.com (8.8.5/8.8.5) with UUCP id UAA01297 for freebsd-scsi@freebsd.org; Tue, 1 Jul 1997 20:45:36 -0500 (CDT) Received: from localhost (jdn@localhost) by acp.qiv.com (8.8.5/8.8.5) with SMTP id UAA00630 for ; Tue, 1 Jul 1997 20:44:38 -0500 (CDT) X-Authentication-Warning: acp.qiv.com: jdn owned process doing -bs Date: Tue, 1 Jul 1997 20:44:37 -0500 (CDT) From: "Jay D. Nelson" To: freebsd-scsi@freebsd.org Subject: 2.2.2-RELEASE/Viper anomolies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a report rather than a plea. I've solved the problem, but it's left me curious. (Questions at end.) I have an Archive Viper 2525 attached to a Tekram DC300B ISA controller as the only external device. Prom version on the Viper is 007 which I know is problematic. Internal is a Quantum LPS240S, a Seagate Hawk and a Sony CD55S CD-Rom -- also off the same controller. External cable is from Sun, internal is flat ribbon. I installed 2.2.2 from WC CD. GENERIC kernel and all subsequent kernels I built would either not see the drive or (after any kind of access) leave it in a condition where only a power off would make it visable to the controller. The curiosity here is that under 2.2.1, I could coerce it to behave as a normal drive. After going back to 2.2.1, I can dump, restore and (after one change) I haven't seen any problems. This drive was packaged by Artecon and sold by Sun Express. It ran without problems on a Sun1+. (I know Sun has a penchant for proprietary proms, so I didn't expect much when I brought it over.) I did have problems under 2.1.[567]. The one thing that surprised me, though, was that this drive came with parity disabled. I understood that if parity was enabled, it should be enabled for every device on the bus. The drives I replaced on Sun systems all had parity enabled -- so I ASSumed, this drive was also. Since enabeling parity, I have had 0 problems with 2.2.1. So my questions are: Should all devices be parity enabled? -- or none? Is there anything I can do to make it acceptable to 2.2.2? Would putting it on a controller by itself be a benifit? What magic incantation does it take to get last prom release from Seagate? If anyone wants more information, I'd be happy to provide all I can. (Enabeling debugging didn't yield anything as far as I can tell.) Anyway, 2.2.1 works great with this combination. 2.2.2 doesn't. -- Jay From owner-freebsd-scsi Tue Jul 1 20:20:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA09959 for freebsd-scsi-outgoing; Tue, 1 Jul 1997 20:20:32 -0700 (PDT) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA09954 for ; Tue, 1 Jul 1997 20:20:28 -0700 (PDT) Received: by math.berkeley.edu (8.7.5/1.33(math)Ow.3) id UAA04700; Tue, 1 Jul 1997 20:20:22 -0700 (PDT) Date: Tue, 1 Jul 1997 20:20:22 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199707020320.UAA04700@math.berkeley.edu> To: freebsd-scsi@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE/Viper anomolies Cc: dan@math.berkeley.edu, jdn@qiv.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Should all devices be parity enabled? -- or none? All devices should be parity enabled. In most cases, they always generate SCSI bus parity and the "parity enable" option just causes them to check it. You should always try to check the configuration of every SCSI device that you install on a system. Vendors are particularly indifferent about enabling parity checking because they would rather that the end user lose an occasional bit than complain about mysterious error messages from his SCSI system. Not all models of sun checked SCSI bus parity under all releases of SunOS, probably to accommodate old sun SCSI peripherals which were still being sold with SS1s at the time the SS1s were first introduced. It might be that your SCSI tape drive has always generated bad SCSI parity and your SS1+ didn't care, though I think this less likely than some new problem (e.g. an excessively long SCSI bus operating at a faster speed), or perhaps the tape drive has problems with synchronous SCSI bus transfers (something else that SS1s and SS1+s didn't do by default on their motherboard SCSI bus). > Would putting it on a controller by itself be a benifit? I often do this with devices (such as a QIC tape drive) that are likely to hog the SCSI bus because the manufacturer doesn't want to spend more money on the SCSI interface than is necessary to make *his* device run at its full speed. I also like to keep my SCSI busses short and splitting them up helps a lot. Dan Strick dan@math.berkeley.edu From owner-freebsd-scsi Wed Jul 2 04:44:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA29527 for freebsd-scsi-outgoing; Wed, 2 Jul 1997 04:44:10 -0700 (PDT) Received: from weenix.guru.org (phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA29511 for ; Wed, 2 Jul 1997 04:44:03 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id HAA00749 for scsi@freebsd.org; Wed, 2 Jul 1997 07:44:01 -0400 (EDT) From: Keith Mitchell Message-Id: <199707021144.HAA00749@weenix.guru.org> Subject: Archive Viper and 3940UW (bad Drive?) To: scsi@freebsd.org Date: Wed, 2 Jul 1997 07:44:01 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Lately I have been having trouble getting my tape drive to work at all. I get BUS resets everytime I try to access the drive. I have tried moving it to a different BUS. using different cables as well as trying every statement in the SCSI-Select software of my 3940UW card. I know the BUS is terminated correctly (I have tried allowing the last drive on the chain [a wide drive] terminate the BUS and I have also tried using a self-terminating cable [one that has the terminator moded in at the end of the cable]). The verbose probe message for the drive is: st0 at scbus2 target 4 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access density code 0x13, 512-byte blocks, write-enabled and the BUS reset messages I get are: st0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 st0: abort message in message buffer st0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x94 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 ahc1: Issued Channel A Bus Reset. 3 SCBs aborted Clearing bus reset Clearing 'in-reset' flag st0: no longer in timeout ahc1: target 0 using 16Bit transfers st0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 st0: abort message in message buffer st0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x94 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 ahc1: Issued Channel A Bus Reset. 3 SCBs aborted Clearing bus reset Clearing 'in-reset' flag st0: no longer in timeout ahc1: target 0 using 16Bit transfers st0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 st0: abort message in message buffer st0: SCB 0x0 - timed out in command phase, SCSISIGI == 0x94 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 ahc1: Issued Channel A Bus Reset. 3 SCBs aborted Clearing bus reset Clearing 'in-reset' flag st0: no longer in timeout ahc1: target 0 using 16Bit transfers sd2: UNIT ATTENTION asc:29,0 sd2: Power on, reset, or bus device reset occurred , retries:1 ahc1: target 0 synchronous at 10.0MHz, offset = 0x8 My suspicion is that the drive has gone bad. It was working fine up until about the 6th of June and then this happened. Nothing has changed on the SCSI bus and I don't believe anything has changed in the SCSI code. I am running a -current system from around 6/25. Is this likely to be the drive or could it possibly be a cabling issue I forgot about?? BTW does anyone know how well a standard wide cable will work for ultra-wide devices?? -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-scsi Wed Jul 2 07:28:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA07138 for freebsd-scsi-outgoing; Wed, 2 Jul 1997 07:28:05 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA07131 for ; Wed, 2 Jul 1997 07:28:02 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id IAA14206; Wed, 2 Jul 1997 08:27:37 -0600 (MDT) Message-Id: <199707021427.IAA14206@pluto.plutotech.com> To: Keith Mitchell cc: scsi@FreeBSD.ORG Subject: Re: Archive Viper and 3940UW (bad Drive?) In-reply-to: Your message of "Wed, 02 Jul 1997 07:44:01 EDT." <199707021144.HAA00749@weenix.guru.org> Date: Wed, 02 Jul 1997 09:25:18 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Lately I have been having trouble getting my tape drive to work at all. >I get BUS resets everytime I try to access the drive. Can you try this patch??? -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== Index: scsi_base.c =================================================================== RCS file: /usr/cvs/src/sys/scsi/scsi_base.c,v retrieving revision 1.48 diff -c -r1.48 scsi_base.c *** scsi_base.c 1997/04/04 19:37:20 1.48 --- scsi_base.c 1997/07/02 15:22:33 *************** *** 311,317 **** 0, 0, 2, ! 5000, NULL, flags)); } --- 311,317 ---- 0, 0, 2, ! 60000, NULL, flags)); } From owner-freebsd-scsi Wed Jul 2 10:41:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16590 for freebsd-scsi-outgoing; Wed, 2 Jul 1997 10:41:29 -0700 (PDT) Received: from weenix.guru.org (phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA16585 for ; Wed, 2 Jul 1997 10:41:27 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id NAA00740; Wed, 2 Jul 1997 13:41:04 -0400 (EDT) Date: Wed, 2 Jul 1997 13:41:04 -0400 (EDT) From: Keith Mitchell Message-Id: <199707021741.NAA00740@weenix.guru.org> To: gibbs@plutotech.com (Justin T. Gibbs) CC: scsi@freebsd.org Subject: Re: Archive Viper and 3940UW (bad Drive?) X-Newsreader: TIN [UNIX 1.3 unoff BETA release 970124] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you wrote: > >Lately I have been having trouble getting my tape drive to work at all. > >I get BUS resets everytime I try to access the drive. > Can you try this patch??? I still get the errors. They appear to wait a little longer. I mean after trying to access the drive, the LED from the SCSI controller goes on and stays lit (solid) for about 10 seconds before reporting the errors. Before they were pretty much instantaneous. -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-scsi Wed Jul 2 12:29:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA21245 for freebsd-scsi-outgoing; Wed, 2 Jul 1997 12:29:17 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA21236 for ; Wed, 2 Jul 1997 12:29:15 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id NAA21948; Wed, 2 Jul 1997 13:28:46 -0600 (MDT) Message-Id: <199707021928.NAA21948@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Keith Mitchell cc: gibbs@plutotech.com (Justin T. Gibbs), scsi@freebsd.org Subject: Re: Archive Viper and 3940UW (bad Drive?) In-reply-to: Your message of "Wed, 02 Jul 1997 13:41:04 EDT." <199707021741.NAA00740@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 1997 14:26:25 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >In article you >wrote: >> >Lately I have been having trouble getting my tape drive to work at all. >> >I get BUS resets everytime I try to access the drive. > >> Can you try this patch??? > >I still get the errors. They appear to wait a little longer. I mean after >trying to access the drive, the LED from the SCSI controller goes on and >stays lit (solid) for about 10 seconds before reporting the errors. Before >they were pretty much instantaneous. Try going through all of the actions that are performed in st_close and increase the timeout. I've heard of the prevent causing problems which was why I bumped up the timeout value, but it could also be the writing of the filemarks that is causing your problems. >-- >Keith Mitchell Head Administrator: acm.vt.edu >Email: kmitch@weenix.guru.org PGP key available upon request >http://weenix.guru.org/~kmitch > Address and URL (c) 1997 Keith Mitchell - All Rights Reserved > Unauthorized use or duplication prohibited -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Jul 2 17:27:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA03652 for freebsd-scsi-outgoing; Wed, 2 Jul 1997 17:27:36 -0700 (PDT) Received: from tok.qiv.com ([204.214.141.211]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03647 for ; Wed, 2 Jul 1997 17:27:30 -0700 (PDT) Received: (from uucp@localhost) by tok.qiv.com (8.8.5/8.8.5) with UUCP id TAA09205; Wed, 2 Jul 1997 19:15:13 -0500 (CDT) Received: from localhost (jdn@localhost) by acp.qiv.com (8.8.5/8.8.5) with SMTP id TAA01252; Wed, 2 Jul 1997 19:12:55 -0500 (CDT) X-Authentication-Warning: acp.qiv.com: jdn owned process doing -bs Date: Wed, 2 Jul 1997 19:12:54 -0500 (CDT) From: "Jay D. Nelson" To: Dan Strick cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE/Viper anomolies In-Reply-To: <199707020320.UAA04700@math.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Jul 1997, Dan Strick wrote: -> ->> Should all devices be parity enabled? -- or none? -> ->All devices should be parity enabled. In most cases, they always ->generate SCSI bus parity and the "parity enable" option just causes ->them to check it. You should always try to check the configuration ->of every SCSI device that you install on a system. Vendors are ->particularly indifferent about enabling parity checking because I've seen that too often. This drive was from SunOS 4.1.1+patches days. [snip] ->than some new problem (e.g. an excessively long SCSI bus operating ->at a faster speed), or perhaps the tape drive has problems with ->synchronous SCSI bus transfers (something else that SS1s and SS1+s Hmm... External cable is 1 meter. (Impedence mismatch?) I'll put it in the case. BTW -- while I said I've had no problems, that only applies when block size is explicitly set to 512. Variable block size is unreliable. Thanks for the feedback. -- Jay ->didn't do by default on their motherboard SCSI bus). -> ->> Would putting it on a controller by itself be a benifit? -> ->I often do this with devices (such as a QIC tape drive) that are ->likely to hog the SCSI bus because the manufacturer doesn't want ->to spend more money on the SCSI interface than is necessary to ->make *his* device run at its full speed. I also like to keep my ->SCSI busses short and splitting them up helps a lot. -> ->Dan Strick ->dan@math.berkeley.edu -> From owner-freebsd-scsi Fri Jul 4 06:02:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA24104 for freebsd-scsi-outgoing; Fri, 4 Jul 1997 06:02:53 -0700 (PDT) Received: from mail.introweb.nl (introcom.introweb.nl [195.86.14.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA24097 for ; Fri, 4 Jul 1997 06:02:47 -0700 (PDT) Received: from pc4 (pc4.introweb.nl [195.86.14.74]) by mail.introweb.nl (8.7.5/8.7.3) with SMTP id NAA25528 for ; Fri, 4 Jul 1997 13:04:24 GMT Message-Id: <199707041304.NAA25528@mail.introweb.nl> Comments: Authenticated sender is From: "Edwin" To: freebsd-scsi@freebsd.org Date: Fri, 4 Jul 1997 15:02:02 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Asus PCI-DA2000 RAID controller Reply-to: edwin@introweb.nl Priority: normal X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there support for this controller ? It's a PCI RAID controller with support for RAID 0,1,3,5. http://www.asus.com/products/Specs/Addon/DA2000-Spec.asp Greetings, Edwin Ringersma Met vriendelijke groeten, Edwin Ringersma -------------------------------------------------------- IntroWeb Postbus 724 7550 AS Hengelo Tel: 074 - 243 01 05 Steenbakkersweg 25 Fax: 074 - 242 98 95 7553 EH Hengelo http://www.introweb.nl -------------------------------------------------------- Internet Access & Zakelijke Internet Toepassingen -------------------------------------------------------- From owner-freebsd-scsi Fri Jul 4 09:30:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29562 for freebsd-scsi-outgoing; Fri, 4 Jul 1997 09:30:27 -0700 (PDT) Received: from weenix.guru.org (phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29557 for ; Fri, 4 Jul 1997 09:30:25 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id MAA07734; Fri, 4 Jul 1997 12:30:21 -0400 (EDT) From: Keith Mitchell Message-Id: <199707041630.MAA07734@weenix.guru.org> Subject: Re: Archive Viper and 3940UW (bad Drive?) In-Reply-To: <199707021928.NAA21948@pluto.plutotech.com> from "Justin T. Gibbs" at "Jul 2, 97 02:26:25 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Fri, 4 Jul 1997 12:30:21 -0400 (EDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Try going through all of the actions that are performed in st_close and > increase the timeout. I've heard of the prevent causing problems which > was why I bumped up the timeout value, but it could also be the writing > of the filemarks that is causing your problems. After doing this, I noticed that some of my tapes worked and some didn't. After "erasing" all of them they all seem to worked (even on an unmodifed kernel). I was under (I guess false) impression that you didn't have to "erase" them. In the amanda cycle, it just rewinds the tapes and overwrites the data on them. I guess this added a little extra to the filemark or something similar that caused it to take to long (and thus timeout) on the device close. -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-scsi Sat Jul 5 13:15:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA18628 for freebsd-scsi-outgoing; Sat, 5 Jul 1997 13:15:52 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA18621 for ; Sat, 5 Jul 1997 13:15:50 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA25086; Sat, 5 Jul 1997 14:15:28 -0600 (MDT) Message-Id: <199707052015.OAA25086@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Keith Mitchell cc: gibbs@plutotech.com (Justin T. Gibbs), scsi@freebsd.org Subject: Re: Archive Viper and 3940UW (bad Drive?) In-reply-to: Your message of "Fri, 04 Jul 1997 12:30:21 EDT." <199707041630.MAA07734@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Jul 1997 14:15:28 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >After doing this, I noticed that some of my tapes worked and some didn't. >After "erasing" all of them they all seem to worked (even on an unmodifed >kernel). I was under (I guess false) impression that you didn't have to >"erase" them. In the amanda cycle, it just rewinds the tapes and overwrites >the data on them. I guess this added a little extra to the filemark or >something similar that caused it to take to long (and thus timeout) on the >device close. You shouldn't have to erase the tapes before using them. Did up-ing the timeout in st_write_filemarks fix the problem? Perhaps 60s is better than 10s there too? >-- >Keith Mitchell Head Administrator: acm.vt.edu >Email: kmitch@weenix.guru.org PGP key available upon request >http://weenix.guru.org/~kmitch > Address and URL (c) 1997 Keith Mitchell - All Rights Reserved > Unauthorized use or duplication prohibited > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sat Jul 5 14:37:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21000 for freebsd-scsi-outgoing; Sat, 5 Jul 1997 14:37:11 -0700 (PDT) Received: from weenix.guru.org (phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20993 for ; Sat, 5 Jul 1997 14:37:08 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id RAA05245; Sat, 5 Jul 1997 17:37:04 -0400 (EDT) From: Keith Mitchell Message-Id: <199707052137.RAA05245@weenix.guru.org> Subject: Re: Archive Viper and 3940UW (bad Drive?) In-Reply-To: <199707052015.OAA25086@pluto.plutotech.com> from "Justin T. Gibbs" at "Jul 5, 97 02:15:28 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sat, 5 Jul 1997 17:37:04 -0400 (EDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > You shouldn't have to erase the tapes before using them. I agree, but these were not new tapes. These were tapes I have been using for many months repeatedly (in a cycle -- 15 types, so each tape got used about twice a month). > Did up-ing the timeout in st_write_filemarks fix the problem? Perhaps > 60s is better than 10s there too? It helped, but so did uping the times of the .5 second timeouts (mode_sense, mode_select, etc) which may indicate that the problem could be in st_open (the mount). I am not exactly sure what the cause was. Whether everytime amanda rewrote the header, the filemark got longer or what happened. Erasing the tapes did seem to fix it though. Right now, I am running without any mods to the timeout values and all seems to be working correctly (since I erased the tapes). -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-scsi Sat Jul 5 14:53:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21491 for freebsd-scsi-outgoing; Sat, 5 Jul 1997 14:53:15 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA21485 for ; Sat, 5 Jul 1997 14:53:12 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA26449; Sat, 5 Jul 1997 15:52:50 -0600 (MDT) Message-Id: <199707052152.PAA26449@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Keith Mitchell cc: gibbs@plutotech.com (Justin T. Gibbs), scsi@freebsd.org Subject: Re: Archive Viper and 3940UW (bad Drive?) In-reply-to: Your message of "Sat, 05 Jul 1997 17:37:04 EDT." <199707052137.RAA05245@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Jul 1997 15:52:49 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> You shouldn't have to erase the tapes before using them. > >I agree, but these were not new tapes. These were tapes I have been using >for many months repeatedly (in a cycle -- 15 types, so each tape got >used about twice a month). You shouldn't have to erase used tapes before using them either. >> Did up-ing the timeout in st_write_filemarks fix the problem? Perhaps >> 60s is better than 10s there too? > >It helped, but so did uping the times of the .5 second timeouts >(mode_sense, mode_select, etc) which may indicate that the >problem could be in st_open (the mount). If the tape drive needs to look at the media before it can respond, then the .5s timeouts are way too short. >I am not exactly sure what the cause was. Whether everytime amanda >rewrote the header, the filemark got longer or what happened. Erasing >the tapes did seem to fix it though. Right now, I am running without >any mods to the timeout values and all seems to be working correctly >(since I erased the tapes). Which will last for how many months before your dumps panic the system again?? 8-) >-- >Keith Mitchell Head Administrator: acm.vt.edu >Email: kmitch@weenix.guru.org PGP key available upon request >http://weenix.guru.org/~kmitch > Address and URL (c) 1997 Keith Mitchell - All Rights Reserved > Unauthorized use or duplication prohibited > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sat Jul 5 18:07:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28083 for freebsd-scsi-outgoing; Sat, 5 Jul 1997 18:07:06 -0700 (PDT) Received: from weenix.guru.org (phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA28078 for ; Sat, 5 Jul 1997 18:07:02 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id VAA12128; Sat, 5 Jul 1997 21:06:59 -0400 (EDT) From: Keith Mitchell Message-Id: <199707060106.VAA12128@weenix.guru.org> Subject: Re: Archive Viper and 3940UW (bad Drive?) In-Reply-To: <199707052152.PAA26449@pluto.plutotech.com> from "Justin T. Gibbs" at "Jul 5, 97 03:52:49 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sat, 5 Jul 1997 21:06:59 -0400 (EDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > You shouldn't have to erase used tapes before using them either. OK, that is what I thought originally, but then given that erasing them "seemingly" solved the timeout problem I don't know what to think. What does erasing a tape actually do? It doesn't take but a few seconds. My guess is it basically erases the header info that says there is data there, but I really don't know. > If the tape drive needs to look at the media before it can respond, then > the .5s timeouts are way too short. I don't know if it actually looks at the media, but the "busy" light on the drive comes on (of course that light comes on and stays on while the tape is mounted). > >I am not exactly sure what the cause was. Whether everytime amanda > >rewrote the header, the filemark got longer or what happened. Erasing > >the tapes did seem to fix it though. Right now, I am running without > >any mods to the timeout values and all seems to be working correctly > >(since I erased the tapes). > > Which will last for how many months before your dumps panic the system > again?? 8-) Yes, but even if the timeout values were adjusted, it would eventually panic the system on those values as well (given the fact that over time the access to the tape seems to take longer). -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited