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