From owner-freebsd-scsi Sun Sep 26 9:39: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 15CB514BC7 for ; Sun, 26 Sep 1999 09:38:56 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 01EA51CA7; Mon, 27 Sep 1999 00:38:55 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com Cc: Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-reply-to: Your message of "Sat, 25 Sep 1999 13:35:02 MST." Date: Mon, 27 Sep 1999 00:38:55 +0800 From: Peter Wemm Message-Id: <19990926163856.01EA51CA7@overcee.netplex.com.au> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > > I'd like to thank Gerard for doing this- I believe it will be important > for us to test this thoroughly, and if I hadn't been 257 tags overflowed > myself, I'd be doing it now.... I noticed some reasonably priced 53C896 cards on a price list a few days ago, I think I'll try and get one on tuesday (long weekend here). Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 26 17: 7:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 5CAD914BEF; Sun, 26 Sep 1999 17:07:11 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8CAF81CC4; Mon, 27 Sep 1999 08:07:10 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: The Hermit Hacker Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: swap_pager: indefinite wait buffer In-reply-to: Your message of "Fri, 24 Sep 1999 11:15:38 -0300." Date: Mon, 27 Sep 1999 08:07:10 +0800 From: Peter Wemm Message-Id: <19990927000710.8CAF81CC4@overcee.netplex.com.au> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Hermit Hacker wrote: > > I'm assuming a bad drive here, but any way of determining whch based on > the 'device' entry? > > Sep 24 04:22:07 hub /kernel: swap_pager: indefinite wait buffer: device: 0x20 439 > , blkno: 2704, size: 4096 Major 4, minor 0x20039 The bit layout is: 0xmmmmMMmm where 'm' is a part of the minor, M = major. Yes, there is a hole in the minor. Here's an example, you'll have to search for it in full. 0 brw-r----- 1 root operator 4, 0x0002001a Feb 20 1999 /dev/da3s1 Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 26 21:23:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 3A9E014F54 for ; Sun, 26 Sep 1999 21:23:41 -0700 (PDT) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19990927042341.MDII5795.mail.rdc2.on.home.com@mired.eh.local>; Sun, 26 Sep 1999 21:23:41 -0700 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id AAA00791; Mon, 27 Sep 1999 00:23:40 -0400 (EDT) (envelope-from kws) To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 References: From: Kevin Street Date: 27 Sep 1999 00:23:39 -0400 In-Reply-To: Gerard Roudier's message of "Sat, 25 Sep 1999 22:45:15 +0200 (MET DST)" Message-ID: <87puz5q8xg.fsf@mired.eh.local> Lines: 48 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier writes: > I have made available revision 0.3.0 of the sym_hipd driver for > FreeBSD-CAM. This driver version behaves correctly on QUEUE FULL > condition and has been rock solid for me. > Latest revision: > sym-0.3.0-1990925 I decided to give this a try on an ASUS SC-875 (since I don't have an 896) to see what it would do. It's stable and seems to give similar performance to the ncr driver on make buildworld's (src on scsi, obj on ide). It's about 30% slower than the ncr driver with dump however. I was dumping from file systems on da1 to files on da0 (a syquest syjet removable scsi). The sym driver gave me about 1125 - 1250 KBytes per second throughput. The ncr driver gave about 1550 - 1725 KBytes per second as reported by dump. I tried these dumps a couple of times each with similar numbers. These are medium size (400M - 750M) dumps. Small file systems (eg root) were closer in speed with a slight edge to the ncr. Info from dmesg: ncr0: irq 19 at device 9.0 on pci0 or for the sym: sym0: <875> irq 19 at device 9.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, parity checking sym0: open drain IRQ line driver, using on-chip SRAM ... sym0: Downloading SCSI SCRIPTS. (noperiph:sym0:0:-1:-1): SCSI bus reset delivered. changing root device to da1s1a da0 at sym0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1430MB (2929800 512 byte sectors: 255H 63S/T 182C) da1 at sym0 bus 0 target 8 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) -- Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 26 23:50:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 130BE14F76 for ; Sun, 26 Sep 1999 23:50:42 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA10334; Mon, 27 Sep 1999 08:50:30 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA03603; Mon, 27 Sep 1999 08:45:45 +0200 (MET DST) (envelope-from j) Message-ID: <19990927084545.07258@uriah.heep.sax.de> Date: Mon, 27 Sep 1999 08:45:45 +0200 From: J Wunsch To: scsi@freebsd.org Cc: Rick Knebel , "Chris D. Faulhaber" Subject: Re: scanner and scsi Reply-To: Joerg Wunsch References: <19990925083746.A310@rknebel.uplink.net> <199909252303.RAA24089@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199909252303.RAA24089@panzer.kdm.org>; from Kenneth D. Merry on Sat, Sep 25, 1999 at 05:03:17PM -0600 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > Are you sure that xscanimage is looking for a pass device? Is xscanimage > in the ports tree at all? [...] yes, and yes. > Some scanner utilities want a processor target (pt) device. You > might try putting 'device pt0' in your kernel config file (and make > sure you have /dev/pt0 as well). The question is whether the device would be recognized as `processor target'. The boot messages didn't seem to indicate this. SANE is also able to use pt devices (and i actually prefer this variant), all you have to do is something like: $ cat /usr/local/etc/sane.d/hp.conf HP /dev/pt0 option connect-device ^^^^^^^^^^^^^^ (The default is `connect-scsi'.) -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 0: 2:41 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 5210014E27 for ; Mon, 27 Sep 1999 00:02:36 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id BAA35068; Mon, 27 Sep 1999 01:02:22 -0600 (MDT) (envelope-from ken) Message-Id: <199909270702.BAA35068@panzer.kdm.org> Subject: Re: scanner and scsi In-Reply-To: <19990927084545.07258@uriah.heep.sax.de> from J Wunsch at "Sep 27, 1999 08:45:45 am" To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Date: Mon, 27 Sep 1999 01:02:22 -0600 (MDT) Cc: scsi@FreeBSD.ORG, rknebel@uplink.net (Rick Knebel), jedgar@fxp.org (Chris D. Faulhaber) 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 J Wunsch wrote... > As Kenneth D. Merry wrote: > > > Are you sure that xscanimage is looking for a pass device? Is xscanimage > > in the ports tree at all? [...] > > yes, and yes. Where in the ports tree? I can't find it. I can find SANE, but not anything called xscanimage. > > Some scanner utilities want a processor target (pt) device. You > > might try putting 'device pt0' in your kernel config file (and make > > sure you have /dev/pt0 as well). > > The question is whether the device would be recognized as `processor > target'. The boot messages didn't seem to indicate this. SANE is > also able to use pt devices (and i actually prefer this variant), all > you have to do is something like: The reason his scanner wasn't recognized as a pt device is because he didn't put the pt device in his kernel. He sent me private mail later saying that he got things working, probably by putting the pt device in his kernel. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 11:59:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id A94D11542C for ; Mon, 27 Sep 1999 11:59:43 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-99-118.villette.club-internet.fr [194.158.99.118]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA28399; Mon, 27 Sep 1999 20:59:30 +0200 (MET DST) Date: Mon, 27 Sep 1999 21:20:23 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Kevin Street Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <87puz5q8xg.fsf@mired.eh.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, You test is not serious. If you only can provide 1.5MB/second throughput for a benchmark of SCSI driver, please go away or make comparison with an AHA 1542. I consider your posting to be a bad joke and hope that it is not intentionnaly just bad taste.=20 G=E9rard. On 27 Sep 1999, Kevin Street wrote: > Gerard Roudier writes: >=20 > > I have made available revision 0.3.0 of the sym_hipd driver for > > FreeBSD-CAM. This driver version behaves correctly on QUEUE FULL > > condition and has been rock solid for me.=20 >=20 > > Latest revision: > > sym-0.3.0-1990925 >=20 > I decided to give this a try on an ASUS SC-875 (since I don't have an > 896) to see what it would do. It's stable and seems to give similar=20 > performance to the ncr driver on make buildworld's (src on scsi, obj on i= de). =20 >=20 > It's about 30% slower than the ncr driver with dump however. =20 > I was dumping from file systems on da1 to files on da0 > (a syquest syjet removable scsi). >=20 > The sym driver gave me about 1125 - 1250 KBytes per second throughput. > The ncr driver gave about 1550 - 1725 KBytes per second as reported by=20 > dump. I tried these dumps a couple of times each with similar > numbers. These are medium size (400M - 750M) dumps. Small file systems= =20 > (eg root) were closer in speed with a slight edge to the ncr. > =20 > Info from dmesg: >=20 > ncr0: irq 19 at device 9.0 on pci0 >=20 > or for the sym: >=20 > sym0: <875> irq 19 at device 9.0 on pci0 > sym0: Symbios NVRAM, ID 7, Fast-20, parity checking > sym0: open drain IRQ line driver, using on-chip SRAM > ... > sym0: Downloading SCSI SCRIPTS. > (noperiph:sym0:0:-1:-1): SCSI bus reset delivered. > changing root device to da1s1a > da0 at sym0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device=20 > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > da0: 1430MB (2929800 512 byte sectors: 255H 63S/T 182C) > da1 at sym0 bus 0 target 8 lun 0 > da1: Fixed Direct Access SCSI-3 device=20 > da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing = Enabled > da1: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) >=20 > --=20 > Kevin Street > street@iname.com >=20 >=20 > 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 Mon Sep 27 12:56:32 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 A94D51565E for ; Mon, 27 Sep 1999 12:56:16 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA38933; Mon, 27 Sep 1999 13:56:09 -0600 (MDT) (envelope-from ken) Message-Id: <199909271956.NAA38933@panzer.kdm.org> Subject: Re: sym driver 0.3.0 In-Reply-To: from Gerard Roudier at "Sep 27, 1999 09:20:23 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Mon, 27 Sep 1999 13:56:09 -0600 (MDT) Cc: street@iname.com (Kevin Street), 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 [ reply moved to the bottom, where replies belong ] Gerard Roudier wrote... > On 27 Sep 1999, Kevin Street wrote: > > Gerard Roudier writes: > > > > > I have made available revision 0.3.0 of the sym_hipd driver for > > > FreeBSD-CAM. This driver version behaves correctly on QUEUE FULL > > > condition and has been rock solid for me. > > > > > Latest revision: > > > sym-0.3.0-1990925 > > > > I decided to give this a try on an ASUS SC-875 (since I don't have an > > 896) to see what it would do. It's stable and seems to give similar > > performance to the ncr driver on make buildworld's (src on scsi, obj on ide). > > > > It's about 30% slower than the ncr driver with dump however. > > I was dumping from file systems on da1 to files on da0 > > (a syquest syjet removable scsi). > > > > The sym driver gave me about 1125 - 1250 KBytes per second throughput. > > The ncr driver gave about 1550 - 1725 KBytes per second as reported by > > dump. I tried these dumps a couple of times each with similar > > numbers. These are medium size (400M - 750M) dumps. Small file systems > > (eg root) were closer in speed with a slight edge to the ncr. [ ... ] > You test is not serious. If you only can provide 1.5MB/second throughput > for a benchmark of SCSI driver, please go away or make comparison with an > AHA 1542. I consider your posting to be a bad joke and hope that it is not > intentionnaly just bad taste. I don't think it's a joke at all. dump is a reasonable real-world benchmark -- it's something that people run every day. In any case, the issue with dump isn't necessarily the throughput, but rather the number of transactions. dump is notoriously slow, for a variety of reasons. It tends to involve a high number of seeks. Here's an example from the first stage of a dump off of a ccd array consisting of 2 18G Seagate Cheetah II's: ccd0 da0 da1 da2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 8.00 994 7.76 8.00 49 0.38 8.00 521 4.07 8.00 472 3.69 8.00 1010 7.89 0.00 0 0.00 8.00 487 3.81 8.00 523 4.08 8.00 1012 7.91 0.00 0 0.00 8.00 489 3.82 8.00 523 4.08 8.00 1015 7.93 0.00 0 0.00 8.00 492 3.84 8.00 523 4.08 8.00 1015 7.93 0.00 0 0.00 8.00 492 3.84 8.00 523 4.08 8.00 1009 7.88 0.00 0 0.00 8.00 486 3.80 8.00 523 4.08 8.00 980 7.66 0.00 0 0.00 8.00 473 3.70 8.00 507 3.96 8.00 1008 7.88 0.00 0 0.00 8.00 487 3.81 8.00 521 4.07 8.00 1008 7.88 0.00 0 0.00 8.00 491 3.84 8.00 517 4.04 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 8.00 994 7.77 8.00 6 0.05 8.00 479 3.74 8.00 515 4.02 8.00 1014 7.92 0.00 0 0.00 8.00 491 3.84 8.00 523 4.08 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 8.00 999 7.81 8.00 2 0.02 8.00 483 3.78 8.00 516 4.03 8.00 985 7.70 1.67 3 0.00 8.00 475 3.71 8.00 510 3.98 8.00 987 7.71 0.00 0 0.00 8.00 479 3.74 8.00 508 3.97 8.00 995 7.77 0.00 0 0.00 8.00 481 3.76 8.00 514 4.01 8.00 988 7.72 0.00 0 0.00 8.00 477 3.73 8.00 511 3.99 ccd0 da0 da1 da2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 8.00 996 7.78 0.00 0 0.00 8.00 483 3.77 8.00 513 4.01 8.00 996 7.78 0.00 0 0.00 8.00 483 3.78 8.00 513 4.01 8.00 994 7.77 0.00 0 0.00 8.00 479 3.74 8.00 515 4.02 8.00 988 7.72 0.00 0 0.00 8.00 479 3.74 8.00 509 3.98 Now that's a fair number of transactions per second, and certainly not a bad benchmark of drive and controller performance. Later stages of the dump don't go as fast, since they don't necessarily do everything in 8K chunks. Here is sample iostat output from stage 4 of the same dump on the same system: ccd0 da0 da1 da2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 4.66 623 2.84 0.00 0 0.00 4.76 301 1.40 4.58 322 1.44 3.85 381 1.43 0.00 0 0.00 3.73 195 0.71 3.97 186 0.72 3.99 434 1.69 0.00 0 0.00 3.85 188 0.71 4.10 246 0.98 4.32 447 1.88 0.00 0 0.00 4.39 226 0.97 4.24 221 0.91 4.56 597 2.66 0.00 0 0.00 4.56 287 1.28 4.57 310 1.38 4.70 892 4.09 0.00 0 0.00 4.69 446 2.04 4.70 447 2.05 4.72 804 3.71 0.00 0 0.00 4.70 377 1.73 4.73 427 1.97 4.69 958 4.38 0.00 0 0.00 4.69 474 2.17 4.68 483 2.21 4.73 811 3.74 0.00 0 0.00 4.70 410 1.88 4.75 401 1.86 4.71 796 3.66 0.00 0 0.00 4.72 409 1.89 4.69 387 1.77 4.70 969 4.45 0.00 0 0.00 4.73 474 2.19 4.67 495 2.26 4.63 593 2.68 0.00 0 0.00 4.58 317 1.42 4.69 276 1.26 4.71 861 3.96 0.00 0 0.00 4.68 435 1.99 4.73 427 1.97 4.71 871 4.01 0.00 0 0.00 4.66 440 2.00 4.75 432 2.00 So the transaction counts vary widely, and the average throughput isn't all that great for a pair of drives that can otherwise do at least 30MB/sec together. But the number of transactions is still fairly high. I think what you may want to do is ask Kevin to give you some comparisons of iostat output from dumps with the ncr driver and dumps with the sym driver, so you can compare how many average transactions per second happen in each stage of the dump with each driver. That might shed light on whether there are any significant performance differences between the drivers. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 13:22: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id B61F2152E0 for ; Mon, 27 Sep 1999 13:21:44 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id WAA24965 for scsi@FreeBSD.ORG; Mon, 27 Sep 1999 22:21:43 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id VAA00973; Mon, 27 Sep 1999 21:58:53 +0200 (MET DST) (envelope-from j) Message-ID: <19990927215852.01119@uriah.heep.sax.de> Date: Mon, 27 Sep 1999 21:58:52 +0200 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: scanner and scsi Reply-To: Joerg Wunsch References: <19990927084545.07258@uriah.heep.sax.de> <199909270702.BAA35068@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199909270702.BAA35068@panzer.kdm.org>; from Kenneth D. Merry on Mon, Sep 27, 1999 at 01:02:22AM -0600 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > Where in the ports tree? I can't find it. I can find SANE, but not > anything called xscanimage. I don't have the scanner here at home. I think it's in `xsane'. > The reason his scanner wasn't recognized as a pt device is because > he didn't put the pt device in his kernel. Ah, OK. I think using the pt driver is better anyway, since it moves the responsibility to assemble SCSI commands into the kernel driver, where it IMHO belongs to. Alas, the sane package poorly documents the possible device and driver choices for FreeBSD... -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 15: 2:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id DE2B014FDF for ; Mon, 27 Sep 1999 15:02:45 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-168-115.villette.club-internet.fr [195.36.168.115]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA07694; Tue, 28 Sep 1999 00:02:27 +0200 (MET DST) Date: Tue, 28 Sep 1999 00:23:20 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: Kevin Street , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <199909271956.NAA38933@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I donnot want to provide too many comparisons between the ncr and the sim_hipd driver, even if I have actually done benchmarks that involve=20 the both drivers. What I can say is that I know all the pathes (C code and SCRIPTS) of the both drivers and all my testing just met my expectations. One of the great difference between the drivers is the Tps. I have posted a bit about, but it seems people are too much selective on this list, even if its traffic seem low.=20 I invite you to read my previous postings about this topic and will just=20 post the following output from iostat I got using 2 10K disk on a single=20 SYM53C896 channel (I have described the test conditions in a previous posting): (Cheetah2 LVD + DRVS LVD) tty da0 da1 da2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 1 20 4.00 3934 15.37 4.00 4098 16.01 0.00 0 0.00 2 0 24 7 = 68 0 0 4.00 4444 17.36 4.00 4466 17.44 0.00 0 0.00 4 0 53 14 = 29 0 0 4.00 4449 17.38 4.00 4460 17.42 0.00 0 0.00 4 0 53 15 = 28 0 0 4.00 4461 17.43 4.00 4460 17.42 0.00 0 0.00 3 0 56 14 = 27 0 0 4.00 4461 17.42 4.00 4462 17.43 0.00 0 0.00 3 0 52 16 = 29 0 0 4.00 4464 17.44 4.00 4466 17.45 0.00 0 0.00 3 0 54 17 = 25 0 0 4.00 4433 17.32 4.00 4466 17.45 0.00 0 0.00 4 0 52 17 = 27 0 0 4.00 4454 17.40 4.00 4465 17.44 0.00 0 0.00 2 0 54 15 = 28 0 44 4.00 3592 14.03 4.00 3485 13.62 0.00 0 0.00 4 0 39 14 = 43 0 0 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 The sym_hipd driver is also very fast using 53C875 and 895 controllers. I cannot perform CCD testings at the moment since I donnot have time enough for that, but I have some additionnal benchmarks I could flood the list with.=20 If you want results, I will try to collect some next weekend and post them. On the result above (sequential read), may-be disconnections are not so=20 frequent, but I know the reselection path of the sym_hipd driver enough=20 to claim that this path is also very fast and certainly faster than the ncr since it is just O(1) for both SCRIPTS and C code with regards to=20 the number of concurrent IOs (all that from 810A to C1010). By the way, the above result requires the command overhead (without data)= =20 to be as low as 62 micro-seconds and the ncr driver seems unable to provide a command overhead lower that _twice_ this value.=20 G=E9rard. On Mon, 27 Sep 1999, Kenneth D. Merry wrote: > [ reply moved to the bottom, where replies belong ] >=20 > Gerard Roudier wrote... > > On 27 Sep 1999, Kevin Street wrote: > > > Gerard Roudier writes: > > >=20 > > > > I have made available revision 0.3.0 of the sym_hipd driver for > > > > FreeBSD-CAM. This driver version behaves correctly on QUEUE FULL > > > > condition and has been rock solid for me.=20 > > >=20 > > > > Latest revision: > > > > sym-0.3.0-1990925 > > >=20 > > > I decided to give this a try on an ASUS SC-875 (since I don't have an > > > 896) to see what it would do. It's stable and seems to give similar= =20 > > > performance to the ncr driver on make buildworld's (src on scsi, obj = on ide). =20 > > >=20 > > > It's about 30% slower than the ncr driver with dump however. =20 > > > I was dumping from file systems on da1 to files on da0 > > > (a syquest syjet removable scsi). > > >=20 > > > The sym driver gave me about 1125 - 1250 KBytes per second throughput= =2E > > > The ncr driver gave about 1550 - 1725 KBytes per second as reported b= y=20 > > > dump. I tried these dumps a couple of times each with similar > > > numbers. These are medium size (400M - 750M) dumps. Small file syst= ems=20 > > > (eg root) were closer in speed with a slight edge to the ncr. >=20 > [ ... ] >=20 > > You test is not serious. If you only can provide 1.5MB/second throughpu= t > > for a benchmark of SCSI driver, please go away or make comparison with = an > > AHA 1542. I consider your posting to be a bad joke and hope that it is = not > > intentionnaly just bad taste.=20 >=20 > I don't think it's a joke at all. dump is a reasonable real-world > benchmark -- it's something that people run every day. >=20 > In any case, the issue with dump isn't necessarily the throughput, but > rather the number of transactions. dump is notoriously slow, for a varie= ty > of reasons. It tends to involve a high number of seeks. Here's an examp= le > from the first stage of a dump off of a ccd array consisting of 2 18G > Seagate Cheetah II's: >=20 > ccd0 da0 da1 da2 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 8.00 994 7.76 8.00 49 0.38 8.00 521 4.07 8.00 472 3.69 > 8.00 1010 7.89 0.00 0 0.00 8.00 487 3.81 8.00 523 4.08 > 8.00 1012 7.91 0.00 0 0.00 8.00 489 3.82 8.00 523 4.08 > 8.00 1015 7.93 0.00 0 0.00 8.00 492 3.84 8.00 523 4.08 > 8.00 1015 7.93 0.00 0 0.00 8.00 492 3.84 8.00 523 4.08 > 8.00 1009 7.88 0.00 0 0.00 8.00 486 3.80 8.00 523 4.08 > 8.00 980 7.66 0.00 0 0.00 8.00 473 3.70 8.00 507 3.96 > 8.00 1008 7.88 0.00 0 0.00 8.00 487 3.81 8.00 521 4.07 > 8.00 1008 7.88 0.00 0 0.00 8.00 491 3.84 8.00 517 4.04 > 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 > 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 > 8.00 994 7.77 8.00 6 0.05 8.00 479 3.74 8.00 515 4.02 > 8.00 1014 7.92 0.00 0 0.00 8.00 491 3.84 8.00 523 4.08 > 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 > 8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09 > 8.00 999 7.81 8.00 2 0.02 8.00 483 3.78 8.00 516 4.03 > 8.00 985 7.70 1.67 3 0.00 8.00 475 3.71 8.00 510 3..98 > 8.00 987 7.71 0.00 0 0.00 8.00 479 3.74 8.00 508 3.97 > 8.00 995 7.77 0.00 0 0.00 8.00 481 3.76 8.00 514 4.01 > 8.00 988 7.72 0.00 0 0.00 8.00 477 3.73 8.00 511 3.99 > ccd0 da0 da1 da2=20 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s=20 > 8.00 996 7.78 0.00 0 0.00 8.00 483 3.77 8.00 513 4.01=20 > 8.00 996 7.78 0.00 0 0.00 8.00 483 3.78 8.00 513 4.01=20 > 8.00 994 7.77 0.00 0 0.00 8.00 479 3.74 8.00 515 4.02=20 > 8.00 988 7.72 0.00 0 0.00 8.00 479 3.74 8.00 509 3.98=20 > =20 > Now that's a fair number of transactions per second, and certainly not a > bad benchmark of drive and controller performance. >=20 > Later stages of the dump don't go as fast, since they don't necessarily d= o > everything in 8K chunks. Here is sample iostat output from stage 4 of th= e > same dump on the same system: >=20 > ccd0 da0 da1 da2 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 4.66 623 2.84 0.00 0 0.00 4.76 301 1.40 4.58 322 1.44 > 3.85 381 1.43 0.00 0 0.00 3.73 195 0.71 3.97 186 0.72 > 3.99 434 1.69 0.00 0 0.00 3.85 188 0.71 4.10 246 0.98 > 4.32 447 1.88 0.00 0 0.00 4.39 226 0.97 4.24 221 0.91 > 4.56 597 2.66 0.00 0 0.00 4.56 287 1.28 4.57 310 1.38 > 4.70 892 4.09 0.00 0 0.00 4.69 446 2.04 4.70 447 2.05 > 4.72 804 3.71 0.00 0 0.00 4.70 377 1.73 4.73 427 1.97 > 4.69 958 4.38 0.00 0 0.00 4.69 474 2.17 4.68 483 2.21 > 4.73 811 3.74 0.00 0 0.00 4.70 410 1.88 4.75 401 1.86 > 4.71 796 3.66 0.00 0 0.00 4.72 409 1.89 4.69 387 1.77 > 4.70 969 4.45 0.00 0 0.00 4.73 474 2.19 4.67 495 2.26 > 4.63 593 2.68 0.00 0 0.00 4.58 317 1.42 4.69 276 1.26 > 4.71 861 3.96 0.00 0 0.00 4.68 435 1.99 4.73 427 1.97 > 4.71 871 4.01 0.00 0 0.00 4.66 440 2.00 4.75 432 2.00 >=20 > So the transaction counts vary widely, and the average throughput isn't > all that great for a pair of drives that can otherwise do at least 30MB/s= ec > together. But the number of transactions is still fairly high. >=20 > I think what you may want to do is ask Kevin to give you some comparisons > of iostat output from dumps with the ncr driver and dumps with the sym > driver, so you can compare how many average transactions per second happe= n > in each stage of the dump with each driver. That might shed light on > whether there are any significant performance differences between the > drivers. >=20 > Ken > --=20 > Kenneth Merry > ken@kdm.org >=20 >=20 > 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 Mon Sep 27 15:31:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id 6F2A514DE3 for ; Mon, 27 Sep 1999 15:31:17 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-168-115.villette.club-internet.fr [195.36.168.115]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA16560; Tue, 28 Sep 1999 00:30:58 +0200 (MET DST) Date: Tue, 28 Sep 1999 00:51:47 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Kenneth D. Merry" Cc: Kevin Street , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <199909271956.NAA38933@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 27 Sep 1999, Kenneth D. Merry wrote: > ccd0 da0 da1 da2 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 8.00 994 7.76 8.00 49 0.38 8.00 521 4.07 8.00 472 3.69 > 8.00 1010 7.89 0.00 0 0.00 8.00 487 3.81 8.00 523 4.08 > 8.00 1012 7.91 0.00 0 0.00 8.00 489 3.82 8.00 523 4.08 This sym_hipd driver can perform at least 5 times the above number of 8K transactions per second on 1 LVD BUS given appropriate hard disks (even if reselections are used). So, such a poor testing is inappropriate for the sym_hipd driver that would absolutely not be the bottleneck.=20 (Btw, using a 875 the sym_hipd driver should be able to perform about=20 4 times the above Tps given appripriate hard disks) > Now that's a fair number of transactions per second, and certainly not a > bad benchmark of drive and controller performance. >=20 > Later stages of the dump don't go as fast, since they don't necessarily d= o > everything in 8K chunks. Here is sample iostat output from stage 4 of th= e > same dump on the same system: >=20 > ccd0 da0 da1 da2 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 4.66 623 2.84 0.00 0 0.00 4.76 301 1.40 4.58 322 1.44 > 3.85 381 1.43 0.00 0 0.00 3.73 195 0.71 3.97 186 0.72 > 3.99 434 1.69 0.00 0 0.00 3.85 188 0.71 4.10 246 0.98 > 4.32 447 1.88 0.00 0 0.00 4.39 226 0.97 4.24 221 0.91 This one is still inadequate. > So the transaction counts vary widely, and the average throughput isn't > all that great for a pair of drives that can otherwise do at least 30MB/s= ec > together. But the number of transactions is still fairly high. >=20 > I think what you may want to do is ask Kevin to give you some comparisons > of iostat output from dumps with the ncr driver and dumps with the sym > driver, so you can compare how many average transactions per second happe= n > in each stage of the dump with each driver. That might shed light on > whether there are any significant performance differences between the > drivers. I will not ask anything, but Kevin can post anything he wants, and I will reply to him. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 15:36:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (Postfix) with ESMTP id AE90F14E64 for ; Mon, 27 Sep 1999 15:36:13 -0700 (PDT) (envelope-from pantzer@speedy.ludd.luth.se) Received: from speedy.ludd.luth.se (pantzer@speedy.ludd.luth.se [130.240.16.164]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id XAA11345; Mon, 27 Sep 1999 23:36:09 +0100 Message-Id: <199909272236.XAA11345@zed.ludd.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: Message from Gerard Roudier of "Mon, 27 Sep 1999 21:20:23 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Sep 1999 00:36:08 +0200 From: Mattias Pantzare Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > You test is not serious. If you only can provide 1.5MB/second throughpu= t > for a benchmark of SCSI driver, please go away or make comparison with = an > AHA 1542. I consider your posting to be a bad joke and hope that it is = not > intentionnaly just bad taste. = Why is it not serious?? A SCSI driver has to be fast even for slow device= s = even if it can drive very fast devices. It is more important to be fast = on slow devices as those are the most likly to be a problem! 30% is a real problem, and a mixture of slow and fast devices on the same= SCSI = bus is common. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 15:49:57 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 1EB5E14C21 for ; Mon, 27 Sep 1999 15:49:53 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id QAA12387; Mon, 27 Sep 1999 16:39:16 -0600 (MDT) Date: Mon, 27 Sep 1999 16:39:16 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199909272239.QAA12387@narnia.plutotech.com> To: Gerard Roudier Cc: scsi@FreeBSD.org Subject: Re: sym driver 0.3.0 X-Newsgroups: pluto.freebsd.scsi 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 In article you wrote: > > > On Mon, 27 Sep 1999, Kenneth D. Merry wrote: > >> ccd0 da0 da1 da2 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 8.00 994 7.76 8.00 49 0.38 8.00 521 4.07 8.00 472 3.69 >> 8.00 1010 7.89 0.00 0 0.00 8.00 487 3.81 8.00 523 4.08 >> 8.00 1012 7.91 0.00 0 0.00 8.00 489 3.82 8.00 523 4.08 > > This sym_hipd driver can perform at least 5 times the above number of 8K > transactions per second on 1 LVD BUS given appropriate hard disks (even if > reselections are used). So, such a poor testing is inappropriate for the > sym_hipd driver that would absolutely not be the bottleneck. It is a non-sequential load where we are seek bound, so perhaps the system or drive or driver is behaving in ways that you don't expect. I certainly find it puzzling that the ncr driver handles this non-sequential load faster than the sim_hipd driver since I know that your driver's architecture is superior. I could run some SCSI bus traces if these would be helpful. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 17:23: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp.snet.net (smtp.snet.net [204.60.6.55]) by hub.freebsd.org (Postfix) with ESMTP id 04500153F9 for ; Mon, 27 Sep 1999 17:23:06 -0700 (PDT) (envelope-from chf@bear.com) Received: from bear.com (dnbr-sh7-port45.snet.net [204.60.215.45]) by smtp.snet.net (8.9.3/8.9.3/SNET-bmx-1.3/D-1.7/O-1.6) with ESMTP id UAA24719 for ; Mon, 27 Sep 1999 20:23:04 -0400 (EDT) Message-ID: <37F00AB8.A9BDF18C@bear.com> Date: Mon, 27 Sep 1999 20:24:25 -0400 From: chf-SNET X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: HP Vectra UX with onboard amd 53c974 scsi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've got the above system. It works fine with 2.2.7 and is reported as: amd0 rev 2 int a irq 10 on pci 0:4:0 Will/is this supported in 3.3R? It is not detected in 3.2R boot floppy. I have tried the patch in UserConfig of setting eisa to 12. Thanks for any help! Charlie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 27 18:52:19 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 89EE714DDF for ; Mon, 27 Sep 1999 18:52:16 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id TAA41196; Mon, 27 Sep 1999 19:52:13 -0600 (MDT) (envelope-from ken) Message-Id: <199909280152.TAA41196@panzer.kdm.org> Subject: Re: HP Vectra UX with onboard amd 53c974 scsi In-Reply-To: <37F00AB8.A9BDF18C@bear.com> from chf-SNET at "Sep 27, 1999 08:24:25 pm" To: chf@bear.com (chf-SNET) Date: Mon, 27 Sep 1999 19:52:13 -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 chf-SNET wrote... > I've got the above system. It works fine with 2.2.7 and is reported as: > > amd0 rev 2 int a irq 10 on pci 0:4:0 > > Will/is this supported in 3.3R? It is not detected in 3.2R boot floppy. There was no driver for the AMD 53c974 chips in 3.2. There is a driver in 3.3, but it is an unadvertised feature, since it still needs a little error recovery work. In any case, download the 3.3 boot floppy and see if it works for you. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 28 4:49:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 2656A1547D for ; Tue, 28 Sep 1999 04:49:42 -0700 (PDT) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19990928114942.ECCN5795.mail.rdc2.on.home.com@mired.eh.local> for ; Tue, 28 Sep 1999 04:49:42 -0700 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id XAA01197; Mon, 27 Sep 1999 23:40:37 -0400 (EDT) (envelope-from kws) To: "Kenneth D. Merry" Cc: groudier@club-internet.fr (Gerard Roudier), scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 References: <199909271956.NAA38933@panzer.kdm.org> From: Kevin Street Date: 27 Sep 1999 23:40:37 -0400 In-Reply-To: "Kenneth D. Merry"'s message of "Mon, 27 Sep 1999 13:56:09 -0600 (MDT)" Message-ID: <874sgfog96.fsf@mired.eh.local> Lines: 88 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" writes: > Gerard Roudier wrote... > > You test is not serious. If you only can provide 1.5MB/second throughput > > for a benchmark of SCSI driver, please go away or make comparison with an > > AHA 1542. I consider your posting to be a bad joke and hope that it is not > > intentionnaly just bad taste. This original hasn't made it to me yet so I don't have all the context. If this comment by Gerard was aimed at me, then my response is: I'm assuming that you intended the sym driver to be used for real applications on real machines. If its only purpose is to run benchmarks, then let me know that and I will go away. > I think what you may want to do is ask Kevin to give you some comparisons > of iostat output from dumps with the ncr driver and dumps with the sym > driver, ... I've done a few more tests. I tried to see the effect that the slow Syquest drive is having. When I dump to an IDE drive then the sym driver is faster than the ncr by 15-20%. But when I dump to the Syquest, then the interference slows down the sym driver more than the ncr. Here's what I got from 8 test runs of dump. dump from da1 to ad0 (IBM SCSI to WD IDE) time KB/sec ncr 246 1764 ncr 250 1736 sym 211 2056 sym 209 2076 dump from da1 to da0 (IBM SCSI to Syjet SCSI) time KB/sec ncr 275 1578 ncr 277 1566 sym 335 1295 sym 336 1291 Looking at iostat shows dump pushing 64KB blocks at the Syquest which is almost keeping up. It gets behind occasionally and the da1 transfers stop until da0 catches up. With the ncr driver it looks like this: tty da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 30 64.00 24 1.49 4.75 265 1.23 1 0 5 2 92 0 30 64.00 25 1.55 4.71 219 1.01 1 0 2 1 97 0 30 64.00 23 1.42 0.00 0 0.00 0 0 0 0100 0 30 64.00 25 1.55 0.00 0 0.00 0 0 0 0 99 0 30 53.92 25 1.30 3.56 275 0.96 1 0 6 1 92 0 30 64.00 25 1.55 3.60 564 1.98 0 0 15 2 83 On the sym driver, the pauses from da1 are more frequent and longer. On the Syquest at da0, there's something strange going on. The transaction rate on da0 drops way off while it's trying to catch up, which means that da1 is forced to wait longer before it can start blasting data at it again. tty da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 30 64.00 22 1.36 2.91 397 1.13 0 0 21 18 60 0 30 64.00 21 1.30 3.41 292 0.97 1 0 14 21 64 0 30 64.00 20 1.24 3.75 82 0.30 0 0 5 21 74 0 30 64.00 21 1.30 0.00 0 0.00 0 0 0 27 72 0 30 64.00 21 1.30 0.00 0 0.00 0 0 0 26 73 0 30 64.00 19 1.18 0.00 0 0.00 0 0 0 24 75 0 89 64.00 17 1.05 0.00 0 0.00 2 0 0 17 81 0 30 64.00 15 0.93 0.00 0 0.00 1 0 0 14 85 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 8 92 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 1 99 0 30 55.27 22 1.18 3.69 702 2.53 2 0 11 6 82 0 30 64.00 22 1.36 3.78 670 2.47 1 0 21 16 62 0 30 64.00 23 1.42 3.19 478 1.49 1 0 21 17 61 0 30 64.00 20 1.24 0.00 0 0.00 0 0 0 22 77 0 30 64.00 17 1.05 0.00 0 0.00 1 0 0 16 83 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 9 91 0 30 64.00 4 0.25 0.00 0 0.00 0 0 0 4 96 0 30 48.95 21 0.99 3.43 520 1.74 2 0 8 2 88 So this would appear to be the cause of the slower dumps. Perhaps this is error recovery activity on da0? Whatever it is, the sym driver isn't handling it as gracefully as the ncr. -- Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 28 8:40:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id C683F15723 for ; Tue, 28 Sep 1999 08:40:49 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-185.villette.club-internet.fr [194.158.116.185]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id RAA02394; Tue, 28 Sep 1999 17:40:37 +0200 (MET DST) Date: Tue, 28 Sep 1999 18:01:34 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Mattias Pantzare Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <199909272236.XAA11345@zed.ludd.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 28 Sep 1999, Mattias Pantzare wrote: > > You test is not serious. If you only can provide 1.5MB/second throughpu= t > > for a benchmark of SCSI driver, please go away or make comparison with = an > > AHA 1542. I consider your posting to be a bad joke and hope that it is = not > > intentionnaly just bad taste.=20 >=20 > Why is it not serious?? A SCSI driver has to be fast even for slow device= s=20 > even if it can drive very fast devices. It is more important to be fast= =20 > on slow devices as those are the most likly to be a problem! >=20 > 30% is a real problem, and a mixture of slow and fast devices on the same= SCSI=20 > bus is common. If a SCSI device behaves slower with a faster SIM/HA pair then there is a probably some problem in the SCSI device. If my goal had been to provide fast stuff for either slow and/or shitty SCSI devices I would certainly not have spent a single second of my life to SCSI/PCI. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 28 8:57:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 2BEA914E41 for ; Tue, 28 Sep 1999 08:57:41 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-102-86.villette.club-internet.fr [194.158.102.86]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id RAA06408; Tue, 28 Sep 1999 17:57:27 +0200 (MET DST) Date: Tue, 28 Sep 1999 18:18:19 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Kevin Street Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <874sgfog96.fsf@mired.eh.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I suggest you to configure the same number of tags for the sym and the ncr using camcontrol after boot, then to redo your testings and post results.= =20 You can be sure I will comment them. G=E9rard. On 27 Sep 1999, Kevin Street wrote: > "Kenneth D. Merry" writes: > > Gerard Roudier wrote... > > > You test is not serious. If you only can provide 1.5MB/second through= put > > > for a benchmark of SCSI driver, please go away or make comparison wit= h an > > > AHA 1542. I consider your posting to be a bad joke and hope that it i= s not > > > intentionnaly just bad taste.=20 >=20 > This original hasn't made it to me yet so I don't have all the > context. If this comment by Gerard was aimed at me, then my response > is: I'm assuming that you intended the sym driver to be used for real > applications on real machines. If its only purpose is to run > benchmarks, then let me know that and I will go away. >=20 > > I think what you may want to do is ask Kevin to give you some compariso= ns > > of iostat output from dumps with the ncr driver and dumps with the sym > > driver, ... >=20 > I've done a few more tests. I tried to see the effect that the > slow Syquest drive is having. When I dump to an IDE drive then > the sym driver is faster than the ncr by 15-20%. But when I dump > to the Syquest, then the interference slows down the sym driver more > than the ncr. Here's what I got from 8 test runs of dump. >=20 > dump from da1 to ad0 (IBM SCSI to WD IDE) > =09time=09KB/sec > ncr=09246=091764 > ncr=09250=091736 > sym=09211=092056 > sym=09209=092076 >=20 > dump from da1 to da0 (IBM SCSI to Syjet SCSI) > =09time=09KB/sec > ncr=09275=091578 > ncr=09277=091566=09 > sym=09335=091295 > sym=09336=091291 >=20 > Looking at iostat shows dump pushing 64KB blocks at the Syquest > which is almost keeping up. It gets behind occasionally and > the da1 transfers stop until da0 catches up. With the ncr > driver it looks like this: >=20 > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >=20 > 0 30 64.00 24 1.49 4.75 265 1.23 1 0 5 2 92 > 0 30 64.00 25 1.55 4.71 219 1.01 1 0 2 1 97 > 0 30 64.00 23 1.42 0.00 0 0.00 0 0 0 0100 > 0 30 64.00 25 1.55 0.00 0 0.00 0 0 0 0 99 > 0 30 53.92 25 1.30 3.56 275 0.96 1 0 6 1 92 > 0 30 64.00 25 1.55 3.60 564 1.98 0 0 15 2 83 >=20 > On the sym driver, the pauses from da1 are more frequent and > longer. On the Syquest at da0, there's something strange > going on. The transaction rate on da0 drops way off while it's=20 > trying to catch up, which means that da1 is forced to wait > longer before it can start blasting data at it again. >=20 > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >=20 > 0 30 64.00 22 1.36 2.91 397 1.13 0 0 21 18 60 > 0 30 64.00 21 1.30 3.41 292 0.97 1 0 14 21 64 > 0 30 64.00 20 1.24 3.75 82 0.30 0 0 5 21 74 > 0 30 64.00 21 1.30 0.00 0 0.00 0 0 0 27 72 > 0 30 64.00 21 1.30 0.00 0 0.00 0 0 0 26 73 > 0 30 64.00 19 1.18 0.00 0 0.00 0 0 0 24 75 > 0 89 64.00 17 1.05 0.00 0 0.00 2 0 0 17 81 > 0 30 64.00 15 0.93 0.00 0 0.00 1 0 0 14 85 > 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 8 92 > 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 1 99 > 0 30 55.27 22 1.18 3.69 702 2.53 2 0 11 6 82 > 0 30 64.00 22 1.36 3.78 670 2.47 1 0 21 16 62 > 0 30 64.00 23 1.42 3.19 478 1.49 1 0 21 17 61 > 0 30 64.00 20 1.24 0.00 0 0.00 0 0 0 22 77 > 0 30 64.00 17 1.05 0.00 0 0.00 1 0 0 16 83 > 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 9 91 > 0 30 64.00 4 0.25 0.00 0 0.00 0 0 0 4 96 > 0 30 48.95 21 0.99 3.43 520 1.74 2 0 8 2 88 >=20 > So this would appear to be the cause of the slower dumps. > Perhaps this is error recovery activity on da0? Whatever > it is, the sym driver isn't handling it as gracefully as > the ncr. >=20 > --=20 > Kevin Street > street@iname.com >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 28 9: 1:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by hub.freebsd.org (Postfix) with ESMTP id 89D2B14ED6 for ; Tue, 28 Sep 1999 09:01:13 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-102-86.villette.club-internet.fr [194.158.102.86]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id SAA14403; Tue, 28 Sep 1999 18:01:05 +0200 (MET DST) Date: Tue, 28 Sep 1999 18:22:01 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Kevin Street Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <874sgfog96.fsf@mired.eh.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The sym driver reads the user setup from the NVRAM and applies it. If it happens that you just disabled some important features from the NVRAM then this also may explain the problem. Check your user setup and report me it. You can be double-sure that I will comment it.=20 G=E9rard. On 27 Sep 1999, Kevin Street wrote: > "Kenneth D. Merry" writes: > > Gerard Roudier wrote... > > > You test is not serious. If you only can provide 1.5MB/second through= put > > > for a benchmark of SCSI driver, please go away or make comparison wit= h an > > > AHA 1542. I consider your posting to be a bad joke and hope that it i= s not > > > intentionnaly just bad taste.=20 >=20 > This original hasn't made it to me yet so I don't have all the > context. If this comment by Gerard was aimed at me, then my response > is: I'm assuming that you intended the sym driver to be used for real > applications on real machines. If its only purpose is to run > benchmarks, then let me know that and I will go away. >=20 > > I think what you may want to do is ask Kevin to give you some compariso= ns > > of iostat output from dumps with the ncr driver and dumps with the sym > > driver, ... >=20 > I've done a few more tests. I tried to see the effect that the > slow Syquest drive is having. When I dump to an IDE drive then > the sym driver is faster than the ncr by 15-20%. But when I dump > to the Syquest, then the interference slows down the sym driver more > than the ncr. Here's what I got from 8 test runs of dump. >=20 > dump from da1 to ad0 (IBM SCSI to WD IDE) > =09time=09KB/sec > ncr=09246=091764 > ncr=09250=091736 > sym=09211=092056 > sym=09209=092076 >=20 > dump from da1 to da0 (IBM SCSI to Syjet SCSI) > =09time=09KB/sec > ncr=09275=091578 > ncr=09277=091566=09 > sym=09335=091295 > sym=09336=091291 >=20 > Looking at iostat shows dump pushing 64KB blocks at the Syquest > which is almost keeping up. It gets behind occasionally and > the da1 transfers stop until da0 catches up. With the ncr > driver it looks like this: >=20 > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >=20 > 0 30 64.00 24 1.49 4.75 265 1.23 1 0 5 2 92 > 0 30 64.00 25 1.55 4.71 219 1.01 1 0 2 1 97 > 0 30 64.00 23 1.42 0.00 0 0.00 0 0 0 0100 > 0 30 64.00 25 1.55 0.00 0 0.00 0 0 0 0 99 > 0 30 53.92 25 1.30 3.56 275 0.96 1 0 6 1 92 > 0 30 64.00 25 1.55 3.60 564 1.98 0 0 15 2 83 >=20 > On the sym driver, the pauses from da1 are more frequent and > longer. On the Syquest at da0, there's something strange > going on. The transaction rate on da0 drops way off while it's=20 > trying to catch up, which means that da1 is forced to wait > longer before it can start blasting data at it again. >=20 > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >=20 > 0 30 64.00 22 1.36 2.91 397 1.13 0 0 21 18 60 > 0 30 64.00 21 1.30 3.41 292 0.97 1 0 14 21 64 > 0 30 64.00 20 1.24 3.75 82 0.30 0 0 5 21 74 > 0 30 64.00 21 1.30 0.00 0 0.00 0 0 0 27 72 > 0 30 64.00 21 1.30 0.00 0 0.00 0 0 0 26 73 > 0 30 64.00 19 1.18 0.00 0 0.00 0 0 0 24 75 > 0 89 64.00 17 1.05 0.00 0 0.00 2 0 0 17 81 > 0 30 64.00 15 0.93 0.00 0 0.00 1 0 0 14 85 > 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 8 92 > 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 1 99 > 0 30 55.27 22 1.18 3.69 702 2.53 2 0 11 6 82 > 0 30 64.00 22 1.36 3.78 670 2.47 1 0 21 16 62 > 0 30 64.00 23 1.42 3.19 478 1.49 1 0 21 17 61 > 0 30 64.00 20 1.24 0.00 0 0.00 0 0 0 22 77 > 0 30 64.00 17 1.05 0.00 0 0.00 1 0 0 16 83 > 0 30 64.00 8 0.50 0.00 0 0.00 0 0 0 9 91 > 0 30 64.00 4 0.25 0.00 0 0.00 0 0 0 4 96 > 0 30 48.95 21 0.99 3.43 520 1.74 2 0 8 2 88 >=20 > So this would appear to be the cause of the slower dumps. > Perhaps this is error recovery activity on da0? Whatever > it is, the sym driver isn't handling it as gracefully as > the ncr. >=20 > --=20 > Kevin Street > street@iname.com >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 28 19: 1:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 7AB981579E for ; Tue, 28 Sep 1999 19:01:12 -0700 (PDT) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19990929020111.QINB5795.mail.rdc2.on.home.com@mired.eh.local>; Tue, 28 Sep 1999 19:01:11 -0700 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id WAA01205; Tue, 28 Sep 1999 22:01:10 -0400 (EDT) (envelope-from kws) From: Kevin Street MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <14321.29414.266150.585956@mired.eh.local> Date: Tue, 28 Sep 1999 22:01:10 -0400 (EDT) To: Gerard Roudier Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: References: <874sgfog96.fsf@mired.eh.local> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier writes: > >I suggest you to configure the same number of tags for the sym and the= ncr >using camcontrol after boot, then to redo your testings and post resul= ts.=20 >You can be sure I will comment them. G=E9rard, that's it. When I boot, the tags on the Syquest are set to=20= 1. When I first run the dump, the tags are automatically set up to 64 and this gives poor performance. If I manually reset them to 8,=20 then the dump runs much faster. It's now 265 seconds at 1651 KBytes/sec and this is now faster than the ncr throughput. With the ncr driver the tags are 32 at boot and get automatically reset to 8 when the dump runs. =20 Is it cam or the ncr driver which reduces the tags to the correct value= ? It would definitely be useful if the sym driver could dynamically reduce the tags for devices that can't handle 64 openings. The only other parameters that are different are the Read/Write Retry Counts. They start at 34/28 on the ncr and are increased to 75 when the dump runs. The sym driver has them set to 75 at boot, so these end up being the same. Thanks for the help. --=20 Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 7:31: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (Postfix) with ESMTP id 89787151C4 for ; Wed, 29 Sep 1999 07:30:09 -0700 (PDT) (envelope-from pantzer@speedy.ludd.luth.se) Received: from speedy.ludd.luth.se (pantzer@speedy.ludd.luth.se [130.240.16.164]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id PAA03731; Wed, 29 Sep 1999 15:29:51 +0100 Message-Id: <199909291429.PAA03731@zed.ludd.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: Message from Gerard Roudier of "Tue, 28 Sep 1999 18:01:34 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Sep 1999 16:29:51 +0200 From: Mattias Pantzare Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, 28 Sep 1999, Mattias Pantzare wrote: > = > > > You test is not serious. If you only can provide 1.5MB/second throu= ghput > > > for a benchmark of SCSI driver, please go away or make comparison w= ith an > > > AHA 1542. I consider your posting to be a bad joke and hope that it= is not > > > intentionnaly just bad taste. = > > = > > Why is it not serious?? A SCSI driver has to be fast even for slow de= vices = > > even if it can drive very fast devices. It is more important to be fa= st = > > on slow devices as those are the most likly to be a problem! > > = > > 30% is a real problem, and a mixture of slow and fast devices on the = same SCSI = > > bus is common. > = > If a SCSI device behaves slower with a faster SIM/HA pair then there is= a > probably some problem in the SCSI device. If my goal had been to provid= e > fast stuff for either slow and/or shitty SCSI devices I would certainly= > not have spent a single second of my life to SCSI/PCI. Or the driver is doing things wrong. = You may have a valid point in that the device is not doing things acordin= g to = the SCSI spec, but you can't dissmiss the test only becouse you never use= slow = devices on a fast SCSI buss (that is, do not live in the real world :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 9:51:24 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 9C01915A13 for ; Wed, 29 Sep 1999 09:49:57 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id KAA14390; Wed, 29 Sep 1999 10:38:56 -0600 (MDT) Date: Wed, 29 Sep 1999 10:38:56 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199909291638.KAA14390@narnia.plutotech.com> To: Kevin Street , Gerard Roudier Cc: scsi@FreeBSD.org Subject: Re: sym driver 0.3.0 X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <874sgfog96.fsf@mired.eh.local> <14321.29414.266150.585956@mired.eh.local> 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 In article <14321.29414.266150.585956@mired.eh.local> you wrote: > > Is it cam or the ncr driver which reduces the tags to the correct value? > It would definitely be useful if the sym driver could dynamically > reduce the tags for devices that can't handle 64 openings. The peripheral driver/XPT will reduce the number of tags so long as the QUEUE FULL return status is passed all the way up the food chain. It looks as those the sym_hipd driver returns CAM_REQUEUE_REQ in this case instead of CAM_SCSI_STATUS_ERROR. (The status was originally set correctly by the QUEUE FULL handler, but is later clobbered by the run down of the qtmp queue). -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 12:23:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id EAAEC1594A for ; Wed, 29 Sep 1999 12:22:41 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-165-185.villette.club-internet.fr [195.36.165.185]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA23239; Wed, 29 Sep 1999 21:21:47 +0200 (MET DST) Date: Wed, 29 Sep 1999 21:42:27 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Kevin Street Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 In-Reply-To: <14321.29414.266150.585956@mired.eh.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 28 Sep 1999, Kevin Street wrote: > Is it cam or the ncr driver which reduces the tags to the correct value? > It would definitely be useful if the sym driver could dynamically > reduce the tags for devices that can't handle 64 openings. This had been a misunderstanding from me that is fixed in SYM.0.4.0. I have uploaded the patch yesterday. The problem appears to me when rereading the source code. There were no risk for your data. =20 > The only other parameters that are different are the Read/Write Retry > Counts. They start at 34/28 on the ncr and are increased to 75 when > the dump runs. The sym driver has them set to 75 at boot, so these > end up being the same. Basically, given slow devices and comparable configurations, no significant differences in performances should be observed between the sym and the ncr driver. By the way, I am much more interested in robustness and reliability testings that ncr .vs. sym benchmarks. I have no doubts about the performances of the sym driver that are guaranteed by design and are known for the linux sym53c8xx driver that is based on the same design regarding performances issues.=20 About benchmarks, comparisons with other HAs from other vendors will be welcome, especially using high end hard disks and Adaptec equivalent adapters. The README.sym file contains a summary of the sym driver features. Performances is probably the one people on this list are most interested in, but some others as the support the all NVRAM formats is a major feature for end-users and extremely user-friendly. You may also consider that the sym driver supports _full_ SPI2 minus linked commands (that IIRC are obsoleted by SPI3), which is pretty rare on the planet (some SPI2 features are still to be tested). > Thanks for the help. Thanks to you, too. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 13: 7:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 62D78158E3 for ; Wed, 29 Sep 1999 13:06:20 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-100-191.villette.club-internet.fr [194.158.100.191]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA18855; Wed, 29 Sep 1999 22:05:30 +0200 (MET DST) Date: Wed, 29 Sep 1999 22:26:30 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Justin T. Gibbs" Cc: Kevin Street , scsi@FreeBSD.org Subject: Re: sym driver 0.3.0 In-Reply-To: <199909291638.KAA14390@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 29 Sep 1999, Justin T. Gibbs wrote: > In article <14321.29414.266150.585956@mired.eh.local> you wrote: > >=20 > > Is it cam or the ncr driver which reduces the tags to the correct value= ? > > It would definitely be useful if the sym driver could dynamically > > reduce the tags for devices that can't handle 64 openings. >=20 > The peripheral driver/XPT will reduce the number of tags so long as > the QUEUE FULL return status is passed all the way up the food chain. > It looks as those the sym_hipd driver returns CAM_REQUEUE_REQ in this > case instead of CAM_SCSI_STATUS_ERROR. (The status was originally > set correctly by the QUEUE FULL handler, but is later clobbered by > the run down of the qtmp queue). Indeed it was that. I have fixed it yesterday when rereading the code and made SYM.0.4.0 available. I just reread the code after having posted my suggestion to look on the tags number and discovered the issue. I have stressed the change using LXY4 and it seemed robust and fits XPT expectations that reduces the device queue depth now. I had been confused while testing the QUEUE FULL code the first time by the value 32 reported by camcontrol versus 64 asked by the SIM. By the way, I never experienced problem with LXY4 when starting with 64 tags under Linux and adjusting the tag depth when needed. When the write caching is disabled on LXY4, the device can accept more than 32 tags without returning QUEUE FULL. May-be FreeBSD-CAM is a bit too conservative about quircky devices.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 13:21: 1 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 7560815077 for ; Wed, 29 Sep 1999 13:20:53 -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 OAA01634; Wed, 29 Sep 1999 14:19:29 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199909292019.OAA01634@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Gerard Roudier Cc: "Justin T. Gibbs" , Kevin Street , scsi@FreeBSD.org Subject: Re: sym driver 0.3.0 In-reply-to: Your message of "Wed, 29 Sep 1999 22:26:30 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Sep 1999 14:19:29 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Indeed it was that. I have fixed it yesterday when rereading the code an= d >made SYM.0.4.0 available. I just reread the code after having posted my >suggestion to look on the tags number and discovered the issue. I have >stressed the change using LXY4 and it seemed robust and fits XPT >expectations that reduces the device queue depth now. I had been confuse= d >while testing the QUEUE FULL code the first time by the value 32 reporte= d >by camcontrol versus 64 asked by the SIM. By the way, I never experience= d >problem with LXY4 when starting with 64 tags under Linux and adjusting >the tag depth when needed. When the write caching is disabled on LXY4, t= he >device can accept more than 32 tags without returning QUEUE FULL. May-be= >FreeBSD-CAM is a bit too conservative about quircky devices. It has always been my intention to change the tag reduction algorithm to be more adaptive than the current approach. In order to deal gracefully with resource shortages in multi-initiator situations, the tag algorithm should attempt to raise the number of tags. Assuming this 'windowing' code only occasionally incurs a QUEUE FULL, quirk entries for devices like the Atlas II would not be needed. This is another entry on my whiteboard. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 14:52:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front3m.grolier.fr (front3m.grolier.fr [195.36.216.53]) by hub.freebsd.org (Postfix) with ESMTP id B5751155EF for ; Wed, 29 Sep 1999 14:52:37 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-105-29.villette.club-internet.fr [194.158.105.29]) by front3m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA17806; Wed, 29 Sep 1999 23:52:08 +0200 (MET DST) Date: Thu, 30 Sep 1999 00:13:09 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: "Justin T. Gibbs" Cc: "Justin T. Gibbs" , Kevin Street , scsi@FreeBSD.org Subject: Re: sym driver 0.3.0 In-Reply-To: <199909292019.OAA01634@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 29 Sep 1999, Justin T. Gibbs wrote: > >Indeed it was that. I have fixed it yesterday when rereading the code an= d > >made SYM.0.4.0 available. I just reread the code after having posted my > >suggestion to look on the tags number and discovered the issue. I have > >stressed the change using LXY4 and it seemed robust and fits XPT > >expectations that reduces the device queue depth now. I had been confuse= d > >while testing the QUEUE FULL code the first time by the value 32 reporte= d > >by camcontrol versus 64 asked by the SIM. By the way, I never experience= d > >problem with LXY4 when starting with 64 tags under Linux and adjusting > >the tag depth when needed. When the write caching is disabled on LXY4, t= he > >device can accept more than 32 tags without returning QUEUE FULL. May-be > >FreeBSD-CAM is a bit too conservative about quircky devices. >=20 > It has always been my intention to change the tag reduction algorithm to > be more adaptive than the current approach. In order to deal gracefully > with resource shortages in multi-initiator situations, the tag algorithm > should attempt to raise the number of tags. Assuming this 'windowing' > code only occasionally incurs a QUEUE FULL, quirk entries for devices > like the Atlas II would not be needed. This is another entry on my > whiteboard. Reducing the device queue depth to the actual number of disconnected commands is fine as an immediate decision. Increasing the number of tags based on some simple criteria seems to be quite fine even for the quantum drives, at least in mono-initiator environments. For example, adding 1 to the queue depth every N good status received (N constant) seems good enough. I wanted to use N<100 but coded N=3D1000 under Linux.=20 Obviously there is room for far better heuristics that can use variable value for N based on the actual pattern of the QUEUE FULL conditions=20 compared to GOOD statuses received. Note that if you are good at dealing with LXY4 and friends QUEUE FULL status, you are probably excellent in this regard for any other device and may-be for ever. :-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 29 21: 9:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from friley-160-236.res.iastate.edu (friley-160-236.res.iastate.edu [129.186.160.236]) by hub.freebsd.org (Postfix) with ESMTP id 319DA150EA for ; Wed, 29 Sep 1999 21:09:47 -0700 (PDT) (envelope-from cc@137.org) Received: from ameslab.gov (friley-160-235.res.iastate.edu [129.186.160.235]) by friley-160-236.res.iastate.edu (Postfix) with ESMTP id B045A129; Wed, 29 Sep 1999 23:09:46 -0500 (CDT) Message-ID: <37F2E28A.11ED3110@ameslab.gov> Date: Thu, 30 Sep 1999 04:09:46 +0000 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.4.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I decided I would try out your driver as I don't have any terribly critical data on that SCSI bus. Anyways, I have discovered that the driver does not probe all the luns of scsi devices. I have a Nakamichi changer, and only the first cd device is recognized. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 2:53:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by hub.freebsd.org (Postfix) with ESMTP id F0F6D159AE; Thu, 30 Sep 1999 02:53:16 -0700 (PDT) (envelope-from bfischer@Techfak.uni-bielefeld.de) Received: from frolic.no-support.loc (ppp36-386.hrz.uni-bielefeld.de) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FIV00CLGA4IGT@mail.uni-bielefeld.de>; Thu, 30 Sep 1999 11:53:08 +0200 (MET DST) Received: (from bjoern@localhost) by frolic.no-support.loc (8.9.3/8.9.3) id LAA00884; Thu, 30 Sep 1999 11:52:10 +0200 (CEST envelope-from bjoern) Date: Thu, 30 Sep 1999 11:52:10 +0200 From: Bjoern Fischer Subject: check for unaligned buffers in CAM [was Re: Cdrecord problems...] In-reply-to: <37F293E7.E63F9E36@es.co.nz> To: Mike Muir Cc: Eliezer Rodriguez Gonzalez , Bjoern Fischer , freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Message-id: <19990930115210.A325@frolic.no-support.loc> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable References: <37F293E7.E63F9E36@es.co.nz> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 30, 1999 at 10:34:15AM +1200, Mike Muir wrote: > Eliezer Rodriguez Gonzalez wrote: > >=20 > > Hello everybody: > >=20 > > Finally I was able to burn my own copy of 3.3-RELEASE, downloaded via f= tp > > from a mirror site. > > I found out, by research and because Mr Fischer told me so, that while > > using version 1.6.1 of cdrecord there was a problem using the internal > > buffer, so I disabled that feature via the command option fs=3D0 and th= en > > everything worked fine and I was able to burn my CD-ROM with the older > > cdrecord version. >=20 > This also happens when using 1.8a28 under -current.. not quite sure why, > but i'm > guessing for the same reasons outlined in an earlier posting in this > thread. > (I'm going to try a29 next). You could check for unaligned buffers in sys/cam/cam_periph.c:cam_periph_mapmem() (around line 530 in -stable). One (Kenneth? me?) could also make this debugging hook permanent in conjunction with one or more sysctl knobs which switch on the check or/and -- even better -- send a signal (SIGBUS?) to the process on unaligned buffers. That would make it very easy to debug not only cdrecord but *any* userland process that uses cam transport. Any opinions? Bj=F6rn --=20 -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L+++(--) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=20 ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 10:43:47 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 C4DBC14F1B; Thu, 30 Sep 1999 10:43:41 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA32290; Thu, 30 Sep 1999 11:40:57 -0600 (MDT) (envelope-from ken) Message-Id: <199909301740.LAA32290@panzer.kdm.org> Subject: Re: check for unaligned buffers in CAM [was Re: Cdrecord problems...] In-Reply-To: <19990930115210.A325@frolic.no-support.loc> from Bjoern Fischer at "Sep 30, 1999 11:52:10 am" To: bfischer@Techfak.Uni-Bielefeld.DE (Bjoern Fischer) Date: Thu, 30 Sep 1999 11:40:57 -0600 (MDT) Cc: mmuir@es.co.nz (Mike Muir), elie@uncle.cult.cu (Eliezer Rodriguez Gonzalez), freebsd-stable@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 Bjoern Fischer wrote... > On Thu, Sep 30, 1999 at 10:34:15AM +1200, Mike Muir wrote: > > Eliezer Rodriguez Gonzalez wrote: > > > > > > Hello everybody: > > > > > > Finally I was able to burn my own copy of 3.3-RELEASE, downloaded via ftp > > > from a mirror site. > > > I found out, by research and because Mr Fischer told me so, that while > > > using version 1.6.1 of cdrecord there was a problem using the internal > > > buffer, so I disabled that feature via the command option fs=0 and then > > > everything worked fine and I was able to burn my CD-ROM with the older > > > cdrecord version. > > > > This also happens when using 1.8a28 under -current.. not quite sure why, > > but i'm > > guessing for the same reasons outlined in an earlier posting in this > > thread. > > (I'm going to try a29 next). > > You could check for unaligned buffers in > sys/cam/cam_periph.c:cam_periph_mapmem() (around line 530 in -stable). > > One (Kenneth? me?) could also make this debugging hook permanent in > conjunction with one or more sysctl knobs which switch on the check > or/and -- even better -- send a signal (SIGBUS?) to the process on > unaligned buffers. That would make it very easy to debug not only > cdrecord but *any* userland process that uses cam transport. > > Any opinions? I think it would be better for userland code authors to use the tools available for debugging. It's pretty easy to do something like assert((ccb->csio.data_ptr & PAGE_MASK) == 0); Sending non-page-aligned buffers to the passthrough driver is not forbidden outright. The problem is sending buffers that are close (within a page) to the maximum size (64K) that are not page aligned. Joerg had a problem at one point in cdrecord with non page-aligned buffers, and he fixed it. My guess is that he has introduced a new problem. If you tell him about it, I'm sure he'll fix it. (I think he may be out of town at the moment, so it may be a little while before he responds.) In the mean time, you can get around the problem by changing the CAM version of scsi_maxdma() in libscg/scsi-bsd.c to return DFLTPHYS - PAGE_SIZE instead of DFLTPHYS. That will prevent the problem from occuring. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 11:55:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id B2AE51518B for ; Thu, 30 Sep 1999 11:54:10 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-164-190.villette.club-internet.fr [195.36.164.190]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA01194; Thu, 30 Sep 1999 20:53:50 +0200 (MET DST) Date: Thu, 30 Sep 1999 21:14:55 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Chris Csanady Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.4.0 In-Reply-To: <37F2E28A.11ED3110@ameslab.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 30 Sep 1999, Chris Csanady wrote: > Well, I decided I would try out your driver as I don't have any > terribly critical data on that SCSI bus. Anyways, I have > discovered that the driver does not probe all the luns of scsi > devices. I have a Nakamichi changer, and only the first cd > device is recognized. Thanks for trying this driver and for the problem report. Could you try to get some debug informations from the CAM layer. The status returned by the driver for the TEST UNIT READY for some existing LUN !=3D 0 will help. Unfortunately I donnot have multi-lun devices for testing this out. In theory, the driver can support up to 64 LUNs and is configured by=20 default to 16 (SYMCONF_MAX_LUN in sym_conf.h). G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 12:43:55 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 2FC6C14D0A for ; Thu, 30 Sep 1999 12:43:46 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA13540; Thu, 30 Sep 1999 12:42:47 -0700 Date: Thu, 30 Sep 1999 12:42:39 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gerard Roudier Cc: Chris Csanady , scsi@FreeBSD.ORG Subject: Re: sym driver 0.4.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'll try it for higher LUNs when I get a chance to look at this- I have a target I can configure for up to a fairly arbitrary number of luns, although I'd like to know how you can support more than 32 luns for parallel SCSi w/o going to SCCLUN semantics. You should note that there is a setting now in cam_xpt.c such that only luns 0..7 will be searched unless there's a quirk for a device. There are far too many broken devices out there that just do strange things when you go into the higher luns. On Thu, 30 Sep 1999, Gerard Roudier wrote: >=20 >=20 > On Thu, 30 Sep 1999, Chris Csanady wrote: >=20 > > Well, I decided I would try out your driver as I don't have any > > terribly critical data on that SCSI bus. Anyways, I have > > discovered that the driver does not probe all the luns of scsi > > devices. I have a Nakamichi changer, and only the first cd > > device is recognized. >=20 > Thanks for trying this driver and for the problem report. > Could you try to get some debug informations from the CAM layer. > The status returned by the driver for the TEST UNIT READY for some > existing LUN !=3D 0 will help. >=20 > Unfortunately I donnot have multi-lun devices for testing this out. > In theory, the driver can support up to 64 LUNs and is configured by=20 > default to 16 (SYMCONF_MAX_LUN in sym_conf.h). >=20 > G=E9rard. >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 13:25:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 52EE214E9B for ; Thu, 30 Sep 1999 13:25:07 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-164-104.villette.club-internet.fr [195.36.164.104]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA01608; Thu, 30 Sep 1999 22:24:26 +0200 (MET DST) Date: Thu, 30 Sep 1999 22:45:14 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Matthew Jacob Cc: Chris Csanady , scsi@FreeBSD.ORG Subject: Re: sym driver 0.4.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 30 Sep 1999, Matthew Jacob wrote: > I'll try it for higher LUNs when I get a chance to look at this- I have a > target I can configure for up to a fairly arbitrary number of luns, Thanks. > although I'd like to know how you can support more than 32 luns for > parallel SCSi w/o going to SCCLUN semantics. SPI2 allows 6 bits for the LUN number. > You should note that there is a setting now in cam_xpt.c such that only > luns 0..7 will be searched unless there's a quirk for a device. There are > far too many broken devices out there that just do strange things when yo= u > go into the higher luns. May-be, for covering all existing multi-lun devices, at least luns 0,..,15 should be supported. G=E9rard. > On Thu, 30 Sep 1999, Gerard Roudier wrote: >=20 > >=20 > >=20 > > On Thu, 30 Sep 1999, Chris Csanady wrote: > >=20 > > > Well, I decided I would try out your driver as I don't have any > > > terribly critical data on that SCSI bus. Anyways, I have > > > discovered that the driver does not probe all the luns of scsi > > > devices. I have a Nakamichi changer, and only the first cd > > > device is recognized. > >=20 > > Thanks for trying this driver and for the problem report. > > Could you try to get some debug informations from the CAM layer. > > The status returned by the driver for the TEST UNIT READY for some > > existing LUN !=3D 0 will help. > >=20 > > Unfortunately I donnot have multi-lun devices for testing this out. > > In theory, the driver can support up to 64 LUNs and is configured by=20 > > default to 16 (SYMCONF_MAX_LUN in sym_conf.h). > >=20 > > G=E9rard. > >=20 > >=20 > >=20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 13:29:32 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 CCDD214E9B for ; Thu, 30 Sep 1999 13:29:30 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA13795; Thu, 30 Sep 1999 13:29:16 -0700 Date: Thu, 30 Sep 1999 13:29:08 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gerard Roudier Cc: Chris Csanady , scsi@FreeBSD.ORG Subject: Re: sym driver 0.4.0 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 > > > I'll try it for higher LUNs when I get a chance to look at this- I have a > > target I can configure for up to a fairly arbitrary number of luns, > > Thanks. > > > although I'd like to know how you can support more than 32 luns for > > parallel SCSi w/o going to SCCLUN semantics. > > SPI2 allows 6 bits for the LUN number. I'll go back and (re)check that spec then. How does this apply to revisions less than SCSI-3? > > > You should note that there is a setting now in cam_xpt.c such that only > > luns 0..7 will be searched unless there's a quirk for a device. There are > > far too many broken devices out there that just do strange things when you > > go into the higher luns. > > May-be, for covering all existing multi-lun devices, at least luns 0,..,15 > should be supported. I would think not for the generic case. I originally thought so, but I ran into too much breakage. It's simple enough to say "if <= SCSI2 and !HILUNS_QUIRKED, then maxlun == 8". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 30 18:36: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 82CD215629 for ; Thu, 30 Sep 1999 18:35:57 -0700 (PDT) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19991001013555.ZSKQ5795.mail.rdc2.on.home.com@mired.eh.local>; Thu, 30 Sep 1999 18:35:55 -0700 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id VAA00843; Thu, 30 Sep 1999 21:35:54 -0400 (EDT) (envelope-from kws) To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 References: From: Kevin Street Date: 30 Sep 1999 21:35:53 -0400 In-Reply-To: Gerard Roudier's message of "Wed, 29 Sep 1999 22:26:30 +0200 (MET DST)" Message-ID: <87u2obkgli.fsf@mired.eh.local> Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gerard Roudier writes: > Indeed it was that. I have fixed it yesterday when rereading the code and > made SYM.0.4.0 available. I just reread the code after having posted my > suggestion to look on the tags number and discovered the issue. Gérard, yes SYM.0.4.0 is working correctly for me. The tags are now automatically set to 8 on the Syquest drive. Thanks! -- Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 1 13:28:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 824C215391 for ; Fri, 1 Oct 1999 13:28:05 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-170-217.villette.club-internet.fr [195.36.170.217]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA10502; Fri, 1 Oct 1999 22:27:48 +0200 (MET DST) Date: Fri, 1 Oct 1999 22:48:53 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Chris Csanady Cc: scsi@FreeBSD.ORG Subject: SYM 0.5.0 (Re: sym driver 0.4.0) In-Reply-To: <37F2E28A.11ED3110@ameslab.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hopefully SYM-0.5.0 fixes this problem (uploaded minutes ago). By the way, I have reduced the number of luns to 8 by default, since some devices are definitely bad behaving when asked for a lun > 7.=20 G=E9rard. On Thu, 30 Sep 1999, Chris Csanady wrote: > Well, I decided I would try out your driver as I don't have any > terribly critical data on that SCSI bus. Anyways, I have > discovered that the driver does not probe all the luns of scsi > devices. I have a Nakamichi changer, and only the first cd > device is recognized. >=20 > Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 1 18:42:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rknebel.uplink.net (rknebel.uplink.net [209.173.88.243]) by hub.freebsd.org (Postfix) with ESMTP id 7D37A14BEF for ; Fri, 1 Oct 1999 18:42:13 -0700 (PDT) (envelope-from rknebel@uplink.net) Received: from rknebel.uplink.net (rknebel [209.173.88.243]) by rknebel.uplink.net (8.9.3/8.9.3) with SMTP id VAA00336 for ; Fri, 1 Oct 1999 21:41:17 -0400 (EDT) (envelope-from rknebel@uplink.net) From: Rick Knebel Reply-To: rknebel@uplink.net To: scsi@freebsd.org Subject: scsi tape backup Date: Fri, 1 Oct 1999 21:40:46 -0400 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99100121411701.00324@rknebel.uplink.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have two scsi cards in my machine. My adaptec only had my external scanner hooked up to it. I purchased a scsi internal tape backup and hooked it up to this card also. Now is where the weirdness starts. The scanner is id3 and the tape is id4. If I boot up without the scsi cable hooked to the tape backup the power light comes on and the tape will go through the bootup process. If I connect the scsi cable the light will not come on and the tape backup gets no power. AS soon as I disconnect the scsi cable from the tape backup the tape light will come on and it will make noise. If I let the bootup process continue the scsi card complains that it did not find termination. I do not understand this. Can anyone help. Thanks Rick -- Rick Knebel rknebel@uplink.net http://rknebel.uplink.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 2 9:45:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 04C0114DE9 for ; Sat, 2 Oct 1999 09:45:39 -0700 (PDT) (envelope-from mike@sentex.net) Received: from ospf-mdt.sentex.net (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id MAA24232; Sat, 2 Oct 1999 12:45:34 -0400 (EDT) From: mike@sentex.net (Mike Tancsa) To: jreynold@primenet.com (John and Jennifer Reynolds) Cc: freebsd-scsi@freebsd.org Subject: Re: new quirk entry for my seagate tape-- this time a STT20000N Date: Sat, 02 Oct 1999 16:45:33 GMT Message-ID: <37f63490.1434693500@mail.sentex.net> References: In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22 Sep 1999 11:03:12 -0400, in sentex.lists.freebsd.scsi you wrote: sa0: Removable Sequential Access SCSI-2 device seems to be hit with the same quirk. Can someone make a similar entry ? mt seteotmodel 1 also allows me to do more than one dump to the device as described below. ---Mike > >Hi, > >Could one of you fine commiters commit the attached patch to >/usr/src/sys/cam/scsi/scsi_sa.c ? I finally got my new Seagate TapeStor >8000 drive working with the advice of several on this list. The trick turned >out to be using "mt seteotmodel 1" to make the SA driver deal with just 1 >filemark at EOT. Everything seems to be peachy now. The following quirk entry >makes things work peachy as well without having to remember the 'mt' command >before backing up. > >I'm using 3.3-STABLE (CVSup'ed very recently ... I believe last sunday) and I >would imagine that the patch would apply to -current as well. > >(I didn't know if I should send-pr for such a small patch ...) > >Thanks, and thanks for everybody's help!!!!! > >-Jr > >--- scsi_sa.c Tue Sep 21 01:18:26 1999 >+++ scsi_sa.c.new Wed Sep 22 07:17:36 1999 >@@ -213,6 +213,10 @@ > > static struct sa_quirk_entry sa_quirk_table[] = > { >+ { >+ { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "Seagate", >+ "STT8000N*", "*"}, SA_QUIRK_1FM, 0 >+ }, > { > { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "ARCHIVE", > "Python 25601*", "*"}, SA_QUIRK_NOCOMP, 0 >@@ -544,7 +548,7 @@ > printf("unable to backspace over one of double" > " filemarks at end of tape\n"); > xpt_print_path(periph->path); >- printf("it is possible that this device " >+ printf("it is possible that this device" > " needs a SA_QUIRK_1FM quirk set for it\n"); > softc->flags |= SA_FLAG_TAPE_FROZEN; > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation >jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running >jreynold@primenet.com FreeBSD 3.3-STABLE. FreeBSD: The Power to Serve. >http://www.primenet.com/~jreynold/ Come join us!!! @ http://www.FreeBSD.org/ >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-scsi" in the body of the message > >--- Mike Tancsa (mdtancsa@sentex.net) Sentex Communications Corp, Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 2 11:35:17 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 76A0815240 for ; Sat, 2 Oct 1999 11:35:06 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA20196; Sat, 2 Oct 1999 11:34:44 -0700 Date: Sat, 2 Oct 1999 11:34:33 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Tancsa Cc: John and Jennifer Reynolds , freebsd-scsi@FreeBSD.ORG Subject: Re: new quirk entry for my seagate tape-- this time a STT20000N In-Reply-To: <37f63490.1434693500@mail.sentex.net> 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 Will do. Also am adding options SA_1FM_AT_EOD option so that you can just configure a kernel to default to the one filemark behaviour (quirks will still override). This will be in -current and -stable in an hour. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 2 14:10:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from localhost.primenet.com (208-48-174-242.nas-2.scf.primenet.com [208.48.174.242]) by hub.freebsd.org (Postfix) with ESMTP id 4AD23153AB for ; Sat, 2 Oct 1999 14:10:10 -0700 (PDT) (envelope-from jreynold@primenet.com) Received: (from jreynold@localhost) by localhost.primenet.com (8.9.3/8.9.3) id OAA07898; Sat, 2 Oct 1999 14:12:10 -0700 (MST) (envelope-from jreynold@primenet.com) From: John and Jennifer Reynolds MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14326.29994.47289.270980@localhost.primenet.com> Date: Sat, 2 Oct 1999 14:12:10 -0700 (MST) To: mjacob@feral.com Cc: Mike Tancsa , John and Jennifer Reynolds , freebsd-scsi@FreeBSD.ORG Subject: Re: new quirk entry for my seagate tape-- this time a STT20000N In-Reply-To: References: <37f63490.1434693500@mail.sentex.net> X-Mailer: VM 6.73 under Emacs 20.3.1 Cc: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ On Saturday, October 2, Matthew Jacob wrote: ] > > Will do. Also am adding > > options SA_1FM_AT_EOD > > option so that you can just configure a kernel to default to the one > filemark behaviour (quirks will still override). This will be in -current > and -stable in an hour. > Splendid idea! With all these blastid Seagate drives needing the quirk, it makes sense. -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running jreynold@primenet.com FreeBSD 3.3-STABLE. FreeBSD: The Power to Serve. http://www.primenet.com/~jreynold/ Come join us!!! @ http://www.FreeBSD.org/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message