From owner-freebsd-scsi Sun Jul 4 2:27:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id 36AC514ED1; Sun, 4 Jul 1999 02:27:13 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id LAA06006; Sun, 4 Jul 1999 11:15:56 +0200 (CEST) (envelope-from se) Date: Sun, 4 Jul 1999 11:15:56 +0200 From: Stefan Esser To: Andre Oppermann Cc: freebsd-scsi@freebsd.org, Stefan Esser Subject: Re: ncr0: queue is empty Message-ID: <19990704111556.B4870@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: <377B1E99.46188B0C@pipeline.ch> <19990702003518.B468@dialup124.mi.uni-koeln.de> <377C77C1.4F8ACEE1@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <377C77C1.4F8ACEE1@pipeline.ch>; from Andre Oppermann on Fri, Jul 02, 1999 at 10:26:41AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-07-02 10:26 +0200, Andre Oppermann wrote: > scbus0 on ncr0 bus 0: > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 2 lun 0 (pass1,cd0) > at scbus0 target 4 lun 0 (pass2,da1) > at scbus0 target 4 lun 1 (pass3,cd1) Many Quantum drives show erratic behaviour if confronted with too many simultanous commands. For that reason, you may want to add a Quirk entry for your drive to "/sys/cam/cam_xpt.c", similar to the existing entries for all kinds of Atlas drives ... > Do you need more information? What can I do? More info sent in separate mail (regarding test of whether the problem was introduced with rev. 1.146 of ncr.c, although you are the only one to report a problem after that change went in two months ago ...) Your problem report keeps me from merging 1.146 from -current into -stable. This means, that U2W support will be missing from -stable for another week. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jul 4 3:28:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from opi.flirtbox.ch (unknown [62.48.0.50]) by hub.freebsd.org (Postfix) with SMTP id 4E31814CC1 for ; Sun, 4 Jul 1999 03:28:05 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 14580 invoked from network); 4 Jul 1999 10:28:04 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.128.182]) (envelope-sender ) by opi.flirtbox.ch (qmail-ldap-1.03) with SMTP for ; 4 Jul 1999 10:28:04 -0000 Message-ID: <377F37E7.8B0F13D1@pipeline.ch> Date: Sun, 04 Jul 1999 12:31:03 +0200 From: Andre Oppermann Organization: Internet Business Solutions Ltd. X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: se@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: Re: ncr0: queue is empty References: <377B1E99.46188B0C@pipeline.ch> <19990702003518.B468@dialup124.mi.uni-koeln.de> <377C77C1.4F8ACEE1@pipeline.ch> <19990704111556.B4870@dialup124.mi.uni-koeln.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser wrote: > > On 1999-07-02 10:26 +0200, Andre Oppermann wrote: > > scbus0 on ncr0 bus 0: > > at scbus0 target 0 lun 0 (pass0,da0) > > at scbus0 target 2 lun 0 (pass1,cd0) > > at scbus0 target 4 lun 0 (pass2,da1) > > at scbus0 target 4 lun 1 (pass3,cd1) > > Many Quantum drives show erratic behaviour if confronted with too many > simultanous commands. For that reason, you may want to add a Quirk entry > for your drive to "/sys/cam/cam_xpt.c", similar to the existing entries > for all kinds of Atlas drives ... What is an reasonable value for that drive? > > Do you need more information? What can I do? > > More info sent in separate mail (regarding test of whether the problem > was introduced with rev. 1.146 of ncr.c, although you are the only one > to report a problem after that change went in two months ago ...) Thanks! I'll do what you told me. > Your problem report keeps me from merging 1.146 from -current into > -stable. This means, that U2W support will be missing from -stable for > another week. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jul 4 13:49: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id F022214F43; Sun, 4 Jul 1999 13:48:49 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id WAA06305; Sun, 4 Jul 1999 22:49:07 +0200 (CEST) (envelope-from se) Date: Sun, 4 Jul 1999 22:49:07 +0200 From: Stefan Esser To: Andre Oppermann Cc: freebsd-scsi@freebsd.org, Stefan Esser Subject: Re: ncr0: queue is empty Message-ID: <19990704224907.A2698@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: <377B1E99.46188B0C@pipeline.ch> <19990702003518.B468@dialup124.mi.uni-koeln.de> <377C77C1.4F8ACEE1@pipeline.ch> <19990704111556.B4870@dialup124.mi.uni-koeln.de> <377F37E7.8B0F13D1@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <377F37E7.8B0F13D1@pipeline.ch>; from Andre Oppermann on Sun, Jul 04, 1999 at 12:31:03PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-07-04 12:31 +0200, Andre Oppermann wrote: > Stefan Esser wrote: > > > > On 1999-07-02 10:26 +0200, Andre Oppermann wrote: > > > scbus0 on ncr0 bus 0: > > > at scbus0 target 0 lun 0 (pass0,da0) > > > at scbus0 target 2 lun 0 (pass1,cd0) > > > at scbus0 target 4 lun 0 (pass2,da1) > > > at scbus0 target 4 lun 1 (pass3,cd1) > > > > Many Quantum drives show erratic behaviour if confronted with too many > > simultanous commands. For that reason, you may want to add a Quirk entry > > for your drive to "/sys/cam/cam_xpt.c", similar to the existing entries > > for all kinds of Atlas drives ... > > What is an reasonable value for that drive? I guess you want to try the values that work with other Quantum drives: { /* Reports QUEUE FULL for temporary resource shortages */ { T_DIRECT, SIP_MEDIA_FIXED, quantum, "XP34550*", "*" }, /*quirks*/0, /*mintags*/24, /*maxtags*/32 }, The "reducing number of tags" message has been disabled on popular demand a few months ago, IIRC. But you can re-enable it, though I don't remember how ... (kernel config option ? verbose boot ? You'll find out easily by greping for the origin of that message in the CAM sources ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jul 4 18:21:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 091D815013; Sun, 4 Jul 1999 18:21:28 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id TAA73301; Sun, 4 Jul 1999 19:21:26 -0600 (MDT) (envelope-from ken) Message-Id: <199907050121.TAA73301@panzer.kdm.org> Subject: Re: ncr0: queue is empty In-Reply-To: <19990704224907.A2698@dialup124.mi.uni-koeln.de> from Stefan Esser at "Jul 4, 1999 10:49:07 pm" To: se@FreeBSD.ORG Date: Sun, 4 Jul 1999 19:21:26 -0600 (MDT) Cc: oppermann@pipeline.ch (Andre Oppermann), freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser wrote... > On 1999-07-04 12:31 +0200, Andre Oppermann wrote: > > Stefan Esser wrote: > > > > > > On 1999-07-02 10:26 +0200, Andre Oppermann wrote: > > > > scbus0 on ncr0 bus 0: > > > > at scbus0 target 0 lun 0 (pass0,da0) > > > > at scbus0 target 2 lun 0 (pass1,cd0) > > > > at scbus0 target 4 lun 0 (pass2,da1) > > > > at scbus0 target 4 lun 1 (pass3,cd1) > > > > > > Many Quantum drives show erratic behaviour if confronted with too many > > > simultanous commands. For that reason, you may want to add a Quirk entry > > > for your drive to "/sys/cam/cam_xpt.c", similar to the existing entries > > > for all kinds of Atlas drives ... > > > > What is an reasonable value for that drive? > > I guess you want to try the values that work with other Quantum drives: > > { > /* Reports QUEUE FULL for temporary resource shortages */ > { T_DIRECT, SIP_MEDIA_FIXED, quantum, "XP34550*", "*" }, > /*quirks*/0, /*mintags*/24, /*maxtags*/32 > }, > > The "reducing number of tags" message has been disabled on popular demand > a few months ago, IIRC. But you can re-enable it, though I don't remember > how ... (kernel config option ? verbose boot ? You'll find out easily by > greping for the origin of that message in the CAM sources ;-) Just boot verbose, that'll re-enable the message. Don't be alarmed at the other "error" messages that pop up as well. Verbose is, as its name implies, verbose. :) You can also find out how many tags your device is using like this: $ camcontrol tags da1 -v (pass1:ahc1:0:1:0): dev_openings 64 (pass1:ahc1:0:1:0): dev_active 0 (pass1:ahc1:0:1:0): devq_openings 64 (pass1:ahc1:0:1:0): devq_queued 0 (pass1:ahc1:0:1:0): held 0 (pass1:ahc1:0:1:0): mintags 2 (pass1:ahc1:0:1:0): maxtags 255 dev_openings + dev_active == total number of available tags The Atlas I had some firmware problems similar to the Atlas II, namely that it would lock up under high load. I think the L915 firmware fixed that problem. I'm not sure whether the Atlas I had the queue full problems that the Atlas II and III have, though. Justin might remember. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jul 5 18:12:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 6B07315373 for ; Mon, 5 Jul 1999 18:12:04 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id TAA00431; Mon, 5 Jul 1999 19:12:05 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199907060112.TAA00431@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@freebsd.org Subject: Re: just so you all know how really whacky it can get... In-reply-to: Your message of "Fri, 02 Jul 1999 18:39:18 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jul 1999 19:12:05 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >I've added Fabric support and also added/tested for SCCLUN.... > >While doing a rescan on a SCCLUN enabled (16 bit luns) through a switch... >this sort of leads me to believe that we need some more flags so that an >HBA can inform CAM that an exhaustive search isn't needed- or at least I >need to try and implement the REPORT LUNS command... at some point it >rebooted (I didn't yet catch why).... really pretty amusing: Take a look at the CAM3 spec's 'bind' interface and how it defines the path inquiry data. I'd like to move in this direction (CAM paths become bind handles or some-such), but it looks like, based on the recent working group meeting, that the bind stuff will be simplified a bit. There was a proposal for forcing SIMs to present a 'static' address to the XPT across LIP events even if the device's loop id changed. Unfortunately I don't know enough about fiber channel to critique the spec or the proposal. The other problem that you are running into is that we currently don't have a kernel thread dedicated to performing rescan operations and we attempt to scan all possible targets in parallel. I thought that I had the necessary tests in there to error out cleanly, but I guess that isn't the case. As soon as I catch a breath here, I'd like to move forward on CAM2->CAM3 transition issues as well as give the XPT it's own thread so that we can keep the parallel probe framework, and gracefully run even with limited memory resources. REPORT LUNS and how to deal with SCSI3 devices in general certainly needs to be addressed before 4.0 as well. If you have ideas in this area, please pass them on. I should be back working on CAM heavily in about two weeks time. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jul 5 21:15:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 58F8214E9E for ; Mon, 5 Jul 1999 21:15:46 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id VAA11184; Mon, 5 Jul 1999 21:15:43 -0700 Date: Mon, 5 Jul 1999 21:15:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@freebsd.org Subject: Re: just so you all know how really whacky it can get... In-Reply-To: <199907060112.TAA00431@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > >I've added Fabric support and also added/tested for SCCLUN.... > > > >While doing a rescan on a SCCLUN enabled (16 bit luns) through a switch... > >this sort of leads me to believe that we need some more flags so that an > >HBA can inform CAM that an exhaustive search isn't needed- or at least I > >need to try and implement the REPORT LUNS command... at some point it > >rebooted (I didn't yet catch why).... really pretty amusing: > > Take a look at the CAM3 spec's 'bind' interface and how it defines > the path inquiry data. I'd like to move in this direction (CAM paths > become bind handles or some-such), but it looks like, based on the recent In my spare time.... sigh.. glub... > working group meeting, that the bind stuff will be simplified a bit. There > was a proposal for forcing SIMs to present a 'static' address to the XPT > across LIP events even if the device's loop id changed. That's what is happening now (finally)- I believe this is the right thing to have happen. It makes system management somewhat easier. > The other problem that you are running into is that we currently don't have > a kernel thread dedicated to performing rescan operations and we attempt > to scan all possible targets in parallel. I thought that I had the > necessary tests in there to error out cleanly, but I guess that isn't > the case. No, that can't be the right thing to do, can it? There is absolutely no guarantee about the order of completion, so that which had been da0 is now da1... I'd actually like to have change the the flags so that you *don't* scan- let the HBA announce devices asynchronously, no? > As soon as I catch a breath here, I'd like to move forward on CAM2->CAM3 > transition issues as well as give the XPT it's own thread so that we > can keep the parallel probe framework, and gracefully run even with limited > memory resources. REPORT LUNS and how to deal with SCSI3 devices in > general certainly needs to be addressed before 4.0 as well. If you have > ideas in this area, please pass them on. I should be back working on > CAM heavily in about two weeks time. Let's talk... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 0: 7:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 79BF614C0C for ; Tue, 6 Jul 1999 00:07:47 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id AAA45221; Tue, 6 Jul 1999 00:07:38 -0700 (PDT) Date: Tue, 6 Jul 1999 00:07:36 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" Cc: mjacob@feral.com, "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: just so you all know how really whacky it can get... In-Reply-To: <199907060112.TAA00431@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 5 Jul 1999, Justin T. Gibbs wrote: > > > >I've added Fabric support and also added/tested for SCCLUN.... > > > >While doing a rescan on a SCCLUN enabled (16 bit luns) through a switch... > >this sort of leads me to believe that we need some more flags so that an > >HBA can inform CAM that an exhaustive search isn't needed- or at least I > >need to try and implement the REPORT LUNS command... at some point it > >rebooted (I didn't yet catch why).... really pretty amusing: > > Take a look at the CAM3 spec's 'bind' interface and how it defines > the path inquiry data. I'd like to move in this direction (CAM paths > become bind handles or some-such), but it looks like, based on the recent > working group meeting, that the bind stuff will be simplified a bit. There > was a proposal for forcing SIMs to present a 'static' address to the XPT > across LIP events even if the device's loop id changed. Unfortunately I > don't know enough about fiber channel to critique the spec or the proposal. > > The other problem that you are running into is that we currently don't have > a kernel thread dedicated to performing rescan operations and we attempt > to scan all possible targets in parallel. I thought that I had the > necessary tests in there to error out cleanly, but I guess that isn't > the case. The last version of the SLICE code I had working here used a general purpose rescan daemon, I called it 'deviced' but that was basically what it did. It accepted probe requests which it would queue and then perform at a later time. I was about half way through getting it working properly on X-day. > > As soon as I catch a breath here, I'd like to move forward on CAM2->CAM3 > transition issues as well as give the XPT it's own thread so that we > can keep the parallel probe framework, and gracefully run even with limited > memory resources. REPORT LUNS and how to deal with SCSI3 devices in > general certainly needs to be addressed before 4.0 as well. If you have > ideas in this area, please pass them on. I should be back working on > CAM heavily in about two weeks time. > > -- > Justin > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 0: 9:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9AAF814C0C for ; Tue, 6 Jul 1999 00:09:34 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id AAA11614; Tue, 6 Jul 1999 00:09:27 -0700 Date: Tue, 6 Jul 1999 00:09:22 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Julian Elischer Cc: scsi@FreeBSD.ORG Subject: Re: just so you all know how really whacky it can get... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The last version of the SLICE code I had working here used a general > purpose rescan daemon, I called it 'deviced' but that was basically what > it did. It accepted probe requests which it would queue and then perform > at a later time. I was about half way through getting it working properly > on X-day. Were you planning on bringing it back? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 8: 6:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 49C7C14C83 for ; Tue, 6 Jul 1999 08:06:38 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id JAA01383; Tue, 6 Jul 1999 09:06:37 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199907061506.JAA01383@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , scsi@freebsd.org Subject: Re: just so you all know how really whacky it can get... In-reply-to: Your message of "Mon, 05 Jul 1999 21:15:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 09:06:37 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> The other problem that you are running into is that we currently don't have >> a kernel thread dedicated to performing rescan operations and we attempt >> to scan all possible targets in parallel. I thought that I had the >> necessary tests in there to error out cleanly, but I guess that isn't >> the case. > >No, that can't be the right thing to do, can it? There is absolutely no >guarantee about the order of completion, so that which had been da0 is now >da1... There is a difference between probe order and announce order. The XPT will rescan all devices in parallel and then announce them, in order, to the peripheral drivers so that unit ordering is preserved. >I'd actually like to have change the the flags so that you *don't* scan- >let the HBA announce devices asynchronously, no? Perhaps. You'd have to add the 'async' stuff as a separate capability from the 'I know what's out there' capability. I'm not sure that all media can do the async stuff (e.g. SCAM). The XPT may have to initiate a SIM level topology probe, wait for it to complete, and then iterate through the results. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 8:10:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 222DC14C83 for ; Tue, 6 Jul 1999 08:10:51 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id IAA54815; Tue, 6 Jul 1999 08:10:50 -0700 (PDT) Date: Tue, 6 Jul 1999 08:10:49 -0700 (PDT) From: Julian Elischer To: Matthew Jacob Cc: scsi@FreeBSD.ORG Subject: Re: just so you all know how really whacky it can get... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Jul 1999, Matthew Jacob wrote: > > > > The last version of the SLICE code I had working here used a general > > purpose rescan daemon, I called it 'deviced' but that was basically what > > it did. It accepted probe requests which it would queue and then perform > > at a later time. I was about half way through getting it working properly > > on X-day. > > Were you planning on bringing it back? > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > I basically lost all interest for a while and then the newest stuff on my system got clobbered, so I'd have to restart from a point about a week before that (the newest I have). I'm geting closer to being able to do that now as various things have changed on the work scene so I might have more time (yey). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 10:23:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id BFB0614C46; Tue, 6 Jul 1999 10:23:47 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id LAA68449; Tue, 6 Jul 1999 11:13:14 -0600 (MDT) Date: Tue, 6 Jul 1999 11:13:14 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907061713.LAA68449@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset X-Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This stuff should really go to the SCSI list. I read that list much more frequently than this one. > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB > part of the drive). It takes 1s or more to reset. The reset is initiated > because for example an illegal command was received (sync cache for > example). The hard coded reset delay in there is quite crude. You should just call xpt_freeze_devq() for that device and then release the queue from a timeout handler. In general, the peripheral drivers will wait until after a bus settle delay anyway, but the only way to ensure this delay is to freeze the queue. > The problem is that the reset is initiated and the command that failed > xpt_done()-d with an error. All ccbs that have an error status set should cause the device queue to be frozen and the CAM_DEV_QFRZN flag should be set in the cam status field of the CCB. If you don't freeze the queue, the peripheral driver cannot perform error recovery in a consistant way. It also looks like all umass I/O is blocking/polling. Since this can occur from a SWI, this is pretty bad to do. Is there no alternative? It also appears that this driver has a very limited error code vocabulary. Is that because the transport or device gives little information about errors? > What would be the proper approach to make the ccb delay until the reset > has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or > store the ccb and process it when the reset is done? CAM_REQUEUE_REQ is for commands that have been queued in the SIM but have never been sent to a device. The error modle goes something like this: All ccbs with non-zero status should cause the device queue to be frozen and the CAM_DEV_QFRZN flag set in the status word. When an error occurrs: Return all queued CCBs that match the device(s) affected by the error with CAM_REQUEUE_REQ status. Return any 'invalidated' commands (commands that were on the device but have been thrown out in response to this error) with the correct error status (CAM_BUS_RESET, CAM_BDR_SENT, etc.) Return any commands that have completed with an error with the apropriate error code (CAM_UNCOR_PARIY, CAM_SCSI_STATUS_ERROR, CAM_DATA_RUN_ERR, etc.) If you require a specific amount of recovery time, freeze the device or simq and schedule a timeout to release the queue. An underrun is not an error. If a ccb is returned with no error codes set, the residual will be examined, so you must set the residual on all completed commands. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 10:25:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 5406A14ECC for ; Tue, 6 Jul 1999 10:25:24 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id LAA68455; Tue, 6 Jul 1999 11:14:50 -0600 (MDT) Date: Tue, 6 Jul 1999 11:14:50 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907061714.LAA68455@narnia.plutotech.com> To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset X-Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > should do bus settling for SCSI_DELAY. If you're not actually doing a bus > reset, you need to hold off the command with a requeue but only if you > tell it when it can go (I believe- I sure wish Justin would document this > stuff). I wish Justin had the time to document all of this too. Most of this is documented in the CAM2 spec. The only addition here is the CAM_REQUEUE_REQ status. Regardless, I would encourage any CAM hackers to read the CAM2 and CAM3 specs. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 10:35:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 3216414D33 for ; Tue, 6 Jul 1999 10:35:05 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id LAA68469; Tue, 6 Jul 1999 11:24:32 -0600 (MDT) Date: Tue, 6 Jul 1999 11:24:32 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907061724.LAA68469@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: CAM panic in camq_fini X-Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Redirected to the SCSI list > When, after attaching to the CAM later with > > cam_simq_alloc(1) > cam_sim_alloc(action, poll, "umass", sc, unit, 1, 0, devq) > xpt_bus_register(sc->sim, 0) > xpt_create_path(&sc->path, NULL, cam_sim_path(sc->sim), > CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) > > doing an immediate detach from it again, like so: > > xpt_async(AC_LOST_DEVICE, sc->path, NULL) > xpt_free_path(sc->path) > xpt_bus_deregister(cam_sim_path(sc->sim)) > cam_sim_free(sc->sim, /*free_devq*/TRUE) Here's a fix for one of the detach bugs. There really is no guarantee that the detach of SIMs will work right now and since the new-bus stuff for detach hasn't settled, I don't know how much effort towards this is worth while right now... -- Justin ==== //depot/FreeBSD-current/src/sys/cam/cam_queue.c#5 - /usr/src/sys/cam/cam_queue.c ==== *** /tmp/tmp.415.0 Tue Jul 6 11:32:44 1999 --- /usr/src/sys/cam/cam_queue.c Tue Jul 6 11:32:30 1999 *************** *** 242,249 **** void cam_devq_free(struct cam_devq *devq) { ! camq_free(&devq->alloc_queue); ! camq_free(&devq->send_queue); free(devq, M_DEVBUF); } --- 242,249 ---- void cam_devq_free(struct cam_devq *devq) { ! camq_fini(&devq->alloc_queue); ! camq_fini(&devq->send_queue); free(devq, M_DEVBUF); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 10:52:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id BA8B614D33 for ; Tue, 6 Jul 1999 10:52:56 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-149.skylink.it [194.185.55.149]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id TAA32686; Tue, 6 Jul 1999 19:52:32 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id TAA00343; Tue, 6 Jul 1999 19:48:32 +0200 (CEST) Date: Tue, 6 Jul 1999 19:48:32 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset In-Reply-To: <199907061713.LAA68449@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This stuff should really go to the SCSI list. I read that list much more > frequently than this one. Good idea. > The hard coded reset delay in there is quite crude. You should just > call xpt_freeze_devq() for that device and then release the queue ... > It also looks like all umass I/O is blocking/polling. Since this can occur > from a SWI, this is pretty bad to do. Is there no alternative? You are looking at the wrong version of the driver (the version in CURRENT is rapidly becoming obsolete). Please have a look at: http://www.etla.net/~n_hibma/usb/umass.c.new This version uses a state machine triggered by callbacks from finished USB transfers. > from a timeout handler. In general, the peripheral drivers will wait > until after a bus settle delay anyway, but the only way to ensure this > delay is to freeze the queue. Reset does not only occur after a bus reset but more often, after phase errors and other transient errors that might occur on the drive. So I need to have a proper mechanism after a reset after an error. > All ccbs that have an error status set should cause the device > queue to be frozen and the CAM_DEV_QFRZN flag should be set in > the cam status field of the CCB. If you don't freeze the queue, > the peripheral driver cannot perform error recovery in a consistant > way. umass uses one tagged opening. > It also appears that this driver has a very limited error code > vocabulary. Is that because the transport or device gives little > information about errors? Yes. I'm not even sure whether Sense can be reliably retrieved. See www.usb.org -> Developers home page -> class documents -> Bulk-Only mass storage. They return: - Command in Command Block Wrapper (SCSI/ATA/etc.) succeeded - Command failed - Phase Error - D'uh! And nothing else. Braindead, but that's the spec for you. Nick -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 10:58:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 6C15614DDD for ; Tue, 6 Jul 1999 10:58:12 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id KAA00856; Tue, 6 Jul 1999 10:53:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907061753.KAA00856@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nick Hibma Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset In-reply-to: Your message of "Tue, 06 Jul 1999 19:48:32 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 10:53:53 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > It also appears that this driver has a very limited error code > > vocabulary. Is that because the transport or device gives little > > information about errors? > > Yes. I'm not even sure whether Sense can be reliably retrieved. See > www.usb.org -> Developers home page -> class documents -> Bulk-Only mass > storage. They return: > > - Command in Command Block Wrapper (SCSI/ATA/etc.) succeeded > - Command failed > - Phase Error > - D'uh! > > And nothing else. Braindead, but that's the spec for you. You ought to be able to send a Request Sense command if you get a "command failed" status. Actually, I think that someone above you will try to do that anyway. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 11:26:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id B399314D3B for ; Tue, 6 Jul 1999 11:26:33 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-149.skylink.it [194.185.55.149]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id UAA00843; Tue, 6 Jul 1999 20:26:05 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id UAA00427; Tue, 6 Jul 1999 20:26:11 +0200 (CEST) Date: Tue, 6 Jul 1999 20:26:11 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Mike Smith Cc: "Justin T. Gibbs" , scsi@freebsd.org Subject: Re: CAM: delaying new commands during reset In-Reply-To: <199907061753.KAA00856@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > And nothing else. Braindead, but that's the spec for you. > > You ought to be able to send a Request Sense command if you get a > "command failed" status. Actually, I think that someone above you will > try to do that anyway. The dev/ppbus/vpo.c driver does the fetching itself. I also have not seent he command appear when playing with the drive. Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 11:28:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 01BDF15003 for ; Tue, 6 Jul 1999 11:28:27 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA13493 for ; Tue, 6 Jul 1999 11:28:27 -0700 Date: Tue, 6 Jul 1999 11:28:17 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: scsi@freebsd.org Subject: Hello, World! (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Update your links ---------- Forwarded message ---------- Date: Tue, 06 Jul 1999 12:13:32 -0600 From: John Lohmeyer To: T10 Reflector Cc: Michael LoBue , "Mason, Harry" , STAReflector Subject: Hello, World! * From the T10 Reflector (t10@symbios.com), posted by: * John Lohmeyer * The T10 web and ftp sites have moved. The new sites are: T10 web site: http://www.t10.org/ T10 ftp site: ftp://ftp.t10.org/ Please update your bookmarks. The old sites (at symbios.com) will continue to operate for a while, but will eventually be taken out of service. I've checked the new site with LinkBot 4.1 and was given a 100 percentile quality rating. However, if you experience any problems, please let me know. We will continue to use the t10@symbios.com reflector address for another couple weeks because our majordomo expert is on vacation. We'll cut over to the new reflector when she gets back and is ready to deal with any glitches. >>> I want to thank the SCSI Trade Association for providing the new T10 server. <<< John -- John Lohmeyer Email: lohmeyer@ix.netcom.com LSI Logic Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Fax: +1-719-533-7036 Colo Spgs, CO 80907 BBS: +1-719-533-7950 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@symbios.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 15: 5: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from surf.iae.nl (surf.IAE.nl [194.151.66.2]) by hub.freebsd.org (Postfix) with ESMTP id 6514F14FBF for ; Tue, 6 Jul 1999 15:05:01 -0700 (PDT) (envelope-from wjw@iae.nl) Received: by surf.iae.nl (Postfix, from userid 74) id 48CAF9FAE; Wed, 7 Jul 1999 00:05:00 +0200 (MET DST) Subject: Trouble on my DPT controller To: scsi@freebsd.org Date: Wed, 7 Jul 1999 00:05:00 +0200 (MET DST) Reply-To: wjw@IAE.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 Message-Id: <19990706220500.48CAF9FAE@surf.iae.nl> From: wjw@iae.nl (Willem Jan Withagen) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've got a DPT controller 3334 which "suddenly" claims: Jul 6 02:41:30 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc764c - timed out Jul 6 02:41:31 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc76c8 - timed out It has repeated itself during make worlds.... I'm running a relatively recently -stable (2 weeks old) Is this a hardware problem or a software problem? Thanx, --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 15:27: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4D41214D46 for ; Tue, 6 Jul 1999 15:26:59 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA86737; Tue, 6 Jul 1999 16:26:55 -0600 (MDT) (envelope-from ken) Message-Id: <199907062226.QAA86737@panzer.kdm.org> Subject: Re: Trouble on my DPT controller In-Reply-To: <19990706220500.48CAF9FAE@surf.iae.nl> from Willem Jan Withagen at "Jul 7, 1999 00:05:00 am" To: wjw@IAE.nl Date: Tue, 6 Jul 1999 16:26:55 -0600 (MDT) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Willem Jan Withagen wrote... > Hi, > > I've got a DPT controller 3334 which "suddenly" claims: > > Jul 6 02:41:30 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc764c - timed out > Jul 6 02:41:31 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc76c8 - timed out > It has repeated itself during make worlds.... > > I'm running a relatively recently -stable (2 weeks old) > > Is this a hardware problem or a software problem? I suspect it's a hardware problem. The above message is from the DPT driver's timeout handler, and it is complaining about a particular disk or array you've got setup. The timeout for read and write operations from the DA driver is 60 seconds. So that means that da0 didn't complete a read or write in 60 seconds. What sort of disk is da0? There are some disks that are known to lock up under heavy I/O. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 15:32:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from surf.iae.nl (surf.IAE.nl [194.151.66.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B39215406 for ; Tue, 6 Jul 1999 15:32:13 -0700 (PDT) (envelope-from wjw@iae.nl) Received: by surf.iae.nl (Postfix, from userid 74) id B61AA9FAE; Wed, 7 Jul 1999 00:32:12 +0200 (MET DST) Subject: Re: Trouble on my DPT controller In-Reply-To: <199907062226.QAA86737@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 6, 99 04:26:55 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 7 Jul 1999 00:32:12 +0200 (MET DST) Cc: scsi@freeBSD.org Reply-To: wjw@IAE.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1637 Message-Id: <19990706223212.B61AA9FAE@surf.iae.nl> From: wjw@iae.nl (Willem Jan Withagen) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You ( Kenneth D. Merry ) write: => > Jul 6 02:41:30 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc764c - timed out => > Jul 6 02:41:31 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc76c8 - timed out => > It has repeated itself during make worlds.... => > => > I'm running a relatively recently -stable (2 weeks old) => > => > Is this a hardware problem or a software problem? => => I suspect it's a hardware problem. The above message is from the DPT => driver's timeout handler, and it is complaining about a particular disk or => array you've got setup. => => The timeout for read and write operations from the DA driver is 60 seconds. => So that means that da0 didn't complete a read or write in 60 seconds. => => What sort of disk is da0? There are some disks that are known to lock up => under heavy I/O. It's been a long time since I looked at them, but probably they'll be "wrong" (any Quantum sort of is, and that's why I have them at home, not at work. :-) da1: Fixed Direct Access SCSI-2 device da1: Tagged Queueing Enabled da1: 2013MB (4124224 512 byte sectors: 255H 63S/T 256C) Is there any way to test the individual disks-defects "through" the DPT controller? [~wjw] root@hobby> scsi-defects /dev/rda1 Plist SCIOCCOMMAND ioctl: Inappropriate ioctl for device There are no defects (in this list). (da1 is a single disk on the same DPT controller.) --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 15:38:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id E968914C32 for ; Tue, 6 Jul 1999 15:38:09 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA86869; Tue, 6 Jul 1999 16:38:06 -0600 (MDT) (envelope-from ken) Message-Id: <199907062238.QAA86869@panzer.kdm.org> Subject: Re: Trouble on my DPT controller In-Reply-To: <19990706223212.B61AA9FAE@surf.iae.nl> from Willem Jan Withagen at "Jul 7, 1999 00:32:12 am" To: wjw@iae.nl Date: Tue, 6 Jul 1999 16:38:06 -0600 (MDT) Cc: scsi@freeBSD.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Willem Jan Withagen wrote... > You ( Kenneth D. Merry ) write: > => > Jul 6 02:41:30 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc764c - timed out > => > Jul 6 02:41:31 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc76c8 - timed out > => > It has repeated itself during make worlds.... > => > > => > I'm running a relatively recently -stable (2 weeks old) > => > > => > Is this a hardware problem or a software problem? > => > => I suspect it's a hardware problem. The above message is from the DPT > => driver's timeout handler, and it is complaining about a particular disk or > => array you've got setup. > => > => The timeout for read and write operations from the DA driver is 60 seconds. > => So that means that da0 didn't complete a read or write in 60 seconds. > => > => What sort of disk is da0? There are some disks that are known to lock up > => under heavy I/O. > > It's been a long time since I looked at them, but probably they'll be > "wrong" (any Quantum sort of is, and that's why I have them at home, not at > work. :-) > > da1: Fixed Direct Access SCSI-2 device > da1: Tagged Queueing Enabled > da1: 2013MB (4124224 512 byte sectors: 255H 63S/T 256C) Heh, yeah, Quantum disks are almost always suspicious. :) I don't remember any problems with that drive specifically, although I certainly wouldn't rule out a firmware bug. You should probably look on Quantum's ftp site and see if there is any updated firmware for the drive. They released updated firmware for the Atlas II (LYK8) that fixed the hanging problem, and it's possible there may be newer firmware for that disk. > Is there any way to test the individual disks-defects "through" the DPT > controller? > [~wjw] root@hobby> scsi-defects /dev/rda1 Plist > SCIOCCOMMAND ioctl: Inappropriate ioctl for device > There are no defects (in this list). Well, that's an old script, written for the old SCSI layer's userland interface. Try 'camcontrol defects', like this: camcontrol defects -n da -u 0 -f phys -PG If you look at the camcontrol(8) man page or 'camcontrol help', you'll see more information about the defects command. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 15:39:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id C1A0714EAA for ; Tue, 6 Jul 1999 15:39:22 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id XAA11666; Tue, 6 Jul 1999 23:39:08 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 6 Jul 1999 23:39:07 +0100 (BST) From: Doug Rabson To: "Justin T. Gibbs" Cc: Nick Hibma , scsi@freebsd.org Subject: Re: CAM panic in camq_fini In-Reply-To: <199907061724.LAA68469@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Jul 1999, Justin T. Gibbs wrote: > Redirected to the SCSI list > > > When, after attaching to the CAM later with > > > > cam_simq_alloc(1) > > cam_sim_alloc(action, poll, "umass", sc, unit, 1, 0, devq) > > xpt_bus_register(sc->sim, 0) > > xpt_create_path(&sc->path, NULL, cam_sim_path(sc->sim), > > CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) > > > > doing an immediate detach from it again, like so: > > > > xpt_async(AC_LOST_DEVICE, sc->path, NULL) > > xpt_free_path(sc->path) > > xpt_bus_deregister(cam_sim_path(sc->sim)) > > cam_sim_free(sc->sim, /*free_devq*/TRUE) > > Here's a fix for one of the detach bugs. There really is no > guarantee that the detach of SIMs will work right now and since > the new-bus stuff for detach hasn't settled, I don't know how > much effort towards this is worth while right now... I have some hopefully good ideas about fixing detach (and unload). When I get a chance, I will try to write up a description of how I think the thing has to work. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 16: 6:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from surf.iae.nl (surf.IAE.nl [194.151.66.2]) by hub.freebsd.org (Postfix) with ESMTP id 3760815071 for ; Tue, 6 Jul 1999 16:06:25 -0700 (PDT) (envelope-from wjw@iae.nl) Received: by surf.iae.nl (Postfix, from userid 74) id 427C59FAE; Wed, 7 Jul 1999 01:06:22 +0200 (MET DST) Subject: Re: Trouble on my DPT controller In-Reply-To: <199907062238.QAA86869@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 6, 99 04:38:06 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 7 Jul 1999 01:06:21 +0200 (MET DST) Cc: wjw@iae.nl, scsi@freeBSD.org Reply-To: wjw@IAE.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2127 Message-Id: <19990706230622.427C59FAE@surf.iae.nl> From: wjw@iae.nl (Willem Jan Withagen) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You ( Kenneth D. Merry ) write: => > It's been a long time since I looked at them, but probably they'll be => > "wrong" (any Quantum sort of is, and that's why I have them at home, not at => > work. :-) => > => > da1: Fixed Direct Access SCSI-2 device => > da1: Tagged Queueing Enabled => > da1: 2013MB (4124224 512 byte sectors: 255H 63S/T 256C) => => Heh, yeah, Quantum disks are almost always suspicious. :) I don't remember => any problems with that drive specifically, although I certainly wouldn't => rule out a firmware bug. => => You should probably look on Quantum's ftp site and see if there is any => updated firmware for the drive. They released updated firmware for the => Atlas II (LYK8) that fixed the hanging problem, and it's possible there may => be newer firmware for that disk. I'll try to tackle that part. => > Is there any way to test the individual disks-defects "through" the DPT => > controller? => > [~wjw] root@hobby> scsi-defects /dev/rda1 Plist => > SCIOCCOMMAND ioctl: Inappropriate ioctl for device => > There are no defects (in this list). => => Well, that's an old script, written for the old SCSI layer's userland => interface. Try 'camcontrol defects', like this: => => camcontrol defects -n da -u 0 -f phys -PG => => If you look at the camcontrol(8) man page or 'camcontrol help', you'll see => more information about the defects command. Good suggestion. We'll be using that at work as well. It does work om my old Micropolis on the AHC0, but on the DPT it's giving zero errors for both grown and factory defects. And the latter I find sort of hard to believe. It even reporst nothing on the single disk to the DPT I'had been toying with these command: an eject on my dpt RAID-5 gives me an invalid array :-) So you might want to disable that in the code for fixed-drives. But using this --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 16:11: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 49BBE14C99 for ; Tue, 6 Jul 1999 16:10:59 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA87097; Tue, 6 Jul 1999 17:10:56 -0600 (MDT) (envelope-from ken) Message-Id: <199907062310.RAA87097@panzer.kdm.org> Subject: Re: Trouble on my DPT controller In-Reply-To: <19990706230622.427C59FAE@surf.iae.nl> from Willem Jan Withagen at "Jul 7, 1999 01:06:21 am" To: wjw@iae.nl Date: Tue, 6 Jul 1999 17:10:56 -0600 (MDT) Cc: scsi@freeBSD.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Willem Jan Withagen wrote... > You ( Kenneth D. Merry ) write: > => > Is there any way to test the individual disks-defects "through" the DPT > => > controller? > => > [~wjw] root@hobby> scsi-defects /dev/rda1 Plist > => > SCIOCCOMMAND ioctl: Inappropriate ioctl for device > => > There are no defects (in this list). > => > => Well, that's an old script, written for the old SCSI layer's userland > => interface. Try 'camcontrol defects', like this: > => > => camcontrol defects -n da -u 0 -f phys -PG > => > => If you look at the camcontrol(8) man page or 'camcontrol help', you'll see > => more information about the defects command. > > Good suggestion. We'll be using that at work as well. > > It does work om my old Micropolis on the AHC0, but on the DPT it's giving > zero errors for both grown and factory defects. And the latter I find sort > of hard to believe. > It even reporst nothing on the single disk to the DPT I wonder if the DPT is filtering the command somehow. I also find it hard to believe that your disk has no defects. > I'had been toying with these command: > an eject on my dpt RAID-5 gives me an invalid array :-) > So you might want to disable that in the code for fixed-drives. Heh, well, part of the fun of camcontrol is that it gives users 10 miles more rope than they need to hang themselves. :) For even more fun, you can try out my camcontrol format patches: http://www.freebsd.org/~ken/camcontrol.format.061799 Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 17:29:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id D111514F55 for ; Tue, 6 Jul 1999 17:29:09 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id SAA01024; Tue, 6 Jul 1999 18:29:10 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199907070029.SAA01024@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nick Hibma Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset In-reply-to: Your message of "Tue, 06 Jul 1999 19:48:32 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 18:29:10 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Reset does not only occur after a bus reset but more often, after phase >errors and other transient errors that might occur on the drive. So I >need to have a proper mechanism after a reset after an error. Sure. >> All ccbs that have an error status set should cause the device >> queue to be frozen and the CAM_DEV_QFRZN flag should be set in >> the cam status field of the CCB. If you don't freeze the queue, >> the peripheral driver cannot perform error recovery in a consistant >> way. > >umass uses one tagged opening. This matters little. The peripheral driver still expects that when an error occurs the queue will be frozen (unless the devices sets the queue freeze disable bit, but this is handled by the XPT for you). If you don't freeze the queue, the order in which the transaction is re-queued or the queue is frozen for error recovery by the peripheral driver, etc. will change the outcome. >> It also appears that this driver has a very limited error code >> vocabulary. Is that because the transport or device gives little >> information about errors? > >Yes. I'm not even sure whether Sense can be reliably retrieved. See >www.usb.org -> Developers home page -> class documents -> Bulk-Only mass >storage. They return: > > - Command in Command Block Wrapper (SCSI/ATA/etc.) succeeded > - Command failed > - Phase Error > - D'uh! So no SCSI status? That's pretty lame. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 17:33: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 3CD31152CA for ; Tue, 6 Jul 1999 17:32:56 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id SAA01053; Tue, 6 Jul 1999 18:32:24 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199907070032.SAA01053@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nick Hibma Cc: Mike Smith , "Justin T. Gibbs" , scsi@freebsd.org Subject: Re: CAM: delaying new commands during reset In-reply-to: Your message of "Tue, 06 Jul 1999 20:26:11 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 18:32:24 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> > And nothing else. Braindead, but that's the spec for you. >> >> You ought to be able to send a Request Sense command if you get a >> "command failed" status. Actually, I think that someone above you will >> try to do that anyway. > >The dev/ppbus/vpo.c driver does the fetching itself. I also have not >seent he command appear when playing with the drive. You have to do the fetching yourself. AutoSense retrieval is somewhat expected by the CAM framework. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 18:17: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ezln23.earthbroadcasting.com (ezln23.thedial.com [207.135.131.130]) by hub.freebsd.org (Postfix) with ESMTP id 7124714CB4 for ; Tue, 6 Jul 1999 18:17:01 -0700 (PDT) (envelope-from chris@thedial.com) Received: from thedial.com (localhost.earthbroadcasting.com [127.0.0.1]) by ezln23.earthbroadcasting.com (8.9.3/8.9.3) with ESMTP id TAA83754 for ; Tue, 6 Jul 1999 19:17:04 -0600 (MDT) (envelope-from chris@thedial.com) Message-ID: <3782AA8F.6A8087DC@thedial.com> Date: Tue, 06 Jul 1999 19:17:03 -0600 From: Christopher Taylor X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: AIT/DLT Tape Compatibility Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I need a high capacity tape backup solution for FreeBSD. In the past, I have used DAT with no problems, but now I need something quite a bit bigger and more reliable. Does FreeBSD support AIT or DLT devices? Would these be considered "SCSI" as stated in the FreeBSD FAQ? BTW, I wasn't sure if this message should be posted in freebsd-scsi or freebsd-question...Hope I chose correctly The FreeBSD FAQ states: "FreeBSD supports SCSI, QIC-36 (with a QIC-02 interface) and QIC-40/80 (Floppy based) tape drives. This includes 8-mm (aka Exabyte) and DAT drives. The QIC-40/80 drives are known to be slow. Some of the early 8-mm drives are not quite compatible with SCSI-2, and may not work well with FreeBSD." --Chris -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Christopher Taylor Technical Director Earth Broadcasting Corporation (EBC) 415 East 200 South Salt Lake City, Utah 84111 phone: (801) 322-3949 cell: (801) 541-8287 email: chris@thedial.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 18:24:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 7933114F6E for ; Tue, 6 Jul 1999 18:24:04 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1003) id C2BF2F818; Tue, 6 Jul 1999 21:24:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id B3FE39B15; Tue, 6 Jul 1999 21:24:03 -0400 (EDT) Date: Tue, 6 Jul 1999 21:24:03 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: Christopher Taylor Cc: freebsd-scsi@freebsd.org Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: <3782AA8F.6A8087DC@thedial.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Jul 1999, Christopher Taylor wrote: > I need a high capacity tape backup solution for FreeBSD. In the past, I > have used DAT with no problems, but now I need something quite a bit > bigger and more reliable. Does FreeBSD support AIT or DLT devices? Would > these be considered "SCSI" as stated in the FreeBSD FAQ? > Yes, AIT and DLT drives are considered SCSI if they use a standard SCSI interface. As for specific drives, personally I have been using a Sony SDX-300C (AIT) drive under FreeBSD since pre-3.0. > The FreeBSD FAQ states: > "FreeBSD supports SCSI, QIC-36 (with a QIC-02 interface) and QIC-40/80 > (Floppy based) tape drives. This includes > 8-mm (aka Exabyte) and DAT drives. The QIC-40/80 drives are known to be > slow. > It would be nearly impossible to list every drive out on the market. In general, most tape drives that follow the SCSI specification should work. When in doubt, just ask. ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jul 6 20:18:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id C0AB914D5A for ; Tue, 6 Jul 1999 20:18:11 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA88180; Tue, 6 Jul 1999 21:17:27 -0600 (MDT) (envelope-from ken) Message-Id: <199907070317.VAA88180@panzer.kdm.org> Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: from "Chris D. Faulhaber" at "Jul 6, 1999 09:24:03 pm" To: jedgar@fxp.org (Chris D. Faulhaber) Date: Tue, 6 Jul 1999 21:17:27 -0600 (MDT) Cc: chris@thedial.com (Christopher Taylor), freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris D. Faulhaber wrote... > On Tue, 6 Jul 1999, Christopher Taylor wrote: > > > I need a high capacity tape backup solution for FreeBSD. In the past, I > > have used DAT with no problems, but now I need something quite a bit > > bigger and more reliable. Does FreeBSD support AIT or DLT devices? Would > > these be considered "SCSI" as stated in the FreeBSD FAQ? > > > > Yes, AIT and DLT drives are considered SCSI if they use a standard SCSI > interface. As for specific drives, personally I have been using a Sony > SDX-300C (AIT) drive under FreeBSD since pre-3.0. I can also confirm that the SDX-300C works just fine under FreeBSD. It can even hold more than 50G on a single tape. :) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 0:18:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 30FF614BDE for ; Wed, 7 Jul 1999 00:17:48 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id JAA25934; Wed, 7 Jul 1999 09:17:21 +0200 (MET DST) Date: Wed, 7 Jul 1999 09:17:20 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , Christopher Taylor , freebsd-scsi@FreeBSD.ORG Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: <199907070317.VAA88180@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Yes, AIT and DLT drives are considered SCSI if they use a standard SCSI > > interface. As for specific drives, personally I have been using a Sony > > SDX-300C (AIT) drive under FreeBSD since pre-3.0. > > I can also confirm that the SDX-300C works just fine under FreeBSD. It > can even hold more than 50G on a single tape. :) The OnStream drives don't. Just in case you were wondering. Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 8:22:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ezln23.earthbroadcasting.com (ezln23.thedial.com [207.135.131.130]) by hub.freebsd.org (Postfix) with ESMTP id 0876C14D85 for ; Wed, 7 Jul 1999 08:22:40 -0700 (PDT) (envelope-from chris@thedial.com) Received: from thedial.com (localhost.earthbroadcasting.com [127.0.0.1]) by ezln23.earthbroadcasting.com (8.9.3/8.9.3) with ESMTP id JAA84844; Wed, 7 Jul 1999 09:22:21 -0600 (MDT) (envelope-from chris@thedial.com) Message-ID: <378370AD.D6B861EF@thedial.com> Date: Wed, 07 Jul 1999 09:22:21 -0600 From: Christopher Taylor X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nick Hibma Cc: "Kenneth D. Merry" , "Chris D. Faulhaber" , freebsd-scsi@FreeBSD.ORG Subject: Re: AIT/DLT Tape Compatibility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for all of your replies to my post...I think I will continue with my plans to get a Sony AIT drive... --Chris -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Christopher Taylor Technical Director Earth Broadcasting Corporation (EBC) 415 East 200 South Salt Lake City, Utah 84111 phone: (801) 322-3949 cell: (801) 541-8287 email: chris@thedial.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 10:45:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 219D615251 for ; Wed, 7 Jul 1999 10:45:18 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA28502; Wed, 7 Jul 1999 19:40:18 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA00754; Wed, 7 Jul 1999 19:19:43 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907071719.TAA00754@yedi.iaf.nl> Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: <199907070317.VAA88180@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 6, 1999 9:17:27 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 7 Jul 1999 19:19:43 +0200 (CEST) Cc: jedgar@fxp.org, chris@thedial.com, freebsd-scsi@freebsd.org 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Chris D. Faulhaber wrote... > > On Tue, 6 Jul 1999, Christopher Taylor wrote: > > > > > I need a high capacity tape backup solution for FreeBSD. In the past, I > > > have used DAT with no problems, but now I need something quite a bit > > > bigger and more reliable. Does FreeBSD support AIT or DLT devices? Would > > > these be considered "SCSI" as stated in the FreeBSD FAQ? > > > > > > > Yes, AIT and DLT drives are considered SCSI if they use a standard SCSI > > interface. As for specific drives, personally I have been using a Sony > > SDX-300C (AIT) drive under FreeBSD since pre-3.0. > > I can also confirm that the SDX-300C works just fine under FreeBSD. It > can even hold more than 50G on a single tape. :) To add to the confusion: DLT2000 and DLT4000 run just fine with FreeBSD. I run both models. Don't have a DLT7000 but I have no reason to assume it would work any less than the DLT[24]00 drives. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 10:48:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1EA8414EEA for ; Wed, 7 Jul 1999 10:48:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA17380; Wed, 7 Jul 1999 10:48:26 -0700 Date: Wed, 7 Jul 1999 10:48:26 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: "Kenneth D. Merry" , jedgar@fxp.org, chris@thedial.com, freebsd-scsi@FreeBSD.ORG Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: <199907071719.TAA00754@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > > > I need a high capacity tape backup solution for FreeBSD. In the past, I > > > > have used DAT with no problems, but now I need something quite a bit > > > > bigger and more reliable. Does FreeBSD support AIT or DLT devices? Would > > > > these be considered "SCSI" as stated in the FreeBSD FAQ? > > > > > > > > > > Yes, AIT and DLT drives are considered SCSI if they use a standard SCSI > > > interface. As for specific drives, personally I have been using a Sony > > > SDX-300C (AIT) drive under FreeBSD since pre-3.0. > > > > I can also confirm that the SDX-300C works just fine under FreeBSD. It > > can even hold more than 50G on a single tape. :) > > To add to the confusion: DLT2000 and DLT4000 run just fine with FreeBSD. > I run both models. Don't have a DLT7000 but I have no reason to assume > it would work any less than the DLT[24]00 drives. Why is this confusion? Have I missed a bug report somewhere? The Onstream device support is in progress. It's not 50GB for this model, but that will be coming. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 12:18:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id BA1081548D; Wed, 7 Jul 1999 12:18:37 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id TAA00656; Wed, 7 Jul 1999 19:11:42 +0200 (CEST) (envelope-from se) Date: Wed, 7 Jul 1999 19:11:39 +0200 From: Stefan Esser To: "Kenneth D. Merry" Cc: Andre Oppermann , freebsd-scsi@FreeBSD.ORG, Stefan Esser Subject: Re: ncr0: queue is empty Message-ID: <19990707191139.A552@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG References: <19990704224907.A2698@dialup124.mi.uni-koeln.de> <199907050121.TAA73301@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199907050121.TAA73301@panzer.kdm.org>; from Kenneth D. Merry on Sun, Jul 04, 1999 at 07:21:26PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-07-04 19:21 -0600, "Kenneth D. Merry" wrote: > The Atlas I had some firmware problems similar to the Atlas II, namely that > it would lock up under high load. I think the L915 firmware fixed that > problem. I'm not sure whether the Atlas I had the queue full problems that > the Atlas II and III have, though. Justin might remember. Well, and my Atlas I **knows** ;-) The original Atlas had the same problem as the later models. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 15: 0:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 0817E154C2 for ; Wed, 7 Jul 1999 15:00:14 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA08790; Wed, 7 Jul 1999 23:59:34 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA02645; Wed, 7 Jul 1999 21:28:25 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907071928.VAA02645@yedi.iaf.nl> Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: from Matthew Jacob at "Jul 7, 1999 10:48:26 am" To: mjacob@feral.com Date: Wed, 7 Jul 1999 21:28:25 +0200 (CEST) Cc: ken@plutotech.com, jedgar@fxp.org, chris@thedial.com, freebsd-scsi@FreeBSD.ORG 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > > > > > > > > > I need a high capacity tape backup solution for FreeBSD. In the past, I > > > > > have used DAT with no problems, but now I need something quite a bit > > > > > bigger and more reliable. Does FreeBSD support AIT or DLT devices? Would > > > > > these be considered "SCSI" as stated in the FreeBSD FAQ? > > > > > > > > > > > > > Yes, AIT and DLT drives are considered SCSI if they use a standard SCSI > > > > interface. As for specific drives, personally I have been using a Sony > > > > SDX-300C (AIT) drive under FreeBSD since pre-3.0. > > > > > > I can also confirm that the SDX-300C works just fine under FreeBSD. It > > > can even hold more than 50G on a single tape. :) > > > > To add to the confusion: DLT2000 and DLT4000 run just fine with FreeBSD. > > I run both models. Don't have a DLT7000 but I have no reason to assume > > it would work any less than the DLT[24]00 drives. > > Why is this confusion? Have I missed a bug report somewhere? Ah, sorry. What I meant is: "the difficulty in choosing a device". More choices -> more confusion. > The Onstream device support is in progress. It's not 50GB for this model, > but that will be coming. I don't own a beast like that. From what I've read about it I probably would not consider it either. My bias, probably.. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jul 7 15: 3: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EC8CF1544E for ; Wed, 7 Jul 1999 15:03:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id PAA18329; Wed, 7 Jul 1999 15:02:47 -0700 Date: Wed, 7 Jul 1999 15:02:47 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: ken@plutotech.com, jedgar@fxp.org, chris@thedial.com, freebsd-scsi@FreeBSD.ORG Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: <199907071928.VAA02645@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The Onstream device support is in progress. It's not 50GB for this model, > > but that will be coming. > > I don't own a beast like that. From what I've read about it I probably > would not consider it either. My bias, probably.. > Why? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 8 9:55:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id D388114FA6; Thu, 8 Jul 1999 09:55:22 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id SAA08543; Thu, 8 Jul 1999 18:55:13 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id SAA12192; Thu, 8 Jul 1999 18:54:21 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id SAA08728; Thu, 8 Jul 1999 18:55:12 +0200 (CEST) (envelope-from ticso) Date: Thu, 8 Jul 1999 18:55:11 +0200 From: Bernd Walter To: freebsd-alpha@freebsd.org, freebsd-scsi@freebsd.org Subject: Adaptec 2940UW on alpha working? Message-ID: <19990708185508.A8698@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I need to add some HDDs to my alpha but unfornately I can't use them on the onboard ncr because of cabeling. I own an unused 2940UW and want to know if it is worth to update to a recent current to use it. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 8 11: 0:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 986281555C for ; Thu, 8 Jul 1999 11:00:37 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA01973; Thu, 8 Jul 1999 19:45:29 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id AAA05069; Thu, 8 Jul 1999 00:40:28 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907072240.AAA05069@yedi.iaf.nl> Subject: Re: AIT/DLT Tape Compatibility In-Reply-To: from Matthew Jacob at "Jul 7, 1999 3: 2:47 pm" To: mjacob@feral.com Date: Thu, 8 Jul 1999 00:40:28 +0200 (CEST) Cc: ken@plutotech.com, jedgar@fxp.org, chris@thedial.com, freebsd-scsi@FreeBSD.ORG 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.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > > > > The Onstream device support is in progress. It's not 50GB for this model, > > > but that will be coming. > > > > I don't own a beast like that. From what I've read about it I probably > > would not consider it either. My bias, probably.. > > > Why? Well, IIRC there was a lot of debate on what special adaptations in the drivers were needed for the Onstream. I happen to like devices that 'just work' without lots of tweaking. The biggest compliment devices can get IMHO is "Just works. Boring hardware". I'm not claiming that the Onstream is a bad device though. Just more 'special' it appears. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 8 12:26:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4860715077; Thu, 8 Jul 1999 12:26:27 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA00319; Thu, 8 Jul 1999 13:26:13 -0600 (MDT) (envelope-from ken) Message-Id: <199907081926.NAA00319@panzer.kdm.org> Subject: Re: Adaptec 2940UW on alpha working? In-Reply-To: <19990708185508.A8698@cicely8.cicely.de> from Bernd Walter at "Jul 8, 1999 06:55:11 pm" To: ticso@cicely.de (Bernd Walter) Date: Thu, 8 Jul 1999 13:26:13 -0600 (MDT) Cc: freebsd-alpha@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bernd Walter wrote... > I need to add some HDDs to my alpha but unfornately I can't use them on the > onboard ncr because of cabeling. > I own an unused 2940UW and want to know if it is worth to update to a recent > current to use it. It works: ahc0: irq 20 at device 10.0 on pci1 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: interrupting at CIA irq 20 da2 at ahc0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) That's with -current from mid-June on a 433au box. Of course you can't boot from an Adaptec controller, since SRM doesn't know about it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 8 12:42:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5A236150FB; Thu, 8 Jul 1999 12:42:49 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA21857; Thu, 8 Jul 1999 12:42:33 -0700 Date: Thu, 8 Jul 1999 12:42:33 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Bernd Walter , freebsd-alpha@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Adaptec 2940UW on alpha working? In-Reply-To: <199907081926.NAA00319@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I own an unused 2940UW and want to know if it is worth to update to a recent > > current to use it. > > It works: > > ahc0: irq 20 at device 10.0 on pci1 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc0: interrupting at CIA irq 20 > da2 at ahc0 bus 0 target 0 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da2: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) > > That's with -current from mid-June on a 433au box. So why hasn't alpha/conf/GENERIC been updated? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 8 12:46:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 82E9D150B4; Thu, 8 Jul 1999 12:46:24 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA00491; Thu, 8 Jul 1999 13:46:12 -0600 (MDT) (envelope-from ken) Message-Id: <199907081946.NAA00491@panzer.kdm.org> Subject: Re: Adaptec 2940UW on alpha working? In-Reply-To: from Matthew Jacob at "Jul 8, 1999 12:42:33 pm" To: mjacob@feral.com Date: Thu, 8 Jul 1999 13:46:12 -0600 (MDT) Cc: ken@plutotech.com (Kenneth D. Merry), ticso@cicely.de (Bernd Walter), freebsd-alpha@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > > > > I own an unused 2940UW and want to know if it is worth to update to a recent > > > current to use it. > > > > It works: > > > > ahc0: irq 20 at device 10.0 on pci1 > > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > ahc0: interrupting at CIA irq 20 > > da2 at ahc0 bus 0 target 0 lun 0 > > da2: Fixed Direct Access SCSI-2 device > > da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled > > da2: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) > > > > That's with -current from mid-June on a 433au box. > > So why hasn't alpha/conf/GENERIC been updated? Probably because Justin didn't update it when he checked in the changes to the Adaptec driver. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 9 2: 5:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from metzelkueche.tabu.uni-bonn.de (metzelkueche.tabu.uni-bonn.de [131.220.159.242]) by hub.freebsd.org (Postfix) with ESMTP id C4CA11552A; Fri, 9 Jul 1999 02:05:08 -0700 (PDT) (envelope-from armin@metzelkueche.tabu.uni-bonn.de) Received: from localhost (armin@localhost [127.0.0.1]) by metzelkueche.tabu.uni-bonn.de (8.9.3/8.9.3) with ESMTP id LAA30760; Fri, 9 Jul 1999 11:04:33 +0200 Date: Fri, 9 Jul 1999 11:04:33 +0200 (MEST) From: Armin Ollig X-Sender: armin@metzelkueche.tabu.uni-bonn.de To: freebsd-alpha@FreeBSD.ORG Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Adaptec 2940UW on alpha working? In-Reply-To: <199907081926.NAA00319@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Jul 1999, Kenneth D. Merry wrote: > It works: Unfortunately not for me. I have a NCR810 and an 2940uw in the same machine (PC164_). The NCR works fine. The kernel detects my 2940uw and the UW disk that is connected. However i cannot access the disk at all (cat /dev/da0c and disklabel do not work). > > ahc0: irq 20 at device 10.0 on pci1 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc0: interrupting at CIA irq 20 > da2 at ahc0 bus 0 target 0 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da2: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) Same kernel messages at my alphaPC164, except the disk is a quantum and the controller is early 2940uw. I have FBSD current from around last week. best regards, --armin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 9 8:35:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 13A0E14E0A; Fri, 9 Jul 1999 08:35:09 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA24896; Fri, 9 Jul 1999 08:34:51 -0700 Date: Fri, 9 Jul 1999 08:34:51 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Armin Ollig Cc: freebsd-alpha@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Adaptec 2940UW on alpha working? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You have to give more details than 'does not work'. We're good, but not telepathic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 9 14:22:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AF32414EA0 for ; Fri, 9 Jul 1999 14:22:35 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA26662 for ; Fri, 9 Jul 1999 14:22:34 -0700 Date: Fri, 9 Jul 1999 14:22:34 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: scsi@freebsd.org Subject: CAM scan order perplexities Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sometimes things seem to hang for me irretrievably when I'm booting- somewhere usually in the scanning goop that CAM does when you're booting... Mostly this happens for me with Qlogic FC, but it happens rarely for me also with the Qlogic SCSI- and it happens a lot for Andrew Gallatin @ Duke with SCSI on alpha...(I've made things marginally better for him at the moment by having his isp not scan other than lun 0 and ignore nvram settings..).... But this is not what this mail is about... I've been playing around with watching what goes on to try and sort this out, and here's something very strange.... I've set up a case where I can turn on/off throwing commands at a device, so I try multiple SCANS... here's a trace of this: isp1: Firmware State Config Wait -> Ready isp1: Loop ID 109, ALPA 0x29 isp1: Target 1 (Loop 0x1) Port ID 0xe8 role Target arrived Port WWN 0x2200002037001e57 Node WWN 0x2000002037001e57 isp1: Target 2 (Loop 0x2) Port ID 0xe4 role Target arrived Port WWN 0x22000020370752ba Node WWN 0x20000020370752ba isp1: Target 3 (Loop 0x3) Port ID 0xe2 role Target arrived Port WWN 0x2200002037049513 Node WWN 0x2000002037049513 isp1: Target 4 (Loop 0x4) Port ID 0xe1 role Target arrived Port WWN 0x2200002037049a0a Node WWN 0x2000002037049a0a da3 at isp1 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 100.000MB/s transfers, Tagged Queueing Enabled da3: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da2 at isp1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 100.000MB/s transfers, Tagged Queueing Enabled da2: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da4 at isp1 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 100.000MB/s transfers, Tagged Queueing Enabled da4: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da5 at isp1 bus 0 target 2 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 100.000MB/s transfers, Tagged Queueing Enabled da5: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) ~Stopped at siointr1+0x15c: br zero,siointr1+0x2e0 db> w/l isp_kill_unit 2 isp_kill_unit 0 = 0x2 db> c (da2:isp1:0:1:0): lost device (da2:isp1:0:1:0): removing device entry (da5:isp1:0:2:0): lost device (da5:isp1:0:2:0): removing device entry (da3:isp1:0:3:0): lost device (da3:isp1:0:3:0): removing device entry (da4:isp1:0:4:0): lost device (da4:isp1:0:4:0): removing device entry ~Stopped at siointr1+0x15c: br zero,siointr1+0x2e0 db> w/i isp_kill_unit 2 Unknown size db> w/l isp_kill_unit 0 isp_kill_unit 0x2 = 0 db> c da3 at isp1 bus 0 target 2 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 100.000MB/s transfers, Tagged Queueing Enabled da3: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da4 at isp1 bus 0 target 3 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 100.000MB/s transfers, Tagged Queueing Enabled da4: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da2 at isp1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 100.000MB/s transfers, Tagged Queueing Enabled da2: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da5 at isp1 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 100.000MB/s transfers, Tagged Queueing Enabled da5: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) So, I have four disks on the loop. I camcontrol rescan once, and get the first mapping as: da3 at isp1 bus 0 target 3 lun 0 da2 at isp1 bus 0 target 1 lun 0 da4 at isp1 bus 0 target 4 lun 0 da5 at isp1 bus 0 target 2 lun 0 Now, first of all, this makes no sense to me- the order that this is sent in *should* be 0..N, but that's not what happens. Why? So, I turn of connecting to the device, do a camcontrol rescan which removes all the devices. Then I rescan again and get this: da3 at isp1 bus 0 target 2 lun 0 da4 at isp1 bus 0 target 3 lun 0 da2 at isp1 bus 0 target 1 lun 0 da5 at isp1 bus 0 target 4 lun 0 I'm sorry- this just cannot be the right thing to have happen. I haven't changed a thing in my configuration. Everybody is at the same Loop address. The disks should show back up at the same place. What's going on? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 9 14:34:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1166F14CB0 for ; Fri, 9 Jul 1999 14:34:22 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA26718 for ; Fri, 9 Jul 1999 14:34:22 -0700 Date: Fri, 9 Jul 1999 14:34:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: scsi@freebsd.org Subject: Followup to: CAM scan order perplexities In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In case someone wonders whether they're really different devices, etc.: farrago.feral.com > for i in 2 3 4 5; do root camcontrol inquiry da${i}; done pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number LAE84063 pass2: 100.000MB/s transfers , Tagged Queueing Enabled pass3: Fixed Direct Access SCSI-2 device pass3: Serial Number N8066376 pass3: 100.000MB/s transfers , Tagged Queueing Enabled pass4: Fixed Direct Access SCSI-2 device pass4: Serial Number LA690047 pass4: 100.000MB/s transfers , Tagged Queueing Enabled pass5: Fixed Direct Access SCSI-2 device pass5: Serial Number LA677041 pass5: 100.000MB/s transfers , Tagged Queueing Enabled farrago.feral.com > root camcontrol rescan 1 Re-scan of bus 1 was successful farrago.feral.com > root camcontrol rescan 1 Re-scan of bus 1 was successful farrago.feral.com > for i in 2 3 4 5; do root camcontrol inquiry da${i}; done pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number N8066376 pass2: 100.000MB/s transfers , Tagged Queueing Enabled pass3: Fixed Direct Access SCSI-2 device pass3: Serial Number LAE84063 pass3: 100.000MB/s transfers , Tagged Queueing Enabled pass4: Fixed Direct Access SCSI-2 device pass4: Serial Number LA690047 pass4: 100.000MB/s transfers , Tagged Queueing Enabled pass5: Fixed Direct Access SCSI-2 device pass5: Serial Number LA677041 pass5: 100.000MB/s transfers , Tagged Queueing Enabled To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jul 10 21:21:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 4FC5C14C89 for ; Sat, 10 Jul 1999 21:21:19 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id VAA28966; Sat, 10 Jul 1999 21:21:18 -0700 (PDT) Message-ID: <19990710212118.49328@hydrogen.fircrest.net> Date: Sat, 10 Jul 1999 21:21:18 -0700 From: John-Mark Gurney To: freebsd-scsi@freebsd.org Subject: microp 4421-07 fails on tags... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=S5YaxWCcQjTEyOLp X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --S5YaxWCcQjTEyOLp Content-Type: text/plain; charset=us-ascii well, after a long time testing, the microp 4421-07: da0: Fixed Direct Access SCSI2 device has serious problems with tag queuing... the only way I was able to get this drive to work reliably was to turn of tags completely... does anyone have a drive with a different firmware that does do tags? if no one does, I'll just commit the attached patch.... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson --S5YaxWCcQjTEyOLp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="microp.patch" Index: cam_xpt.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam_xpt.c,v retrieving revision 1.24 diff -u -r1.24 cam_xpt.c --- cam_xpt.c 1998/10/15 19:08:52 1.24 +++ cam_xpt.c 1999/05/17 01:33:32 @@ -236,6 +236,7 @@ static const char quantum[] = "QUANTUM"; static const char sony[] = "SONY"; static const char west_digital[] = "WDIGTL"; +static const char microp[] = "MICROP"; static struct xpt_quirk_entry xpt_quirk_table[] = { @@ -256,12 +257,17 @@ }, { /* Broken tagged queuing drive */ + { T_DIRECT, SIP_MEDIA_FIXED, microp, "4421-07*", "*" }, + /*quirks*/0, /*mintags*/0, /*maxtags*/0 + }, + { + /* Broken tagged queuing drive */ { T_DIRECT, SIP_MEDIA_FIXED, "HP", "C372*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, { /* Broken tagged queuing drive */ - { T_DIRECT, SIP_MEDIA_FIXED, "MICROP", "3391*", "x43h" }, + { T_DIRECT, SIP_MEDIA_FIXED, microp, "3391*", "x43h" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, { --S5YaxWCcQjTEyOLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jul 10 21:30:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 3A5B214CD1 for ; Sat, 10 Jul 1999 21:30:52 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA19573; Sat, 10 Jul 1999 22:30:41 -0600 (MDT) (envelope-from ken) Message-Id: <199907110430.WAA19573@panzer.kdm.org> Subject: Re: microp 4421-07 fails on tags... In-Reply-To: <19990710212118.49328@hydrogen.fircrest.net> from John-Mark Gurney at "Jul 10, 1999 09:21:18 pm" To: gurney_j@resnet.uoregon.edu (John-Mark Gurney) Date: Sat, 10 Jul 1999 22:30:41 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John-Mark Gurney wrote... > well, after a long time testing, the microp 4421-07: > da0: Fixed Direct Access SCSI2 device > > has serious problems with tag queuing... the only way I was able to > get this drive to work reliably was to turn of tags completely... does > anyone have a drive with a different firmware that does do tags? > > if no one does, I'll just commit the attached patch.... You need to be a little more specific about how the drive is broken, and how you tested it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jul 10 21:43:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 413C71506F for ; Sat, 10 Jul 1999 21:43:30 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id VAA29297; Sat, 10 Jul 1999 21:43:20 -0700 (PDT) Message-ID: <19990710214320.56085@hydrogen.fircrest.net> Date: Sat, 10 Jul 1999 21:43:20 -0700 From: John-Mark Gurney To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: microp 4421-07 fails on tags... References: <19990710212118.49328@hydrogen.fircrest.net> <199907110430.WAA19573@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199907110430.WAA19573@panzer.kdm.org>; from Kenneth D. Merry on Sat, Jul 10, 1999 at 10:30:41PM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry scribbled this message on Jul 10: > John-Mark Gurney wrote... > > well, after a long time testing, the microp 4421-07: > > da0: Fixed Direct Access SCSI2 device > > > > has serious problems with tag queuing... the only way I was able to > > get this drive to work reliably was to turn of tags completely... does > > anyone have a drive with a different firmware that does do tags? > > > > if no one does, I'll just commit the attached patch.... > > You need to be a little more specific about how the drive is broken, and > how you tested it. the drive will not return ccb's (the ccb's will timeout) if you have 2 or more tags defined in the quirk structure... I tried various levels of tags from the default limit and 2, 8, 16, and 32 if I remeber correctly... all of those would cause a ccb to not be returned and end up timing out, and now that I have this entry in, I can run with the fs's on it no longer mounted sync (which helped prevent to many commands from hitting the drive)... since I didn't have the nice camcontrol ability to set tags, I had to build kernels to test this... of course this still doesn't address the fact that Justin hasn't gotten back to me on the fact that the adv driver is broken wrt chinon cdrom drives... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jul 10 22:22:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 2405814BE7 for ; Sat, 10 Jul 1999 22:22:38 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA19783; Sat, 10 Jul 1999 23:22:36 -0600 (MDT) (envelope-from ken) Message-Id: <199907110522.XAA19783@panzer.kdm.org> Subject: Re: microp 4421-07 fails on tags... In-Reply-To: <19990710214320.56085@hydrogen.fircrest.net> from John-Mark Gurney at "Jul 10, 1999 09:43:20 pm" To: gurney_j@resnet.uoregon.edu (John-Mark Gurney) Date: Sat, 10 Jul 1999 23:22:36 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John-Mark Gurney wrote... > Kenneth D. Merry scribbled this message on Jul 10: > > John-Mark Gurney wrote... > > > well, after a long time testing, the microp 4421-07: > > > da0: Fixed Direct Access SCSI2 device > > > > > > has serious problems with tag queuing... the only way I was able to > > > get this drive to work reliably was to turn of tags completely... does > > > anyone have a drive with a different firmware that does do tags? > > > > > > if no one does, I'll just commit the attached patch.... > > > > You need to be a little more specific about how the drive is broken, and > > how you tested it. > > the drive will not return ccb's (the ccb's will timeout) if you have 2 > or more tags defined in the quirk structure... I tried various levels > of tags from the default limit and 2, 8, 16, and 32 if I remeber > correctly... all of those would cause a ccb to not be returned and end > up timing out, and now that I have this entry in, I can run with the > fs's on it no longer mounted sync (which helped prevent to many commands > from hitting the drive)... Hmm, sounds like buggy firmware all right. Don't you mean "no longer mounted _async_"? In any case, softupdates would have had a similar effect, and isn't dangerous to run with. > since I didn't have the nice camcontrol ability to set tags, I had to > build kernels to test this... That's unfortunate. You would have been able to do it with -current or -stable from early May on. > of course this still doesn't address the fact that Justin hasn't gotten > back to me on the fact that the adv driver is broken wrt chinon cdrom > drives... Not surprising, I suppose. You might want to ping him again. Anyway, your drive sounds broken enough. Feel free to commit the patch. Make sure you mention the name of the drive in the commit message, and make sure you commit it to -stable as well as -current. I'm sure someone will squawk if they have a 4421 that works properly with tagged queueing. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jul 10 23: 3: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 1237314E3D for ; Sat, 10 Jul 1999 23:02:55 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id XAA00669; Sat, 10 Jul 1999 23:02:37 -0700 (PDT) Message-ID: <19990710230236.35387@hydrogen.fircrest.net> Date: Sat, 10 Jul 1999 23:02:36 -0700 From: John-Mark Gurney To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: microp 4421-07 fails on tags... References: <19990710214320.56085@hydrogen.fircrest.net> <199907110522.XAA19783@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199907110522.XAA19783@panzer.kdm.org>; from Kenneth D. Merry on Sat, Jul 10, 1999 at 11:22:36PM -0600 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry scribbled this message on Jul 10: > John-Mark Gurney wrote... > > Kenneth D. Merry scribbled this message on Jul 10: > > > John-Mark Gurney wrote... > > > > well, after a long time testing, the microp 4421-07: > > > > da0: Fixed Direct Access SCSI2 device > > > > > > > > has serious problems with tag queuing... the only way I was able to > > > > get this drive to work reliably was to turn of tags completely... does > > > > anyone have a drive with a different firmware that does do tags? > > > > > > > > if no one does, I'll just commit the attached patch.... > > > > > > You need to be a little more specific about how the drive is broken, and > > > how you tested it. > > > > the drive will not return ccb's (the ccb's will timeout) if you have 2 > > or more tags defined in the quirk structure... I tried various levels > > of tags from the default limit and 2, 8, 16, and 32 if I remeber > > correctly... all of those would cause a ccb to not be returned and end > > up timing out, and now that I have this entry in, I can run with the > > fs's on it no longer mounted sync (which helped prevent to many commands > > from hitting the drive)... > > Hmm, sounds like buggy firmware all right. Don't you mean "no longer > mounted _async_"? In any case, softupdates would have had a similar > effect, and isn't dangerous to run with. nope, I did mean sync, it seemed to help and actually let me do some installs on the disk, while w/o it, it would fail... > > since I didn't have the nice camcontrol ability to set tags, I had to > > build kernels to test this... > > That's unfortunate. You would have been able to do it with -current or > -stable from early May on. yeh, I noticed, but I did most of the work before the tree was integrated, and I had problems with 3.1-R being worse than 3.0-R as far as the vm system was concerned... > > of course this still doesn't address the fact that Justin hasn't gotten > > back to me on the fact that the adv driver is broken wrt chinon cdrom > > drives... > > Not surprising, I suppose. You might want to ping him again. > > Anyway, your drive sounds broken enough. Feel free to commit the patch. > Make sure you mention the name of the drive in the commit message, and make > sure you commit it to -stable as well as -current. I'm sure someone will > squawk if they have a 4421 that works properly with tagged queueing. yeh, the Microp don't actually have a name for their drives, just their model number... and if they do, we can figure out the fireware rev part of it... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message