From owner-freebsd-scsi Sun Oct 13 20:23:44 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA21795 for freebsd-scsi-outgoing; Sun, 13 Oct 1996 20:23:44 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA21789 for ; Sun, 13 Oct 1996 20:23:40 -0700 (PDT) Received: from post.io.org by mail.crl.com with SMTP id AA26184 (5.65c/IDA-1.5 for ); Sun, 13 Oct 1996 20:24:10 -0700 Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id XAA18880 for ; Sun, 13 Oct 1996 23:20:14 -0400 (EDT) Date: Sun, 13 Oct 1996 23:20:14 -0400 (EDT) From: Brian Tao To: FREEBSD-SCSI-L Subject: Wonky controller or drive? 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 I added a new 4GB drive into our Web/FTP server three days ago (Thursday morning, Oct 10), and I've been seeing regular panics and crashes since then. The kernel messages seem to suggest mostly otherwise. The server has an NCR 53c810 SCSI controller and an SMC 10/100 Mbps Ethernet controller. The new drive in question is a Quantum Atlas, at ncr0:1:0. There is also a 1GB Seagate Medallist (sd0), two 4GB Quantum Grand Prix drives and three other 4GB Quantum Atlas drives. All the drives have ARRE and AWRE turned on. FreeBSD 2.2-960501-SNAP #0: Thu Jun 6 22:56:14 EDT 1996 taob@cabal.io.org:/usr/local/src/2.2-960501-SNAP/sys/compile/WWW de0 rev 18 int a irq 12 on pci0:9 de0: DC21140 [10-100Mb/s] pass 1.2 Ethernet address 00:00:c0:39:41:c8 de0: enabling 10baseT UTP port ncr0 rev 2 int a irq 10 on pci0:11 ncr0 waiting for scsi devices to settle (ncr0:0:0): "SEAGATE ST51080N 0913" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1030MB (2109840 512 byte sectors) sd0(ncr0:0:0): with 4826 cyls, 4 heads, and an average 109 sectors/track (ncr0:1:0): "Quantum XP34300 81HB" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 4101MB (8399520 512 byte sectors) sd1(ncr0:1:0): with 3907 cyls, 20 heads, and an average 107 sectors/track [...] The first crash came Thursday evening. It looks like the controller itself failed, but the kernel panic that followed immediately after seemed to happen in _tcp_fasttimo. What does "CCB already dequeued" mean? ncr0: SCSI phase error fixup: CCB already dequeued (0xf3452800) ncr0: restart (ncr dead ?). sd5(ncr0:5:0): error code 114 , retries:3 sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 sd0(ncr0:0:0): Power on, reset, or bus device reset occurred 0 current process = Idle interrupt mask = panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8c875 fault code = supervisor read, page not present instruction pointer = 0x8:0xf0146613 stack pointer = 0x10:0xf01caccc frame pointer = 0x10:0xf01cacd4 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 = Idle interrupt mask = panic: page fault Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... I didn't get any panic messages for the second crash, but it looked like the VM system was unable to read pages back into physical memory: ncr0: SCSI phase error fixup: CCB already dequeued (0xf3452600) ncr0: restart (ncr dead ?). sd1(ncr0:1:0): error code 0 , retries:2 sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 sd0(ncr0:0:0): Power on, reset, or bus device reset occurred , retries:3 sd3(ncr0:3:0): UNIT ATTENTION asc:29,0 sd3(ncr0:3:0): Power on, reset, or bus device reset occurred sks:80,0 , retries:3 sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. ncr0: restart (ncr dead ?). sd3(ncr0:3:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 sd0(ncr0:0:0): Power on, reset, or bus device reset occurred , retries:1 sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. sd5(ncr0:5:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. sd6(ncr0:6:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. spec_getpages: I/O read error vm_fault: pager input (probably hardware) error, PID 12849 failure pid 12849 (imagemap), uid 9: exited on signal 11 spec_getpages: I/O read error vm_fault: pager input (probably hardware) error, PID 12878 failure pid 12878 (imagemap), uid 9: exited on signal 11 spec_getpages: I/O read error vm_fault: pager input (probably hardware) error, PID 12923 failure pid 12923 (imagemap), uid 9: exited on signal 11 spec_getpages: I/O read error vm_fault: pager input (probably hardware) error, PID 12936 failure pid 12936 (imagemap), uid 9: exited on signal 11 A few more instances of "Power on, reset, or bus device reset occurred" appeared, as well as a couple of "Unrecovered read errors" on the new Quantum, despite having ARRE enabled. The third crash in two days was actually in _tulip_rx_intr, if you believe the instruction pointer info in the panic message: ncr0: SCSI phase error fixup: CCB already dequeued (0xf3452400) ncr0: restart (ncr dead ?). panic: free: multiple frees syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x39c00000 fault code = supervisor read, page not present instruction pointer = 0x8:0xf017961b stack pointer = 0x10:0xefbff9c4 frame pointer = 0x10:0xefbff9f0 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 = 107 (nfsd) interrupt mask = net panic: page fault Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... That happened twice so far, in _tulip_rx_intr. The most recent crash was definitely related to the new Quantum: assertion "cp" failed: file "../../pci/ncr.c", line 5543 sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. assertion "cp" failed: file "../../pci/ncr.c", line 5543 sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. assertion "cp" failed: file "../../pci/ncr.c", line 5543 sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. assertion "cp" failed: file "../../pci/ncr.c", line 5543 sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. assertion "cp" failed: file "../../pci/ncr.c", line 5543 sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. assertion "cp" failed: file "../../pci/ncr.c", line 5543 sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 giving up Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... So my question is, bad controller or bad drive? This server, which was very stable before I put in the new drive, seems to be having trouble with both its disk and network components? I don't have another spare 4GB drive to swap in, and it's the long weekend in Canada. :( Could a marginally bad drive cause all these problems? -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Sun Oct 13 20:28:27 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA22092 for freebsd-scsi-outgoing; Sun, 13 Oct 1996 20:28:27 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA21988 for ; Sun, 13 Oct 1996 20:27:04 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id XAA18909 for ; Sun, 13 Oct 1996 23:26:24 -0400 (EDT) Date: Sun, 13 Oct 1996 23:26:23 -0400 (EDT) From: Brian Tao To: FREEBSD-SCSI-L Subject: High-capacity tape libraries 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 Would amanda have any problems with the Exabyte EXB-8900S "Mammoth" tape library or the DEC DLT-2500 and DLT-4500 libraries? -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Sun Oct 13 23:05:44 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA29339 for freebsd-scsi-outgoing; Sun, 13 Oct 1996 23:05:44 -0700 (PDT) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA29331 for ; Sun, 13 Oct 1996 23:05:35 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01985; Mon, 14 Oct 1996 08:01:28 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA00782; Mon, 14 Oct 1996 08:01:25 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id WAA10119; Sat, 12 Oct 1996 22:55:17 +0200 (MET DST) From: J Wunsch Message-Id: <199610122055.WAA10119@uriah.heep.sax.de> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Date: Sat, 12 Oct 1996 22:55:17 +0200 (MET DST) Cc: jgreco@brasil.moneng.mei.com (Joe Greco) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199610111357.IAA20953@brasil.moneng.mei.com> from Joe Greco at "Oct 11, 96 08:57:50 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Joe Greco wrote: > Hi Rod, Not me :), but... > > Is there a good tool to do this sort of stuff under FreeBSD (besides doing > it by hand with the scsi command)? > > The NCR controllers in use around here do not have a built in BIOS utility > (like the Adaptecs do) to do low level formatting and verification/bad > block remapping. What's wrong with scsiformat(8)? It used to be in the 2.2 branch for quite some time, but also finally found its way into 2.1.5R. -- 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. ;-) From owner-freebsd-scsi Mon Oct 14 05:50:37 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA25163 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 05:50:37 -0700 (PDT) Received: from unicorn.uk1.vbc.net (unicorn.uk1.vbc.net [194.207.2.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA24812 for ; Mon, 14 Oct 1996 05:38:53 -0700 (PDT) Received: (from gordon@localhost) by unicorn.uk1.vbc.net (8.7.3/8.7.3) id NAA19873; Mon, 14 Oct 1996 13:34:08 +0100 Date: Mon, 14 Oct 1996 13:34:07 +0100 (BST) From: Gordon Henderson X-Sender: gordon@unicorn To: Joe Greco cc: "Rodney W. Grimes" , freebsd-scsi@FREEBSD.ORG Subject: Re: Buslogic controller, Sync mode & a SCSI disk error In-Reply-To: <199610111357.IAA20953@brasil.moneng.mei.com> Message-ID: Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FREEBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 11 Oct 1996, Joe Greco wrote: > > BACKUPS ARE STRONGLY RECOMMENDED BEFORE DOING THIS! > > If that fails you are going to have to run a low level verify operation > > and tell it to remap the block that it could not read, then run fsck > > and hope to hell it was just a file system block and not meta data. > > Hi Rod, > > Is there a good tool to do this sort of stuff under FreeBSD (besides doing > it by hand with the scsi command)? Of course, theres no point in using an existing tool, or writing a utility to do it if the driver is going to crap out on you when you do hit a bad block. My machine paniced again over the weekend )-: Looks like the bt driver also corrupts the syslog file... Oct 12 19:32:02 news /kernel: sd1(bt0:1:0): MEDIUM ERROR info:29b40f asc:11,0 Unrecovered read error Oct 12 19:32:02 news /kernel: , retries:4^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@ Oct 12 20:20:50 news /kernel: bt0: not taking commands! Oct 12 20:20:50 news /kernel: Debugger("bt742a") called. Oct 12 20:20:50 news /kernel: bt0: Try to abort Oct 12 20:20:50 news /kernel: bt0: not taking commands! Oct 12 20:20:51 news /kernel: Debugger("bt742a") called. Oct 12 20:20:51 news /kernel: bt0: Abort Operation has timed out Oct 12 20:20:51 news /kernel: bt0: not taking commands! Oct 12 20:20:51 news /kernel: Debugger("bt742a") called. Oct 12 20:20:51 news /kernel: bt0: Abort Operation has timed out There were no othe rmessages until it reboted some 8 minutes later: Oct 12 20:28:44 news /kernel: FreeBSD 2.1.5-RELEASE #0: Tue Sep 24 15:48:51 BST 1996 etc... Gordon From owner-freebsd-scsi Mon Oct 14 06:25:51 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA27022 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 06:25:51 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA27016 for ; Mon, 14 Oct 1996 06:25:49 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA23698; Mon, 14 Oct 1996 08:21:41 -0500 From: Joe Greco Message-Id: <199610141321.IAA23698@brasil.moneng.mei.com> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 14 Oct 1996 08:21:40 -0500 (CDT) Cc: freebsd-scsi@freebsd.org, jgreco@brasil.moneng.mei.com In-Reply-To: <199610122055.WAA10119@uriah.heep.sax.de> from "J Wunsch" at Oct 12, 96 10:55:17 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Joe Greco wrote: > > Hi Rod, > > Not me :), but... :-) > > Is there a good tool to do this sort of stuff under FreeBSD (besides doing > > it by hand with the scsi command)? > > > > The NCR controllers in use around here do not have a built in BIOS utility > > (like the Adaptecs do) to do low level formatting and verification/bad > > block remapping. > > What's wrong with scsiformat(8)? It used to be in the 2.2 branch for > quite some time, but also finally found its way into 2.1.5R. 1) Because I didn't know it was there; 2) Because generally I am more interested in a utility to do verification and bad block remapping. Usually by the time I decide to low level a drive, it is being swapped out for a new unit that has already been burned in for a while... but it is nice to know that a utility is available. :-) That will save some time when I am setting up new systems. Any ideas on a verification/bad block remapper utility? Would it be hard to do? ... JG From owner-freebsd-scsi Mon Oct 14 08:02:50 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA02213 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 08:02:50 -0700 (PDT) Received: from Octopussy (Octopussy.MI.Uni-Koeln.DE [134.95.212.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA02205 for ; Mon, 14 Oct 1996 08:02:33 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-13.slip.Uni-Koeln.DE) by Octopussy with SMTP id AA22289 (5.67b/IDA-1.5 for ); Mon, 14 Oct 1996 17:02:07 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.6/8.6.9) id RAA00816; Mon, 14 Oct 1996 17:01:53 +0200 (MET DST) Message-Id: <199610141501.RAA00816@x14.mi.uni-koeln.de> Date: Mon, 14 Oct 1996 17:01:53 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: taob@io.org (Brian Tao) Cc: freebsd-scsi@freebsd.org (FREEBSD-SCSI-L) Subject: Re: Wonky controller or drive? In-Reply-To: ; from Brian Tao on Oct 13, 1996 23:20:14 -0400 References: X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao writes: > I added a new 4GB drive into our Web/FTP server three days ago > (Thursday morning, Oct 10), and I've been seeing regular panics and > crashes since then. The kernel messages seem to suggest mostly > otherwise. > > The server has an NCR 53c810 SCSI controller and an SMC 10/100 > Mbps Ethernet controller. The new drive in question is a Quantum > Atlas, at ncr0:1:0. There is also a 1GB Seagate Medallist (sd0), two > 4GB Quantum Grand Prix drives and three other 4GB Quantum Atlas > drives. All the drives have ARRE and AWRE turned on. Hmm, adding the 7th drive caused problems ??? I guess this is the largest disk capacity that ever got connected to a single 53c810 ... :) In order to understand what's wrong, I'd like to know whether these driver are internal or in an external case (and with their own power supplies), the length of the SCSI bus cable (not only to external boxes, but also within them). I expect this to be caused by either a too long cable (for the transfer rate) or a problem with the power supplies. (The 4GB drives need some 15W each under load, but temporary peaks may be much higher and may in fact occur on multiple drives simultanously, depending on how you spread the file systems. The power will be continously drawn on the 5V line, but there may be significant current peaks on the 12V line. I'd suggest to have a power-supply that delivers 2A at 12V per 4GB drive. If all of them are connected to a single PS, then a total of 8A at 12V might be sufficient. > (ncr0:0:0): "SEAGATE ST51080N 0913" type 0 fixed SCSI 2 > (ncr0:1:0): "Quantum XP34300 81HB" type 0 fixed SCSI 2 > The first crash came Thursday evening. It looks like the > controller itself failed, but the kernel panic that followed > immediately after seemed to happen in _tcp_fasttimo. What does "CCB > already dequeued" mean? > > ncr0: SCSI phase error fixup: CCB already dequeued (0xf3452800) > ncr0: restart (ncr dead ?). > sd5(ncr0:5:0): error code 114 > , retries:3 No, that's probably not a controller failure, but a lost SCSI ACK. The CCB already dequeued is a secondary effect, after some code at interrupt level cancelled a SCSI command that was taking too long. > I didn't get any panic messages for the second crash, but it > looked like the VM system was unable to read pages back into physical > memory: > > ncr0: SCSI phase error fixup: CCB already dequeued (0xf3452600) > ncr0: restart (ncr dead ?). Same problem as above: The SCSI bus appears to be locked, and no devcice makes any progress anymore ... > A few more instances of "Power on, reset, or bus device reset > occurred" appeared, as well as a couple of "Unrecovered read errors" > on the new Quantum, despite having ARRE enabled. The third crash in These read errors do most probably indicate, that the data has not been transferred to the NCR completely. > two days was actually in _tulip_rx_intr, if you believe the > instruction pointer info in the panic message: > > ncr0: SCSI phase error fixup: CCB already dequeued (0xf3452400) > ncr0: restart (ncr dead ?). > panic: free: multiple frees This might have been a random coincidence. But I'll check whether I find anything that might explain this. > syncing disks... > Fatal trap 12: page fault while in kernel mode I do not think that this is directly related to the NCR driver ... It does rather look like some kernel data structures got corrupted. > fault virtual address = 0x39c00000 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf017961b > stack pointer = 0x10:0xefbff9c4 > frame pointer = 0x10:0xefbff9f0 > 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 = 107 (nfsd) > interrupt mask = net > That happened twice so far, in _tulip_rx_intr. The most recent > crash was definitely related to the new Quantum: > > assertion "cp" failed: file "../../pci/ncr.c", line 5543 > sd1(ncr0:1:0): COMMAND FAILED (4 28) @f3452800. An SCSI error occured, but no command control block could be identified for the current command. This may in special circumstances happen, if some command gets terminated. I'll think about a more descriptive error message in order to understand what actually happened. > So my question is, bad controller or bad drive? This server, > which was very stable before I put in the new drive, seems to be > having trouble with both its disk and network components? I don't > have another spare 4GB drive to swap in, and it's the long weekend in > Canada. :( Could a marginally bad drive cause all these problems? Well, my first guess would be the SCSI cable being too long (or not good enough) or the peak load on the power supply being too high. You can check the prior by using only slow transfers (async. or at most 5MB/s sync). If the power supply is at its limit, then you should be able to cause failures by increasing the seek rate (ie. do random seeks with little data actually being transferred). Reagrds, STefan From owner-freebsd-scsi Mon Oct 14 08:18:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA03064 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 08:18:12 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA03056 for ; Mon, 14 Oct 1996 08:18:09 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id IAA13017; Mon, 14 Oct 1996 08:17:22 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199610141517.IAA13017@GndRsh.aac.dev.com> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error In-Reply-To: <199610122055.WAA10119@uriah.heep.sax.de> from J Wunsch at "Oct 12, 96 10:55:17 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 14 Oct 1996 08:17:21 -0700 (PDT) Cc: freebsd-scsi@freebsd.org, jgreco@brasil.moneng.mei.com X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Joe Greco wrote: > > > Hi Rod, > > Not me :), but... Ooopsss.. I failed to answer the first time... > > > > Is there a good tool to do this sort of stuff under FreeBSD (besides doing > > it by hand with the scsi command)? Not really, scsi(8) was flushed out at my request and expense to replace just 1 of the tools I had to run under DOS frequently, several of the other tools I use less often and have not sought out a FreeBSD replacement for. The ``tool'' I usually use for running a ``verify with remap'' pass is the aha2940 BIOS lately, since I can just pop the drive on a test setup and fix it. > > > > The NCR controllers in use around here do not have a built in BIOS utility > > (like the Adaptecs do) to do low level formatting and verification/bad > > block remapping. > > What's wrong with scsiformat(8)? It used to be in the 2.2 branch for > quite some time, but also finally found its way into 2.1.5R. scsiformat(8) is destructive only, I can't fix a drive full of data with it. :-(. How hard would it be to extend it so that it does what the aha2940 ``verify'' mode does? -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-scsi Mon Oct 14 08:27:02 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA03625 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 08:27:02 -0700 (PDT) Received: from Octopussy (Octopussy.MI.Uni-Koeln.DE [134.95.212.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA03410 for ; Mon, 14 Oct 1996 08:24:01 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-41.slip.Uni-Koeln.DE) by Octopussy with SMTP id AA23648 (5.67b/IDA-1.5 for ); Mon, 14 Oct 1996 17:23:15 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.6/8.6.9) id RAA00864; Mon, 14 Oct 1996 17:22:34 +0200 (MET DST) Message-Id: <199610141522.RAA00864@x14.mi.uni-koeln.de> Date: Mon, 14 Oct 1996 17:22:33 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: elrond@imladris.frmug.fr.net (Bertrand Petit) Cc: freebsd-scsi@freebsd.org Subject: Re: Success report: NOMAI MCD540 In-Reply-To: <199610120646.IAA02796@imladris.frmug.fr.net>; from Bertrand Petit on Oct 12, 1996 08:46:42 +0200 References: <199610120646.IAA02796@imladris.frmug.fr.net> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bertrand Petit writes: > > I sucessfuly hooked a NOMAI MCD540 removable disk unit to a > FreeBSD 2.1.0-RELEASE system. > > I got some troubles to make it work, I got tons of bus resets > and NCR crashes likes this: > > sd5(ncr0:5:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. > ncr0:5: ERROR (80:100) (8-2a-0) (8/13) @ (544:900b0000). > script cmd = 910a0000 > reg: da 10 80 13 47 08 05 1f 01 08 05 2a 80 00 02 00. > ncr0: handshake timeout > sd5(ncr0:5:0): COMMAND FAILED (6 ff) @f0c04c00. Everything is fine, except for the handshake timeout. Your device seems to be very slow at times (for example when loading a new medium ?) and just blocks operations on the SCSI bus for a significant time. This was considered a device failure in 2.1R, but it was later found, that there are in fact some CD-ROM changers, CD-R drives or SCSI scanners, which may do this as part of their normal operation. The handshake timeout has been removed from the driver for this reason. Apply the following patch, if you ever again have a problem with your device causing handshake timeouts: Index: /sys/pci/ncr.c =================================================================== RCS file: /usr/cvs/src/sys/pci/ncr.c,v retrieving revision 1.57 retrieving revision 1.58 diff -C2 -r1.57 -r1.58 *** ncr.c 1996/01/15 00:10:15 1.57 --- ncr.c 1996/01/15 23:16:39 1.58 *************** *** 4427,4431 **** OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ ! OUTB (nc_stime0, 0xfb ); /* HTH = 1.6sec STO = 0.1 sec. */ /* --- 4427,4431 ---- OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ ! OUTB (nc_stime0, 0x0b ); /* HTH = disabled, STO = 0.1 sec. */ /* > It was solved by a main board BIOS update on an Asus > P/I-55TP4XE with an Asus PCI-SCSI2000 adaptater. The last version of > the BIOS available from the Asus ftp site or mirrors, in the file > TCX5I020.ZIP. Regards, STefan From owner-freebsd-scsi Mon Oct 14 08:40:59 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA04626 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 08:40:59 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA04576 for ; Mon, 14 Oct 1996 08:40:40 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA24323; Mon, 14 Oct 1996 10:37:53 -0500 From: Joe Greco Message-Id: <199610141537.KAA24323@brasil.moneng.mei.com> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 14 Oct 1996 10:37:53 -0500 (CDT) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@freebsd.org, jgreco@brasil.moneng.mei.com In-Reply-To: <199610141517.IAA13017@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Oct 14, 96 08:17:21 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Not really, scsi(8) was flushed out at my request and expense to replace > just 1 of the tools I had to run under DOS frequently, several of the > other tools I use less often and have not sought out a FreeBSD replacement > for. > > The ``tool'' I usually use for running a ``verify with remap'' pass is the > aha2940 BIOS lately, since I can just pop the drive on a test setup and > fix it. That is nice now show me how to do it on a machine that is 30 miles away please :-) :-) > > > > > > The NCR controllers in use around here do not have a built in BIOS utility > > > (like the Adaptecs do) to do low level formatting and verification/bad > > > block remapping. > > > > What's wrong with scsiformat(8)? It used to be in the 2.2 branch for > > quite some time, but also finally found its way into 2.1.5R. > > scsiformat(8) is destructive only, I can't fix a drive full of data > with it. :-(. How hard would it be to extend it so that it does > what the aha2940 ``verify'' mode does? Perhaps even with a nicer interface :-) Personally I am quite fond of the "analyze" feature available in Sun format, but that is also a fair amount of additional work. ... JG From owner-freebsd-scsi Mon Oct 14 08:59:51 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06005 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 08:59:51 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA05945 for ; Mon, 14 Oct 1996 08:59:28 -0700 (PDT) Received: from rogue.io.org (rogue.io.org [198.133.36.157]) by post.io.org (8.7.5/8.7.3) with SMTP id LAA23369; Mon, 14 Oct 1996 11:58:59 -0400 (EDT) Date: Mon, 14 Oct 1996 11:58:59 -0400 (EDT) From: Brian Tao To: Stefan Esser cc: FREEBSD-SCSI-L Subject: Re: Wonky controller or drive? In-Reply-To: <199610141501.RAA00816@x14.mi.uni-koeln.de> 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 Mon, 14 Oct 1996, Stefan Esser wrote: > > Hmm, adding the 7th drive caused problems ??? No, not precisely. This is the history: sd1 was a 4GB Quantum Atlas to begin with. That one died during a power outage about a month ago. I replaced it with a 1GB drive in the meantime. That's still seven devices. I only recently replaced it with a new 4GB drive, since we were running out of room on the 1GB (Web and FTP server logs, mostly). The cable configuration hasn't changed, just that one drive. sd0 and sd1 (1GB boot drive, plus the new 4GB drive) are mounted internally in the PC (50-wire ribbon cable, about 40 cm). The remaining drives are in two daisy-chained external enclosures, total cable length of about 150 cm (two lengths of external cabling, two lengths of internal ribbon cabling), out to the last drive. The internal chain is terminated with jumpers on the Quantum. The external chain has an active terminator plugged into the last enclosure. Each enclosure has its own power supply and fans. One has four bays (three drives) and the other has two bays (two drives). > I guess this is the largest disk capacity that > ever got connected to a single 53c810 ... :) SCSI bus speed isn't a consideration for our FTP server... I just needed the mass storage. :) > I expect this to be caused by either a too > long cable (for the transfer rate) or a problem > with the power supplies. What is the maximum? 6 m or something like that? I should be well within spec. [much helpful description of panic messages deleted... thanks!] > Well, my first guess would be the SCSI cable being > too long (or not good enough) or the peak load on the > power supply being too high. > > You can check the prior by using only slow transfers > (async. or at most 5MB/s sync). If the power supply > is at its limit, then you should be able to cause > failures by increasing the seek rate (ie. do random > seeks with little data actually being transferred). Hummmm... what could I use to do that? Running bonnie repeatedly on the 4GB drive for the random seek tests? I don't think there is a way on the NCR (unlike the Adaptecs) to specify the bus speed or sync/async mode. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Mon Oct 14 09:23:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07789 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 09:23:46 -0700 (PDT) Received: from rs1.rrz.Uni-Koeln.DE (rs1.rrz.Uni-Koeln.DE [134.95.100.208]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA07762 for ; Mon, 14 Oct 1996 09:23:15 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-6.slip.Uni-Koeln.DE) by rs1.rrz.Uni-Koeln.DE with SMTP id AA47253 (5.67b/IDA-1.5 for ); Mon, 14 Oct 1996 18:21:23 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.6/8.6.9) id SAA04657; Mon, 14 Oct 1996 18:19:26 +0200 (MET DST) Message-Id: <199610141619.SAA04657@x14.mi.uni-koeln.de> Date: Mon, 14 Oct 1996 18:19:26 +0200 From: se@mi.uni-koeln.de (Stefan Esser) To: taob@io.org (Brian Tao) Cc: se@zpr.uni-koeln.de (Stefan Esser), freebsd-scsi@freebsd.org (FREEBSD-SCSI-L) Subject: Re: Wonky controller or drive? In-Reply-To: ; from Brian Tao on Oct 14, 1996 11:58:59 -0400 References: X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao writes: > On Mon, 14 Oct 1996, Stefan Esser wrote: > > > > Hmm, adding the 7th drive caused problems ??? > > No, not precisely. This is the history: sd1 was a 4GB Quantum > Atlas to begin with. That one died during a power outage about a > month ago. I replaced it with a 1GB drive in the meantime. That's > still seven devices. I only recently replaced it with a new 4GB > drive, since we were running out of room on the 1GB (Web and FTP > server logs, mostly). Ok. > The cable configuration hasn't changed, just that one drive. sd0 > and sd1 (1GB boot drive, plus the new 4GB drive) are mounted > internally in the PC (50-wire ribbon cable, about 40 cm). The > remaining drives are in two daisy-chained external enclosures, total > cable length of about 150 cm (two lengths of external cabling, two > lengths of internal ribbon cabling), out to the last drive. The > internal chain is terminated with jumpers on the Quantum. The > external chain has an active terminator plugged into the last > enclosure. Each enclosure has its own power supply and fans. One has > four bays (three drives) and the other has two bays (two drives). Hmm, I count 3 internal and two external cables ... I guess each internal cable is some 100cm, actually, at least I've yet to see a shorter cable being delivered with a system. (Well, if you made it from components yourself this is different :) > > I expect this to be caused by either a too > > long cable (for the transfer rate) or a problem > > with the power supplies. > > What is the maximum? 6 m or something like that? I should be > well within spec. I've seen problems with much less than 6m of cable, and I would not trust single-ended Fast SCSI with more than 3m. Don't forget, that those maximum length specs do only apply to SCSI cable of a given quality (impendance and capacitance), and your internal cables are probably far from optimal ... > > Well, my first guess would be the SCSI cable being > > too long (or not good enough) or the peak load on the > > power supply being too high. > > > > You can check the prior by using only slow transfers > > (async. or at most 5MB/s sync). If the power supply > > is at its limit, then you should be able to cause > > failures by increasing the seek rate (ie. do random > > seeks with little data actually being transferred). > > Hummmm... what could I use to do that? Running bonnie repeatedly > on the 4GB drive for the random seek tests? I don't think there is a I'd rather use multiple simultanously running "find" processes, startet half a minute apart in order to not take advantage of the caches ... > way on the NCR (unlike the Adaptecs) to specify the bus speed or > sync/async mode. Well, I use /usr/sbin/ncrcontrol for that purpose :) # ncrcontrol -s sync=5 limits the transfer rate to 5MHz. # ncrcontrol -t 1 -s async makes target 1 only use asynch. transfers. # ncrcontrol -t 3 -t 4 -s tags=0 -t 5 -s tags=8 disables sending tags to targets 3 and 4, while target 5 will receive up to 8 simultanous commands (instead of the default of 4 for a device supporting TCQ). # ncrcontrol -i T:L Vendor Device Rev Speed Max Wide Tags 0:0 Quantum XP32150 576D 10.0 10.0 8 4 1:0 DEC DSP3053LS X442 10.0 10.0 8 4 4:0 TOSHIBA CD-ROM XM-3601TA 0725 4.0 10.0 8 - 5:0 HP C1533A 9406 10.0 10.0 8 - # ncrcontrol -v -p 1 total XP32150 DSP3053L CD-ROM X C1533A transf. disconn interru ---- ms transfer ---- t/s kb/s t/s kb/s t/s kb/s t/s kb/s t/s kb/s length exp une fly brk total pre post disc 26 174 26 174 0 0 0 0 0 0 6853 33 0 26 0 9.6 0.4 0.4 5.8 43 153 43 153 0 0 0 0 0 0 3644 48 0 43 0 9.3 0.9 0.0 7.0 40 188 40 188 0 0 0 0 0 0 4813 55 0 40 0 10.8 0.2 0.0 4.5 30 168 30 168 0 0 0 0 0 0 5734 34 0 30 0 15.0 0.0 0.3 12.3 73 363 73 363 0 0 0 0 0 0 5092 72 0 73 0 20.4 0.5 0.1 16.2 (Disk activity caused by "find / -print".) There is a man page for ncrcontrol, BTW, and "ncrcontrol -?" and "-s ?" give some information on supported options. Regards, STefan From owner-freebsd-scsi Mon Oct 14 10:24:44 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA12313 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 10:24:44 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA12171 for ; Mon, 14 Oct 1996 10:23:15 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA09632; Mon, 14 Oct 1996 19:21:11 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA16999; Mon, 14 Oct 1996 19:21:11 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.6/8.6.9) id SAA06506; Mon, 14 Oct 1996 18:53:57 +0200 (MET DST) From: J Wunsch Message-Id: <199610141653.SAA06506@uriah.heep.sax.de> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Date: Mon, 14 Oct 1996 18:53:57 +0200 (MET DST) Cc: jgreco@brasil.moneng.mei.com (Joe Greco) In-Reply-To: <199610141321.IAA23698@brasil.moneng.mei.com> from Joe Greco at "Oct 14, 96 08:21:40 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Joe Greco wrote: > > What's wrong with scsiformat(8)? > 2) Because generally I am more interested in a utility to do verification > and bad block remapping. The FORMAT UNIT command does this, inside the drive. At least, that's my experience. One of my old (now retired due to lack of space) Seacrate drives experienced excess bad sectors once, so i backed up, reformatted, and restored the filesystems. It never got any reported bad block again, and it went on for more than a year afterwards until i had to replace it by a larger one recently. > Any ideas on a verification/bad block remapper utility? Would it be > hard to do? On-the-fly verification (non-desctructive, as Rod suggested) is much harder to do. There's no SCSI command for it, you gotta visit each block on the drive, and remap it manually. The existing scsiformat(8) was just Peter D's replacement for the old defunct 4.4BSD scsiformat code, with no more functionality added (and the ugly user interface inherited ;). -- 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. ;-) From owner-freebsd-scsi Mon Oct 14 11:08:52 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14249 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 11:08:52 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA14090 for ; Mon, 14 Oct 1996 11:05:41 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA24624; Mon, 14 Oct 1996 13:01:03 -0500 From: Joe Greco Message-Id: <199610141801.NAA24624@brasil.moneng.mei.com> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: j@uriah.heep.sax.de (J Wunsch) Date: Mon, 14 Oct 1996 13:01:02 -0500 (CDT) Cc: freebsd-scsi@FreeBSD.org, jgreco@brasil.moneng.mei.com In-Reply-To: <199610141653.SAA06506@uriah.heep.sax.de> from "J Wunsch" at Oct 14, 96 06:53:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > 2) Because generally I am more interested in a utility to do verification > > and bad block remapping. > > The FORMAT UNIT command does this, inside the drive. At least, that's > my experience. ...and takes the rest of the good blocks with it :-( ( ;-) ) > One of my old (now retired due to lack of space) > Seacrate drives experienced excess bad sectors once, so i backed up, > reformatted, and restored the filesystems. It never got any reported > bad block again, and it went on for more than a year afterwards until > i had to replace it by a larger one recently. Yes, I know. I've actually got a Quantum ProDrive LPS105S here that was dropped _while_ running (about two feet) and it ended up with 122 defects after gentle combinations of scanning and low level formatting. It has been in service for a lot more than a year and has been 1000% reliable. > > Any ideas on a verification/bad block remapper utility? Would it be > > hard to do? > > On-the-fly verification (non-desctructive, as Rod suggested) is much > harder to do. There's no SCSI command for it, you gotta visit each > block on the drive, and remap it manually. Yes, I know, I've seen someone else's implementation. Nice... too bad it can't help us any. :-( ... JG From owner-freebsd-scsi Mon Oct 14 13:32:56 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA23711 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 13:32:56 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA23706 for ; Mon, 14 Oct 1996 13:32:49 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA25951 (5.67b/IDA-1.5 for freebsd-scsi@FreeBSD.ORG); Mon, 14 Oct 1996 22:32:16 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id TAA00560; Mon, 14 Oct 1996 19:15:16 +0100 (MET) From: Wilko Bulte Message-Id: <199610141815.TAA00560@yedi.iaf.nl> Subject: Re: High-capacity tape libraries To: taob@io.org (Brian Tao) Date: Mon, 14 Oct 1996 19:15:16 +0100 (MET) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Oct 13, 96 11:26:23 pm X-Mailer: ELM [version 2.4 PL24 ME8a] 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 As Brian Tao wrote... > Would amanda have any problems with the Exabyte EXB-8900S > "Mammoth" tape library or the DEC DLT-2500 and DLT-4500 libraries? If you need the docs for the 4700 or 4500 I should have a postscript file somewhere. Lists the scsi implementation in sufficient detail. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-scsi Mon Oct 14 13:37:03 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24093 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 13:37:03 -0700 (PDT) Received: from hda.com (ip95-max1-fitch.zipnet.net [199.232.245.95]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA24088 for ; Mon, 14 Oct 1996 13:36:53 -0700 (PDT) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id RAA19326; Mon, 14 Oct 1996 17:05:09 -0400 From: Peter Dufault Message-Id: <199610142105.RAA19326@hda.com> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 14 Oct 1996 17:05:03 -0400 (EDT) Cc: rgrimes@GndRsh.aac.dev.com, joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.org, jgreco@brasil.moneng.mei.com In-Reply-To: <199610141537.KAA24323@brasil.moneng.mei.com> from "Joe Greco" at Oct 14, 96 10:37:53 am Reply-to: hdalog@zipnet.net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > scsiformat(8) is destructive only, I can't fix a drive full of data > > with it. :-(. How hard would it be to extend it so that it does > > what the aha2940 ``verify'' mode does? > > Perhaps even with a nicer interface :-) Personally I am quite fond > of the "analyze" feature available in Sun format, but that is also a > fair amount of additional work. What do these utilities do? How do they look? How different is the behavior from doing a read/write loop over an unmounted raw disk after ensuring AWRE/ARRE are on, possibly with a read retry count and a "force write to sector N if you exceed read retry errors at sector N" option? Since these read failures typically indicate the drive tried its best already (and our system has issued additional retries also), I'm not sure of what these utilities do other than possibly turning off error checking and reading as much as it can. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Mon Oct 14 14:05:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25548 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 14:05:12 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA25535 for ; Mon, 14 Oct 1996 14:05:07 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA24924; Mon, 14 Oct 1996 16:02:45 -0500 From: Joe Greco Message-Id: <199610142102.QAA24924@brasil.moneng.mei.com> Subject: Re: Buslogic controller, Sync mode & a SCSI disk error To: hdalog@zipnet.net Date: Mon, 14 Oct 1996 16:02:45 -0500 (CDT) Cc: rgrimes@GndRsh.aac.dev.com, freebsd-scsi@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199610142105.RAA19326@hda.com> from "Peter Dufault" at Oct 14, 96 05:05:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > scsiformat(8) is destructive only, I can't fix a drive full of data > > > with it. :-(. How hard would it be to extend it so that it does > > > what the aha2940 ``verify'' mode does? > > > > Perhaps even with a nicer interface :-) Personally I am quite fond > > of the "analyze" feature available in Sun format, but that is also a > > fair amount of additional work. > > What do these utilities do? How do they look? How different is the behavior > from doing a read/write loop over an unmounted raw disk after > ensuring AWRE/ARRE are on, possibly with a read retry count and > a "force write to sector N if you exceed read retry errors at sector N" > option? > > Since these read failures typically indicate the drive tried its > best already (and our system has issued additional retries also), > I'm not sure of what these utilities do other than > possibly turning off error checking and reading as much as it can. Hello Peter, The Adaptec utility appears to simply read all the sectors on the disk, looking for bad sectors. I am not sure what it does to deal with the bad sectors it finds - it simply gives an option to "correct" the errors found. How it is done, I don't know. The Sun format / analyze tool is a bit nicer. It provides a unified formatting/partitioning/error correction interface that is really not too hard to work with: # format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c0t3d0 /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@3,0 Specify disk (enter its number): 0 selecting c0t3d0 [disk formatted] FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character volume name quit format> ana ANALYZE MENU: read - read only test (doesn't harm SunOS) refresh - read then write (doesn't harm data) test - pattern testing (doesn't harm data) write - write then read (corrupts data) compare - write, read, compare (corrupts data) purge - write, read, write (corrupts data) print - display data buffer setup - set analysis parameters config - show analysis parameters quit analyze> setup Analyze entire disk[yes]? Loop continuously[no]? Enter number of passes[2]: Repair defective blocks[yes]? Stop after first error[no]? Use random bit patterns[no]? Enter number of blocks per transfer[126, 0/0/126]: Verify media after formatting[yes]? Enable extended messages[no]? Restore defect list[yes]? Restore disk label[yes]? analyze> read Ready to analyze (won't harm SunOS). This takes a long time, but is interruptable with CTRL-C. Continue? y pass 0 ^C 38/1/22 Total of 0 defective blocks repaired. analyze> Anyways the various tests allow you to perform a variety of read/write operations to check the disk. The "read" test may be run on mounted partitions, the "refresh" and "test" tests will not corrupt data because they read and restore the information that was on the disk, and the others are more brutal. The "read" test appears to be substantially similar to the Adaptec utility. This is a really nice tool. It is not a beginners tool, but it does a lot to avoid the annoyance and mistakes that are so easy to make when dealing with SCSI disks. ... JG From owner-freebsd-scsi Mon Oct 14 17:08:05 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA07721 for freebsd-scsi-outgoing; Mon, 14 Oct 1996 17:08:05 -0700 (PDT) Received: from halla.dacom.co.kr ([164.124.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA07716 for ; Mon, 14 Oct 1996 17:08:02 -0700 (PDT) Received: (from khr@localhost) by halla.dacom.co.kr (8.6.12h2/8.6.9) id JAA22504 for freebsd-scsi@freebsd.org; Tue, 15 Oct 1996 09:03:45 +0900 From: Kil-Hyen Ryu Message-Id: <199610150003.JAA22504@halla.dacom.co.kr> To: freebsd-scsi@freebsd.org Subject: unsubscribe Date: Tue, 15 Oct 96 9:03:39 KST Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-scsi Thu Oct 17 14:37:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA01742 for freebsd-scsi-outgoing; Thu, 17 Oct 1996 14:37:01 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA01725 for ; Thu, 17 Oct 1996 14:36:40 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA01672; Thu, 17 Oct 1996 16:35:30 -0500 From: Joe Greco Message-Id: <199610172135.QAA01672@brasil.moneng.mei.com> Subject: NCR: Max tags? To: se@zpr.uni-koeln.de Date: Thu, 17 Oct 1996 16:35:29 -0500 (CDT) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello Stefan, I noticed that in 2.1.5R, /usr/src/sys/pci/ncr.c, there is a constant limiting SCSI_NCR_MAX_TAGS to 4. Assuming that I am using fairly modern drives (Seacrate ST31055N "Ultra-SCSI" Hawk-2 1GB, Seacrate ST15150N Barra 4GB), is there a problem with raising this constant? What would a good number be? Always looking for a performance tweak or two, ... JG From owner-freebsd-scsi Thu Oct 17 17:58:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA13906 for freebsd-scsi-outgoing; Thu, 17 Oct 1996 17:58:12 -0700 (PDT) Received: from mortly.xxedgexx.com (root@mortly.xxedgexx.com [204.186.5.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA13897 for ; Thu, 17 Oct 1996 17:58:09 -0700 (PDT) Received: from [206.222.42.167] (pool20-004.wwa.com [207.152.112.69]) by mortly.xxedgexx.com (8.7.6/8.7.3) with ESMTP id VAA21119 for ; Thu, 17 Oct 1996 21:00:48 -0400 X-Sender: josh@jedi.xxedgexx.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Oct 1996 19:59:38 -0600 To: freebsd-scsi@FreeBSD.org From: josh Subject: fd tmc-1680 help?! Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk i've got a future domain tmc-1680 scsi host adapter. so far, the only operating systems which i can find to support this are the hard to obtain redhat linux, and the clunky, propriatery sco openserver r5. after reading through the freebsd-scsi mailing list archives, all i've found is requests for a tmc-16xx series driver. i have not, however, found a driver. does such a driver exist? i'm not interested in compiling my own kernel, so if anyone can point me towards a pre-built kernel that will support my scsi card, please let me know. thanks in advance, joshua .-- -. ._. ._. .___. .____.| ._| \ \^\ \/ ^ \' - \ ._' --\ \ \ .___. |----------------------------------------------- '__^___'._^___'._____'__. g e e k t i l l d e a t h. --------------------------------------------------------------------------- whenallelsefails / 1707 keeney st., evanston, il. 60202 / jedi.xxedgexx.com --------------------------------------------------------------------------- From owner-freebsd-scsi Fri Oct 18 09:27:29 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05172 for freebsd-scsi-outgoing; Fri, 18 Oct 1996 09:27:29 -0700 (PDT) Received: from rs1.rrz.Uni-Koeln.DE (rs1.rrz.Uni-Koeln.DE [134.95.100.208]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA05142; Fri, 18 Oct 1996 09:27:07 -0700 (PDT) Received: from pc1.scs-koeln.de ([134.95.30.183]) by rs1.rrz.Uni-Koeln.DE with SMTP id AA80489 (5.67b/IDA-1.5); Fri, 18 Oct 1996 18:24:25 +0200 Message-Id: <1.5.4.32.19961018162233.00695060@mail.rrz.uni-koeln.de> X-Sender: afr04@mail.rrz.uni-koeln.de X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Oct 1996 18:22:33 +0200 To: freebsd-scsi@freebsd.org From: Ralf Luettgen Subject: SCSI-Command to eject a JAZ Disk Cc: freebsd-sos@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello. The last two days I tested the Iomega Jaz drive under FreeBSD 2.1.5 and it works fine. Is there anyone, who knows the SCSI-Command to eject a disk? Thanks for help Ralf From owner-freebsd-scsi Fri Oct 18 15:52:19 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA28458 for freebsd-scsi-outgoing; Fri, 18 Oct 1996 15:52:19 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA28449 for ; Fri, 18 Oct 1996 15:52:13 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA08547; Sat, 19 Oct 1996 00:52:09 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA01331; Sat, 19 Oct 1996 00:52:08 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.6/8.6.9) id XAA29364; Fri, 18 Oct 1996 23:47:17 +0200 (MET DST) From: J Wunsch Message-Id: <199610182147.XAA29364@uriah.heep.sax.de> Subject: Re: SCSI-Command to eject a JAZ Disk To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Date: Fri, 18 Oct 1996 23:47:17 +0200 (MET DST) Cc: afr04@rs1.rrz.Uni-Koeln.DE (Ralf Luettgen) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <1.5.4.32.19961018162233.00695060@mail.rrz.uni-koeln.de> from Ralf Luettgen at "Oct 18, 96 06:22:33 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Ralf Luettgen wrote: > The last two days I tested the Iomega Jaz drive under FreeBSD 2.1.5 and it > works fine. Is there anyone, who knows the SCSI-Command to eject a disk? START STOP UNIT, with LoEj = 1 and Start = 0 (and unit set to your driver unit number, apparently). scsi -f /dev/rsd${unit}.ctl -c "1b 0 0 0 0:b6 v:b1 v:b1 0" $LoEj $Start -- 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. ;-) From owner-freebsd-scsi Fri Oct 18 15:52:31 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA28497 for freebsd-scsi-outgoing; Fri, 18 Oct 1996 15:52:31 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA28491 for ; Fri, 18 Oct 1996 15:52:28 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA08527; Sat, 19 Oct 1996 00:51:56 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA01327; Sat, 19 Oct 1996 00:51:55 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.6/8.6.9) id WAA28525; Fri, 18 Oct 1996 22:38:42 +0200 (MET DST) From: J Wunsch Message-Id: <199610182038.WAA28525@uriah.heep.sax.de> Subject: Re: fd tmc-1680 help?! To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Date: Fri, 18 Oct 1996 22:38:42 +0200 (MET DST) Cc: josh@xxedgexx.com (josh) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from josh at "Oct 17, 96 07:59:38 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As josh wrote: > i've got a future domain tmc-1680 scsi host adapter. > does such a driver exist? To the best of my knowledge, no. I've once heard a rumour of someone going to write one, but it seems to remain a rumour. You are invited to write one... (Btw., ain't this the beast that's now called ``AHA-1505'' or somesuch?) -- 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. ;-)