From owner-freebsd-scsi Sun Jun 27 0: 6:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from control.colossus.dynip.com (226-193.adsl2.avtel.net [207.71.226.193]) by hub.freebsd.org (Postfix) with ESMTP id 4FD7E14ED4; Sun, 27 Jun 1999 00:06:37 -0700 (PDT) (envelope-from dburr@control.colossus.dynip.com) Received: (from dburr@localhost) by control.colossus.dynip.com (8.9.3/8.9.2) id AAA12725; Sun, 27 Jun 1999 00:06:36 -0700 (PDT) (envelope-from dburr) 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 Date: Sun, 27 Jun 1999 00:06:35 -0700 (PDT) Organization: Computer Help From: Donald Burr To: FreeBSD Questions , FreeBSD SCSI Subject: Need help choosing a new SCSI card Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It was bound to happen. After getting a new (external) tape drive and hooking it up to my system, I now find that my SCSI chain is too long to work reliably. With my external devices, I get parity errors and all sorts of unstable performance from my (internal) SCSI hard drives. Almost lost a filesystem because of that. But with my external devices unplugged (leaving only the internal hard drives), everything works perfectly. So it looks like it's time to get me a new SCSI card -- one with multiple buses on the same card (so that the internal and external connectors are both on separate buses). Normally, I would buy a second SCSI card, and put only external devices on it (especially since NCR/Symbios cards are so cheap nowadays), but unfortunately I am also out of PCI slots. So I need a single PCI SCSI card that has multiple buses on the card. So I need some help from the FreeBSD SCSI community in choosing a new card! Here are my requirements: * IMPORTANT!! Separate SCSI buses for internal and external connector. My SCSI chain is too long to have both internal and external be on the same bus. * BIOS on the card. My SCSI disks are my boot devices, so I need an on-card BIOS. MY MOTHERBOARD DOES *NOT* HAVE AN NCR BIOS BUILT IN TO IT (I checked). * Narrow Ultra SCSI support (50-pin, 20MB/s) preferred. All of my devices are narrow, either Fast (10M/sec) or Ultra (20M/sec). I really would rather not have to upgrade to Wide or U2W drives. * FreeBSD compatibility, of course! (I run 3.2-STABLE) But it would be great if the card works under Linux as well, since I have to do projects in Linux now and then. * Reasonable cost. I unfortunately don't have a lot of money to spend. (I might be able to find something used on EBay or some other auction site, though I would rather buy new, of course.) Are there any NCR/Symbios cards that fit the bill? I really like this chipset and it is a heck of a lot cheaper than Adaptec... In addition, if someone can point me to a good mail order (or Web order) place where I can get this card, I would be very grateful. Please reply to me in e-mail &/or to the FreeBSD SCSI list. Thanks! --- Donald Burr -Member The FreeBSD Project| PGP: Your *NEW* WWW HomePage: http://more.at/dburr/ ICQ #16997506 | right to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 27 0:51:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (unknown [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id BF92D14E57; Sun, 27 Jun 1999 00:51:09 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id BAA09536; Sun, 27 Jun 1999 01:50:59 -0600 (MDT) (envelope-from ken) Message-Id: <199906270750.BAA09536@panzer.kdm.org> Subject: Re: Need help choosing a new SCSI card In-Reply-To: from Donald Burr at "Jun 27, 1999 00:06:35 am" To: dburr@pobox.com (Donald Burr) Date: Sun, 27 Jun 1999 01:50:59 -0600 (MDT) Cc: freebsd-questions@FreeBSD.ORG (FreeBSD Questions), freebsd-scsi@FreeBSD.ORG (FreeBSD SCSI) 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 Donald Burr wrote... > It was bound to happen. After getting a new (external) tape drive and > hooking it up to my system, I now find that my SCSI chain is too long > to work reliably. With my external devices, I get parity errors and all > sorts of unstable performance from my (internal) SCSI hard drives. > Almost lost a filesystem because of that. But with my external devices > unplugged (leaving only the internal hard drives), everything works > perfectly. > > So it looks like it's time to get me a new SCSI card -- one with multiple > buses on the same card (so that the internal and external connectors are > both on separate buses). Normally, I would buy a second SCSI card, and > put only external devices on it (especially since NCR/Symbios cards are > so cheap nowadays), but unfortunately I am also out of PCI slots. So I > need a single PCI SCSI card that has multiple buses on the card. > > So I need some help from the FreeBSD SCSI community in choosing a new > card! Here are my requirements: > > * IMPORTANT!! Separate SCSI buses for internal and external connector. > My SCSI chain is too long to have both internal and external be on the > same bus. > * BIOS on the card. My SCSI disks are my boot devices, so I need an > on-card BIOS. MY MOTHERBOARD DOES *NOT* HAVE AN NCR BIOS BUILT IN TO IT > (I checked). > * Narrow Ultra SCSI support (50-pin, 20MB/s) preferred. All of my devices > are narrow, either Fast (10M/sec) or Ultra (20M/sec). I really > would rather not have to upgrade to Wide or U2W drives. > * FreeBSD compatibility, of course! (I run 3.2-STABLE) But it would be > great if the card works under Linux as well, since I have to do projects > in Linux now and then. > * Reasonable cost. I unfortunately don't have a lot of money to spend. > (I might be able to find something used on EBay or some other auction > site, though I would rather buy new, of course.) > > Are there any NCR/Symbios cards that fit the bill? I really like this > chipset and it is a heck of a lot cheaper than Adaptec... > > In addition, if someone can point me to a good mail order (or Web order) > place where I can get this card, I would be very grateful. Well, you could get a Symbios 876 (Ultra) or 896 (Ultra2) based board. No, I don't know where you can get one. You could probably also get an Advansys 3950. NECX (www.necx.com) has them for $230. Don't buy one without talking to Justin, though. Advansys has changed their model numbers around, and I'm not positive the 3950 is supported. And it's only an Ultra board, it can't do Ultra2. You could also get a Qlogic 1240 board. It's dual-channel Ultra. I dunno where to get one, though. Qlogic boards seem to be hard to find, unless you've got SGI boxes. (Their Origin 200's come with Qlogic chips and boards nowadays.) They have a 1280 (Ultra2) dual channel chip as well, but I can't tell whether it's supported by the isp driver. You could also settle for an Adaptec 3940AUW or 3950U2. Both of them work just fine, but as you pointed out, they're expensive. Sometimes, though, it pays to get good hardware. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 27 0:54: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from c523578-a.sttls1.wa.home.com (c523578-a.sttls1.wa.home.com [24.5.122.51]) by hub.freebsd.org (Postfix) with ESMTP id 639D814E57; Sun, 27 Jun 1999 00:54:00 -0700 (PDT) (envelope-from todd@c523578-a.sttls1.wa.home.com) Received: from localhost (todd@localhost) by c523578-a.sttls1.wa.home.com (8.9.3/8.9.2) with ESMTP id BAA22598; Sun, 27 Jun 1999 01:01:11 -0700 (PDT) (envelope-from todd@c523578-a.sttls1.wa.home.com) Date: Sun, 27 Jun 1999 01:01:11 -0700 (PDT) From: Todd Backman To: Donald Burr Cc: FreeBSD Questions , FreeBSD SCSI Subject: Re: Need help choosing a new SCSI card 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 Try the: ADAPTEC AHA-3940UW PCI Dual Channel Wide Ultra-SCSI Controller They are now running at $159 on Onsale... http://www.onsale.com/category/inv/00049180/01828814.htm On Sun, 27 Jun 1999, Donald Burr wrote: > It was bound to happen. After getting a new (external) tape drive and > hooking it up to my system, I now find that my SCSI chain is too long > to work reliably. With my external devices, I get parity errors and all > sorts of unstable performance from my (internal) SCSI hard drives. > Almost lost a filesystem because of that. But with my external devices > unplugged (leaving only the internal hard drives), everything works > perfectly. > > So it looks like it's time to get me a new SCSI card -- one with multiple > buses on the same card (so that the internal and external connectors are > both on separate buses). Normally, I would buy a second SCSI card, and > put only external devices on it (especially since NCR/Symbios cards are > so cheap nowadays), but unfortunately I am also out of PCI slots. So I > need a single PCI SCSI card that has multiple buses on the card. > > So I need some help from the FreeBSD SCSI community in choosing a new > card! Here are my requirements: > > * IMPORTANT!! Separate SCSI buses for internal and external connector. > My SCSI chain is too long to have both internal and external be on the > same bus. > * BIOS on the card. My SCSI disks are my boot devices, so I need an > on-card BIOS. MY MOTHERBOARD DOES *NOT* HAVE AN NCR BIOS BUILT IN TO IT > (I checked). > * Narrow Ultra SCSI support (50-pin, 20MB/s) preferred. All of my devices > are narrow, either Fast (10M/sec) or Ultra (20M/sec). I really > would rather not have to upgrade to Wide or U2W drives. > * FreeBSD compatibility, of course! (I run 3.2-STABLE) But it would be > great if the card works under Linux as well, since I have to do projects > in Linux now and then. > * Reasonable cost. I unfortunately don't have a lot of money to spend. > (I might be able to find something used on EBay or some other auction > site, though I would rather buy new, of course.) > > Are there any NCR/Symbios cards that fit the bill? I really like this > chipset and it is a heck of a lot cheaper than Adaptec... > > In addition, if someone can point me to a good mail order (or Web order) > place where I can get this card, I would be very grateful. > > Please reply to me in e-mail &/or to the FreeBSD SCSI list. Thanks! > --- > Donald Burr -Member The FreeBSD Project| PGP: Your > *NEW* WWW HomePage: http://more.at/dburr/ ICQ #16997506 | right to > Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. > Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 Jun 27 3:35:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sand4.global.net.uk (sand4.global.net.uk [194.126.80.248]) by hub.freebsd.org (Postfix) with ESMTP id A78A414CA3; Sun, 27 Jun 1999 03:35:20 -0700 (PDT) (envelope-from marko@globalnet.co.uk) Received: from p21s10a06.client.global.net.uk ([195.147.218.34] helo=marder-1.) by sand4.global.net.uk with esmtp (Exim 2.12 #1) id 10yCHP-00019R-00; Sun, 27 Jun 1999 11:35:19 +0100 Received: (from marko@localhost) by marder-1. (8.9.2/8.8.8) id LAA00327; Sun, 27 Jun 1999 11:31:38 +0100 (BST) (envelope-from marko) Date: Sun, 27 Jun 1999 11:31:36 +0100 From: Mark Ovens To: Donald Burr Cc: FreeBSD Questions , FreeBSD SCSI Subject: Re: Need help choosing a new SCSI card Message-ID: <19990627113136.A254@marder-1> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Donald Burr on Sun, Jun 27, 1999 at 12:06:35AM -0700 Organization: Total lack of Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 27, 1999 at 12:06:35AM -0700, Donald Burr wrote: > [snip] > Are there any NCR/Symbios cards that fit the bill? I really like this > chipset and it is a heck of a lot cheaper than Adaptec... > Diamond do a dual channel Fireport. I use the single channel version and it works just fine with FreeBSD (Symbios 875 chip), and they're about half the price of Adaptec cards (in the UK anyway). > In addition, if someone can point me to a good mail order (or Web order) > place where I can get this card, I would be very grateful. > > Please reply to me in e-mail &/or to the FreeBSD SCSI list. Thanks! > --- > Donald Burr -Member The FreeBSD Project| PGP: Your > *NEW* WWW HomePage: http://more.at/dburr/ ICQ #16997506 | right to > Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. > Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > -- FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://www.users.globalnet.co.uk/~markov _______________________________________________________________ Mark Ovens, CNC Apps Engineer, Radan Computational Ltd. Bath UK CAD/CAM solutions for Sheetmetal Working Industry mailto:markov@globalnet.co.uk http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 27 8:44:56 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 9BB1B14C2B; Sun, 27 Jun 1999 08:44:50 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id RAA08741; Sun, 27 Jun 1999 17:39:54 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id PAA00557; Sun, 27 Jun 1999 15:30:46 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199906271330.PAA00557@yedi.iaf.nl> Subject: Re: Need help choosing a new SCSI card In-Reply-To: <19990627113136.A254@marder-1> from Mark Ovens at "Jun 27, 1999 11:31:36 am" To: markov@globalnet.co.uk (Mark Ovens) Date: Sun, 27 Jun 1999 15:30:46 +0200 (CEST) Cc: dburr@pobox.com, freebsd-questions@FreeBSD.ORG, 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 Mark Ovens wrote ... > On Sun, Jun 27, 1999 at 12:06:35AM -0700, Donald Burr wrote: > > > > [snip] > > > Are there any NCR/Symbios cards that fit the bill? I really like this > > chipset and it is a heck of a lot cheaper than Adaptec... > > > > Diamond do a dual channel Fireport. I use the single channel version ^--- did. They gave up on SCSI adapters it seems. > and it works just fine with FreeBSD (Symbios 875 chip), and they're > about half the price of Adaptec cards (in the UK anyway). FWIW I have a single channel FP40 which works just dandy. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 27 13:46:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from george.lbl.gov (george.lbl.gov [131.243.2.12]) by hub.freebsd.org (Postfix) with ESMTP id 5A19E14CC8; Sun, 27 Jun 1999 13:46:40 -0700 (PDT) (envelope-from jin@george.lbl.gov) Received: (from jin@localhost) by george.lbl.gov (8.9.3/8.9.2) id NAA23478; Sun, 27 Jun 1999 13:46:37 -0700 (PDT) Date: Sun, 27 Jun 1999 13:46:37 -0700 (PDT) Message-Id: <199906272046.NAA23478@george.lbl.gov> From: jin@george.lbl.gov To: dburr@pobox.com, freebsd-hardware@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Need help choosing a new SCSI card Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > * IMPORTANT!! Separate SCSI buses for internal and external connector. > My SCSI chain is too long to have both internal and external be on the > same bus. It is not clear what you want to have here. (1) Four buses, two for internal and two for external or (2) Two buses, one for internal and one for external None of above is possible or (3) Two buses, both for internal and external with two external connectors and two internal connectors (4) Two buses, both for internal and external with one external connectors and two internal connectors #(3) is available on RAID controller #(4) is available at Diamond Fireport 40 DUAL. This one actually has one external SCSI-2 connector on channel one, and four internal connectors on both channels. Four internal connectors: Two are SCSI-3 connectors for each channel, and the other twos are SCSI-2 connectors for each channel. > * Narrow Ultra SCSI support (50-pin, 20MB/s). I don't have any Wide or > Ultra2/U2W/etc. devices, nor do I plan on getting any. > * FreeBSD compatibility, of course! But it would be great if the card > works under Linux as well, since I have to do projects in Linux now and > then. > * Reasonable cost. I unfortunately don't have a lot of money to spend. > > Are there any NCR/Symbios cards that fit the bill? I really like this > chipset and it is a heck of a lot cheaper than Adaptec... Diamond Fireport 40 DUAL has NCR/Symbios 876 chip. It works under FreeBSD very well. -Jin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 27 14:32:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sand.global.net.uk (sand.global.net.uk [194.126.82.9]) by hub.freebsd.org (Postfix) with ESMTP id E73E814CE5; Sun, 27 Jun 1999 14:32:31 -0700 (PDT) (envelope-from marko@globalnet.co.uk) Received: from p12s01a06.client.global.net.uk ([195.147.209.19] helo=marder-1.) by sand.global.net.uk with esmtp (Exim 2.05 #1) id 10yMXN-0005Bl-00; Sun, 27 Jun 1999 22:32:29 +0100 Received: (from marko@localhost) by marder-1. (8.9.2/8.8.8) id WAA00294; Sun, 27 Jun 1999 22:28:46 +0100 (BST) (envelope-from marko) Date: Sun, 27 Jun 1999 22:28:45 +0100 From: Mark Ovens To: Wilko Bulte Cc: dburr@pobox.com, freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Need help choosing a new SCSI card Message-ID: <19990627222845.A252@marder-1> References: <19990627113136.A254@marder-1> <199906271330.PAA00557@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199906271330.PAA00557@yedi.iaf.nl>; from Wilko Bulte on Sun, Jun 27, 1999 at 03:30:46PM +0200 Organization: Total lack of Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 27, 1999 at 03:30:46PM +0200, Wilko Bulte wrote: > As Mark Ovens wrote ... > > On Sun, Jun 27, 1999 at 12:06:35AM -0700, Donald Burr wrote: > > > > > > > [snip] > > > > > Are there any NCR/Symbios cards that fit the bill? I really like this > > > chipset and it is a heck of a lot cheaper than Adaptec... > > > > > > > Diamond do a dual channel Fireport. I use the single channel version > > ^--- did. They gave up on SCSI adapters it seems. Really? They're still advertising them at http://www.diamondmm.com/products/buyers_guide.html#SI > > > and it works just fine with FreeBSD (Symbios 875 chip), and they're > > about half the price of Adaptec cards (in the UK anyway). > > FWIW I have a single channel FP40 which works just dandy. > That's what I use. Good card, except it screws up my floppy drive (can boot from a floppy but if I then put another floppy in it stops working - never happened before the FP40 was installed). > -- > | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - > |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org > -- FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://www.users.globalnet.co.uk/~markov _______________________________________________________________ Mark Ovens, CNC Apps Engineer, Radan Computational Ltd. Bath UK CAD/CAM solutions for Sheetmetal Working Industry mailto:markov@globalnet.co.uk http://www.radan.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 27 23:14:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id EF77B14E65; Sun, 27 Jun 1999 23:14:41 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA09599; Mon, 28 Jun 1999 08:06:54 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id AAA96092; Mon, 28 Jun 1999 00:13:52 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199906272213.AAA96092@yedi.iaf.nl> Subject: Re: Need help choosing a new SCSI card In-Reply-To: <19990627222845.A252@marder-1> from Mark Ovens at "Jun 27, 1999 10:28:45 pm" To: markov@globalnet.co.uk (Mark Ovens) Date: Mon, 28 Jun 1999 00:13:52 +0200 (CEST) Cc: dburr@pobox.com, freebsd-questions@FreeBSD.ORG, 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 Mark Ovens wrote ... > On Sun, Jun 27, 1999 at 03:30:46PM +0200, Wilko Bulte wrote: > > As Mark Ovens wrote ... > > > On Sun, Jun 27, 1999 at 12:06:35AM -0700, Donald Burr wrote: > > > > > > [snip] > > > > > > > Are there any NCR/Symbios cards that fit the bill? I really like this > > > > chipset and it is a heck of a lot cheaper than Adaptec... > > > > > > > > > > Diamond do a dual channel Fireport. I use the single channel version > > > > ^--- did. They gave up on SCSI adapters it seems. > > Really? They're still advertising them at > http://www.diamondmm.com/products/buyers_guide.html#SI Interesting, some weeks ago they were selling the last ones of thru their online shop. Maybe Diamond reversed their decision?? > > > > FWIW I have a single channel FP40 which works just dandy. > > > > That's what I use. Good card, except it screws up my floppy drive > (can boot from a floppy but if I then put another floppy in it > stops working - never happened before the FP40 was installed). Never had any problems like that. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 28 2:16:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by hub.freebsd.org (Postfix) with ESMTP id 43AFB15233; Mon, 28 Jun 1999 02:16:18 -0700 (PDT) (envelope-from ngr@symbionics.co.uk) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id CAA17726; Mon, 28 Jun 1999 02:16:18 -0700 (PDT) Received: from symnt3.Cadence.COM(194.32.101.100) by mailgate.cadence.com via smap (mjr-v1.2) id xma930561375.017707; Mon, 28 Jun 99 02:16:15 -0700 Received: by symnt3.cadence.com with Internet Mail Service (5.5.2232.9) id ; Mon, 28 Jun 1999 10:15:27 +0100 Message-ID: <1E485299309FD211A2100090271E27A41430AA@symnt3.cadence.com> From: Nigel Roles To: FreeBSD SCSI , FreeBSD Hardware Subject: RE: Need help choosing a new SCSI card Date: Mon, 28 Jun 1999 10:15:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Symbios do an 896 based card called a Symbios 22910. These you may need to buy via LSI Logic, which I agree is not good. This is a 64 bit card, so check that the motherboard you have has proper 32 bit sockets. Mine didn't so I had to 'trim' the end with a soldering iron to get the card in. This card has dual internal and external connectors, all wide, i.e. no 50 way narrow connector. I use a converter on the card to attach a 50 way cable. The converter needss no terminator for the wide portion since it is so close to the chip. If you can get Adaptec for $159 then this is not cheaper! I would have thought that getting 2 Tekram DC390U2Ws would be a better bet since they come with loads of cables and connectors and auto switching terminators, i.e. you can mix LVDS and Ultra on a cable and get the best from both. Intraserver also do an 896 card but I have no experience of it. AMI do a motherboard (MegarumII) with the 896 on board. -----Original Message----- From: Donald Burr [mailto:dburr@pobox.com] Sent: Saturday, June 26, 1999 3:23 AM To: FreeBSD SCSI; FreeBSD Hardware Subject: Need help choosing a new SCSI card It was bound to happen. After getting a new (external) tape drive and hooking it up to my system, I now find that my SCSI chain is too long to work reliably. If I unplug all my external devices (thus leaving only the internal hard drives), everything works fine. So it's time to get me a new SCSI card -- one with multiple buses on the same card. Normally, I would buy a second SCSI card, but unfortunately I am also out of PCI slots. So I need some help from the FreeBSD SCSI community in choosing a new card! Here are my requirements: * IMPORTANT!! Separate SCSI buses for internal and external connector. My SCSI chain is too long to have both internal and external be on the same bus. * Narrow Ultra SCSI support (50-pin, 20MB/s). I don't have any Wide or Ultra2/U2W/etc. devices, nor do I plan on getting any. * FreeBSD compatibility, of course! But it would be great if the card works under Linux as well, since I have to do projects in Linux now and then. * Reasonable cost. I unfortunately don't have a lot of money to spend. Are there any NCR/Symbios cards that fit the bill? I really like this chipset and it is a heck of a lot cheaper than Adaptec... In addition, if someone can point me to a good mail order (or Web order) place where I can get this card, I would be very grateful. Thanks! --- Donald Burr -Member The FreeBSD Project| PGP: Your *NEW* WWW HomePage: http://more.at/dburr/ ICQ #16997506 | right to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 28 10:56:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pinochet.cityline.ru (pinochet.cityline.ru [195.46.160.34]) by hub.freebsd.org (Postfix) with ESMTP id CDEB9153A3 for ; Mon, 28 Jun 1999 10:56:01 -0700 (PDT) (envelope-from alfapri@cityline.ru) Received: from cityline.ru (ppp05-2-25.cityline.ru [195.46.162.25]) by pinochet.cityline.ru (8.9.2/t/08-Oct-1998) with ESMTP id VAA06820 for ; Mon, 28 Jun 1999 21:54:06 +0400 (MSD) Message-ID: <3777B7AC.3C97657C@cityline.ru> Date: Mon, 28 Jun 1999 21:58:04 +0400 From: Alexey Ryndin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-RELEASE i386) MIME-Version: 1.0 To: scsi@freebsd.org Subject: unsubscribe Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe freebsd-scsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 28 17:58:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ezln23.earthbroadcasting.com (ezln23.thedial.com [207.135.131.130]) by hub.freebsd.org (Postfix) with ESMTP id 0CA5B14D9C for ; Mon, 28 Jun 1999 17:58:12 -0700 (PDT) (envelope-from chris@thedial.com) Received: from thedial.com (localhost.earthbroadcasting.com [127.0.0.1]) by ezln23.earthbroadcasting.com (8.9.3/8.9.3) with ESMTP id IAA02088 for ; Tue, 29 Jun 1999 08:58:57 -0600 (MDT) (envelope-from chris@thedial.com) Message-ID: <3778DF30.614476ED@thedial.com> Date: Tue, 29 Jun 1999 08:58:57 -0600 From: Christopher Taylor X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: fsck and dirty file systems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have noticed that FreeBSD 3.2 always gives the following when fsck is run ***** FILE SYSTEM STILL DIRTY ***** ***** PLEASE RERUN FSCK ***** I have tested several fresh 3.2 installs and they all give this message, even after I run fsck multiple times. Any ideas? --Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 28 18: 2: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from tasam.com (tasam.com [206.161.83.22]) by hub.freebsd.org (Postfix) with ESMTP id E92FF14E29 for ; Mon, 28 Jun 1999 18:01:59 -0700 (PDT) (envelope-from freebsd.list@bug.tasam.com) Received: from bug (209-122-196-250.s250.tnt5.lnh.md.dialup.rcn.com [209.122.196.250]) by tasam.com (8.9.3/8.9.1) with SMTP id VAA19280; Mon, 28 Jun 1999 21:01:55 -0400 (EDT) Message-ID: <003101bec1ca$fa9b7840$0286860a@tasam.com> From: "Joe Gleason" To: "Christopher Taylor" , References: <3778DF30.614476ED@thedial.com> Subject: Re: fsck and dirty file systems Date: Mon, 28 Jun 1999 21:01:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Is the file system mounted or unmounted when you run fsck? If it is mounted, then that should explain why this is happening. Joe Gleason Tasam > I have noticed that FreeBSD 3.2 always gives the following when fsck is > run > > ***** FILE SYSTEM STILL DIRTY ***** > > ***** PLEASE RERUN FSCK ***** > > I have tested several fresh 3.2 installs and they all give this message, > even after I run fsck multiple times. > > Any ideas? > > --Chris > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 28 18:16:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ezln23.earthbroadcasting.com (ezln23.thedial.com [207.135.131.130]) by hub.freebsd.org (Postfix) with ESMTP id CC37514ED1 for ; Mon, 28 Jun 1999 18:16:12 -0700 (PDT) (envelope-from chris@thedial.com) Received: from thedial.com (localhost.earthbroadcasting.com [127.0.0.1]) by ezln23.earthbroadcasting.com (8.9.3/8.9.3) with ESMTP id JAA02119; Tue, 29 Jun 1999 09:16:54 -0600 (MDT) (envelope-from chris@thedial.com) Message-ID: <3778E366.54EBF7C9@thedial.com> Date: Tue, 29 Jun 1999 09:16:54 -0600 From: Christopher Taylor X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Joe Gleason Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: fsck and dirty file systems References: <3778DF30.614476ED@thedial.com> <003101bec1ca$fa9b7840$0286860a@tasam.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joe Gleason wrote: > Is the file system mounted or unmounted when you run fsck? > > If it is mounted, then that should explain why this is happening. > > > I have noticed that FreeBSD 3.2 always gives the following when fsck is > > run > > > > ***** FILE SYSTEM STILL DIRTY ***** > > > > ***** PLEASE RERUN FSCK ***** > > > > I have tested several fresh 3.2 installs and they all give this message, > > even after I run fsck multiple times. The files systems this is happening on have all been mounted....I guess that explains it...would you venture an explaination? ;) --Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 28 19:23: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ezln23.earthbroadcasting.com (ezln23.thedial.com [207.135.131.130]) by hub.freebsd.org (Postfix) with ESMTP id 3E53014C23 for ; Mon, 28 Jun 1999 19:22:53 -0700 (PDT) (envelope-from chris@thedial.com) Received: from thedial.com (localhost.earthbroadcasting.com [127.0.0.1]) by ezln23.earthbroadcasting.com (8.9.3/8.9.3) with ESMTP id KAA02195 for ; Tue, 29 Jun 1999 10:23:36 -0600 (MDT) (envelope-from chris@thedial.com) Message-ID: <3778F308.1FD85B09@thedial.com> Date: Tue, 29 Jun 1999 10:23:36 -0600 From: Christopher Taylor X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: CMD 5440 Problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I installed a CMD 5440 with an Adaptec 2940 on FreeBSD 3.2 about four days ago. I followed the instructions on http://bsd.phoenix.az.us/raid/ for setting up my controller and it went smoothly. However, I started noticing file system errors on the RAID box, such as the following... ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y and... ** Phase 4 - Check Reference Counts UNREF FILE I=35859 OWNER=root MODE=100644 SIZE=0 MTIME=Jun 28 18:02 1999 CLEAR? [yn] y ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y There were other errors that came up as well, but I don't currently have those available. But, the errors were bad enough to cause my OS to become unstable. My system rebooted twice before becoming unable to mount my /usr partition (all of my partitions are on the RAID). I spoke with CMD tech support and their latest guess is that the issue is with the Adaptec controller. They said I should turn termination from 'Automatic' to 'Low on/High on'. I'm currently testing this to see if this fixes my problems In the mean time, I there anyone out there who can help me get this working. This is hindering an important project for my company and we are willing to pay consulting fees if need be to get this issue resolved. Thanks, --Chris Christopher Taylor Earth Broadcasting Corporation (801) 322-3949 cell: (801) 541-8287 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 8: 9:46 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 AF41715253 for ; Tue, 29 Jun 1999 08:09:43 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 10yyQz-0006PB-00; Tue, 29 Jun 1999 07:00:25 -0700 Date: Tue, 29 Jun 1999 07:00:23 -0700 (PDT) From: Tom To: Christopher Taylor Cc: Joe Gleason , freebsd-scsi@FreeBSD.ORG Subject: Re: fsck and dirty file systems In-Reply-To: <3778E366.54EBF7C9@thedial.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 29 Jun 1999, Christopher Taylor wrote: > The files systems this is happening on have all been mounted....I guess that > explains it...would you venture an explaination? ;) Mounted filesystems are always dirty by definition. I wouldn't even try to fsck a mounted filesystem. > --Chris Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 8:37:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (unknown [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id ACA4114F54 for ; Tue, 29 Jun 1999 08:37:40 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id JAA26885; Tue, 29 Jun 1999 09:37:26 -0600 (MDT) (envelope-from ken) Message-Id: <199906291537.JAA26885@panzer.kdm.org> Subject: Re: CMD 5440 Problems In-Reply-To: <3778F308.1FD85B09@thedial.com> from Christopher Taylor at "Jun 29, 1999 10:23:36 am" To: chris@thedial.com (Christopher Taylor) Date: Tue, 29 Jun 1999 09:37:26 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Christopher Taylor wrote... > I installed a CMD 5440 with an Adaptec 2940 on FreeBSD 3.2 about four > days ago. I followed the instructions on > > http://bsd.phoenix.az.us/raid/ > > for setting up my controller and it went smoothly. However, I started > noticing file system errors on the RAID box, such as the following... > > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? [yn] y > > and... > > ** Phase 4 - Check Reference Counts > UNREF FILE I=35859 OWNER=root MODE=100644 > SIZE=0 MTIME=Jun 28 18:02 1999 > CLEAR? [yn] y > > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? [yn] y > > SUMMARY INFORMATION BAD > SALVAGE? [yn] y > > BLK(S) MISSING IN BIT MAPS > SALVAGE? [yn] y > > There were other errors that came up as well, but I don't currently have > those available. But, the errors were bad enough to cause my OS to > become unstable. My system rebooted twice before becoming unable to > mount my /usr partition (all of my partitions are on the RAID). > I spoke with CMD tech support and their latest guess is that the issue You weren't by any chance fscking the filesystem while it was still mounted, were you? I noticed your other message in this list... fsck does things without the knowledge of the filesystem code (because it operates through the raw device) and thus can pull the rug out from under the filesystem. > is with the Adaptec controller. They said I should turn termination from > 'Automatic' to 'Low on/High on'. I'm currently testing this to see if > this fixes my problems > > In the mean time, I there anyone out there who can help me get this > working. This is hindering an important project for my company and we > are willing to pay consulting fees if need be to get this issue > resolved. In general, if you've got a SCSI problem, you'll get SCSI error messages of one sort or another. Adaptec's automatic termination option usually works, but setting it manually won't hurt. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 8:48:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 577FA15013 for ; Tue, 29 Jun 1999 08:48:23 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id KAA35943; Tue, 29 Jun 1999 10:48:07 -0500 (CDT) Message-ID: <19990629104807.A35939@Denninger.Net> Date: Tue, 29 Jun 1999 10:48:07 -0500 From: Karl Denninger To: "Kenneth D. Merry" , Christopher Taylor Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CMD 5440 Problems References: <3778F308.1FD85B09@thedial.com> <199906291537.JAA26885@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199906291537.JAA26885@panzer.kdm.org>; from Kenneth D. Merry on Tue, Jun 29, 1999 at 09:37:26AM -0600 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 29, 1999 at 09:37:26AM -0600, Kenneth D. Merry wrote: > Christopher Taylor wrote... > > I installed a CMD 5440 with an Adaptec 2940 on FreeBSD 3.2 about four > > days ago. I followed the instructions on > > You weren't by any chance fscking the filesystem while it was still > mounted, were you? I noticed your other message in this list... That'll do it. :-) I've used CMDs controllers with Adaptec host adapters and FreeBSD for an extended period of time, and have had no problems with them. The application in which I used these devices was an ISP - for primary storage. Trust me when I tell you that if there were implementation "funnies" I would have found them. With that said, I HAVE seen SCSI I/O errors - usually due to either power trouble or bad termination - in the past. But if you're not getting these, the fault almost certainly does not lie in the RAID subsystem. -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net SIGN the online petition for equal parental - and children's - rights at the above URL. Make a difference in a kid's life today. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 11:50:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id D299315138 for ; Tue, 29 Jun 1999 11:50:15 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA83997 for scsi@freebsd.org; Tue, 29 Jun 1999 13:50:13 -0500 (CDT) From: Joe Greco Message-Id: <199906291850.NAA83997@aurora.sol.net> Subject: FreeBSD panics with Mylex DAC960SX To: scsi@freebsd.org Date: Tue, 29 Jun 1999 13:50:13 -0500 (CDT) 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 Hello, First, cool stuff in 3.X! Hats off to you guys. I have one minor issue that I am hoping is a simple fix. I'm using Mylex DAC960SX SCSI-to-SCSI RAID controllers on an ASUS P2B-DS motherboard, off of the onboard SCSI controller. This is a neat gadget that makes a bunch of drives look like a single SCSI target. Now... here's the problem. The unit takes a while to start up (~60s) from power on, and until it reports "STARTUP COMPLETE", FreeBSD blows chunks when trying to access it. In particular, when the Mylex freaks out and thinks half its disks are dead (duh forgot to power them on), the startup sequence never completes, and FreeBSD will sit there doing boot-panic-boot-panic-etc. This is not very gracious, and is a bit irritating since the serial console I need to talk to the Mylex is on the box... So, my _real_ issue is the following panic: Booting [kernel]... /kernel text=0x104404 data=0x15cac+0x1bf4c syms=[0x4+0x1daa0+0x4+0x1ed04] 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.1-RELEASE #3: Mon Apr 12 06:06:16 CDT 1999 root@xxxxxx:/usr/src/sys/compile/SPOOL Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183fbff> real memory = 536870912 (524288K bytes) avail memory = 520056832 (507868K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xf0275000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs chip4: rev 0x03 on pci0.10.0 Probing for devices on PCI bus 1: Probing for devices on PCI bus 2: de0: rev 0x22 int a irq 18 on pci2.4.0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de0: address 00:e0:29:2b:e1:08 de1: rev 0x22 int a irq 19 on pci2.5.0 de1: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de1: address 00:e0:29:2b:e1:09 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 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 sio2: configured irq 5 not in bitmap of probed irqs 0 sio2 not found at 0x3e8 sio3: configured irq 9 not in bitmap of probed irqs 0 sio3 not found at 0x2e8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface we0 at 0x2e8 on isa we0: kernel is keeping watchdog alive APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert disabled, rule-based forwarding disabled, logging limited to 100 packets/entry Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! de1: enabling 100baseTX port changing root device tda0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) o da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: A de0: autosense failed: cable problem? swapon: adding /dev/da0s1b as swap device Automatic reboot in progress... /dev/rda0s1a: FILESYSTEM CLEAN^M; SKIPPING CHECK S ^M/dev/rda0s1a: clean, 138968 frFee (296 frags, 1a7334 blocks, 0.2t% fragmentation)a l trap 18: integer divide fault while in kernel mode mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 instruction pointer = 0x8:0xf014a681 stack pointer = 0x10:0xfa66b9d8 frame pointer = 0x10:0xfa66ba00 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 = 18 (fsck) interrupt mask = <- SMP: XXX trap number = 18 panic: integer divide fault mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 syncing disks... done (da1:ahc0:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da1:ahc0:0:1:0): NOT READY Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Grabbed mp lock for BSP cpu_reset_proxy: Stopped CPU 1 I apologize for not reproducing this on a 3.2R box but I assure you that it also panics in fsck on 3.2R in what appears to be an identical manner. The panic does seem to be caused by fsck - I can enter single user mode just fine. My guess is that the integer divide fault results from the device reporting a size of zero (strictly a guess though!). Normally, size is reported as da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 138928MB (284524544 512 byte sectors: 255H 63S/T 17710C) but during all of these crash-boots, the third line is da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: A If I can provide further information to assist in tracking down this bug, please let me know. Also, I was wondering more generally about what the proper way to deal with a device such as this is. Assuming FreeBSD didn't actually crash when trying to access the device, it is still possible to attempt booting when the DAC controller is not ready, which will result - presumably - in fsck exiting and complaining about that filesystem. What is the "correct" way to wait for something like this to become ready? Is there a "correct" way, even? Thanks, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 11:59:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ezln23.earthbroadcasting.com (ezln23.thedial.com [207.135.131.130]) by hub.freebsd.org (Postfix) with ESMTP id 8483E14F95 for ; Tue, 29 Jun 1999 11:59:11 -0700 (PDT) (envelope-from chris@thedial.com) Received: from thedial.com (localhost.earthbroadcasting.com [127.0.0.1]) by ezln23.earthbroadcasting.com (8.9.3/8.9.3) with ESMTP id CAA15381; Wed, 30 Jun 1999 02:59:50 -0600 (MDT) (envelope-from chris@thedial.com) Message-ID: <3779DC86.35FFB4B@thedial.com> Date: Wed, 30 Jun 1999 02:59:50 -0600 From: Christopher Taylor X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Karl Denninger Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: CMD 5440 Problems References: <3778F308.1FD85B09@thedial.com> <199906291537.JAA26885@panzer.kdm.org> <19990629104807.A35939@Denninger.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karl Denninger wrote: > On Tue, Jun 29, 1999 at 09:37:26AM -0600, Kenneth D. Merry wrote: > > Christopher Taylor wrote... > > > I installed a CMD 5440 with an Adaptec 2940 on FreeBSD 3.2 about four > > > days ago. I followed the instructions on > > > > You weren't by any chance fscking the filesystem while it was still > > mounted, were you? I noticed your other message in this list... > > That'll do it. :-) It sounds like the fsck'ing while the filesystem was mounted was the entire problem. I did an fsck while it was unmounted to clean up any file system problems and then proceeded to hammer the hell out of my RAID. Did another fsck while the RAID was unmounted and it is clean as a whistle. Thanks for your help.. --Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 16: 2:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (unknown [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 8FF74152CE for ; Tue, 29 Jun 1999 16:02:08 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA29666; Tue, 29 Jun 1999 17:00:50 -0600 (MDT) (envelope-from ken) Message-Id: <199906292300.RAA29666@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906291850.NAA83997@aurora.sol.net> from Joe Greco at "Jun 29, 1999 01:50:13 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Tue, 29 Jun 1999 17:00:50 -0600 (MDT) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joe Greco wrote... > Hello, > > First, cool stuff in 3.X! Hats off to you guys. > > I have one minor issue that I am hoping is a simple fix. > > I'm using Mylex DAC960SX SCSI-to-SCSI RAID controllers on an ASUS P2B-DS > motherboard, off of the onboard SCSI controller. This is a neat gadget > that makes a bunch of drives look like a single SCSI target. > > Now... here's the problem. The unit takes a while to start up (~60s) > from power on, and until it reports "STARTUP COMPLETE", FreeBSD blows > chunks when trying to access it. > > In particular, when the Mylex freaks out and thinks half its disks are > dead (duh forgot to power them on), the startup sequence never completes, > and FreeBSD will sit there doing boot-panic-boot-panic-etc. This is not > very gracious, and is a bit irritating since the serial console I need to > talk to the Mylex is on the box... > > So, my _real_ issue is the following panic: [ ... ] > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: A > de0: autosense failed: cable problem? > swapon: adding /dev/da0s1b as swap device > Automatic reboot in progress... > /dev/rda0s1a: FILESYSTEM CLEAN^M; SKIPPING CHECK > S > ^M/dev/rda0s1a: > clean, 138968 frFee (296 frags, 1a7334 blocks, 0.2t% fragmentation)a > l trap 18: integer divide fault while in kernel mode > mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 > instruction pointer = 0x8:0xf014a681 > stack pointer = 0x10:0xfa66b9d8 > frame pointer = 0x10:0xfa66ba00 > 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 = 18 (fsck) > interrupt mask = <- SMP: XXX > trap number = 18 > panic: integer divide fault > mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 > boot() called on cpu#1 > > syncing disks... done > (da1:ahc0:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da1:ahc0:0:1:0): NOT READY > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset called on cpu#1 > cpu_reset: Stopping other CPUs > cpu_reset: Restarting BSP > cpu_reset_proxy: Grabbed mp lock for BSP > cpu_reset_proxy: Stopped CPU 1 > > I apologize for not reproducing this on a 3.2R box but I assure you that > it also panics in fsck on 3.2R in what appears to be an identical manner. > The panic does seem to be caused by fsck - I can enter single user mode > just fine. > > My guess is that the integer divide fault results from the device reporting > a size of zero (strictly a guess though!). Normally, size is reported as > > da1: Fixed Direct Access SCSI-2 device > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: 138928MB (284524544 512 byte sectors: 255H 63S/T 17710C) > > but during all of these crash-boots, the third line is > > da1: Fixed Direct Access SCSI-2 device > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: A That should probably read "Attempt to query device size failed ...." You may be losing characters over the serial console or something. > If I can provide further information to assist in tracking down this bug, > please let me know. My first guess is that it's happening during the open() routine, for some reason. That's why fsck seems to cause the problem. You're probably right about the device returning a size of zero. It isn't immediately clear to me why the open routine would cause a panic, *unless* the Mylex unit returns good status for the read capacity command, but returns a capacity of 0. It would be helpful to get a stack trace from the machine, if you can. Enabling DDB at least will give us a DDB stack trace. > Also, I was wondering more generally about what the proper way to deal with > a device such as this is. Assuming FreeBSD didn't actually crash when > trying to access the device, it is still possible to attempt booting when > the DAC controller is not ready, which will result - presumably - in fsck > exiting and complaining about that filesystem. What is the "correct" way > to wait for something like this to become ready? Is there a "correct" way, > even? Well, it really depends on how the device behaves. Here's what happens after the initial probe phase: - the da driver sends a read capacity to the disk, with a retry count of 4 and a timeout of 5 seconds. 1. The read capacity succeeds, and the probe continues normally. 2. The read capacity fails, and one of a few things happen: 1. If the error has an associated error recovery action, we may send a start unit to the disk, or one TUR every half second for a minute. Then we retry the original command. 2. If the error has no associated error recovery action, we just retry it until the retry count is exhausted. My guess is that the error returned by the Mylex unit may not be an error with an associated recovery action. So we just retry it four times and then report the "Attempt to query device size failed ..." where ... is the error. Unfortunately, you're not getting the error printout, probably because of serial console weirdness. Could you try booting with -v? That will cause the full sense information for the error to get printed out, and maybe we'll have a better chance of figuring out what the error is. Also, once you boot up in single user mode, you might try the following camcontrol command: camcontrol cmd -n da -u 1 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" That will issue a read capacity command to da1, and print out the total number of blocks in the disk and the block size. The -v will tell camcontrol to print out sense information. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 18:59:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id BA58F14C23 for ; Tue, 29 Jun 1999 18:59:07 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id UAA13916; Tue, 29 Jun 1999 20:59:00 -0500 (CDT) From: Joe Greco Message-Id: <199906300159.UAA13916@aurora.sol.net> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906292300.RAA29666@panzer.kdm.org> from "Kenneth D. Merry" at "Jun 29, 1999 5: 0:50 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Tue, 29 Jun 1999 20:58:59 -0500 (CDT) Cc: scsi@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 > > but during all of these crash-boots, the third line is > > > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: A > > That should probably read "Attempt to query device size failed ...." > > You may be losing characters over the serial console or something. No. When done on a VGA console, it shows a graphic character or two. It does not interleave characters from the "changing root device..." though. :-) > > If I can provide further information to assist in tracking down this bug, > > please let me know. > > My first guess is that it's happening during the open() routine, for some > reason. That's why fsck seems to cause the problem. > > You're probably right about the device returning a size of zero. It isn't > immediately clear to me why the open routine would cause a panic, *unless* > the Mylex unit returns good status for the read capacity command, but > returns a capacity of 0. > > It would be helpful to get a stack trace from the machine, if you can. > Enabling DDB at least will give us a DDB stack trace. Okay. Alas, I must go physically bop the power on the machine to cause the Mylex to reset; once it is up and running it is _very_ happy. So I may not get to this for the next day or so. > > Also, I was wondering more generally about what the proper way to deal with > > a device such as this is. Assuming FreeBSD didn't actually crash when > > trying to access the device, it is still possible to attempt booting when > > the DAC controller is not ready, which will result - presumably - in fsck > > exiting and complaining about that filesystem. What is the "correct" way > > to wait for something like this to become ready? Is there a "correct" way, > > even? > > Well, it really depends on how the device behaves. Here's what happens > after the initial probe phase: > > - the da driver sends a read capacity to the disk, with a retry count of 4 > and a timeout of 5 seconds. > > 1. The read capacity succeeds, and the probe continues normally. > 2. The read capacity fails, and one of a few things happen: > > 1. If the error has an associated error recovery action, > we may send a start unit to the disk, or one TUR every > half second for a minute. Then we retry the original > command. > 2. If the error has no associated error recovery action, > we just retry it until the retry count is exhausted. > > My guess is that the error returned by the Mylex unit may not be an > error with an associated recovery action. So we just retry it four times > and then report the "Attempt to query device size failed ..." where ... is > the error. > > Unfortunately, you're not getting the error printout, probably because of > serial console weirdness. Could you try booting with -v? That will cause > the full sense information for the error to get printed out, and maybe > we'll have a better chance of figuring out what the error is. > > Also, once you boot up in single user mode, you might try the following > camcontrol command: > > camcontrol cmd -n da -u 1 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > > That will issue a read capacity command to da1, and print out the total > number of blocks in the disk and the block size. The -v will tell > camcontrol to print out sense information. I will be delighted to. :-) Unfortunately, I will probably have to putz with it a bit, because the Mylex generally becomes ready within a minute of me making it to single user mode. Sigh. I'll also see if it is any different if I break the array, which also causes a panic (but might result in different specifics). ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 29 20:44: 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 DC37414D0A for ; Tue, 29 Jun 1999 20:44:00 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA31467; Tue, 29 Jun 1999 21:42:42 -0600 (MDT) (envelope-from ken) Message-Id: <199906300342.VAA31467@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906300159.UAA13916@aurora.sol.net> from Joe Greco at "Jun 29, 1999 08:58:59 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Tue, 29 Jun 1999 21:42:42 -0600 (MDT) Cc: scsi@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joe Greco wrote... > > > but during all of these crash-boots, the third line is > > > > > > da1: Fixed Direct Access SCSI-2 device > > > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > > > da1: A > > > > That should probably read "Attempt to query device size failed ...." > > > > You may be losing characters over the serial console or something. > > No. When done on a VGA console, it shows a graphic character or two. Hmm, I don't understand what's going on there. > It does not interleave characters from the "changing root device..." > though. :-) That's normal. > > > If I can provide further information to assist in tracking down this bug, > > > please let me know. > > > > My first guess is that it's happening during the open() routine, for some > > reason. That's why fsck seems to cause the problem. > > > > You're probably right about the device returning a size of zero. It isn't > > immediately clear to me why the open routine would cause a panic, *unless* > > the Mylex unit returns good status for the read capacity command, but > > returns a capacity of 0. > > > > It would be helpful to get a stack trace from the machine, if you can. > > Enabling DDB at least will give us a DDB stack trace. > > Okay. Alas, I must go physically bop the power on the machine to cause > the Mylex to reset; once it is up and running it is _very_ happy. So I > may not get to this for the next day or so. Okay, well, whenever you do get to it, lemme know. > > Unfortunately, you're not getting the error printout, probably because of > > serial console weirdness. Could you try booting with -v? That will cause > > the full sense information for the error to get printed out, and maybe > > we'll have a better chance of figuring out what the error is. > > > > Also, once you boot up in single user mode, you might try the following > > camcontrol command: > > > > camcontrol cmd -n da -u 1 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > > > > That will issue a read capacity command to da1, and print out the total > > number of blocks in the disk and the block size. The -v will tell > > camcontrol to print out sense information. > > I will be delighted to. :-) Unfortunately, I will probably have to putz > with it a bit, because the Mylex generally becomes ready within a minute > of me making it to single user mode. Sigh. You might try sticking a little shell script to execute the command in the root directory so you don't have to type it in. > I'll also see if it is any different if I break the array, which also > causes a panic (but might result in different specifics). That would be good to check on. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 5:23:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from maui.net (maui.net [207.175.210.2]) by hub.freebsd.org (Postfix) with ESMTP id 9009814BCE; Wed, 30 Jun 1999 05:23:32 -0700 (PDT) (envelope-from langfod@kauai.pacificglobal.net) Received: from kauai.pacificglobal.net (Kauai.PacificGlobal.NET [209.84.182.101]) by maui.net (8.8.7/8.8.5) with ESMTP id CAA18025; Wed, 30 Jun 1999 02:20:50 -1000 (HST) Received: (from langfod@localhost) by kauai.pacificglobal.net (8.8.8/8.8.5) id CAA18398; Wed, 30 Jun 1999 02:20:49 -1000 (HST) From: David Langford Message-Id: <199906301220.CAA18398@kauai.pacificglobal.net> Subject: Re: Are SIIG SCSI Cards Supported? In-Reply-To: <199906281608.KAA18990@panzer.kdm.org> from "Kenneth D. Merry" at "Jun 28, 1999 10: 8:15 am" To: scsi@freebsd.org Date: Wed, 30 Jun 1999 02:20:49 -1000 (HST) X-blank-line: This space intentionaly left blank. 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 Okay I just tried it with current and it seems to work fine. Note that you need to add "COMPAT_PCI_DRIVER(iha, i91u_device);" somewhere around line 133 of i91u.c. Right now my system is running off of a SIIG AP-40 (~$140) and all seems fine. Also I have a IWILL SIDE-2935UW that at first glance seems to work with this same driver. I havent had a chance to do any real testing with either one though. Now if we can just get this driver into the main tree. Since it looks likes Adaptec has pretty much killed the Sysmbios/NCR chipset the Initio line may be the next reasonable cost SCSI controller... -David Langford langfod@dihelix.com >> > The Initio chips are not supported. There is a driver, written by Initio, >> > for the old SCSI layer, but as far as I know, it hasn't been ported to CAM. >> >> The CAM drivers for Initio chips are found at http://www.ioiscsi.com/bios.html >> It seems they supports Ultra and U2W IOI SCSI cards. >> I haven't tried it yet, but I saw some reports how it works, at >> Japanese mailing list. > >Wow, thanks for the pointer! I didn't know they had updated it, that's >pretty cool. >Ken >-- >Kenneth Merry >ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 6:41:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 596BF15109 for ; Wed, 30 Jun 1999 06:41:30 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id IAA13135; Wed, 30 Jun 1999 08:41:29 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id IAA11937; Wed, 30 Jun 1999 08:41:28 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id IAA14025; Wed, 30 Jun 1999 08:41:28 -0500 (CDT) Date: Wed, 30 Jun 1999 08:41:28 -0500 (CDT) From: Jonathan Lemon Message-Id: <199906301341.IAA14025@free.pcs> To: ken@plutotech.com, scsi@freebsd.org Subject: Re: FreeBSD panics with Mylex DAC960SX X-Newsgroups: local.mail.freebsd-scsi In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >Joe Greco wrote... >> >> da1: Fixed Direct Access SCSI-2 device >> da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled >> da1: A > >That should probably read "Attempt to query device size failed ...." > >You may be losing characters over the serial console or something. > >> If I can provide further information to assist in tracking down this bug, >> please let me know. > >My first guess is that it's happening during the open() routine, for some >reason. That's why fsck seems to cause the problem. > >You're probably right about the device returning a size of zero. It isn't >immediately clear to me why the open routine would cause a panic, *unless* >the Mylex unit returns good status for the read capacity command, but >returns a capacity of 0. I have a situation that sounds similar to this, with similar results. In my case, I have a mostly-bad SCSI disk that doesn't work until it is sufficiently warmed up. When booting, one of the SCSI commands sent to the drive (mode sense, I think) fails, and the kernel panics. Basically, the SCSI bus recognizes some thing is there, but can't even read the vendor string from the disk. "Device connected, but has a fault." -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 10:43:24 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 2D51A155A1 for ; Wed, 30 Jun 1999 10:43:11 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA00843; Wed, 30 Jun 1999 19:29:12 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA00581; Wed, 30 Jun 1999 19:27:26 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199906301727.TAA00581@yedi.iaf.nl> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906292300.RAA29666@panzer.kdm.org> from "Kenneth D. Merry" at "Jun 29, 1999 5: 0:50 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 30 Jun 1999 19:27:26 +0200 (CEST) Cc: jgreco@ns.sol.net, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Joe Greco wrote... > > Hello, > > > > First, cool stuff in 3.X! Hats off to you guys. > > > > I have one minor issue that I am hoping is a simple fix. > > > > I'm using Mylex DAC960SX SCSI-to-SCSI RAID controllers on an ASUS P2B-DS > > motherboard, off of the onboard SCSI controller. This is a neat gadget > > that makes a bunch of drives look like a single SCSI target. > > > > Now... here's the problem. The unit takes a while to start up (~60s) > > from power on, and until it reports "STARTUP COMPLETE", FreeBSD blows > > chunks when trying to access it. > > > > In particular, when the Mylex freaks out and thinks half its disks are > > dead (duh forgot to power them on), the startup sequence never completes, > > and FreeBSD will sit there doing boot-panic-boot-panic-etc. This is not > > very gracious, and is a bit irritating since the serial console I need to > > talk to the Mylex is on the box... > > > > So, my _real_ issue is the following panic: > > [ ... ] > > > da1 at ahc0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: A > > de0: autosense failed: cable problem? > > swapon: adding /dev/da0s1b as swap device > > Automatic reboot in progress... > > /dev/rda0s1a: FILESYSTEM CLEAN^M; SKIPPING CHECK > > S > > ^M/dev/rda0s1a: > > clean, 138968 frFee (296 frags, 1a7334 blocks, 0.2t% fragmentation)a > > l trap 18: integer divide fault while in kernel mode > > mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 > > instruction pointer = 0x8:0xf014a681 > > stack pointer = 0x10:0xfa66b9d8 > > frame pointer = 0x10:0xfa66ba00 > > 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 = 18 (fsck) > > interrupt mask = <- SMP: XXX > > trap number = 18 > > panic: integer divide fault > > mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 > > boot() called on cpu#1 > > > > syncing disks... done > > (da1:ahc0:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > > (da1:ahc0:0:1:0): NOT READY > > Automatic reboot in 15 seconds - press a key on the console to abort > > Rebooting... > > cpu_reset called on cpu#1 > > cpu_reset: Stopping other CPUs > > cpu_reset: Restarting BSP > > cpu_reset_proxy: Grabbed mp lock for BSP > > cpu_reset_proxy: Stopped CPU 1 > > > > I apologize for not reproducing this on a 3.2R box but I assure you that > > it also panics in fsck on 3.2R in what appears to be an identical manner. > > The panic does seem to be caused by fsck - I can enter single user mode > > just fine. > > > > My guess is that the integer divide fault results from the device reporting > > a size of zero (strictly a guess though!). Normally, size is reported as > > > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: 138928MB (284524544 512 byte sectors: 255H 63S/T 17710C) > > > > but during all of these crash-boots, the third line is > > > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: A > > That should probably read "Attempt to query device size failed ...." > > You may be losing characters over the serial console or something. > > > If I can provide further information to assist in tracking down this bug, > > please let me know. > > My first guess is that it's happening during the open() routine, for some > reason. That's why fsck seems to cause the problem. > > You're probably right about the device returning a size of zero. It isn't > immediately clear to me why the open routine would cause a panic, *unless* > the Mylex unit returns good status for the read capacity command, but > returns a capacity of 0. Although this definitely a bogus response I don't see the point in panic-ing the machine. An offensive message on the console, by all means. A panic? This remark assumes you are not booting from the raid of course :) -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 10:47:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quark.ChrisBowman.com (crbowman.erols.com [209.122.47.155]) by hub.freebsd.org (Postfix) with ESMTP id 1BD1F15583 for ; Wed, 30 Jun 1999 10:47:30 -0700 (PDT) (envelope-from crb@ChrisBowman.com) Received: from fermion (fermion.ChrisBowman.com [10.0.1.2]) by quark.ChrisBowman.com (8.9.3/8.9.3) with SMTP id MAA01518; Wed, 30 Jun 1999 12:47:22 -0500 (EST) (envelope-from crb@ChrisBowman.com) Message-Id: <199906301747.MAA01518@quark.ChrisBowman.com> X-Sender: crb@quark X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 30 Jun 1999 13:45:02 -0400 To: David Langford From: "Christopher R. Bowman" Subject: Re: Are SIIG SCSI Cards Supported? Cc: scsi@FreeBSD.ORG In-Reply-To: <199906301220.CAA18398@kauai.pacificglobal.net> References: <199906281608.KAA18990@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:20 AM 6/30/99 -1000, David Langford wrote: >[yada yada yada ...] > >Now if we can just get this driver into the main tree. >Since it looks likes Adaptec has pretty much killed the Sysmbios/NCR >chipset the Initio line may be the next reasonable cost SCSI controller... What in the world makes you think that Adaptec has killed the Symbios chipsets? I have heard no such thing. In fact controllers continue to come out using the latest Symbios chips supporting the latest SCSI standards. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 12: 9:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 28CB71503C for ; Wed, 30 Jun 1999 12:09:19 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA85863; Wed, 30 Jun 1999 14:09:12 -0500 (CDT) From: Joe Greco Message-Id: <199906301909.OAA85863@aurora.sol.net> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906301727.TAA00581@yedi.iaf.nl> from Wilko Bulte at "Jun 30, 1999 7:27:26 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Wed, 30 Jun 1999 14:09:12 -0500 (CDT) Cc: ken@plutotech.com, scsi@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 > > You're probably right about the device returning a size of zero. It isn't > > immediately clear to me why the open routine would cause a panic, *unless* > > the Mylex unit returns good status for the read capacity command, but > > returns a capacity of 0. > > Although this definitely a bogus response I don't see the point in panic-ing > the machine. An offensive message on the console, by all means. A panic? > > This remark assumes you are not booting from the raid of course :) Couldn't boot from it 'til it was ready (which it isn't, which leads to this entire problem). Okay, anyways, ddb output. I really have no clue what I'm doing with the kernel debugger so if I did anything stupid and you need other data, let me know what to do. I put the camcontrol statement and then a fsck -p into root's .profile so that it'd be a bit easier to manage this little show. changing root device to dda0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) a0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: A Enter full pathname of shell or RETURN for /bin/sh: erase ^H, kill ^U, intr ^C /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 camcontrol: error sending command (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (pass1:ahc0:0:1:0): NOT READY end of camcontrol /dev/rda0s1a: cFILESYSTEM CLEANk; SKIPPING CHECKpS 2% fragmentationlean, 127256 f1ree (296 frags, c15870 blocks, 0. ) Fatal trap 18: integer divide fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 01000000 instruction pointer = 0x8:0xf014e637 stack pointer = 0x10:0xfa6399d8 frame pointer = 0x10:0xfa639a00 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 = 10 (fsck) interrupt mask = <- SMP: XXX kernel: type 18 trap, code=0 Stopped at dscheck+0xbb: idivl 0x18(%ecx),%eax db> tracede0: autosense failed: cable problem? /u dscheck(f67b3ae8,f182dd00) at dscheck+0xbb dastrategy(f67b3ae8,0,fa639a01,f181fc00,f181fccc) at dastrategy+0x56 dsinit(f01f746b,20d0c,f01205d4,fa639c90,f181fccc) at dsinit+0x52 dsopen(f01f746b,20d0c,2000,0,f181fccc) at dsopen+0x8e daopen(20d0c,1,2000,fa61b4c0,0) at daopen+0x2a1 spec_open(fa639e2c,fa639e00,f01ae21d,fa639e2c,fa639ea0) at spec_open+0x161 spec_vnoperate(fa639e2c,fa639ea0,f01712ca,fa639e2c,0) at spec_vnoperate+0x15 ufs_vnoperatespec(fa639e2c,0,fa639f94,fa61b4c0,f016879e) at ufs_vnoperatespec+0x15 vn_open(fa639f00,1,140,fa61b4c0,f021527c) at vn_open+0x3e2 open(fa61b4c0,fa639f94,8097140,1,804ac68) at open+0xad syscall(27,27,804ac68,1,efbfdbb4) at syscall+0x187 Xint0x80_syscall() at Xint0x80_syscall+0x4c db> Now, based on some trace printf's I sprinkled in dscheck, it looks to me like I get as far as if (bp->b_bcount % ssp->dss_secsize) goto bad_bcount; around line #191 of kern/subr_diskslice.c. (you can see the "ckpt1c" interspersed with other output if you look carefully). It does not hit the printf() right after that, so I am guessing that ssp->dss_secsize is probably zero. Gah, I feel like I'm programming a Windows box. :-) Okay, I've added a little extra code in there. Now we do } else { printf("ckpt1c\n"); if (! ssp->dss_secsize) { printf("Whoa!\n"); printf("ssp->dss_first_bsd_slice=%d\n", ssp->dss_first_bsd_slice); printf("ssp->dss_nslices=%d\n", ssp->dss_nslices); printf("ssp->dss_oflags=%d\n", ssp->dss_oflags); printf("ssp->dss_secmult=%d\n", ssp->dss_secmult); printf("ssp->dss_secshift=%d\n", ssp->dss_secshift); printf("ssp->dss_secsize=%d\n", ssp->dss_secsize); goto bad; } if (bp->b_bcount % ssp->dss_secsize) goto bad_bcount; Ahh. It doesn't crash now. changing root device tda0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) o da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: A Enter full pathname of shell or RETURN for /bin/sh: erase ^H, kill ^U, intr ^C /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 camcontrol: error sending command (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (pass1:ahc0:0:1:0): NOT READY end of camcontrol /dev/rda0s1a: cFILESYSTEM CLEANk; SKIPPING CHECKpS 2% fragmentationlean, 127256 f1ree (296 frags, c15870 blocks, 0. ) Whoa! ssp->dss_first_bsd_slice=0 ssp->dss_nslices=2 ssp->dss_oflags=0 ssp->dss_secmult=0 ssp->dss_secshift=-1 ssp->dss_secsize=0 da1: error reading primary partition table reading fsbn 0 Can't open /dev/rda1s1e: Input/output error /dev/rda1s1e: CAN'T CHECK FILE SYSTEM. /dev/rda1s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/rda0s1h: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rda0s1h: clean, 232316 free (132 frags, 29023 blocks, 0.1% fragmentation) /dev/rda0s1e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rda0s1e: clean, 51021 free (8125 frags, 5362 blocks, 4.1% fragmentation) /dev/rda0s1f: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rda0s1f: clean, 112455 free (239 frags, 14027 blocks, 0.2% fragmentation) /dev/rda0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rda0s1g: clean, 1308689 free (321 frags, 163546 blocks, 0.0% fragmentation) THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: /dev/rda1s1e (/news) # de0: autosense failed: cable problem? Now if I wait for just a bit, # /sbin/camcontrol cmd -n da -u 1 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 284524543 512 Okay, well, I don't know what the hell the correct fix is, but this will hopefully light a bulb in some SCSI guru's head. The panic, I would think, has _got_ to be fixed. If anyone has a great suggestion on how I can make this work properly, that's good too. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 14:28:16 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 D7A39156F4 for ; Wed, 30 Jun 1999 14:28:09 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA13173; Wed, 30 Jun 1999 23:05:34 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id WAA04041; Wed, 30 Jun 1999 22:07:53 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199906302007.WAA04041@yedi.iaf.nl> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906301909.OAA85863@aurora.sol.net> from Joe Greco at "Jun 30, 1999 2: 9:12 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Wed, 30 Jun 1999 22:07:53 +0200 (CEST) Cc: ken@plutotech.com, 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 Joe Greco wrote ... > > > You're probably right about the device returning a size of zero. It isn't > > > immediately clear to me why the open routine would cause a panic, *unless* > > > the Mylex unit returns good status for the read capacity command, but > > > returns a capacity of 0. > > > > Although this definitely a bogus response I don't see the point in panic-ing > > the machine. An offensive message on the console, by all means. A panic? > > > > This remark assumes you are not booting from the raid of course :) > > Couldn't boot from it 'til it was ready (which it isn't, which leads to this > entire problem). > > Okay, anyways, ddb output. I really have no clue what I'm doing with the > kernel debugger so if I did anything stupid and you need other data, let me > know what to do. > > I put the camcontrol statement and then a fsck -p into root's .profile so > that it'd be a bit easier to manage this little show. > > changing root device to dda0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) > a0s1a > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: A > Enter full pathname of shell or RETURN for /bin/sh: > erase ^H, kill ^U, intr ^C > /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 > camcontrol: error sending command > (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (pass1:ahc0:0:1:0): NOT READY > end of camcontrol > /dev/rda0s1a: cFILESYSTEM CLEANk; SKIPPING CHECKpS > 2% fragmentationlean, 127256 f1ree (296 frags, c15870 blocks, 0. > ) > > > Fatal trap 18: integer divide fault while in kernel mode Integer divide fault... hmm. I have this old DEC RRD42 cdrom drive that works just fine with 2.2.7 but panics a 3.1 install floppy with 'integer divide fault'. 100% repeatable too. On an Adaptec 1740 EISA card by the way. I'll drag it home tomorrow evening to see if it gives a similar traceback. Could be something completely different of course. But still. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 20: 1:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id BB45E1505D for ; Wed, 30 Jun 1999 20:01:12 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id MAA30296; Thu, 1 Jul 1999 12:57:43 +1000 Date: Thu, 1 Jul 1999 12:57:43 +1000 From: Bruce Evans Message-Id: <199907010257.MAA30296@godzilla.zeta.org.au> To: jgreco@ns.sol.net, wilko@yedi.iaf.nl Subject: Re: FreeBSD panics with Mylex DAC960SX Cc: ken@plutotech.com, scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Now, based on some trace printf's I sprinkled in dscheck, it looks to >me like I get as far as > >if (bp->b_bcount % ssp->dss_secsize) > goto bad_bcount; > >around line #191 of kern/subr_diskslice.c. (you can see the "ckpt1c" >interspersed with other output if you look carefully). It does not >hit the printf() right after that, so I am guessing that ssp->dss_secsize >is probably zero. Try this "fix" for dsopen(). This should cause open() to fail before the sector size is used; in particular it should prevent divisions by sector sizes of 0. I don't know how open() gets so far before the sector size is known. Bruce diff -c2 subr_diskslice.c~ subr_diskslice.c *** subr_diskslice.c~ Sat Jun 26 23:42:00 1999 --- subr_diskslice.c Thu Jul 1 12:42:09 1999 *************** *** 731,735 **** unit = dkunit(dev); ! if (lp->d_secsize % DEV_BSIZE) { printf("%s%d: invalid sector size %lu\n", dname, unit, (u_long)lp->d_secsize); --- 731,735 ---- unit = dkunit(dev); ! if (lp->d_secsize == 0 || lp->d_secsize % DEV_BSIZE != 0) { printf("%s%d: invalid sector size %lu\n", dname, unit, (u_long)lp->d_secsize); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 21:12:12 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 1651214D3B for ; Wed, 30 Jun 1999 21:12:07 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA39523; Wed, 30 Jun 1999 22:10:43 -0600 (MDT) (envelope-from ken) Message-Id: <199907010410.WAA39523@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906301909.OAA85863@aurora.sol.net> from Joe Greco at "Jun 30, 1999 02:09:12 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Wed, 30 Jun 1999 22:10:43 -0600 (MDT) Cc: wilko@yedi.iaf.nl (Wilko Bulte), scsi@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM930802243-39452-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM930802243-39452-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Joe Greco wrote... > > > You're probably right about the device returning a size of zero. It isn't > > > immediately clear to me why the open routine would cause a panic, *unless* > > > the Mylex unit returns good status for the read capacity command, but > > > returns a capacity of 0. > > > > Although this definitely a bogus response I don't see the point in panic-ing > > the machine. An offensive message on the console, by all means. A panic? > > > > This remark assumes you are not booting from the raid of course :) > > Couldn't boot from it 'til it was ready (which it isn't, which leads to this > entire problem). > > Okay, anyways, ddb output. I really have no clue what I'm doing with the > kernel debugger so if I did anything stupid and you need other data, let me > know what to do. > > I put the camcontrol statement and then a fsck -p into root's .profile so > that it'd be a bit easier to manage this little show. > > changing root device to dda0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) > a0s1a > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: A > Enter full pathname of shell or RETURN for /bin/sh: > erase ^H, kill ^U, intr ^C > /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 > camcontrol: error sending command > (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (pass1:ahc0:0:1:0): NOT READY > end of camcontrol That's odd. No ASC or ASCQ, just a sense key. Most SCSI-2 devices will give you an ASC and an ASCQ. Even still, that in and of itself shouldn't be enough to cause trouble for us... [ ... ] > db> tracede0: autosense failed: cable problem? > /u > dscheck(f67b3ae8,f182dd00) at dscheck+0xbb > dastrategy(f67b3ae8,0,fa639a01,f181fc00,f181fccc) at dastrategy+0x56 > dsinit(f01f746b,20d0c,f01205d4,fa639c90,f181fccc) at dsinit+0x52 > dsopen(f01f746b,20d0c,2000,0,f181fccc) at dsopen+0x8e > daopen(20d0c,1,2000,fa61b4c0,0) at daopen+0x2a1 > spec_open(fa639e2c,fa639e00,f01ae21d,fa639e2c,fa639ea0) at spec_open+0x161 > spec_vnoperate(fa639e2c,fa639ea0,f01712ca,fa639e2c,0) at spec_vnoperate+0x15 > ufs_vnoperatespec(fa639e2c,0,fa639f94,fa61b4c0,f016879e) at > ufs_vnoperatespec+0x15 > vn_open(fa639f00,1,140,fa61b4c0,f021527c) at vn_open+0x3e2 > open(fa61b4c0,fa639f94,8097140,1,804ac68) at open+0xad > syscall(27,27,804ac68,1,efbfdbb4) at syscall+0x187 > Xint0x80_syscall() at Xint0x80_syscall+0x4c > db> > > Now, based on some trace printf's I sprinkled in dscheck, it looks to > me like I get as far as > > if (bp->b_bcount % ssp->dss_secsize) > goto bad_bcount; > > around line #191 of kern/subr_diskslice.c. (you can see the "ckpt1c" > interspersed with other output if you look carefully). It does not > hit the printf() right after that, so I am guessing that ssp->dss_secsize > is probably zero. Yeah, that would explain the divide by zero panic. [ ... ] > Ahh. It doesn't crash now. > > changing root device tda0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) > o da0s1a > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: A > Enter full pathname of shell or RETURN for /bin/sh: > erase ^H, kill ^U, intr ^C > /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 > camcontrol: error sending command > (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (pass1:ahc0:0:1:0): NOT READY > end of camcontrol > /dev/rda0s1a: cFILESYSTEM CLEANk; SKIPPING CHECKpS > 2% fragmentationlean, 127256 f1ree (296 frags, c15870 blocks, 0. > ) > Whoa! > ssp->dss_first_bsd_slice=0 > ssp->dss_nslices=2 > ssp->dss_oflags=0 > ssp->dss_secmult=0 > ssp->dss_secshift=-1 > ssp->dss_secsize=0 > da1: error reading primary partition table reading fsbn 0 > Can't open /dev/rda1s1e: Input/output error [ ... ] > Now if I wait for just a bit, > > # /sbin/camcontrol cmd -n da -u 1 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > 284524543 512 > > Okay, well, I don't know what the hell the correct fix is, but this > will hopefully light a bulb in some SCSI guru's head. The panic, I would > think, has _got_ to be fixed. If anyone has a great suggestion on how I > can make this work properly, that's good too. Well, Bruce's fix, as he hinted, just covers up the problem, and doesn't really address it. It's probably a good check to have, though. There are several questions I have, which I hope can be answered with some diagnostic patches I've appended. 1. Why does the da1 announcement just print 'A' and not the rest of the line? 2. Why does the camcontrol read capacity output indicate that the Mylex array is not ready, yet an open immediately after that seems to pass the read capacity by just fine? 3. Assuming the read capacity is returned without an error, why does the Mylex return a bogus sector size at least? (indicated by your diagnostic output from the slice code above) Hopefully I can at least get a clue to the answers for 1 and 2 with the patches appended. So, Joe, could you: - apply Bruce's patch (so you won't panic), or just keep the one you've got - apply the attached patch to scsi_da.c - boot with -v (boot kernel -v at the loader prompt) - send the output from the boot I'm rather confused by this, and I'd like to figure out what's going on. Thanks, Ken -- Kenneth Merry ken@plutotech.com --ELM930802243-39452-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=scsi_da.c.diagnostics.063099 Content-Description: scsi_da.c.diagnostics.063099 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_da.c#101 - /a/ken/perforce/cam/sys/cam/scsi/scsi_da.c ==== *** /tmp/tmp.22962.0 Wed Jun 30 21:57:06 1999 --- /a/ken/perforce/cam/sys/cam/scsi/scsi_da.c Wed Jun 30 21:56:28 1999 *************** *** 336,343 **** --- 336,353 ---- SF_RETRY_SELTO, &softc->device_stats); + xpt_print_path(periph->path); + printf("read capacity returned %d\n", error); + + scsi_sense_print(&ccb->csio); + + xpt_print_path(periph->path); + printf("address = %d, length = %d\n", + scsi_4btoul(rcap->addr), scsi_4btoul(rcap->length)); + xpt_release_ccb(ccb); + if (error == 0) { dasetgeom(periph, rcap); } *************** *** 1372,1378 **** * unit not supported" (0x25) error. */ if ((have_sense) && (asc != 0x25) ! && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), "Attempt to query device " --- 1382,1392 ---- * unit not supported" (0x25) error. */ if ((have_sense) && (asc != 0x25) ! && (error_code == SSD_CURRENT_ERROR)) { ! printf("got sense: " ! "sense_key = %#x, asc = %#x, " ! "ascq = %#x\n", ! sense_key, asc, ascq); snprintf(announce_buf, sizeof(announce_buf), "Attempt to query device " *************** *** 1380,1386 **** scsi_sense_key_text[sense_key], scsi_sense_desc(asc,ascq, &cgd.inq_data)); ! else { if (have_sense) scsi_sense_print( &done_ccb->csio); --- 1394,1400 ---- scsi_sense_key_text[sense_key], scsi_sense_desc(asc,ascq, &cgd.inq_data)); ! } else { if (have_sense) scsi_sense_print( &done_ccb->csio); *************** *** 1403,1410 **** --- 1417,1428 ---- } } free(rdcap, M_TEMP); + xpt_print_path(periph->path); + printf("about to print announcement\n"); if (announce_buf[0] != '\0') xpt_announce_periph(periph, announce_buf); + xpt_print_path(periph->path); + printf("printed announcement\n"); softc->state = DA_STATE_NORMAL; /* * Since our peripheral may be invalidated by an error --ELM930802243-39452-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 21:14: 9 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 992FD14D3B for ; Wed, 30 Jun 1999 21:14:06 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA39536; Wed, 30 Jun 1999 22:12:44 -0600 (MDT) (envelope-from ken) Message-Id: <199907010412.WAA39536@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906302007.WAA04041@yedi.iaf.nl> from Wilko Bulte at "Jun 30, 1999 10:07:53 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Wed, 30 Jun 1999 22:12:44 -0600 (MDT) Cc: jgreco@ns.sol.net (Joe Greco), 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 Wilko Bulte wrote... > As Joe Greco wrote ... > > I put the camcontrol statement and then a fsck -p into root's .profile so > > that it'd be a bit easier to manage this little show. > > > > changing root device to dda0 at ahc0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled > > da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) > > a0s1a > > da1 at ahc0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: A > > Enter full pathname of shell or RETURN for /bin/sh: > > erase ^H, kill ^U, intr ^C > > /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 > > camcontrol: error sending command > > (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (pass1:ahc0:0:1:0): NOT READY > > end of camcontrol > > /dev/rda0s1a: cFILESYSTEM CLEANk; SKIPPING CHECKpS > > 2% fragmentationlean, 127256 f1ree (296 frags, c15870 blocks, 0. > > ) > > > > > > Fatal trap 18: integer divide fault while in kernel mode > > Integer divide fault... hmm. I have this old DEC RRD42 cdrom drive > that works just fine with 2.2.7 but panics a 3.1 install floppy with > 'integer divide fault'. 100% repeatable too. On an Adaptec 1740 EISA > card by the way. > > I'll drag it home tomorrow evening to see if it gives a similar traceback. > Could be something completely different of course. But still. It would be interesting to see what the problem is there as well. The CD driver does something similar to the da driver on boot, so the problem could be the same. Is the behavior any different with a CD in the drive or out of the drive? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 21:17:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 88ABD14D3B for ; Wed, 30 Jun 1999 21:17:17 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA39568; Wed, 30 Jun 1999 22:15:23 -0600 (MDT) (envelope-from ken) Message-Id: <199907010415.WAA39568@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907010257.MAA30296@godzilla.zeta.org.au> from Bruce Evans at "Jul 1, 1999 12:57:43 pm" To: bde@zeta.org.au (Bruce Evans) Date: Wed, 30 Jun 1999 22:15:23 -0600 (MDT) Cc: jgreco@ns.sol.net, wilko@yedi.iaf.nl, 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 Bruce Evans wrote... > >Now, based on some trace printf's I sprinkled in dscheck, it looks to > >me like I get as far as > > > >if (bp->b_bcount % ssp->dss_secsize) > > goto bad_bcount; > > > >around line #191 of kern/subr_diskslice.c. (you can see the "ckpt1c" > >interspersed with other output if you look carefully). It does not > >hit the printf() right after that, so I am guessing that ssp->dss_secsize > >is probably zero. > > Try this "fix" for dsopen(). This should cause open() to fail before the > sector size is used; in particular it should prevent divisions by sector > sizes of 0. I don't know how open() gets so far before the sector size is > known. I don't know either, but I intend to find out. :) In any case, that "fix" might actually be useful to catch pathological cases -- i.e. where the drive doesn't return an error for a read capacity, but the data it returns is bogus. (e.g. sector size of 0) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 21:19:17 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 3AB5514D3B for ; Wed, 30 Jun 1999 21:19:14 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA39579; Wed, 30 Jun 1999 22:17:54 -0600 (MDT) (envelope-from ken) Message-Id: <199907010417.WAA39579@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906301727.TAA00581@yedi.iaf.nl> from Wilko Bulte at "Jun 30, 1999 07:27:26 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Wed, 30 Jun 1999 22:17:54 -0600 (MDT) Cc: jgreco@ns.sol.net, 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 Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > My first guess is that it's happening during the open() routine, for some > > reason. That's why fsck seems to cause the problem. > > > > You're probably right about the device returning a size of zero. It isn't > > immediately clear to me why the open routine would cause a panic, *unless* > > the Mylex unit returns good status for the read capacity command, but > > returns a capacity of 0. > > Although this definitely a bogus response I don't see the point in panic-ing > the machine. An offensive message on the console, by all means. A panic? Well, I think the panic is certainly a bug. There should probably be a check for a sector size of 0 somewhere. The only question is whether it should be centralized in the slice code or broken out into each individual driver. I think it may make sense to centralize it. > This remark assumes you are not booting from the raid of course :) Of course. :) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 21:20:11 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 960241555A for ; Wed, 30 Jun 1999 21:20:08 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA39599; Wed, 30 Jun 1999 22:20:05 -0600 (MDT) (envelope-from ken) Message-Id: <199907010420.WAA39599@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199906301341.IAA14025@free.pcs> from Jonathan Lemon at "Jun 30, 1999 08:41:28 am" To: jlemon@americantv.com (Jonathan Lemon) Date: Wed, 30 Jun 1999 22:20:05 -0600 (MDT) Cc: scsi@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote... > In article you write: > >Joe Greco wrote... > >> > >> da1: Fixed Direct Access SCSI-2 device > >> da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > >> da1: A > > > >That should probably read "Attempt to query device size failed ...." > > > >You may be losing characters over the serial console or something. > > > >> If I can provide further information to assist in tracking down this bug, > >> please let me know. > > > >My first guess is that it's happening during the open() routine, for some > >reason. That's why fsck seems to cause the problem. > > > >You're probably right about the device returning a size of zero. It isn't > >immediately clear to me why the open routine would cause a panic, *unless* > >the Mylex unit returns good status for the read capacity command, but > >returns a capacity of 0. > > I have a situation that sounds similar to this, with similar results. > In my case, I have a mostly-bad SCSI disk that doesn't work until it is > sufficiently warmed up. When booting, one of the SCSI commands sent to > the drive (mode sense, I think) fails, and the kernel panics. Hmm, that's likely a different problem. The mode sense happens early in the boot process, right after the inquiry. > Basically, the SCSI bus recognizes some thing is there, but can't even > read the vendor string from the disk. "Device connected, but has a fault." A stack trace, and the boot messages would be helpful if you have the time. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 22:49:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from picalon.gun.de (picalon.gun.de [194.77.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 6FA6814D46 for ; Wed, 30 Jun 1999 22:49:53 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.8.6/8.8.6) with ESMTP id HAA08253; Thu, 1 Jul 1999 07:49:48 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id HAA19632; Thu, 1 Jul 1999 07:49:34 +0200 (CEST) (envelope-from andreas) Date: Thu, 1 Jul 1999 07:49:34 +0200 From: Andreas Klemm To: Tom Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: fsck and dirty file systems Message-ID: <19990701074934.A19363@titan.klemm.gtn.com> References: <3778E366.54EBF7C9@thedial.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Tom on Tue, Jun 29, 1999 at 07:00:23AM -0700 X-Operating-System: FreeBSD 3.2-STABLE SMP X-Disclaimer: A free society is one where it is safe to be unpopular Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 29, 1999 at 07:00:23AM -0700, Tom wrote: > > On Tue, 29 Jun 1999, Christopher Taylor wrote: > > > The files systems this is happening on have all been mounted....I guess that > > explains it...would you venture an explaination? ;) > > Mounted filesystems are always dirty by definition. I wouldn't even try > to fsck a mounted filesystem. fsck's manpage is missing a statement, that fsck should only be used on unmounted filesystems. One could elaborate on this a little bit more, for example: This prerequisite is met during startup, where the root filesystem is mounted read only (to fire up fsck) and where all other filesystems are unmounted. If think you need to check your filesystems, then a) reboot b) reboot and boot into single user mode c) go into single user mode using the shutdown(8) utility and unmount all filesystems you want to check If you need to check the root filesystem, then you have to reboot and boot into single user mode (by using the -s flag), since a root filesystem, that has been mounted r/w (which happens for example when entering multi user mode), can't me remounted read only. Not 100% sure about the last statement, but something like this is really missing. -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Latest song from our band: http://www.freebsd.org/~andreas/mp3/schaukel.mp3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 30 23:13:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CF7EF14CA4 for ; Wed, 30 Jun 1999 23:13:38 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id AAA40208; Thu, 1 Jul 1999 00:13:32 -0600 (MDT) (envelope-from ken) Message-Id: <199907010613.AAA40208@panzer.kdm.org> Subject: Re: Are SIIG SCSI Cards Supported? In-Reply-To: <199906301220.CAA18398@kauai.pacificglobal.net> from David Langford at "Jun 30, 1999 02:20:49 am" To: langfod@maui.net (David Langford) Date: Thu, 1 Jul 1999 00:13:32 -0600 (MDT) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Langford wrote... > Okay I just tried it with current and it seems to work fine. > Note that you need to add > "COMPAT_PCI_DRIVER(iha, i91u_device);" > somewhere around line 133 of i91u.c. > > Right now my system is running off of a SIIG AP-40 (~$140) and all seems > fine. > Also I have a IWILL SIDE-2935UW that at first glance seems to work with > this same driver. > I havent had a chance to do any real testing with either one though. > > Now if we can just get this driver into the main tree. There are actually two Initio drivers, one for their Ultra-2 boards, and one for their Ultra boards. There are several things that have to happen before these drivers can go in the tree: 1. We (Justin or me) need to talk to Initio about incorporating their driver into the tree. 2. We need clarificaton on the copyright on the I9xxx driver. One file has a standard BSD copyright, one file has a copyright that doesn't explicitly allow redistribution, and one file has no copyright at all. The A100 driver has a BSD copyright on both files. My guess is that the copyright difference on the I9xxx driver is just an oversight. 3. Justin needs to review the driver. > Since it looks likes Adaptec has pretty much killed the Sysmbios/NCR > chipset the Initio line may be the next reasonable cost SCSI controller... As someone else pointed out, the Symbios cards are not dead. Symbios is now a part of LSI Logic, but as far as I know, they aren't going to discontinue making products. They're probably the second most successful SCSI chip vendor on the market, so they have little reason to quit. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 0:54:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from opi.flirtbox.ch (unknown [62.48.0.50]) by hub.freebsd.org (Postfix) with SMTP id 99031152C7 for ; Thu, 1 Jul 1999 00:54:13 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 640 invoked from network); 1 Jul 1999 07:54:11 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.128.41]) (envelope-sender ) by opi.flirtbox.ch (qmail-ldap-1.03) with SMTP for ; 1 Jul 1999 07:54:11 -0000 Message-ID: <377B1E99.46188B0C@pipeline.ch> Date: Thu, 01 Jul 1999 09:54:01 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: ncr0: queue is empty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I got this messages today on the screen on my yesterday's 4.0-current box: ncr0: queue empty The only way to get it back was to hit reset. Is this a known problem? If you need more information I'll provide it, just tell me what you need to know. Please CC me as I'm not on SCSI. THX -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 1:31: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from maui.net (maui.net [207.175.210.2]) by hub.freebsd.org (Postfix) with ESMTP id 8346A14CB4 for ; Thu, 1 Jul 1999 01:30:54 -0700 (PDT) (envelope-from langfod@kauai.pacificglobal.net) Received: from kauai.pacificglobal.net (Kauai.PacificGlobal.NET [209.84.182.101]) by maui.net (8.8.7/8.8.5) with ESMTP id WAA19222; Wed, 30 Jun 1999 22:30:51 -1000 (HST) Received: (from langfod@localhost) by kauai.pacificglobal.net (8.8.8/8.8.5) id WAA12097; Wed, 30 Jun 1999 22:30:50 -1000 (HST) From: David Langford Message-Id: <199907010830.WAA12097@kauai.pacificglobal.net> Subject: Re: Are SIIG SCSI Cards Supported? In-Reply-To: from Gerard Roudier at "Jun 30, 1999 11:50:28 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Wed, 30 Jun 1999 22:30:49 -1000 (HST) Cc: langfod@maui.net, scsi@FreeBSD.ORG X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It seems to me that the FreeBSD-CAM method has killed most of the SCSI >drivers in FreeBSD except the aic7xxx one. >The killed drivers have now to resurrect. > >Adaptec perhaps sells more SCSI controllers than SYMBIOS, but SYMBIOS has >up-to-date products and seems quite alive on the SCSI market place. > >If you base your opinion, on the number of problem reports, then you may >wronly beleive that Adaptec owns the whole market of SCSI controllers. >;-) > >If one applies the same on the O/S place, they one also may wrongly >beleive that FreeBSD has never existed. ;-) >Note that this would make it quite immune of being ever killed. ;-) >Gérard. Well I just found the first piece that made one of my assumptions. I hadnt realized that Adaptec had NOT actually bought Symbios last year like I had thought- silly me for not keepign up with the press realases while that appeared when I was out of the country :) It _seems_ like there are fewer and fewer OEM Symbios based cards and even the vendors that used them in the past have been switching to the Advansys and now the Initio chipsets in the lower price point markets. It even seems like the Qlogic based boards in this market are fairly hard to find. I happen to work in the higher end server field and I do see more and more Symbios and Qlogic based boards all the time, but I just havent seem to have heard much in the crazy PC world as much... Oh, BTW- don't get me wrong I am actually quite an Adaptec fan, just getting cheap :) -David Langford langfod@dihelix.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 10:45:25 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 C9EB414DE1 for ; Thu, 1 Jul 1999 10:45:13 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA43357; Thu, 1 Jul 1999 11:44:50 -0600 (MDT) (envelope-from ken) Message-Id: <199907011744.LAA43357@panzer.kdm.org> Subject: Re: Are SIIG SCSI Cards Supported? In-Reply-To: <199907010830.WAA12097@kauai.pacificglobal.net> from David Langford at "Jun 30, 1999 10:30:49 pm" To: langfod@maui.net (David Langford) Date: Thu, 1 Jul 1999 11:44:49 -0600 (MDT) Cc: groudier@club-internet.fr (Gerard Roudier), 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 [ I don't know whether the mail from Gerard Roudier was private or not, I didn't see it on the -scsi list... ] David Langford wrote... > >It seems to me that the FreeBSD-CAM method has killed most of the SCSI > >drivers in FreeBSD except the aic7xxx one. > >The killed drivers have now to resurrect. I don't think I would characterize it quite like that. These are the controllers that were supported before that are no longer supported: - Adaptec AIC 6360/6260 (aic) - Seagate ST01, Future domain 8xx/950 (sea) - Ultrastor controllers (uha) - WD7000 (wds) - Pro Audio Spectrum (nca) (NCR5380/NCR53400) We still support the following controllers that were supported under the old SCSI layer: - Adaptec 7xxx (ahc) (more Adaptec controllers are supported now than under the old SCSI layer) - Adaptec 154x (aha) - Adaptec 174x (ahb) - Symbios 53c8xx (ncr) - QLogic (isp) - DPT SmartRAID/CACHE III and IV (dpt) - AMD 53c974 (amd) - BusLogic Multimaster (bt) - NEC PC98 SCSI controller (bs) (I don't know the actual part or board name) - Iomega parallel port zip drives (vpo) We also support some new boards and drivers: - Advansys boards (adv) - Advansys wide boards (adw) - USB Mass storage controllers (umass) And then there are the two new Initio drivers that will probably get into the tree at some point. Of the controllers that are now unsupported, the only one people really seem to care about is the Adaptec 6360 (aic) driver. There was someone working on it, but we haven't seen anything yet. Lately some folks have made some noise about the ST01 driver, and who knows, something may come of it. Warner Losh has talked about doing the Ultrastor driver, but he's got lots of other more important stuff on his plate at the moment. So I think that overall, we're doing pretty well in the driver department. And, as Justin and I have explained before, the CAM integration probably never would have happened if we hadn't given up support for a few cards. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 11:48:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 31EBE15035 for ; Thu, 1 Jul 1999 11:48:05 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA85021; Thu, 1 Jul 1999 13:48:00 -0500 (CDT) From: Joe Greco Message-Id: <199907011848.NAA85021@aurora.sol.net> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907010410.WAA39523@panzer.kdm.org> from "Kenneth D. Merry" at "Jun 30, 1999 10:10:43 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Thu, 1 Jul 1999 13:47:59 -0500 (CDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > There are several questions I have, which I hope can be answered with some > diagnostic patches I've appended. >=20 > 1. Why does the da1 announcement just print 'A' and not the rest of the > line? >=20 > 2. Why does the camcontrol read capacity output indicate that the Mylex > array is not ready, yet an open immediately after that seems to pass > the read capacity by just fine? If you're talking about when I do the camcontrol after waiting a bit - it is because the Mylex has completed its startup routine. Remember, all of this is only happening when the Mylex has not yet finished its startup procedure, which can happen in the events: 1) Things are OK but it just isn't done yet. This is a rare case, the system just boots too slow with the RAM test and the 15-second boot prompt. If I ESC the RAM test and hit return to boot right away, from a cold power on, then I can get the crash. 2) Things are not OK; i.e. the RAID is damaged or offline. This is the case where I actually first noticed the behaviour. > 3. Assuming the read capacity is returned without an error, why does the > Mylex return a bogus sector size at least? (indicated by your > diagnostic output from the slice code above) >=20 > Hopefully I can at least get a clue to the answers for 1 and 2 with the > patches appended. >=20 > So, Joe, could you: >=20 > - apply Bruce's patch (so you won't panic), or just keep the one you've g= ot Kept mine. > - apply the attached patch to scsi_da.c Done. > - boot with -v (boot kernel -v at the loader prompt) > - send the output from the boot Whoa... okay. Well, I just modified the kernel. The same things apply that were being done; i.e. .profile does a camcontrol and then tries to do a fsck -p. Lots of output. I'm including it all since I don't know what is really significant. ~~ Hit [Enter] to boot immediately, or any other key for command prompt. =0DBooting [kernel] in 14 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. disk1s1a:> boot -s -v=08 =08=08 =08=08 =08=08 =08v -s /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08/kernel = text=3D0x10e9fc |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08dat= a=3D0x16124+0x1de98 |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08syms=3D= [0x4+0x1de20|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08+0x= 4+0x20077\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08] 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.1-RELEASE #4: Thu Jul 1 13:29:19 CDT 1999 root@spool0.newsops.execpc.com:/usr/src/sys/compile/SPOOL-DDB Calibrating clock(s) ... TSC clock: 400900364 Hz, i8254 clock: 1193156 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x652 Stepping=3D2 Features=3D0x183fbff> real memory =3D 536870912 (524288K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00293000 - 0x1ffdffff, 534040576 bytes (130381 pages) avail memory =3D 519999488 (507812K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Found BIOS32 Service Directory header at 0xf00f9d20 Entry =3D 0xf0530 (0xf00f0530) Rev =3D 0 Len =3D 1 PCI BIOS entry at 0x730 DMI header at 0xf00f59c0 Version 2.0 Table at 0xf59da, 32 entries, 1050 bytes Other BIOS signatures found: ACPI: 00000000 $PnP: 000fd150 Preloaded elf kernel "kernel" at 0xf0283000. Math emulator present SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff pci_open(1): mode 1 addr port (0x0cf8) is 0x8000005c pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D71908086) Probing for devices on PCI bus 0: found-> vendor=3D0x8086, dev=3D0x7190, revid=3D0x03 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 map[0]: type 3, range 32, base e4000000, size 26 chip0: rev 0x03 on pci0.0.0 found-> vendor=3D0x8086, dev=3D0x7191, revid=3D0x03 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 subordinatebus=3D1 secondarybus=3D1 chip1: rev 0x03 on pci0.1.0 found-> vendor=3D0x8086, dev=3D0x7110, revid=3D0x02 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 subordinatebus=3D0 secondarybus=3D0 chip2: rev 0x02 on pci0.4.0 found-> vendor=3D0x8086, dev=3D0x7111, revid=3D0x01 class=3D01-01-80, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 map[0]: type 4, range 32, base 0000d800, size 4 Freeing (NOT implemented) redirected ISA irq 10. found-> vendor=3D0x8086, dev=3D0x7112, revid=3D0x01 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 intpin=3Dd, irq=3D19 map[0]: type 4, range 32, base 0000d400, size 5 found-> vendor=3D0x8086, dev=3D0x7113, revid=3D0x02 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 chip3: rev 0x02 on pci0.4.3 Freeing (NOT implemented) redirected ISA irq 10. found-> vendor=3D0x9005, dev=3D0x001f, revid=3D0x00 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 intpin=3Da, irq=3D19 map[0]: type 4, range 32, base 0000d000, size 8 map[1]: type 1, range 64, base e3000000, size 12 map[2]: type 0, range 0, base 00000000, size 0 ahc0: rev 0x00 int a irq 19 on pci= 0.6.0 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: aic7890/91 Wide Channel A, SCSI Id=3D7, 16/255 SCBs ahc0: Downloading Sequencer Program... 392 instructions downloaded found-> vendor=3D0x1011, dev=3D0x0024, revid=3D0x03 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 subordinatebus=3D2 secondarybus=3D2 chip4: rev 0x03 on pci0.1= 0.0 Probing for devices on PCI bus 1: Probing for devices on PCI bus 2: Freeing (NOT implemented) redirected ISA irq 11. found-> vendor=3D0x1011, dev=3D0x0009, revid=3D0x22 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 intpin=3Da, irq=3D18 map[0]: type 4, range 32, base 0000b800, size 7 map[1]: type 1, range 32, base e2800000, size 7 de0: rev 0x22 int a irq 18 on pci2.4.0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de0: address 00:e0:29:2b:e1:08 bpf: de0 attached Freeing (NOT implemented) redirected ISA irq 10. found-> vendor=3D0x1011, dev=3D0x0009, revid=3D0x22 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 subordinatebus=3D0 secondarybus=3D0 intpin=3Da, irq=3D19 map[0]: type 4, range 32, base 0000b400, size 7 map[1]: type 1, range 32, base e2000000, size 7 de1: rev 0x22 int a irq 19 on pci2.5.0 using shared irq19. de1: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de1: address 00:e0:29:2b:e1:09 bpf: de1 attached Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <16 virtual consoles, flags=3D0x0> ed0 not found at 0x280 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x10000, flags:0x3d0000 psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. psm0 not found sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: configured irq 5 not in bitmap of probed irqs 0 sio2: irq maps: 0x1 0x1 0x1 0x1 sio2: probe failed test(s): 0 1 2 4 6 7 9 sio2 not found at 0x3e8 sio3: configured irq 9 not in bitmap of probed irqs 0 sio3: irq maps: 0x1 0x1 0x1 0x1 sio3: probe failed test(s): 0 1 2 4 6 7 9 sio3 not found at 0x2e8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc: parallel port found at 0x378 ppc0: ECP SPP ECP+EPP SPP ppc0 at 0x378 irq 7 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip: irq 7 plip0: on ppbus 0 bpf: lp0 attached vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. we0 at 0x2e8 on isa we0: kernel is keeping watchdog alive imasks: bio c8000040, tty c70c009a, net c70c009a SMP: enabled INTs: 1, 3, 4, 6, 7, 18, 19, apic_imen: 0x00f3ff25 BIOS Geometries: 0:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 1:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 2:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 3:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 4:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 5:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 6:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 7:00000000 0..0=3D1 cylinders, 0..0=3D1 heads, 1..0=3D0 sectors 0 accounted for Device configuration finished. APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert disabled, rule-based forwarding dis= abled, logging limited to 100 packets/entry bpf: tun0 attached bpf: sl0 attached bpf: ppp0 attached new masks: bio c8000040, tty c70c009a, net c70c009a bpf: lo0 attached Waiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff de1: enabling 100baseTX port ahc0: Selection Timeout on A:2. 1 SCBs aborted ahc0: Selection Timeout on A:3. 1 SCBs aborted ahc0: Selection Timeout on A:4. 1 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted ahc0: Selection Timeout on A:6. 1 SCBs aborted ahc0: Selection Timeout on A:8. 1 SCBs aborted ahc0: Selection Timeout on A:9. 1 SCBs aborted ahc0: Selection Timeout on A:10. 1 SCBs aborted ahc0: Selection Timeout on A:11. 1 SCBs aborted ahc0: Selection Timeout on A:12. 1 SCBs aborted ahc0: Selection Timeout on A:13. 1 SCBs aborted ahc0: Selection Timeout on A:14. 1 SCBs aborted ahc0: Selection Timeout on A:15. 1 SCBs aborted (probe1:ahc0:0:1:0): MODE SENSE(06). CDB: 1a 0 a 0 14 0=20 (probe1:ahc0:0:1:0): NOT READY (probe1:ahc0:0:1:0): INQUIRY. CDB: 12 1 80 0 ff 0=20 (probe1:ahc0:0:1:0): ILLEGAL REQUEST asc:24,0 (probe1:ahc0:0:1:0): Invalid field in CDB ahc0: target 0 using 16bit transfers ahc0: target 0 synchronous at 20.0MHz, offset =3D 0xf ahc0: target 1 using 16bit transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device=20 pass0: Serial Number HD0439370E0ZET pass0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enab= led pass1 at ahc0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device=20 pass1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enab= led Considahc0: target 1 using asynchronous transfers ering FFS ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ro(da0:ahc0:0:0:0): about to print announcement da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: Serial Number HD0439370E0ZET da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) (da0:ahc0:0:0:0): printed announcement ot f/s. ahc0: target 1 using asynchronous transfers changingahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 root device toahc0: target 1 using asynchronous transfers da0s1a ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 (da1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da1:ahc0:0:1:0): NOT READY (da1:ahc0:0:1:0): about to print announcement da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device=20 da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: A (da1:ahc0:0:1:0): printed announcement (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 da0s1: type 0xa5, start 63, end =3D 8482319, size 8482257 : OK Enter full pathname of shell or RETURN for /bin/sh: de0: autosense failed: = cable problem? erase ^H, kill ^U, intr ^C /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 camcontrol: error sending command (pass1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (pass1:ahc0:0:1:0(): NOT READY endd of camcontrol=0Da 0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1a: FILESYSTEM CLEpp=00=00/dev/rda0s1=00=00=00=0Cp=0C=00=008=0C= =00=1F|=00=07=00=00=00=03=00=00v=00=00: 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 (da0:ahc0:ahc0: target 1 using asynchronous transfers 0:0:0): reahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ad capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da1:ahc0:0:1:0): NOT READY (da1:ahc0:0:1:0): read capacity returned 0 (da1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da1:ahc0:0:1:0): NOT READY (da1:ahc0:0:1:0): address =3D -523733007, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1h: (FILESYSTEM CLEANd; SKIPPING CHECKaS /dev/rda0s1h: 0clean, 232315 fr:ee (131 frags, 2a9023 blocks, 0.1h% fragmen= tation)c 0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1e: (FILESYSTEM CLEANd; SKIPPING CHECKaS /dev/rda0s1e: 0clean, 51019 fre:e (8139 frags, 5a360 blocks, 4.1%h fragment= ation)=0Dc 0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: ahc0: target 1 using asynchronous tra= nsfers 25 0 0 0 0ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1f: (FILESYSTEM CLEANd; SKIPPING CHECKaS 0/dev/rda0s1f: :clean, 112455 fraee (239 frags, 1h4027 blocks, 0.2c% fragme= ntation)0 :0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rda0s1g: clean, 1308409 free (313 frags, 163512 blocks, 0.0% fragmenta= ti|=00c0:get 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 20.0MHz, offset =3D 0x10 (da1:ahc0:0:1:0): READ(06). CDB: 8 0 0 0 1 0=20 (da1:ahc0:0:1:0): NOT READY da1: error reading primary partition table reading fsbn 0 Can't open /dev/rda1s1e: Input/output error /dev/rda1s1e: CAN'T CHECK FILE SYSTEM. /dev/rda1s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: /dev/rda1s1e (/news) #=20 That's it. Let me know if you need more. ... Joe ---------------------------------------------------------------------------= ---- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 12: 5: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0FFF414A14 for ; Thu, 1 Jul 1999 12:05:04 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id MAA80497; Thu, 1 Jul 1999 12:01:44 -0700 (PDT) Date: Thu, 1 Jul 1999 12:01:44 -0700 (PDT) From: Julian Elischer To: Joe Greco Cc: "Kenneth D. Merry" , scsi@FreeBSD.ORG Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907011848.NAA85021@aurora.sol.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 Thu, 1 Jul 1999, Joe Greco wrote: > > > > - apply Bruce's patch (so you won't panic), or just keep the one you've got > > Kept mine. One assumes one of these two patches will be applied to the tree some time? julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 12: 9:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id C399C15258 for ; Thu, 1 Jul 1999 12:09:35 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA86533; Thu, 1 Jul 1999 14:09:26 -0500 (CDT) From: Joe Greco Message-Id: <199907011909.OAA86533@aurora.sol.net> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: from Julian Elischer at "Jul 1, 1999 12: 1:44 pm" To: julian@whistle.com (Julian Elischer) Date: Thu, 1 Jul 1999 14:09:26 -0500 (CDT) Cc: scsi@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 > On Thu, 1 Jul 1999, Joe Greco wrote: > > > > > > - apply Bruce's patch (so you won't panic), or just keep the one you've got > > > > Kept mine. > > One assumes one of these two patches will be applied to the tree some > time? Mine is almost certainly completely wrong and of limited usefulness. I would hope that somebody who actually understands the architecture of the I/O system would take a minute or two to ponder more appropriate placement. I just patched it at the point it was actually about to crash. If someone would like me to verify that Bruce's patch works before committing it, I'll be happy to do so... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 12:55:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 15E13155EB for ; Thu, 1 Jul 1999 12:55:36 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA44126; Thu, 1 Jul 1999 13:54:18 -0600 (MDT) (envelope-from ken) Message-Id: <199907011954.NAA44126@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907011848.NAA85021@aurora.sol.net> from Joe Greco at "Jul 1, 1999 01:47:59 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Thu, 1 Jul 1999 13:54:18 -0600 (MDT) Cc: scsi@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM930858858-44026-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM930858858-44026-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Joe Greco wrote... > > There are several questions I have, which I hope can be answered with some > > diagnostic patches I've appended. > > > > 1. Why does the da1 announcement just print 'A' and not the rest of the > > line? > > > > 2. Why does the camcontrol read capacity output indicate that the Mylex > > array is not ready, yet an open immediately after that seems to pass > > the read capacity by just fine? > > If you're talking about when I do the camcontrol after waiting a bit - > it is because the Mylex has completed its startup routine. Remember, all > of this is only happening when the Mylex has not yet finished its startup > procedure, which can happen in the events: > > 1) Things are OK but it just isn't done yet. This is a rare case, the > system just boots too slow with the RAM test and the 15-second boot > prompt. If I ESC the RAM test and hit return to boot right away, > from a cold power on, then I can get the crash. > > 2) Things are not OK; i.e. the RAID is damaged or offline. This is the > case where I actually first noticed the behaviour. > > > 3. Assuming the read capacity is returned without an error, why does the > > Mylex return a bogus sector size at least? (indicated by your > > diagnostic output from the slice code above) > > > > Hopefully I can at least get a clue to the answers for 1 and 2 with the > > patches appended. > > > > So, Joe, could you: > > > > - apply Bruce's patch (so you won't panic), or just keep the one you've got > > Kept mine. > > > - apply the attached patch to scsi_da.c > > Done. > > > - boot with -v (boot kernel -v at the loader prompt) > > - send the output from the boot > > Whoa... okay. Well, I just modified the kernel. The same things apply > that were being done; i.e. .profile does a camcontrol and then tries to do a > fsck -p. Lots of output. I'm including it all since I don't know what is > really significant. [ ... ] > That's it. Let me know if you need more. Thanks for all the work on this! I talked to Justin for a minute, and I think we've figured out what the problem is. It's a little more complicated than this, but the simple explanation is that we aren't doing the right thing when a command comes back with just a sense key and no ASC or ASCQ. It's hard to believe we haven't run into this before, but I think that's the problem. Try applying the attached patch to scsi_all.c. It isn't the final patch for this problem, the solution is probably a little more complicated than this. But hopefully this will let us know whether the problem is what we think it is. You should be able to boot okay with this patch, although you probably won't be able to fsck or mount the Mylex array until it's ready to run. Ken -- Kenneth Merry ken@plutotech.com --ELM930858858-44026-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=scsi_all.c.070199 Content-Description: scsi_all.c.070199 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_all.c#59 - /a/ken/perforce/cam/sys/cam/scsi/scsi_all.c ==== *** /tmp/tmp.25512.0 Thu Jul 1 13:46:02 1999 --- /a/ken/perforce/cam/sys/cam/scsi/scsi_all.c Thu Jul 1 13:44:37 1999 *************** *** 765,771 **** * . . . . E - ENCLOSURE SERVICES DEVICE (SES) * DTLPWRSOMCAE ASC ASCQ Action Description * ------------ ---- ---- ------ -----------------------------------*/ ! /* DTLPWRSOMCAE */{SST(0x00, 0x00, SS_NEPDEF, "No additional sense information") }, /* T S */{SST(0x00, 0x01, SS_DEF, "Filemark detected") }, --- 765,771 ---- * . . . . E - ENCLOSURE SERVICES DEVICE (SES) * DTLPWRSOMCAE ASC ASCQ Action Description * ------------ ---- ---- ------ -----------------------------------*/ ! /* DTLPWRSOMCAE */{SST(0x00, 0x00, SS_DEF, "No additional sense information") }, /* T S */{SST(0x00, 0x01, SS_DEF, "Filemark detected") }, --ELM930858858-44026-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jul 1 15:48:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id 629F8158C5; Thu, 1 Jul 1999 15:48:40 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id AAA00796; Fri, 2 Jul 1999 00:35:18 +0200 (CEST) (envelope-from se) Date: Fri, 2 Jul 1999 00:35:18 +0200 From: Stefan Esser To: Andre Oppermann Cc: freebsd-scsi@FreeBSD.org, Stefan Esser Subject: Re: ncr0: queue is empty Message-ID: <19990702003518.B468@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.org References: <377B1E99.46188B0C@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <377B1E99.46188B0C@pipeline.ch>; from Andre Oppermann on Thu, Jul 01, 1999 at 09:54:01AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-07-01 09:54 +0200, Andre Oppermann wrote: > Hi > > I got this messages today on the screen on my yesterday's 4.0-current > box: > > ncr0: queue empty > > The only way to get it back was to hit reset. > > Is this a known problem? > > If you need more information I'll provide it, just tell me what you > need to know. > > Please CC me as I'm not on SCSI. Hi Andre! Sorry, this is not a known problem. Could you offer more details ? Are there any other error messages in the logs ? What NCR chip is on that SCSI card ? Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 1:27: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from opi.flirtbox.ch (unknown [62.48.0.50]) by hub.freebsd.org (Postfix) with SMTP id 1D08B14E36 for ; Fri, 2 Jul 1999 01:26:53 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 11145 invoked from network); 2 Jul 1999 08:26:52 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.128.41]) (envelope-sender ) by opi.flirtbox.ch (qmail-ldap-1.03) with SMTP for ; 2 Jul 1999 08:26:52 -0000 Message-ID: <377C77C1.4F8ACEE1@pipeline.ch> Date: Fri, 02 Jul 1999 10:26:41 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: se@FreeBSD.org Cc: freebsd-scsi@FreeBSD.org Subject: Re: ncr0: queue is empty References: <377B1E99.46188B0C@pipeline.ch> <19990702003518.B468@dialup124.mi.uni-koeln.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser wrote: > > On 1999-07-01 09:54 +0200, Andre Oppermann wrote: > > Hi > > > > I got this messages today on the screen on my yesterday's 4.0-current > > box: > > > > ncr0: queue empty > > > > The only way to get it back was to hit reset. > > > > Is this a known problem? > > > > If you need more information I'll provide it, just tell me what you > > need to know. > > > > Please CC me as I'm not on SCSI. > > Hi Andre! > > Sorry, this is not a known problem. Could you offer more details ? opi# uname -a FreeBSD opi.flirtbox.ch 4.0-CURRENT FreeBSD 4.0-CURRENT #14: Wed Jun 30 10:06:02 CEST 1999 opi@opi.flirtbox.ch:/usr/src/sys/compile/opi i386 opi# uptime 10:08AM up 1 day, 25 mins, 2 users, load averages: 0.03, 0.01, 0.00 > Are there any other error messages in the logs ? There is *nothing* in the logs, it wasn't able to write anything to the disk. However the box didn't lock up, I got a login prompt via telnet but was not able to log in. Since yesterday it has been stable and I didn't change anything. As a side note: This box runs qmail as an mail realy. Sometimes it beats the disk pretty hard. > What NCR chip is on that SCSI card ? from dmesg: CPU: Pentium/P54C (132.63-MHz 586-class CPU) ... ncr0: irq 10 at device 10.0 on pci0 ... Waiting 15 seconds for SCSI devices to settle da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C) changing root device to da0s1a cd0 at ncr0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ncr0 bus 0 target 4 lun 1 cd1: Removable CD-ROM SCSI-2 device cd1: 5.000MB/s transfers (5.000MHz, offset 8) cd1: Attempt to query device size failed: NOT READY, Medium not present da1 at ncr0 bus 0 target 4 lun 0 da1: Removable Optical SCSI-2 device da1: 5.000MB/s transfers (5.000MHz, offset 8) da1: Attempt to query device size failed: NOT READY, Medium not present WARNING: / was not properly dismounted opi# camcontrol devlist -v scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) scbus0 on ncr0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 2 lun 0 (pass1,cd0) at scbus0 target 4 lun 0 (pass2,da1) at scbus0 target 4 lun 1 (pass3,cd1) < > at scbus0 target -1 lun -1 () opi# grep Id ncr.c ** $Id: ncr.c,v 1.149 1999/06/15 13:14:56 des Exp $ /usr/src/sys/i386/conf/opi: controller ncr0 controller scbus0 device da0 #Only need one of these, the code dynamically grows device sa0 device pass0 device cd0 Do you need more information? What can I do? Thanks! -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 2:34:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from opi.flirtbox.ch (unknown [62.48.0.50]) by hub.freebsd.org (Postfix) with SMTP id 8159114C04 for ; Fri, 2 Jul 1999 02:34:41 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 276 invoked from network); 2 Jul 1999 09:34:39 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.128.41]) (envelope-sender ) by opi.flirtbox.ch (qmail-ldap-1.03) with SMTP for ; 2 Jul 1999 09:34:39 -0000 Message-ID: <377C87A5.A048A3E4@pipeline.ch> Date: Fri, 02 Jul 1999 11:34:29 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: se@FreeBSD.org Cc: freebsd-scsi@FreeBSD.org Subject: Re: ncr0: queue is empty References: <377B1E99.46188B0C@pipeline.ch> <19990702003518.B468@dialup124.mi.uni-koeln.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser wrote: > > On 1999-07-01 09:54 +0200, Andre Oppermann wrote: > > Hi > > > > I got this messages today on the screen on my yesterday's 4.0-current > > box: > > > > ncr0: queue empty > > > > The only way to get it back was to hit reset. > > > > Is this a known problem? > > > > If you need more information I'll provide it, just tell me what you > > need to know. > > > > Please CC me as I'm not on SCSI. > > Hi Andre! > > Sorry, this is not a known problem. Could you offer more details ? > Are there any other error messages in the logs ? > > What NCR chip is on that SCSI card ? Ugh! It bite me just again! ncr0: queue emtpy. I don't get a panic or so, just that message repeating over and over again. Before it was running -current from April 12 rock solid. Does it help if I make a kernel with CAMDEBUG? -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 9:47: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 0F5C514EB6 for ; Fri, 2 Jul 1999 09:46:59 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id LAA77311; Fri, 2 Jul 1999 11:46:41 -0500 (CDT) From: Joe Greco Message-Id: <199907021646.LAA77311@aurora.sol.net> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907011954.NAA44126@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 1, 1999 1:54:18 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 2 Jul 1999 11:46:41 -0500 (CDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Thanks for all the work on this! I talked to Justin for a minute, and I > think we've figured out what the problem is. >=20 > It's a little more complicated than this, but the simple explanation is > that we aren't doing the right thing when a command comes back with just a > sense key and no ASC or ASCQ. It's hard to believe we haven't run into > this before, but I think that's the problem. >=20 > Try applying the attached patch to scsi_all.c. It isn't the final patch > for this problem, the solution is probably a little more complicated than > this. But hopefully this will let us know whether the problem is what we > think it is. ~ Hit [Enter] to boot immediately, or any other key for command prompt. =0DBooting [kernel] in 14 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. disk1s1a:> boot -s /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08/kernel = text=3D0x10e9fc |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-= =08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\= =08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08dat= a=3D0x16124+0x1de98 |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08syms=3D= [0x4+0x1de20|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08+0x= 4+0x20077\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08] 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.1-RELEASE #5: Fri Jul 2 11:37:31 CDT 1999 root@:/usr/src/sys/compile/SPOOL-DDB Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x652 Stepping=3D2 Features=3D0x183fbff> real memory =3D 536870912 (524288K bytes) avail memory =3D 519999488 (507812K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xf0283000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci= 0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=3D7, 16/255 SCBs chip4: rev 0x03 on pci0.1= 0.0 Probing for devices on PCI bus 1: Probing for devices on PCI bus 2: de0: rev 0x22 int a irq 18 on pci2.4.0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de0: address 00:e0:29:2b:e1:08 de1: rev 0x22 int a irq 19 on pci2.5.0 de1: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de1: address 00:e0:29:2b:e1:09 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=3D0x0> ed0 not found at 0x280 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 sio2: configured irq 5 not in bitmap of probed irqs 0 sio2 not found at 0x3e8 sio3: configured irq 9 not in bitmap of probed irqs 0 sio3 not found at 0x2e8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface we0 at 0x2e8 on isa we0: kernel is keeping watchdog alive APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert disabled, rule-based forwarding dis= abled, logging limited to 100 packets/entry Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! de1: enabling 100baseTX port changing root device t(da0:ahc0:0:0:0): about to print announcement da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) (da0:ahc0:0:0:0): printed announcement o da0s1a (da0:ahc0:0:0:0): read capacity returned 0 (da1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da1:ahc0:0:1:0): NOT READY (da1:ahc0:0:1:0): fatal error, failed to attach to device (da1:ahc0:0:1:0): lost device (da1:ahc0:0:1:0): about to print announcement (da1:ahc0:0:1:0): printed announcement (da1:ahc0:0:1:0): removing device entry (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 Enter full pathname of shell or RETURN for /bin/sh:=20 erase ^H, kill ^U, intr ^C /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lo(okup_pdass: either the apass driver isn'0t in your kernel: cam_lookup_pasas: or da1 doesn'ht exist end of ccamcontrol 0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1a: (FILESYSTEM CLEANd; SKIPPING CHECKaS /dev/rda0s1a: 0clean, 127240 fr:ee (296 frags, 1a5868 blocks, 0.2h% fragmen= tation)c Can't open /de0v/rda1s1e: Devic:e not configured0 /dev/rda1s1e: :CAN'T CHECK FILE0 SYSTEM. /dev/r:da1s1e: UNEXPECT0ED INCONSISTENCY); RUN fsck MANUA:LLY. read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1h: (FILESYSTEM CLEANd; SKIPPING CHECKaS 0/dev/rda0s1h: :clean, 232315 fraee (131 frags, 2h9023 blocks, 0.1c% fragme= ntation)0 :0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1e: (FILESYSTEM CLEANd; SKIPPING CHECKaS 0/dev/rda0s1e: :clean, 51019 freae (8139 frags, 5d360 blocks, 4.1%e fragmen= tation)=0D0 : autosense failed: cable problem? hc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1f: (FILESYSTEM CLEANd; SKIPPING CHECKaS /dev/rda0s1f: 0clean, 112455 fr:ee (239 frags, 1a4027 blocks, 0.2h% fragmen= tation)c 0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 (da0:ahc0:0:0:0): read capacity returned 0 (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (da0:ahc0:0:0:0): NOT READY (da0:ahc0:0:0:0): address =3D 8496883, length =3D 512 /dev/rda0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rda0s1g: clean, 1308429 free (309 frags, 163515 blocks, 0.0% fragmenta= tion) THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: /dev/rda1s1e (/news) #=20 I take it the "fatal error, failed to attach to device" is what you were trying for? > You should be able to boot okay with this patch, although you probably > won't be able to fsck or mount the Mylex array until it's ready to run. I would expect that. If you have an elegant (or correct) solution to deal with this - for me, at least, preferably from userland - I'm all ears. What I'm thinking is just sitting there querying the thing every few seconds until it reports a size, then have CAM re-query the device. Does that seem reasonable? I'm actually not interested in a solution more complex than that because in the event the RAID fails, it does the same sort of thing, and I'd like to be able to get into the machine from remote and talk to the Mylex. ... Joe ---------------------------------------------------------------------------= ---- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 10:32:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4DA6D1562C for ; Fri, 2 Jul 1999 10:32:24 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA51596; Fri, 2 Jul 1999 11:31:00 -0600 (MDT) (envelope-from ken) Message-Id: <199907021731.LAA51596@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907021646.LAA77311@aurora.sol.net> from Joe Greco at "Jul 2, 1999 11:46:41 am" To: jgreco@ns.sol.net (Joe Greco) Date: Fri, 2 Jul 1999 11:31:00 -0600 (MDT) Cc: scsi@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM930936660-51339-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM930936660-51339-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Joe Greco wrote... > > Thanks for all the work on this! I talked to Justin for a minute, and I > > think we've figured out what the problem is. > > > > It's a little more complicated than this, but the simple explanation is > > that we aren't doing the right thing when a command comes back with just a > > sense key and no ASC or ASCQ. It's hard to believe we haven't run into > > this before, but I think that's the problem. > > > > Try applying the attached patch to scsi_all.c. It isn't the final patch > > for this problem, the solution is probably a little more complicated than > > this. But hopefully this will let us know whether the problem is what we > > think it is. > [ ... ] > (da0:ahc0:0:0:0): printed announcement > o da0s1a > (da0:ahc0:0:0:0): read capacity returned 0 > (da1:ahc0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da1:ahc0:0:1:0): NOT READY > (da1:ahc0:0:1:0): fatal error, failed to attach to device > (da1:ahc0:0:1:0): lost device > (da1:ahc0:0:1:0): about to print announcement > (da1:ahc0:0:1:0): printed announcement > (da1:ahc0:0:1:0): removing device entry > (da0:ahc0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:ahc0:0:0:0): NOT READY > (da0:ahc0:0:0:0): address = 8496883, length = 512 > Enter full pathname of shell or RETURN for /bin/sh: > erase ^H, kill ^U, intr ^C > /sbin/camcontrol cmd -n da -u 1 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 > camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed > cam_lookup_pass: No such file or directory > cam_lo(okup_pdass: either the apass driver isn'0t in your kernel: > cam_lookup_pasas: or da1 doesn'ht exist > end of ccamcontrol [ ... ] > I take it the "fatal error, failed to attach to device" is what you were > trying for? Yes and no. I forgot that you were running 3.1-era code. I made some changes before 3.2 went out (I can't remember when, but you could probably just look at the cvs logs for scsi_da.c and see) to make the da and cd drivers to make them attach in almost every case. (the exception being when the drive returns a "logical unit not supported" error) So, what I would expect to happen with 3.2 or 4.0 code would be that the da driver would attach, but you wouldn't be able to open it to fsck the drive until the drive is ready. > > You should be able to boot okay with this patch, although you probably > > won't be able to fsck or mount the Mylex array until it's ready to run. > > I would expect that. If you have an elegant (or correct) solution to deal > with this - for me, at least, preferably from userland - I'm all ears. > > What I'm thinking is just sitting there querying the thing every few > seconds until it reports a size, then have CAM re-query the device. Does > that seem reasonable? > > I'm actually not interested in a solution more complex than that because > in the event the RAID fails, it does the same sort of thing, and I'd like > to be able to get into the machine from remote and talk to the Mylex. Well, I would suggest either upgrading the machine to a newer -stable code base or applying the attached patch to scsi_da.c. That will make the da driver attach even when your Mylex unit isn't ready. Then, you might be able to do something like this in /etc/rc: camcontrol tur -n da -u 1 >/dev/null 2>&1 while [ "$?" != 0 ] do sleep 1 camcontrol tur -n da -u 1 >/dev/null 2>&1 done ...do fsck, etc... You might also want to put a maximum count in there or something so that if the Mylex doesn't become ready after a given period of time, you stop waiting for it. What the above script fragment is taking advantage of is that 'camcontrol tur' will only exit with a 0 status if the device is ready. We could also probably do something within the CAM error recovery code along the same lines, but I think it would probably end up being a kludge, and possibly not correct, at least within the current error recovery framework. If the above camcontrol trick works for you, that's probably the best solution, since it gives you an easy way to tweak or disable the test if you want. Anyway, lemme know whether it works for you, or if you've got more questions or whatever.. Ken -- Kenneth Merry ken@plutotech.com --ELM930936660-51339-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=scsi_da.c.1.22 Content-Description: scsi_da.c.1.22 Content-Transfer-Encoding: 7bit Index: scsi_da.c =================================================================== RCS file: /usr/local/cvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.21 retrieving revision 1.22 diff -c -r1.21 -r1.22 *** scsi_da.c 1999/03/05 23:20:20 1.21 --- scsi_da.c 1999/05/06 20:16:04 1.22 *************** *** 25,31 **** * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ! * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ */ #include "opt_hw_wdog.h" --- 25,31 ---- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ! * $Id: scsi_da.c,v 1.22 1999/05/06 20:16:04 ken Exp $ */ #include "opt_hw_wdog.h" *************** *** 1381,1393 **** &asc, &ascq); } /* ! * With removable media devices, we expect ! * 0x3a (Medium not present) errors, since not ! * everyone leaves a disk in the drive. If ! * the error is anything else, though, we ! * shouldn't attach. */ ! if ((have_sense) && (asc == 0x3a) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), --- 1381,1392 ---- &asc, &ascq); } /* ! * Attach to anything that claims to be a ! * direct access or optical disk device, ! * as long as it doesn't return a "Logical ! * unit not supported" (0x25) error. */ ! if ((have_sense) && (asc != 0x25) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), --ELM930936660-51339-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 18:39:58 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 0C2BB15185 for ; Fri, 2 Jul 1999 18:39:48 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id SAA01431; Fri, 2 Jul 1999 18:39:44 -0700 Date: Fri, 2 Jul 1999 18:39:18 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" , "Kenneth D. Merry" Cc: scsi@freebsd.org Subject: just so you all know how really whacky it can get... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've added Fabric support and also added/tested for SCCLUN.... While doing a rescan on a SCCLUN enabled (16 bit luns) through a switch... this sort of leads me to believe that we need some more flags so that an HBA can inform CAM that an exhaustive search isn't needed- or at least I need to try and implement the REPORT LUNS command... at some point it rebooted (I didn't yet catch why).... really pretty amusing: isp1: Loop DOWN- freezing SIMQ until Loop comes up isp1: LIP occurred isp1: Loop UP-releasing frozen SIMQ isp1: Firmware State Config Wait -> Ready isp1: Loop ID 89, AL_PA 0x4a, Port ID 0x814b4a isp1: type 0x2@portid 0x814dcb 0x210000203704fe7d isp1: type 0x2@portid 0x814db5 0x5080020000029502 isp1: type 0x2@portid 0x814dcc 0x2100002037078f93 isp1: type 0x2@portid 0x814dcb 0x210000203704fe7d isp1: type 0x2@portid 0x814dcd 0x2100002037049eab isp1: type 0x2@portid 0x814dcc 0x2100002037078f93 isp1: type 0x2@portid 0x814dd2 0x5080020000029501 isp1: type 0x2@portid 0x814dcd 0x2100002037049eab isp1: type 0x2@portid 0x814ddc 0x2100002037074a00 isp1: type 0x2@portid 0x814dd2 0x5080020000029501 isp1: type 0x2@portid 0x814de0 0x2100002037003259 isp1: type 0x2@portid 0x814ddc 0x2100002037074a00 isp1: type 0x2@portid 0x814de1 0x2100002037049a8f isp1: type 0x2@portid 0x814de0 0x2100002037003259 isp1: type 0x2@portid 0x814de2 0x2100002037049f06 isp1: type 0x2@portid 0x814de1 0x2100002037049a8f isp1: type 0x2@portid 0x814de4 0x21000020370022e4 isp1: type 0x2@portid 0x814de2 0x2100002037049f06 isp1: type 0x2@portid 0x814e75 0x000000c08c000176 isp1: type 0x2@portid 0x814de4 0x21000020370022e4 isp1: type 0x2@portid 0x814fef 0x2200080020a020e8 isp1: type 0x2@portid 0x814e75 0x000000c08c000176 isp1: type 0x2@portid 0x814b4a 0x210000e08b0012c5 da2 at isp1 bus 0 target 131 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 100.000MB/s transfers, Tagged Queueing Enabled da2: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da3 at isp1 bus 0 target 132 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 100.000MB/s transfers, Tagged Queueing Enabled da3: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da4 at isp1 bus 0 target 133 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 100.000MB/s transfers, Tagged Queueing Enabled da4: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da5 at isp1 bus 0 target 135 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 100.000MB/s transfers, Tagged Queueing Enabled da5: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da6 at isp1 bus 0 target 136 lun 0 da6: Fixed Direct Access SCSI-2 device da6: 100.000MB/s transfers, Tagged Queueing Enabled da6: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da7 at isp1 bus 0 target 137 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 100.000MB/s transfers, Tagged Queueing Enabled da7: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da8 at isp1 bus 0 target 138 lun 0 da8: Fixed Direct Access SCSI-2 device da8: 100.000MB/s transfers, Tagged Queueing Enabled da8: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da9 at isp1 bus 0 target 139 lun 0 da9: Fixed Direct Access SCSI-2 device da9: 100.000MB/s transfers, Tagged Queueing Enabled da9: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) (da10:isp1:0:139:671): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da10:isp1:0:139:671): ILLEGAL REQUEST asc:25,0 (da10:isp1:0:139:671): Logical unit not supported field replaceable unit: 1 (da10:isp1:0:139:671): fatal error, failed to attach to device (da10:isp1:0:139:671): lost device (da10:isp1:0:139:671): removing device entry (da11:isp1:0:136:672): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da11:isp1:0:136:672): ILLEGAL REQUEST asc:25,0 (da11:isp1:0:136:672): Logical unit not supported field replaceable unit: 1 (da11:isp1:0:136:672): fatal error, failed to attach to device (da11:isp1:0:136:672): lost device (da11:isp1:0:136:672): removing device entry (da10:isp1:0:132:22981): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da10:isp1:0:132:22981): ILLEGAL REQUEST asc:25,0 (da10:isp1:0:132:22981): Logical unit not supported field replaceable unit: 1 (da10:isp1:0:132:22981): fatal error, failed to attach to device (da10:isp1:0:132:22981): lost device (da10:isp1:0:132:22981): removing device entry (da11:isp1:0:136:22980): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da11:isp1:0:136:22980): ILLEGAL REQUEST asc:25,0 (da11:isp1:0:136:22980): Logical unit not supported field replaceable unit: 1 (da11:isp1:0:136:22980): fatal error, failed to attach to device (da11:isp1:0:136:22980): lost device (da11:isp1:0:136:22980): removing device entry isp1: command timed out for target 137 lun 671 isp1: command timed out for target 138 lun 671 (da10:isp1:0:133:28905): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da10:isp1:0:133:28905): ILLEGAL REQUEST asc:25,0 (da10:isp1:0:133:28905): Logical unit not supported field replaceable unit: 1 (da10:isp1:0:133:28905): fatal error, failed to attach to device (da10:isp1:0:133:28905): lost device (da10:isp1:0:133:28905): removing device entry (da11:isp1:0:138:1241): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da11:isp1:0:138:1241): ILLEGAL REQUEST asc:25,0 (da11:isp1:0:138:1241): Logical unit not supported field replaceable unit: 1 (da11:isp1:0:138:1241): fatal error, failed to attach to device (da11:isp1:0:138:1241): lost device (da11:isp1:0:138:1241): removing device entry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 20:12:18 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 26F841520C for ; Fri, 2 Jul 1999 20:12:13 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA57892; Fri, 2 Jul 1999 21:11:46 -0600 (MDT) (envelope-from ken) Message-Id: <199907030311.VAA57892@panzer.kdm.org> Subject: Re: just so you all know how really whacky it can get... In-Reply-To: from Matthew Jacob at "Jul 2, 1999 06:39:18 pm" To: mjacob@feral.com Date: Fri, 2 Jul 1999 21:11:46 -0600 (MDT) Cc: gibbs@plutotech.com, 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 Matthew Jacob wrote... > > I've added Fabric support and also added/tested for SCCLUN.... > > While doing a rescan on a SCCLUN enabled (16 bit luns) through a switch... > this sort of leads me to believe that we need some more flags so that an > HBA can inform CAM that an exhaustive search isn't needed- or at least I > need to try and implement the REPORT LUNS command... at some point it > rebooted (I didn't yet catch why).... really pretty amusing: [ ... ] > da9 at isp1 bus 0 target 139 lun 0 > da9: Fixed Direct Access SCSI-2 device > da9: 100.000MB/s transfers, Tagged Queueing Enabled > da9: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) > (da10:isp1:0:139:671): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da10:isp1:0:139:671): ILLEGAL REQUEST asc:25,0 > (da10:isp1:0:139:671): Logical unit not supported field replaceable unit: 1 > (da10:isp1:0:139:671): fatal error, failed to attach to device > (da10:isp1:0:139:671): lost device > (da10:isp1:0:139:671): removing device entry > (da11:isp1:0:136:672): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da11:isp1:0:136:672): ILLEGAL REQUEST asc:25,0 > (da11:isp1:0:136:672): Logical unit not supported field replaceable unit: 1 > (da11:isp1:0:136:672): fatal error, failed to attach to device > (da11:isp1:0:136:672): lost device > (da11:isp1:0:136:672): removing device entry > (da10:isp1:0:132:22981): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da10:isp1:0:132:22981): ILLEGAL REQUEST asc:25,0 > (da10:isp1:0:132:22981): Logical unit not supported field replaceable unit: 1 > (da10:isp1:0:132:22981): fatal error, failed to attach to device > (da10:isp1:0:132:22981): lost device > (da10:isp1:0:132:22981): removing device entry > (da11:isp1:0:136:22980): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da11:isp1:0:136:22980): ILLEGAL REQUEST asc:25,0 > (da11:isp1:0:136:22980): Logical unit not supported field replaceable unit: 1 > (da11:isp1:0:136:22980): fatal error, failed to attach to device > (da11:isp1:0:136:22980): lost device > (da11:isp1:0:136:22980): removing device entry > isp1: command timed out for target 137 lun 671 > isp1: command timed out for target 138 lun 671 > (da10:isp1:0:133:28905): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da10:isp1:0:133:28905): ILLEGAL REQUEST asc:25,0 > (da10:isp1:0:133:28905): Logical unit not supported field replaceable unit: 1 > (da10:isp1:0:133:28905): fatal error, failed to attach to device > (da10:isp1:0:133:28905): lost device > (da10:isp1:0:133:28905): removing device entry > (da11:isp1:0:138:1241): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da11:isp1:0:138:1241): ILLEGAL REQUEST asc:25,0 > (da11:isp1:0:138:1241): Logical unit not supported field replaceable unit: 1 > (da11:isp1:0:138:1241): fatal error, failed to attach to device > (da11:isp1:0:138:1241): lost device > (da11:isp1:0:138:1241): removing device entry That is impressive. :) At least the da driver test I put in works correctly. Otherwise, you'd probably have over 650,000 da devices. :) One thing I don't understand, though, is why any of those disks would even respond on a LUN other than 0. You'd think they would do the normal thing and just not respond to an inquiry. I think you're right, we probably need to do something about it. But the REPORT LUNS command wouldn't help here, since that's a SCSI-3 command. Unless you can change the definition on those drives. Even still, it wouldn't help in all cases. One possible sequence of things we could do is: - attempt to change the definition of the device to SCSI-3 - if that works, send the REPORT LUNS command - probe only the luns returned - if the change definition doesn't work, only probe up to N luns, where N is no more than 7 or 16 (for FC) Does that even sound reasonable? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 20:27:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 6CBCB14C14 for ; Fri, 2 Jul 1999 20:27:22 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id WAA22102; Fri, 2 Jul 1999 22:27:20 -0500 (CDT) From: Joe Greco Message-Id: <199907030327.WAA22102@aurora.sol.net> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907021731.LAA51596@panzer.kdm.org> from "Kenneth D. Merry" at "Jul 2, 1999 11:31: 0 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 2 Jul 1999 22:27:19 -0500 (CDT) Cc: scsi@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 > Yes and no. I forgot that you were running 3.1-era code. I made some > changes before 3.2 went out (I can't remember when, but you could probably > just look at the cvs logs for scsi_da.c and see) to make the da and cd > drivers to make them attach in almost every case. (the exception being > when the drive returns a "logical unit not supported" error) > > So, what I would expect to happen with 3.2 or 4.0 code would be that the da > driver would attach, but you wouldn't be able to open it to fsck the drive > until the drive is ready. Seems quite reasonable. If you don't mind waiting a week or so, I'll be able to test it on a 3.2R box. I just can't power cycle a machine in Chicago from here in Milwaukee, so I've gotta make a road trip. > Then, you might be able to do something like this in /etc/rc: > > camcontrol tur -n da -u 1 >/dev/null 2>&1 > while [ "$?" != 0 ] > do > sleep 1 > camcontrol tur -n da -u 1 >/dev/null 2>&1 > done > ...do fsck, etc... I'll actually stick something like that in with the fsck code, which is later in a /usr/local/etc/rc.* something-or-other. The system is supposed to bring itself up and then do whatever is needed to start its news subsystem, since (among other things) I'd rather have it live on-net to refuse connections while this is all going on. Thanks for the specific camcontrol incantation to check the thing... I'm sure I'd have figured it out eventually but I like having the correct solution. ;-) > We could also probably do something within the CAM error recovery code > along the same lines, but I think it would probably end up being a kludge, > and possibly not correct, at least within the current error recovery > framework. I'd actually rather _not_ see that, or at least have it be only an optional behaviour of some sort. I do think it is completely legitimate for the OS to say that a drive isn't available, but it'd be a very bad thing (as far as I am concerned) for the OS to get hung up waiting for a drive to become ready. ... JG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 20:33:18 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 A040D14F26 for ; Fri, 2 Jul 1999 20:33:15 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA58017; Fri, 2 Jul 1999 21:31:58 -0600 (MDT) (envelope-from ken) Message-Id: <199907030331.VAA58017@panzer.kdm.org> Subject: Re: FreeBSD panics with Mylex DAC960SX In-Reply-To: <199907030327.WAA22102@aurora.sol.net> from Joe Greco at "Jul 2, 1999 10:27:19 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Fri, 2 Jul 1999 21:31:57 -0600 (MDT) Cc: scsi@freebsd.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joe Greco wrote... > > Yes and no. I forgot that you were running 3.1-era code. I made some > > changes before 3.2 went out (I can't remember when, but you could probably > > just look at the cvs logs for scsi_da.c and see) to make the da and cd > > drivers to make them attach in almost every case. (the exception being > > when the drive returns a "logical unit not supported" error) > > > > So, what I would expect to happen with 3.2 or 4.0 code would be that the da > > driver would attach, but you wouldn't be able to open it to fsck the drive > > until the drive is ready. > > Seems quite reasonable. > > If you don't mind waiting a week or so, I'll be able to test it on a 3.2R > box. I just can't power cycle a machine in Chicago from here in Milwaukee, > so I've gotta make a road trip. If you apply the patch I attached to my last message, you should get the same behavior from your older code, and avoid making the road trip. :) > > Then, you might be able to do something like this in /etc/rc: > > > > camcontrol tur -n da -u 1 >/dev/null 2>&1 > > while [ "$?" != 0 ] > > do > > sleep 1 > > camcontrol tur -n da -u 1 >/dev/null 2>&1 > > done > > ...do fsck, etc... > > I'll actually stick something like that in with the fsck code, which is > later in a /usr/local/etc/rc.* something-or-other. The system is supposed > to bring itself up and then do whatever is needed to start its news > subsystem, since (among other things) I'd rather have it live on-net to > refuse connections while this is all going on. Thanks for the specific > camcontrol incantation to check the thing... I'm sure I'd have figured it > out eventually but I like having the correct solution. ;-) You're welcome. It should work okay, but make sure you test it out of course. :) > > We could also probably do something within the CAM error recovery code > > along the same lines, but I think it would probably end up being a kludge, > > and possibly not correct, at least within the current error recovery > > framework. > > I'd actually rather _not_ see that, or at least have it be only an optional > behaviour of some sort. I do think it is completely legitimate for the OS > to say that a drive isn't available, but it'd be a very bad thing (as far > as I am concerned) for the OS to get hung up waiting for a drive to become > ready. I agree. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jul 2 22: 8:44 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 93EF915257 for ; Fri, 2 Jul 1999 22:08:42 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id WAA01891; Fri, 2 Jul 1999 22:08:41 -0700 Date: Fri, 2 Jul 1999 22:08:12 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: gibbs@plutotech.com, scsi@freebsd.org Subject: Re: just so you all know how really whacky it can get... In-Reply-To: <199907030311.VAA57892@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was impressed that it did as well as it did- really pretty good all told. > One thing I don't understand, though, is why any of those disks would even > respond on a LUN other than 0. You'd think they would do the normal thing > and just not respond to an inquiry. Disk breakage. The parallel SCSI ISP 7.63 f/w goes up to 32 luns. I don't allow it to (yet) go above 8 luns because there are far too many disks that just go apeshit- and this is a problem because there are a large number of RAID devices that really want use all 32 luns (for parallel SCSI). Think about all the devices that can't cope with non-zero luns at all. Now imagine that you're the f/w writer- if you handle greater than lun 0, you should handle all luns sensibly, right? Heh. You don't know f/w writers... > I think you're right, we probably need to do something about it. But > the REPORT LUNS command wouldn't help here, since that's a SCSI-3 command. > Unless you can change the definition on those drives. Even still, it > wouldn't help in all cases. > > One possible sequence of things we could do is: > > - attempt to change the definition of the device to SCSI-3 > - if that works, send the REPORT LUNS command > - probe only the luns returned > - if the change definition doesn't work, only probe up to N luns, > where N is no more than 7 or 16 (for FC) > > Does that even sound reasonable? I think I simply would skip the change definition- just try the REPORT LUNS command. Just because a command is specified in SCSI-3 doesn't mean that a SCSI-2 device won't decode it. But if you can do the change definition, that'd work too. That should unambiguously tell one what the number of supported luns are. Beyond that, I'm thinking that we need to move a bit more agressively on the runtime quirking we've been talking about and allow people to specify devices that *can* go above 8 or 16 luns. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message