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 <freebsd-scsi@freebsd.org>; 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 <freebsd-scsi@freebsd.org>); 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 <freebsd-scsi@freebsd.org>; Sun, 13 Oct 1996 23:20:14 -0400 (EDT)
Date: Sun, 13 Oct 1996 23:20:14 -0400 (EDT)
From: Brian Tao <taob@io.org>
To: FREEBSD-SCSI-L <freebsd-scsi@freebsd.org>
Subject: Wonky controller or drive?
Message-Id: <Pine.NEB.3.92.961013224954.12078B-100000@zap.io.org>
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 <Digital DC21140 Fast Ethernet> 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 <ncr 53c810 scsi> 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 <freebsd-scsi@freebsd.org>; 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 <freebsd-scsi@freebsd.org>; Sun, 13 Oct 1996 23:26:24 -0400 (EDT)
Date: Sun, 13 Oct 1996 23:26:23 -0400 (EDT)
From: Brian Tao <taob@io.org>
To: FREEBSD-SCSI-L <freebsd-scsi@freebsd.org>
Subject: High-capacity tape libraries
Message-ID: <Pine.NEB.3.92.961013232441.12078C-100000@zap.io.org>
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 <freebsd-scsi@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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 <freebsd-scsi@FREEBSD.ORG>; 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 <gordon@drogon.net>
X-Sender: gordon@unicorn
To: Joe Greco <jgreco@brasil.moneng.mei.com>
cc: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>, 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: <Pine.LNX.3.91.961014132103.19196D-100000@unicorn>
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 <freebsd-scsi@freebsd.org>; 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 <jgreco@brasil.moneng.mei.com>
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 <freebsd-scsi@freebsd.org>; 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 <freebsd-scsi@freebsd.org>); 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: <Pine.NEB.3.92.961013224954.12078B-100000@zap.io.org>; from Brian Tao on Oct 13, 1996 23:20:14 -0400
References: <Pine.NEB.3.92.961013224954.12078B-100000@zap.io.org>
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 <freebsd-scsi@freebsd.org>; 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" <rgrimes@GndRsh.aac.dev.com>
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 <freebsd-scsi@freebsd.org>; 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 <freebsd-scsi@freebsd.org>); 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 <freebsd-scsi@freebsd.org>; 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 <jgreco@brasil.moneng.mei.com>
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 <freebsd-scsi@freebsd.org>; 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 <taob@io.org>
To: Stefan Esser <se@zpr.uni-koeln.de>
cc: FREEBSD-SCSI-L <freebsd-scsi@freebsd.org>
Subject: Re: Wonky controller or drive?
In-Reply-To: <199610141501.RAA00816@x14.mi.uni-koeln.de>
Message-ID: <Pine.BSF.3.95.961014114553.2494F-100000@rogue.io.org>
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 <freebsd-scsi@freebsd.org>; 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 <freebsd-scsi@freebsd.org>); 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: <Pine.BSF.3.95.961014114553.2494F-100000@rogue.io.org>; from Brian Tao on Oct 14, 1996 11:58:59 -0400
References: <Pine.BSF.3.95.961014114553.2494F-100000@rogue.io.org>
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 <freebsd-scsi@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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 <freebsd-scsi@FreeBSD.org>; 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 <jgreco@brasil.moneng.mei.com>
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 <freebsd-scsi@FreeBSD.ORG>; 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 <wilko@yedi.iaf.nl>
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: <Pine.NEB.3.92.961013232441.12078C-100000@zap.io.org> 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 <freebsd-scsi@FreeBSD.org>; 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 <dufault@hda.com>
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 <freebsd-scsi@FreeBSD.org>; 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 <jgreco@brasil.moneng.mei.com>
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 <MEI QL 540 cyl 2799 alt 2 hd 3 sec 128>
/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 <freebsd-scsi@freebsd.org>; 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 <khr@halla.dacom.co.kr>
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 <freebsd-scsi@freebsd.org>; 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 <jgreco@brasil.moneng.mei.com>
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 <freebsd-scsi@FreeBSD.org>; 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 <freebsd-scsi@FreeBSD.org>; Thu, 17 Oct 1996 21:00:48 -0400
X-Sender: josh@jedi.xxedgexx.com
Message-Id: <v03007802ae8c94ef0621@[206.222.42.167]>
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 <josh@xxedgexx.com>
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 <afr04@rs1.rrz.Uni-Koeln.DE>
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 <freebsd-scsi@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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 <freebsd-scsi@FreeBSD.org>; 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 <j@uriah.heep.sax.de>
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: <v03007802ae8c94ef0621@[206.222.42.167]> 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. ;-)