From owner-freebsd-scsi Mon Jan 6 01:54:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA24398 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 01:54:15 -0800 (PST) Received: from hydrogen.nike.efn.org (metriclient-9.uoregon.edu [128.223.172.9]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA24393 for ; Mon, 6 Jan 1997 01:54:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.4/8.8.4) with SMTP id BAA01029; Mon, 6 Jan 1997 01:53:01 -0800 (PST) Date: Mon, 6 Jan 1997 01:53:01 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Joerg Wunsch cc: FreeBSD SCSI list Subject: Re: Ideas on CD changers sought In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 4 Jan 1997, J Wunsch wrote: > As John-Mark Gurney wrote: > > > I'm assuming I should combine it with the previous patch, correct? > > Not really. The ``add LUN to second command byte'' patch is gone, > your counter-example proved that it's useless. umm... see below... > But: this patch will only have any effect in your system as long as > you keep the CD-ROM quirk record out that prevents multiple LUNs from > being probed. well... thanks to the brain not working the first time I booted the kernel the cdrom drives probed fine... due to faulty logic the entry was being included... after I fixed the bug... I rebooted... but now it responds on ALL luns... and no unknown devices are created... I will try both your first and second patch together (w/o the quirk entry)... and see if that produces the desired results... :) > If this patch works (i.e., i haven't done any trivial mistake), it > doesn't endanger any production-level environment. The expected > result is that the not really existant LUNs on your Chinon drives pop > up as `uk0' through `uk12' or something like this, but no longer as > bogus `sd' devices. `uk' devices are fairly harmless, almost the only > thing you could do with them is sending direct SCSI commands. actually.. if you think about this... it could be actually very useful... as then you have acess to the additional luns on a device... don't know what you would do with 'em... but you have 'em :)... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-scsi Mon Jan 6 05:22:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA04582 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 05:22:58 -0800 (PST) Received: from david.siemens.de (david.siemens.de [146.254.1.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA04577 for ; Mon, 6 Jan 1997 05:22:55 -0800 (PST) Received: from salomon.mchp.siemens.de (salomon.mchp.siemens.de [139.23.33.13]) by david.siemens.de (8.8.3/8.8.0) with ESMTP id OAA20734 for ; Mon, 6 Jan 1997 14:18:52 +0100 (MET) Received: from curry.mchp.siemens.de (smtpd@curry.zfe.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.2/8.8.0) with ESMTP id OAA20762 for ; Mon, 6 Jan 1997 14:22:35 +0100 (MET) Received: (from smtpd@localhost) by curry.mchp.siemens.de (8.8.4/8.8.4) id OAA17470 for ; Mon, 6 Jan 1997 14:22:34 +0100 (MET) From: Andre Albsmeier Message-Id: <199701061322.OAA14038@server.us.tld> Subject: put SCSI disk on same controller as DLT or not? To: freebsd-scsi@freebsd.org Date: Mon, 6 Jan 1997 14:22:22 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, don't know if this belongs to -scsi or -hardware or elswhere... I'm running 2.2-BETA on a P166 with two Adaptec 2940. I plan to use amanda to do backups on a DEC DLT which is connected to one of the two 2940s. Since a lot of files to be backed up come via a 10 MBps network, I want to use a holding disk where the data is being collcted first and then written to the DLT (which is significantly faster than the network). To optimize performance, I would like to know if I should connect the holding disk to the same 2940 as the DLT is attached to or to the other one. My thoughts are, that if I had both devices on different controllers, the throughput could be faster since the data is read from one controller and pushed directly to the other one. Maybe someone has already experience with this, or some of the SCSI experts can give me a small hint... Thanks in advance, Andre From owner-freebsd-scsi Mon Jan 6 07:36:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA11734 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 07:36:56 -0800 (PST) Received: from destiny.erols.com (someone@destiny.erols.com [207.96.73.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA11727 for ; Mon, 6 Jan 1997 07:36:51 -0800 (PST) Received: from localhost (jdowdal@localhost) by destiny.erols.com (8.8.4/8.6.12) with SMTP id KAA04537; Mon, 6 Jan 1997 10:34:35 -0500 (EST) Date: Mon, 6 Jan 1997 10:34:35 -0500 (EST) From: John Dowdal To: Andre Albsmeier cc: freebsd-scsi@freebsd.org Subject: Re: put SCSI disk on same controller as DLT or not? In-Reply-To: <199701061322.OAA14038@server.us.tld> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 6 Jan 1997, Andre Albsmeier wrote: > Hi, > > don't know if this belongs to -scsi or -hardware or elswhere... > > I'm running 2.2-BETA on a P166 with two Adaptec 2940. I plan to use > amanda to do backups on a DEC DLT which is connected to one of the > two 2940s. Since a lot of files to be backed up come via a 10 MBps network, I > want to use a holding disk where the data is being collcted first and then > written to the DLT (which is significantly faster than the network). > > To optimize performance, I would like to know if I should connect the holding > disk to the same 2940 as the DLT is attached to or to the other one. > > My thoughts are, that if I had both devices on different controllers, the > throughput could be faster since the data is read from one controller > and pushed directly to the other one. > > Maybe someone has already experience with this, or some of the SCSI experts > can give me a small hint... I used to work for the comp sci department at university of maryland [where amanda was written], where they have a couple hundred machines backed up to a 20GB DLT tape on an old DEC 3000 (alpha). The DLT [with compression disabled; using gzip on clients] was able to stream 1500KB/s, The holding disk was an 9GB seagate elite [5400 RPM]. When the dumps were coming in over the network, the tape did not stream [got about 1/2 the maximum throughput] because the holding disk was thrashing from 10 other dumps coming in from other machines at the same time. When the holding disk was otherwise idle, the system streamed the tape. The amanda server had a single Turbochannel [DEC bus] 10mbit scsi controller and 6 devices, but I don't think the machine would have performed much better with two scsi controllers since the disk was seeking itself to death most of the amanda run. There exists a "amanda-users@cs.umd.edu" mailing list for amanda specific questions. To subscribe (stolen from amanda readme) amanda-users The amanda-users mailing list is for questions and general discussion about the Amanda Network Backup Manager. This package and related files are available via anonymous FTP from ftp.cs.umd.edu in the pub/amanda directory. NOTE: the amanda-users list is itself on the amanda-announce distribution, so you only need to subscribe to one of the two lists, not both. To subscribe, send a message to amanda-users-request@cs.umd.edu. John From owner-freebsd-scsi Mon Jan 6 08:17:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA13987 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 08:17:16 -0800 (PST) Received: from gatekeeper.fsl.noaa.gov (gatekeeper.fsl.noaa.gov [137.75.131.181]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA13982 for ; Mon, 6 Jan 1997 08:17:13 -0800 (PST) Received: from cardinal.fsl.noaa.gov (daemon@cardinal.fsl.noaa.gov [137.75.60.101]) by gatekeeper.fsl.noaa.gov (8.7.5/8.7.3) with ESMTP id QAA00443 for ; Mon, 6 Jan 1997 16:17:12 GMT Received: from auk.fsl.noaa.gov by cardinal.fsl.noaa.gov with SMTP (1.40.112.3/16.2) id AA261597432; Mon, 6 Jan 1997 16:17:12 GMT Message-Id: <32D125EB.4E3F@fsl.noaa.gov> Date: Mon, 06 Jan 1997 09:18:51 -0700 From: Kelly Organization: CIRA/NOAA X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX B.10.10 9000/725) Mime-Version: 1.0 To: scsi@freebsd.org Subject: Problem appears from migration from bt0 to ncr0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello SCSI experts. I've recently migrated a host using a Buslogic 946C to an NCR 53C810. This machine contains a DAT drive and I use it as an Amanda dumphost. It also contains a DFRS hard drive. That's where the problem is. The DFRS is a good capacity drive that's nice 'n fast and doesn't even run too hot, but it goes asleep ever so often for some kind of thermal calibration period or something. During this time, the Buslogic driver would report "bt0: try to abort" but everything would be fine afterward. Now, with the NCR driver, things get confused. The thermal calibration period will cause syslogd to have an input/output error trying to write messages to disk. The kernel spits out ncr0: restart (ncr dead ?). Jan 6 03:47:07 sage /kernel: sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Jan 6 03:47:07 sage /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 Jan 6 03:47:07 sage /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred Now, although alarming, the filesystems seem OK. The disk works afterwards as does the CD-ROM. But the worse part is this: access to any sequential devices on the SCSI bus stops working. Any tape activity results in input/output error and messages like the following: Jan 6 06:57:22 sage /kernel: st1(ncr0:3:0): 275ns (4 Mb/sec) offset 8. Jan 6 06:57:22 sage /kernel: st1(ncr0:3:0): NOT READY asc:4,1 Jan 6 06:57:22 sage /kernel: st1(ncr0:3:0): Logical unit is in process of becoming ready Jan 6 06:57:37 sage /kernel: ncr0: restart (ncr dead ?). It looks like any tape activity causes a bus reset, and the tape drives can't handle it. But I'm probably wrong. Now, I wouldn't mind chucking the DFRS drive into the nearest active volcano complete with massive cinder dome and flying sparks and other nifty special effects, but my wife would frown on more computer equipment appearing on the credit card bill. So, is there anything you could recommend I try in software? -- Sean Kelly NOAA Forecast Systems Laboratory kelly@fsl.noaa.gov Boulder Colorado USA http://www-sdd.fsl.noaa.gov/~kelly/ From owner-freebsd-scsi Mon Jan 6 12:00:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA24227 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 12:00:51 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA24145 for ; Mon, 6 Jan 1997 11:59:13 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA22179 (5.67b/IDA-1.5 for ); Mon, 6 Jan 1997 20:58:50 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id UAA03245; Mon, 6 Jan 1997 20:58:51 +0100 (CET) Message-Id: Date: Mon, 6 Jan 1997 20:58:50 +0100 From: se@freebsd.org (Stefan Esser) To: kelly@fsl.noaa.gov (Kelly) Cc: scsi@freebsd.org Subject: Re: Problem appears from migration from bt0 to ncr0 References: <32D125EB.4E3F@fsl.noaa.gov> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 In-Reply-To: <32D125EB.4E3F@fsl.noaa.gov>; from Kelly on Jan 6, 1997 09:18:51 -0700 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 6, kelly@fsl.noaa.gov (Kelly) wrote: > Hello SCSI experts. > > I've recently migrated a host using a Buslogic 946C to an NCR 53C810. Which FreeBSD version is that ? Please test with a 2.2-BETA, if possible ... > This machine contains a DAT drive and I use it as an Amanda dumphost. > It also contains a DFRS hard drive. That's where the problem is. > > The DFRS is a good capacity drive that's nice 'n fast and doesn't even > run too hot, but it goes asleep ever so often for some kind of thermal > calibration period or something. During this time, the Buslogic driver > would report "bt0: try to abort" but everything would be fine afterward. > > Now, with the NCR driver, things get confused. The thermal calibration > period will cause syslogd to have an input/output error trying to write > messages to disk. The kernel spits out Well, the DFRS is known to go asleep for more than a minute :( You can extend the time-outs (in the GENERIC SCSI code) to be longer than that, for all commands. This should avoid the code that thinks the NCR might be dead, if no progress is made for a long time, and no NCR chip and SCSI bus reset would occur ... > ncr0: restart (ncr dead ?). > Jan 6 03:47:07 sage /kernel: sd0(ncr0:0:0): FAST SCSI-2 100ns (10 > Mb/sec) offset 8. > Jan 6 03:47:07 sage /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 > Jan 6 03:47:07 sage /kernel: sd0(ncr0:0:0): Power on, reset, or bus > device reset occurred > > Now, although alarming, the filesystems seem OK. The disk works > afterwards as does the CD-ROM. > > But the worse part is this: access to any sequential devices on the SCSI > bus stops working. Any tape activity results in input/output error and > messages like the following: > > Jan 6 06:57:22 sage /kernel: st1(ncr0:3:0): 275ns (4 Mb/sec) offset 8. > Jan 6 06:57:22 sage /kernel: st1(ncr0:3:0): NOT READY asc:4,1 > Jan 6 06:57:22 sage /kernel: st1(ncr0:3:0): Logical unit is in process > of becoming ready > Jan 6 06:57:37 sage /kernel: ncr0: restart (ncr dead ?). What kind of tape device is that ? Please disable synchronous transfers for the tape: # ncrcontrol -t 3 -s sync=0 I guess, that the tape drive and the NCR driver disagree about the transfer mode, after the SCSI bus reset. This must be fixed (if it is the case), but I need more input ... > It looks like any tape activity causes a bus reset, and the tape drives > can't handle it. But I'm probably wrong. I've been thinking whether the tape is reset to use asynchronous transfers after the bus reset, but looking on the messages above, it is obvious that the 4MB transfer rate has successfully been negotiated again. Hmmm ... No idea what's going on here ... > Now, I wouldn't mind chucking the DFRS drive into the nearest active > volcano complete with massive cinder dome and flying sparks and other > nifty special effects, but my wife would frown on more computer > equipment appearing on the credit card bill. So, is there anything you > could recommend I try in software? Please try the ncrcontrol command given above. Report, how long the drive "sleeps". If possible, switch off and on the tape drive and see, whether that makes it operational again ... Regards, STefan From owner-freebsd-scsi Mon Jan 6 12:19:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25130 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 12:19:48 -0800 (PST) Received: from gatekeeper.fsl.noaa.gov (gatekeeper.fsl.noaa.gov [137.75.131.181]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA25083; Mon, 6 Jan 1997 12:19:16 -0800 (PST) Received: from cardinal.fsl.noaa.gov (daemon@cardinal.fsl.noaa.gov [137.75.60.101]) by gatekeeper.fsl.noaa.gov (8.7.5/8.7.3) with ESMTP id UAA02037; Mon, 6 Jan 1997 20:19:15 GMT Received: from auk.fsl.noaa.gov by cardinal.fsl.noaa.gov with SMTP (1.40.112.3/16.2) id AA053741954; Mon, 6 Jan 1997 20:19:15 GMT Message-Id: <32D15EA6.47A0@fsl.noaa.gov> Date: Mon, 06 Jan 1997 13:20:54 -0700 From: Kelly Organization: CIRA/NOAA X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX B.10.10 9000/725) Mime-Version: 1.0 To: Stefan Esser Cc: scsi@freebsd.org Subject: Re: Problem appears from migration from bt0 to ncr0 References: <32D125EB.4E3F@fsl.noaa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've recently migrated a host using a Buslogic 946C to an NCR 53C810. > Which FreeBSD version is that ? > Please test with a 2.2-BETA, if possible ... It's 2.1.5R. I'll try it out with 2.2B as soon as possible. By the way, do you know if it's safe to update just the ncr driver code? > Well, the DFRS is known to go asleep for more than a minute :( Blah! > You can extend the time-outs (in the GENERIC SCSI code) to be > longer than that, for all commands. This should avoid the code > that thinks the NCR might be dead, if no progress is made for > a long time, and no NCR chip and SCSI bus reset would occur ... Sounds good. And I know where that is, too. :-) > What kind of tape device is that ? Wangtek 6130-HS DDS-1. > I've been thinking whether the tape is reset to use asynchronous > transfers after the bus reset, but looking on the messages above, > it is obvious that the 4MB transfer rate has successfully been > negotiated again. Hmmm ... No idea what's going on here ... Neither do I---but that's because I'm as far from being a SCSI expert as Andromeda is from Cleveland. FYI: the DAT drive always appeared as async with the buslogic controller (and the QIC drive in that system was sync). With the ncr, the DAT drive is now sync and the QIC is async! Curious. Thanks very much for your suggestions. I'll try 'em out, then try upgrading to 2.2-BETA, and try 'em out again. Take care! --k From owner-freebsd-scsi Mon Jan 6 12:22:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25383 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 12:22:14 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA25375 for ; Mon, 6 Jan 1997 12:22:10 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA15012; Mon, 6 Jan 1997 21:21:19 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA03430; Mon, 6 Jan 1997 21:21:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA04658; Mon, 6 Jan 1997 21:05:42 +0100 (MET) Message-ID: Date: Mon, 6 Jan 1997 21:05:42 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG (FreeBSD SCSI list) Cc: gurney_j@resnet.uoregon.edu (John-Mark Gurney) Subject: Re: Ideas on CD changers sought References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from John-Mark Gurney on Jan 6, 1997 01:53:01 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As John-Mark Gurney wrote: > included... after I fixed the bug... I rebooted... but now it responds > on ALL luns... and no unknown devices are created... Hmm, i would have loved to see (some of) the probe messages. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Jan 6 12:29:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25841 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 12:29:24 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA25836 for ; Mon, 6 Jan 1997 12:29:19 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA10452 (5.67b/IDA-1.5 for ); Mon, 6 Jan 1997 21:29:05 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id VAA03470; Mon, 6 Jan 1997 21:29:07 +0100 (CET) Message-Id: Date: Mon, 6 Jan 1997 21:29:06 +0100 From: se@freebsd.org (Stefan Esser) To: kelly@fsl.noaa.gov (Kelly) Cc: scsi@freebsd.org Subject: Re: Problem appears from migration from bt0 to ncr0 References: <32D125EB.4E3F@fsl.noaa.gov> <32D15EA6.47A0@fsl.noaa.gov> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 In-Reply-To: <32D15EA6.47A0@fsl.noaa.gov>; from Kelly on Jan 6, 1997 13:20:54 -0700 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 6, kelly@fsl.noaa.gov (Kelly) wrote: > > > I've recently migrated a host using a Buslogic 946C to an NCR 53C810. > > Which FreeBSD version is that ? > > Please test with a 2.2-BETA, if possible ... > > It's 2.1.5R. I'll try it out with 2.2B as soon as possible. By the > way, do you know if it's safe to update just the ncr driver code? No, there are too many changes to other parts of thje kernel. But 2.2R should be as reliable as 2.1.5 ... > > Well, the DFRS is known to go asleep for more than a minute :( > > Blah! Didn't you observe this ? The drive is identical to the twice as expencive DFHS, except for the scheduled power down after some 10s of hours. No problem for a workstation, but unacceptable for a server that is kept powered on for days (or months). > Sounds good. And I know where that is, too. :-) Fine! Please report, whether it helps ... > > What kind of tape device is that ? > > Wangtek 6130-HS DDS-1. Hmmm, that's a first generation DDS-1 DAT, right ? > FYI: the DAT drive always appeared as async with the buslogic controller > (and the QIC drive in that system was sync). With the ncr, the DAT > drive is now sync and the QIC is async! Curious. Then just try async transfers for both of them ... If they are targets 3 and 4, then the following single command will do: # ncrcontrol -t 3 -t 4 -s sync=0 Regards, STefan From owner-freebsd-scsi Mon Jan 6 13:16:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA29095 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 13:16:29 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA29082 for ; Mon, 6 Jan 1997 13:16:21 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA31931 (5.67b/IDA-1.5 for freebsd-scsi@freebsd.org); Mon, 6 Jan 1997 22:15:58 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id UAA00758; Mon, 6 Jan 1997 20:36:57 +0100 (MET) From: Wilko Bulte Message-Id: <199701061936.UAA00758@yedi.iaf.nl> Subject: Re: put SCSI disk on same controller as DLT or not? To: Andre.Albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Mon, 6 Jan 1997 20:36:57 +0100 (MET) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199701061322.OAA14038@server.us.tld> from "Andre Albsmeier" at Jan 6, 97 02:22:22 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Andre Albsmeier wrote... > I'm running 2.2-BETA on a P166 with two Adaptec 2940. I plan to use > amanda to do backups on a DEC DLT which is connected to one of the > two 2940s. Since a lot of files to be backed up come via a 10 MBps network, I > want to use a holding disk where the data is being collcted first and then > written to the DLT (which is significantly faster than the network). > > To optimize performance, I would like to know if I should connect the holding > disk to the same 2940 as the DLT is attached to or to the other one. My experience on a Sun Sparc20 is that to keep the DLT streaming it is best to hook the disk and DLT to different controllers. The Sun could not keep up with the data rate the DLT required. This was Solaris 2.4 BTW. On my own DLT2000 on a P100 FreeBSD box I first had the DLT hooked up to the same NCR810 as the system disk. Worked ok for backups with 'dump', practically no stop 'n go operation. The DLT is now on a seperate NCR810 (I got too much SCSI devices :-) but the speed is the same. Note that all of this highly depends on how 'compressible' your data is. To keep streaming on highly compressible data the DLT needs much more data to be delivered to it's SCSI interface. If you feel adventurous you can get the transfer statistics from the DLT drive itself. To do this I hacked up the script below. Note that this script is known to have crashed my system (very seldom, but still). #!/bin/sh # dltinfo: get more information out of your DLT tape # drive. # # (C) 1996, Wilko Bulte, wilko@yedi.iaf.nl # # Warning: This script was only tested on a DEC TZ87 DLT # drive. It has been observed to hang the SCSI # bus/card/driver (?? who knows). Use it at your # own risk. # # You need the DLT drive's OEM manual (or similar) to make # sense out of some of the data reported. # Please send any constructive comments by email to wilko@yedi.iaf.nl Device=/dev/st2 CtrlDevice=${Device}ctl.0 ## scsi(8) setup Verbose="-v" TimeOut="-s 3" ### Do a full inquiry (including vendor unique info) # Assumption: the spurious hangups are either firmware or # SCSI card driver related... do_inquiry() { echo ------ Inquiry Product data ------ echo scsi -f $CtrlDevice \ $Verbose \ $Timeout \ -c "12 0 0 0 38 0" \ -i 56 \ "{skip} s8 \ {Vendor } z8 \ {ProductID } z16 \ {Version } z4 \ {Released FW flag } i1 \ {Firmware version } i2 \ {EEPROM Format } i2 \ {Firmware personality } i1 \ {Firmware sub-personality } i1 \ {Tape directory format version } i1 \ {Controller hardware revision } i1 \ {Drive EEPROM version } i1 \ {Drive hardware version } i1 \ {Media loader EEPROM version } i1 \ {Media loader hardware version } i1 \ {Media loader mechanical version } i1 \ {Media loader present flag } i1 \ {Drive library type code } i1" } do_get_ecm_serial() { # Get electronics module serial number from Vital Product Data pages scsi -f $CtrlDevice \ $Verbose \ $TimeOut \ -c "12 1 80 0 e 0" \ -i 14 \ "{skip} *i4 \ {ECM serial number } z10" } do_get_fw_details() { # Get firmware details from Vital Product Data pages scsi -f $CtrlDevice \ $Verbose \ $TimeOut \ -c "12 1 C0 0 24 0" \ -i 36 \ "{skip} *i4 \ {Servo Firmware checksum } i2 \ {Servo EEPROM checksum } i2 \ {68020 Firmware checksum } i4 \ {68020 Firmware build date } z24" } get_write_error_log() { echo ------ Write errors log page ------ echo scsi -f $CtrlDevice \ $Verbose \ $Timeout \ -c "4d 0 42 0 0 0 0 0 3f 0" \ -i 63 \ "{skip} *i4 \ {skip} *i4 \ {Corrected errors without substantial delay} i4 \ {skip} *i4 \ {Corrected errors with possible delay } i4 \ {skip} *i4 \ {Total errors } i4 \ {skip} *i4 \ {Total errors corrected } i4 \ {skip} *i4 \ {Total times correction algorithm processed} i4 \ {skip} *i4 \ {Total bytes processed } i8 \ {skip} *i4 \ {Total uncorrected errors } i4" echo ------ End of write errors log page ------ } get_read_error_log() { echo ------ Read errors log page ------ echo scsi -f $CtrlDevice \ $Verbose \ $Timeout \ -c "4d 0 43 0 0 0 0 0 3f 0" \ -i 63 \ "{skip} *i4 \ {skip} *i4 \ {Corrected errors without substantial delay} i4 \ {skip} *i4 \ {Corrected errors with possible delay } i4 \ {skip} *i4 \ {Total errors } i4 \ {skip} *i4 \ {Total errors corrected } i4 \ {skip} *i4 \ {Total times correction algorithm processed} i4 \ {skip} *i4 \ {Total bytes processed } i8 \ {skip} *i4 \ {Total uncorrected errors } i4" echo ------ End of read errors log page ------ } get_compression_log() { # Assumption: from the results observed in testing it lookse # like the residual counts are in kBytes (and not # in Mbytes as the TZ87 manual tells us). echo ------ Compression log page ------ echo scsi -f $CtrlDevice \ $Verbose \ $Timeout \ -c "4d 0 72 0 0 0 0 0 4c 0" \ -i 76 \ "{skip} *i4 \ {skip } *i4 \ {Read compression ratio (* 100 %) } i2 \ {skip } *i4 \ {Write compression ratio (* 100 %) } i2 \ {skip } *i4 \ {Total host Mbytes reads } i4 \ {skip } *i4 \ {Total host kbytes read residual } i4 \ {skip } *i4 \ {On tape Mbytes read } i4 \ {skip} *i4 \ {On tape kbytes read residual } i4 \ {skip} *i4 \ {Host requested Mbytes written } i4 \ {skip} *i4 \ {Host requested kbytes written residual } i4 \ {skip} *i4 \ {On tape Mbytes written } i4 \ {skip} *i4 \ {On tape kbytes written residual } i4 " echo ------ End of compression log page ------ } get_read_error_log echo get_write_error_log echo get_compression_log do_inquiry Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-scsi Mon Jan 6 14:01:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA03059 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 14:01:47 -0800 (PST) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA03054 for ; Mon, 6 Jan 1997 14:01:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.4/8.8.4) with SMTP id OAA03702; Mon, 6 Jan 1997 14:00:58 -0800 (PST) Date: Mon, 6 Jan 1997 14:00:58 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Joerg Wunsch cc: FreeBSD SCSI list Subject: Re: Ideas on CD changers sought In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 6 Jan 1997, J Wunsch wrote: > As John-Mark Gurney wrote: > > > included... after I fixed the bug... I rebooted... but now it responds > > on ALL luns... and no unknown devices are created... > > Hmm, i would have loved to see (some of) the probe messages. well.. I didn't look to closely.. but from what I remeber they just probed as any cdrom would... when I get home I will run some tests with both your hacks and just your last hack... and of course save the dmesg output... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-scsi Mon Jan 6 15:36:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA10444 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 15:36:45 -0800 (PST) Received: from mongo.hfconsulting.com (mongo.louisville.edu [136.165.241.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA10438 for ; Mon, 6 Jan 1997 15:36:42 -0800 (PST) Received: (from hans@localhost) by mongo.hfconsulting.com (8.7.5/8.6.6) id SAA02149 for freebsd-scsi@freebsd.org; Mon, 6 Jan 1997 18:36:36 -0500 (EST) From: Hans Fiedler Message-Id: <199701062336.SAA02149@mongo.hfconsulting.com> Subject: WangTek 3200 tape drive To: freebsd-scsi@freebsd.org Date: Mon, 6 Jan 1997 18:36:35 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've sort of aquired a WangTek 3200SE standalone SCSI tape drive from a system that's going away. I put it on an Adeptec AHA2940, but it doesn't seem to work, but does on the old box (HP9000/710). The errors I'm getting on the console are; st0(ahc1:0:0): MEDIUM ERROR info:113000 asc:c,0 Write error sks:80,1 st0(ahc1:0:0): MEDIUM ERROR info:1 asc:c,0 Write error and I just get an an Input/output error on the tar process tar: can't write to /dev/rst0 : Input/output error I've tried several tapes, and they are write enabled, I don't have any documentation on the drive other then a sheet detailing the dip settings, which look reasonable to me, and are the same as ehwn it worked on the HP box. I'm wondering if anyone has gotten one of these working and if so were there any special settings on the drive or the SCSI adaptor? Thanks for any help. From owner-freebsd-scsi Mon Jan 6 23:17:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA03167 for freebsd-scsi-outgoing; Mon, 6 Jan 1997 23:17:59 -0800 (PST) Received: from hydrogen.nike.efn.org (metriclient-8.uoregon.edu [128.223.172.8]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA03150 for ; Mon, 6 Jan 1997 23:17:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hydrogen.nike.efn.org (8.8.4/8.8.4) with SMTP id XAA00365; Mon, 6 Jan 1997 23:16:23 -0800 (PST) Date: Mon, 6 Jan 1997 23:16:23 -0800 (PST) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Joerg Wunsch cc: FreeBSD SCSI list Subject: Re: Ideas on CD changers sought In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-707283115-852621383=:311" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-707283115-852621383=:311 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 6 Jan 1997, J Wunsch wrote: > As John-Mark Gurney wrote: > > > included... after I fixed the bug... I rebooted... but now it responds > > on ALL luns... and no unknown devices are created... > > Hmm, i would have loved to see (some of) the probe messages. here you go... as you can see the one with both hacks (testboth) does assign the other luns to the uk device... I have the verbose boot messages from both.. but there isn't any difference in the probes... oh... sorry for taking so long... I didn't sleep for that whole 24 hours or so :) ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) --0-707283115-852621383=:311 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=test Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: RnJlZUJTRCAyLjItOTYwODAxLVNOQVAgIzI6IFN1biBKYW4gIDUgMTc6NDI6 NTkgUFNUIDE5OTcNCiAgICByb290QDovdXNyL3NyYy9zeXMvY29tcGlsZS90 ZXN0DQpDYWxpYnJhdGluZyBjbG9jayhzKSByZWxhdGl2ZSB0byBtYzE0Njgx OEEgY2xvY2suLi4NCmk4MjU0IGNsb2NrOiAxMTkzMzA2IEh6DQpDUFU6IGk0 ODZEWCAoNDg2LWNsYXNzIENQVSkNCiAgT3JpZ2luID0gIkF1dGhlbnRpY0FN RCIgIElkID0gMHg0ZjQNCnJlYWwgbWVtb3J5ICA9IDUwMzMxNjQ4ICg0OTE1 MksgYnl0ZXMpDQphdmFpbCBtZW1vcnkgPSA0NzYxNjAwMCAoNDY1MDBLIGJ5 dGVzKQ0KUHJvYmluZyBmb3IgZGV2aWNlcyBvbiBQQ0kgYnVzIDA6DQpjaGlw MCA8Z2VuZXJpYyBQQ0kgYnJpZGdlICh2ZW5kb3I9MTEwNiBkZXZpY2U9MDUw NSBzdWJjbGFzcz0wKT4gcmV2IDMgb24gcGNpMDowDQpidDAgPEJ1c2xvZ2lj IDk0NiBTQ1NJIGhvc3QgYWRhcHRlcj4gcmV2IDAgaW50IGEgaXJxIDE1IG9u IHBjaTA6OQ0KYnQwOiBCdDk0NkMvIDAtKDMyYml0KSBidXMNCmJ0MDogcmVh ZGluZyBib2FyZCBzZXR0aW5ncywgYnVzbWFzdGVyaW5nLCBpbnQ9MTUNCmJ0 MDogdmVyc2lvbiA0LjI0LCBzeW5jLCBwYXJpdHksIDMyIG1ieHMsIDMyIGNj YnMNCmJ0MDogdGFyZyAwIHN5bmMgcmF0ZT0xMC4wME1CL3MoMTAwbnMpLCBv ZmZzZXQ9MTUNCmJ0MDogdGFyZyAyIHN5bmMgcmF0ZT0xMC4wME1CL3MoMTAw bnMpLCBvZmZzZXQ9MTUNCmJ0MDogdGFyZyA1IGFzeW5jDQpidDA6IFVzaW5n IFN0cmljdCBSb3VuZCByb2JpbiBzY2hlbWUNCmJ0MCB3YWl0aW5nIGZvciBz Y3NpIGRldmljZXMgdG8gc2V0dGxlDQooYnQwOjA6MCk6ICJDT05ORVIgQ0ZQ MTA2MFMgMS4wNUdCIDIwMzUiIHR5cGUgMCBmaXhlZCBTQ1NJIDINCnNkMChi dDA6MDowKTogRGlyZWN0LUFjY2VzcyAxMDEzTUIgKDIwNzQ4ODAgNTEyIGJ5 dGUgc2VjdG9ycykNCihidDA6MjowKTogIk1JQ1JPUCA0NDIxLTA3ICAgMDMy OVNKIDAzMjkiIHR5cGUgMCBmaXhlZCBTQ1NJIDINCnNkMShidDA6MjowKTog RGlyZWN0LUFjY2VzcyAyMDQ3TUIgKDQxOTMzNjAgNTEyIGJ5dGUgc2VjdG9y cykNCihidDA6MzowKTogIkNISU5PTiBDRC1ST00gQ0RTLTUzNSBRMjAiIHR5 cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDEoYnQwOjM6MCk6IENELVJPTSBj ZCBwcmVzZW50IFsxODY5OTAgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6 MzoxKTogIkNISU5PTiBDRC1ST00gQ0RTLTUzNSBRMjAiIHR5cGUgNSByZW1v dmFibGUgU0NTSSAyDQpjZDMoYnQwOjM6MSk6IENELVJPTSBjZCBwcmVzZW50 IFsxODY5OTAgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6MzoyKTogIkNI SU5PTiBDRC1ST00gQ0RTLTUzNSBRMjAiIHR5cGUgNSByZW1vdmFibGUgU0NT SSAyDQpjZDQoYnQwOjM6Mik6IENELVJPTSBjZCBwcmVzZW50IFsxODY5OTAg eCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6MzozKTogIkNISU5PTiBDRC1S T00gQ0RTLTUzNSBRMjAiIHR5cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDUo YnQwOjM6Myk6IENELVJPTSBjZCBwcmVzZW50IFsxODY5OTAgeCAyMDQ4IGJ5 dGUgcmVjb3Jkc10NCihidDA6Mzo0KTogIkNISU5PTiBDRC1ST00gQ0RTLTUz NSBRMjAiIHR5cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDYoYnQwOjM6NCk6 IENELVJPTSBjZCBwcmVzZW50IFsxODY5OTAgeCAyMDQ4IGJ5dGUgcmVjb3Jk c10NCihidDA6Mzo1KTogIkNISU5PTiBDRC1ST00gQ0RTLTUzNSBRMjAiIHR5 cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDcoYnQwOjM6NSk6IENELVJPTSBj ZCBwcmVzZW50IFsxODY5OTAgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6 Mzo2KTogIkNISU5PTiBDRC1ST00gQ0RTLTUzNSBRMjAiIHR5cGUgNSByZW1v dmFibGUgU0NTSSAyDQpjZDgoYnQwOjM6Nik6IENELVJPTSBjZCBwcmVzZW50 IFsxODY5OTAgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6Mzo3KTogIkNI SU5PTiBDRC1ST00gQ0RTLTUzNSBRMjAiIHR5cGUgNSByZW1vdmFibGUgU0NT SSAyDQpjZDkoYnQwOjM6Nyk6IENELVJPTSBjZCBwcmVzZW50IFsxODY5OTAg eCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6NDowKTogIkNISU5PTiBDRC1S T00gQ0RTLTUzNSBRMTAiIHR5cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDIo YnQwOjQ6MCk6IENELVJPTSBjZCBwcmVzZW50IFszMDAwNzcgeCAyMDQ4IGJ5 dGUgcmVjb3Jkc10NCihidDA6NDoxKTogIkNISU5PTiBDRC1ST00gQ0RTLTUz NSBRMTAiIHR5cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDEwKGJ0MDo0OjEp OiBDRC1ST00gY2QgcHJlc2VudCBbMzAwMDc3IHggMjA0OCBieXRlIHJlY29y ZHNdDQooYnQwOjQ6Mik6ICJDSElOT04gQ0QtUk9NIENEUy01MzUgUTEwIiB0 eXBlIDUgcmVtb3ZhYmxlIFNDU0kgMg0KY2QxMShidDA6NDoyKTogQ0QtUk9N IGNkIHByZXNlbnQgWzMwMDA3NyB4IDIwNDggYnl0ZSByZWNvcmRzXQ0KKGJ0 MDo0OjMpOiAiQ0hJTk9OIENELVJPTSBDRFMtNTM1IFExMCIgdHlwZSA1IHJl bW92YWJsZSBTQ1NJIDINCmNkMTIoYnQwOjQ6Myk6IENELVJPTSBjZCBwcmVz ZW50IFszMDAwNzcgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihidDA6NDo0KTog IkNISU5PTiBDRC1ST00gQ0RTLTUzNSBRMTAiIHR5cGUgNSByZW1vdmFibGUg U0NTSSAyDQpjZDEzKGJ0MDo0OjQpOiBDRC1ST00gY2QgcHJlc2VudCBbMzAw MDc3IHggMjA0OCBieXRlIHJlY29yZHNdDQooYnQwOjQ6NSk6ICJDSElOT04g Q0QtUk9NIENEUy01MzUgUTEwIiB0eXBlIDUgcmVtb3ZhYmxlIFNDU0kgMg0K Y2QxNChidDA6NDo1KTogQ0QtUk9NIGNkIHByZXNlbnQgWzMwMDA3NyB4IDIw NDggYnl0ZSByZWNvcmRzXQ0KKGJ0MDo0OjYpOiAiQ0hJTk9OIENELVJPTSBD RFMtNTM1IFExMCIgdHlwZSA1IHJlbW92YWJsZSBTQ1NJIDINCmNkMTUoYnQw OjQ6Nik6IENELVJPTSBjZCBwcmVzZW50IFszMDAwNzcgeCAyMDQ4IGJ5dGUg cmVjb3Jkc10NCihidDA6NDo3KTogIkNISU5PTiBDRC1ST00gQ0RTLTUzNSBR MTAiIHR5cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDE2KGJ0MDo0OjcpOiBD RC1ST00gY2QgcHJlc2VudCBbMzAwMDc3IHggMjA0OCBieXRlIHJlY29yZHNd DQooYnQwOjU6MCk6ICJQTEVYVE9SIENELVJPTSBETS1YWDI4IDMuMDgiIHR5 cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDAoYnQwOjU6MCk6IENELVJPTSBj ZCBwcmVzZW50IFszMDE4NjYgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCnZnYTAg PFZHQS1jb21wYXRpYmxlIGRpc3BsYXkgZGV2aWNlPiByZXYgNzEgb24gcGNp MDoxMA0KUHJvYmluZyBmb3IgZGV2aWNlcyBvbiB0aGUgSVNBIGJ1czoNCnNj MCBhdCAweDYwLTB4NmYgaXJxIDEgb24gbW90aGVyYm9hcmQNCnNjMDogVkdB IGNvbG9yIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDA+DQplZDAg YXQgMHgzMDAtMHgzMWYgaXJxIDExIG9uIGlzYQ0KZWQwOiBhZGRyZXNzIDAw OjIwOmE5OjAxOmRjOmUzLCB0eXBlIE5FMjAwMCAoMTYgYml0KSANCnNpbzAg YXQgMHgzZjgtMHgzZmYgaXJxIDQgb24gaXNhDQpzaW8wOiB0eXBlIDE2NTUw QQ0Kc2lvMSBhdCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2ENCnNpbzE6IHR5 cGUgMTY1NTBBDQpkZ2IwOiBQQy9YZSA2NC84SyAod2luZG93ZWQpDQpkZ2Iw IGF0IDB4MzIwLTB4MzIzIG1hZGRyIDB4ZDAwMDAgbXNpemUgODE5MiBvbiBp c2ENCmRnYjA6IDIgcG9ydHMNCmxwdDAgbm90IGZvdW5kIGF0IDB4ZmZmZmZm ZmYNCmxwdDEgbm90IGZvdW5kIGF0IDB4ZmZmZmZmZmYNCmZkYzAgYXQgMHgz ZjAtMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhDQpmZGMwOiBORUMgNzY1DQpm ZDA6IDEuMk1CIDUuMjVpbg0KbWF0Y2RjMCBub3QgZm91bmQgYXQgMHgyMzAN CnNiMCBhdCAweDIyMCBpcnEgMTAgZHJxIDEgb24gaXNhDQpzYjA6IDxTb3Vu ZEJsYXN0ZXIgUHJvIDMuMT4NCm9wbDAgYXQgMHgzODggb24gaXNhDQpvcGww OiA8WWFtYWhhIE9QTC0zIEZNPg0KbnB4MCBvbiBtb3RoZXJib2FyZA0KbnB4 MDogSU5UIDE2IGludGVyZmFjZQ0Kc3RyYXkgaXJxIDcNCnN0cmF5IGlycSA3 DQpzdHJheSBpcnEgNw0Kc3RyYXkgaXJxIDcNCnN0cmF5IGlycSA3DQp0b28g bWFueSBzdHJheSBpcnEgNydzOyBub3QgbG9nZ2luZyBhbnkgbW9yZQ0K --0-707283115-852621383=:311 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=testboth Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: YmluIHNjaGVtZQ0KYnQwIHdhaXRpbmcgZm9yIHNjc2kgZGV2aWNlcyB0byBz ZXR0bGUNCihidDA6MDowKTogIkNPTk5FUiBDRlAxMDYwUyAxLjA1R0IgMjAz NSIgdHlwZSAwIGZpeGVkIFNDU0kgMg0Kc2QwKGJ0MDowOjApOiBEaXJlY3Qt QWNjZXNzIDEwMTNNQiAoMjA3NDg4MCA1MTIgYnl0ZSBzZWN0b3JzKQ0KKGJ0 MDoyOjApOiAiTUlDUk9QIDQ0MjEtMDcgICAwMzI5U0ogMDMyOSIgdHlwZSAw IGZpeGVkIFNDU0kgMg0Kc2QxKGJ0MDoyOjApOiBEaXJlY3QtQWNjZXNzIDIw NDdNQiAoNDE5MzM2MCA1MTIgYnl0ZSBzZWN0b3JzKQ0KKGJ0MDozOjApOiAi Q0hJTk9OIENELVJPTSBDRFMtNTM1IFEyMCIgdHlwZSA1IHJlbW92YWJsZSBT Q1NJIDINCmNkMShidDA6MzowKTogQ0QtUk9NIGNkIHByZXNlbnQgWzE4Njk5 MCB4IDIwNDggYnl0ZSByZWNvcmRzXQ0KKGJ0MDozOjEpOiBVTklUIEFUVEVO VElPTiBhc2M6MjgsMA0KKGJ0MDozOjEpOiAgTm90IHJlYWR5IHRvIHJlYWR5 IHRyYW5zaXRpb24sIG1lZGl1bSBtYXkgaGF2ZSBjaGFuZ2VkDQooYnQwOjM6 MSk6ICJ1bmtub3duIHVua25vd24gPz8/PyIgdHlwZSAxMyBmaXhlZCBTQ1NJ IDANCnVrMChidDA6MzoxKTogVW5rbm93biANCihidDA6MzoyKTogVU5JVCBB VFRFTlRJT04gYXNjOjI4LDANCihidDA6MzoyKTogIE5vdCByZWFkeSB0byBy ZWFkeSB0cmFuc2l0aW9uLCBtZWRpdW0gbWF5IGhhdmUgY2hhbmdlZA0KKGJ0 MDozOjIpOiAidW5rbm93biB1bmtub3duID8/Pz8iIHR5cGUgMTMgZml4ZWQg U0NTSSAwDQp1azEoYnQwOjM6Mik6IFVua25vd24gDQooYnQwOjM6Myk6IFVO SVQgQVRURU5USU9OIGFzYzoyOCwwDQooYnQwOjM6Myk6ICBOb3QgcmVhZHkg dG8gcmVhZHkgdHJhbnNpdGlvbiwgbWVkaXVtIG1heSBoYXZlIGNoYW5nZWQN CihidDA6MzozKTogInVua25vd24gdW5rbm93biA/Pz8/IiB0eXBlIDEzIGZp eGVkIFNDU0kgMA0KdWsyKGJ0MDozOjMpOiBVbmtub3duIA0KKGJ0MDozOjQp OiBVTklUIEFUVEVOVElPTiBhc2M6MjgsMA0KKGJ0MDozOjQpOiAgTm90IHJl YWR5IHRvIHJlYWR5IHRyYW5zaXRpb24sIG1lZGl1bSBtYXkgaGF2ZSBjaGFu Z2VkDQooYnQwOjM6NCk6ICJ1bmtub3duIHVua25vd24gPz8/PyIgdHlwZSAx MyBmaXhlZCBTQ1NJIDANCnVrMyhidDA6Mzo0KTogVW5rbm93biANCihidDA6 Mzo1KTogVU5JVCBBVFRFTlRJT04gYXNjOjI4LDANCihidDA6Mzo1KTogIE5v dCByZWFkeSB0byByZWFkeSB0cmFuc2l0aW9uLCBtZWRpdW0gbWF5IGhhdmUg Y2hhbmdlZA0KKGJ0MDozOjUpOiAidW5rbm93biB1bmtub3duID8/Pz8iIHR5 cGUgMTMgZml4ZWQgU0NTSSAwDQp1azQoYnQwOjM6NSk6IFVua25vd24gDQoo YnQwOjM6Nik6IFVOSVQgQVRURU5USU9OIGFzYzoyOCwwDQooYnQwOjM6Nik6 ICBOb3QgcmVhZHkgdG8gcmVhZHkgdHJhbnNpdGlvbiwgbWVkaXVtIG1heSBo YXZlIGNoYW5nZWQNCihidDA6Mzo2KTogInVua25vd24gdW5rbm93biA/Pz8/ IiB0eXBlIDEzIGZpeGVkIFNDU0kgMA0KdWs1KGJ0MDozOjYpOiBVbmtub3du IA0KKGJ0MDozOjcpOiBVTklUIEFUVEVOVElPTiBhc2M6MjgsMA0KKGJ0MDoz OjcpOiAgTm90IHJlYWR5IHRvIHJlYWR5IHRyYW5zaXRpb24sIG1lZGl1bSBt YXkgaGF2ZSBjaGFuZ2VkDQooYnQwOjM6Nyk6ICJ1bmtub3duIHVua25vd24g Pz8/PyIgdHlwZSAxMyBmaXhlZCBTQ1NJIDANCnVrNihidDA6Mzo3KTogVW5r bm93biANCihidDA6NDowKTogIkNISU5PTiBDRC1ST00gQ0RTLTUzNSBRMTAi IHR5cGUgNSByZW1vdmFibGUgU0NTSSAyDQpjZDIoYnQwOjQ6MCk6IENELVJP TSBjZCBwcmVzZW50IFszMDAwNzcgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCihi dDA6NDoxKTogVU5JVCBBVFRFTlRJT04gYXNjOjI4LDANCihidDA6NDoxKTog IE5vdCByZWFkeSB0byByZWFkeSB0cmFuc2l0aW9uLCBtZWRpdW0gbWF5IGhh dmUgY2hhbmdlZA0KKGJ0MDo0OjEpOiAidW5rbm93biB1bmtub3duID8/Pz8i IHR5cGUgMTMgZml4ZWQgU0NTSSAwDQp1azcoYnQwOjQ6MSk6IFVua25vd24g DQooYnQwOjQ6Mik6IFVOSVQgQVRURU5USU9OIGFzYzoyOCwwDQooYnQwOjQ6 Mik6ICBOb3QgcmVhZHkgdG8gcmVhZHkgdHJhbnNpdGlvbiwgbWVkaXVtIG1h eSBoYXZlIGNoYW5nZWQNCihidDA6NDoyKTogInVua25vd24gdW5rbm93biA/ Pz8/IiB0eXBlIDEzIGZpeGVkIFNDU0kgMA0KdWs4KGJ0MDo0OjIpOiBVbmtu b3duIA0KKGJ0MDo0OjMpOiBVTklUIEFUVEVOVElPTiBhc2M6MjgsMA0KKGJ0 MDo0OjMpOiAgTm90IHJlYWR5IHRvIHJlYWR5IHRyYW5zaXRpb24sIG1lZGl1 bSBtYXkgaGF2ZSBjaGFuZ2VkDQooYnQwOjQ6Myk6ICJ1bmtub3duIHVua25v d24gPz8/PyIgdHlwZSAxMyBmaXhlZCBTQ1NJIDANCnVrOShidDA6NDozKTog VW5rbm93biANCihidDA6NDo0KTogVU5JVCBBVFRFTlRJT04gYXNjOjI4LDAN CihidDA6NDo0KTogIE5vdCByZWFkeSB0byByZWFkeSB0cmFuc2l0aW9uLCBt ZWRpdW0gbWF5IGhhdmUgY2hhbmdlZA0KKGJ0MDo0OjQpOiAidW5rbm93biB1 bmtub3duID8/Pz8iIHR5cGUgMTMgZml4ZWQgU0NTSSAwDQp1azEwKGJ0MDo0 OjQpOiBVbmtub3duIA0KKGJ0MDo0OjUpOiBVTklUIEFUVEVOVElPTiBhc2M6 MjgsMA0KKGJ0MDo0OjUpOiAgTm90IHJlYWR5IHRvIHJlYWR5IHRyYW5zaXRp b24sIG1lZGl1bSBtYXkgaGF2ZSBjaGFuZ2VkDQooYnQwOjQ6NSk6ICJ1bmtu b3duIHVua25vd24gPz8/PyIgdHlwZSAxMyBmaXhlZCBTQ1NJIDANCnVrMTEo YnQwOjQ6NSk6IFVua25vd24gDQooYnQwOjQ6Nik6IFVOSVQgQVRURU5USU9O IGFzYzoyOCwwDQooYnQwOjQ6Nik6ICBOb3QgcmVhZHkgdG8gcmVhZHkgdHJh bnNpdGlvbiwgbWVkaXVtIG1heSBoYXZlIGNoYW5nZWQNCihidDA6NDo2KTog InVua25vd24gdW5rbm93biA/Pz8/IiB0eXBlIDEzIGZpeGVkIFNDU0kgMA0K dWsxMihidDA6NDo2KTogVW5rbm93biANCihidDA6NDo3KTogVU5JVCBBVFRF TlRJT04gYXNjOjI4LDANCihidDA6NDo3KTogIE5vdCByZWFkeSB0byByZWFk eSB0cmFuc2l0aW9uLCBtZWRpdW0gbWF5IGhhdmUgY2hhbmdlZA0KKGJ0MDo0 OjcpOiAidW5rbm93biB1bmtub3duID8/Pz8iIHR5cGUgMTMgZml4ZWQgU0NT SSAwDQp1azEzKGJ0MDo0OjcpOiBVbmtub3duIA0KKGJ0MDo1OjApOiAiUExF WFRPUiBDRC1ST00gRE0tWFgyOCAzLjA4IiB0eXBlIDUgcmVtb3ZhYmxlIFND U0kgMg0KY2QwKGJ0MDo1OjApOiBDRC1ST00gY2QgcHJlc2VudCBbMzAxODY2 IHggMjA0OCBieXRlIHJlY29yZHNdDQp2Z2EwIDxWR0EtY29tcGF0aWJsZSBk aXNwbGF5IGRldmljZT4gcmV2IDcxIG9uIHBjaTA6MTANClByb2JpbmcgZm9y IGRldmljZXMgb24gdGhlIElTQSBidXM6DQpzYzAgYXQgMHg2MC0weDZmIGly cSAxIG9uIG1vdGhlcmJvYXJkDQpzYzA6IFZHQSBjb2xvciA8MTYgdmlydHVh bCBjb25zb2xlcywgZmxhZ3M9MHgwPg0KZWQwIGF0IDB4MzAwLTB4MzFmIGly cSAxMSBvbiBpc2ENCmVkMDogYWRkcmVzcyAwMDoyMDphOTowMTpkYzplMywg dHlwZSBORTIwMDAgKDE2IGJpdCkgDQpzaW8wIGF0IDB4M2Y4LTB4M2ZmIGly cSA0IG9uIGlzYQ0Kc2lvMDogdHlwZSAxNjU1MEENCnNpbzEgYXQgMHgyZjgt MHgyZmYgaXJxIDMgb24gaXNhDQpzaW8xOiB0eXBlIDE2NTUwQQ0KZGdiMDog UEMvWGUgNjQvOEsgKHdpbmRvd2VkKQ0KZGdiMCBhdCAweDMyMC0weDMyMyBt YWRkciAweGQwMDAwIG1zaXplIDgxOTIgb24gaXNhDQpkZ2IwOiAyIHBvcnRz DQpscHQwIG5vdCBmb3VuZCBhdCAweGZmZmZmZmZmDQpscHQxIG5vdCBmb3Vu ZCBhdCAweGZmZmZmZmZmDQpmZGMwIGF0IDB4M2YwLTB4M2Y3IGlycSA2IGRy cSAyIG9uIGlzYQ0KZmRjMDogTkVDIDc2NQ0KZmQwOiAxLjJNQiA1LjI1aW4N Cm1hdGNkYzAgbm90IGZvdW5kIGF0IDB4MjMwDQpzYjAgYXQgMHgyMjAgaXJx IDEwIGRycSAxIG9uIGlzYQ0Kc2IwOiA8U291bmRCbGFzdGVyIFBybyAzLjE+ DQpvcGwwIGF0IDB4Mzg4IG9uIGlzYQ0Kb3BsMDogPFlhbWFoYSBPUEwtMyBG TT4NCm5weDAgb24gbW90aGVyYm9hcmQNCm5weDA6IElOVCAxNiBpbnRlcmZh Y2UNCnN0cmF5IGlycSA3DQpzdHJheSBpcnEgNw0Kc3RyYXkgaXJxIDcNCnN0 cmF5IGlycSA3DQpzdHJheSBpcnEgNw0KdG9vIG1hbnkgc3RyYXkgaXJxIDcn czsgbm90IGxvZ2dpbmcgYW55IG1vcmUNCg== --0-707283115-852621383=:311-- From owner-freebsd-scsi Tue Jan 7 07:05:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA25246 for freebsd-scsi-outgoing; Tue, 7 Jan 1997 07:05:03 -0800 (PST) Received: from pupil.ifpan.edu.pl (pupil.ifpan.edu.pl [148.81.45.137]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id HAA25193 for ; Tue, 7 Jan 1997 07:03:54 -0800 (PST) Received: (from slawek@localhost) by pupil.ifpan.edu.pl (8.6.12/8.6.12) id QAA00201 for freebsd-scsi@freebsd.org; Tue, 7 Jan 1997 16:00:56 GMT From: Slawomir Stuglik Message-Id: <199701071600.QAA00201@pupil.ifpan.edu.pl> Subject: dev for WD7193 SCSI ctrl? To: freebsd-scsi@freebsd.org Date: Tue, 7 Jan 1997 16:00:55 +0000 () X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey friends, I have a question: Did exist any version FreeBSD which have driver for WD7193 SCSI / PCI controler? -- Slawomir Stuglik -= IRC: sipek =- email: slawek@belfer.ifpan.edu.pl Location: Warszawa, Polska, PGP key & GEEK CODE available on finger. Slawek Stuglik It's better to have gun and not need it than to need a gun and not have it. From owner-freebsd-scsi Tue Jan 7 14:52:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA17441 for freebsd-scsi-outgoing; Tue, 7 Jan 1997 14:52:31 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA17421 for ; Tue, 7 Jan 1997 14:52:15 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA26901; Tue, 7 Jan 1997 23:51:39 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA00288; Tue, 7 Jan 1997 23:51:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id XAA10403; Tue, 7 Jan 1997 23:39:44 +0100 (MET) Message-ID: Date: Tue, 7 Jan 1997 23:39:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hans@hfconsulting.com (Hans Fiedler) Cc: freebsd-scsi@freebsd.org Subject: Re: WangTek 3200 tape drive References: <199701062336.SAA02149@mongo.hfconsulting.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701062336.SAA02149@mongo.hfconsulting.com>; from Hans Fiedler on Jan 6, 1997 18:36:35 -0500 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Hans Fiedler wrote: > st0(ahc1:0:0): MEDIUM ERROR info:113000 asc:c,0 Write error sks:80,1 > st0(ahc1:0:0): MEDIUM ERROR info:1 asc:c,0 Write error There's probably not much we could do for you. You are sure that you're using the correct medium type? What kind of drive is it, DAT? Maybe you're trying to use it with a wrong blocksize? What does `mt status' report? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Jan 8 05:20:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA04664 for freebsd-scsi-outgoing; Wed, 8 Jan 1997 05:20:59 -0800 (PST) Received: from dicsmss1.jrc.it (dicsmss1.jrc.it [139.191.1.65]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA04632; Wed, 8 Jan 1997 05:20:48 -0800 (PST) Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA19074; Wed, 8 Jan 97 14:26:23 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA04911; Wed, 8 Jan 1997 14:20:18 +0100 Date: Wed, 8 Jan 1997 14:20:17 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: freebsd-scsi@freebsd.org, freebsd-questions@freebsd.org Subject: AVA-1505, 2.2-alpha and IRQs Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just browsed through the list of AVA-1505 related postings; but I could find no answer on the quesion; o Does the AVA-1505 work (with 2.2-Alpha ?) I've tried to get it to work; it is recognized fine by the aic0 driver; but after that things hang as there seems to be no IRQ coming back from the card. During the boot it uses polling; so that works fine (regardless IRQ and IRQ settings). I've tried to cook a kernel which had only the bare essentials; removed all other cards; forces the P&P support to just the two I needed for video and ide controller; and put some IRQ debugging in. It seems to go down to the 6360 chip fine; if you use the poll you can see it worked fine; but no IRQ ever comes back; rerardless of the board jumper setting. Anyone any ideas ? Cause it is kind of slow with the polling :-) Has anyone got it to work ? I.e. the actual AVA1505 beastie; not the older 6360 based controllers ! Dw. http://ewse.ceo.org http://enrm.ceo.org DWvGulik@Dialis.xs4all.nl Dirk.vanGulik@jrc.it +39 332 78 0014 +39 332 78 9549 fax +39 332 78 9185 ISEI/ESBA; The Center For Earth Observation Joint Research Centre of the European Communities, Ispra, Italy From owner-freebsd-scsi Wed Jan 8 06:11:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA06496 for freebsd-scsi-outgoing; Wed, 8 Jan 1997 06:11:07 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA06486; Wed, 8 Jan 1997 06:10:49 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id PAA16943; Wed, 8 Jan 1997 15:12:51 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id PAA01734; Wed, 8 Jan 1997 15:10:34 +0100 (MET) From: Christoph Kukulies Message-Id: <199701081410.PAA01734@gilberto.physik.rwth-aachen.de> Subject: Re: AVA-1505, 2.2-alpha and IRQs In-Reply-To: from "Dirk.vanGulik@jrc.it" at "Jan 8, 97 02:20:17 pm" To: Dirk.vanGulik@jrc.it Date: Wed, 8 Jan 1997 15:10:33 +0100 (MET) Cc: freebsd-scsi@freebsd.org, freebsd-questions@freebsd.org Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Just browsed through the list of AVA-1505 related postings; but > I could find no answer on the quesion; > > o Does the AVA-1505 work (with 2.2-Alpha ?) > > I've tried to get it to work; it is recognized fine by the aic0 > driver; but after that things hang as there seems to be no IRQ > coming back from the card. During the boot it uses polling; so > that works fine (regardless IRQ and IRQ settings). > > I've tried to cook a kernel which had only the bare essentials; > removed all other cards; forces the P&P support to just the two > I needed for video and ide controller; and put some IRQ debugging > in. It seems to go down to the 6360 chip fine; if you use the > poll you can see it worked fine; but no IRQ ever comes back; > rerardless of the board jumper setting. > > Anyone any ideas ? Cause it is kind of slow with the polling :-) > > Has anyone got it to work ? I.e. the actual AVA1505 beastie; not the > older 6360 based controllers ! I have one of these (AVA1505) in my drawer as the result of an unsuccessful effort getting it to work here under a 3.0-current. Interesting that you are saying that no irq comes through. I observed that the probe was OK but when trying to access the tape I had attached to it the process got hung which may happen when no IRQ occurs. Also the aic probe seemed to mess my WD8013 cards I had in that machine. After all I gave up and bought a used AH1542CF. Maybe something's odd with enabling the interrupts on the board (aic chip). > > Dw. > > > > http://ewse.ceo.org http://enrm.ceo.org > DWvGulik@Dialis.xs4all.nl Dirk.vanGulik@jrc.it > +39 332 78 0014 +39 332 78 9549 > fax +39 332 78 9185 > > ISEI/ESBA; The Center For Earth Observation > Joint Research Centre of the European Communities, Ispra, Italy > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-scsi Wed Jan 8 08:16:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA13116 for freebsd-scsi-outgoing; Wed, 8 Jan 1997 08:16:22 -0800 (PST) Received: from gatekeeper.fsl.noaa.gov (gatekeeper.fsl.noaa.gov [137.75.131.181]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA13089; Wed, 8 Jan 1997 08:16:08 -0800 (PST) Received: from cardinal.fsl.noaa.gov (daemon@cardinal.fsl.noaa.gov [137.75.60.101]) by gatekeeper.fsl.noaa.gov (8.7.5/8.7.3) with ESMTP id QAA11496; Wed, 8 Jan 1997 16:16:07 GMT Received: from auk.fsl.noaa.gov by cardinal.fsl.noaa.gov with SMTP (1.40.112.3/16.2) id AA155570166; Wed, 8 Jan 1997 16:16:06 GMT Message-Id: <32D3C8B1.EDA@fsl.noaa.gov> Date: Wed, 08 Jan 1997 09:17:53 -0700 From: Sean Kelly Organization: CIRA/NOAA X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX B.10.10 9000/725) Mime-Version: 1.0 To: Stefan Esser Cc: scsi@freebsd.org Subject: Re: Problem appears from migration from bt0 to ncr0 References: <32D125EB.4E3F@fsl.noaa.gov> <32D15EA6.47A0@fsl.noaa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan: Here're the results so far with the DFRS drive of doom. First, with the system running 2.1.5R, I modified /sys/scsi/sd.c and changed xs->timeout from 10000 to 80000. Later that evening, the DFRS went to sleep but the same problem occurred as before. Perhaps I should've used a higher value? (And if what I changed wasn't correct, do let me know.) Next, I upgraded to 2.2-BETA, and ran the system with an unmodified sd.c. This time, the system locked up (!) when the DFRS went to sleep. The console displayed: ncr0: SCSI phase error fixup: CCB already dequeued (...) and the scrollback buffer worked, and I could enter my account name at the login prompt. But nothing else; as if any activity requiring the disk just hung. I hit the reset switch. I still need to try changing the xs->timeout in the 2.2-BETA kernel and forcing the tape drives to be async in /etc/rc.local. Thanks for your help so far! -- Sean Kelly NOAA Forecast Systems Laboratory kelly@fsl.noaa.gov Boulder Colorado USA http://www-sdd.fsl.noaa.gov/~kelly/ From owner-freebsd-scsi Thu Jan 9 02:27:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA21552 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 02:27:35 -0800 (PST) Received: from plato.salford.ac.uk (plato.salford.ac.uk [146.87.1.3]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id CAA21515 for ; Thu, 9 Jan 1997 02:27:26 -0800 (PST) Received: (qmail 18989 invoked by uid 141); 9 Jan 1997 10:27:22 -0000 Date: Thu, 9 Jan 1997 10:27:22 +0000 (GMT) From: Mark Powell To: Lindsay Computer Systems cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? In-Reply-To: <199701081734.LAA18011@jump.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 8 Jan 1997, Lindsay Computer Systems wrote: > On 8 Jan 1997 17:08:23 -0000, mark@plato.salford.ac.uk wrote: > >>The ATX (XP55T2P4) Revision 3.0 does NOT have 75Mhz or 83Mhz settings. > >>The P55T2P4-S has the third jumper soldered over to preclude 75Mhz or > >>83Mhz. settings. > >Rick, are you saying that the only board that supports 75 and 83 is > >the plain T2P4 rev. >= 3.0? I was going to get a T2P4S for the SCSI, > >but will get a seperate 2940UW if necessary to get the 75MHz bus speed. > > Correct, only the plain P55T2P4 rev. 3.0/3.1 have everything needed to do 75 & 83Mhz, > but I seriously doubt that a heavily loaded 2940 will perform well above 33Mhz PCI bus > speeds.... Why's that? Also, what d'you mean by "well"? > The SC-200 and the SC-875 stand a much better chance of running well at higher PCI > bus speeds when drives are attached that fully use their capabilities. Not too sure on the quality of the FreeBSD drivers for the NCR though. And I don't think the NCR 53c875 is supported at all, just 810 & 825 :( Suppose, I could just use narrow drives instead of the wides I currently have? Hmmm, I really wanted to overclock a Cyrix 6x86 P166+ to a P200+, and this seemed to be the way to do it from other's expericence. Do you have any idea whether the DFI G586VPS Pro (using VLSI Lunx chipset) or the or the MTech R534 (http://www.mtiusa.com/r534.htm), using the Sis5571 chipset which I think I read somewhere "allows the PCI bus to be locked at 32MHz [sic?] whatever the external clock speed", would be better for this purpose? > Rick Lindsay, Lindsay Computer Systems, http://www.jump.net/~lcs/ > Voice: 512-719-5257, Austin, Texas Sorry for all the questions, Rick, but you do seem to know your stuff :) Cheers. Mark Powell - Unix Information Officer - Clifford Whitworth Building A.I.S., University of Salford, Salford, Manchester, UK. Tel: +44 161 745 5936 Fax: +44 161 736 3596 Email: mark@salford.ac.uk finger mark@ucsalf.ac.uk (for PGP key) Home Page From owner-freebsd-scsi Thu Jan 9 04:08:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA25588 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 04:08:38 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA25583 for ; Thu, 9 Jan 1997 04:08:34 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id WAA26952; Thu, 9 Jan 1997 22:38:17 +1030 (CST) From: Michael Smith Message-Id: <199701091208.WAA26952@genesis.atrad.adelaide.edu.au> Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? In-Reply-To: from Mark Powell at "Jan 9, 97 10:27:22 am" To: mark@salford.ac.uk (Mark Powell) Date: Thu, 9 Jan 1997 22:38:16 +1030 (CST) Cc: lcs@jumpnet.com, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Powell stands accused of saying: > > > Correct, only the plain P55T2P4 rev. 3.0/3.1 have everything needed to do 75 & 83Mhz, > > but I seriously doubt that a heavily loaded 2940 will perform well above 33Mhz PCI bus > > speeds.... > > Why's that? Also, what d'you mean by "well"? A good question. Providing the bus interface on the aic7xxx part is up to it, it might run faster. Bear in mind that it's only designed for 33MHz though. > > The SC-200 and the SC-875 stand a much better chance of running well at higher PCI > > bus speeds when drives are attached that fully use their capabilities. > > Not too sure on the quality of the FreeBSD drivers for the NCR though. And The FreeBSD NCR drivers are excellent. Note that experimental evidence tends to indicate that the 2940 is better under multi-drive loads than the NCR, but by a fairly small margin. Also note that many so-called "onboard 2940" controllers are actually lower-spec parts that won't perform anywhere near as well. Basically, we have the following Adaptec parts : aic7880 : AHC398xU, AHC3940U, AHC2940U aic7870 : AHC398x, AHC3940, AHC2940 aic7860 : AHC2940AU, "onboard 2940" aic7850, aic7855 : "onboard 2940" If at all possible, demand to know which chip is actually used. The comment "when drives are attached that fully use their capabilities" is a bit of a curious one though. Drives don't use a controller's capabilities; the driver does, in order to use the drive's capabilities. > I don't think the NCR 53c875 is supported at all, just 810 & 825 :( The FreeBSD/NetBSD NCR driver supports the 810, 815, 820, 825, 860 and 875. > Suppose, I could just use narrow drives instead of the wides I > currently have? Hmmm, I really wanted to overclock a Cyrix 6x86 > P166+ to a P200+, and this seemed to be the way to do it from > other's expericence. Why? Unless you are going to be doing things that are totally CPU bound, you should be more worried about memory and I/O throughput than plain CPU cycle time. Going to narrow drives will just defeat this. > Do you have any idea whether the DFI G586VPS Pro (using VLSI Lunx chipset) > or the or the MTech R534 (http://www.mtiusa.com/r534.htm), using the > Sis5571 chipset which I think I read somewhere "allows the PCI bus to be > locked at 32MHz [sic?] whatever the external clock speed", would be better > for this purpose? I would be demanding datasheets on the chipsets in question and studying the timing values programmed by the BIOS for these boards in comparison with the Intel chipsets and their recommended timing. The 430FX chipsets push things pretty hard already; I'm skeptical that these other newcomers are likely to be more than marginally better. > Mark Powell - Unix Information Officer - Clifford Whitworth Building -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-scsi Thu Jan 9 07:20:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA03870 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 07:20:35 -0800 (PST) Received: from europa.salford.ac.uk (europa.salford.ac.uk [146.87.3.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA03858 for ; Thu, 9 Jan 1997 07:20:29 -0800 (PST) Received: from plato.salford.ac.uk by europa.salford.ac.uk with SMTP (PP); Thu, 9 Jan 1997 15:20:09 +0000 Received: (qmail 22019 invoked by alias); 9 Jan 1997 15:20:06 -0000 Delivered-To: alias-catchall-freebsd-scsi@freebsd.org Received: (qmail 22005 invoked by uid 141); 9 Jan 1997 15:20:06 -0000 Date: Thu, 9 Jan 1997 15:20:06 +0000 (GMT) From: Mark Powell To: Michael Smith cc: freebsd-scsi@freebsd.org, freebsd-scsifreeb@sdorgsd.org Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? In-Reply-To: <199701091208.WAA26952@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 9 Jan 1997, Michael Smith wrote: > Mark Powell stands accused of saying: > > > Correct, only the plain P55T2P4 rev. 3.0/3.1 have everything needed to do 75 & 83Mhz, > > > but I seriously doubt that a heavily loaded 2940 will perform well above 33Mhz PCI bus > > > speeds.... > > > > Why's that? Also, what d'you mean by "well"? > > A good question. Providing the bus interface on the aic7xxx part is > up to it, it might run faster. Bear in mind that it's only designed > for 33MHz though. Yeah. The guy replyed saying that Asus have tested the 7880 and found that it doesn't meet all their test criteria over 33MHz. Although it does "work". > > > The SC-200 and the SC-875 stand a much better chance of running well at higher PCI > > > bus speeds when drives are attached that fully use their capabilities. > > > > Not too sure on the quality of the FreeBSD drivers for the NCR though. And > > The FreeBSD NCR drivers are excellent. Note that experimental > evidence tends to indicate that the 2940 is better under multi-drive > loads than the NCR, but by a fairly small margin. Also note that many > so-called "onboard 2940" controllers are actually lower-spec parts > that won't perform anywhere near as well. The P55-T2P4S motherboard has a 7880 on-board. However, that motherboard won't go to 75MHz and 83MHz as will the non-SCSI T2P4. > > I don't think the NCR 53c875 is supported at all, just 810 & 825 :( > > The FreeBSD/NetBSD NCR driver supports the 810, 815, 820, 825, 860 and > 875. > > > Suppose, I could just use narrow drives instead of the wides I > > currently have? Hmmm, I really wanted to overclock a Cyrix 6x86 > > P166+ to a P200+, and this seemed to be the way to do it from > > other's expericence. > > Why? Unless you are going to be doing things that are totally CPU > bound, you should be more worried about memory and I/O throughput than > plain CPU cycle time. Going to narrow drives will just defeat this. Yeah, I know. I meant if the 875 wasn't supported I could use the 810 with narrow drives and still push the external clock speed to 75MHz. However, now you've enlightened me I can get the 875 and use it under FreeBSD with my wide drives and hopefully with a greater chance of success than with a 7880. > > Do you have any idea whether the DFI G586VPS Pro (using VLSI Lunx chipset) > > or the or the MTech R534 (http://www.mtiusa.com/r534.htm), using the > > Sis5571 chipset which I think I read somewhere "allows the PCI bus to be > > locked at 32MHz [sic?] whatever the external clock speed", would be better > > for this purpose? > > I would be demanding datasheets on the chipsets in question and > studying the timing values programmed by the BIOS for these boards in > comparison with the Intel chipsets and their recommended timing. The > 430FX chipsets push things pretty hard already; I'm skeptical that > these other newcomers are likely to be more than marginally better. These chipsets are designed to accomodate the Cyrix P200+ which needs an external clock speed of 75MHz. They also support the Cyrix's "Linear Burst Mode" which can supposedly give a 3-5% speed improvement on cache filling. However, I agree and think I'd be going down a blind alley with such new chipsets. I'll stick with the 430HX chipset on the T2P4. Mark Powell - Unix Information Officer - Clifford Whitworth Building A.I.S., University of Salford, Salford, Manchester, UK. Tel: +44 161 745 5936 Fax: +44 161 736 3596 Email: mark@salford.ac.uk finger mark@ucsalf.ac.uk (for PGP key) Home Page From owner-freebsd-scsi Thu Jan 9 07:42:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA05064 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 07:42:09 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA05058 for ; Thu, 9 Jan 1997 07:42:06 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id CAA27446; Fri, 10 Jan 1997 02:11:49 +1030 (CST) From: Michael Smith Message-Id: <199701091541.CAA27446@genesis.atrad.adelaide.edu.au> Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? In-Reply-To: from Mark Powell at "Jan 9, 97 03:20:06 pm" To: M.S.Powell@ais.salford.ac.uk (Mark Powell) Date: Fri, 10 Jan 1997 02:11:48 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-scsi@freebsd.org, freebsd-scsifreeb@sdorgsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Powell stands accused of saying: > > Yeah, I know. I meant if the 875 wasn't supported I could use the 810 with > narrow drives and still push the external clock speed to 75MHz. However, That would be stupid. The extra CPU performance would be more than offset by the loss of disk performance in all but the most extreme cases. > now you've enlightened me I can get the 875 and use it under FreeBSD with > my wide drives and hopefully with a greater chance of success than with a > 7880. If you have several wide disks, the 7880 will probably give better performance than the 875, all other things being equal. > These chipsets are designed to accomodate the Cyrix P200+ which needs an > external clock speed of 75MHz. They also support the Cyrix's "Linear Burst > Mode" which can supposedly give a 3-5% speed improvement on cache filling. > However, I agree and think I'd be going down a blind alley with such new > chipsets. I'll stick with the 430HX chipset on the T2P4. No! You're not paying attention 8) You want an _FX_ chipset motherboard, specifically for the improved CPU-memory bandwidth. Even the VX with all its corners cut is faster than the HX. Don't kid yourself that the extra few MHz of PCI speed will make major differences to your performance, particularly if it means that you sacrifice CPU-memory bandwidth to get it. Spend some time looking for the real bottlenecks in the system rather than trying to open paths that are already adequately wide. > Mark Powell - Unix Information Officer - Clifford Whitworth Building -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-scsi Thu Jan 9 11:14:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA16407 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 11:14:40 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA16383 for ; Thu, 9 Jan 1997 11:14:27 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2-biteme) with ESMTP id NAA08395 for ; Thu, 9 Jan 1997 13:14:12 -0600 (CST) Received: from Mercury.mcs.net (fredriks@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA22683 for ; Thu, 9 Jan 1997 13:14:08 -0600 (CST) Received: (from fredriks@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id NAA17382 for scsi@freebsd.org; Thu, 9 Jan 1997 13:14:04 -0600 (CST) From: Lars Fredriksen Message-Id: <199701091914.NAA17382@Mercury.mcs.net> Subject: Adaptech 2940/44W and older drives To: scsi@freebsd.org Date: Thu, 9 Jan 1997 13:14:04 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just upgraded my machine, and am running into problems with my older drives. The Apdatech 2944W (differential version of the 2940) reports the following types of errors: timeout in datain phase SCSISIGI=0x54 timeout in datain phase SCSISIGI=0x44 and then a UNIT ATTENTION (power on/reset/device reset) The same configuration worked just great with my EISA based 2740 controller. I thought it first to be an issue with my 68 pin to 50 pin cable for the narrow devices, but using the internal 50 pin connector displays the same symtoms. The firmware level on the 2744 is from 1995 (I forgot the revision number), but it is less than 1.23. The devices that I am talking to are all Seagate 1G or 2G disks (5 1/4). The controller reports that it negotiated 4.4MB/s synch access with if my memory serves me right is the same as the 2740 did. Any one seen this? Anything I can do to figure this out? Justin? Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks.pr.mcs.net (home-home) From owner-freebsd-scsi Thu Jan 9 13:14:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA21910 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 13:14:52 -0800 (PST) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA21905 for ; Thu, 9 Jan 1997 13:14:49 -0800 (PST) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.6.13/8.6.9) with ESMTP id NAA21760 for ; Thu, 9 Jan 1997 13:14:42 -0800 Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.4/8.6.12) with SMTP id NAA05248 for ; Thu, 9 Jan 1997 13:14:41 -0800 (PST) Date: Thu, 9 Jan 1997 13:14:41 -0800 (PST) From: Chris Timmons To: freebsd-scsi@freebsd.org Subject: RELENG_2_2, ahc3940UW, XP34300W, /kernel: Queue Full Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running a RELENG_2_2 kernel from about 1/5 on a pro/200 (asus p6np5) with a 3940UW, two XP34300W quantums and and NEC 8x cdrom. I have an adaptec internal wide cable with active termination and the bus looks like this: a: ahc3940UW, xp34300W, xp34300W, narrow nec cdrom, active term. b: (no devices) I was thinking that with the active terminator on the cable I could safely leave the narrow CD player at the end. Anyways, I have two questions: When the system boots, I see this boot message while the unused B channel of the 3940 is probed: ahc1 rev 0 int a irq 10 on pci1:5 ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs ahc1 waiting for scsi devices to settle ahc1: Someone reset channel A ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ ??? The second and more worriesome question has to do with what happened last night when Amanda started reading the disks during backup. After all of the scanning work, Amanda did a small level 1 backup of a small partition, during which I got this: opus /kernel: Queue Full opus /kernel: sd1(ahc0:1:0): timed out in datain phase, SCSISIGI == 0x44 opus /kernel: SEQADDR == 0x5a opus /kernel: sd0(ahc0:0:0): abort message in message buffer opus /kernel: sd0(ahc0:0:0): timed out in datain phase, SCSISIGI == 0x54 opus /kernel: SEQADDR == 0x5a opus /kernel: ahc0: Issued Channel A Bus Reset. 2 SCBs aborted opus /kernel: sd1(ahc0:1:0): UNIT ATTENTION asc:29,2 opus /kernel: , retries:3 opus /kernel: sd0(ahc0:0:0): UNIT ATTENTION asc:29,2 opus /kernel: , retries:3 I have lots of 3940's and atlas-II drives, including another releng_2_2 system that have never ever burped, so I am assuming this problem has to do with my termination scheme (which seemed like a good idea at the time with that big wide terminator coming after the narrow CD player.) Comments? (other than gassing up the LART or whatever :) -Chris From owner-freebsd-scsi Thu Jan 9 16:16:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA00234 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 16:16:04 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA00195; Thu, 9 Jan 1997 16:15:59 -0800 (PST) Message-Id: <199701100015.QAA00195@freefall.freebsd.org> To: Lars Fredriksen cc: scsi@freebsd.org Subject: Re: Adaptech 2940/44W and older drives In-reply-to: Your message of "Thu, 09 Jan 1997 13:14:04 CST." <199701091914.NAA17382@Mercury.mcs.net> Date: Thu, 09 Jan 1997 16:15:59 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a known problem. Please refer to the SCSI list archives for the other reports of this problem. I hope to fix this, and a few other problems with the driver before 2.2R ships, but as my life is a little hectic for the moment, don't expect immediate movement on this issue. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Jan 9 16:17:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA00299 for freebsd-scsi-outgoing; Thu, 9 Jan 1997 16:17:22 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA00285; Thu, 9 Jan 1997 16:17:13 -0800 (PST) Message-Id: <199701100017.QAA00285@freefall.freebsd.org> To: Chris Timmons cc: freebsd-scsi@freebsd.org Subject: Re: RELENG_2_2, ahc3940UW, XP34300W, /kernel: Queue Full In-reply-to: Your message of "Thu, 09 Jan 1997 13:14:41 PST." Date: Thu, 09 Jan 1997 16:17:13 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >ahc1 rev 0 int a irq 10 on pci1:5 >ahc1: aic7880 Wide Channel B, SCSI Id=7, 16 SCBs >ahc1 waiting for scsi devices to settle > >ahc1: Someone reset channel A >^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ >??? I think this bug is fixed in current. >The second and more worriesome question has to do with what happened last >night when Amanda started reading the disks during backup. After all of >the scanning work, Amanda did a small level 1 backup of a small partition, >during which I got this: > >opus /kernel: Queue Full >opus /kernel: sd1(ahc0:1:0): timed out in datain phase, SCSISIGI == 0x44 >opus /kernel: SEQADDR == 0x5a >opus /kernel: sd0(ahc0:0:0): abort message in message buffer >opus /kernel: sd0(ahc0:0:0): timed out in datain phase, SCSISIGI == 0x54 >opus /kernel: SEQADDR == 0x5a >opus /kernel: ahc0: Issued Channel A Bus Reset. 2 SCBs aborted >opus /kernel: sd1(ahc0:1:0): UNIT ATTENTION asc:29,2 >opus /kernel: , retries:3 >opus /kernel: sd0(ahc0:0:0): UNIT ATTENTION asc:29,2 >opus /kernel: , retries:3 I know about this problem and am attempting to fix it for 2.2R. It may be a few weeks before I have a fix though. >-Chris > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Jan 10 03:19:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA06498 for freebsd-scsi-outgoing; Fri, 10 Jan 1997 03:19:57 -0800 (PST) Received: from shadows.aeon.net (bsdscsi@shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA06493 for ; Fri, 10 Jan 1997 03:19:53 -0800 (PST) Received: (from bsdscsi@localhost) by shadows.aeon.net (8.8.4/8.8.3) id NAA27406; Fri, 10 Jan 1997 13:17:22 +0200 (EET) From: mika ruohotie Message-Id: <199701101117.NAA27406@shadows.aeon.net> Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 10 Jan 1997 13:17:22 +0200 (EET) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199701091541.CAA27446@genesis.atrad.adelaide.edu.au> from Michael Smith at "Jan 10, 97 02:11:48 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > No! You're not paying attention 8) You want an _FX_ chipset > motherboard, specifically for the improved CPU-memory bandwidth. Even > the VX with all its corners cut is faster than the HX. Don't kid pardon? > yourself that the extra few MHz of PCI speed will make major > differences to your performance, particularly if it means that > you sacrifice CPU-memory bandwidth to get it. > > Spend some time looking for the real bottlenecks in the system rather > than trying to open paths that are already adequately wide. > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ is there something not commonly known here? since what i've heard tells that 430FX is much slower than VX and that HX is faster than either one when running at the "top" speed... there's relatively long memory and clock cycle stuff behind this... mickey From owner-freebsd-scsi Fri Jan 10 07:36:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA16106 for freebsd-scsi-outgoing; Fri, 10 Jan 1997 07:36:32 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA16100 for ; Fri, 10 Jan 1997 07:36:28 -0800 (PST) Received: from plato.salford.ac.uk (plato.salford.ac.uk [146.87.1.3]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id HAA17577 for ; Fri, 10 Jan 1997 07:36:22 -0800 (PST) Received: (qmail 5222 invoked by uid 141); 10 Jan 1997 15:35:11 -0000 Date: Fri, 10 Jan 1997 15:35:11 +0000 (GMT) From: Mark Powell To: Michael Smith cc: Mark Powell , MSP@owellai.ssa, MSPowellaiss@alforda.cuk Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? In-Reply-To: <199701091208.WAA26952@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 9 Jan 1997, Michael Smith wrote: > Mark Powell stands accused of saying: > > I don't think the NCR 53c875 is supported at all, just 810 & 825 :( > > The FreeBSD/NetBSD NCR driver supports the 810, 815, 820, 825, 860 and > 875. Is that in all FreeBSD's? I'm running 2.2-RELEASE, is it in there? Cheers. Mark Powell - Unix Information Officer - Clifford Whitworth Building A.I.S., University of Salford, Salford, Manchester, UK. Tel: +44 161 745 5936 Fax: +44 161 736 3596 Email: mark@salford.ac.uk finger mark@ucsalf.ac.uk (for PGP key) Home Page From owner-freebsd-scsi Fri Jan 10 08:57:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA19594 for freebsd-scsi-outgoing; Fri, 10 Jan 1997 08:57:38 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA19589 for ; Fri, 10 Jan 1997 08:57:35 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2-biteme) with ESMTP id KAA01414 for ; Fri, 10 Jan 1997 10:57:25 -0600 (CST) Received: from Venus.mcs.net (jonas@Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA14874; Fri, 10 Jan 1997 10:57:18 -0600 (CST) Received: (from jonas@localhost) by Venus.mcs.net (8.8.2/8.8.2) id KAA19460; Fri, 10 Jan 1997 10:57:17 -0600 (CST) From: Lars Jonas Olsson Message-Id: <199701101657.KAA19460@Venus.mcs.net> Subject: HP 6020i CD writer supported? To: scsi@freebsd.org Date: Fri, 10 Jan 1997 10:57:16 -0600 (CST) Cc: jonas@mcs.net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've read the worm.c source and it seems to support HP4020i. This doesn't seem available anymore though. I found the HP6020i (6x read, 2x write) for ~$550. Has this one been tested? It seems the chances of it working should be pretty good, right? Any other recommendations? Jonas From owner-freebsd-scsi Fri Jan 10 13:03:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02686 for freebsd-scsi-outgoing; Fri, 10 Jan 1997 13:03:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA02648 for ; Fri, 10 Jan 1997 13:02:40 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA07634; Fri, 10 Jan 1997 22:02:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA24256; Fri, 10 Jan 1997 21:35:54 +0100 (MET) Message-ID: Date: Fri, 10 Jan 1997 21:35:54 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: mark@salford.ac.uk (Mark Powell) Cc: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Subject: Re: Can the P/I-P55T2P4 be overclocked? In other words does it support 75 and 83MHz bus speeds? References: <199701091208.WAA26952@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Mark Powell on Jan 10, 1997 15:35:11 +0000 Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Mark Powell wrote: > > The FreeBSD/NetBSD NCR driver supports the 810, 815, 820, 825, 860 and > > 875. > > Is that in all FreeBSD's? Yes. > I'm running 2.2-RELEASE, is it in there? Oh, so you're ahead of time! :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jan 10 13:10:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA03246 for freebsd-scsi-outgoing; Fri, 10 Jan 1997 13:10:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA03172 for ; Fri, 10 Jan 1997 13:09:24 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA07700; Fri, 10 Jan 1997 22:06:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA24304; Fri, 10 Jan 1997 21:48:19 +0100 (MET) Message-ID: Date: Fri, 10 Jan 1997 21:48:19 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: jonas@mcs.net (Lars Jonas Olsson) Cc: scsi@freebsd.org Subject: Re: HP 6020i CD writer supported? References: <199701101657.KAA19460@Venus.mcs.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701101657.KAA19460@Venus.mcs.net>; from Lars Jonas Olsson on Jan 10, 1997 10:57:16 -0600 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Lars Jonas Olsson wrote: > I've read the worm.c source and it seems to support HP4020i. This > doesn't seem available anymore though. I found the HP6020i (6x read, > 2x write) for ~$550. Has this one been tested? It seems the chances of > it working should be pretty good, right? Any other recommendations? Chances are good, yes, but i haven't heard from anybody who might have tested it yet. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jan 10 13:39:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA04979 for freebsd-scsi-outgoing; Fri, 10 Jan 1997 13:39:47 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA04973; Fri, 10 Jan 1997 13:39:34 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-43.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA01723 (5.67b/IDA-1.5); Fri, 10 Jan 1997 22:39:19 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id WAA06293; Fri, 10 Jan 1997 22:39:11 +0100 (CET) Message-Id: Date: Fri, 10 Jan 1997 22:39:11 +0100 From: se@freebsd.org (Stefan Esser) To: kelly@fsl.noaa.gov (Sean Kelly) Cc: se@freebsd.org (Stefan Esser), scsi@freebsd.org Subject: Re: Problem appears from migration from bt0 to ncr0 References: <32D125EB.4E3F@fsl.noaa.gov> <32D15EA6.47A0@fsl.noaa.gov> <32D3C8B1.EDA@fsl.noaa.gov> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 In-Reply-To: <32D3C8B1.EDA@fsl.noaa.gov>; from Sean Kelly on Jan 8, 1997 09:17:53 -0700 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 8, kelly@fsl.noaa.gov (Sean Kelly) wrote: > Stefan: > > Here're the results so far with the DFRS drive of doom. > > First, with the system running 2.1.5R, I modified /sys/scsi/sd.c and > changed xs->timeout from 10000 to 80000. Later that evening, the DFRS > went to sleep but the same problem occurred as before. Perhaps I > should've used a higher value? (And if what I changed wasn't correct, > do let me know.) Guess you were right. You can try with SCSI debug enabled, see /sys/scsi/scsi_debug.h ... Then you'll know which command is aborted. But this will significantly slow down your system. The "scsi" command allows to set the debug level, if debug code is compiled into the kernel. You'll need lots of disk space for the log messages, though (and you should write them to some other drive ...) Sorry, I can't spend much time on this problem, I just don't HAVE that time :( > Next, I upgraded to 2.2-BETA, and ran the system with an unmodified > sd.c. This time, the system locked up (!) when the DFRS went to sleep. > The console displayed: > > ncr0: SCSI phase error fixup: CCB already dequeued (...) Yes, this is the result of the NCR being locked by the unresponsive drive for too long. I should make the recovery more robust, but I do not have a drive that exhibits such a problem, and it is not so easy to reproduce and test, on my system. (I do not want to loose any of my work because of such a test, and do not want to buy a DFRS just to have a drive to play with ...) > and the scrollback buffer worked, and I could enter my account name at > the login prompt. But nothing else; as if any activity requiring the > disk just hung. I hit the reset switch. This is not an acceptable outcome. But I can't do much about it, currently. Sorry ... > I still need to try changing the xs->timeout in the 2.2-BETA kernel and > forcing the tape drives to be async in /etc/rc.local. You may try with all devices async, since one of the inconsistencies that might have been caused by the controller reset are in the transfer rates assumed by both sides. Regards, STefan