From owner-freebsd-scsi Sun Sep 28 00:20:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14891 for freebsd-scsi-outgoing; Sun, 28 Sep 1997 00:20:45 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA14869 for ; Sun, 28 Sep 1997 00:20:39 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA00268; Sun, 28 Sep 1997 09:20:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA00691; Sun, 28 Sep 1997 09:07:50 +0200 (MET DST) Message-ID: <19970928090750.FH40216@uriah.heep.sax.de> Date: Sun, 28 Sep 1997 09:07:50 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Cc: langfod@dihelix.com (David Langford) Subject: Re: Possible ncr problem? References: <199709280439.SAA00307@caliban.dihelix.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 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 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709280439.SAA00307@caliban.dihelix.com>; from David Langford on Sep 27, 1997 18:39:31 -1000 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As David Langford wrote: > Any thought on what this means? > assertion "cp" failed: file "../../pci/ncr.c", line 6228 > sd1: COMMAND FAILED (4 28) @f0497000. > assertion "cp" failed: file "../../pci/ncr.c", line 6228 > sd1: COMMAND FAILED (4 28) @f0497000. Please, re-read the answers Stefan gave to this question in the mailing list archives for freebsd-scsi. Basically, the IBM drives seem to dislike tagged commands when it comes to START STOP UNIT. Removing the scsi_start_unit() from sdopen() probably solves your (and my :) problem, but i didn't try so far. The upcoming CAM code is supposed to handle this situation better. -- 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 Sun Sep 28 06:14:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA00722 for freebsd-scsi-outgoing; Sun, 28 Sep 1997 06:14:49 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA00715 for ; Sun, 28 Sep 1997 06:14:45 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id XAA14224 for freebsd-scsi@freebsd.org; Sun, 28 Sep 1997 23:14:40 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id XAA16851; Sun, 28 Sep 1997 23:09:13 +1000 (EST) Message-Id: <199709281309.XAA16851@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: freebsd-scsi@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: Possible ncr problem? References: <199709280439.SAA00307@caliban.dihelix.com> <19970928090750.FH40216@uriah.heep.sax.de> In-Reply-To: <19970928090750.FH40216@uriah.heep.sax.de> from J Wunsch at "Sun, 28 Sep 1997 07:07:50 +0000" Date: Sun, 28 Sep 1997 23:09:13 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sunday, 28th September 1997, J Wunsch wrote: >As David Langford wrote: > >> Any thought on what this means? > >> assertion "cp" failed: file "../../pci/ncr.c", line 6228 >> sd1: COMMAND FAILED (4 28) @f0497000. >> assertion "cp" failed: file "../../pci/ncr.c", line 6228 >> sd1: COMMAND FAILED (4 28) @f0497000. > >Please, re-read the answers Stefan gave to this question in the >mailing list archives for freebsd-scsi. > >Basically, the IBM drives seem to dislike tagged commands when it >comes to START STOP UNIT. Removing the scsi_start_unit() from >sdopen() probably solves your (and my :) problem, but i didn't try so >far. > >The upcoming CAM code is supposed to handle this situation better. If there is a rough hack that could be applied to 2.2.5, I think we should. This problem is becoming more widespread (with the growing popularity of NCR controllers and IBM disks) and the CAM code will not be here in time. If we could make the message a little bit less horrifying, it would be a start. I can test any fixes, but I don't think I'll be able to generate any in time. Stephen. From owner-freebsd-scsi Sun Sep 28 07:16:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA03312 for freebsd-scsi-outgoing; Sun, 28 Sep 1997 07:16:04 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA03289 for ; Sun, 28 Sep 1997 07:15:53 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA22430; Mon, 29 Sep 1997 00:14:32 +1000 Date: Mon, 29 Sep 1997 00:14:32 +1000 From: Bruce Evans Message-Id: <199709281414.AAA22430@godzilla.zeta.org.au> To: freebsd-scsi@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: Possible ncr problem? Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>Basically, the IBM drives seem to dislike tagged commands when it >>comes to START STOP UNIT. Removing the scsi_start_unit() from >>sdopen() probably solves your (and my :) problem, but i didn't try so >>far. >> >>The upcoming CAM code is supposed to handle this situation better. > >If there is a rough hack that could be applied to 2.2.5, I think we should. >This problem is becoming more widespread (with the growing popularity of >NCR controllers and IBM disks) and the CAM code will not be here in time. Just don't call scsi_start_unit() if the device is already open. I first saw the problem using something like $ dd if=/dev/zero of=bigfile bs=1m count=20 $ "a program `fileblocks' which opens the raw device behind `bigfile' to determine the file blocks in `bigfile'" It is now obvious how this causes problems: there is a fair amount of i/o in progress when the dd finishes, and opening the raw device causes an scsi_start_unit() which does bad things to the i/o. BTW, shouldn't the device be locked just before scsi_test_unit_ready() instead of just after it? BTW2, locking of open() is still missing from all SCSI drivers except sd. Bruce From owner-freebsd-scsi Sun Sep 28 14:04:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22721 for freebsd-scsi-outgoing; Sun, 28 Sep 1997 14:04:51 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA22712 for ; Sun, 28 Sep 1997 14:04:42 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA19973 (5.67b/IDA-1.5 for ); Sun, 28 Sep 1997 23:04:27 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id LAA00968; Sun, 28 Sep 1997 11:01:43 +0200 (CEST) X-Face: " Date: Sun, 28 Sep 1997 11:01:42 +0200 From: Stefan Esser To: David Langford Cc: scsi@FreeBSD.ORG Subject: Re: Possible ncr problem? References: <199709280439.SAA00307@caliban.dihelix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709280439.SAA00307@caliban.dihelix.com>; from David Langford on Sat, Sep 27, 1997 at 06:39:31PM -1000 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 27, David Langford wrote: > Any thought on what this means? Yes, again the QUEUE_FULL problem of the DORS. This drive can't deal with a reasonable number of tagged commands at times, it seems. Since the generic SCSI layer will immediately re-issue the failed command, there will be no adverse effect, if it succeeds within 5 retries. The new generic SCSI code currently being prepared by Justin Gibbs will take care of this problem. > After reconfiguring my SCSI chain several times I think I can > rule bad termination. > > Bad drive could be. I only have seen these errors if I "dump" > the main partition on the drive or place my "obj" directory and do a > "make world". I have been wondering, whether the problem is caused by sending an unnecessary START_STOP_UNIT when the raw partition is opened. IBM drives did never like that ... You may want to remove the call of scsi_start_unit() from sd.c (there is only one occurance), and see whether the error messages are still printed ... > Fsck doesnt show problems and bad144 at least seemed to scan the drive without > any console messages showing up. Fsck does also open the raw partition, but at that time, there should not be any other activity. I'm guessing, that even a START_STOP_UNIT command that is a NOP because the drive motor had been started long ago, does collide with any other command on IBM drives. > assertion "cp" failed: file "../../pci/ncr.c", line 6228 > sd1: COMMAND FAILED (4 28) @f0497000. > assertion "cp" failed: file "../../pci/ncr.c", line 6228 > sd1: COMMAND FAILED (4 28) @f0497000. The 28 identifies QUEUE_FULL status, the 4 just is an indication, that processing of the command run to completion, as far as the NCR controller and the driver are concerned. > sd0: type 0 fixed SCSI 2 > sd1: type 0 fixed SCSI 2 There was roumor, that the non-wide DORS does not support as many tags as the wide version, though I never had a chance to confirm this myself. If you want to help debug the problem, then please try a kernel that does not start the SCSI drives in /sys/scsi/sd.c:sdopen(). Regards, STefan From owner-freebsd-scsi Sun Sep 28 23:37:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21572 for freebsd-scsi-outgoing; Sun, 28 Sep 1997 23:37:27 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA21558 for ; Sun, 28 Sep 1997 23:37:20 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 907 invoked by uid 1001); 29 Sep 1997 06:37:15 +0000 (GMT) To: se@FreeBSD.ORG Cc: scsi@FreeBSD.ORG Subject: Re: Possible ncr problem? In-Reply-To: Your message of "Sun, 28 Sep 1997 11:01:42 +0200" References: <19970928110142.45106@mi.uni-koeln.de> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 29 Sep 1997 08:37:14 +0200 Message-ID: <905.875515034@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Any thought on what this means? > > Yes, again the QUEUE_FULL problem of the DORS. > This drive can't deal with a reasonable number > of tagged commands at times, it seems. Since > the generic SCSI layer will immediately re-issue > the failed command, there will be no adverse > effect, if it succeeds within 5 retries. I have a slightly different problem. I have an ASUS SC200 controller with a Seagate ST15150N (the old half-height 4 GB Barracuda) and an IBM DORS 32160. The bootup messages are: (ncr0:0:0): "IBM DORS-32160 WA0A" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): 10.0 MB/s (100 ns, offset 8) (ncr0:1:0): "SEAGATE ST15150N 0022" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): 10.0 MB/s (100 ns, offset 8) My problem is that I get the COMMAND FAILED, Sep 29 02:05:09 verdi /kernel: assertion "cp" failed: file "../../pci/ncr.c", line 5565 Sep 29 02:05:09 verdi /kernel: sd1(ncr0:1:0): COMMAND FAILED (4 28) @f08e1600. at irregular intervals, and it's always the Seagate disk it happens to. When this starts, it never stops again until I reboot the machine. The machine quickly becomes unusable when it happens. (And yes, it happened again last night, while /etc/daily was being run.) Any ideas? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-scsi Sun Sep 28 23:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22536 for freebsd-scsi-outgoing; Sun, 28 Sep 1997 23:50:59 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA22501 for ; Sun, 28 Sep 1997 23:50:50 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA13228 for freebsd-scsi@FreeBSD.ORG; Mon, 29 Sep 1997 08:50:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA03648; Mon, 29 Sep 1997 08:50:47 +0200 (MET DST) Message-ID: <19970929085047.AZ40873@uriah.heep.sax.de> Date: Mon, 29 Sep 1997 08:50:47 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Subject: Re: Possible ncr problem? References: <199709280439.SAA00307@caliban.dihelix.com> <19970928090750.FH40216@uriah.heep.sax.de> <199709281309.XAA16851@ogre.dtir.qld.gov.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 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 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709281309.XAA16851@ogre.dtir.qld.gov.au>; from Stephen McKay on Sep 28, 1997 23:09:13 +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stephen McKay wrote: > If there is a rough hack that could be applied to 2.2.5, I think we should. options FAILSAFE This is part of GENERIC already, and prevents the ncr driver from using tagged command queuing. Tagged commands on ahc have to be enabled explicitly, so i think the defaults are pretty safe. -- 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 Sep 29 04:01:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA04401 for freebsd-scsi-outgoing; Mon, 29 Sep 1997 04:01:44 -0700 (PDT) Received: from indigo.ie (aoife.indigo.ie [194.125.133.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA04357; Mon, 29 Sep 1997 04:01:27 -0700 (PDT) Received: from indigo.ie (localhost [127.0.0.1]) by indigo.ie (8.8.5/8.8.5/INDIGO-HUB) with ESMTP id MAA16750; Mon, 29 Sep 1997 12:01:25 +0100 (BST) Message-Id: <199709291101.MAA16750@indigo.ie> To: scsi@freebsd.org, stable@freebsd.org Subject: Kernel disk hangs under load with 2.2-STABLE From: Alan Judge Date: Mon, 29 Sep 1997 12:01:24 +0100 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Posting to both scsi and stable, since I'm not sure which is at fault and if there is a hang bug in 2.2-STABLE, it would be good to find it.] I have a machine running squid (with the data stored on a CCD striped set of disks). Since it's a major web cache, the disks get a fairly steady and sometimes heavy load. The machine doesn't do anything else and squid is the only large process (RSS of 120MB on a 256MB machine). The kernel is 2.2-STABLE, cvsuped last Tuesday; hardware is dual Adaptec 2940UWs with Quantum Atlas II UW disks. No unusual config options other than increases of NBUF and NMBCLUSTERS. Every so often (about once in two to three days), the squid process hangs and shows up in D state in ps. The process cannot be killed and commands that are disk related sometimes hang. The only cure is to reboot, and the reboot is usually not clean (syncing disks, .... giving up). Oddly, reducing the size of the web cache (which indirectly reduces squids RSS and the proportion of the CCD array in use) reduces the frequency of the hangs. I know that's probably not enough info to find a bug. Any suggestions on how to start debugging this? What commands should I try? How do I find what squid is stuck waiting for? Should I bring up gdb or DDB and look at something? -- Alan Judge Phone: +353-1-6046901 Indigo Network Operations Centre Fax: +353-1-6046948 From owner-freebsd-scsi Mon Sep 29 13:18:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA05913 for freebsd-scsi-outgoing; Mon, 29 Sep 1997 13:18:51 -0700 (PDT) Received: from caliban.dihelix.com (caliban.dihelix.com [198.180.136.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA05902; Mon, 29 Sep 1997 13:18:38 -0700 (PDT) Received: (from langfod@localhost) by caliban.dihelix.com (8.8.7/8.8.3) id KAA18082; Mon, 29 Sep 1997 10:18:32 -1000 (HST) Message-Id: <199709292018.KAA18082@caliban.dihelix.com> Subject: Re: Possible ncr problem? In-Reply-To: <19970928110142.45106@mi.uni-koeln.de> from Stefan Esser at "Sep 28, 97 11:01:42 am" To: se@freebsd.org (Stefan Esser) Date: Mon, 29 Sep 1997 10:18:31 -1000 (HST) Cc: langfod@dihelix.com, scsi@freebsd.org From: "David Langford" X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4ME+ PL31 (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 Interesting that this never happened to me with sd0 but ony to sd1 when I added it to the chain. Well I have a new kernel without the scsi_start_unit() in "sd.c". I have a "make world" running and I did a partial "dump" to "/dev/null". So far no nasty "sd1: COMMAND FAILED (4 28) @f0497000" messages. -David Langford langfod@dihelix.com >Yes, again the QUEUE_FULL problem of the DORS. >This drive can't deal with a reasonable number >of tagged commands at times, it seems. Since >the generic SCSI layer will immediately re-issue >the failed command, there will be no adverse >effect, if it succeeds within 5 retries. > >You may want to remove the call of scsi_start_unit() >from sd.c (there is only one occurance), and see >whether the error messages are still printed ... > >> sd0: type 0 fixed SCSI 2 >> sd1: type 0 fixed SCSI 2 > >There was roumor, that the non-wide DORS does not >support as many tags as the wide version, though I >never had a chance to confirm this myself. >If you want to help debug the problem, then please >try a kernel that does not start the SCSI drives >in /sys/scsi/sd.c:sdopen(). >Regards, STefan From owner-freebsd-scsi Mon Sep 29 14:42:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA12287 for freebsd-scsi-outgoing; Mon, 29 Sep 1997 14:42:51 -0700 (PDT) Received: from iago.ienet.com (iago.ienet.com [207.78.32.53]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA12277 for ; Mon, 29 Sep 1997 14:42:45 -0700 (PDT) Received: from iago.ienet.com (localhost.ienet.com [127.0.0.1]) by iago.ienet.com (8.8.5/8.8.5) with ESMTP id OAA14361 Mon, 29 Sep 1997 14:42:42 -0700 (PDT) Message-Id: <199709292142.OAA14361@iago.ienet.com> To: freebsd-scsi@FreeBSD.ORG, terryl@ienet.com From: pius@ienet.com Subject: adding SCSI drive to a live system Date: Mon, 29 Sep 1997 14:42:42 -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is it possible to add a SCSI drive to a running system? The system is running FreeBSD 2.1.7.1-stable (last cvsupped and made world on May 9, 1997). Can one connect the drive to the SCSI bus and then probe all devices on the bus again? The -p option to the scsi(8) command claims to be able to do this, but the "super scsi" device mentioned in the man page doesn't seem to exist. Any ideas on how to achieve this? Thanks very much, Pius From owner-freebsd-scsi Mon Sep 29 21:16:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA00397 for freebsd-scsi-outgoing; Mon, 29 Sep 1997 21:16:40 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA00392 for ; Mon, 29 Sep 1997 21:16:30 -0700 (PDT) Received: (qmail 26680 invoked by uid 1000); 30 Sep 1997 04:16:44 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092597 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709292142.OAA14361@iago.ienet.com> Date: Mon, 29 Sep 1997 21:16:44 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: pius@ienet.com Subject: RE: adding SCSI drive to a live system Cc: terryl@ienet.com, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi pius@ienet.com; On 29-Sep-97 you wrote: > > Is it possible to add a SCSI drive to a running system? > > The system is running FreeBSD 2.1.7.1-stable (last cvsupped and made > world on May 9, 1997). > > Can one connect the drive to the SCSI bus and then probe all devices > on the bus again? The -p option to the scsi(8) command claims to be > able to do this, but the "super scsi" device mentioned in the man page > doesn't seem to exist. > > Any ideas on how to achieve this? I do not remember the details on the software side, but you have to be careful on the hardware side. Most scsi subsystems belch when devices physically connect and disconnect under power. --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-scsi Tue Sep 30 00:23:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA08966 for freebsd-scsi-outgoing; Tue, 30 Sep 1997 00:23:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA08960 for ; Tue, 30 Sep 1997 00:23:33 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA28774; Tue, 30 Sep 1997 09:23:21 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA07882; Tue, 30 Sep 1997 09:20:23 +0200 (MET DST) Message-ID: <19970930092023.NO30665@uriah.heep.sax.de> Date: Tue, 30 Sep 1997 09:20:23 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: pius@ienet.com, terryl@ienet.com Subject: Re: adding SCSI drive to a live system References: <199709292142.OAA14361@iago.ienet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 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 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709292142.OAA14361@iago.ienet.com>; from pius@ienet.com on Sep 29, 1997 14:42:42 -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As pius@ienet.com wrote: > Can one connect the drive to the SCSI bus and then probe all devices > on the bus again? The -p option to the scsi(8) command claims to be > able to do this, but the "super scsi" device mentioned in the man page > doesn't seem to exist. It does exist, provided you're configuring the `su' and `ssc' pseudo-devices. I was contemplating to add them by default in future releases. However, you don't need /dev/scsisuper if you've got at least one device on any SCSI bus already configured at boot time. (The `super' device is only needed if all SCSI busses were empty at boot time.) Say, your sd0 was already there when booting, so just do scsi -f /dev/rsd0.ctl -r Remember to always use the control devices for this kind of stuff; they are merely a hookup into the SCSI layers without actually touching the device itself already at open() time. NB: there's no method to un-probe some device right now. But, i think you can have more than one device configured at the same target ID. Say, you've once had a direct-access device on ID 4, sd1. Later on, you disconnect this target, and add a sequential target at ID 4. Run a scsi -r, and you should be able to use it as (assume) st0. -- 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 Tue Sep 30 12:31:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15909 for freebsd-scsi-outgoing; Tue, 30 Sep 1997 12:31:37 -0700 (PDT) Received: from caliban.dihelix.com (caliban.dihelix.com [198.180.136.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15888; Tue, 30 Sep 1997 12:31:29 -0700 (PDT) Received: (from langfod@localhost) by caliban.dihelix.com (8.8.7/8.8.3) id JAA06320; Tue, 30 Sep 1997 09:31:25 -1000 (HST) Date: Tue, 30 Sep 1997 09:31:25 -1000 (HST) From: David Langford Message-Id: <199709301931.JAA06320@caliban.dihelix.com> To: multimedia@freebsd.org, scsi@freebsd.org Subject: Readin DAT Audio tapes? Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there an easy way to play DAT audio tapes with any of the standard DAT drives? worse case: would "dd" work? Thanks, -David Langford langfod@dihelix.com From owner-freebsd-scsi Tue Sep 30 14:07:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22145 for freebsd-scsi-outgoing; Tue, 30 Sep 1997 14:07:21 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA22137 for ; Tue, 30 Sep 1997 14:07:13 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA06831 (5.67b/IDA-1.5 for freebsd-scsi@FreeBSD.ORG); Tue, 30 Sep 1997 23:07:28 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA00782; Tue, 30 Sep 1997 19:18:26 +0100 (MET) From: Wilko Bulte Message-Id: <199709301818.TAA00782@yedi.iaf.nl> Subject: Re: adding SCSI drive to a live system To: pius@ienet.com Date: Tue, 30 Sep 1997 19:18:26 +0100 (MET) Cc: freebsd-scsi@FreeBSD.ORG, terryl@ienet.com In-Reply-To: <199709292142.OAA14361@iago.ienet.com> from "pius@ienet.com" at Sep 29, 97 02:42:42 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.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 pius@ienet.com wrote... > > > Is it possible to add a SCSI drive to a running system? > > The system is running FreeBSD 2.1.7.1-stable (last cvsupped and made > world on May 9, 1997). > > Can one connect the drive to the SCSI bus and then probe all devices > on the bus again? The -p option to the scsi(8) command claims to be > able to do this, but the "super scsi" device mentioned in the man page > doesn't seem to exist. I tend to do things like: scsi -r -f /dev/rsd0c (where sd0 is my root disk, and therefore always present). Please note that you better use some scsi bus / hot swap enclosure if you want to do this. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ----------------------------------------------------------------------Yoda From owner-freebsd-scsi Wed Oct 1 03:14:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04129 for freebsd-scsi-outgoing; Wed, 1 Oct 1997 03:14:13 -0700 (PDT) Received: from DonaldBurr.dyn.ml.org (dburr@[206.18.115.71]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04110; Wed, 1 Oct 1997 03:14:01 -0700 (PDT) Received: (from dburr@localhost) by DonaldBurr.dyn.ml.org (8.8.5/8.8.5) id DAA01071; Wed, 1 Oct 1997 03:13:08 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Wed, 01 Oct 1997 03:00:52 -0700 (PDT) Organization: Starfleet Command From: Donald Burr To: AIC7xxx List , FreeBSD SCSI , FreeBSD Hardware Subject: Odd behavior of Wangtek 5525ES SCSI tape drive under 2.2.2 and A Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I am the proud owner of a (ahc0:4:0): "WANGTEK 5525ES SCSI 73R1" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x0, drive empty Wangtek 5525ES SCSI-2 tape drive (525MB QIC-525 drive). It's connected to my brand-new Adaptec AHA-2940AU PCI SCSI controller (aic7860), on my FreeBSD 2.2.2-RELEASE system. This setup works pretty well. I've already done several successful dumps to this device, and have created more tar tapes than I can shake a stick at. The weirdness comes with the `mt' command. Basically, any "mt" command that causes the tape drive to spin (weof, retension, fsf, etc.) SOMETIMES (probably 1 in 10 times) causes the system to "soft hang". Processes keep running, I can switch to another VC and login, or telnet to the machine over the network, etc. BUT the mt process is hung -- I can't exit with Ctrl-C, or kill (even kill -KILL) it. Ctrl-Z fails to suspend the thing, and the process fails to die on a reboot/shutdown (this results in the "syncing disks...giving up" message). And the tape drive don't spin. BUT, other commands that access the tape drive (tar, dump, even dd) work fine!!! unix% tar cv /some/dir /some/dir/a /some/dir/a/file /some/dir/b/dir /some/dir/c/file2 ...tape drive chugs away, and finishes successfully unix% dump 0auf /dev/rst0 / DUMP: .... [successful dump] unix% dd if=/dev/rst0 of=/dev/zero ...blahblahblah unix% mt retension [ oops - hung. Big Red Button time. ] I have tried the usual remedies -- checking cables and termination, disconnecting all SCSI devices EXCEPT the tape drive, etc. Nothing helps. As stated above, I run 2.2.2-RELEASE. I have tried one of the RELENG kernels (970913 I think), with the same behavior. Unfortunately I'm not man enough to try CURRENT. :) My controller is an Adaptec AHA-2940AU PCI SCSI controller (aic7860). The controller works great, and all of my other devices (JAZ, cd-rom, etc.) work flawlessly. Any ideas? dmesg output follows: Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.2-RELEASE #0: Mon Sep 15 01:19:35 PDT 1997 root@DonaldBurr.DonaldBurr.dyn.ml.org:/usr/src/sys/compile/DONALDBURR CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x4f4 Stepping=4 Features=0x1 real memory = 33554432 (32768K bytes) avail memory = 30396416 (29684K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:5 vga0 rev 71 on pci0:11 ahc0 rev 1 int a irq 11 on pci0:13 ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs ahc0 waiting for scsi devices to settle (ahc0:1:0): "NEC CD-ROM DRIVE:462 1.16" type 5 removable SCSI 2 cd0(ahc0:1:0): CD-ROM can't get the size (ahc0:2:0): "iomega jaz 1GB H.72" type 0 removable SCSI 2 sd0(ahc0:2:0): Direct-Access sd0(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd0 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) sd0(ahc0:2:0): with 1021 cyls, 64 heads, and an average 32 sectors/track (ahc0:4:0): "WANGTEK 5525ES SCSI 73R1" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x0, drive empty ed0 rev 0 int a irq 9 on pci0:15 ed0: address 00:00:b4:5a:4e:71, type NE2000 (16 bit) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <12 virtual consoles, flags=0x0> lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , 32-bit, multi-block-32 wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0x80ff80ff on isa wdc1: unit 0 (wd2): , 32-bit, multi-block-32 wd2: 234MB (479632 sectors), 967 cyls, 16 heads, 31 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface sb0 at 0x220 irq 10 drq 1 on isa sb0: opl0 at 0x388 on isa opl0: sctarg0(noadapter::): Processor Target Donald Burr - Ask me for my PGP key | PGP: Your WWW HomePage: http://DonaldBurr.base.org/ ICQ #1347455 | right to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNDIiMvjpixuAwagxAQG2OwQArwrX8X64kdcoH4IyyBFNG4Z8odYXNia3 eRgNWLgurrLdqHDCe3X9fF6wEsMHhVYC341NhjbgIFOtcuHXxWZzYBccdVyxWbE4 CZ0O762RdASE9ezNnnDvNnTysYl7c0hh2efti8HZdUbhorpByx98p/IhLn/8QhLs KDdzQ9vGqcA= =E/1T -----END PGP SIGNATURE----- From owner-freebsd-scsi Wed Oct 1 06:44:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA13913 for freebsd-scsi-outgoing; Wed, 1 Oct 1997 06:44:15 -0700 (PDT) Received: from anise.csv.warwick.ac.uk (csubl@anise.csv.warwick.ac.uk [137.205.192.106]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA13854; Wed, 1 Oct 1997 06:43:24 -0700 (PDT) From: Mr M P Searle Message-Id: <1996.199710011340@anise.csv.warwick.ac.uk> Received: by anise.csv.warwick.ac.uk id OAA01996; Wed, 1 Oct 1997 14:40:04 +0100 (BST) Subject: Re: Odd behavior of Wangtek 5525ES SCSI tape drive under 2.2.2 and A In-Reply-To: from Donald Burr at "Oct 1, 97 03:00:52 am" To: dburr@poboxes.com (Donald Burr) Date: Wed, 1 Oct 1997 14:39:54 +0100 (BST) Cc: aic7xxx@freebsd.org, freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (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 -- Start of PGP signed section. > I am the proud owner of a > > (ahc0:4:0): "WANGTEK 5525ES SCSI 73R1" type 1 removable SCSI 2 > st0(ahc0:4:0): Sequential-Access density code 0x0, drive empty > > Wangtek 5525ES SCSI-2 tape drive (525MB QIC-525 drive). It's connected to > my brand-new Adaptec AHA-2940AU PCI SCSI controller (aic7860), on my > FreeBSD 2.2.2-RELEASE system. > > This setup works pretty well. I've already done several successful dumps > to this device, and have created more tar tapes than I can shake a stick > at. > > The weirdness comes with the `mt' command. Basically, any "mt" command > that causes the tape drive to spin (weof, retension, fsf, etc.) SOMETIMES > (probably 1 in 10 times) causes the system to "soft hang". Processes keep > running, I can switch to another VC and login, or telnet to the machine > over the network, etc. BUT the mt process is hung -- I can't exit with > Ctrl-C, or kill (even kill -KILL) it. Ctrl-Z fails to suspend the thing, > and the process fails to die on a reboot/shutdown (this results in the > "syncing disks...giving up" message). And the tape drive don't spin. > > BUT, other commands that access the tape drive (tar, dump, even dd) work > fine!!! > > unix% tar cv /some/dir > /some/dir/a > /some/dir/a/file > /some/dir/b/dir > /some/dir/c/file2 > ...tape drive chugs away, and finishes successfully > unix% dump 0auf /dev/rst0 / > DUMP: .... > [successful dump] > unix% dd if=/dev/rst0 of=/dev/zero > ...blahblahblah > unix% mt retension > [ oops - hung. Big Red Button time. ] > > I have tried the usual remedies -- checking cables and termination, > disconnecting all SCSI devices EXCEPT the tape drive, etc. Nothing helps. > > As stated above, I run 2.2.2-RELEASE. I have tried one of the RELENG > kernels (970913 I think), with the same behavior. Unfortunately I'm not > man enough to try CURRENT. :) > > My controller is an Adaptec AHA-2940AU PCI SCSI controller (aic7860). The > controller works great, and all of my other devices (JAZ, cd-rom, etc.) > work flawlessly. > > Any ideas? > Well, no, but you're not the only one. I've got a Tandberg 250MB QIC-250 drive, on an NCR controller. 'mt fsf' will often cause SCSI errors on all devices, a SCSI reset, or a completely hung system (not just that process). 'cat /dev/nrst0 > /dev/null' has no problems, even though it is doing the same thing. I'm not sure that my problem is the same as yours (this drive is generally dodgy - hangs and SCSI errors also happen if I don't wait for one command to complete before running another, or if I try to read two files without rewinding and moving back again between them...), but it looks similar. Anyway, I've worked round it by replacing all the mt commands (mostly fsf) with things like the 'cat /dev/nrst0 > /dev/null' to move forward a file, and anything with /dev/rst0 to rewind. You could probably do the same for a lot of the other mt commands as well. You could also try the 'wait for tape to stop clunking before next command' fix in case mine isn't the only drive in the world to do this. (or put big sleeps in scripts) This is with 2.1.0, so it may be the same thing despite the different errors. From owner-freebsd-scsi Wed Oct 1 07:03:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14902 for freebsd-scsi-outgoing; Wed, 1 Oct 1997 07:03:06 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14872; Wed, 1 Oct 1997 07:02:46 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id IAA12415; Wed, 1 Oct 1997 08:02:37 -0600 (MDT) Message-Id: <199710011402.IAA12415@pluto.plutotech.com> To: Donald Burr cc: AIC7xxx List , FreeBSD SCSI , FreeBSD Hardware Subject: Re: Odd behavior of Wangtek 5525ES SCSI tape drive under 2.2.2 and A In-reply-to: Your message of "Wed, 01 Oct 1997 03:00:52 PDT." Date: Wed, 01 Oct 1997 08:02:10 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >-----BEGIN PGP SIGNED MESSAGE----- > >I am the proud owner of a > >(ahc0:4:0): "WANGTEK 5525ES SCSI 73R1" type 1 removable SCSI 2 >st0(ahc0:4:0): Sequential-Access density code 0x0, drive empty > >Wangtek 5525ES SCSI-2 tape drive (525MB QIC-525 drive). It's connected to >my brand-new Adaptec AHA-2940AU PCI SCSI controller (aic7860), on my >FreeBSD 2.2.2-RELEASE system. Set the termination setting on your 2940AU explicitly. Do not use "Auto Termination". You should also upgrade to the latest version of the aic7xxx driver from 2.2-stable. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Oct 2 20:40:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13334 for freebsd-scsi-outgoing; Thu, 2 Oct 1997 20:40:52 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA13305; Thu, 2 Oct 1997 20:40:46 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA13129; Thu, 2 Oct 1997 21:40:44 -0600 (MDT) Message-Id: <199710030340.VAA13129@pluto.plutotech.com> Date: Thu, 02 Oct 1997 21:40:15 -0600 From: "Justin T. Gibbs" Subject: New SCSI Framework Patches Available Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To: undisclosed-recipients:; ------- Blind-Carbon-Copy X-Mailer: exmh version 2.0zeta 7/24/97 To: gibbs@FreeBSD.org Subject: New SCSI Framework Patches Available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 21:40:15 -0600 From: "Justin T. Gibbs" Common Access Method SCSI layer Patches Available You've all seen messages talking about a new SCSI layer for FreeBSD, and I'm pleased to announce the first Alpha release of that work. I plan to release snapshots on a weekly basis as new features and hardware support are added. To see what is currently supported, skip down to the supported hardware section. So now you must be asking yourself, "What is CAM? and why would I want it?" CAM is an ANSI ratified spec that defines a software interface for talking to SCSI and ATAPI devices. This new SCSI layer for FreeBSD is not strictly CAM compliant, but follows many of the precepts of CAM. More importantly, this work addresses many of the short comings of the previous SCSI layer and should provide better performance, reliability, and ease the task of adding support for new controllers. I hope that many of you will try it. "work in progress", this code has been through over two months of testing here at Pluto and I feel pretty good about the stability of the code. If you do have the facilities to experiment, please do. I welcome your feedback especially about the performance of the new system. Features: Round-robin, per priority level scheduling of devices and their resources. I/O Completion, error recovery, and processing queued I/O is performed in a separate software interrupt handler. The old system had the potential of blocking out hardware interrupts for lengthy periods as much of this processing occurred as the result of a call from the controller's interrupt handler. The generic SCSI layer now understands tagged I/O and exports this functionality to the peripheral drivers. This allows drivers like the "direct access" driver to perform ordered tagged transactions for meta-data writes. Async, ordered, meta-data writes are now enabled in vfs_bio.c The "direct access" driver prevents "tag starvation" from occurring by guaranteeing that at least one write in every 5 second period to a tagged queuing device has an ordered tag. This removes the need for individual controller drivers to worry about this problem. Complete and controller independent handling of the "QUEUE FULL" and "BUSY" status codes. The number of tags that are queued to a device are dynamically adjusted by the generic layer. Interrupt driven sub-device probing. At boot time, all buses are probed in parallel yielding a much faster boot. As probing occurs after all interrupt and timer services are available, no additional (and often error prone) "polling" code is needed in each controller driver. Better error recovery. When an error occurs, the queue of transactions to the erring device is "frozen", full status is reported back to the peripheral driver, and the peripheral driver can recover the device without perturbing queued up I/O. As all transactions have an associated priority and generation count, after recovery is complete, transactions that are retried are automatically re-queued in their original order. All error handling is performed based on a detected failure. The old code would often perform actions "just in case" before accessing a device as the error recovery mechanism was inadequate. Now, for example, if your disk spins down, the system will properly recover even if the device is already open. Support for "high power" commands. Peripheral drivers can mark actions that may tax a power supply as "high powered". Only a certain number (default of 4, but configurable with the CAM_MAX_HIGHPOWER kernel option) of these commands are allowed to be active at a time. This allows a user to, for example, disable spin-up on the drives in an enclosure and let the system spin them up in a controlled fashion. By default, all luns are scanned on devices during probe. In the old SCSI layer, this was often problematic as it performed a Test Unit Ready prior to performing an Identify. Many devices that properly handle the Identify will hang the bus if you attempt a different command to a high lun. Transfer negotiations only occurs to devices that actually support negotiations (based on their inquiry information). This is performed in a controller independent fashion. There is now a generic quirk mechanism that allows controllers, peripheral drivers, or the CAM transport layer to define their own quirks entries. Currently the CAM transport layer has quirk entries that allow for modulation of tags and disabling multi-lun probing. The AdvanSys driver uses quirk entries to control some of the "hardware bug fixes" in the driver that only apply to certain types of devices. Hard-wiring of devices to specific unit numbers is supported as it was in the old system. Userland "pass-through" commands are supported. The interface is different than from the old SCSI code, but sample code is provided (including patches to XMCD), and we do plan to provide a scsi.8 command in the future. SUPPORTED HARDWARE Aic7xxx driver (ahc): This driver supports all of the devices the original FreeBSD driver supports but with the following new features: Autotermination support for aic7860 based cards. Indirect SCB paging that allows up to 255 SCBs to be active on aic7770, aic7850, and aic7860 cards. Bug fixes to the multi-lun support. The beginnings of a target mode implementation. AdvanSys Driver (adv): This driver supports the entire line of AdvanSys narrow channel devices. Tagged queuing is also supported. The only caveat is that bounce buffering is not implemented yet, so ISA cards must be used in systems with less than 16MB of RAM. The next driver I will be working on will support the Buslogic Multimaster cards. Supported peripherals: Direct Access driver (da): 512 byte sectored disk drivers. Support for other sector sizes is planned, but further investigation on the "right" approach for this is needed. It probably belongs in the disk-slice code. CDROM driver (cd): This driver should support everything the old driver did. Other peripheral drivers are in the works. HOW TO INSTALL IT BACKUP YOUR OLD KERNEL!!! cp /kernel /kernel.works Get the code: ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/cam-971002.tar.gz ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/cam-971002.diffs.gz ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/cam-971002samples.tar.gz cd /usr/src tar xvfz cam-971002.tar.gz zcat cam-971002.diffs.gz | patch cd usr.sbin/config make clean all install cd sys/i386/conf vi MYKERNEL Comment out all unsupported SCSI devices, and substitute "da" for "sd". Look in LINT or GENERIC for examples. config MYKERNEL cd ../../MYKERNEL make all make install If you want XMCD or the userland sample code, untar cam-971002samples.tar.gz and read the enclosed README file. - -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== ------- End of Blind-Carbon-Copy From owner-freebsd-scsi Thu Oct 2 23:08:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21333 for freebsd-scsi-outgoing; Thu, 2 Oct 1997 23:08:45 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21327; Thu, 2 Oct 1997 23:08:42 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id XAA26455; Thu, 2 Oct 1997 23:08:01 -0700 (PDT) Date: Thu, 2 Oct 1997 23:08:01 -0700 (PDT) From: Doug White Reply-To: Doug White To: David Langford cc: multimedia@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Readin DAT Audio tapes? In-Reply-To: <199709301931.JAA06320@caliban.dihelix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 30 Sep 1997, David Langford wrote: > > Is there an easy way to play DAT audio tapes with any of the > standard DAT drives? At one point I remember a discussion that DAT backup drives have a media sensor on it and the DAT tapes are encoded depending on their intended use. The audio ones are poorer quality I guess and the DAT drives will reject them. So I don't think that'll work at all, unless you have a drive that says it supports audio tapes too. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major From owner-freebsd-scsi Fri Oct 3 00:42:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA28123 for freebsd-scsi-outgoing; Fri, 3 Oct 1997 00:42:51 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28089; Fri, 3 Oct 1997 00:42:42 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id RAA00415; Fri, 3 Oct 1997 17:05:44 +0930 (CST) Message-ID: <19971003170542.27390@lemis.com> Date: Fri, 3 Oct 1997 17:05:42 +0930 From: Greg Lehey To: Doug White Cc: David Langford , multimedia@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Readin DAT Audio tapes? References: <199709301931.JAA06320@caliban.dihelix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Doug White on Thu, Oct 02, 1997 at 11:08:01PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Oct 02, 1997 at 11:08:01PM -0700, Doug White wrote: > On Tue, 30 Sep 1997, David Langford wrote: > >> >> Is there an easy way to play DAT audio tapes with any of the >> standard DAT drives? > > At one point I remember a discussion that DAT backup drives have a media > sensor on it and the DAT tapes are encoded depending on their intended > use. The audio ones are poorer quality I guess and the DAT drives will > reject them. So I don't think that'll work at all, unless you have a > drive that says it supports audio tapes too. All DDS drives that I know have a switch to determine whether DAT tapes should be rejected. If you want to handle DAT tapes, you could enable them by turning the switch off. Unfortunately, I don't think that that alone would solve the problem. Greg From owner-freebsd-scsi Fri Oct 3 05:06:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09287 for freebsd-scsi-outgoing; Fri, 3 Oct 1997 05:06:17 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA09282 for ; Fri, 3 Oct 1997 05:06:14 -0700 (PDT) Received: from gurney.reilly.home (d10.syd2.zeta.org.au [203.26.11.10]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id WAA14883; Fri, 3 Oct 1997 22:00:42 +1000 Received: (from andrew@localhost) by gurney.reilly.home (8.8.7/8.8.5) id VAA02092; Fri, 3 Oct 1997 21:57:58 +1000 (EST) From: Andrew Reilly Message-Id: <199710031157.VAA02092@gurney.reilly.home> Date: Fri, 3 Oct 1997 21:57:58 +1000 (EST) Subject: Re: New SCSI Framework Patches Available To: gibbs@plutotech.com cc: freebsd-scsi@FreeBSD.org In-Reply-To: <199710030340.VAA13129@pluto.plutotech.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On 2 Oct, Justin T. Gibbs wrote: > Supported peripherals: > > Direct Access driver (da): > 512 byte sectored disk drivers. Support for other sector sizes is > planned, but further investigation on the "right" approach for this > is needed. It probably belongs in the disk-slice code. Pardon for the unhelpful intrusion, but could someone please explain the issue here? I have hopes that one day my Fujitsu MO drive will be able to use 2k-sector media. Is the problem that much of the code calculates size information in sectors, (perhaps for 32-bit length restriction reasons?) and these sizes will not be appropriate for the information stored in them if the sectors themselves are not all the same size? Would it hurt (in a system that wished to use 2k-sector media on at least one drive) to use 2k sectors for all da drives, even if that meant multiple-sector writes were done as one? -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-scsi Fri Oct 3 11:36:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04170 for freebsd-scsi-outgoing; Fri, 3 Oct 1997 11:36:26 -0700 (PDT) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04165 for ; Fri, 3 Oct 1997 11:36:23 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA04392; Fri, 3 Oct 1997 12:35:38 -0600 (MDT) Message-Id: <199710031835.MAA04392@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrew Reilly cc: gibbs@plutotech.com, freebsd-scsi@FreeBSD.org Subject: Re: New SCSI Framework Patches Available In-reply-to: Your message of "Fri, 03 Oct 1997 21:57:58 +1000." <199710031157.VAA02092@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 1997 12:35:09 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >On 2 Oct, Justin T. Gibbs wrote: >> Supported peripherals: >> >> Direct Access driver (da): >> 512 byte sectored disk drivers. Support for other sector sizes is >> planned, but further investigation on the "right" approach for this >> is needed. It probably belongs in the disk-slice code. > >Pardon for the unhelpful intrusion, but could someone please explain >the issue here? The issue is that most of the system deals with devices in "DEV_BSIZE" chunks (512bytes). In the past, each device driver has had to perform some amount of conversion if the device block size doesn't match that value. Performing the conversion to block sizes that are a power of 2 isn't hard, but in some cases, the block size is an "odd" value (Try writing audio tracks to a WORM for instance). I'd like to deal with this issue cleanly and not require each and every device driver to handle this case on it's own. So, the question is how to best handle the problem? NetBSD has a few PRs in their gnats database that offer possible solutions. I just haven't had time to really consider the problem in detail and come up with a clean approach. >-- >Andrew > >"The steady state of disks is full." > -- Ken Thompson -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Oct 3 12:20:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA06925 for freebsd-scsi-outgoing; Fri, 3 Oct 1997 12:20:11 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA06891 for ; Fri, 3 Oct 1997 12:20:06 -0700 (PDT) Received: (qmail 960 invoked by uid 1000); 3 Oct 1997 19:20:11 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092597 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199710031157.VAA02092@gurney.reilly.home> Date: Fri, 03 Oct 1997 12:20:11 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Andrew Reilly Subject: Re: New SCSI Framework Patches Available Cc: freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Andrew Reilly; On 03-Oct-97 you wrote: > On 2 Oct, Justin T. Gibbs wrote: > > Supported peripherals: > > > > Direct Access driver (da): > > 512 byte sectored disk drivers. Support for other sector sizes is > > planned, but further investigation on the "right" approach for this > > is needed. It probably belongs in the disk-slice code. > > Pardon for the unhelpful intrusion, but could someone please explain > the issue here? > > I have hopes that one day my Fujitsu MO drive will be able to use > 2k-sector media. Is the problem that much of the code calculates size > information in sectors, (perhaps for 32-bit length restriction reasons?) > and these sizes will not be appropriate for the information stored in > them if the sectors themselves are not all the same size? Would it hurt > (in a system that wished to use 2k-sector media on at least one drive) > to use 2k sectors for all da drives, even if that meant multiple-sector > writes were done as one? Maybe this has something to do with trying to help me solve the 528 byte sectors... Explanation: The DPT is papable of handling 528 byte physical sectors. They appear as 512 bytes logical size (``normal''). The extra 16 bytes are used for ECC data path between the controller's memory and the disk. Or, are we talking here about supporting the strange (to me) sector sizes available on some CD-ROM drives? Strange as in non power of two sizes. --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-scsi Fri Oct 3 14:37:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA14299 for freebsd-scsi-outgoing; Fri, 3 Oct 1997 14:37:56 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA14294 for ; Fri, 3 Oct 1997 14:37:54 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA12095; Fri, 3 Oct 1997 14:24:21 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd012088; Fri Oct 3 21:24:13 1997 Message-ID: <3435623F.500F9F30@whistle.com> Date: Fri, 03 Oct 1997 14:23:11 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: Andrew Reilly , freebsd-scsi@FreeBSD.ORG Subject: Re: New SCSI Framework Patches Available References: <199710031835.MAA04392@pluto.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs wrote: > > >On 2 Oct, Justin T. Gibbs wrote: > >> Supported peripherals: > >> > >> Direct Access driver (da): > >> 512 byte sectored disk drivers. Support for other sector sizes is > >> planned, but further investigation on the "right" approach for this > >> is needed. It probably belongs in the disk-slice code. > > > >Pardon for the unhelpful intrusion, but could someone please explain > >the issue here? > > The issue is that most of the system deals with devices in "DEV_BSIZE" > chunks (512bytes). In the past, each device driver has had to perform some > amount of conversion if the device block size doesn't match that value. > Performing the conversion to block sizes that are a power of 2 isn't hard, > but in some cases, the block size is an "odd" value (Try writing audio > tracks to a WORM for instance). I'd like to deal with this issue cleanly > and not require each and every device driver to handle this case on it's > own. Justin, I have new disk handling code that does this all cleanly. I'll send you a copy as soon as I get the last killer bugs out of it. in th emean-while don't spend too much time on this roblem as I'm working on it.. It will fit into your stuff just fine I think. > > So, the question is how to best handle the problem? NetBSD has a few PRs > in their gnats database that offer possible solutions. I just haven't had > time to really consider the problem in detail and come up with a clean > approach. > > >-- > >Andrew > > > >"The steady state of disks is full." > > -- Ken Thompson > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== From owner-freebsd-scsi Sat Oct 4 18:21:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17695 for freebsd-scsi-outgoing; Sat, 4 Oct 1997 18:21:03 -0700 (PDT) Received: from linda.pathlink.com (linda.pathlink.com [204.30.237.136]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17688 for ; Sat, 4 Oct 1997 18:20:59 -0700 (PDT) Received: from data (data.pathlink.com [204.30.237.162]) by linda.pathlink.com (8.8.7/8.8.5) with SMTP id SAA04196; Sat, 4 Oct 1997 18:20:46 -0700 (PDT) Message-Id: <3.0.1.32.19971004182056.006ba024@dopey.pathlink.com> X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 04 Oct 1997 18:20:56 -0700 To: gibbs@plutotech.com (Justin T. Gibbs) From: Kachun Lee Subject: AHC error messages with 2.2.5-BETA Cc: freebsd-scsi@freebsd.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 has a P6 200mhz system running 2.2-releng to the latest 2.2.5-BETA that had 2 2740 controllers. I replaced 1 of 2740 with a 3740 when I added an extra drive to it and splitted 12 drives into 3 channels. The system has been generating the following errors about twice a day with different drives/ahc channel... Oct 4 16:16:39 clark /kernel: ahc1: WARNING no command for scb 99 (cmdcmplt) Oct 4 16:16:39 clark /kernel: QOUTCNT == 1 Oct 4 16:16:49 clark /kernel: sd9(ahc1:11:0): SCB 0x5 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0xe6 Oct 4 16:16:49 clark /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x27 SSTAT1 = 0xb Oct 4 16:16:49 clark /kernel: Ordered Tag queued Oct 4 16:16:49 clark /kernel: Ordered Tag sent Oct 4 16:16:55 clark /kernel: sd9(ahc1:11:0): SCB 0x5 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 Oct 4 16:16:55 clark /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Oct 4 16:16:55 clark /kernel: sd9(ahc1:11:0): Queueing an Abort SCB Oct 4 16:16:55 clark /kernel: sd9(ahc1:11:0): Abort Message Sent Oct 4 16:16:55 clark /kernel: sd9(ahc1:11:0): SCB 5 - Abort Tag Completed. Oct 4 16:16:55 clark /kernel: sd9(ahc1:11:0): no longer in timeout Beside pause the system for a minute or so, the system kept running. Should I ignore the errors or something I could do? Best regards PS: I has the following options enabled: options AHC_TAGENABLE options AHC_SCBPAGING_ENABLE options AHC_ALLOW_MEMIO