From owner-freebsd-scsi Sun Dec 5 1:38:27 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 6C4871525B; Sun, 5 Dec 1999 01:38:18 -0800 (PST) (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 BAA12534; Sun, 5 Dec 1999 01:39:25 -0800 Date: Sun, 5 Dec 1999 01:39:25 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Chris G. Demetriou" Cc: Jason Thorpe , Wilko Bulte , gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ISP firmware compiled in as a default.... In-Reply-To: <8766yeasvh.fsf@redmail.netbsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Matthew Jacob writes: > > Nope, I don't think so. I pretty much always had been downloading f/w. > > False. see NetBSD sys/dev/ic/isp.c: > > revision 1.18 > date: 1998/01/28 19:09:24; author: mjacob; state: Exp; lines: +9 -5 > Fix for port-alpha/4903- always download f/w unless config flags say > no or we have no firmware to download. > > and/or: > > http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=4903 False. Go to rev 1.1 of isp_pci.c && isp.c && asm_pci.h. F/W download was conditional only there being a fwlen of non-zero. You asked for a config option to turn off f/w downloads. Also, I started trying, at one point, to pay attention to the f/w revisions in currently running (i.e., loaded by SRM) f/w and not loading on top of that. The latter turned out to be a lose because the version numbers vary depending on what feature sets you have. It's also not clear where Digital's f/w (which they probably do themselves) fits in. > > > > There was a hop skip and dance with some f/w and Chris's machine > > [ ... ] > > yeah: before that patch, you _weren't_ always downloading the > firmware, and the DEC ISP firmware didn't work with your isp driver. > 8-) It does a better job now of working with older and different f/w sets. We're talking about two years of fooling around with this now since then, and while I'm kinda stupid, I *do* learn from experience. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 1:38:50 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 0187C15147; Sun, 5 Dec 1999 01:38:46 -0800 (PST) (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 BAA12541; Sun, 5 Dec 1999 01:39:50 -0800 Date: Sun, 5 Dec 1999 01:39:50 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jason Thorpe Cc: Wilko Bulte , gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ISP firmware compiled in as a default.... In-Reply-To: <199912050504.VAA18543@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 4 Dec 1999, Jason Thorpe wrote: > On Sat, 4 Dec 1999 19:47:18 -0800 (PST) > Matthew Jacob wrote: > > > Nope, I don't think so. I pretty much always had been downloading f/w. > > There was a hop skip and dance with some f/w and Chris's machine and some > > stupid ass bugs in 7.55 f/w where you'd tell it to renegotiate and then > > ask it what it had done and it lied and gave back random values. > > Actually, you used to compare "present firmware rev" with "driver firmware > rev" and load the driver firmware if it was "newwer". Version numbering > inconsistencies changed that policy... at least is how I remember it. What I said.... > > > Nope- the netbsd changes list is too hard to read. > > Uh, okay, whatever. > > -- Jason R. Thorpe > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 3: 7:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4349B150FD for ; Sun, 5 Dec 1999 03:07:51 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id LAA30512; Sun, 5 Dec 1999 11:56:52 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id MAA66960; Sun, 5 Dec 1999 12:03:31 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199912051103.MAA66960@yedi.iaf.nl> Subject: Re: not so fast Fast SCSI? In-Reply-To: from Matthew Jacob at "Dec 4, 1999 4: 3:21 pm" To: mjacob@feral.com Date: Sun, 5 Dec 1999 12:03:31 +0100 (CET) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > This is not correctly negotiating out of async mode. I cannot deal with > this for several days. I would suspect that NVRAM settings are pooched- > try disabling them by doing > > set isp_nonvram=1 That did not help. But running the eeromcfg.exe utility from ARC and setting up all devices for Ultra/Fast & Wide mode made all the difference :) Thanks, -- | / o / / _ Arnhem, The Netherlands - The FreeBSD Project |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 3:15:45 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 0E89C1526C for ; Sun, 5 Dec 1999 03:15:43 -0800 (PST) (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 DAA12742; Sun, 5 Dec 1999 03:16:27 -0800 Date: Sun, 5 Dec 1999 03:16:27 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: not so fast Fast SCSI? In-Reply-To: <199912051103.MAA66960@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 5 Dec 1999, Wilko Bulte wrote: > As Matthew Jacob wrote ... > > > This is not correctly negotiating out of async mode. I cannot deal with > > this for several days. I would suspect that NVRAM settings are pooched- > > try disabling them by doing > > > > set isp_nonvram=1 > > That did not help. But running the eeromcfg.exe utility from ARC and > setting up all devices for Ultra/Fast & Wide mode made all the difference :) Ack! poop! The isp_nonvram=(1< X-Sender: groudier@localhost To: "David O'Brien" , "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Addendum to sym driver integration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-34455191-944408684=:340" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-34455191-944408684=:340 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE David, I have attached to this mail a diff against -CURRENT(19991204/??????) that should allow you to complete integration of the sym driver into FreeBSD-CURRENT.=20 By the way I have some news about SYM53C1010 based PCI-SCSI controllers being planned by LSILOGIC to be available January the 10th.=20 This makes the sym driver candidate to the latest FreeBSD-3.X level for user, that will have such a controller, to be able to update their production systems or install their O/S without useless complexity. Speaking about myself, not having the driver also merged with =20 FreeBSD-3.X implies that I still have to maintain separate patches for this branch. Driver changes: --------------- New: - The C1010 stepping B0 (Rev 1) tested ok for DT transfers=20 without the U3EN broken bit work-around enabled. Bug fixes: * sym_hipd.c - Fix a bug in sym_evaluate_dp() that made MDP not work. (Btw, MDP is actually not tested due to lack of hardware using this feature). - Chip table changed for the C1010 B0 to be supported without=20 the U3EN bit work-around enabled (And a tiny driver bug fixed=20 for this to work). Other changes: * sym_conf.h sym_defs.h sym_hipd.c - Add SYMSETUP_MAX_LUN option. - Add SYMSETUP_LP_PROBE_MAP option. This option may be used to=20 tell the driver about chips that are to be claimed with lower=20 priority than old pci bus based driver (typically the ncr). - Document in sym_conf.h driver options that can be specified=20 from the kernel configuration file. - Sim vendor id changed to "FreeBSD". Kernel changes (proposed): -------------------------- * scsi_all.c - Add FAST-80 timing to the scsi syncrates table. * options - Define (with minimal comments) the following options for opt_sym.h. SYMSETUP_LP_PROBE_MAP SYMSETUP_SCSI_DIFF SYMSETUP_PCI_PARITY SYMSETUP_MAX_LUN Default values should fit most situations, but some rare cases may=20 require such options to be tweaked by user. (The LINT file is not updated by the attached diffs) Notes: ------ The new README.sym file is not yet there since I haven't had time enough this weekend for completing it. The Ultra3 FAST-80 DT data transfer support needs the syncrates table in scsi_all.c to be updated. The real full support of SPI3/DT needs CAM enhancements Justin is working on, prior to doing corresponding changes (if any required) in SIMs. The FAST-80 sync rate seems to me not to make problems. If, for some reason, this change in scsi_all.c will be refused, you may want to let me know. Thanks. Regards, G=E9rard. --8323328-34455191-944408684=:340 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sym-1.0.0.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LS0tIC4uL2N1cnJlbnQtb3JpZy9zcmMvc3lzL2NhbS9zY3NpL3Njc2lfYWxs LmMJU2F0IEF1ZyAyOCAwMDo0MDo0NSAxOTk5DQorKysgc3JjL3N5cy9jYW0v c2NzaS9zY3NpX2FsbC5jCVNhdCBEZWMgIDQgMjI6MjY6MjUgMTk5OQ0KQEAg LTIzOTQsNiArMjM5NCw3IEBADQogICAgICAgICB1X2ludCBwZXJpb2RfZmFj dG9yOw0KICAgICAgICAgdV9pbnQgcGVyaW9kOwkvKiBpbiAxMHRocyBvZiBu cyAqLw0KIH0gc2NzaV9zeW5jcmF0ZXNbXSA9IHsNCisgICAgICAgIHsgMHgw OSwgMTI1IH0sCS8qIEZBU1QtODAgKi8NCiAgICAgICAgIHsgMHgwYSwgMjUw IH0sDQogICAgICAgICB7IDB4MGIsIDMwMyB9LA0KICAgICAgICAgeyAweDBj LCA1MDAgfQ0KLS0tIC4uL2N1cnJlbnQtb3JpZy9zcmMvc3lzL2NvbmYvb3B0 aW9ucwlGcmkgRGVjICAzIDIxOjIxOjQ1IDE5OTkNCisrKyBzcmMvc3lzL2Nv bmYvb3B0aW9ucwlTYXQgRGVjICA0IDIyOjE5OjI1IDE5OTkNCkBAIC0xNzQs NiArMTc0LDE5IEBADQogIyBPcHRpb25zIHVzZWQgb25seSBpbiBjYW0vc2Nz aS9zY3NpX3B0LmMNCiBTQ1NJX1BUX0RFRkFVTFRfVElNRU9VVAlvcHRfcHQu aA0KIA0KKyMgT3B0aW9ucyB1c2VkIGluIGRldi9zeW0vIChTeW1iaW9zIFND U0kgZHJpdmVyKS4NCitTWU1TRVRVUF9MUF9QUk9CRV9NQVAJb3B0X3N5bS5o CSMtTG93IFByaW9yaXR5IFByb2JlIE1hcCAoYml0cykNCisJCQkJCSMgQWxs b3dzIHRoZSBuY3IgdG8gdGFrZSBwcmVjZWRlbmNlDQorCQkJCQkjIDEgKDE8 PDApIC0+IDgxMGEsIDg2MA0KKwkJCQkJIyAyICgxPDwxKSAtPiA4MjVhLCA4 NzUsIDg4NSwgODk1DQorCQkJCQkjIDQgKDE8PDIpIC0+IDg5NWEsIDg5Niwg MTUxMGQgDQorU1lNU0VUVVBfU0NTSV9ESUZGCW9wdF9zeW0uaAkjLUhWRCBz dXBwb3J0IGZvciA4MjVhLCA4NzUsIDg4NQ0KKwkJCQkJIyBkaXNhYmxlZDow IChkZWZhdWx0KSwgZW5hYmxlZDoxDQorU1lNU0VUVVBfUENJX1BBUklUWQlv cHRfc3ltLmgJIy1QQ0kgcGFyaXR5IGNoZWNraW5nDQorCQkJCQkjIGRpc2Fi bGVkOjAsIGVuYWJsZWQ6MSAoZGVmYXVsdCkNCitTWU1TRVRVUF9NQVhfTFVO CW9wdF9zeW0uaAkjLU51bWJlciBvZiBMVU5zIHN1cHBvcnRlZA0KKwkJCQkJ IyBkZWZhdWx0OjgsIHJhbmdlOlsxLi42NF0NCisNCiAjIE9wdGlvbnMgdXNl ZCBvbmx5IGluIHBjaS9uY3IuYw0KIFNDU0lfTkNSX0RFQlVHCQlvcHRfbmNy LmgNCiBTQ1NJX05DUl9NQVhfU1lOQwlvcHRfbmNyLmgNCi0tLSAuLi9jdXJy ZW50LW9yaWcvc3JjL3N5cy9kZXYvc3ltL3N5bV9jb25mLmgJU2F0IE5vdiAy NyAyMzozMjozNSAxOTk5DQorKysgc3JjL3N5cy9kZXYvc3ltL3N5bV9jb25m LmgJU3VuIERlYyAgNSAxMTozNjowOCAxOTk5DQpAQCAtNjUsOCArNjUsMTcg QEANCiANCiAvKg0KICAqICBTdXBwb3J0IGZvciBlYXJsaWVzdCBMU0k1M0Mx MDEwIGJvYXJkcy4NCi0gKiAgQ29tbWVyY2lhbCBjaGlwcyB3aWxsIGJlIGZp eGVkLCBhbmQgdGhlbiB0aGUgDQotICogIGNvcnJlc3BvbmRpbmcgY29kZSB3 aWxsIGdldCB1c2VsZXNzLg0KKyAqDQorICogIFRoaXMgb3B0aW9uIGVuYWJs ZXMgd29yay1hcm91bmRzIGZvciB0aGUgZXhwZXJpbWVudGFsIA0KKyAqICBD MTAxMCBjaGlwcyByZXZpc2lvbiAwIHRvIHdvcmsgaW4gRFQgbW9kZS4NCisg KiAgU2luY2UsIG9mZmljaWFsbHkgc3VwcG9ydGVkIGNoaXBzIChCMCBzdGVw cGluZyBhbmQgbGF0ZXIpDQorICogIGhhdmUgYmVlbiBmaXhlZCwgbm9ib2R5 LCBleGNlcHQgZHJpdmVyIG1haW50YWluZXJzLA0KKyAqICBzaG91bGQgZXZl ciBuZWVkZWQgdGhpcyBvcHRpb24gdG8gaGF2ZSBiZWVuIGRlZmluZWQuDQor ICogIFRoaXMgb3B0aW9uIGFuZCB0aGUgY29kZSBpdCBhZGRyZXNzZXMgd2ls bCBiZSByZW1vdmVkIA0KKyAqICBmcm9tIHRoZSBzb3VyY2UgaW4gc29tZSBs YXRlciB2ZXJzaW9uIG9mIHRoZSBkcml2ZXIuDQorICogIEJ5IHRoZSB3YXks IHRoZSA1M0MxMDEwIEIwIHN0ZXBwaW5nIChyZXYuIDEpIGhhcyBiZWVuIA0K KyAqICB0ZXN0ZWQgb2sgd2l0aCBVbHRyYTMgRFQgZGF0YSB0cmFuc2ZlcnMg dXNpbmcgdGhpcyBkcml2ZXIsDQorICogIHdpdGhvdXQgdGhlc2Ugd29yay1h cm91bmRzIGJlaW5nIGVuYWJsZWQuDQogICovDQogLyogI2RlZmluZQlTWU1D T05GX0JST0tFTl9VM0VOX1NVUFBPUlQgKi8NCiANCkBAIC0xMDIsNyArMTEx LDcgQEANCiAgKiAgQW55d2F5LCB0aGUgY29zdCBvZiBhY2NlcHRpbmcgdXAg dG8gNjQgbG9naWNhbCB1bml0IGlzIGxvdyBpbiANCiAgKiAgdGhpcyBkcml2 ZXIsIHRodXMgZ29pbmcgd2l0aCB0aGUgbWF4aW11bSBpcyBhY2NlcHRhYmxl Lg0KICAqLw0KLSNkZWZpbmUgU1lNQ09ORl9NQVhfTFVOCQkoOCkNCisjZGVm aW5lIFNZTUNPTkZfTUFYX0xVTgkJKDY0KQ0KIA0KIC8qDQogICogIE1heCBu dW1iZXIgb2YgSU8gY29udHJvbCBibG9ja3MgcXVldWVkIHRvIHRoZSBjb250 cm9sbGVyLg0KQEAgLTE1OCwxMCArMTY3LDExIEBADQogICogIE1heCBTQ1NJ IG9mZnNldC4NCiAgKi8NCiAjZGVmaW5lIFNZTVNFVFVQX01BWF9PRkZTCSg2 NCkNCisNCiAvKg0KICAqICBEZWZhdWx0IG51bWJlciBvZiB0YWdzLg0KICAq Lw0KLSNkZWZpbmUgU1lNU0VUVVBfTUFYX1RBRwkoNjQpDQorI2RlZmluZSBT WU1TRVRVUF9NQVhfVEFHCSgxPDxTWU1DT05GX01BWF9UQUdfT1JERVIpDQog DQogLyoNCiAgKiAgU1lNQklPUyBOVlJBTSBmb3JtYXQgc3VwcG9ydC4NCkBA IC0xNzUsOCArMTg1LDE1IEBADQogDQogLyoNCiAgKiAgUENJIHBhcml0eSBj aGVja2luZy4NCisgKiAgSXQgc2hvdWxkIG5vdCBiZSBhbiBvcHRpb24sIGJ1 dCBzb21lIHBvb3Igb3IgYnJva2VuIA0KKyAqICBQQ0ktSE9TVCBicmlkZ2Vz IGhhdmUgYmVlbiByZXBvcnRlZCB0byBtYWtlIHByb2JsZW1zIA0KKyAqICB3 aGVuIHRoaXMgZmVhdHVyZSBpcyBlbmFibGVkLg0KKyAqICBTZXR0aW5nIHRo aXMgb3B0aW9uIHRvIDAgdGVsbHMgdGhlIGRyaXZlciBub3QgdG8gDQorICog IGVuYWJsZSB0aGUgY2hlY2tpbmcgYWdhaW5zdCBQQ0kgcGFyaXR5Lg0KICAq Lw0KKyNpZm5kZWYgU1lNU0VUVVBfUENJX1BBUklUWQ0KICNkZWZpbmUgU1lN U0VUVVBfUENJX1BBUklUWQkoMSkNCisjZW5kaWYNCiANCiAvKg0KICAqICBT Q1NJIHBhcml0eSBjaGVja2luZy4NCkBAIC0xODksOSArMjA2LDMzIEBADQog I2RlZmluZSBTWU1TRVRVUF9TQ1NJX0xFRAkoMCkNCiANCiAvKg0KLSAqICBT Q1NJIGRpZmZlcmVudGlhbC4NCisgKiAgU0NTSSBIaWdoIFZvbHRhZ2UgRGlm ZmVyZW50aWFsIHN1cHBvcnQuDQorICoNCisgKiAgSFZEL0xWRC9TRSBjYXBh YmxlIGNvbnRyb2xsZXJzICg4OTUsIDg5NUEsIDg5NiwgMTAxMCkgDQorICog IHJlcG9ydCB0aGUgYWN0dWFsIFNDU0kgQlVTIG1vZGUgZnJvbSB0aGUgU1RF U1Q0IElPIA0KKyAqICByZWdpc3Rlci4NCisgKg0KKyAqICBCdXQgZm9yIEhW RC9TRSBvbmx5IGNhcGFibGUgY2hpcHMgKDgyNWEsIDg3NSwgODg1KSwgDQor ICogIHRoZSBkcml2ZXIgdXNlcyBzb21lIGhldXJpc3RpYyB0byBwcm9iZSBh Z2FpbnN0IEhWRC4gDQorICogIE5vcm1hbGx5LCB0aGUgY2hpcCBzZW5zZXMg dGhlIERJRkZTRU5TIHNpZ25hbCBhbmQgDQorICogIHNob3VsZCBzd2l0Y2gg aXRzIEJVUyB0cmFuY2VpdmVycyB0byBoaWdoIGltcGVkYW5jZSANCisgKiAg aW4gc2l0dWF0aW9uIG9mIHRoZSBkcml2ZXIgaGF2aW5nIGJlZW4gd3Jvbmcg YWJvdXQgDQorICogIHRoZSBhY3R1YWwgQlVTIG1vZGUuIE1heS1iZSwgdGhl IEJVUyBtb2RlIHByb2Jpbmcgb2YgDQorICogIHRoZSBkcml2ZXIgaXMgc2Fm ZSwgYnV0LCBnaXZlbiB0aGF0IGl0IG1heSBiZSBwYXJ0aWFsbHkgDQorICog IGJhc2VkIG9uIHNvbWUgcHJldmlvdXMgSU8gcmVnaXN0ZXIgc2V0dGluZ3Ms IGl0IA0KKyAqICBjYW5ub3QgYmUgc3RhdGVkIHNvLiBUaHVzLCBkZWNpc2lv biBoYXMgYmVlbiB0YWtlbiANCisgKiAgdG8gcmVxdWlyZSBhIHVzZXIgb3B0 aW9uIHRvIGJlIHNldCBmb3IgdGhlIERJRkYgcHJvYmluZyANCisgKiAgdG8g YmUgYXBwbGllZCBmb3IgdGhlIDgyNWEsIDg3NSBhbmQgODg1IGNoaXBzLg0K KyAqICANCisgKiAgVGhpcyBzZXR1cCBvcHRpb24gd29ya3MgYXMgZm9sbG93 czoNCisgKg0KKyAqICAgIDAgIC0+ICBIVkQgb25seSBzdXBwb3J0ZWQgZm9y IDg5NSwgODk1QSwgODk2LCAxMDEwLg0KKyAqICAgIDEgIC0+ICBIVkQgcHJv YmVkICBmb3IgODI1QSwgODc1LCA4ODUuDQorICogICAgMiAgLT4gIEhWRCBh c3N1bWVkIGZvciA4MjVBLCA4NzUsIDg4NSAobm90IGFkdmlzZWQpLg0KICAq Lw0KKyNpZm5kZWYgU1lNU0VUVVBfU0NTSV9ESUZGDQogI2RlZmluZSBTWU1T RVRVUF9TQ1NJX0RJRkYJKDApDQorI2VuZGlmDQogDQogLyoNCiAgKiAgSVJR IG1vZGUuDQpAQCAtMjI0LDUgKzI2NSw0MyBAQA0KICAqICBCdHcsIGFsbCBt eSB0ZXN0aW5ncyBvZiByZXNpZHVhbHMgaGF2ZSBzdWNjZWVkZWQuDQogICov DQogI2RlZmluZSBTWU1DT05GX1JFU0lEVUFMX1NVUFBPUlQgMQ0KKw0KKy8q DQorICogIFN1cHBvcnRlZCBtYXhpbXVtIG51bWJlciBvZiBMVU5zIHRvIGFu bm91bmNlIHRvIA0KKyAqICB0aGUgYWNjZXNzIG1ldGhvZC4NCisgKiAgVGhl IGRyaXZlciBzdXBwb3J0cyB1cCB0byA2NCBMVU5zIHBlciB0YXJnZXQgYXMg DQorICogIHJlcXVpcmVkIGJ5IFNQSS0yL1NQSS0zLiBIb3dldmVyIHNvbWUg U0NTSSBkZXZpY2VzICANCisgKiAgZGVzaWduZWQgcHJpb3IgdG8gdGhlc2Ug c3BlY2lmaWNhdGlvbnMgb3Igbm90IGJlaW5nICANCisgKiAgY29uZm9ybWFu dCBtYXkgYmUgaGlnaGx5IGNvbmZ1c2VkIHdoZW4gdGhleSBhcmUgDQorICog IGFza2VkIGFib3V0IGEgTFVOID4gNy4NCisgKi8NCisjaWZuZGVmIFNZTVNF VFVQX01BWF9MVU4NCisjZGVmaW5lIFNZTVNFVFVQX01BWF9MVU4JKDgpDQor I2VuZGlmDQorDQorLyoNCisgKiAgTG93IHByaW9yaXR5IHByb2JlIG1hcC4N CisgKiANCisgKiAgVGhpcyBvcHRpb24gaXMgdXNlZCBhcyBhIGJpdG1hcCB0 byB0ZWxsIHRoZSBkcml2ZXIgDQorICogIGFib3V0IGNoaXBzIHRoYXQgYXJl IHRvIGJlIGNsYWltZWQgd2l0aCBhIGxvdyBwcmlvcml0eSANCisgKiAgKC0y MDAwKSBieSB0aGUgcHJvYmUgbWV0aG9kLiBUaGlzIGFsbG93cyBhbnkgb3Ro ZXIgZHJpdmVyIA0KKyAqICB0aGF0IG1heSByZXR1cm4gc29tZSBoaWdoZXIg cHJpb3JpdHkgdmFsdWUgZm9yIHRoZSBzYW1lIA0KKyAqICBjaGlwcyB0byB0 YWtlIHByZWNlZGVuY2Ugb3ZlciB0aGlzIGRyaXZlciAoc3ltKS4NCisgKiAg VGhpcyBvcHRpb24gbWF5IGJlIHVzZWQgd2hlbiBib3RoIHRoZSBuY3IgZHJp dmVyIGFuZCB0aGlzIA0KKyAqICBkcml2ZXIgYXJlIGNvbmZpZ3VyZWQuDQor ICoNCisgKiAgQml0cyBhcmUgdG8gYmUgY29kZWQgYXMgZm9sbG93czoNCisg KiAgICAxICAtPiAgODEwYSwgODYwDQorICogICAgMiAgLT4gIDgyNWEsIDg3 NSwgODg1LCA4OTUNCisgKiAgICA0ICAtPiAgODk1YSwgODk2LCAxNTEwZA0K KyAqICAgIDggIC0+ICAxMDEwDQorICoNCisgKiAgRm9yIGV4YW1wbGUsIHZh bHVlIDUgdGVsbHMgdGhlIGRyaXZlciB0byBjbGFpbSBzdXBwb3J0IA0KKyAq ICBmb3IgODEwYSwgODYwLCA4OTVhLCA4OTYgYW5kIDE1MTBkIHdpdGggbG93 IHByaW9yaXR5LCANCisgKiAgYWxsb3dpbmcgdGhlIG5jciBkcml2ZXIgdG8g dGFrZSBwcmVjZWRlbmNlIGlmIGNvbmZpZ3VyZWQuDQorICovDQorI2lmbmRl ZiBTWU1TRVRVUF9MUF9QUk9CRV9NQVANCisjZGVmaW5lIFNZTVNFVFVQX0xQ X1BST0JFX01BUCAwDQorI2VuZGlmDQogDQogI2VuZGlmIC8qIFNZTV9DT05G X0ggKi8NCi0tLSAuLi9jdXJyZW50LW9yaWcvc3JjL3N5cy9kZXYvc3ltL3N5 bV9kZWZzLmgJU2F0IE5vdiAyNyAyMzozMjozNSAxOTk5DQorKysgc3JjL3N5 cy9kZXYvc3ltL3N5bV9kZWZzLmgJU2F0IERlYyAgNCAyMToyNDoxMSAxOTk5 DQpAQCAtOTEsNiArOTEsNyBAQA0KIAl1X2NoYXIJYnVyc3RfbWF4OwkvKiBs b2ctYmFzZS0yIG9mIG1heCBidXJzdCAqLw0KIAl1X2NoYXIJb2Zmc2V0X21h eDsNCiAJdV9jaGFyCW5yX2Rpdmlzb3I7DQorCXVfY2hhcglscF9wcm9iZV9i aXQ7DQogCXVfaW50CWZlYXR1cmVzOw0KICNkZWZpbmUgRkVfTEVEMAkJKDE8 PDApDQogI2RlZmluZSBGRV9XSURFCQkoMTw8MSkgICAgLyogV2lkZSBkYXRh IHRyYW5zZmVycyAqLw0KLS0tIC4uL2N1cnJlbnQtb3JpZy9zcmMvc3lzL2Rl di9zeW0vc3ltX2hpcGQuYwlTdW4gTm92IDI4IDAxOjM1OjI5IDE5OTkNCisr KyBzcmMvc3lzL2Rldi9zeW0vc3ltX2hpcGQuYwlTdW4gRGVjICA1IDE0OjIw OjEzIDE5OTkNCkBAIC01Niw3ICs1Niw3IEBADQogICogU1VDSCBEQU1BR0Uu DQogICovDQogDQotI2RlZmluZSBTWU1fRFJJVkVSX05BTUUJInN5bS0wLjEy LjAtMTk5OTExMjciDQorI2RlZmluZSBTWU1fRFJJVkVSX05BTUUJInN5bS0x LjAuMC0xOTk5MTIwNSINCiANCiAjaW5jbHVkZSA8cGNpLmg+DQogI2luY2x1 ZGUgPHN0ZGRlZi5oPgkvKiBGb3Igb2Zmc2V0b2YgKi8NCkBAIC0xMjIsNiAr MTIyLDcgQEANCiB0eXBlZGVmCXVfaW50MzJfdCB1MzI7DQogDQogLyogRHJp dmVyIGNvbmZpZ3VyYXRpb24gYW5kIGRlZmluaXRpb25zICovDQorI2luY2x1 ZGUgIm9wdF9zeW0uaCINCiAjaW5jbHVkZSA8ZGV2L3N5bS9zeW1fY29uZi5o Pg0KICNpbmNsdWRlIDxkZXYvc3ltL3N5bV9kZWZzLmg+DQogDQpAQCAtMzU2 LDcgKzM1Nyw3IEBADQogCSNkZWZpbmUgREVCVUdfRkxBR1Mgc3ltX2RlYnVn DQogI2Vsc2UNCiAvKgkjZGVmaW5lIERFQlVHX0ZMQUdTICgweDA2MzEpICov DQotCSNkZWZpbmUgREVCVUdfRkxBR1MgKDB4MDApDQorCSNkZWZpbmUgREVC VUdfRkxBR1MgKDB4MDAwMCkNCiAjZW5kaWYNCiAjZGVmaW5lIHN5bV92ZXJi b3NlCShucC0+dmVyYm9zZSkNCiANCkBAIC01MDkwLDEzICs1MDkxLDEyIEBA DQogCSAqLw0KIAlpZiAobnAtPmZlYXR1cmVzICYgRkVfQzEwKSB7DQogCQl1 dmFsID0gdXZhbCAmIH5VM0VOOw0KLQkJaWYgKGR0KQl7DQogI2lmbmRlZglT WU1DT05GX0JST0tFTl9VM0VOX1NVUFBPUlQNCisJCWlmIChkdCkJew0KIAkJ CWFzc2VydChucC0+ZmVhdHVyZXMgJiBGRV9VM0VOKTsNCi0jZWxzZQ0KIAkJ CXV2YWwgfD0gVTNFTjsNCi0jZW5kaWYNCiAJCX0NCisjZW5kaWYNCiAJfQ0K IAllbHNlIHsNCiAJCXd2YWwgPSB3dmFsICYgflVMVFJBOw0KQEAgLTY4Mjks OSArNjgyOSw5IEBADQogCX0NCiAJZWxzZSBpZiAoZHBfb2ZzID4gMCkgew0K IAkJd2hpbGUgKGRwX3NnIDwgU1lNQ09ORl9NQVhfU0cpIHsNCi0JCQkrK2Rw X3NnOw0KIAkJCXRtcCA9IHNjcl90b19jcHUoY3AtPnBoeXMuZGF0YVtkcF9z Z10uc2l6ZSk7DQogCQkJZHBfb2ZzIC09ICh0bXAgJiAweGZmZmZmZik7DQor CQkJKytkcF9zZzsNCiAJCQlpZiAoZHBfb2ZzIDw9IDApDQogCQkJCWJyZWFr Ow0KIAkJfQ0KQEAgLTkzNjQsMTAgKzkzNjQsMTIgQEANCiAJCWNwaS0+bWF4 X3RhcmdldCA9IChucC0+ZmVhdHVyZXMgJiBGRV9XSURFKSA/IDE1IDogNzsN CiAJCS8qIFNlbWFudGljIHByb2JsZW06KUxVTiBudW1iZXIgbWF4ID0gbWF4 IG51bWJlciBvZiBMVU5zIC0gMSAqLw0KIAkJY3BpLT5tYXhfbHVuID0gU1lN Q09ORl9NQVhfTFVOLTE7DQorCQlpZiAoU1lNU0VUVVBfTUFYX0xVTiA8IFNZ TUNPTkZfTUFYX0xVTikNCisJCQljcGktPm1heF9sdW4gPSBTWU1TRVRVUF9N QVhfTFVOLTE7DQogCQljcGktPmJ1c19pZCA9IGNhbV9zaW1fYnVzKHNpbSk7 DQogCQljcGktPmluaXRpYXRvcl9pZCA9IG5wLT5teWFkZHI7DQogCQljcGkt PmJhc2VfdHJhbnNmZXJfc3BlZWQgPSAzMzAwOw0KLQkJc3RybmNweShjcGkt PnNpbV92aWQsICJHZXJhcmQgUm91ZGllciIsIFNJTV9JRExFTik7DQorCQlz dHJuY3B5KGNwaS0+c2ltX3ZpZCwgIkZyZWVCU0QiLCBTSU1fSURMRU4pOw0K IAkJc3RybmNweShjcGktPmhiYV92aWQsICJTeW1iaW9zIiwgSEJBX0lETEVO KTsNCiAJCXN0cm5jcHkoY3BpLT5kZXZfbmFtZSwgY2FtX3NpbV9uYW1lKHNp bSksIERFVl9JRExFTik7DQogCQljcGktPnVuaXRfbnVtYmVyID0gY2FtX3Np bV91bml0KHNpbSk7DQpAQCAtOTUxNSw2MCArOTUxNyw2MCBAQA0KICNlbmRp ZiAvKiBGcmVlQlNEXzRfQnVzICovDQogDQogc3RhdGljIHN0cnVjdCBzeW1f cGNpX2NoaXAgc3ltX3BjaV9kZXZfdGFibGVbXSA9IHsNCi0ge1BDSV9JRF9T WU01M0M4MTAsIDB4MGYsICI4MTAiLCA0LCAgOCwgNCwNCisge1BDSV9JRF9T WU01M0M4MTAsIDB4MGYsICI4MTAiLCA0LCA4LCA0LCAwLA0KICBGRV9FUkx9 DQogICwNCi0ge1BDSV9JRF9TWU01M0M4MTAsIDB4ZmYsICI4MTBhIiwgNCwg IDgsIDQsDQorIHtQQ0lfSURfU1lNNTNDODEwLCAweGZmLCAiODEwYSIsIDQs ICA4LCA0LCAxLA0KICBGRV9DQUNIRV9TRVR8RkVfTERTVFJ8RkVfUEZFTnxG RV9CT0Z9DQogICwNCi0ge1BDSV9JRF9TWU01M0M4MjUsIDB4MGYsICI4MjUi LCA2LCAgOCwgNCwNCisge1BDSV9JRF9TWU01M0M4MjUsIDB4MGYsICI4MjUi LCA2LCAgOCwgNCwgMCwNCiAgRkVfV0lERXxGRV9CT0Z8RkVfRVJMfEZFX0RJ RkZ9DQogICwNCi0ge1BDSV9JRF9TWU01M0M4MjUsIDB4ZmYsICI4MjVhIiwg NiwgIDgsIDQsDQorIHtQQ0lfSURfU1lNNTNDODI1LCAweGZmLCAiODI1YSIs IDYsICA4LCA0LCAyLA0KICBGRV9XSURFfEZFX0NBQ0hFMF9TRVR8RkVfQk9G fEZFX0RGU3xGRV9MRFNUUnxGRV9QRkVOfEZFX1JBTXxGRV9ESUZGfQ0KICAs DQotIHtQQ0lfSURfU1lNNTNDODYwLCAweGZmLCAiODYwIiwgIDQsICA4LCA1 LA0KKyB7UENJX0lEX1NZTTUzQzg2MCwgMHhmZiwgIjg2MCIsIDQsICA4LCA1 LCAxLA0KICBGRV9VTFRSQXxGRV9DTEs4MHxGRV9DQUNIRV9TRVR8RkVfQk9G fEZFX0xEU1RSfEZFX1BGRU59DQogICwNCi0ge1BDSV9JRF9TWU01M0M4NzUs IDB4MDEsICI4NzUiLCAgNiwgMTYsIDUsDQorIHtQQ0lfSURfU1lNNTNDODc1 LCAweDAxLCAiODc1IiwgNiwgMTYsIDUsIDIsDQogIEZFX1dJREV8RkVfVUxU UkF8RkVfQ0xLODB8RkVfQ0FDSEUwX1NFVHxGRV9CT0Z8RkVfREZTfEZFX0xE U1RSfEZFX1BGRU58DQogIEZFX1JBTXxGRV9ESUZGfQ0KICAsDQotIHtQQ0lf SURfU1lNNTNDODc1LCAweGZmLCAiODc1IiwgIDYsIDE2LCA1LA0KKyB7UENJ X0lEX1NZTTUzQzg3NSwgMHhmZiwgIjg3NSIsIDYsIDE2LCA1LCAyLA0KICBG RV9XSURFfEZFX1VMVFJBfEZFX0RCTFJ8RkVfQ0FDSEUwX1NFVHxGRV9CT0Z8 RkVfREZTfEZFX0xEU1RSfEZFX1BGRU58DQogIEZFX1JBTXxGRV9ESUZGfQ0K ICAsDQotIHtQQ0lfSURfU1lNNTNDODc1XzIsMHhmZiwgIjg3NV8yIiwgNiwg MTYsIDUsDQorIHtQQ0lfSURfU1lNNTNDODc1XzIsIDB4ZmYsICI4NzUiLCA2 LCAxNiwgNSwgMiwNCiAgRkVfV0lERXxGRV9VTFRSQXxGRV9EQkxSfEZFX0NB Q0hFMF9TRVR8RkVfQk9GfEZFX0RGU3xGRV9MRFNUUnxGRV9QRkVOfA0KICBG RV9SQU18RkVfRElGRn0NCiAgLA0KLSB7UENJX0lEX1NZTTUzQzg4NSwgMHhm ZiwgIjg4NSIsICA2LCAxNiwgNSwNCisge1BDSV9JRF9TWU01M0M4ODUsIDB4 ZmYsICI4ODUiLCA2LCAxNiwgNSwgMiwNCiAgRkVfV0lERXxGRV9VTFRSQXxG RV9EQkxSfEZFX0NBQ0hFMF9TRVR8RkVfQk9GfEZFX0RGU3xGRV9MRFNUUnxG RV9QRkVOfA0KICBGRV9SQU18RkVfRElGRn0NCiAgLA0KLSB7UENJX0lEX1NZ TTUzQzg5NSwgMHhmZiwgIjg5NSIsICA2LCAzMSwgNywNCisge1BDSV9JRF9T WU01M0M4OTUsIDB4ZmYsICI4OTUiLCA2LCAzMSwgNywgMiwNCiAgRkVfV0lE RXxGRV9VTFRSQTJ8RkVfUVVBRHxGRV9DQUNIRV9TRVR8RkVfQk9GfEZFX0RG U3xGRV9MRFNUUnxGRV9QRkVOfA0KICBGRV9SQU18RkVfTENLRlJRfQ0KICAs DQotIHtQQ0lfSURfU1lNNTNDODk2LCAweGZmLCAiODk2IiwgIDYsIDMxLCA3 LA0KKyB7UENJX0lEX1NZTTUzQzg5NiwgMHhmZiwgIjg5NiIsIDYsIDMxLCA3 LCA0LA0KICBGRV9XSURFfEZFX1VMVFJBMnxGRV9RVUFEfEZFX0NBQ0hFX1NF VHxGRV9CT0Z8RkVfREZTfEZFX0xEU1RSfEZFX1BGRU58DQogIEZFX1JBTXxG RV9SQU04S3xGRV82NEJJVHxGRV9JTzI1NnxGRV9OT1BNfEZFX0xFREN8RkVf TENLRlJRfQ0KICAsDQotIHtQQ0lfSURfU1lNNTNDODk1QSwgMHhmZiwgIjg5 NWEiLCAgNiwgMzEsIDcsDQorIHtQQ0lfSURfU1lNNTNDODk1QSwgMHhmZiwg Ijg5NWEiLCA2LCAzMSwgNywgNCwNCiAgRkVfV0lERXxGRV9VTFRSQTJ8RkVf UVVBRHxGRV9DQUNIRV9TRVR8RkVfQk9GfEZFX0RGU3xGRV9MRFNUUnxGRV9Q RkVOfA0KICBGRV9SQU18RkVfUkFNOEt8RkVfNjRCSVR8RkVfSU8yNTZ8RkVf Tk9QTXxGRV9MRURDfEZFX0xDS0ZSUX0NCiAgLA0KLSB7UENJX0lEX0xTSTUz QzEwMTAsIDB4NDUsICIxMDEwIiwgIDYsIDYyLCA3LA0KKyB7UENJX0lEX0xT STUzQzEwMTAsIDB4MDAsICIxMDEwIiwgNiwgNjIsIDcsIDgsDQogIEZFX1dJ REV8RkVfVUxUUkEzfEZFX1FVQUR8RkVfQ0FDSEVfU0VUfEZFX0JPRnxGRV9E RkJDfEZFX0xEU1RSfEZFX1BGRU58DQogIEZFX1JBTXxGRV9SQU04S3xGRV82 NEJJVHxGRV9JTzI1NnxGRV9OT1BNfEZFX0xFREN8RkVfUENJNjZ8RkVfQ1JD fA0KICBGRV9DMTB9DQogICwNCi0ge1BDSV9JRF9MU0k1M0MxMDEwLCAweGZm LCAiMTAxMCIsICA2LCA2MiwgNywNCisge1BDSV9JRF9MU0k1M0MxMDEwLCAw eGZmLCAiMTAxMCIsIDYsIDYyLCA3LCA4LA0KICBGRV9XSURFfEZFX1VMVFJB M3xGRV9RVUFEfEZFX0NBQ0hFX1NFVHxGRV9CT0Z8RkVfREZCQ3xGRV9MRFNU UnxGRV9QRkVOfA0KICBGRV9SQU18RkVfUkFNOEt8RkVfNjRCSVR8RkVfSU8y NTZ8RkVfTk9QTXxGRV9MRURDfEZFX1BDSTY2fEZFX0NSQ3wNCiAgRkVfQzEw fEZFX1UzRU59DQogICwNCi0ge1BDSV9JRF9MU0k1M0MxNTEwRCwgMHhmZiwg IjE1MTBEIiwgIDYsIDMxLCA3LA0KKyB7UENJX0lEX0xTSTUzQzE1MTBELCAw eGZmLCAiMTUxMGQiLCA2LCAzMSwgNywgNCwNCiAgRkVfV0lERXxGRV9VTFRS QTJ8RkVfUVVBRHxGRV9DQUNIRV9TRVR8RkVfQk9GfEZFX0RGU3xGRV9MRFNU UnxGRV9QRkVOfA0KICBGRV9SQU18RkVfSU8yNTZ8RkVfTEVEQ30NCiB9Ow0K QEAgLTk2MzQsNyArOTYzNiw3IEBADQogCWNoaXAgPSBzeW1fZmluZF9wY2lf Y2hpcChkZXYpOw0KIAlpZiAoY2hpcCkgew0KIAkJZGV2aWNlX3NldF9kZXNj KGRldiwgY2hpcC0+bmFtZSk7DQotCQlyZXR1cm4gMDsNCisJCXJldHVybiAo Y2hpcC0+bHBfcHJvYmVfYml0ICYgU1lNU0VUVVBfTFBfUFJPQkVfTUFQKSA/ IC0yMDAwIDogMDsNCiAJfQ0KIAlyZXR1cm4gRU5YSU87DQogfQ0K --8323328-34455191-944408684=:340-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 9:48: 1 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 BDF5E14DCA for ; Sun, 5 Dec 1999 09:47:58 -0800 (PST) (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 JAA13842; Sun, 5 Dec 1999 09:49:12 -0800 Date: Sun, 5 Dec 1999 09:49:12 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: freebsd-scsi@freebsd.org Subject: Re: not so fast Fast SCSI? In-Reply-To: <199912051305.OAA68255@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Ack! poop! The isp_nonvram=(1< > shouldn't ask the NVRAM for settings, but I guess it still asks the > > F/W what the current settings are and I guess they got hauled along. > > Seems like it. Is this a bug or a feature? Bug. With what I told you. It should have been isp_no_nvram= Settings are: := bit mask of units to set a feature for isp_disable disable unit(s)- they attach but don't probe isp_mem_map map memory space isp_io_map map io space option SCSI_ISP_PREFER_MEM_MAP sets an initial mem map preference, otherwise io mapping is preferred isp_no_fwload don't load firmware isp_fwload units to *load* f/w for (if avail) option SCSI_ISP_NO_FWLOAD_MASK sets an initial value for isp_no_fwload. option ISP_COMPILE_1020_FW compiles in 1020/1040 f/w. option ISP_COMPILE_1080_FW compiles in 1080/1240/1280 f/w. option ISP_COMPILE_2100_FW compiles in 2100 f/w. option ISP_COMPILE_2200_FW compiles in 2200 f/w. option ISP_COMPILE_FW compiles in all f/w. isp_no_nvram don't look at nvram or get current device params isp_nvram loat at nvram and get device params option SCSI_ISP_NO_NVRAM_MASK sets an initial value for isp_no_nvram. isp_fcduplex set full duplex (FC only) isp_fcduplex disable full duplex (FC only) option SCSI_ISP_FCDUPLEX sets an initial value for isp_fcduplex isp_wwn set World Wide Name option SCSI_ISP_WWN sets an overriding value for isp_wwn isp_debug set initial debugging value for all boards > (sidenote: your TZ==PST, shouldn't you be in bed? ;-) ;-) Was. Too short a time. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 10:35:10 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 C92DB14BD0; Sun, 5 Dec 1999 10:35:06 -0800 (PST) (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 KAA14034; Sun, 5 Dec 1999 10:36:13 -0800 Date: Sun, 5 Dec 1999 10:36:13 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ISP firmware compiled in as a default.... In-Reply-To: <199912042142.WAA88557@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (late followup)> > > However, I had a bit of a hard time with the SRM loaded f/w (and this is > > the latest) when I had both an internal drive and 2 external tape drives. > > This problem went away when I went back to compiling in the f/w which then > > downloaded. > > Did you have both internal AND external devices on the same KZPBA card? > FYI: we (== Compaq) don't support this. Obviously this decision is based > on the f/w that is in the SRM code. Tests have shown it really does not > work well when both internal and external devices are present on the same > card. YMMV of course and I obviously don't know what was biting you. Wasn't a standard KZPBA, but that's not the high order bit. If the f/w figures out there's something on both internal and external connectors, it's supposed to drop the pullups. That's why the 7.65 f/w is a lot better than the 5.XXX f/w- in this case. >,,, > > So, I'm in a bit of a quandary now as to what the right thing to do is. > > Don't shoot me: the right thing to do is to make it possible to boot ... I won't shoot you, but it doesn't help me answer the question of 'should f/w be compiled in by default'. I suppose Mike answered it best about checking sizes. >... > Hm. The DEC-sanctioned cards (as far as SRM booting goes, so for > system disks) only use 1040's if I'm not mistaken. So this might be the > most practical short-term solution. How much would 1040-only f/w > add to the installation kernel ? Actually, the latest 4100 f/w (at least the one I installed at NASA/Ames) recognizes the 2100, but won't boot from it. Nyah, Nyah! PTI PCI-470 and Anatres Qlogic 2100 clones have fcode in them and you can boot from them on sparc! -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 10:38: 9 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 52F4A14BD0; Sun, 5 Dec 1999 10:38:07 -0800 (PST) (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 KAA14053; Sun, 5 Dec 1999 10:39:21 -0800 Date: Sun, 5 Dec 1999 10:39:21 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ISP firmware compiled in as a default.... 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 > >... > > Hm. The DEC-sanctioned cards (as far as SRM booting goes, so for > > system disks) only use 1040's if I'm not mistaken. So this might be the > > most practical short-term solution. How much would 1040-only f/w > > add to the installation kernel ? > > Actually, the latest 4100 f/w (at least the one I installed at NASA/Ames) > recognizes the 2100, but won't boot from it. Nyah, Nyah! PTI PCI-470 > and Anatres Qlogic 2100 clones have fcode in them and you can boot from > them on sparc! And that should have been 'Antares'. And, of course, BIOS booting works for these cards too (via WWN). *Groan*- don't tell me that this would be an argument for support ARC.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 13:53:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id E8A5915428; Sun, 5 Dec 1999 13:53:14 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA24738; Sun, 5 Dec 1999 22:31:23 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA72235; Sun, 5 Dec 1999 19:59:20 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199912051859.TAA72235@yedi.iaf.nl> Subject: Re: ISP firmware compiled in as a default.... In-Reply-To: from Matthew Jacob at "Dec 5, 1999 10:36:13 am" To: mjacob@feral.com Date: Sun, 5 Dec 1999 19:59:20 +0100 (CET) Cc: gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > > Did you have both internal AND external devices on the same KZPBA card? > > FYI: we (== Compaq) don't support this. Obviously this decision is based > > on the f/w that is in the SRM code. Tests have shown it really does not > > work well when both internal and external devices are present on the same > > card. YMMV of course and I obviously don't know what was biting you. > > Wasn't a standard KZPBA, but that's not the high order bit. If the f/w > figures out there's something on both internal and external connectors, > it's supposed to drop the pullups. That's why the 7.65 f/w is a lot better > than the 5.XXX f/w- in this case. Hm. Well the reasons I heared within Compaq was that they did not like the signal quality on the SCSI bus when both internal and external devices are present. Ultra SCSI speeds obviously make this worse, as do marginal cables etc. > > > So, I'm in a bit of a quandary now as to what the right thing to do is. > > > > Don't shoot me: the right thing to do is to make it possible to boot > > ... I won't shoot you, but it doesn't help me answer the question of > 'should f/w be compiled in by default'. I suppose Mike answered it best > about checking sizes. Clearer answer: my vote is to include the 1040 f/w > > Hm. The DEC-sanctioned cards (as far as SRM booting goes, so for > > system disks) only use 1040's if I'm not mistaken. So this might be the > > most practical short-term solution. How much would 1040-only f/w > > add to the installation kernel ? > > Actually, the latest 4100 f/w (at least the one I installed at NASA/Ames) > recognizes the 2100, but won't boot from it. Nyah, Nyah! PTI PCI-470 Probably SRM is picky somehow. -- | / o / / _ Arnhem, The Netherlands - The FreeBSD Project |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 14:38:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B74FB14A01; Sun, 5 Dec 1999 14:38:32 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA27517; Sun, 5 Dec 1999 23:28:07 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA15055; Sun, 5 Dec 1999 23:27:43 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199912052227.XAA15055@yedi.iaf.nl> Subject: Re: ISP firmware compiled in as a default.... In-Reply-To: <199912050356.TAA17391@lestat.nas.nasa.gov> from Jason Thorpe at "Dec 4, 1999 7:56:44 pm" To: thorpej@nas.nasa.gov Date: Sun, 5 Dec 1999 23:27:43 +0100 (CET) Cc: mjacob@feral.com, gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Jason Thorpe wrote ... > On Sat, 4 Dec 1999 22:42:57 +0100 (CET) > Wilko Bulte wrote: > > > Don't shoot me: the right thing to do is to make it possible to boot > > FreeBSD/alpha from a CDROM. With or without Qlogic firmware FreeBSD/alpha > > is quickly getting too big to be really practical as far as floppy booting > > goes. NetBSD can do CDROM booting, but I don't really understand the > > issues around CDROM bootability. Having fixed the size problem the extra > > NetBSD can also boot a kernel split across multiple floppies. Our > libsa `ustarfs' is pretty cool: > > nbftp:thorpej 15$ ls -l > total 6256 > 1456 -rw-r--r-- 1 thorpej netbsd 1474560 Dec 4 19:05 disk1of2 > 816 -rw-r--r-- 1 thorpej netbsd 819200 Dec 4 19:05 disk2of2 > > ...that's a NetBSD/alpha install floppy set. Neat. One learns something new everyday :) I had used NetBSD install from a CDR before. -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 5 15:27:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id A820614D10 for ; Sun, 5 Dec 1999 15:27:08 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991205175916.45672@mojave.sitaranetworks.com> Date: Sun, 5 Dec 1999 17:59:16 -0500 From: Greg Lehey To: Stephen McKay , freebsd-scsi@FreeBSD.ORG Subject: Re: Administrivia: charter clarification question Reply-To: Greg Lehey References: <199912041637.CAA03403@nymph.detir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199912041637.CAA03403@nymph.detir.qld.gov.au>; from Stephen McKay on Sun, Dec 05, 1999 at 02:37:58AM +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 5 December 1999 at 2:37:58 +1000, Stephen McKay wrote: > In response to my recent thread "Tape driver problems" I was advised twice > by a respectable FreeBSD citizen that my posting was misfiled and should > have gone to -current. Quote: > > "If it's -CURRENT, talk about it on -CURRENT. That overrides anything else." > > It is my belief that scsi stuff should be discussed on -scsi no matter > whether it is -current, -stable, or some older release. Am I wrong? > The charter as it stands is rather thin: > >>>>> info freebsd-scsi > FREEBSD-SCSI SCSI subsystem > This is the mailing list for people working on the scsi subsystem > for FreeBSD. > > Please note that this is not a whinge, I am not after ammunition for an > "I told you so", and I'm not going to say who contacted me. I just want > the system to work smoothly. Well, I suppose I must be the "respectable FreeBSD citizen". It looks like my view are pretty much in the minority, so I'll accept the majority view. This doesn't mean I agree: I think you're more likely to get a good response on -CURRENT. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 6 7:51:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from paert.tse-online.de (paert.tse-online.de [194.97.69.172]) by hub.freebsd.org (Postfix) with SMTP id 8D59C15341 for ; Mon, 6 Dec 1999 07:51:10 -0800 (PST) (envelope-from ab@paert.tse-online.de) Received: (qmail 36707 invoked by uid 1000); 6 Dec 1999 15:53:20 -0000 Date: Mon, 6 Dec 1999 16:53:20 +0100 From: Andreas Braukmann To: freebsd-scsi@freebsd.org Subject: AHA 3985 ? Message-ID: <19991206165320.E4254@paert.tse-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Organization: TSE GmbH - Neue Medien Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, ... currently I'm shopping for a multi-channel SCSI-hostadapter. It doesn't need to be U2W. I might be able to put my hands on an three-channel AHA3985. The adaptec websites characterizes this model to be supported on Novell Netware only; and I wasn't able to find any further detailed information on it. Does anybody know this hostadapter in detail? Would the ahc-driver be able to handle the hostadapter? (I had a look at ahc_pci.c and afterall it seems to handle an adapter called 398XU ...) Thanks, Andreas -- : Anti-Spam Petition: http://www.politik-digital.de/spam/ : : PGP-Key: http://www.tse-online.de/~ab/public-key : : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 6 8: 8:10 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 4AA9A15319 for ; Mon, 6 Dec 1999 08:08:06 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id JAA10231; Mon, 6 Dec 1999 09:07:55 -0700 (MST) (envelope-from ken) Message-Id: <199912061607.JAA10231@panzer.kdm.org> Subject: Re: AHA 3985 ? In-Reply-To: <19991206165320.E4254@paert.tse-online.de> from Andreas Braukmann at "Dec 6, 1999 04:53:20 pm" To: braukmann@tse-online.de (Andreas Braukmann) Date: Mon, 6 Dec 1999 09:07:55 -0700 (MST) 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 Andreas Braukmann wrote... > Hi there, > > ... currently I'm shopping for a multi-channel SCSI-hostadapter. > It doesn't need to be U2W. I might be able to put my hands on an > three-channel AHA3985. The adaptec websites characterizes this model > to be supported on Novell Netware only; and I wasn't able to find any > further detailed information on it. > > Does anybody know this hostadapter in detail? > Would the ahc-driver be able to handle the hostadapter? > (I had a look at ahc_pci.c and afterall it seems to handle > an adapter called 398XU ...) You can use it as a SCSI adapter, but the RAID features won't be functional. 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 Dec 6 12: 8:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 7B7D4155F7 for ; Mon, 6 Dec 1999 12:07:53 -0800 (PST) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id PAA30895; Mon, 6 Dec 1999 15:07:53 -0500 (EST) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14412.6040.627711.418071@trooper.velocet.net> Date: Mon, 6 Dec 1999 15:07:52 -0500 (EST) To: freebsd-scsi@freebsd.org Subject: LVD Teckram card not LVD under FreeBSD. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have some of the 2940 U2W LVD cards... and a bunch of LVD drives with cabling. On the 2940, they all probe in FreeBSD as 80M/s. I also have a TekRAM card to try... and it's BIOS screen probes the drives as 80M/s LVD (it is an LVD card), but when FreeBSD probes the drives they come up as 40M/s Ultra-2. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 7 20:52: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mayhem.com (mayhem.com [204.254.116.10]) by hub.freebsd.org (Postfix) with ESMTP id C25E414C04; Tue, 7 Dec 1999 20:52:01 -0800 (PST) (envelope-from jacob@mayhem.com) Received: (from jacob@localhost) by mayhem.com (8.9.1/8.9.1) id XAA06171; Tue, 7 Dec 1999 23:51:57 -0500 (EST) (envelope-from jacob) From: Jacob DeGlopper Message-Id: <199912080451.XAA06171@mayhem.com> Subject: Re: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card In-Reply-To: <199911250558.WAA00813@panzer.kdm.org> from "Kenneth D. Merry" at "Nov 24, 1999 10:58:16 pm" To: ken@kdm.org (Kenneth D. Merry) Date: Tue, 7 Dec 1999 23:51:57 -0500 (EST) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Final followup. With an Adaptec 2940, the system boots fine with a CD in the drive. It was some strange interaction with the NCR card and the drive's response when there was a CD loaded at boot. > Jacob DeGlopper wrote... > > Followup on this problem. I have an Adaptec 2940 SCSI card on the way, > > which seems to be more of a standard, but maybe that's not the problem. > > I discovered that if there is no CD in the drive when I boot FreeBSD, > > it works fine. What does that indicate? > > > > cd0 at ncr0 bus 0 target 2 lun 0 > > cd0: Removable CD-ROM SCSI2 device > > cd0: 10.0MB/s transfers (10.0MHz, offset 8) > > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c > > losed > > > > Put a CD in, and you can mount it just fine and use it. Leave the CD in > > when you reboot, and it locks up with the same NCR timeout errors I > > was seeing below. > > This sounds like it may be a drive firmware problem, although it's > difficult to say for sure. How long does it take to mount the CD? How > long does it take for the error messages to pop up when there isn't a CD in > the drive? Mounting the CD once the system is up seems to be normal, and there weren't any errors or delays booting with an empty drive. > > > I am running FreeBSD 3.0-RELEASE. I have recently acquired a Yamaha > > > CRZ6416sz SCSI CD-RW drive. I have an existing SCSI chain with a > > > NCR 815 card, Seagate disk, and HP DAT drive; all those have been > > > working fine. > > > > > > When booting the system with the new drive installed, I get some errors, > > > and then the system halts. Running a kernel without the SCSI cd device > > > configured gets the CD-ROM recognized by the pass driver without errors. > > > I have double-checked the terminator, and tried other SCSI ids with no > > > change. The drive appears to work fine in Windows. I have also tried > > > adjusting the SCSI_DELAY timeout up to 20 seconds with no change. > > > > > > The specific errors I get are: > > > > > > cd0:ncr0:0:2:0: got CAM status 0x4a > > > fatal error, failed to attach to device (cd0:ncr0:0:2:0) removing device > > > entry > > Oooh, that's not good at all. Status 0x4a is a selection timeout. That > means the drive isn't responding to attempts to contact it over the SCSI > bus. > > > > I've also tried the drive in another FreeBSD system with an NCR 875 card, > > > and it failed with the same messages, as did booting with the 3.3 boot > > > disks. > > > > > > I haven't found anything very promising in the archives related to these > > > NCR timeout problems; does anyone have any ideas, or do I have to > > > go out and get a more expensive SCSI card? > > Well, since you've already ordered a 2940, it'll be good to see what > happens with that. The Adaptec driver is generally less buggy than the ncr > driver. > > Have you tried different CDs in the drive? It could be that there is > something about the CD you're using that makes the drive barf. It seemed to happen with all the CDs I tried. > This really sounds like a firmware issue of some sort with your CDROM drive, > although I'll be more confident in saying that once you've tried the drive > with an Adaptec controller. -- Jacob DeGlopper, FF/EMT-B, N3RHI jacob@mayhem.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 7 21:12:45 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 A088614EB0; Tue, 7 Dec 1999 21:12:42 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA27627; Tue, 7 Dec 1999 22:12:32 -0700 (MST) (envelope-from ken) Message-Id: <199912080512.WAA27627@panzer.kdm.org> Subject: Re: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card In-Reply-To: <199912080451.XAA06171@mayhem.com> from Jacob DeGlopper at "Dec 7, 1999 11:51:57 pm" To: jacob@mayhem.com (Jacob DeGlopper) Date: Tue, 7 Dec 1999 22:12:32 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions@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 Jacob DeGlopper wrote... > Final followup. With an Adaptec 2940, the system boots fine with a > CD in the drive. It was some strange interaction with the NCR card > and the drive's response when there was a CD loaded at boot. Well, that's not too surprising. > > Jacob DeGlopper wrote... > > > > I am running FreeBSD 3.0-RELEASE. I have recently acquired a Yamaha > > > > CRZ6416sz SCSI CD-RW drive. I have an existing SCSI chain with a > > > > NCR 815 card, Seagate disk, and HP DAT drive; all those have been > > > > working fine. It is possible that the problem with the NCR driver may have been fixed in a later release. It's hard to say for sure. In any case, I'm glad you got it working. 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 Dec 7 21:44:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id BB01215030 for ; Tue, 7 Dec 1999 21:44:31 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11vYNe-0002Lm-00 for freebsd-scsi@freebsd.org; Tue, 7 Dec 1999 20:07:06 -0800 Date: Tue, 7 Dec 1999 20:07:05 -0800 (PST) From: Tom To: freebsd-scsi@freebsd.org Subject: Disks that grow? 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 Let's say that I have a external RAID box that looks like a big disk to FreeBSD. Now, the RAID box supports online expansion. If I expand the size, the logical disk just gets bigger. What will FreeBSD do if it discovers that a disk that it is using just got bigger? I'd like to be able to use disklabel and create a new partition. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 7 21:58: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles551.castles.com [208.214.165.115]) by hub.freebsd.org (Postfix) with ESMTP id DF44A154C0 for ; Tue, 7 Dec 1999 21:58:00 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id WAA11783; Tue, 7 Dec 1999 22:00:06 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912080600.WAA11783@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tom Cc: freebsd-scsi@freebsd.org Subject: Re: Disks that grow? In-reply-to: Your message of "Tue, 07 Dec 1999 20:07:05 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 1999 22:00:06 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Let's say that I have a external RAID box that looks like a big disk to > FreeBSD. Now, the RAID box supports online expansion. If I expand the > size, the logical disk just gets bigger. > > What will FreeBSD do if it discovers that a disk that it is using just > got bigger? > > I'd like to be able to use disklabel and create a new partition. You can do this, yes. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 8 19:29: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191]) by hub.freebsd.org (Postfix) with ESMTP id A56031526E; Wed, 8 Dec 1999 19:28:52 -0800 (PST) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA10564; Wed, 8 Dec 1999 23:28:51 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 8 Dec 1999 23:28:51 -0400 (AST) From: The Hermit Hacker To: freebsd-scsi@freebsd.org Cc: mackley@tht.net, freebsd-stable@freebsd.org Subject: SCSI problem ... OS or just bus? 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 recently did two upgrades in the course of a few days...upgraded my 3.3-STABLE to a more recent version, and added hard drives onto the system...now I'm getting SCSI problems that make no sense :( The machine just hung once more, which its doing every few hours...I can get down to the debugger, but a 'trace' doesn't appear to show anyting, so I panic... ========== (da4:ahc0:0:8:0): Other SCB Timeout (da4:ahc0:0:8:0): SCB 0xeb - timed out in dataout phase, SEQADDR == 0x10f (da4:ahc0:0:8:0): Other SCB Timeout (da2:ahc0:0:5:0): SCB 0x24 - timed out in dataout phase, SEQADDR == 0x10f (da2:ahc0:0:5:0): BDR message in message buffer (da2:ahc0:0:5:0): SCB 0x92 - timed out in dataout phase, SEQADDR == 0x10f (da2:ahc0:0:5:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 98 SCBs aborted ^C^C^CStopped at siointr1+0xc5: jmp siointr1+0x1c9 db> where No such command db> list No such command db> ? Bad character ? db> help print p examine x search set write w delete d break dwatch watch step s continue c until next match trace call show ps gdb panic db> trace siointr1(c225d000,0,c021dc47,0,d6030010) at siointr1+0xc5 siointr(0,d6030010,77,d6034000,0) at siointr+0x13 Xfastintr4() at Xfastintr4+0x17 db> continue ^C^CStopped at siointr1+0xc5: jmp siointr1+0x1c9 db> trace siointr1(c225d000,0,c021dc47,0,d6030010) at siointr1+0xc5 siointr(0,d6030010,65,d6031000,0) at siointr+0x13 Xfastintr4() at Xfastintr4+0x17 db> panic panic: from debugger syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01ec14c stack pointer = 0x10:0xc025a5fc frame pointer = 0x10:0xc025a600 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault (da0:ahc0:0:0:0): Synchronize cache failed, status == 0xb, scsi status == 0x0 ====== I'm going to upgrade to the newest kernel, but none of the recent commit messages *sound* like they are applicable... A dmesg of the machine looks like, just in case either anything about the controller/drives pops out at anyone? ====== Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #0: Wed Dec 1 09:53:53 EST 1999 root@hub.org:/usr/src/sys/compile/hub_org Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 501139140 Hz CPU: Pentium III (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff,MMX,FXSR,> real memory = 805306368 (786432K bytes) avail memory = 780460032 (762168K bytes) Preloaded elf kernel "kernel" at 0xc02df000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x01 int a irq 14 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x01 int a irq 15 on pci0.10.0 ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 12 on pci0.11.0 xl0: Ethernet address: 00:60:08:c8:36:05 xl0: autoneg complete, link status good (half-duplex, 10Mbps) xl1: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 10 on pci0.12.0 xl1: Ethernet address: 00:60:97:d0:3c:f5 xl1: autoneg complete, link status good (half-duplex, 10Mbps) Probing for devices on PCI bus 1: vga0: rev 0x01 int a irq 10 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: UMC9008 [0x0890a355] Serial 0xab8d1af0 Comp ID: PNP80d6 [0xd680d041] ed1: address 00:c0:f0:1a:8d:ab, type NE2000 (16 bit) ed1 (edpnp sn 0xab8d1af0) at 0x220-0x23f irq 11 on isa Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <4 virtual consoles, flags=0x0> ed0 not found at 0x280 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default Waiting 2 seconds for SCSI devices to settle cda2 at ahc0 bus 0 target 5 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) da3 at ahc0 bus 0 target 6 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da4 at ahc0 bus 0 target 8 lun 0 da4: Fixed Direct Access SCSI-3 device da4: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da4: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C) da8 at ahc0 bus 0 target 12 lun 0 da8: Fixed Direct Access SCSI-3 device da8: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da8: 17366MB (35566000 512 byte sectors: 255H 63S/T 2213C) da5 at ahc0 bus 0 target 9 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da5: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da7 at ahc0 bus 0 target 11 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da7: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da6 at ahc0 bus 0 target 10 lun 0 da6: Fixed Direct Access SCSI-2 device da6: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da6: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) hanging root device to da0s1a WARNING: / was not properly dismounted ======= The QUANTUMs above have been in the machine for >1yr now and have worked, from what I can tell, without a hitch...its only since we added da4+ that we've seeing the problems...interaction problem between drive manufacturers? I seem to recall this sort of thing being a problem on older drives, but.. Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 8 19:42: 3 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 D298115552; Wed, 8 Dec 1999 19:41:53 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id UAA36152; Wed, 8 Dec 1999 20:41:41 -0700 (MST) (envelope-from ken) Message-Id: <199912090341.UAA36152@panzer.kdm.org> Subject: Re: SCSI problem ... OS or just bus? In-Reply-To: from The Hermit Hacker at "Dec 8, 1999 11:28:51 pm" To: scrappy@hub.org (The Hermit Hacker) Date: Wed, 8 Dec 1999 20:41:41 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG, mackley@tht.net, freebsd-stable@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 The Hermit Hacker wrote... > > I recently did two upgrades in the course of a few days...upgraded my > 3.3-STABLE to a more recent version, and added hard drives onto the > system...now I'm getting SCSI problems that make no sense :( > > The machine just hung once more, which its doing every few hours...I can > get down to the debugger, but a 'trace' doesn't appear to show anyting, so > I panic... > > ========== > (da4:ahc0:0:8:0): Other SCB Timeout > (da4:ahc0:0:8:0): SCB 0xeb - timed out in dataout phase, SEQADDR == 0x10f > (da4:ahc0:0:8:0): Other SCB Timeout > (da2:ahc0:0:5:0): SCB 0x24 - timed out in dataout phase, SEQADDR == 0x10f > (da2:ahc0:0:5:0): BDR message in message buffer > (da2:ahc0:0:5:0): SCB 0x92 - timed out in dataout phase, SEQADDR == 0x10f > (da2:ahc0:0:5:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 98 SCBs aborted [ ... ] > The QUANTUMs above have been in the machine for >1yr now and have worked, > from what I can tell, without a hitch...its only since we added da4+ that > we've seeing the problems...interaction problem between drive > manufacturers? I seem to recall this sort of thing being a problem on > older drives, but.. You have a cabling or termination problem. 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 Wed Dec 8 21:13:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 2C5171556D; Wed, 8 Dec 1999 21:12:59 -0800 (PST) (envelope-from igiveup@ix.netcom.com) Received: from ix.netcom.com (user-2ini8pe.dialup.mindspring.com [165.121.35.46]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA28198; Thu, 9 Dec 1999 00:12:51 -0500 (EST) Message-ID: <384F3A52.23868C19@ix.netcom.com> Date: Wed, 08 Dec 1999 21:12:50 -0800 From: Ben Speirs X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: The Hermit Hacker Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCSI problem ... OS or just bus? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Hermit Hacker wrote: > > I recently did two upgrades in the course of a few days...upgraded my > 3.3-STABLE to a more recent version, and added hard drives onto the > system...now I'm getting SCSI problems that make no sense :( > > The machine just hung once more, which its doing every few hours...I can > get down to the debugger, but a 'trace' doesn't appear to show anyting, so > I panic... > > ========== > (da4:ahc0:0:8:0): Other SCB Timeout > (da4:ahc0:0:8:0): SCB 0xeb - timed out in dataout phase, SEQADDR == 0x10f > (da4:ahc0:0:8:0): Other SCB Timeout > (da2:ahc0:0:5:0): SCB 0x24 - timed out in dataout phase, SEQADDR == 0x10f > (da2:ahc0:0:5:0): BDR message in message buffer > (da2:ahc0:0:5:0): SCB 0x92 - timed out in dataout phase, SEQADDR == 0x10f > (da2:ahc0:0:5:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 98 SCBs aborted Just another data point - A similar thing happened to me. I rebuilt the kernel and world back in September and my previously happy SCSI system started issuing the same type of messages. I saved the output of the system log. Portions of it are listed below: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #3: Fri Sep 24 21:00:39 PDT 1999 root@sloth:/usr/src/sys/compile/SLOTH [...trim...] ahc0: rev 0x00 int a irq 9 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs [...trim...] Waiting 8 seconds for SCSI devices to settle changing root device to da0s3a da0 at ahc0 bus 0 target 15 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) cd0 at ahc0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 3.300MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present Unexpected busfree. LASTPHASE == 0x1 SEQADDR == 0x153 ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xff, SEQ_FLAGS == 0x0 (cd0:ahc0:0:0:0): SCB 0x16 - timed out in datain phase, SEQADDR == 0x153 (cd0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:15:0): SCB 0x3 - timed out in datain phase, SEQADDR == 0x153 (da0:ahc0:0:15:0): BDR message in message buffer (da0:ahc0:0:15:0): SCB 0x3 - timed out in datain phase, SEQADDR == 0x153 (da0:ahc0:0:15:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 2 SCBs aborted fd0c: hard error reading fsbn 0 (No status) The problem occurred while accessing the da0 device and cd0 device at the same time. I could reproduce it at will, and almost instantly by copying a file from the CD-ROM to the hard drive. I could not reproduce the error with the older, slower NEC cd1 CD-ROM device. I rechecked all my termination and unplugged one device after another without any success. My guess was that the cd0 drive had gone goofy on me. The only thing I have not tried is replacing the cables. Since I had the other CD available my fix was to yank out the suspect device. It has been near the bottom of my 'things to do' list. Maybe we both got bit by the same "fix" that uncovered hidden hardware problems. Maybe not, it looks like you have problems with only Wide channel devices. -- -Ben Speirs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 9 2:51:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.powertech.no (intentia.powertech.no [195.159.0.220]) by hub.freebsd.org (Postfix) with ESMTP id 19C4F155C4; Thu, 9 Dec 1999 02:51:51 -0800 (PST) (envelope-from shamz@login2.powertech.no) Received: from login2.powertech.no (IDENT:root@login2.powertech.no [195.159.0.152]) by mail.powertech.no (8.9.3/8.8.5) with ESMTP id LAA20855; Thu, 9 Dec 1999 11:51:11 +0100 Received: (from shamz@localhost) by login2.powertech.no (8.9.3/8.9.3) id LAA11857; Thu, 9 Dec 1999 11:51:48 +0100 Date: Thu, 9 Dec 1999 11:51:48 +0100 From: Shaun Jurrens To: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCSI problem ... OS or just bus? Message-ID: <19991209115148.A10267@shamz.net> Mail-Followup-To: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi again, Sorry if this breaks the thread, because it is a little cut and paste from the html version. I also have had numerous problems with my wide drives. I have even updated the firmware and thought things were better, but last week a cvsup brought a screen full of scb timeouts. The termination is correct. The cables are ok. The firmware is updated. The version running is 3.3-Stable #0 or #1 (don't have the box in front of me). The logs are the same as everyone elses. The drives are two Quantum WideSCSI drives in sizes of ca. 1.0 and 4.3 GB. The controller is a pci card Adaptec 2940W. I would love to just change the hardware, but as I see IBM drives often have the same problem and I don't have $300 to spare right now, I am hoping the bug will be found before I fsck myself silly. The drives have caused a couple of crashes and clobbered everthing from logs to src to my X-server binaries, so it is more than a nuisance. BTW, the drives have no new bad sectors either. Sorry for the terseness in respect to the logs, but the last 10 mails with the same logs haven't lead to a resolution. They can be provided, but don't seem to be being used. -- Yours truly, Shaun D. Jurrens shaun@shamz.net IRCnick: shamz #chillout #unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 9 3:22: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.powertech.no (intentia.powertech.no [195.159.0.220]) by hub.freebsd.org (Postfix) with ESMTP id 0E74514DE8; Thu, 9 Dec 1999 03:21:58 -0800 (PST) (envelope-from shamz@login2.powertech.no) Received: from login2.powertech.no (IDENT:root@login2.powertech.no [195.159.0.152]) by mail.powertech.no (8.9.3/8.8.5) with ESMTP id MAA26361; Thu, 9 Dec 1999 12:21:19 +0100 Received: (from shamz@localhost) by login2.powertech.no (8.9.3/8.9.3) id MAA14172; Thu, 9 Dec 1999 12:21:56 +0100 Date: Thu, 9 Dec 1999 12:21:55 +0100 From: Shaun Jurrens To: Harlan Stenn Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCSI problem ... OS or just bus? Message-ID: <19991209122155.B10267@shamz.net> Mail-Followup-To: Harlan Stenn , freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org References: <19991209115148.A10267@shamz.net> <707.944736910@brown.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <707.944736910@brown.pfcs.com>; from Harlan Stenn on Thu, Dec 09, 1999 at 05:55:10AM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 09, 1999 at 05:55:10AM -0500, Harlan Stenn wrote: #> Is the SCSI chain too long? #> #> H There are only three drives internally with extra cooling on the flat band cable connected to the wide bus. The cable is ca. 30cm long. AFAIK, the scsi wide bus will work up to 1.3m, or maybe it was 3m, in any case the cable isn't too long. It all worked perfectly up until about the end of June, actually. The bugs seemed too random to put my finger on it, although I have really tried everything. I unfortunately don't have equipent to test what actually goes out from the bus or if everything there is ok, electronically speaking. I know the drives work reliably with winbloze (or at least did, since I don't use it very often anymore). -- Yours truly, Shaun D. Jurrens shaun@shamz.net IRCnick: shamz #chillout #unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 9 7:56:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191]) by hub.freebsd.org (Postfix) with ESMTP id AE8341570E; Thu, 9 Dec 1999 07:56:28 -0800 (PST) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA16335; Thu, 9 Dec 1999 11:56:26 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 9 Dec 1999 11:56:25 -0400 (AST) From: The Hermit Hacker To: Ben Speirs Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCSI problem ... OS or just bus? In-Reply-To: <384F3A52.23868C19@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As an update, so far...without turning news back on again, and after upgrading the kernel and doing a make world 12hrs ago, things have been stable *so far*...the first time this happened after we added the drives, it took about 17hrs or so...subsequent ones generally took 2-4hrs... I'm going to re-enable news this afternoon and see if adding that extra thrashing to the system causes a repeat of the problem or not... On Wed, 8 Dec 1999, Ben Speirs wrote: > The Hermit Hacker wrote: > > > > I recently did two upgrades in the course of a few days...upgraded my > > 3.3-STABLE to a more recent version, and added hard drives onto the > > system...now I'm getting SCSI problems that make no sense :( > > > > The machine just hung once more, which its doing every few hours...I can > > get down to the debugger, but a 'trace' doesn't appear to show anyting, so > > I panic... > > > > ========== > > (da4:ahc0:0:8:0): Other SCB Timeout > > (da4:ahc0:0:8:0): SCB 0xeb - timed out in dataout phase, SEQADDR == 0x10f > > (da4:ahc0:0:8:0): Other SCB Timeout > > (da2:ahc0:0:5:0): SCB 0x24 - timed out in dataout phase, SEQADDR == 0x10f > > (da2:ahc0:0:5:0): BDR message in message buffer > > (da2:ahc0:0:5:0): SCB 0x92 - timed out in dataout phase, SEQADDR == 0x10f > > (da2:ahc0:0:5:0): no longer in timeout, status = 34b > > ahc0: Issued Channel A Bus Reset. 98 SCBs aborted > > Just another data point - A similar thing happened to me. I rebuilt the > kernel and world back in September and my previously happy SCSI system > started issuing the same type of messages. I saved the output of the > system log. Portions of it are listed below: > > Copyright (c) 1992-1999 FreeBSD Inc. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights > reserved. > FreeBSD 3.3-STABLE #3: Fri Sep 24 21:00:39 PDT 1999 > root@sloth:/usr/src/sys/compile/SLOTH > [...trim...] > ahc0: rev 0x00 int a irq 9 on pci0.9.0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > [...trim...] > Waiting 8 seconds for SCSI devices to settle > changing root device to da0s3a > da0 at ahc0 bus 0 target 15 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 4149MB (8498506 512 byte sectors: 255H 63S/T 529C) > cd0 at ahc0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 8) > cd0: Attempt to query device size failed: NOT READY, Medium not present > cd1 at ahc0 bus 0 target 1 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: 3.300MB/s transfers > cd1: Attempt to query device size failed: NOT READY, Medium not present > > > Unexpected busfree. LASTPHASE == 0x1 > SEQADDR == 0x153 > ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE > RESET > SAVED_TCL == 0x0, ARG_1 == 0xff, SEQ_FLAGS == 0x0 > (cd0:ahc0:0:0:0): SCB 0x16 - timed out in datain phase, SEQADDR == 0x153 > (cd0:ahc0:0:0:0): Other SCB Timeout > (da0:ahc0:0:15:0): SCB 0x3 - timed out in datain phase, SEQADDR == 0x153 > (da0:ahc0:0:15:0): BDR message in message buffer > (da0:ahc0:0:15:0): SCB 0x3 - timed out in datain phase, SEQADDR == 0x153 > (da0:ahc0:0:15:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 2 SCBs aborted > fd0c: hard error reading fsbn 0 (No status) > > > The problem occurred while accessing the da0 device and cd0 device at > the same time. I could reproduce it at will, and almost instantly by > copying a file from the CD-ROM to the hard drive. I could not reproduce > the error with the older, slower NEC cd1 CD-ROM device. I rechecked all > my termination and unplugged one device after another without any > success. My guess was that the cd0 drive had gone goofy on me. The > only thing I have not tried is replacing the cables. Since I had the > other CD available my fix was to yank out the suspect device. It has > been near the bottom of my 'things to do' list. > > Maybe we both got bit by the same "fix" that uncovered hidden hardware > problems. Maybe not, it looks like you have problems with only Wide > channel devices. > > -- > -Ben Speirs > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 9 9:55:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 4E65E155E5; Thu, 9 Dec 1999 09:55:39 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id MAA14412; Thu, 9 Dec 1999 12:55:05 -0500 (EST) Reply-To: Randell Jesup To: Shaun Jurrens Cc: Harlan Stenn , freebsd-scsi@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: SCSI problem ... OS or just bus? References: <19991209115148.A10267@shamz.net> <707.944736910@brown.pfcs.com> <19991209122155.B10267@shamz.net> From: Randell Jesup Date: 09 Dec 1999 12:55:34 -0500 In-Reply-To: Shaun Jurrens's message of "Thu, 9 Dec 1999 12:21:55 +0100" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Shaun Jurrens writes: >On Thu, Dec 09, 1999 at 05:55:10AM -0500, Harlan Stenn wrote: >#> Is the SCSI chain too long? >#> >#> H >There are only three drives internally with extra cooling on the flat band >cable connected to the wide bus. The cable is ca. 30cm long. AFAIK, the scsi >wide bus will work up to 1.3m, or maybe it was 3m, in any case the cable isn't >too long. It all worked perfectly up until about the end of June, actually. >The bugs seemed too random to put my finger on it, although I have really >tried everything. I've seen SCSI cables go bad (usually after handling/plugging/etc, but sometimes apparently randomly, even in the days of 5MB/s 8-bit SCSI). The effects can be very strange. Also, active terminators could go bad or get damaged, etc (quite less likely). Another common often-forgotten failure mode is a power-supply problem. I've seen drives that will spin up and talk, and when you try to get them to read/seek, they'd reset or even head-crash - until you moved them to another power supply. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 10 7:59:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254]) by hub.freebsd.org (Postfix) with ESMTP id 7FC8914EBF for ; Fri, 10 Dec 1999 07:59:22 -0800 (PST) (envelope-from roberto@eurocontrol.fr) Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.43.2]) by matrix.eurocontrol.fr (Postfix) with ESMTP id 59EF023C7; Fri, 10 Dec 1999 16:59:21 +0100 (CET) (envelope-from roberto@caerdonn.eurocontrol.fr) Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193) id 7634A4E32; Fri, 10 Dec 1999 16:59:20 +0100 (CET) Date: Fri, 10 Dec 1999 16:59:20 +0100 From: Ollivier Robert To: FreeBSD SCSI Users' list Cc: groudier@club-internet.fr Subject: Problem with Ultra negociation Message-ID: <19991210165920.A385@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: FreeBSD 4.0-CURRENT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Since I updated my CURRENT on the 7th, both my SCSI disks seem to fail Ultra negociation even though I forced it in the Symbios BIOS... Any idea ? I'm using the sym driver: Before: -=-=- Nov 15 17:09:18 thendara /kernel: FreeBSD 4.0-CURRENT #1: Mon Nov 15 15:03:46 CET 1999 Nov 15 17:09:18 thendara /kernel: roberto@thendara.eurocontrol.fr:/src/src/sys/compile/CAERDONN Nov 15 17:09:18 thendara /kernel: Timecounter "i8254" frequency 1193182 Hz Nov 15 17:09:18 thendara /kernel: Timecounter "TSC" frequency 498747364 Hz Nov 15 17:09:18 thendara /kernel: CPU: Pentium III/Xeon (498.75-MHz 686-class CPU) Nov 15 17:09:18 thendara /kernel: Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Nov 15 17:09:18 thendara /kernel: Features=0x383fbff Nov 15 17:09:18 thendara /kernel: real memory = 268435456 (262144K bytes) Nov 15 17:09:18 thendara /kernel: avail memory = 257675264 (251636K bytes) Nov 15 17:09:18 thendara /kernel: Preloaded elf kernel "kernel" at 0xc02b3000. Nov 15 17:09:18 thendara /kernel: Pentium Pro MTRR support enabled Nov 15 17:09:18 thendara /kernel: npx0: on motherboard Nov 15 17:09:18 thendara /kernel: npx0: INT 16 interface ... Nov 15 17:09:19 thendara /kernel: sym0: <875> irq 9 at device 4.0 on pci2 Nov 15 17:09:19 thendara /kernel: sym0: Symbios NVRAM, ID 7, Fast-20, parity checking Nov 15 17:09:19 thendara /kernel: sym0: open drain IRQ line driver, using on-chip SRAM Nov 15 17:09:19 thendara /kernel: da0 at sym0 bus 0 target 0 lun 0 Nov 15 17:09:19 thendara /kernel: da0: Fixed Direct Access SCSI-3 device Nov 15 17:09:19 thendara /kernel: da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled Nov 15 17:09:19 thendara /kernel: da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) Nov 15 17:09:19 thendara /kernel: da1 at sym0 bus 0 target 1 lun 0 Nov 15 17:09:19 thendara /kernel: da1: Fixed Direct Access SCSI-2 device Nov 15 17:09:19 thendara /kernel: da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled Nov 15 17:09:19 thendara /kernel: da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) -=-=- Now: -=-=- Dec 7 14:13:48 caerdonn /kernel: Copyright (c) 1992-1999 The FreeBSD Project. Dec 7 14:13:48 caerdonn /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Dec 7 14:13:48 caerdonn /kernel: The Regents of the University of California. All rights reserved. Dec 7 14:13:48 caerdonn /kernel: FreeBSD 4.0-CURRENT #9: Tue Dec 7 12:49:33 CET 1999 Dec 7 14:13:48 caerdonn /kernel: roberto@caerdonn.eurocontrol.fr:/src/src/sys/compile/CAERDONN ... Dec 7 14:13:49 caerdonn /kernel: sym0: <875> irq 9 at device 4.0 on pci2 Dec 7 14:13:49 caerdonn /kernel: sym0: Symbios NVRAM, ID 7, Fast-20, parity checking Dec 7 14:13:49 caerdonn /kernel: sym0: open drain IRQ line driver, using on-chip SRAM ... Dec 7 14:13:49 caerdonn /kernel: da0 at sym0 bus 0 target 0 lun 0 Dec 7 14:13:49 caerdonn /kernel: da0: Fixed Direct Access SCSI-3 device Dec 7 14:13:49 caerdonn /kernel: da0: 20.000MB/s transfers (10.000MHz, offset 16, 16bit), Tagged Queueing Enabled Dec 7 14:13:49 caerdonn /kernel: da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) Dec 7 14:13:49 caerdonn /kernel: da1 at sym0 bus 0 target 1 lun 0 Dec 7 14:13:49 caerdonn /kernel: da1: Fixed Direct Access SCSI-2 device Dec 7 14:13:49 caerdonn /kernel: da1: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled Dec 7 14:13:49 caerdonn /kernel: da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) Dec 7 14:13:49 caerdonn /kernel: cd0 at sym0 bus 0 target 6 lun 0 Dec 7 14:13:49 caerdonn /kernel: cd0: Removable CD-ROM SCSI-2 device Dec 7 14:13:49 caerdonn /kernel: cd0: 4.032MB/s transfers (4.032MHz, offset 15) Dec 7 14:13:49 caerdonn /kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present -=-=- -- Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 10 8:40:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hermes.mixx.net (hermes.mixx.net [212.84.196.35]) by hub.freebsd.org (Postfix) with ESMTP id 6612B15235 for ; Fri, 10 Dec 1999 08:40:33 -0800 (PST) (envelope-from news-list.freebsd.scsi@innominate.de) Received: from mate.bln.innominate.de (gatekeeper.innominate.de [212.5.16.129]) by hermes.mixx.net (8.9.3/8.9.3) with ESMTP id SAA28447 for ; Fri, 10 Dec 1999 18:40:29 +0100 Received: by mate.bln.innominate.de (Postfix, from userid 9) id 2E3BE2CA6B; Fri, 10 Dec 1999 17:40:30 +0100 (CET) From: news-list.freebsd.scsi@innominate.de (Thomas Graichen) Reply-To: Thomas Graichen X-Newsgroups: innominate.bln.list.freebsd.scsi Subject: status: initio controller support Date: 10 Dec 1999 16:40:29 GMT Organization: innominate AG, Berlin, Germany Lines: 19 Message-ID: Reply-To: graichen@innominate.de X-Trace: mate.bln.innominate.de 944844029 19629 192.168.0.213 (10 Dec 1999 16:40:29 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/pre-1.4-19990805 ("Preacher Man") (UNIX) (FreeBSD/3.3-RELEASE (i386)) To: scsi@FreeBSD.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i just want to inform about the state of the preparation of the initio controller driver for the integration into the FreeBSD source tree: the copyright issues are cleared now - the driver sources are now under bsd copyright and i'll start cleanup up looking through the sources soon - the current state you can always see at http://www.innominate.org/~tgr/projects/FreeBSD/iha anyone interested please test it and mail me any comments - i hope to get slowly forward now and a bit more between xmas and new year t -- graichen@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Dec 11 12:20: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 63CEB14CB1 for ; Sat, 11 Dec 1999 12:20:02 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA00447 for freebsd-scsi@freebsd.org; Sat, 11 Dec 1999 20:24:03 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA79373 for freebsd-scsi@freebsd.org; Sat, 11 Dec 1999 21:14:47 +0100 (CET) (envelope-from wilko) Date: Sat, 11 Dec 1999 21:14:47 +0100 From: Wilko Bulte To: FreeBSD SCSI hackers Subject: negotiating for Ultra on AH2940UW Message-ID: <19991211211447.A79362@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On todays -current I don't see my Seagate ST34371W negotiate for Ultra speed. Disk is brand new BTW. Have I missed something? Wilko ==== ahc0: irq 10 at device 20.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4095MB (8388314 512 byte sectors: 255H 63S/T 522C) -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Dec 11 15:10:42 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 A8BB514C0C for ; Sat, 11 Dec 1999 15:10:40 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA00930; Sat, 11 Dec 1999 16:10:36 -0700 (MST) (envelope-from ken) Date: Sat, 11 Dec 1999 16:10:36 -0700 From: "Kenneth D. Merry" To: Wilko Bulte Cc: FreeBSD SCSI hackers Subject: Re: negotiating for Ultra on AH2940UW Message-ID: <19991211161036.A910@panzer.kdm.org> References: <19991211211447.A79362@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991211211447.A79362@yedi.iaf.nl>; from wilko@yedi.iaf.nl on Sat, Dec 11, 1999 at 09:14:47PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 11, 1999 at 09:14:47PM +0100, Wilko Bulte wrote: > On todays -current I don't see my Seagate ST34371W negotiate for > Ultra speed. Disk is brand new BTW. > > Have I missed something? > > Wilko > ==== > > ahc0: irq 10 at device 20.0 on pci0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > > da0: Fixed Direct Access SCSI-2 device > da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 4095MB (8388314 512 byte sectors: 255H 63S/T 522C) Do you have Ultra speeds enabled in the Adaptec BIOS, and is that particular target set up in the BIOS for Ultra speeds? 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 Sat Dec 11 16:28:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 07CF914BCA for ; Sat, 11 Dec 1999 16:28:30 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 11wwsG-0001fn-00 for freebsd-scsi@freebsd.org; Sat, 11 Dec 1999 16:28:28 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Subject: filemarks? Message-Id: Date: Sat, 11 Dec 1999 16:28:28 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org freebsd 3.3-stable of 99.11.5 ncr0: rev 0x04 int a irq 10 on pci0.20.0 sa0 at ncr0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 8) if a dump is taken with /usr/bin/mt -f /dev/rsa0 rewind /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s2a /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s2e /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s2f /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s1 /usr/bin/mt -f /dev/rsa0 rewind i expect five files to be written to the tape. but, if i issue /usr/bin/mt -f /dev/rsa0 fsf 2 the tape fast forwards all the way to the end, pauses, then fast rewinds to the beginning and barfs # /usr/bin/mt -f /dev/rsa0 fsf 2 mt: /dev/rsa0: fsf: Input/output error i know that it is a full rewind because if i then issue /sbin/restore -if /dev/rsa0 i see the first file system as opposed to the third. i get the same result with /usr/bin/mt -f /dev/rsa0 rewind /sbin/restore -if /dev/rsa0 -s 2 i can actually get the five 'files' by for i in 1 2 3 4 5; do /bin/dd if=/dev/nrsa0 bs=64k of=tape%i done and then see each of the files properly with restore. what am i misunderstanding here? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 2: 5: 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 9809C14E41 for ; Sun, 12 Dec 1999 02:04:59 -0800 (PST) (envelope-from mw@theatre.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id LAA09429; Sun, 12 Dec 1999 11:04:56 +0100 (CET) Received: by theatre.sax.de (8.9.3/8.6.12-s1) id IAA35136; Sun, 12 Dec 1999 08:24:03 +0100 (CET) Date: Sun, 12 Dec 1999 08:24:03 +0100 From: Martin Welk To: Randy Bush Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? Message-ID: <19991212082403.A34441@theatre.sax.de> Reply-To: mw@sax.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from randy@psg.com on Sat, Dec 11, 1999 at 04:28:28PM -0800 Organization: Private UUCP/Usenet site. X-Phone: +49 3731 458867 X-Operating-System: FreeBSD http://www.freebsd.org/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 11, 1999 at 04:28:28PM -0800, Randy Bush wrote: > the tape fast forwards all the way to the end, pauses, then fast rewinds > to the beginning and barfs No wonder, you're always and always again using /dev/rsa0 which is a tape device that does automatically rewind the tape when it closed. Try again with /dev/nrsa0 (the _n_on-rewinding tape device) and everything should work properly :-) Regards, Martin -- /| /| | /| / ,,You know, there's a lot of opportunities, / |/ | artin |/ |/ elk if you're knowing to take them, you know, there's a lot of opportunities, Freiberg/Saxony, Germany if there aren't you can make them, mw@sax.de / mw@theatre.sax.de make or break them!'' (Tennant/Lowe) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 5: 5:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 66E6714D5E for ; Sun, 12 Dec 1999 05:05:39 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id NAA04020; Sun, 12 Dec 1999 13:10:10 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id NAA29926; Sun, 12 Dec 1999 13:07:09 +0100 (CET) (envelope-from wilko) Date: Sun, 12 Dec 1999 13:07:09 +0100 From: Wilko Bulte To: "Kenneth D. Merry" Cc: FreeBSD SCSI hackers Subject: Re: negotiating for Ultra on AH2940UW Message-ID: <19991212130709.C29291@yedi.iaf.nl> References: <19991211211447.A79362@yedi.iaf.nl> <19991211161036.A910@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991211161036.A910@panzer.kdm.org>; from ken@kdm.org on Sat, Dec 11, 1999 at 04:10:36PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 11, 1999 at 04:10:36PM -0700, Kenneth D. Merry wrote: > On Sat, Dec 11, 1999 at 09:14:47PM +0100, Wilko Bulte wrote: > > On todays -current I don't see my Seagate ST34371W negotiate for > > Ultra speed. Disk is brand new BTW. > > Have I missed something? > > > > ahc0: irq 10 at device 20.0 on pci0 > > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > > > > da0: Fixed Direct Access SCSI-2 device > > da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing > > Enabled > > da0: 4095MB (8388314 512 byte sectors: 255H 63S/T 522C) > > Do you have Ultra speeds enabled in the Adaptec BIOS, and is that > particular target set up in the BIOS for Ultra speeds? Bleghh. I should know how to do this by now: I set the device selection to Ultra but forgot the flip the Ultra master switch one menu further down in the Adaptec Sorry for the lousy S/N W/ -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 5:15:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.omnilink.net (mail.omnilink.net [194.64.25.6]) by hub.freebsd.org (Postfix) with ESMTP id 6A70D14E49 for ; Sun, 12 Dec 1999 05:15:41 -0800 (PST) (envelope-from ob@omnilink.net) Received: from ntsrv2 (my.jav.net [212.255.14.194]) by mail.omnilink.net (8.9.3/8.9.3) with SMTP id OAA01806 for ; Sun, 12 Dec 1999 14:17:05 +0100 (CET) (envelope-from ob@omnilink.net) Message-ID: <00e001bf44a2$ecea6c00$c20effd4@jav.net> From: "Oliver Blasnik" To: Subject: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Sun, 12 Dec 1999 14:15:05 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, I do have several FreeBSD-Systems (3.1, 3.3) connected to external CRD-5440-Raid-Controllers and encountered massive Problems on one (new) machine this weekend :( All are working with on-board Adaptec 7890-Controllers, set up to UW 40 MHz, which is in specification to that 5440. Connection is done via Granite-Cables and Terminators, the Raid is the only device, I do NOT have any termination- or cabling-Problems on any of that 3 machines. Firmware of the 5440s is 1.9. But what happend... The server refused to work on after multiple "nice" messages in /var/log/messages, telling me: Dec 11 04:01:57 bigfoot /kernel: (da1:ahc0:0:0:1): SCB 0x47 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Dec 11 04:01:57 bigfoot /kernel: (da1:ahc0:0:0:1): Queuing a BDR SCB Dec 11 04:01:57 bigfoot /kernel: (da1:ahc0:0:0:1): Bus Device Reset Message Sent Dec 11 04:01:57 bigfoot /kernel: (da1:ahc0:0:0:1): no longer in timeout, status = 34b Dec 11 04:01:57 bigfoot /kernel: ahc0: Bus Device Reset on A:0. 2 SCBs aborted This server is our backup-machine (amanda) and had high scsi-load at this time. I think that there were many SCB's waiting to finish and that driver didn't wait long enough. After that crash I checked out the other Raid-Systems and found identical messages on all (which were still running)... As a work-around the only thing was to disable tagged-queuing on all systems (added that devices to cam_xpt.c and build a new kernel). None of these messages occured anymore. Anyone experienced something like this? How could I expand the timeout for tagged-queuing? Is there any workaround to use tagq (scsi is now extremely slow in comparision to yesterday...)? Regards, Oliver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 7:10:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 8BA8014DED for ; Sun, 12 Dec 1999 07:10:51 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 11xAe8-0002q1-00; Sun, 12 Dec 1999 07:10:48 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Martin Welk Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? References: <19991212082403.A34441@theatre.sax.de> Message-Id: Date: Sun, 12 Dec 1999 07:10:48 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> the tape fast forwards all the way to the end, pauses, then fast rewinds >> to the beginning and barfs > No wonder, you're always and always again using /dev/rsa0 apologies for the typo. note that the `restore -s` did not work. here the problem report is with the problems in the problem report fixed. :-) btw, i suspect hardware. it's a bad scsi month for me. randy ---- freebsd 3.3-stable of 99.11.5 ncr0: rev 0x04 int a irq 10 on pci0.20.0 sa0 at ncr0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 8) if a dump is taken with /usr/bin/mt -f /dev/rsa0 rewind /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s2a /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s2e /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s2f /sbin/dump 0uaf /dev/nrsa0 /dev/wd0s1 /usr/bin/mt -f /dev/rsa0 rewind i expect five files to be written to the tape. but, if i issue /usr/bin/mt -f /dev/nrsa0 fsf 2 the tape fast forwards all the way to the end, pauses, then fast rewinds to the beginning and barfs # this is now an actual cut and paste # /usr/bin/mt -f /dev/nrsa0 fsf 2 mt: /dev/nrsa0: fsf: Input/output error i know that it is a full rewind because if i then issue /sbin/restore -if /dev/rsa0 i see the first file system as opposed to the third. i get the same result with /usr/bin/mt -f /dev/rsa0 rewind /sbin/restore -if /dev/rsa0 -s 2 # this should not need no-rewind i can actually get the five 'files' by for i in 1 2 3 4 5; do /bin/dd if=/dev/nrsa0 bs=64k of=tape%i done and then see each of the files properly with restore. what am i misunderstanding here? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 7:47:59 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 A755614F18 for ; Sun, 12 Dec 1999 07:47:55 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id IAA27060; Sun, 12 Dec 1999 08:37:47 -0700 (MST) Date: Sun, 12 Dec 1999 08:37:47 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199912121537.IAA27060@narnia.plutotech.com> To: "Oliver Blasnik" Cc: scsi@FreeBSD.org Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <00e001bf44a2$ecea6c00$c20effd4@jav.net> 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 <00e001bf44a2$ecea6c00$c20effd4@jav.net> you wrote: > Hi there, > > I do have several FreeBSD-Systems (3.1, 3.3) connected to external > CRD-5440-Raid-Controllers and encountered massive Problems on one (new) > machine this weekend :( > > All are working with on-board Adaptec 7890-Controllers, set up to UW 40 MHz, > which is in specification to that 5440. Connection is done via Granite-Cables > and Terminators, the Raid is the only device, I do NOT have any termination- > or cabling-Problems on any of that 3 machines. Firmware of the 5440s is 1.9. Your error messages don't indicate a cabling problem, but they do seem to indicate a firmware bug in the CRD. > As a work-around the only thing was to disable tagged-queuing on all systems > (added that devices to cam_xpt.c and build a new kernel). None of these > messages occured anymore. > > Anyone experienced something like this? How could I expand the timeout for > tagged-queuing? Is there any workaround to use tagq (scsi is now extremely > slow in comparision to yesterday...)? The timeout should be 60 seconds. That is a veritable eternity for a disk, especially since we do issue ordered tagged commads from time to time to ensure that no tag starvation occurs on the device. One thing you could try doing is limiting the number of tags we attempt to use. Take a look at the quirk entries for the Quantum Atlas drives in cam_xpt.c for details. Did you try contacting CRD's technical support? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 10:29:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 7AFC2150CD for ; Sun, 12 Dec 1999 10:29:33 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id TAA04956 for freebsd-scsi@FreeBSD.ORG; Sun, 12 Dec 1999 19:29:25 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 7F4A38863; Sun, 12 Dec 1999 18:52:21 +0100 (CET) Date: Sun, 12 Dec 1999 18:52:21 +0100 From: Ollivier Robert To: FreeBSD SCSI hackers Subject: Re: negotiating for Ultra on AH2940UW Message-ID: <19991212185221.A10709@keltia.freenix.fr> Mail-Followup-To: FreeBSD SCSI hackers References: <19991211211447.A79362@yedi.iaf.nl> <19991211161036.A910@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: <19991211161036.A910@panzer.kdm.org> X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Kenneth D. Merry: > Do you have Ultra speeds enabled in the Adaptec BIOS, and is that > particular target set up in the BIOS for Ultra speeds? Interestingly enough, I have the same problem on a Symbios controller (using the sym driver), see previous message in this list. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 12:20:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by hub.freebsd.org (Postfix) with ESMTP id 49A5E14C30 for ; Sun, 12 Dec 1999 12:20:13 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-116-3.villette.club-internet.fr [194.158.116.3]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA28277; Sun, 12 Dec 1999 21:20:00 +0100 (MET) Date: Sun, 12 Dec 1999 22:45:48 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Ollivier Robert Cc: FreeBSD SCSI hackers Subject: Re: negotiating for Ultra on AH2940UW In-Reply-To: <19991212185221.A10709@keltia.freenix.fr> 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 Sun, 12 Dec 1999, Ollivier Robert wrote: > According to Kenneth D. Merry: > > Do you have Ultra speeds enabled in the Adaptec BIOS, and is that > > particular target set up in the BIOS for Ultra speeds? >=20 > Interestingly enough, I have the same problem on a Symbios controller (us= ing > the sym driver), see previous message in this list. I didn't miss your previous message, neither I missed the similar problem report with the Adaptec. I have updated to latest kernel and didn't experience the problem on my system. The sym driver also gets device settings from the NVRAM. You should check your devices are still configured for Ultra transfers. The SDMS BIOS may have lowered all devices to 10 MHz / 8 bit data transfers in the NVRAM if some error occurred while it was scanning the SCSI BUS. (It seems that not all people at SYMBIOS agree about this BIOS behaviour to be a feature;).) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 14:14: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.omnilink.net (mail.omnilink.net [194.64.25.6]) by hub.freebsd.org (Postfix) with ESMTP id BB56514E00 for ; Sun, 12 Dec 1999 14:14:02 -0800 (PST) (envelope-from ob@omnilink.net) Received: from ntsrv2 (my.jav.net [212.255.14.194]) by mail.omnilink.net (8.9.3/8.9.3) with SMTP id XAA66672; Sun, 12 Dec 1999 23:15:26 +0100 (CET) (envelope-from ob@omnilink.net) Message-ID: <006201bf44ee$21a01df0$c20effd4@jav.net> From: "Oliver Blasnik" To: , "Justin T. Gibbs" References: <199912121537.IAA27060@narnia.plutotech.com> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Sun, 12 Dec 1999 23:13:34 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I asked after several problems: > > As a work-around the only thing was to disable tagged-queuing on all systems > > (added that devices to cam_xpt.c and build a new kernel). None of these > > messages occured anymore. Justin wrote: > The timeout should be 60 seconds. That is a veritable eternity for > a disk, especially since we do issue ordered tagged commads from > time to time to ensure that no tag starvation occurs on the device. Ok, 60 seconds should be enough :) > One thing you could try doing is limiting the number of tags we > attempt to use. Take a look at the quirk entries for the Quantum > Atlas drives in cam_xpt.c for details. I just checked out the datasheet-pdf of that 5440 at cmd.com. They write something about 32 commands-cache per host. Possibly they do mean tagq. Btw, I can en/disable tagged queuing at controller-level, but not set the size of the queue. That brings me to the question -> how much tagq's are default with that freebsd-drivers? If it's more than 32, a nice PR should be transmitted with including that CMD-Controllers to cam_xpt.c's list. > Did you try contacting CRD's technical support? Not yet, it's Sunday and I am @home... Cu, Oliver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 14:31:29 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 D3E3F14E73 for ; Sun, 12 Dec 1999 14:31:26 -0800 (PST) (envelope-from mw@theatre.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id XAA22458; Sun, 12 Dec 1999 23:31:23 +0100 (CET) Received: by theatre.sax.de (8.9.3/8.6.12-s1) id WAA57880; Sun, 12 Dec 1999 22:36:12 +0100 (CET) Date: Sun, 12 Dec 1999 22:36:11 +0100 From: Martin Welk To: Randy Bush Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? Message-ID: <19991212223611.A53246@theatre.sax.de> References: <19991212082403.A34441@theatre.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from randy@psg.com on Sun, Dec 12, 1999 at 07:10:48AM -0800 Organization: Private UUCP/Usenet site. X-Phone: +49 3731 458867 X-Operating-System: FreeBSD http://www.freebsd.org/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Dec 12, 1999 at 07:10:48AM -0800, Randy Bush wrote: > apologies for the typo. note that the `restore -s` did not work. What a pity. Could have been very easy otherwise :-) > here the problem report is with the problems in the problem report > fixed. :-) > > btw, i suspect hardware. it's a bad scsi month for me. Oh, one reason why I'm using FreeBSD for about five years it that real problems already got usually fixed fast. When I started with FreeBSD, the main reason was that I wanted to setup a CD-ROM server for the company I was working for that time. Nobody had done that before, and when somebody did so, it was very expensive, as Windows NT was available and needed much resources, same with Netware and most other operating systems available. So I chose a 486DX2/66 with 16 mbytes memory, one 540 mbyte SCSI disk, six CD-ROM drives and the cheapest VGA card available (the machine was planned to have a serial console shared with an Altos SVR3 machine) and the dealer called me crazy. However, it worked fine, although some of the CD-ROMs I was going to use were not ISO compliant, so a friend of mine in Dresden (who brought FreeBSD to me and me to FreeBSD) helped me with some kernel patch and I was happy again. Okay, back from travelling in time (I was reading the 300 bit/s acoustic coupler thread on freebsd-isdn before) to your problem. > what am i misunderstanding here? I am absolutely not sure if my idea could be the right one, I haven't used such a tape drive before - we've always chosen the Tandberg SLR during the last two years. But with one of the last ones (a SLR6 one, now known as SLR24 as Tandberg is changing their way of naming tapes from increasing numbers to using the ``compression enabled optimum tape size'', because that drive does 12 gb uncompressed and up to 24 gb compressed) I had some difficulties, two, and thanks to Matt Dillon for helping me. Usually, there are two filemarks written to the tape, but there are devices ``that can only write 1'' (man page for mt, there is furtter informations). You could try ``mt geteotmodel'' to see what's the driver's opinion about which model it uses currently. Next thing: use the other one - see at the seteotmodel option and do some ``mt seteotmodel n'' (where n is 1 or 2) and look if something is changing. In /sys/cam/scsi/scsi_sa.c (sa driver source) it reads { { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 }, This is the only quirk for HP tapes, and your's won't be matched against it as T503 won't match T20* - maybe, it has something to do with it. May be some of the SCSI gurus can help better. Regards, Martin -- /| /| | /| / ,,You know, there's a lot of opportunities, / |/ | artin |/ |/ elk if you're knowing to take them, you know, there's a lot of opportunities, Freiberg/Saxony, Germany if there aren't you can make them, mw@sax.de / mw@theatre.sax.de make or break them!'' (Tennant/Lowe) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 14:35:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 39D3714E81 for ; Sun, 12 Dec 1999 14:35:08 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id XAA18201 for freebsd-scsi@FreeBSD.ORG; Sun, 12 Dec 1999 23:35:02 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id A85CC8863; Sun, 12 Dec 1999 22:37:31 +0100 (CET) Date: Sun, 12 Dec 1999 22:37:31 +0100 From: Ollivier Robert To: FreeBSD SCSI hackers Subject: Re: negotiating for Ultra on AH2940UW Message-ID: <19991212223731.B13516@keltia.freenix.fr> Mail-Followup-To: FreeBSD SCSI hackers References: <19991212185221.A10709@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Gerard Roudier: > The sym driver also gets device settings from the NVRAM. You should check > your devices are still configured for Ultra transfers. The SDMS BIOS may > have lowered all devices to 10 MHz / 8 bit data transfers in the NVRAM if > some error occurred while it was scanning the SCSI BUS. (It seems that not > all people at SYMBIOS agree about this BIOS behaviour to be a feature;).) I checked that already. I forced the rate to 40 in the BIOS. I'll retry tomorrow probably... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 14:35:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id E236D14F21 for ; Sun, 12 Dec 1999 14:35:15 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 11xHaD-0001i2-00; Sun, 12 Dec 1999 14:35:13 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Martin Welk Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? References: <19991212082403.A34441@theatre.sax.de> <19991212223611.A53246@theatre.sax.de> Message-Id: Date: Sun, 12 Dec 1999 14:35:13 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Usually, there are two filemarks written to the tape, but there are devices > ``that can only write 1'' (man page for mt, there is furtter informations). > You could try ``mt geteotmodel'' to see what's the driver's opinion about > which model it uses currently. # mt -f /dev/rsa0 geteotmodel /dev/rsa0: the model is 2 filemarks at EOT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 12 17:43:49 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 3F9F114CAE for ; Sun, 12 Dec 1999 17:43:47 -0800 (PST) (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 RAA10228; Sun, 12 Dec 1999 17:45:14 -0800 Date: Sun, 12 Dec 1999 17:45:14 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randy Bush Cc: Martin Welk , freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? 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 Yes, but it didn't complain about this. This particular HP is an ancient DDS-1 DAT drive, I believe. I don't know why it behaved the way it did, and w/o more kernel messages, can't say more. I asked about whether it was in 'fixed' as opposed to 'variable' mode because filemarks are handled internally slightly differently- but still, doesn't seem like this could be anything but bum h/w. On Sun, 12 Dec 1999, Randy Bush wrote: > > Usually, there are two filemarks written to the tape, but there are devices > > ``that can only write 1'' (man page for mt, there is furtter informations). > > You could try ``mt geteotmodel'' to see what's the driver's opinion about > > which model it uses currently. > > # mt -f /dev/rsa0 geteotmodel > /dev/rsa0: the model is 2 filemarks at EOT > > > 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 Sun Dec 12 20:51:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by hub.freebsd.org (Postfix) with ESMTP id 8948114FA7; Sun, 12 Dec 1999 20:50:55 -0800 (PST) (envelope-from Thrumbar@Worldnet.att.net) Received: from 11.neworleans-01-02rs16rt.la.dial-access.att.net ([12.73.238.11]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19991213045053.GYMA5516@11.neworleans-01-02rs16rt.la.dial-access.att.net>; Mon, 13 Dec 1999 04:50:53 +0000 From: Thrumbar Pathfinder To: scsi@freebsd.org Cc: freebsd-security@FreeBSD.ORG Subject: Developer's Interface Guide for IA-64 Servers (DIG64) Adopter Date: Sun, 12 Dec 1999 22:47:52 -0600 Organization: OmniCorp Interstellar Message-ID: <54t85sgf6meqtotpmhrjgrmc831eidjqe8@4ax.com> X-Mailer: Forte Agent 1.7/32.534 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 Attention, all FreeBSD, OpenBSD and NetBSD developers.. This is a chance we cannot ignore.. Please form up a development team with a central tram leader and get signed up for this offer. The Documentation personnel should sign up for the Contributors link to add BSD's voice in setting the guidelines for future BSD development for all three forms... Please read below.. (also, team leaders, send me a e-mail when you sign-up to keep me informed as to the process and to get an idea on how many teams there is involved) About the DIG64 Leading hardware and software vendors have formed an industry group to develop the DIG64 guidelines. These guidelines establish basic system building blocks, interfaces, and programming conventions for upcoming IA-64 based servers and their system-level software in order to define hardware and software compatibility and interoperability.=20 DIG64 is...=20 an industry-driven set of technical guidelines that define hardware, firmware and operating system's compatibility for IA-64 servers providing IT with systems built on common, stabilized interfaces that improve reliability and interoperability, lower qualification and support costs developed and backed by the key IA-64 OEMs, OSVs, and BIOS vendors who are contributing to its development and are building compliant products allowing the industry to accelerate the pace of IA-64 technology adoption=20 By defining common building blocks and interfaces and proactively addressing legacy issues, the DIG64 provides an array of benefits for both developers and IT organizations.=20 =46or developers, the DIG64: =20 Increases the efficiency of the design process, freeing developers to focus design resources of features that add unique value and differentiate their products in the marketplace. =20 Gives firmware and OS vendors a known set of interfaces to build to, enabling them to confidentially develop their products concurrently with the hardware and shrink time to markets. =20 Provides a technology migration roadmap that extends the planning horizon for developers and allows them to create designs with increased longevity.=20 =46or business users and Information Technology (IT) departments: =20 Standard interfaces and interoperable layers enhance the reliability and robustness of the resulting servers as well as lowering qualification costs. Since developers find it easier to build components that work together, customers can enjoy a greater choice of robust, innovative server solutions. Because the DIG64 addresses the migration of support-intensive, obsolete technologies to newer, more robust choices, IT departments can control or reduce the cost of server support.=20 DIG64 Defined =20 The DIG64 specification defines basic system building blocks, interfaces and programming conventions between IA-64 based servers and system-level software such as the operating system and device drivers. The specification covers:=20 Core system components such as the processor, chipset, memory, I/O bus, and server management hardware.=20 =20 Interfaces to peripheral devices for networking, communications and storage.=20 =20 Low-level firmware interfaces to the operating system for system configuration, boot and runtime services.=20 The guide does not create new standards and interfaces, but selects components and interfaces from already existing technologies. To ensure interoperability, the DIG64 also specifies implementation requirements for each specification or standard.=20 The DIG64 spells out a roadmap for eliminating obsolete technologies. Release 1.0, which is currently available , pertains to servers=20 based on the Intel=AE Itanium=99 processor. Subsequent versions will address future processors as they are developed. A three-level hierarchy of required, recommended and optional features enables vendors to choose how quickly they want to remove older technologies.=20 The DIG64 is operating-system independent, promoting cross-platform interoperability among servers running Windows 2000*, Linux and other UNIX* operating systems.=20 Join Other Industry Leaders Already Building Compatible IA-64 Server Solutions! =20 =20 There is still time to get involved by becoming a DIG64 Adopter member. To find out more about the advantages of becoming a DIG64 Adopter, take look at the DIG64 www site.... http://www.dig64.org/ To sign up as a Developer's Interface Guide for IA-64 Servers (DIG64) Adopter, complete all of the information at the link listed below and hit the submit button. You will then be able to download a "DIG64 Adopters Agreement". http://www.dig64.org/signup.htm By becoming a DIG64 Contributor, you will be able to provide technical input into the development of the DIG64 guidelines in addition to gaining access to the latest published draft. All input will be reviewed by the DIG64 Working Group for possible inclusion in the guideline. http://www.dig64.org/contributor.htm When you have formed your group please e-mail me so that I will know how many groups there are.. Please include a list of the individuals on the team and their position on said team as well as any contact information you are willing to provide... Thrumbar@Worldnet.att.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 0:20:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.omnilink.net (mail.omnilink.net [194.64.25.6]) by hub.freebsd.org (Postfix) with ESMTP id 0F04114EA9 for ; Mon, 13 Dec 1999 00:20:33 -0800 (PST) (envelope-from ob@omnilink.net) Received: from ntsrv2 (my.jav.net [212.255.14.194]) by mail.omnilink.net (8.9.3/8.9.3) with SMTP id JAA45886; Mon, 13 Dec 1999 09:21:24 +0100 (CET) (envelope-from ob@omnilink.net) Message-ID: <00e201bf4542$c84a8bf0$c20effd4@jav.net> From: "Oliver Blasnik" To: "Justin T. Gibbs" , References: <199912121537.IAA27060@narnia.plutotech.com> <006201bf44ee$21a01df0$c20effd4@jav.net> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Mon, 13 Dec 1999 09:19:25 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (... answering to myself is weird, isn't it?... ) I wrote: > I just checked out the datasheet-pdf of that 5440 at cmd.com. They write > something about 32 commands-cache per host. Thinking about this... 32 commands per host... Hum... As far as CRD's show their logical partitions in a per-lun-basis, you could have e.g. 3 independend partitions, each with a 10,6 (*g*) commands-cache... Ough :( That dynamically things aren't good.... I'll setup a max of 4 in cam_xpt.c and check it out. Possibly a recommended patch to cam_xpt.c would be to setup this, as far freebsd only supports 8 lun's by default (afair?). Any chances to get that into 3.4R? Justin? :) Actual added this to cam_xpt.c: { /* Broken tagged queuing drive, 32 tqs per host */ /* changed 12/12/1999 oliver blasnik fixno2 */ { T_DIRECT, SIP_MEDIA_FIXED, "CMD TECH","CRD*","*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/ 4 }, Cu, Oliver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 0:30:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles516.castles.com [208.214.165.80]) by hub.freebsd.org (Postfix) with ESMTP id 7A11814FB5 for ; Mon, 13 Dec 1999 00:30:26 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA06120; Mon, 13 Dec 1999 00:32:46 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912130832.AAA06120@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Oliver Blasnik" Cc: "Justin T. Gibbs" , freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 09:19:25 +0100." <00e201bf4542$c84a8bf0$c20effd4@jav.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 00:32:46 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I just checked out the datasheet-pdf of that 5440 at cmd.com. They write > > something about 32 commands-cache per host. > > Thinking about this... 32 commands per host... Hum... As far as CRD's show their > logical partitions in a per-lun-basis, you could have e.g. 3 independend > partitions, each with a 10,6 (*g*) commands-cache... > Ough :( That dynamically things aren't good.... > > I'll setup a max of 4 in cam_xpt.c and check it out. Possibly a recommended > patch to cam_xpt.c would be to setup this, as far freebsd only supports 8 lun's > by default (afair?). Any chances to get that into 3.4R? Justin? :) No. FreeBSD starts assuming that a drive will handle 64 tags, but it expects that the drive will correctly report a queue-full condition so that it can dynamically adjust this number downwards. If the problem in this case is that the CMD unit is accepting a tagged command and then simply throwing it away, that's a bug in the CMD firmware. > Actual added this to cam_xpt.c: > { > /* Broken tagged queuing drive, 32 tqs per host */ > /* changed 12/12/1999 oliver blasnik fixno2 */ > { T_DIRECT, SIP_MEDIA_FIXED, "CMD TECH","CRD*","*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/ 4 > }, This may solve the "problem", but it will substantially degrade performance in the case where there's only one array on the controller. You might want to consider using a PCI:SCSI RAID controller like a Mylex DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better on these units, and they typically offer all of the features of the external units at a lower price. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 2: 4:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fuchs.omnilink.de (hase.omnilink.de [194.64.25.65]) by hub.freebsd.org (Postfix) with ESMTP id 069B4150A2; Mon, 13 Dec 1999 02:04:32 -0800 (PST) (envelope-from ob@omnilink.net) Received: by fuchs.omnilink.de; id LAA05553; Mon, 13 Dec 1999 11:02:25 +0100 (MET) Received: from sondermuell.omnilink.de(194.64.25.218) by fuchs.omnilink.de via smap (V4.2) id xma005547; Mon, 13 Dec 99 11:02:18 +0100 Message-ID: <000c01bf4551$d8862240$da1940c2@omnilink.de> Reply-To: "Oliver Blasnik" From: "Oliver Blasnik" To: , "Mike Smith" References: <199912130832.AAA06120@mass.cdrom.com> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Mon, 13 Dec 1999 11:07:21 +0100 Organization: Omnilink ISC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote: > No. FreeBSD starts assuming that a drive will handle 64 tags, but it=20 > expects that the drive will correctly report a queue-full condition so = > that it can dynamically adjust this number downwards. And this could not work as far these maximum of 32 commands is = host-based, not lun-based. =20 > If the problem in this case is that the CMD unit is accepting a tagged = > command and then simply throwing it away, that's a bug in the CMD=20 > firmware. Correct. =20 > This may solve the "problem", but it will substantially degrade=20 > performance in the case where there's only one array on the = controller. Right. But on the other hand enables tq without bothering on = system-crashed :) Better slow than not running. =20 > > You might want to consider using a PCI:SCSI RAID controller like a = Mylex=20 > DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better on=20 > these units, and they typically offer all of the features of the = external=20 > units at a lower price. > *g* Not a possibility for me. It has to be external for different reasons. We do not only have = FreeBSD, there's also Solaris and WinNT. Connecting an external system = enables transparency. Some CRD's are connected to two machines, = sometimes to share the array, sometimes to enable high-availability for = a system (hot-take-over of the drives). You could set up two CRD's to = the same drive bay to enable renundancy and cut off this single point of = failure. Last but not least, if one machine burns down, just take a new = hardware, plug it onto the raid and switch it on - running and up again. = Tell me how to do that with your controllers :) Cu, Oliver PS: I made a mistake on my cam_xpt.c-entry. the "min-tags" has to be >0 = to enable tq :) --=20 __ OMNILINK Internet Service Center GmbH / \ Hahnstrasse 70, 60528 Frankfurt __\ /_________ Tel.: (0 69)66 44 10 Fax: (0 69)66 44 11 99 O M N I L I N K http://www.omnilink.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 2:11:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles516.castles.com [208.214.165.80]) by hub.freebsd.org (Postfix) with ESMTP id 9396B14FF7; Mon, 13 Dec 1999 02:11:43 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id CAA21782; Mon, 13 Dec 1999 02:14:24 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912131014.CAA21782@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Oliver Blasnik" Cc: freebsd-scsi@FreeBSD.ORG, "Mike Smith" Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 11:07:21 +0100." <000c01bf4551$d8862240$da1940c2@omnilink.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 1999 02:14:23 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Mike Smith wrote: > = > > No. FreeBSD starts assuming that a drive will handle 64 tags, but it= = > > expects that the drive will correctly report a queue-full condition s= o = > > that it can dynamically adjust this number downwards. > = > And this could not work as far these maximum of 32 commands is host-bas= ed, not lun-based. That would depend on the configuration of the unit. It'd work well for = the single-drive case. > > This may solve the "problem", but it will substantially degrade = > > performance in the case where there's only one array on the controlle= r. > Right. But on the other hand enables tq without bothering on system-cra= shed :) > Better slow than not running. Perhaps. Better fixed firmware than terrible performance. > > > > You might want to consider using a PCI:SCSI RAID controller like a My= lex = > > DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better on= = > > these units, and they typically offer all of the features of the exte= rnal = > > units at a lower price. > > > = > *g* Not a possibility for me. > = > It has to be external for different reasons. We do not only have > FreeBSD, there's also Solaris and WinNT. NT supports these controllers, as does Intel Solaris. They probably have= = drivers for the PCI Sparc systems as well. > Connecting an external system > enables transparency. Some CRD's are connected to two machines, sometim= es > to share the array, sometimes to enable high-availability for a system > (hot-take-over of the drives). You could set up two CRD's to the same > drive bay to enable renundancy and cut off this single point of failure= =2E =2E.. if they worked properly. 8) > Last but not least, if one machine burns down, just take a new hardware= , > plug it onto the raid and switch it on - running and up again. Tell me = how > to do that with your controllers :) Easy. They all save their config on the array as well as in NVRAM. With= = the newer models you could even pull the battery-backed RAM module off = the burnt controller and save the cached write data as well. -- = \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 2:34:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id D4C5514C38; Mon, 13 Dec 1999 02:34:55 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id CAA06144; Mon, 13 Dec 1999 02:33:11 -0800 (PST) Message-Id: <199912131033.CAA06144@implode.root.com> To: Mike Smith Cc: "Oliver Blasnik" , freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 02:14:23 PST." <199912131014.CAA21782@mass.cdrom.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 13 Dec 1999 02:33:10 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Mike Smith wrote: >> >> > No. FreeBSD starts assuming that a drive will handle 64 tags, but it >> > expects that the drive will correctly report a queue-full condition so >> > that it can dynamically adjust this number downwards. >> >> And this could not work as far these maximum of 32 commands is host-based, not lun-based. > >That would depend on the configuration of the unit. It'd work well for >the single-drive case. > >> > This may solve the "problem", but it will substantially degrade >> > performance in the case where there's only one array on the controller. >> Right. But on the other hand enables tq without bothering on system-crashed :) >> Better slow than not running. > >Perhaps. Better fixed firmware than terrible performance. I've been reading all of this and I'm still wondering what this is all about. TeraSolutions has many of the CRD-5440-104 (LVD version) controllers in the field and have never had problems with them. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 2:35:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fuchs.omnilink.de (hase.omnilink.de [194.64.25.65]) by hub.freebsd.org (Postfix) with ESMTP id CFEAF14E36; Mon, 13 Dec 1999 02:35:26 -0800 (PST) (envelope-from ob@omnilink.net) Received: by fuchs.omnilink.de; id LAA08346; Mon, 13 Dec 1999 11:33:24 +0100 (MET) Received: from sondermuell.omnilink.de(194.64.25.218) by fuchs.omnilink.de via smap (V4.2) id xma008329; Mon, 13 Dec 99 11:33:11 +0100 Message-ID: <002a01bf4556$28f56ca0$da1940c2@omnilink.de> Reply-To: "Oliver Blasnik" From: "Oliver Blasnik" To: , "Mike Smith" References: <199912131014.CAA21782@mass.cdrom.com> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Mon, 13 Dec 1999 11:38:14 +0100 Organization: Omnilink ISC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote: >> And this could not work as far these maximum of 32 commands is = host-based, not lun-based. >>That would depend on the configuration of the unit. It'd work well = for=20 >>the single-drive case. ... which is unrealistic, the typical install is one boot- and one (or = more) data-partition(s). >Perhaps. Better fixed firmware than terrible performance. Again, think realistic, "fixing" FreeBSD is a more on-time-solution than = waiting for cmdtech to do an update. >> > You might want to consider using a PCI:SCSI RAID controller like a = Mylex=20 >> > DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better = on=20 >NT supports these controllers, as does Intel Solaris. They probably = have=20 >drivers for the PCI Sparc systems as well. And what about non-PCI-systems? Sorry, again, think realistic. The only = "works identical on all systems"-solution is external. And I prefer = using prooven adaptec-drivers than not-so-often-used others on my = systems... Btw, I do not recognise that 3.3-stable (and older releases are running = here, up from 2.1.6) do have drivers for the controllers you mentioned. >> You could set up two CRD's to the same >> drive bay to enable renundancy and cut off this single point of = failure. >... if they worked properly. 8) Worked fine with Solaris2.6, and if disabling tq is the only solution on = multiple-os-at-the-same-raid, I will do that on controller-level. >> Last but not least, if one machine burns down, just take a new = hardware, >> plug it onto the raid and switch it on - running and up again. Tell = me how >> to do that with your controllers :) >Easy. They all save their config on the array as well as in NVRAM. = With=20 >the newer models you could even pull the battery-backed RAM module off=20 >the burnt controller and save the cached write data as well. You have to open both systems and change hardware. This is wasted time = in my point of view as you don't have this in an emergency case. Now, let us end this thread, it is going into an "my controller is = better"-war, which lets me think downto the "old commodore- and = atari-wars" long time ago. They ended up with no result, as this thread = would. There are multiple possibilities for multiple requirements. = Better focus on a solution and a better FreeBSD. Cu, Oliver --=20 __ OMNILINK Internet Service Center GmbH / \ Hahnstrasse 70, 60528 Frankfurt __\ /_________ Tel.: (0 69)66 44 10 Fax: (0 69)66 44 11 99 O M N I L I N K http://www.omnilink.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 2:38:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fuchs.omnilink.de (hase.omnilink.de [194.64.25.65]) by hub.freebsd.org (Postfix) with ESMTP id 5A14614DE4 for ; Mon, 13 Dec 1999 02:38:27 -0800 (PST) (envelope-from ob@omnilink.net) Received: by fuchs.omnilink.de; id LAA08580; Mon, 13 Dec 1999 11:36:24 +0100 (MET) Received: from sondermuell.omnilink.de(194.64.25.218) by fuchs.omnilink.de via smap (V4.2) id xma008526; Mon, 13 Dec 99 11:35:47 +0100 Message-ID: <003301bf4556$86522e60$da1940c2@omnilink.de> Reply-To: "Oliver Blasnik" From: "Oliver Blasnik" To: Cc: References: <199912131033.CAA06144@implode.root.com> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Mon, 13 Dec 1999 11:40:51 +0100 Organization: Omnilink ISC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, David Greenman wrote: > I've been reading all of this and I'm still wondering what this is = all > about. TeraSolutions has many of the CRD-5440-104 (LVD version) = controllers > in the field and have never had problems with them. Using FreeBSD >3.0 and tagged queuing enabled at system and raid? Let me = take a look at your dmesg :) Cu, Oliver --=20 __ OMNILINK Internet Service Center GmbH / \ Hahnstrasse 70, 60528 Frankfurt __\ /_________ Tel.: (0 69)66 44 10 Fax: (0 69)66 44 11 99 O M N I L I N K http://www.omnilink.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 4:26:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id C20F214D50 for ; Mon, 13 Dec 1999 04:26:33 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id EAA06256; Mon, 13 Dec 1999 04:24:46 -0800 (PST) Message-Id: <199912131224.EAA06256@implode.root.com> To: "Oliver Blasnik" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 11:40:51 +0100." <003301bf4556$86522e60$da1940c2@omnilink.de> From: David Greenman Reply-To: dg@root.com Date: Mon, 13 Dec 1999 04:24:46 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >David Greenman wrote: >> I've been reading all of this and I'm still wondering what this is all >> about. TeraSolutions has many of the CRD-5440-104 (LVD version) controllers >> in the field and have never had problems with them. > >Using FreeBSD >3.0 and tagged queuing enabled at system and raid? Let me take a look at your dmesg :) Yes. Works just fine. Controller firmware is C1-9. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 5: 3:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (209-176-244-82.inil.com [209.176.244.82]) by hub.freebsd.org (Postfix) with ESMTP id 8C68E1507B; Mon, 13 Dec 1999 05:03:53 -0800 (PST) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id HAA20060; Mon, 13 Dec 1999 07:03:41 -0600 (CST) Message-ID: <19991213070341.C20023@Denninger.Net> Date: Mon, 13 Dec 1999 07:03:41 -0600 From: Karl Denninger To: dg@root.com, Mike Smith Cc: Oliver Blasnik , freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x References: <199912131014.CAA21782@mass.cdrom.com> <199912131033.CAA06144@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199912131033.CAA06144@implode.root.com>; from David Greenman on Mon, Dec 13, 1999 at 02:33:10AM -0800 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 13, 1999 at 02:33:10AM -0800, David Greenman wrote: > >> Mike Smith wrote: > >> > >> > No. FreeBSD starts assuming that a drive will handle 64 tags, but it > >> > expects that the drive will correctly report a queue-full condition so > >> > that it can dynamically adjust this number downwards. > >> > >> And this could not work as far these maximum of 32 commands is host-based, not lun-based. > > > >That would depend on the configuration of the unit. It'd work well for > >the single-drive case. > > > >> > This may solve the "problem", but it will substantially degrade > >> > performance in the case where there's only one array on the controller. > >> Right. But on the other hand enables tq without bothering on system-crashed :) > >> Better slow than not running. > > > >Perhaps. Better fixed firmware than terrible performance. > > I've been reading all of this and I'm still wondering what this is all > about. TeraSolutions has many of the CRD-5440-104 (LVD version) controllers > in the field and have never had problems with them. > > -DG I used to have a bunch of these controllers in production use as well, never saw this kind of problem with them, and they DID reduce the number of tag slots from 64 downward automatically (they DO properly report queue-full). This has to be a new firmware bug - I haven't run one in about a year, but prior to that time they DID work as expected. -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 5: 4:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (209-176-244-82.inil.com [209.176.244.82]) by hub.freebsd.org (Postfix) with ESMTP id 9DB4B14F57 for ; Mon, 13 Dec 1999 05:04:57 -0800 (PST) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id HAA20070; Mon, 13 Dec 1999 07:04:53 -0600 (CST) Message-ID: <19991213070453.D20023@Denninger.Net> Date: Mon, 13 Dec 1999 07:04:53 -0600 From: Karl Denninger To: Oliver Blasnik , dg@root.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x References: <199912131033.CAA06144@implode.root.com> <003301bf4556$86522e60$da1940c2@omnilink.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <003301bf4556$86522e60$da1940c2@omnilink.de>; from Oliver Blasnik on Mon, Dec 13, 1999 at 11:40:51AM +0100 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 13, 1999 at 11:40:51AM +0100, Oliver Blasnik wrote: > Hi, > > David Greenman wrote: > > I've been reading all of this and I'm still wondering what this is all > > about. TeraSolutions has many of the CRD-5440-104 (LVD version) controllers > > in the field and have never had problems with them. > > Using FreeBSD >3.0 and tagged queuing enabled at system and raid? Let me take a look at your dmesg :) Yes. Me too. I used to have a BUNCH of these in production use with FreeBSD >3.0, tagged queueing enabled, and I got reports of the tags being reduced downward during operation from 64 to (typically) 32 over the first few minutes of operation after a boot. -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 6:36:42 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 388FC14F16 for ; Mon, 13 Dec 1999 06:36:37 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id HAA28120; Mon, 13 Dec 1999 07:26:26 -0700 (MST) Date: Mon, 13 Dec 1999 07:26:26 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199912131426.HAA28120@narnia.plutotech.com> To: dg@root.com Cc: scsi@FreeBSD.org Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199912131033.CAA06144@implode.root.com> 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 <199912131033.CAA06144@implode.root.com> you wrote: >> >>Perhaps. Better fixed firmware than terrible performance. > > I've been reading all of this and I'm still wondering what this is all > about. TeraSolutions has many of the CRD-5440-104 (LVD version) controllers > in the field and have never had problems with them. Have you deployed a configuration with two systems attached to the same array? This is not the first time that I've heard of CRD problems with multi-host access. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 6:42:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 19204150DD for ; Mon, 13 Dec 1999 06:42:46 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id GAA06526; Mon, 13 Dec 1999 06:40:23 -0800 (PST) Message-Id: <199912131440.GAA06526@implode.root.com> To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 07:26:26 MST." <199912131426.HAA28120@narnia.plutotech.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 13 Dec 1999 06:40:23 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >In article <199912131033.CAA06144@implode.root.com> you wrote: >>> >>>Perhaps. Better fixed firmware than terrible performance. >> >> I've been reading all of this and I'm still wondering what this is all >> about. TeraSolutions has many of the CRD-5440-104 (LVD version) controllers >> in the field and have never had problems with them. > >Have you deployed a configuration with two systems attached to the >same array? This is not the first time that I've heard of CRD problems >with multi-host access. Good point, no, all of our systems are single host access to the controller. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 6:50:10 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 4C1B2150E5; Mon, 13 Dec 1999 06:49:56 -0800 (PST) (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 HAA00346; Mon, 13 Dec 1999 07:49:40 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199912131449.HAA00346@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Mike Smith Cc: "Oliver Blasnik" , "Justin T. Gibbs" , freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 00:32:46 PST." <199912130832.AAA06120@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 07:49:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I'll setup a max of 4 in cam_xpt.c and check it out. Possibly a recommended >> patch to cam_xpt.c would be to setup this, as far freebsd only supports 8 lu >n's >> by default (afair?). Any chances to get that into 3.4R? Justin? :) > >No. FreeBSD starts assuming that a drive will handle 64 tags, but it >expects that the drive will correctly report a queue-full condition so >that it can dynamically adjust this number downwards. Actually it starts at 255 or the maximum allowed by the controller linked to the drive. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 8:39:54 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 D439B1549B for ; Mon, 13 Dec 1999 08:39:48 -0800 (PST) (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 IAA12204 for ; Mon, 13 Dec 1999 08:41:22 -0800 Date: Mon, 13 Dec 1999 08:41:22 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: scsi@freebsd.org Subject: dual bus controllers? 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 Have folks been using these okay with -current as of the last week? I've been trying to do Qlogic 1280 support and that's been fine except there seems to be some oddities for the second bus, etc. It worked fine when I did the Qlogic 1240 support 6 months ago- but because I didn't actually have a Qlogic 1240, I couldn't (re)test as things moved along. So far I'm seeing things like disklabel and hang in cam_periph_lock and 'camcontrol rescan' hang (indeterminate where).... So I thought a quick check with folks here who have any non-Qlogic dual bus controllers to see whether or not things are okay for them (this is just dual-bus controllers which are *not* separate PCI instances..) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 14:37:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.omnilink.net (mail.omnilink.net [194.64.25.6]) by hub.freebsd.org (Postfix) with ESMTP id CFBE514D47 for ; Mon, 13 Dec 1999 14:37:46 -0800 (PST) (envelope-from ob@omnilink.net) Received: from ntsrv2 (my.jav.net [212.255.14.194]) by mail.omnilink.net (8.9.3/8.9.3) with SMTP id XAA38359; Mon, 13 Dec 1999 23:38:01 +0100 (CET) (envelope-from ob@omnilink.net) Message-ID: <001901bf45ba$73433080$c20effd4@jav.net> From: "Oliver Blasnik" To: , "Justin T. Gibbs" Cc: References: <199912131440.GAA06526@implode.root.com> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Date: Mon, 13 Dec 1999 23:36:08 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David & Justin wrote: > >Have you deployed a configuration with two systems attached to the > >same array? This is not the first time that I've heard of CRD problems > >with multi-host access. > > Good point, no, all of our systems are single host access to the > controller. Ooookaaay... I do have one spare-controller left. Some old, slow diskdrives are also available, I'll try it out with both modes (single and dual-host-configuration) and write down the results. Hope I do find enough time for that :) If that's the solution, we can close that thread. Btw, I never saw any "reducing taggedqueues"... Firmware on all is C1.9 - like David's. VERY interesting thing. And, after fixing all servers to max 4-tq's, they're running without errors. Hu? Cu, Oliver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 14:53:20 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 DA403152E2 for ; Mon, 13 Dec 1999 14:53:10 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA33458; Mon, 13 Dec 1999 15:53:02 -0700 (MST) (envelope-from ken) Date: Mon, 13 Dec 1999 15:53:02 -0700 From: "Kenneth D. Merry" To: Oliver Blasnik Cc: dg@root.com, "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Message-ID: <19991213155301.A33398@panzer.kdm.org> References: <199912131440.GAA06526@implode.root.com> <001901bf45ba$73433080$c20effd4@jav.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <001901bf45ba$73433080$c20effd4@jav.net>; from ob@omnilink.net on Mon, Dec 13, 1999 at 11:36:08PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 13, 1999 at 23:36:08 +0100, Oliver Blasnik wrote: > David & Justin wrote: > > > >Have you deployed a configuration with two systems attached to the > > >same array? This is not the first time that I've heard of CRD problems > > >with multi-host access. > > > > Good point, no, all of our systems are single host access to the > > controller. > > Ooookaaay... > I do have one spare-controller left. Some old, slow diskdrives are also > available, I'll try it out with both modes (single and dual-host-configuration) > and write down the results. Hope I do find enough time for that :) If that's the > solution, we can close that thread. My guess is that that may be your problem. Charles Sprickman had a fair number of problems with a CMD RAID controller, and his setup was a multi-LUN setup. > Btw, I never saw any "reducing taggedqueues"... Firmware on all is C1.9 - like > David's. VERY interesting thing. And, after fixing all servers to max 4-tq's, > they're running without errors. Hu? You won't see any messages about the number of tags being reduced if you're running FreeBSD 3.2 or later. You can see them if you boot with -v, ("boot kernel -v" at the loader prompt). You can also check the number of outstanding tags with camcontrol in FreeBSD 3.2 and later. e.g.: {panzer:/usr/home/ken:2:0} camcontrol tags da1 (pass1:ahc1:0:1:0): device openings: 64 The above command just gives you the total number of possible transactions for the device in question. The total number possible is the sum of openings + active: {panzer:/usr/home/ken:3:0} camcontrol tags da1 -v (pass1:ahc1:0:1:0): dev_openings 55 (pass1:ahc1:0:1:0): dev_active 9 (pass1:ahc1:0:1:0): devq_openings 55 (pass1:ahc1:0:1:0): devq_queued 0 (pass1:ahc1:0:1:0): held 0 (pass1:ahc1:0:1:0): mintags 2 (pass1:ahc1:0:1:0): maxtags 255 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 Dec 13 22: 2:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id A5421152D3 for ; Mon, 13 Dec 1999 22:02:11 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11xjUg-0001RS-00; Mon, 13 Dec 1999 20:23:22 -0800 Date: Mon, 13 Dec 1999 20:21:22 -0800 (PST) From: Tom To: Oliver Blasnik Cc: freebsd-scsi@FreeBSD.ORG, Mike Smith Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-Reply-To: <000c01bf4551$d8862240$da1940c2@omnilink.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Dec 1999, Oliver Blasnik wrote: > It has to be external for different reasons. We do not only have > FreeBSD, there's also Solaris and WinNT. Connecting an external system > enables transparency. Some CRD's are connected to two machines, ... If you want to go with standalone RAID, use Infortrend over CRD. First of all, you can up to 256 tags per host, and they can still do everything CRD does. Overall the Infortrend firmware is quite good. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:23: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 47DD91523A; Mon, 13 Dec 1999 22:22:55 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id WAA08612; Mon, 13 Dec 1999 22:20:08 -0800 (PST) Message-Id: <199912140620.WAA08612@implode.root.com> To: Tom Cc: Oliver Blasnik , freebsd-scsi@FreeBSD.ORG, Mike Smith Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 20:21:22 PST." From: David Greenman Reply-To: dg@root.com Date: Mon, 13 Dec 1999 22:20:08 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >On Mon, 13 Dec 1999, Oliver Blasnik wrote: > >> It has to be external for different reasons. We do not only have >> FreeBSD, there's also Solaris and WinNT. Connecting an external system >> enables transparency. Some CRD's are connected to two machines, >... > > If you want to go with standalone RAID, use Infortrend over CRD. First >of all, you can up to 256 tags per host, and they can still do everything >CRD does. Overall the Infortrend firmware is quite good. ...unless you use the battery backup, in which case the Infortrend gets stuck in an infinite crash/restart loop on powerup if there are dirty buffers in the cache. A show stopper for us, which is why we're still using the CMD. The Infortrend also has some strange performance anolomies which result in very poor performance in some cases. Repeated calls into their tech support over the past 3 weeks have so far gotten us nowhere. If you or anyone else here would like to go with the Infortrend, let me know - I have two IFT-3102U2G controllers (w/IFT-9070B battery backup modules) sitting on the shelf that I'd be happy to sell at below cost. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:24:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id D97DB15310; Mon, 13 Dec 1999 22:24:14 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11xjr3-0001TK-00; Mon, 13 Dec 1999 20:46:29 -0800 Date: Mon, 13 Dec 1999 20:46:28 -0800 (PST) From: Tom To: Mike Smith Cc: Oliver Blasnik , "Justin T. Gibbs" , freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-Reply-To: <199912130832.AAA06120@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Dec 1999, Mike Smith wrote: > > You might want to consider using a PCI:SCSI RAID controller like a Mylex > DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better on > these units, and they typically offer all of the features of the external > units at a lower price. > Well, except for a couple of drawbacks: - You can't boot from AMI or Mylex controllers under FreeBSD 3.x yet. The DPT PCI RAID card is only one that supports booting, but an external RAID box is easily twice as fast as an DPT card. - No online configuration yet. Each controller brand needs it own management app ported to FreeBSD. An external card usually has a nice LCD display. I can even hookup new drives and configure a new logical disk, or expand an existing logical disk with a couple of button presses (at least on Infortrend). As far standalone controllers, I'd go with an Infortrend over CRD. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:28: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles528.castles.com [208.214.165.92]) by hub.freebsd.org (Postfix) with ESMTP id A700E151AB for ; Mon, 13 Dec 1999 22:28:05 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id WAA00978; Mon, 13 Dec 1999 22:30:55 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912140630.WAA00978@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tom Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 20:46:28 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 22:30:55 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On Mon, 13 Dec 1999, Mike Smith wrote: > > > > > You might want to consider using a PCI:SCSI RAID controller like a Mylex > > DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better on > > these units, and they typically offer all of the features of the external > > units at a lower price. > > > > Well, except for a couple of drawbacks: > > - You can't boot from AMI or Mylex controllers under FreeBSD 3.x yet. The > DPT PCI RAID card is only one that supports booting, but an external RAID > box is easily twice as fast as an DPT card. Actually, you can boot the Compaq Smart2 family controllers as well. But there are some major defects in the 3.x and older boot infrastructure that make it a bit hard. It wouldn't be too hard to write some new bootblocks for these other controllers though, and I expect I'll do just that. > - No online configuration yet. Each controller brand needs it own > management app ported to FreeBSD. An external card usually has a nice LCD > display. I can even hookup new drives and configure a new logical disk, > or expand an existing logical disk with a couple of button presses (at > least on Infortrend). Actually, all the internal controllers (bar a couple of very old Mylex units) have much nicer interfaces in their BIOS code. I'll take a fullscreen app over trying to build my spanned array with three pushbuttons and a 40x2 LCD. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:32:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 4C64915148 for ; Mon, 13 Dec 1999 22:32:42 -0800 (PST) (envelope-from tim@futuresouth.com) Received: (from tim@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id AAA22002; Tue, 14 Dec 1999 00:31:53 -0600 (CST) Date: Tue, 14 Dec 1999 00:31:53 -0600 From: Tim Tsai To: Tom Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Message-ID: <19991214003153.A21808@futuresouth.com> References: <199912130832.AAA06120@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Infortrend just released a series of PowerPC based controllers that might resolve some of the performance problems. We have two that's been pretty solid but they're both on lightly loaded boxes. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:35: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 1583F1554E; Mon, 13 Dec 1999 22:34:48 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11xk1K-0001Ur-00; Mon, 13 Dec 1999 20:57:06 -0800 Date: Mon, 13 Dec 1999 20:57:06 -0800 (PST) From: Tom To: Mike Smith Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-Reply-To: <199912140630.WAA00978@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Dec 1999, Mike Smith wrote: > > - No online configuration yet. Each controller brand needs it own > > management app ported to FreeBSD. An external card usually has a nice LCD > > display. I can even hookup new drives and configure a new logical disk, > > or expand an existing logical disk with a couple of button presses (at > > least on Infortrend). > > Actually, all the internal controllers (bar a couple of very old Mylex > units) have much nicer interfaces in their BIOS code. I'll take a > fullscreen app over trying to build my spanned array with three > pushbuttons and a 40x2 LCD. 8) BIOS? That means the server is down. I'm talking about _online_. If the LCD is too small, use a full screen VT100/ANSI interface via a serial port. Again, while the controller and server are online. The Infortrend controller can even be configured to run PPP on the serial port, so you can plug it into a host port, or into a term server and telnet direct to the controler. I love playing the "which disk is dead" game when a DPT RAID controller's audible alarm is sounding, but I have to boot into the management interface to figure out which one. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:41:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles528.castles.com [208.214.165.92]) by hub.freebsd.org (Postfix) with ESMTP id 29D5115310 for ; Mon, 13 Dec 1999 22:41:41 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id WAA01069; Mon, 13 Dec 1999 22:44:31 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912140644.WAA01069@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tom Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 20:57:06 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 22:44:31 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Actually, all the internal controllers (bar a couple of very old Mylex > > units) have much nicer interfaces in their BIOS code. I'll take a > > fullscreen app over trying to build my spanned array with three > > pushbuttons and a 40x2 LCD. 8) > > BIOS? That means the server is down. I'm talking about _online_. There you've got me. But not for too long. 8) > I love playing the "which disk is dead" game when a DPT RAID > controller's audible alarm is sounding, but I have to boot into the > management interface to figure out which one. This is what managed enclosures are for. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:45: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id E666415571; Mon, 13 Dec 1999 22:45:03 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11xkBG-0001Vi-00; Mon, 13 Dec 1999 21:07:22 -0800 Date: Mon, 13 Dec 1999 21:07:22 -0800 (PST) From: Tom To: Mike Smith Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-Reply-To: <199912140644.WAA01069@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Dec 1999, Mike Smith wrote: > > > Actually, all the internal controllers (bar a couple of very old Mylex > > > units) have much nicer interfaces in their BIOS code. I'll take a > > > fullscreen app over trying to build my spanned array with three > > > pushbuttons and a 40x2 LCD. 8) > > > > BIOS? That means the server is down. I'm talking about _online_. > > There you've got me. But not for too long. 8) > > > I love playing the "which disk is dead" game when a DPT RAID > > controller's audible alarm is sounding, but I have to boot into the > > management interface to figure out which one. > > This is what managed enclosures are for. Huh? And how is that supposed to work? I use SAF-TE enclosures. Unless I can access the RAID management app, how can I access that info? That certainly isn't possible with a DPT controller. Besides, SAF-TE can tell what disks are plugged in, not which ones actually work. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 13 22:53:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles528.castles.com [208.214.165.92]) by hub.freebsd.org (Postfix) with ESMTP id A865015512; Mon, 13 Dec 1999 22:53:18 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id WAA01148; Mon, 13 Dec 1999 22:56:12 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912140656.WAA01148@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tom Cc: Mike Smith , freebsd-scsi@freebsd.org Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x In-reply-to: Your message of "Mon, 13 Dec 1999 21:07:22 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 22:56:12 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > I love playing the "which disk is dead" game when a DPT RAID > > > controller's audible alarm is sounding, but I have to boot into the > > > management interface to figure out which one. > > > > This is what managed enclosures are for. > > Huh? And how is that supposed to work? I use SAF-TE enclosures. > Unless I can access the RAID management app, how can I access that info? > That certainly isn't possible with a DPT controller. > > Besides, SAF-TE can tell what disks are plugged in, not which ones > actually work. Any decent managed enclosure has a 'fault' indicator for each drive. Any decent controller will set the 'fault' indicator for a failed drive. I concede your basic point - we need a better software management interface yet; but my original one also stands that these controllers are something that with a bit more encouragement we will be able to depend upon just as well. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 14 11: 3:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by hub.freebsd.org (Postfix) with ESMTP id 82F8014D18 for ; Tue, 14 Dec 1999 11:03:30 -0800 (PST) (envelope-from mreimer@vpop.net) Received: from vpop.net (bilbo.vpop.net [216.160.82.65]) by boromir.vpop.net (8.9.1/8.9.1) with ESMTP id LAA12442 for ; Tue, 14 Dec 1999 11:03:24 -0800 (PST) Message-ID: <38569480.558FA790@vpop.net> Date: Tue, 14 Dec 1999 11:03:28 -0800 From: Matthew Reimer Organization: VPOP Technologies, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Unexpected bus free & swap_pager: indefinite wait buffer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We're running 3.3-stable from about 10/21/1999 on a machine that we haven't physically touched for about four months. It has a (supposedly good) LVD cable with a terminator at the end of the cable, that came with the Asus motherboard. Last night, the kernel started printing the errors below and the machine became unusable: couldn't login, unresponsive shells, though it did still respond to pings. The blknos reported in the swap_pager message repeated in a cycle (e.g., 8944, 328, 8944, 328...), and every now and then another blkno would be added to the cycle, until at the end (just before we hit the reset button) the cycle was 8944,328,2640,174968,44560,42848,40720,3208,512,3160. Are we losing a disk, or is it some kind of bug, or...? Thanks in advance for any help you can offer. Matt Dec 13 17:35:00 merry /kernel: Unexpected busfree. LASTPHASE == 0x40 Dec 13 17:35:01 merry /kernel: SEQADDR == 0x5d Dec 13 17:35:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:35:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:35:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:35:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:36:01 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:36:01 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:36:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:36:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:36:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:36:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:37:01 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:37:01 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:37:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:37:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:37:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:37:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:38:01 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:38:01 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 Dec 13 17:38:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 8944, size: 4096 Dec 13 17:38:21 merry /kernel: swap_pager: indefinite wait buffer: device: 0x20409, blkno: 328, size: 4096 ... Dec 13 18:43:39 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 8944, size: 4096 Dec 13 18:43:39 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 328, size: 4096 Dec 13 18:43:40 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 2640, size: 4096 Dec 13 18:43:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 174968, size: 4096 Dec 13 18:43:41 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 44560, size: 8192 Dec 13 18:43:43 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 42848, size: 4096 Dec 13 18:43:46 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 40720, size: 8192 Dec 13 18:43:48 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 3208, size: 4096 Dec 13 18:43:50 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 512, size: 4096 Dec 13 18:43:58 merry /kernel: swap_pager: indefinite wait buffer: device: 0x204 09, blkno: 3160, size: 4096 Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #0: Thu Oct 21 17:29:20 PDT 1999 mreimer@merry.vpop.net:/usr/src/sys/compile/MERRY Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 451025038 Hz CPU: Pentium II/Xeon/Celeron (451.03-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 268435456 (262144K bytes) avail memory = 258519040 (252460K bytes) Preloaded elf kernel "kernel" at 0xc0292000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 10 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x05 int a irq 10 on pci0.9. 0 fxp0: Ethernet address 00:90:27:32:65:cc vga0: rev 0x00 int a irq 11 on pci0.12.0 Probing for devices on PCI bus 1: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle cda0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 17519MB (35879135 512 byte sectors: 255H 63S/T 2233C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 17519MB (35879135 512 byte sectors: 255H 63S/T 2233C) machine "i386" cpu "I686_CPU" ident MERRY maxusers 80 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options NFS #Network Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options SYSVSHM options SYSVMSG options SYSVSEM options SOFTUPDATES options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" options COMPAT_LINUX config kernel root on da0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 controller ahc0 controller scbus0 device da0 device sa0 device pass0 # atkbdc0 controls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty device npx0 at isa? port IO_NPX irq 13 device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 device fxp0 pseudo-device loop pseudo-device ether pseudo-device pty 32 pseudo-device gzip # Exec gzipped a.out's To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 14 12: 8:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 5CC9615152 for ; Tue, 14 Dec 1999 12:08:50 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00665; Tue, 14 Dec 1999 12:11:24 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912142011.MAA00665@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Reimer Cc: freebsd-scsi@freebsd.org Subject: Re: Unexpected bus free & swap_pager: indefinite wait buffer In-reply-to: Your message of "Tue, 14 Dec 1999 11:03:28 PST." <38569480.558FA790@vpop.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 12:11:24 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > We're running 3.3-stable from about 10/21/1999 on a machine that we > haven't physically touched for about four months. It has a (supposedly > good) LVD cable with a terminator at the end of the cable, that came > with the Asus motherboard. Last night, the kernel started printing the > errors below and the machine became unusable: couldn't login, > unresponsive shells, though it did still respond to pings. > > The blknos reported in the swap_pager message repeated in a cycle (e.g., > 8944, 328, 8944, 328...), and every now and then another blkno would be > added to the cycle, until at the end (just before we hit the reset > button) the cycle was > 8944,328,2640,174968,44560,42848,40720,3208,512,3160. > > Are we losing a disk, or is it some kind of bug, or...? > > Thanks in advance for any help you can offer. > > Matt > > Dec 13 17:35:00 merry /kernel: Unexpected busfree. LASTPHASE == 0x40 This is indicative of a disk going away, either from a firmware bug or overheating. Everything goes downhill from there (the command has been lost, and we don't recover well from that). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 14 13:40:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by hub.freebsd.org (Postfix) with ESMTP id 24E81150E2; Tue, 14 Dec 1999 13:40:11 -0800 (PST) (envelope-from mreimer@vpop.net) Received: from vpop.net (bilbo.vpop.net [216.160.82.65]) by boromir.vpop.net (8.9.1/8.9.1) with ESMTP id NAA25151; Tue, 14 Dec 1999 13:40:10 -0800 (PST) Message-ID: <3856B93D.4D962CB1@vpop.net> Date: Tue, 14 Dec 1999 13:40:13 -0800 From: Matthew Reimer Organization: VPOP Technologies, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Unexpected bus free & swap_pager: indefinite wait buffer References: <199912142011.MAA00665@mass.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote: > > > We're running 3.3-stable from about 10/21/1999 on a machine that we > > haven't physically touched for about four months. It has a (supposedly > > good) LVD cable with a terminator at the end of the cable, that came > > with the Asus motherboard. Last night, the kernel started printing the > > errors below and the machine became unusable: couldn't login, > > unresponsive shells, though it did still respond to pings. > > > > The blknos reported in the swap_pager message repeated in a cycle (e.g., > > 8944, 328, 8944, 328...), and every now and then another blkno would be > > added to the cycle, until at the end (just before we hit the reset > > button) the cycle was > > 8944,328,2640,174968,44560,42848,40720,3208,512,3160. > > > > Are we losing a disk, or is it some kind of bug, or...? > > > > Thanks in advance for any help you can offer. > > > > Matt > > > > Dec 13 17:35:00 merry /kernel: Unexpected busfree. LASTPHASE == 0x40 > > This is indicative of a disk going away, either from a firmware bug or > overheating. Everything goes downhill from there (the command has been > lost, and we don't recover well from that). Thanks for the answer, Mike. The possibility of the disk overheating fits the symptom of the Adaptec probe taking a long time for that drive. :( Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 14 14:41:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from admin.us.net (admin.us.net [198.240.72.18]) by hub.freebsd.org (Postfix) with ESMTP id 941CF14BEA; Tue, 14 Dec 1999 14:41:06 -0800 (PST) (envelope-from stimpy@admin.us.net) Received: from localhost (stimpy@localhost) by admin.us.net (8.8.8/8.8.8) with ESMTP id RAA17748; Tue, 14 Dec 1999 17:41:09 -0500 (EST) X-Provider: US Net - Advanced Internet Services - 301-361-USNET - info@us.net Where Business Connects! (tm) -- http://www.us.net/ Date: Tue, 14 Dec 1999 17:41:09 -0500 (EST) From: Brent Scott To: freebsd-hardware@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: integrated adaptec AIC-7896 controller w/ 2.2.8 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 Hello, (apologies for the cross-posting, I'm not sure which is the best path to follow here) We're trying to build a pair of 2.2.8 servers around Intel L440GX+ Mobos w/ an integrated Adaptec AIC-7896 controller, and we've learned (ack!) that 2.2.8 does not support U2W LVD SCSI natively. It appears we need the CAM drivers. However, since this is a virgin install, we need a bootable floppy that we can use to get the SCSI gear recognized for an install, or some other way to install 2.2.8 from scratch. If someone can schlep a boot image this way that includes CAM support, or if there is a more sane way, please advise. We have some old 1542 cards around but they obviously can't juggle the U2W LVD drives we've got in there, or we'd gen a kernel on that config to get off the ground. We also have a PCI 2940-U2W card we could yank from a server for a few hours if necessary, but we'd prefer not to do that if at all possible. Thanks! Brent Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 14 15:10:49 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 2A75815119; Tue, 14 Dec 1999 15:10:40 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA42889; Tue, 14 Dec 1999 16:09:19 -0700 (MST) (envelope-from ken) Date: Tue, 14 Dec 1999 16:09:19 -0700 From: "Kenneth D. Merry" To: Brent Scott Cc: freebsd-hardware@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: integrated adaptec AIC-7896 controller w/ 2.2.8 Message-ID: <19991214160919.A42799@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from stimpy@admin.us.net on Tue, Dec 14, 1999 at 05:41:09PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 14, 1999 at 17:41:09 -0500, Brent Scott wrote: > (apologies for the cross-posting, I'm not sure which is the best path to follow here) > > We're trying to build a pair of 2.2.8 servers around Intel L440GX+ Mobos > w/ an integrated Adaptec AIC-7896 controller, and we've learned (ack!) > that 2.2.8 does not support U2W LVD SCSI natively. It appears we need the > CAM drivers. However, since this is a virgin install, we need a bootable > floppy that we can use to get the SCSI gear recognized for an install, or > some other way to install 2.2.8 from scratch. If someone can schlep a > boot image this way that includes CAM support, or if there is a more sane > way, please advise. There is a CAM-modified FreeBSD snapshot from around FreeBSD 2.2.7 here: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/development/cam I'm not sure, however, that it supports the 7896. It might. There are also diffs in that directory that you can apply against 2.2.x for CAM support. They'll probably need tweaking to work completely. Keep in mind that that version of CAM is fairly old at this point (it is mid-1998 vintage), and is missing a lot of bug-fixes that have gone into the tree since then. I would recommend against using a CAM-modified 2.2.x if you can get around it at all. It really would be much easier to just use a newer release. FreeBSD 3.3 supports your hardware, although -stable has some important bugfixes for the 7896/7 boards. You can get a FreeBSD 3.3-stable snapshot here: ftp://current.FreeBSD.ORG/pub/FreeBSD/snapshots/i386 Those snapshots represent what will be (tomorrow, I think) FreeBSD 3.4. > We have some old 1542 cards around but they obviously can't juggle the U2W > LVD drives we've got in there, or we'd gen a kernel on that config to get > off the ground. We also have a PCI 2940-U2W card we could yank from a > server for a few hours if necessary, but we'd prefer not to do that if at > all possible. Well, you can use LVD drives with 1542 controllers. The LVD disks will negotiate down to fast narrow SCSI. Keep in mind that LVD disks don't have terminators, so you will need external terminators for them. The 2940U2W uses an Adaptec 7890, which is also only supported in CAM. So that won't help you any. 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 Dec 14 15:49:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 95A3F14E8C; Tue, 14 Dec 1999 15:49:11 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11xzAm-0002DB-00; Tue, 14 Dec 1999 13:07:52 -0800 Date: Tue, 14 Dec 1999 13:07:51 -0800 (PST) From: Tom To: Brent Scott Cc: freebsd-hardware@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: integrated adaptec AIC-7896 controller w/ 2.2.8 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 14 Dec 1999, Brent Scott wrote: > Hello, > > (apologies for the cross-posting, I'm not sure which is the best path to follow here) > > We're trying to build a pair of 2.2.8 servers around Intel L440GX+ Mobos > w/ an integrated Adaptec AIC-7896 controller, and we've learned (ack!) > that 2.2.8 does not support U2W LVD SCSI natively. It appears we need the Use 3.3 instead? 2.2.8 is being mantained yet, but nothing new is being added, so don't hold your breath for support. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 14 17:49:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from admin.us.net (admin.us.net [198.240.72.18]) by hub.freebsd.org (Postfix) with ESMTP id 4862A15125; Tue, 14 Dec 1999 17:49:08 -0800 (PST) (envelope-from stimpy@admin.us.net) Received: from localhost (stimpy@localhost) by admin.us.net (8.8.8/8.8.8) with ESMTP id UAA21056; Tue, 14 Dec 1999 20:49:09 -0500 (EST) X-Provider: US Net - Advanced Internet Services - 301-361-USNET - info@us.net Where Business Connects! (tm) -- http://www.us.net/ Date: Tue, 14 Dec 1999 20:49:08 -0500 (EST) From: Brent Scott To: freebsd-scsi@freebsd.org Cc: freebsd-hardware@freebsd.org Subject: thanks. Was: integrated adaptec AIC-7896 controller w/ 2.2.8 In-Reply-To: <199912150048.QAA04613@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for the advice so far. We're going to make the leap and jump for 3.3 (or the rumored 3.4 due any hour). We've been tied to the 2.2.x tree for a long time, so we were reluctant to move to the next era. This looks like the kind of situation that would warrant going for it. Brent Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 15 0:50:18 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 BC56D15337 for ; Wed, 15 Dec 1999 00:50:12 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id JAA21154 for scsi@FreeBSD.ORG; Wed, 15 Dec 1999 09:50:11 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id JAA90184; Wed, 15 Dec 1999 09:33:47 +0100 (MET) (envelope-from j) Message-ID: <19991215093347.10192@uriah.heep.sax.de> Date: Wed, 15 Dec 1999 09:33:47 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: 512 / 2048 switchable CDROM (Pioneer DRM-600) Reply-To: Joerg Wunsch References: <3831B5A2.5C66CC59@hiwaay.net> <199911162320.QAA68076@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199911162320.QAA68076@panzer.kdm.org>; from Kenneth D. Merry on Tue, Nov 16, 1999 at 04:20:50PM -0700 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 (Very old thread.) As Kenneth D. Merry wrote: > In general, yeah, you'll want to use 2K sectors with FreeBSD. I > don't think the CD driver particularly cares about the sector size, > but I'm not sure how the cd9660 code would react to a non-2K sectors > size. It probably won't notice at all :), since it would only try transactions in multiples of 2K which are still supposed to work even if the drive supported a smaller blocksize. If the drive supports 512-byte deblocking, you can of course also mount a UFS CD-ROM then. :) (Or to 2K blocksize devices work with UFS now?) -- 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 Wed Dec 15 1:20:15 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 41D5F1546E for ; Wed, 15 Dec 1999 01:20:13 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id KAA21692 for freebsd-scsi@FreeBSD.ORG; Wed, 15 Dec 1999 10:20:12 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id KAA90290; Wed, 15 Dec 1999 10:09:57 +0100 (MET) (envelope-from j) Message-ID: <19991215100956.30691@uriah.heep.sax.de> Date: Wed, 15 Dec 1999 10:09:56 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? Reply-To: Joerg Wunsch References: <19991212082403.A34441@theatre.sax.de> <19991212223611.A53246@theatre.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19991212223611.A53246@theatre.sax.de>; from Martin Welk on Sun, Dec 12, 1999 at 10:36:11PM +0100 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 Martin Welk wrote: > However, it worked fine, although some of the CD-ROMs I was going to > use were not ISO compliant, so a friend of mine in Dresden (who > brought FreeBSD to me and me to FreeBSD) helped me with some kernel > patch and I was happy again. Hehe, you know that friend from Dresden? I do. :-) Since that time, FreeBSD understands ancient High-Sierra CDs. ;-) > Usually, there are two filemarks written to the tape, but there are > devices ``that can only write 1'' (man page for mt, there is furtter > informations). Actually, they can all write 2, but on QIC & alike (don't know for the newer Tandberg MLRs) you cannot go to EOM, then backspace over the second of the filemarks, and try writing from there -- you'll get a `write append error'. I think all other drives can do this, and the drive in question here was DDS, so it should be able to work with 2 FMs. Btw., Matt, wouldn't it make sense to automatically turn the driver into 1 FM mode for any "TANDBERG" drive? I don't know how their DLTs are announcing, though... Anything else they're building is QIC or upwards compatible, and AFAIK they are the only vendor still producing QIC drives at all. And please, default to variable mode for all the larger QIC drives... :) Actually, i'd rather see the historical FreeBSD behaviour restored where the default was variable for any QIC cartridge >= 525, and 512-byte fixed for anything up to QIC-150. Sure, this requires to read one block until the drive will announce an actual density, but this algorithm used to work well in previous versions of FreeBSD, and you have to spend the time for ``logging in'' the tape once per mount session anyway, so it doesn't matter. (This can take a bit of time on a larger QIC medium, i know.) -- 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 Wed Dec 15 2:24:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sol.freibergnet.de (sol.freibergnet.de [194.123.255.4]) by hub.freebsd.org (Postfix) with ESMTP id F2DB0154BF for ; Wed, 15 Dec 1999 02:24:05 -0800 (PST) (envelope-from mw@sol.freibergnet.de) Received: (from mw@localhost) by sol.freibergnet.de (8.9.3/8.9.3) id LAA06898; Wed, 15 Dec 1999 11:23:16 +0100 (CET) (envelope-from mw) Date: Wed, 15 Dec 1999 11:23:16 +0100 From: Martin Welk To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? Message-ID: <19991215112316.B47501@sol.freibergnet.de> Reply-To: mw@freibergnet.de References: <19991212082403.A34441@theatre.sax.de> <19991212223611.A53246@theatre.sax.de> <19991215100956.30691@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <19991215100956.30691@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Wed, Dec 15, 1999 at 10:09:56AM +0100 Organization: FreibergNet Systemhaus GbR, D-09599 Freiberg X-Operating-System: FreeBSD http://www.freebsd.org/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 15, 1999 at 10:09:56AM +0100, J Wunsch wrote: > Hehe, you know that friend from Dresden? I do. :-) I guess you see him every morning when you pass the mirror in your bathroom. He was that guy who convinced me to give FreeBSD a try, at a time, when everybody told me that ``six CD-ROM drives in one machine _should_ work, but I haven't tried that'' :-) Regards, Martin -- FreibergNet Systemhaus GbR Martin Welk * Sales, Support Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781387 Unternehmensgruppe Liebscher & Partner fax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 15 8: 5:52 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 71A4F153B2 for ; Wed, 15 Dec 1999 08:05:47 -0800 (PST) (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 IAA20853; Wed, 15 Dec 1999 08:07:27 -0800 Date: Wed, 15 Dec 1999 08:07:27 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? In-Reply-To: <19991215100956.30691@uriah.heep.sax.de> 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 > > Actually, they can all write 2, but on QIC & alike (don't know for the > newer Tandberg MLRs) you cannot go to EOM, then backspace over the > second of the filemarks, and try writing from there -- you'll get a > `write append error'. I think all other drives can do this, and the > drive in question here was DDS, so it should be able to work with 2 > FMs. Yet another reason why 1FM@EOT should be the default. Unfortunately, we have too many ill-informed or fanciful or contrary users to allow this (I tried to get this as a default for 4.0). > > Btw., Matt, wouldn't it make sense to automatically turn the driver > into 1 FM mode for any "TANDBERG" drive? I don't know how their DLTs > are announcing, though... Anything else they're building is QIC or > upwards compatible, and AFAIK they are the only vendor still producing > QIC drives at all. > > And please, default to variable mode for all the larger QIC > drives... :) It seems to me that rather than proliferating compiled in quirks, we should work on the magical table that can be parsed at boot time. > Actually, i'd rather see the historical FreeBSD behaviour restored > where the default was variable for any QIC cartridge >= 525, and > 512-byte fixed for anything up to QIC-150. Sure, this requires to > read one block until the drive will announce an actual density, but > this algorithm used to work well in previous versions of FreeBSD, and > you have to spend the time for ``logging in'' the tape once per mount > session anyway, so it doesn't matter. (This can take a bit of time on > a larger QIC medium, i know.) Yes- you should check the latest driver out, Joerg. It does a test read at mount time. And I have people yelling it me because of the time it takes. Can't please anyone.... a driver writer's lot is so hard ("Would you like some cheese and crackers to go with that whine?") -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 15 15:22: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 D260A153F3 for ; Wed, 15 Dec 1999 15:22:40 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id AAA07146 for freebsd-scsi@FreeBSD.ORG; Thu, 16 Dec 1999 00:22:39 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id AAA92225; Thu, 16 Dec 1999 00:11:41 +0100 (MET) (envelope-from j) Message-ID: <19991216001140.64432@uriah.heep.sax.de> Date: Thu, 16 Dec 1999 00:11:40 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? Reply-To: Joerg Wunsch References: <19991215100956.30691@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Wed, Dec 15, 1999 at 08:07:27AM -0800 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 Matthew Jacob wrote: > Yet another reason why 1FM@EOT should be the default. Yep > Unfortunately, we have too many ill-informed or fanciful or contrary > users to allow this (I tried to get this as a default for 4.0). That's like Poul-Hennings bike shed problem... It's probably better to make no noise about it and just change it in a ``mumble, mumble, improve the sa(4) driver a little'' commit than asking publically before. ;-) I bet nobody would even notice the change if it happened... (In particular, i think the driver could simulate 2 FM's once it noticed the EOM signal from the drive.) > It seems to me that rather than proliferating compiled in quirks, we > should work on the magical table that can be parsed at boot time. I'm in favour of any hac^H^H^Hsolution that works. :) > Yes- you should check the latest driver out, Joerg. *blush* I've built a release yesterday, but the /usr/src of my machine's already about 2 months old now, right... It probably won't be updated before year 2000 since i'm going to leave for Russia next week, visiting my girlfriend there. > It does a test read at mount time. And I have people yelling it me > because of the time it takes. They simply didn't understand that this time will always be taken, either at the time the first mt(1) command is issued, or by the time of the first actual read/write operation... > Can't please anyone.... a driver writer's lot is so hard Ah well, you're robust enough to bear it. ;-) -- 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 Wed Dec 15 16:58:39 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 CB01915650; Wed, 15 Dec 1999 16:58:33 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id RAA30807; Wed, 15 Dec 1999 17:48:28 -0700 (MST) Date: Wed, 15 Dec 1999 17:48:28 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199912160048.RAA30807@narnia.plutotech.com> To: Mike Smith Cc: scsi@FreeBSD.ORG Subject: Re: Unexpected bus free & swap_pager: indefinite wait buffer X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199912142011.MAA00665@mass.cdrom.com> 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 <199912142011.MAA00665@mass.cdrom.com> you wrote: >> We're running 3.3-stable from about 10/21/1999 on a machine that we >> haven't physically touched for about four months. It has a (supposedly >> good) LVD cable with a terminator at the end of the cable, that came >> with the Asus motherboard. Last night, the kernel started printing the >> errors below and the machine became unusable: couldn't login, >> unresponsive shells, though it did still respond to pings. >> >> The blknos reported in the swap_pager message repeated in a cycle (e.g., >> 8944, 328, 8944, 328...), and every now and then another blkno would be >> added to the cycle, until at the end (just before we hit the reset >> button) the cycle was >> 8944,328,2640,174968,44560,42848,40720,3208,512,3160. >> >> Are we losing a disk, or is it some kind of bug, or...? >> >> Thanks in advance for any help you can offer. >> >> Matt >> >> Dec 13 17:35:00 merry /kernel: Unexpected busfree. LASTPHASE == 0x40 > > This is indicative of a disk going away, either from a firmware bug or > overheating. Everything goes downhill from there (the command has been > lost, and we don't recover well from that). Hmm. We should have retried the command. Of course, this might have failed if the drive decided to stop responding. Does the swap-pager code in 3.3 talk about "indefinite wait buffers" if the I/O system returns an error? I would expect this only if the command never returns, but I'll have to poke around in the code to find out. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 15 18:28:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from apollo.ocsny.com (apollo.ocsny.com [204.107.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 7480014D28 for ; Wed, 15 Dec 1999 18:28:38 -0800 (PST) (envelope-from mikel@ocsny.com) Received: from localhost (mikel@localhost) by apollo.ocsny.com (8.9.2/8.9.3) with ESMTP id VAA55041 for ; Wed, 15 Dec 1999 21:27:08 -0500 (EST) Date: Wed, 15 Dec 1999 21:27:08 -0500 (EST) From: Mikel To: freebsd-scsi@freebsd.org Subject: bt950r drivers 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 Per chance is anyone out there working on a port of the driver set for the bt950r raid uw3 scsi controller? On a side note I once found a link to writing fBSD drivers but it seems to be broken...(probly from the refering page...) anyway does anyone know of a current howto? Cheers, mikel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 15 18:35:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id CE87E14CE9 for ; Wed, 15 Dec 1999 18:35:21 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA05247; Wed, 15 Dec 1999 18:38:05 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912160238.SAA05247@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mikel Cc: freebsd-scsi@freebsd.org Subject: Re: bt950r drivers In-reply-to: Your message of "Wed, 15 Dec 1999 21:27:08 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Dec 1999 18:38:05 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Per chance is anyone out there working on a port of the driver set for the > bt950r raid uw3 scsi controller? It's not actually a RAID controller; it's a SCSI controller with some RAID software. Mylex make "real" RAID controllers as well, and we support the SCSI:SCSI ones (of course) as well as the PCI:SCSI ones (in 4.x, and under 3.x with some patches and limitations). > On a side note I once found a link to writing fBSD drivers but it seems to > be broken...(probly from the refering page...) anyway does anyone know of > a current howto? "Read the source". Seriously. There's nothing better out there at the moment, I'm afraid. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 16 2:41:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from meloghost.melog.de (meloghost.melog.de [193.155.17.3]) by hub.freebsd.org (Postfix) with ESMTP id 799CE14F23 for ; Thu, 16 Dec 1999 02:41:53 -0800 (PST) (envelope-from hf@Melog.DE) Received: from janus (janus.melog.de [193.155.17.21]) by meloghost.melog.de (8.9.3/8.9.3) with ESMTP id LAA18477; Thu, 16 Dec 1999 11:41:27 +0100 Message-Id: <4.2.2.19991216114021.00b192a0@meloghost.melog.de> X-Sender: hf@meloghost.melog.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Dec 1999 11:41:41 +0100 To: mjacob@feral.com From: Hauke Fath Subject: Re: filemarks? Cc: Joerg Wunsch , freebsd-scsi@FreeBSD.ORG In-Reply-To: References: <19991215100956.30691@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:07 15.12.99 -0800, Matthew Jacob wrote: > > > > Actually, they can all write 2, but on QIC & alike (don't know for the > > newer Tandberg MLRs) you cannot go to EOM, then backspace over the > > second of the filemarks, and try writing from there -- you'll get a > > `write append error'. I think all other drives can do this, and the > > drive in question here was DDS, so it should be able to work with 2 > > FMs. > >Yet another reason why 1FM@EOT should be the default. Unfortunately, we >have too many ill-informed or fanciful or contrary users to allow this (I >tried to get this as a default for 4.0). Matt, in what way exactly would this affect userland tools? (Tandberg SLR4/5, NetBSD here.) hauke -- Hauke Fath Tangro Software Components GmbH D-69115 Heidelberg hf@Tangro.DE Ruf +49-6221-13336-35, Fax -21 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 16 8:41:50 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 7006414E17 for ; Thu, 16 Dec 1999 08:41:48 -0800 (PST) (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 IAA26146; Thu, 16 Dec 1999 08:43:18 -0800 Date: Thu, 16 Dec 1999 08:43:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Hauke Fath Cc: Joerg Wunsch , freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? In-Reply-To: <4.2.2.19991216114021.00b192a0@meloghost.melog.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Dec 1999, Hauke Fath wrote: > At 08:07 15.12.99 -0800, Matthew Jacob wrote: > > > > > > Actually, they can all write 2, but on QIC & alike (don't know for the > > > newer Tandberg MLRs) you cannot go to EOM, then backspace over the > > > second of the filemarks, and try writing from there -- you'll get a > > > `write append error'. I think all other drives can do this, and the > > > drive in question here was DDS, so it should be able to work with 2 > > > FMs. > > > >Yet another reason why 1FM@EOT should be the default. Unfortunately, we > >have too many ill-informed or fanciful or contrary users to allow this (I > >tried to get this as a default for 4.0). > > Matt, > > in what way exactly would this affect userland tools? > (Tandberg SLR4/5, NetBSD here.) ( ^^^^^^ ?? Note that this is a FreeBSD list and (comments made are with respect to the FreeBSD tape driver. Very little (testing has been done with the same h/w under NetBSD) As far as I know, it's only tcopy that is affected by this (tcopy doesn't work on tapes that have a single tape mark). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 16 9: 3:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from meloghost.melog.de (meloghost.melog.de [193.155.17.3]) by hub.freebsd.org (Postfix) with ESMTP id EFED6156C0 for ; Thu, 16 Dec 1999 09:03:18 -0800 (PST) (envelope-from hf@Melog.DE) Received: from janus (janus.melog.de [193.155.17.21]) by meloghost.melog.de (8.9.3/8.9.3) with ESMTP id SAA21233; Thu, 16 Dec 1999 18:03:11 +0100 Message-Id: <4.2.2.19991216175352.00b83250@meloghost.melog.de> X-Sender: hf@meloghost.melog.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Dec 1999 18:03:24 +0100 To: mjacob@feral.com From: Hauke Fath Subject: Re: filemarks? Cc: Hauke Fath , Joerg Wunsch , freebsd-scsi@FreeBSD.ORG In-Reply-To: References: <4.2.2.19991216114021.00b192a0@meloghost.melog.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:43 16.12.99 -0800, Matthew Jacob wrote: >On Thu, 16 Dec 1999, Hauke Fath wrote: > > > Matt, > > > > in what way exactly would this affect userland tools? > > (Tandberg SLR4/5, NetBSD here.) >( ^^^^^^ ?? Note that this is a FreeBSD list and I know. >(comments made are with respect to the FreeBSD tape driver. Very little >(testing has been done with the same h/w under NetBSD) Sure. NetBSD currently lines up all known QIC drives in st.c's quirk table, most of them only to specify the blocksize. And it doesn't deal at all with the [12]FM@EOD issue. But the question whether to write one or two filemarks at EOD and how to deal with drives that do not like that (QIC) is neither driver- nor platform specific. hauke >As far as I know, it's only tcopy that is affected by this (tcopy doesn't >work on tapes that have a single tape mark). -- Hauke Fath Tangro Software Components GmbH D-69115 Heidelberg hf@Tangro.DE Ruf +49-6221-13336-35, Fax -21 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 16 9:32:35 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 CD05614ECB for ; Thu, 16 Dec 1999 09:32:33 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA26355; Thu, 16 Dec 1999 09:34:01 -0800 Date: Thu, 16 Dec 1999 09:34:01 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Hauke Fath Cc: Joerg Wunsch , freebsd-scsi@FreeBSD.ORG Subject: Re: filemarks? In-Reply-To: <4.2.2.19991216175352.00b83250@meloghost.melog.de> 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 > > But the question whether to write one or two filemarks at EOD and how to > deal with drives that do not like that (QIC) is neither driver- nor > platform specific. In my opinion, oft stated, it's only devices that cannot determine physical eot that need two filemarks. As far as I know, only 1/2" Reel tape drives have this property. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 3:16:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from meloghost.melog.de (meloghost.melog.de [193.155.17.3]) by hub.freebsd.org (Postfix) with ESMTP id 2DE6F14FCD for ; Fri, 17 Dec 1999 03:16:42 -0800 (PST) (envelope-from hf@Melog.DE) Received: from janus (janus.melog.de [193.155.17.21]) by meloghost.melog.de (8.9.3/8.9.3) with ESMTP id MAA24457; Fri, 17 Dec 1999 12:16:24 +0100 Message-Id: <4.2.2.19991217120438.00c89250@meloghost.melog.de> X-Sender: hf@meloghost.melog.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 17 Dec 1999 12:16:38 +0100 To: mjacob@feral.com From: Hauke Fath Subject: Re: filemarks? Cc: Hauke Fath , Joerg Wunsch , freebsd-scsi@FreeBSD.ORG In-Reply-To: References: <4.2.2.19991216175352.00b83250@meloghost.melog.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:34 16.12.99 -0800, Matthew Jacob wrote: >In my opinion, oft stated, it's only devices that cannot determine >physical eot that need two filemarks. As far as I know, only 1/2" Reel >tape drives have this property. Sounds quite sane to me. Better to quirk half-inch reel tape than the rest of the tape world. ;) What were the counter arguments? Like you said, userland does not (should not) care about the details of EOD detection. How does an application learn about EOD? By an error code? A while back, I saw you advocating fixed block sizes for QIC drives. Can you explain your reasons? I have seen many problems with this default (interoperability) and have hacked the NetBSD st.c to default to variable blocksize. hauke -- Hauke Fath Tangro Software Components GmbH D-69115 Heidelberg hf@Tangro.DE Ruf +49-6221-13336-35, Fax -21 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 3:40:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fuchs.omnilink.de (hase.omnilink.de [194.64.25.65]) by hub.freebsd.org (Postfix) with ESMTP id C199C14C41 for ; Fri, 17 Dec 1999 03:40:33 -0800 (PST) (envelope-from ob@omnilink.net) Received: by fuchs.omnilink.de; id MAA21657; Fri, 17 Dec 1999 12:38:26 +0100 (MET) Received: from sondermuell.omnilink.de(194.64.25.218) by fuchs.omnilink.de via smap (V4.2) id xma021653; Fri, 17 Dec 99 12:37:52 +0100 Message-ID: <008101bf4883$e275cd70$da1940c2@omnilink.de> Reply-To: "Oliver Blasnik" From: "Oliver Blasnik" To: Subject: Results of CRD5440-Checks Date: Fri, 17 Dec 1999 12:43:06 +0100 Organization: Omnilink ISC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, here are the results of my bugtracking of that weird = tagged-queueing-problem (if anyone want's to know it). It took about one = day to come up with this. Environment:=20 System 1: P133, ASUS-MB (some oooold) System 2: PII/366, ASUS P2B-S, Scsi-Bios 2.11 (latest) System 3: dual PII/450, ASUS P2B-DS, Scsi-Bios 2.11 (latest) Two CRD5440, different Manufacturing Date, 2 logical Partitions Adaptec 2940UW, latest Bios (1.34.x) =20 Results: The problems do occure on BOTH scsi-controllers (onboard 7890 and 2940) = in single-host AND dual-host-mode of the CRD. They do NOT occure on = System 1, but System 2 and 3 (the faster machines). There is no difference between FreeBSD 3.1R, 3.3R and 3.4RC. After changing cam_xpt.c to disable TQ (or disable TQ directly on the = CRD's), the systems were stable again. There was no real difference = between setting a fixed value of 4 tqs/disk or dynamic-mode (fixed did a = little bit longer...). The problem ONLY comes up after accessing both logical CRD-partitions = (da0 and da1 in FreeBSD) in a high-load-state (40 dd's for one, 40 dd's = for the other drive to fill up the command cache). If just accessing one = partition, the system worked well. So, resulting fact is -> this controller does NOT work correctly, if = tagged queuing enabled with more than one active logical partition. I = switched off TQ at controller-level to let the kernel unchanged. = Possibly this information should go to some type of hcl. I will post a full-featuerd report to crd-tech and hope to get a result. Cu, Oliver --=20 __ OMNILINK Internet Service Center GmbH / \ Hahnstrasse 70, 60528 Frankfurt __\ /_________ Tel.: (0 69)66 44 10 Fax: (0 69)66 44 11 99 O M N I L I N K http://www.omnilink.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 11:54:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B55F015798 for ; Fri, 17 Dec 1999 11:54:25 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id LAA19353; Fri, 17 Dec 1999 11:52:06 -0800 (PST) Message-Id: <199912171952.LAA19353@implode.root.com> To: "Oliver Blasnik" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Results of CRD5440-Checks In-reply-to: Your message of "Fri, 17 Dec 1999 12:43:06 +0100." <008101bf4883$e275cd70$da1940c2@omnilink.de> From: David Greenman Reply-To: dg@root.com Date: Fri, 17 Dec 1999 11:52:06 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >here are the results of my bugtracking of that weird tagged-queueing-problem (if anyone want's to know it). It took about one day to come up with this. > >Environment: > System 1: P133, ASUS-MB (some oooold) > System 2: PII/366, ASUS P2B-S, Scsi-Bios 2.11 (latest) > System 3: dual PII/450, ASUS P2B-DS, Scsi-Bios 2.11 (latest) > Two CRD5440, different Manufacturing Date, 2 logical Partitions > Adaptec 2940UW, latest Bios (1.34.x) > >Results: >The problems do occure on BOTH scsi-controllers (onboard 7890 and 2940) in single-host AND dual-host-mode of the CRD. They do NOT occure on System 1, but System 2 and 3 (the faster machines). >There is no difference between FreeBSD 3.1R, 3.3R and 3.4RC. > >After changing cam_xpt.c to disable TQ (or disable TQ directly on the CRD's), the systems were stable again. There was no real difference between setting a fixed value of 4 tqs/disk or dynamic-mode (fixed did a little bit longer...). > >The problem ONLY comes up after accessing both logical CRD-partitions (da0 and da1 in FreeBSD) in a high-load-state (40 dd's for one, 40 dd's for the other drive to fill up the command cache). If just accessing one partition, the system worked well. > >So, resulting fact is -> this controller does NOT work correctly, if tagged queuing enabled with more than one active logical partition. I switched off TQ at controller-level to let the kernel unchanged. Possibly this information should go to some type of hcl. > >I will post a full-featuerd report to crd-tech and hope to get a result. We use FreeBSD's native partition support for the different filesystems on our systems and don't use the logical partitions of the CRD-5440, so that probably explains why we haven't seen the problem. I'm very interested to hear what CMD has to say about it... -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 12:13:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 6AC0414F81 for ; Fri, 17 Dec 1999 12:13:25 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id MAA19446; Fri, 17 Dec 1999 12:11:03 -0800 (PST) Message-Id: <199912172011.MAA19446@implode.root.com> To: "Oliver Blasnik" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Results of CRD5440-Checks In-reply-to: Your message of "Fri, 17 Dec 1999 12:43:06 +0100." <008101bf4883$e275cd70$da1940c2@omnilink.de> From: David Greenman Reply-To: dg@root.com Date: Fri, 17 Dec 1999 12:11:03 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The problem ONLY comes up after accessing both logical CRD-partitions (da0 and da1 in FreeBSD) in a high-load-state (40 dd's for one, 40 dd's for the other drive to fill up the command cache). If just accessing one partition, the system worked well. > >So, resulting fact is -> this controller does NOT work correctly, if tagged queuing enabled with more than one active logical partition. I switched off TQ at controller-level to let the kernel unchanged. Possibly this information should go to some type of hcl. > >I will post a full-featuerd report to crd-tech and hope to get a result. BTW, when you talk to CMD, ask them about another bug that I found with the CRD-5440: If you have a multiple of 640KB of dirty buffers in the write- back cache when a SCSI synchronize cache command is issued, the controller will lock up (crash). This can happen when you reboot the system (FreeBSD issues a synchronize cache command on last device close), but in practice is very unlikely - there isn't usually that much in the cache when the filesystem umount is done. To reproduce on a system with the CRD-5440 as da1 and not otherwise mounted, do: dd if=/dev/zero of=/dev/rda1 bs=64k count=10 ...will kill it every time, recoverable only with a power cycle. bs*count can be any multiple of 640KB. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 12:16:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id DCD8B157DF for ; Fri, 17 Dec 1999 12:16:34 -0800 (PST) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id MAA19483; Fri, 17 Dec 1999 12:14:15 -0800 (PST) Message-Id: <199912172014.MAA19483@implode.root.com> To: "Oliver Blasnik" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Results of CRD5440-Checks In-reply-to: Your message of "Fri, 17 Dec 1999 12:11:03 PST." <199912172011.MAA19446@implode.root.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 17 Dec 1999 12:14:15 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > To reproduce on a system with the CRD-5440 as da1 and not otherwise >mounted, do: > >dd if=/dev/zero of=/dev/rda1 bs=64k count=10 Forgot to mention: this will destroy any filesystems you have on the RAID set (since it overwrites the label and other stuff at the front)...so don't try this unless you know what you're doing! -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 14:17:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.omnilink.net (mail.omnilink.net [194.64.25.6]) by hub.freebsd.org (Postfix) with ESMTP id 0AFAB14DBE for ; Fri, 17 Dec 1999 14:17:40 -0800 (PST) (envelope-from ob@omnilink.net) Received: from ntsrv2 (my.jav.net [212.255.14.194]) by mail.omnilink.net (8.9.3/8.9.3) with SMTP id XAA55060; Fri, 17 Dec 1999 23:18:41 +0100 (CET) (envelope-from ob@omnilink.net) Message-ID: <004201bf48dc$5e9f81e0$c20effd4@jav.net> From: "Oliver Blasnik" To: Cc: References: <199912172014.MAA19483@implode.root.com> Subject: Re: Results of CRD5440-Checks Date: Fri, 17 Dec 1999 23:16:23 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Greenman wote: > > To reproduce on a system with the CRD-5440 as da1 and not otherwise > >mounted, do: > >dd if=/dev/zero of=/dev/rda1 bs=64k count=10 > Forgot to mention: this will destroy any filesystems you have on the RAID > set (since it overwrites the label and other stuff at the front)...so don't > try this unless you know what you're doing! Not any, just that one logical partition da1... I'll get two new raid-systems at wednesday (hopefully...) and try that out. Wanna see a crashed crd :) The reason for setting up multiple logical partitions is simple: 2 boot-partitions with about 2Gig, 1 Data-Partition. So, two hosts can boot up from the same controller and (will be set up later, did this before with solaris) one can take over control with the same data if needed (eg. for high-availability). > David Greenman Cu, Oliver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 17 17:11:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from fep6.mail.ozemail.net (fep6.mail.ozemail.net [203.2.192.123]) by hub.freebsd.org (Postfix) with ESMTP id 93EA814D9E for ; Fri, 17 Dec 1999 17:11:42 -0800 (PST) (envelope-from count@ozemail.com.au) Received: from mycroft.marshall.id.au (slmlb20p37.ozemail.com.au [210.84.133.229]) by fep6.mail.ozemail.net (8.9.0/8.6.12) with SMTP id MAA02071 for ; Sat, 18 Dec 1999 12:11:37 +1100 (EST) From: "Geoffrey C. Marshall" Organization: Tobacco Chewers and Body Painters Association To: freebsd-scsi@freebsd.org Subject: Re: Results of CRD5440-Checks Date: Sat, 18 Dec 1999 12:01:04 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <004201bf48dc$5e9f81e0$c20effd4@jav.net> MIME-Version: 1.0 Message-Id: <99121812112800.68037@mycroft.marshall.id.au> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I hope this is the appropriate place... I run CURRENT (more or less) on a Machine with a Gigabyte motherboard that includes a 2940UW Dual. This works quite well even though my devices are not (currently) optimised. I have recently tried to fit an AVA 2902I into the system to handle my external scanner. Works just fine under windows, but FreeBSD karks it with an 'automatic reboot'. The first and second controllers are recognised, no problem (these being the ones on the mother board) but it seems that fairly late in the boot process something dies. Now I can't post a dmesg, because I can't boot with the card there. What information can I provide (and how do I get it!) to whom to get some assistance about this matter? Any ideas anyone? G... -- count@nemesis.com.au Practice random acts of kindness and senseless beauty. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 19 11:21:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by hub.freebsd.org (Postfix) with ESMTP id 64B5514CFA for ; Sun, 19 Dec 1999 11:21:27 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-100-167.villette.club-internet.fr [194.158.100.167]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA26739 for ; Sun, 19 Dec 1999 20:21:24 +0100 (MET) Date: Sun, 19 Dec 1999 21:47:38 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: scsi@FreeBSD.org Subject: sym driver for FreeBSD-3.4.0 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 have given a try to RELENG_3_4_0_RELEASE after having completed it with= =20 my latest sym driver version (1.1.0). People interested in having this driver added to their 3.4.0 tree within a= =20 minute may want to download the following files: ftp://ftp.tux.org/pub/roudier/drivers/freebsd/stable/README ftp://ftp.tux.org/pub/roudier/drivers/freebsd/stable/sym-driver-1.1.0-for-f= reebsd-3.4.0.patch.gz and apply the patch to a fresh 3.4.0 source tree. 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 Dec 20 9:38:40 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 D285D14D54; Mon, 20 Dec 1999 09:38:37 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA12498; Mon, 20 Dec 1999 09:39:47 -0800 Date: Mon, 20 Dec 1999 09:39:47 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Polstra Cc: Hauke Fath , Joerg Wunsch , "Rodney W. Grimes" , Thomas David Rivers , Bob Bishop , Greg Lehey , Stephen McKay , phk@freebsd.org, scsi@freebsd.org Subject: Re: filemarks? 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 > > By my reading, POSIX doesn't allow that behavior. It says (section > 6.4.2.2): > > If a write() requests that more bytes be written than there is > room for (for example, the physical end of a medium), only as > many bytes as there is room for shall be written. For example, > supppose there is space for 20 bytes more in a file before > reaching a limit. A write of 512 bytes would return 20. The > next write of a nonzero number of bytes would give a failure > return (except as noted below). > > That last sentence precludes the application from continuing writing > beyond the early warning. The "except as noted below" doesn't seem to > refer to anything relevant here. Hmmm.... Here's another try at this: A user application detects EARLY WARNING during writing by getting a return from the write(2) system call of zero (zero bytes were written). If the device open is the non-rewinding tape device, the application may close and reopen it and continue writing until physical end of medium (EOT) is reached, whereupon a value of -1 is returned from the write(2) system call and the system error is set to ENOSPC. A filemark will be written in the usual manner if EARLY WARNING is detected and the application closes the tape device at that point. It is unlikely that filemark(s) can be written after physical EOT is detected. If the user applications continues to attempt to write after EARLY WARNING notification, a value of -1 will be returned with the system error set to ENOSPC. Some tape devices may be configured such that they do not report EARLY WARNING, in which case the physical EOT notification as described above will occur first. If a user application writes to EARLY WARNING, closes and rewinds the tape device, and later reopens it and seeks to the end of recorded media and starts writing again, EARLY WARNING detection may or may not be defeated, in which case physical EOT notification will occur as described above. If the tape device is set in fixed block mode, EARLY WARNING may or may not be able to be successfully detected and signified to the user application as described above. This makes a tape more akin to a tty device that dropped DCD (:-)). At any rate, I think that POSIX semantics are adhered to in this case, but there is at least some attempt to have a signification condition other than a hard error and still allow trailer records to be written. The last paragraph also leaves wiggle room for possible future delayed buffering. Another way to do this would be to use the Solaris model, which is a little harder to implement (more tape state has to be maintained). Thoughts? -matt p.s.: and thanks for the positive discussion on this! Finally we may be able to get somewhere .... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 20 9:43:13 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 59791151FF; Mon, 20 Dec 1999 09:43:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA12513; Mon, 20 Dec 1999 09:44:28 -0800 Date: Mon, 20 Dec 1999 09:44:28 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Polstra Cc: Hauke Fath , Joerg Wunsch , "Rodney W. Grimes" , Thomas David Rivers , Bob Bishop , Greg Lehey , Stephen McKay , phk@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: filemarks? 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 Correction: > can be written after physical EOT is detected. If the user > applications continues to attempt to write after EARLY > WARNING notification, a value of -1 will be returned with > the system error set to ENOSPC. Should be: can be written after physical EOT is detected. If the user applications does not close the device and continues to attempt to write after EARLY WARNING notification, a value of -1 will be returned with the system error set to ENOSPC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 20 22:40:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id D263E153F8; Mon, 20 Dec 1999 22:40:45 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id WAA10946; Mon, 20 Dec 1999 22:39:04 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id WAA41264; Mon, 20 Dec 1999 22:39:03 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 20 Dec 1999 22:39:03 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Matthew Jacob Subject: Re: filemarks? Cc: scsi@freebsd.org, phk@freebsd.org, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , "Rodney W. Grimes" , Joerg Wunsch , Hauke Fath Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > A user application detects EARLY WARNING during writing by > getting a return from the write(2) system call of zero (zero > bytes were written). If the device open is the non-rewinding > tape device, the application may close and reopen it and > continue writing until physical end of medium I'm sorry, but this is not the Unix elegance we all know and love. You're twisting yourself into knots trying to fit a square peg into a round hole. End of media is a classic "exceptional condition" and it needs to be handled as such. It can't just be contorted into the existing API, which simply has no room for it. That's why until now there has been no standard Unix way to deal with end of media -- because it doesn't fit into the constraints of the write(2) API. I say again that the most reasonable way in Unix to handle exceptional conditions is to raise a signal. That's what signals are for. I disagree with your earlier statement that signals are hard to program. All you have to do in the signal handler is set a flag. The mainline code, when it sees the flag, will do whatever it would have done if the write() call had returned a short count under your proposal. The use of a signal for this is no different in concept than many other uses of signals. Think about SIGPIPE, SIGXFSZ, SIGXCPU, and SIGURG, for example, and you'll see that they serve the same kind of purpose. > p.s.: and thanks for the positive discussion on this! Finally we may be > able to get somewhere .... I think this discussion needs to take place on -arch or -current if it is to carry any weight. There are people who care about this stuff and who have informed opinions who aren't being included. How about moving it to -arch? John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 20 23:15:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4A22F14A1B; Mon, 20 Dec 1999 23:15:38 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA14626; Mon, 20 Dec 1999 23:17:29 -0800 Date: Mon, 20 Dec 1999 23:17:29 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Polstra Cc: scsi@freebsd.org, phk@freebsd.org, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , "Rodney W. Grimes" , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Dec 1999, John Polstra wrote: > Matthew Jacob wrote: > > > A user application detects EARLY WARNING during writing by > > getting a return from the write(2) system call of zero (zero > > bytes were written). If the device open is the non-rewinding > > tape device, the application may close and reopen it and > > continue writing until physical end of medium > > I'm sorry, but this is not the Unix elegance we all know and love. > You're twisting yourself into knots trying to fit a square peg into > a round hole. End of media is a classic "exceptional condition" and But it's not quite end of media- it's a warning that it's near. > it needs to be handled as such. It can't just be contorted into the > existing API, which simply has no room for it. That's why until now > there has been no standard Unix way to deal with end of media -- > because it doesn't fit into the constraints of the write(2) API. > > I say again that the most reasonable way in Unix to handle exceptional > conditions is to raise a signal. That's what signals are for. I > disagree with your earlier statement that signals are hard to program. > All you have to do in the signal handler is set a flag. The mainline > code, when it sees the flag, will do whatever it would have done if > the write() call had returned a short count under your proposal. I didn't mean to say it was hard to program- just that it's more stuff to add, but maybe not so bad. > The use of a signal for this is no different in concept than many > other uses of signals. Think about SIGPIPE, SIGXFSZ, SIGXCPU, and > SIGURG, for example, and you'll see that they serve the same kind of > purpose. Umm- what's your suggestion as to which one to use and is it set to SIG_IGN by default? > > > p.s.: and thanks for the positive discussion on this! Finally we may be > > able to get somewhere .... > > I think this discussion needs to take place on -arch or -current if it > is to carry any weight. There are people who care about this stuff > and who have informed opinions who aren't being included. How about > moving it to -arch? We could move it there. What I'm trying to see is if there's a consensus among the people who actually use tapes about this. This would be on the scsi alias. So far, I'd still like to hear from Greg and Rodney Grimes in particular (they were the most vehement when I raised this last time on -current). Then I'd move it to a more generic 'unix sniff test' forum again. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 20 23:29:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2AB1A14E94; Mon, 20 Dec 1999 23:29:38 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA45172; Mon, 20 Dec 1999 23:29:26 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912210729.XAA45172@gndrsh.dnsmgr.net> Subject: Re: filemarks? In-Reply-To: from John Polstra at "Dec 20, 1999 10:39:03 pm" To: jdp@polstra.com (John Polstra) Date: Mon, 20 Dec 1999 23:29:26 -0800 (PST) Cc: mjacob@feral.com (Matthew Jacob), scsi@freebsd.org, phk@freebsd.org, syssgm@detir.qld.gov.au (Stephen McKay), grog@lemis.com (Greg Lehey), rb@gid.co.uk (Bob Bishop), rivers@dignus.com (Thomas David Rivers), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hf@Melog.DE (Hauke Fath) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Matthew Jacob wrote: > > > A user application detects EARLY WARNING during writing by > > getting a return from the write(2) system call of zero (zero > > bytes were written). If the device open is the non-rewinding > > tape device, the application may close and reopen it and > > continue writing until physical end of medium > > I'm sorry, but this is not the Unix elegance we all know and love. > You're twisting yourself into knots trying to fit a square peg into > a round hole. End of media is a classic "exceptional condition" and > it needs to be handled as such. It can't just be contorted into the > existing API, which simply has no room for it. That's why until now > there has been no standard Unix way to deal with end of media -- > because it doesn't fit into the constraints of the write(2) API. The API has a perfectly acceptable and working mechanism to deal with this. RETURN VALUES Upon successful completion the number of bytes which were written is re- turned. Otherwise a -1 is returned and the global variable errno is set to indicate the error. We seem to have 3 cases when Early Warning is detected: a) The write(2) completed, all data has been written to the tape. Here by definition we should simply return nbytes, after all, nothing is wrong at this point, all the data did make it onto the tape. The driver layer should set a flag at this point noting that Early Warning has been seen but not delivered to the consumer. This flag will be delivered by c) below, since the driver layer knows not to try and put any more data on the tape. b) The write(2) was not completed, some bytes did make it to the tape. If _some_ bytes made it we should return how many did and set the Early Warning flag as in a). If no bytes made it we return 0, which is a degenerative case, no quite covered by the definition of RETURN VALUE but in wide usage. c) The write(2) was not able to put any data on the tape. Return -1, NOSPC. Whats wrong with this model? > I say again that the most reasonable way in Unix to handle exceptional > conditions is to raise a signal. That's what signals are for. I IMHO, this is _not_ an exceptional condition, but a normal condition handled by the normal system call return values. Geez lewezzz the computer industry has been dealing with magtape and EOM for 40 years this way. Most mainframe class stuff on EOM detection does a BSR WEOF REW and asks for a new volume. It seems only in the unix world we have a major problem in dealing with this simple thing. Is that because we have been missing BSR from all our tape programs? > disagree with your earlier statement that signals are hard to program. > All you have to do in the signal handler is set a flag. The mainline > code, when it sees the flag, will do whatever it would have done if > the write() call had returned a short count under your proposal. I agree that signals are not hard to handle, but they I disagree that they are the way to handle EOM. > > p.s.: and thanks for the positive discussion on this! Finally we may be > > able to get somewhere .... > > I think this discussion needs to take place on -arch or -current if it > is to carry any weight. There are people who care about this stuff > and who have informed opinions who aren't being included. How about > moving it to -arch? Agree.. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 20 23:35:12 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 8A0B11534E; Mon, 20 Dec 1999 23:35:10 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA14664; Mon, 20 Dec 1999 23:37:01 -0800 Date: Mon, 20 Dec 1999 23:37:01 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Rodney W. Grimes" Cc: John Polstra , scsi@FreeBSD.ORG, phk@FreeBSD.ORG, Stephen McKay , Greg Lehey , Bob Bishop , Thomas David Rivers , Joerg Wunsch , Hauke Fath Subject: Re: filemarks? In-Reply-To: <199912210729.XAA45172@gndrsh.dnsmgr.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 [ moving to -arch ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 20 23:39:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id EA1B3153A0; Mon, 20 Dec 1999 23:39:13 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA45202; Mon, 20 Dec 1999 23:39:04 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912210739.XAA45202@gndrsh.dnsmgr.net> Subject: Re: filemarks? In-Reply-To: from Matthew Jacob at "Dec 20, 1999 11:37:01 pm" To: mjacob@feral.com Date: Mon, 20 Dec 1999 23:39:04 -0800 (PST) Cc: jdp@polstra.com (John Polstra), scsi@FreeBSD.ORG, phk@FreeBSD.ORG, syssgm@detir.qld.gov.au (Stephen McKay), grog@lemis.com (Greg Lehey), rb@gid.co.uk (Bob Bishop), rivers@dignus.com (Thomas David Rivers), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hf@Melog.DE (Hauke Fath) 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 > > [ moving to -arch ] You may loose me on this move... and an email to majordomo to find out which lists I am on won't tell me about -arch. ARGHHH!!!! Please stuff me in the cc: header for now... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 21 1:20:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from piper.kspu.kr.ua (piper.kspu.kr.ua [195.5.1.122]) by hub.freebsd.org (Postfix) with ESMTP id 6FFF31543B for ; Tue, 21 Dec 1999 01:20:20 -0800 (PST) (envelope-from john@piper.kspu.kr.ua) Received: (from john@localhost) by piper.kspu.kr.ua (8.9.3/8.9.3) id LAA05395 for freebsd-scsi@freebsd.org; Tue, 21 Dec 1999 11:20:14 +0200 (EET) Date: Tue, 21 Dec 1999 11:20:14 +0200 From: John Savitsky To: freebsd-scsi@freebsd.org Subject: SCB 0x34 timed out in dataout phase, Again (sorry) Message-ID: <19991221112014.A5291@kspu.kr.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I saw in the list, that the same problem arises many times before, but I can't find a solution. So: I have a ASUS P2B-S motherboard with AIC-7890 U2 chipset and AIC-3860 transceiver onboard. Two HDDs: DDRS-34560 detected as SE connected to a U2 68pin connector by LVD cable with supplied terminator. One HP C1533A Storage Device connected to a Fast SCSI-II 50pin connector, terminated by a passive terminator. Dmesg follows: ======================================= FreeBSD 3.2-RELEASE #0: Tue Sep 14 11:30:46 EEST 1999 [snip] ahc0: rev 0x00 int a irq 12 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs [snip] sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 32) changing root device to wd0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) ========================================== I'm running amanda backups at night. Mostly every time, in the middle of backup, I get the following errors: -------------------------- (da0:ahc0:0:0:0): SCB 0x34 - timed out in dataout phase, SEQADDR == 0x5d (da0:ahc0:0:0:0): Other SCB Timeout (da0:ahc0:0:0:0): SCB 0x48 - timed out in dataout phase, SEQADDR == 0x5d (da0:ahc0:0:0:0): Other SCB Timeout (sa0:ahc0:0:3:0): SCB 0x49 - timed out in dataout phase, SEQADDR == 0x5d (sa0:ahc0:0:3:0): BDR message in message buffer (sa0:ahc0:0:3:0): SCB 0x49 - timed out in dataout phase, SEQADDR == 0x5c (sa0:ahc0:0:3:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 3 SCBs aborted (sa0:ahc0:0:3:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 (sa0:ahc0:0:3:0): UNIT ATTENTION asc:29,0 (sa0:ahc0:0:3:0): Power on, reset, or bus device reset occurred (sa0:ahc0:0:3:0): failed to write terminating filemark(s) (sa0:ahc0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. (sa0:ahc0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. xptioctl: pass driver is not in the kernel xptioctl: put "device pass0" in your kernel config file -------------------------- I checked cables and termination many times, but without success. May be I have to change some timeouts? Please, help me find the answer. -- Sincerely yours, John Savitsky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 21 10:13:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 68B4B1570B for ; Tue, 21 Dec 1999 10:13:14 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 120Tlo-000DBc-00; Tue, 21 Dec 1999 10:12:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Savitsky Cc: freebsd-scsi@freebsd.org Subject: Re: SCB 0x34 timed out in dataout phase, Again (sorry) References: <19991221112014.A5291@kspu.kr.ua> Message-Id: Date: Tue, 21 Dec 1999 10:12:24 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > FreeBSD 3.2-RELEASE #0: Tue Sep 14 11:30:46 EEST 1999 > > ahc0: rev 0x00 int a irq 12 on pci0.6.0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > sa0 at ahc0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > changing root device to wd0s1a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) > ========================================== > > I'm running amanda backups at night. Mostly every time, in the middle > of backup, I get the following errors: > -------------------------- > (da0:ahc0:0:0:0): SCB 0x34 - timed out in dataout phase, SEQADDR == 0x5d > (da0:ahc0:0:0:0): Other SCB Timeout > (da0:ahc0:0:0:0): SCB 0x48 - timed out in dataout phase, SEQADDR == 0x5d > (da0:ahc0:0:0:0): Other SCB Timeout > (sa0:ahc0:0:3:0): SCB 0x49 - timed out in dataout phase, SEQADDR == 0x5d > (sa0:ahc0:0:3:0): BDR message in message buffer > (sa0:ahc0:0:3:0): SCB 0x49 - timed out in dataout phase, SEQADDR == 0x5c > (sa0:ahc0:0:3:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 3 SCBs aborted > (sa0:ahc0:0:3:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 > (sa0:ahc0:0:3:0): UNIT ATTENTION asc:29,0 > (sa0:ahc0:0:3:0): Power on, reset, or bus device reset occurred > (sa0:ahc0:0:3:0): failed to write terminating filemark(s) > (sa0:ahc0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. > (sa0:ahc0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. > xptioctl: pass driver is not in the kernel > xptioctl: put "device pass0" in your kernel config file oh oh. i have ASUS P2B-DS 3.3-STABLE of 991122 DEC/Quantum DLT2000 sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: cd present [140956 x 2048 byte records] from which i can restore but not dump. somewhere in the dump, i get (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 (sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Unexpected busfree. LASTPHASE == 0x0 SEQADDR == 0x5e (sa0:ahc0:0:6:0): Cam Status 0x13 (sa0:ahc0:0:6:0): error 5 resid 10240 count 10240 i put in an expensive terminated custom scsi cable. i upgraded asus and dlt flash. i sprinkled eye of newt. now it is in for rma. when it comes back, if the problem persists, i am gonna be very confused. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 24 0:43:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns1.aha.ru (ns1.aha.ru [195.2.80.142]) by hub.freebsd.org (Postfix) with ESMTP id 2F4C414FE6 for ; Fri, 24 Dec 1999 00:43:09 -0800 (PST) (envelope-from abb@zenon.net) Received: from pb.hq.zenon.net (pb.zenon.net [195.2.64.18]) by ns1.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id LAA07847 for ; Fri, 24 Dec 1999 11:42:26 +0300 (MSK) Received: from zenon.net (abb.hq.zenon.net [192.168.9.25]) by pb.hq.zenon.net (8.9.3/8.9.3) with ESMTP id LAA87222 for ; Fri, 24 Dec 1999 11:42:25 +0300 (MSK) Message-ID: <38633232.261EE905@zenon.net> Date: Fri, 24 Dec 1999 11:43:30 +0300 From: Alexander Bezroutchko X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: scsi@freebsd.org Subject: IFT3102 and FreeBSD 3.4-STABLE troubles Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I have following configuration: * two IFT-3102U2G controllers are configured in redundant mode (caches get syncronized via channel 0), firmware revision 2.23 * channel 1 is disk channel, it serves three Ultra2 drives * channels 2,3 are host channels * two hosts (2 x PIII Xeon-550, RAM 512M, C440GX+, no disk), FreeBSD 3.4-STABLE * host1's ultra2 port is connected to channel2 * host2's ultra2 port is connected to channel3 When I pull away primary controller, processes which use disk hangs. After ~4 sec secondary controller become primary. Sometimes hung processes get running immediatery. But sometimes unhangs only after 60 sec. Also after controller reset (it takes 1-2 minute) some directories became empty, another ones unreadable -- read operation returns 'Device not configured'. The questions are: 1. Is it FreeBSD's or IFT's bug ? 2. Does anybody know solution/workaround ? 3. 'Disconnection' enabled on RAIDcontroller and on-board scsi controller on hosts, is it correct ? 4. Does anybody have expirience maintaining servers without local disk (external only) ? Are there any troubles ? Any help would be greatly appreciated. SY, Alexander Bezroutchko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 24 15:10:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 6F88C14F57 for ; Fri, 24 Dec 1999 15:10:23 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 121dqc-0000BS-00; Fri, 24 Dec 1999 15:10:10 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Savitsky Cc: freebsd-scsi@freebsd.org Subject: Re: SCB 0x34 timed out in dataout phase, Again (sorry) References: <19991221112014.A5291@kspu.kr.ua> Message-Id: Date: Fri, 24 Dec 1999 15:10:10 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > FreeBSD 3.2-RELEASE #0: Tue Sep 14 11:30:46 EEST 1999 > > [snip] > > ahc0: rev 0x00 int a irq 12 on pci0.6.0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > [snip] > > sa0 at ahc0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > changing root device to wd0s1a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) > ========================================== > > I'm running amanda backups at night. Mostly every time, in the middle > of backup, I get the following errors: > -------------------------- > (da0:ahc0:0:0:0): SCB 0x34 - timed out in dataout phase, SEQADDR == 0x5d > (da0:ahc0:0:0:0): Other SCB Timeout > (da0:ahc0:0:0:0): SCB 0x48 - timed out in dataout phase, SEQADDR == 0x5d > (da0:ahc0:0:0:0): Other SCB Timeout > (sa0:ahc0:0:3:0): SCB 0x49 - timed out in dataout phase, SEQADDR == 0x5d > (sa0:ahc0:0:3:0): BDR message in message buffer > (sa0:ahc0:0:3:0): SCB 0x49 - timed out in dataout phase, SEQADDR == 0x5c > (sa0:ahc0:0:3:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 3 SCBs aborted > (sa0:ahc0:0:3:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 > (sa0:ahc0:0:3:0): UNIT ATTENTION asc:29,0 > (sa0:ahc0:0:3:0): Power on, reset, or bus device reset occurred > (sa0:ahc0:0:3:0): failed to write terminating filemark(s) > (sa0:ahc0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. > (sa0:ahc0:0:3:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. > xptioctl: pass driver is not in the kernel > xptioctl: put "device pass0" in your kernel config file > -------------------------- asus p2bds 3.4-stable quantum dlt-2000 similar problem o replaced scsi cable with fancy terminated one o upgraded motherboard firmware o upgraded drive firmware o sent drive in for rma o problem persists (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 (sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Unexpected busfree. LASTPHASE == 0x0 SEQADDR == 0x5e (sa0:ahc0:0:6:0): Cam Status 0x13 (sa0:ahc0:0:6:0): error 5 resid 10240 count 10240 this worked with -current, but stopped working when i reverted to 3.x i now start to suspect the driver. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 24 18: 5: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 9C8BC158F5 for ; Fri, 24 Dec 1999 18:05:05 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 121f2q-0004uC-00; Fri, 24 Dec 1999 16:26:52 -0800 Date: Fri, 24 Dec 1999 16:26:51 -0800 (PST) From: Tom To: Alexander Bezroutchko Cc: scsi@freebsd.org Subject: Re: IFT3102 and FreeBSD 3.4-STABLE troubles In-Reply-To: <38633232.261EE905@zenon.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 On Fri, 24 Dec 1999, Alexander Bezroutchko wrote: > Hello, > > I have following configuration: > * two IFT-3102U2G controllers are configured in redundant mode > (caches get syncronized via channel 0), firmware revision 2.23 > * channel 1 is disk channel, it serves three Ultra2 drives > * channels 2,3 are host channels > > * two hosts (2 x PIII Xeon-550, RAM 512M, C440GX+, no disk), > FreeBSD 3.4-STABLE > * host1's ultra2 port is connected to channel2 > * host2's ultra2 port is connected to channel3 > > When I pull away primary controller, processes which use disk > hangs. After ~4 sec secondary controller become primary. > Sometimes hung processes get running immediatery. But sometimes > unhangs only after 60 sec. > > Also after controller reset (it takes 1-2 minute) some > directories became empty, another ones unreadable -- read > operation returns 'Device not configured'. The questions are: > > 1. Is it FreeBSD's or IFT's bug ? > > 2. Does anybody know solution/workaround ? > > 3. 'Disconnection' enabled on RAIDcontroller and on-board scsi > controller on hosts, is it correct ? > > 4. Does anybody have expirience maintaining servers without > local disk (external only) ? Are there any troubles ? > > Any help would be greatly appreciated. > > SY, Alexander Bezroutchko Well, I'm testing a single IFT-3102U2G on a dual-PIII under 3.4 stable. I'm assuming that the take-over by the redundant controller is similar in appearance to the host, as resetting a controller. I've done a few resets of the IFT controller until full load (three instances of postmark). FreeBSD paused, then printed a bunch of errors and then continued. I have had a incident where FreeBSD just hung after resetting the controller. I couldn't reproduce it though. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Dec 25 6:42: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from piper.kspu.kr.ua (piper.kspu.kr.ua [195.5.1.122]) by hub.freebsd.org (Postfix) with ESMTP id 91E3614E81 for ; Sat, 25 Dec 1999 06:41:55 -0800 (PST) (envelope-from john@piper.kspu.kr.ua) Received: (from john@localhost) by piper.kspu.kr.ua (8.9.3/8.9.3) id QAA24526 for freebsd-scsi@FreeBSD.ORG; Sat, 25 Dec 1999 16:41:51 +0200 (EET) Date: Sat, 25 Dec 1999 16:41:51 +0200 From: John Savitsky To: freebsd-scsi@FreeBSD.ORG Subject: Re: SCB 0x34 timed out in dataout phase, Again (sorry) Message-ID: <19991225164151.A24504@kspu.kr.ua> Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <19991221112014.A5291@kspu.kr.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from randy@psg.com on Fri, Dec 24, 1999 at 03:10:10PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Dec 24, 1999 at 03:10:10PM -0800, Randy Bush wrote: > > asus p2bds > 3.4-stable > quantum dlt-2000 > > similar problem > o replaced scsi cable with fancy terminated one > o upgraded motherboard firmware > o upgraded drive firmware > o sent drive in for rma > o problem persists > > this worked with -current, but stopped working when i reverted to 3.x > > i now start to suspect the driver. > > randy Sorry for delayed answer. I make some experiments to moving my backups to different time, but with no success. I thought that problems might be of intensive HDD operations caused by `periodic daily'. As you see in my previous posting, our hardware suppliers connected IBM DDRS-34560 detected by Adaptec controller as -SE devices to the Ultra 2 socket. I suppose that this socket has LVD electric signals in difference to the Wide SCSI connector? Is this correct? Might it be the problem? May be I have to connect my HDDs to the Wide SCSI connector using SE cable? -- Sincerely yours, John Savitsky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message