From owner-freebsd-scsi Sun Apr 12 00:25:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA01886 for freebsd-scsi-outgoing; Sun, 12 Apr 1998 00:25:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA01881 for ; Sun, 12 Apr 1998 00:25:37 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id BAA09794; Sun, 12 Apr 1998 01:21:27 -0600 (MDT) Date: Sun, 12 Apr 1998 01:21:27 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804120721.BAA09794@narnia.plutotech.com> To: Joerg Wunsch cc: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804070732.XAA28712@revolution.3-cities.com> <19980411204617.63713@uriah.heep.sax.de> <19980412105735.37665@freebie.lemis.com> <19980412083937.23967@uriah.heep.sax.de> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19980412083937.23967@uriah.heep.sax.de> you wrote: > As Greg Lehey wrote: > >> My understanding is that the CAM driver returns ENOSPC. I don't know >> whether it performs a partial write, but as long as it correctly >> reports what it does, that's fine by me. > > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. ENOSPC is the correct error code. It is even documented in dump that it's lack of handling ENOSPC as EOT is a bug. I have patches that fix this problem. > EOF/EOM _must_ return a partial write, *and no error*. In variable block mode, there is no partial write performed by the device, so ENOSPC is returned immediately at EOM. In fixed block mode, if some blocks were written, a short write is returned with no error, but the next write attempt will return ENOSPC. EOF will return either a partial read, followed by a 0 length read, or a 0 length read if you just happen to be at EOF when a read is attempted. We follow the SCSI tape semantics whereby the logical head position is after the filemark after a filemark is encountered. This means that the first read after a filemark, starts into the next file. EOM returns a 0 length read. > An error must only be returned iff attempting to start the write > operation beyond the end of medium. I don't believe that these are the correct semanics. No error should be returned if a partial request was satisfied. If the entire request cannot be satisfied because we are at, or past EOM on a write, an error should be returned. This is exactly the same semantics as writing to a file when there is no space left on the device. > Since tapes cannot seek (at least > not in the current driver, although it's probably possible for some > drives to teach them seeking), the question is not so easy to answer > when you really have to return an error. I think the following would > be OK for all the existing software: > > . write(2) starts before EOM, but the requests spans EOM: the syscall > writes as much as can be handled, and returns a short write (but no > error). > > . first write(2) request that starts exactly at EOM: special case of > the above, the syscall returns just 0, but no error. > > . repeated attempt of the previous case: return EINVAL. Why is EINVAL a more appropriate error code than ENOSPC? > The latter would help programs that attempt to repeatedly to operate > beyond the EOM to detect their error, albeit these programs are > arguably broken. The latter would break dump. It waits for write to return 0 10 times before believing it has hit EOM. You either have to return no error, or return the correct error. ENOSPC makes perfect sense and we should use it. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 12 03:51:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA18755 for freebsd-scsi-outgoing; Sun, 12 Apr 1998 03:51:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA18750 for ; Sun, 12 Apr 1998 03:51:51 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id MAA20681 for scsi@FreeBSD.ORG; Sun, 12 Apr 1998 12:51:50 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id MAA22170; Sun, 12 Apr 1998 12:43:41 +0200 (MET DST) Message-ID: <19980412124340.50537@uriah.heep.sax.de> Date: Sun, 12 Apr 1998 12:43:40 +0200 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Reply-To: Joerg Wunsch References: <199804070732.XAA28712@revolution.3-cities.com> <199804120721.BAA09794@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804120721.BAA09794@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Apr 12, 1998 at 01:21:27AM -0600 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Justin T. Gibbs wrote: > > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. > > ENOSPC is the correct error code. Where did you get this from? All descriptions for ENOSPC i could find (our own man page, as well as ``The single UNIX specification'' on http://www.rdg.opengroup.org/onlinepubs/ -- i don't have access to the appropriate Posix docs) make it very explicit that ENOSPC is only related to regular files and directories. > It is even documented in dump that > it's lack of handling ENOSPC as EOT is a bug. No. I can't seem to find it. The only mention of ENOSPC is: /* * fixme: Pyramids running OSx return ENOSPC * at EOT on 1/2 inch drives. */ ...which rather sounds like an idiosyncrasy on Pyramid's OS than the admission of a bug in dump. How do you `fix' all the other programs inside and outside our tree? (Start with GNUtar's multi-volume handling for an example.) > > An error must only be returned iff attempting to start the write > > operation beyond the end of medium. > > I don't believe that these are the correct semanics. No error should > be returned if a partial request was satisfied. If the entire request > cannot be satisfied because we are at, or past EOM on a write, an error > should be returned. This is exactly the same semantics as writing to > a file when there is no space left on the device. I think this violates the traditional behaviour. Alas, the existing docs are not fully clear on this, and allow both interpretations. Our own write(2) man page is rather thin on this. The UNXI spec is a little more verbose: If a write() requests that more bytes be written than there is room for (for example, the ulimit or the physical end of a medium), only as many bytes as there is room for will be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a non-zero number of bytes will give a failure return (except as noted below) and the implementation will generate a SIGXFSZ signal for the thread. It only tells about ``the next write of a non-zero number'', and this entire man page doesn't mention special files at all. :( Again, i'm just arguing to follow what's IMHO the traditional behaviour, so software relying on it would work. (And i don't see that this traditional behaviour would be in violent conflict with these specs.) > > . repeated attempt of the previous case: return EINVAL. > > Why is EINVAL a more appropriate error code than ENOSPC? Because ENOSPC is limited by definition. (See above.) > > The latter would help programs that attempt to repeatedly to operate > > beyond the EOM to detect their error, albeit these programs are > > arguably broken. > > The latter would break dump. It waits for write to return 0 10 times > before believing it has hit EOM. OK, i take this one back. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 12 05:36:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA01696 for freebsd-scsi-outgoing; Sun, 12 Apr 1998 05:36:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA01691 for ; Sun, 12 Apr 1998 05:36:26 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.8.8/8.8.8) with ESMTP id OAA19073 for ; Sun, 12 Apr 1998 14:36:12 +0200 (MDT) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.8/8.8.5) with ESMTP id OAA01779 for ; Sun, 12 Apr 1998 14:36:11 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id OAA05525 for ; Sun, 12 Apr 1998 14:36:13 +0200 (CEST) From: Andre Albsmeier Message-Id: <199804121236.OAA06663@intern> Subject: Re: Which FreeBSD version supports this new 3940AU? In-Reply-To: <199804112259.QAA08634@narnia.plutotech.com> from "Justin T. Gibbs" at "Apr 11, 98 04:59:29 pm" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Sun, 12 Apr 1998 14:36:06 +0200 (CEST) Cc: andre.albsmeier@mchp.siemens.de, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 > In article <199804111314.PAA28884@intern> you wrote: > > Is there a known workaround here? Or will the (hopefully) > > upcoming CAM driver support this new beast? > > The CAM driver supports the aic7895 which is the "one large > chip" on a 3940AU. OK, thanks a lot for your reply. I know that the 7895 is supported by CAM but I didn't want to remove the label which sticks on the chip. Thanks, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 12 09:44:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25974 for freebsd-scsi-outgoing; Sun, 12 Apr 1998 09:44:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA25968 for ; Sun, 12 Apr 1998 09:44:44 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id KAA11609; Sun, 12 Apr 1998 10:41:00 -0600 (MDT) Date: Sun, 12 Apr 1998 10:41:00 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804121641.KAA11609@narnia.plutotech.com> To: Joerg Wunsch cc: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804070732.XAA28712@revolution.3-cities.com> <199804120721.BAA09794@narnia.plutotech.com> <19980412124340.50537@uriah.heep.sax.de> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19980412124340.50537@uriah.heep.sax.de> you wrote: > As Justin T. Gibbs wrote: > >> > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. >> >> ENOSPC is the correct error code. > > Where did you get this from? All descriptions for ENOSPC i could find > (our own man page, as well as ``The single UNIX specification'' on > http://www.rdg.opengroup.org/onlinepubs/ -- i don't have access to the > appropriate Posix docs) make it very explicit that ENOSPC is only > related to regular files and directories. I'm not an opengroup member, so I can't read their pages. My understanding is that BSDOS also returns ENOSPC in this scenario. >> It is even documented in dump that >> it's lack of handling ENOSPC as EOT is a bug. > > No. I can't seem to find it. The only mention of ENOSPC is: > > /* > * fixme: Pyramids running OSx return ENOSPC > * at EOT on 1/2 inch drives. > */ > > ...which rather sounds like an idiosyncrasy on Pyramid's OS than the > admission of a bug in dump. Regardless of the definition of ENOSPC, dump must handle it. I can just as easily dump to a regular file as a special file. > How do you `fix' all the other programs inside and outside our tree? > (Start with GNUtar's multi-volume handling for an example.) GNUtar's multi-volume handling deals with ENOSPC just fine: /* We're multivol Panic if we didn't get the right kind of response */ /* ENXIO is for the UNIX PC */ if (err < 0 && errno != ENOSPC && errno != EIO && errno != ENXIO) writeerror (err); > I think this violates the traditional behaviour. Alas, the existing > docs are not fully clear on this, and allow both interpretations. Our > own write(2) man page is rather thin on this. The UNXI spec is a > little more verbose: > > If a write() requests that more bytes be written than there is > room for (for example, the ulimit or the physical end of a > medium), only as many bytes as there is room for will be > written. For example, suppose there is space for 20 bytes more > in a file before reaching a limit. A write of 512 bytes will > return 20. The next write of a non-zero number of bytes will > give a failure return (except as noted below) and the > implementation will generate a SIGXFSZ signal for the thread. > > It only tells about ``the next write of a non-zero number'', and this > entire man page doesn't mention special files at all. :( Again, i'm > just arguing to follow what's IMHO the traditional behaviour, so > software relying on it would work. (And i don't see that this > traditional behaviour would be in violent conflict with these specs.) Perhaps special files are not mentioned because they should behave the same as ordinary files??? Isn't that supposed to be the UNIX way? It seems rather clear to me from the above description that a non-zero length write that doesn't write a single byte for lack of space is supposed to return an error. The only thing you've argued against is the use of ENOSPC for that error. I think it's bogus to limit ENOSPC's definition to just ordinary files as "Device out of space" makes all too much sense for this situation. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 12 09:58:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA27827 for freebsd-scsi-outgoing; Sun, 12 Apr 1998 09:58:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA27822 for ; Sun, 12 Apr 1998 09:58:04 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id LAA01135; Sun, 12 Apr 1998 11:57:47 -0500 (EST) (envelope-from toor) Message-Id: <199804121657.LAA01135@dyson.iquest.net> Subject: Re: SCSI EOT fixed J"org? In-Reply-To: <199804121641.KAA11609@narnia.plutotech.com> from "Justin T. Gibbs" at "Apr 12, 98 10:41:00 am" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Sun, 12 Apr 1998 11:57:47 -0500 (EST) Cc: joerg_wunsch@uriah.heep.sax.de, scsi@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 Justin T. Gibbs said: > In article <19980412124340.50537@uriah.heep.sax.de> you wrote: > > As Justin T. Gibbs wrote: > > > >> > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. > >> > >> ENOSPC is the correct error code. > > > > Where did you get this from? All descriptions for ENOSPC i could find > > (our own man page, as well as ``The single UNIX specification'' on > > http://www.rdg.opengroup.org/onlinepubs/ -- i don't have access to the > > appropriate Posix docs) make it very explicit that ENOSPC is only > > related to regular files and directories. > > I'm not an opengroup member, so I can't read their pages. My understanding > is that BSDOS also returns ENOSPC in this scenario. > The pages are available to anyone (with a simple registration.) The info is also available really cheap (I have a CDROM, much less money than the POSIX specs.) The only reason that I got a copy was because it was so cheap. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 12 14:58:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA06089 for freebsd-scsi-outgoing; Sun, 12 Apr 1998 14:58:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero-fddi.simon-shapiro.org (sendero-fddi.Simon-Shapiro.ORG [206.190.148.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA06070 for ; Sun, 12 Apr 1998 14:57:57 -0700 (PDT) (envelope-from shimon@sendero-fddi.simon-shapiro.org) Received: (qmail 25890 invoked by uid 1000); 12 Apr 1998 22:06:58 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-040798 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 12 Apr 1998 15:06:57 -0700 (PDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: freebsd-scsi@FreeBSD.ORG Subject: DPT PM3334UW on FX440LX Chipsets Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you have been frustrated by BIOD and hanging problems of htis controller, on these motherboards, please accept my apology for not contacting you directly. I have a new firmware set that can/should solve this problem. Please contact me for details, as this is not for general distribution yet. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 00:08:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18783 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 00:08:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA18767 for ; Mon, 13 Apr 1998 00:08:23 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id BAA09501 for ; Mon, 13 Apr 1998 01:08:22 -0600 (MDT) Message-Id: <199804130708.BAA09501@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: scsi@FreeBSD.ORG Subject: CAM 980413 snapshot available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Apr 1998 01:04:40 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Full information about CAM can be obtained from: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/README or ftp://ftp.kdm.org/pub/FreeBSD/cam/README Changes for the 980413 Snapshot: - New BusLogic/Mylex MultiMaster driver. - Tape driver now properly reports and allows the configuration of compression and density settings. mt not only reports if compression is available, but the type of compression that is being used. - Tape driver properly returns short or 0 length reads at EOF and EOM. - Dump understands ENOSPC and works in multi-volume mode with the CAM tape driver. -- Justin T. Gibbs Kenneth D. Merry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 02:22:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA12352 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 02:22:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA12342 for ; Mon, 13 Apr 1998 02:22:40 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA08799 for scsi@FreeBSD.ORG; Mon, 13 Apr 1998 11:22:39 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA25274; Mon, 13 Apr 1998 11:20:42 +0200 (MET DST) Message-ID: <19980413112042.37252@uriah.heep.sax.de> Date: Mon, 13 Apr 1998 11:20:42 +0200 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Reply-To: Joerg Wunsch References: <199804070732.XAA28712@revolution.3-cities.com> <199804121641.KAA11609@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804121641.KAA11609@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Apr 12, 1998 at 10:41:00AM -0600 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Justin T. Gibbs wrote: > Regardless of the definition of ENOSPC, dump must handle it. I can > just as easily dump to a regular file as a special file. But in this case, it must be treated as an error, not as an indication of prompting the operator to change volumes. So, that's rather an argumentation against you. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 03:00:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA19073 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 03:00:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA19063 for ; Mon, 13 Apr 1998 03:00:25 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id MAA10048 for ; Mon, 13 Apr 1998 12:00:12 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id MAA07754 for ; Mon, 13 Apr 1998 12:00:02 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804131000.MAA07754@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: scsi@FreeBSD.ORG Subject: SCBtimeouts with CAM and AIC7880 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Apr 1998 12:00:02 +0200 From: Mark Murray Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have a GA586DX with 2xP5/200's and an on-board AIC7880. I have been running CAM for the last month or so, and it is a LOT more stable than the previous code, but there is a problem with SCB's. If I stress the disks too much, I start getting the message "Timedout SCB handled by another timeout" (from aic7xxx.c). This message repeats itself ad nauseam at about 5-10-sec intervals, and the machine is unuseable. A reset is necessary to get it going again. Any clues? Could this be a race condition in the SMP case? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 06:18:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA21477 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 06:18:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA21468 for ; Mon, 13 Apr 1998 13:18:31 GMT (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id HAA19651; Mon, 13 Apr 1998 07:14:49 -0600 (MDT) Date: Mon, 13 Apr 1998 07:14:49 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804131314.HAA19651@narnia.plutotech.com> To: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804070732.XAA28712@revolution.3-cities.com> <199804121641.KAA11609@narnia.plutotech.com> <19980413112042.37252@uriah.heep.sax.de> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19980413112042.37252@uriah.heep.sax.de> you wrote: > As Justin T. Gibbs wrote: > >> Regardless of the definition of ENOSPC, dump must handle it. I can >> just as easily dump to a regular file as a special file. > > But in this case, it must be treated as an error, not as an indication > of prompting the operator to change volumes. So, that's rather an > argumentation against you. ;-) Not if I'm dumping to a regular file on a floppy, or jaz drive, etc. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 06:21:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA22229 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 06:21:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22223 for ; Mon, 13 Apr 1998 13:20:59 GMT (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id HAA19663; Mon, 13 Apr 1998 07:17:05 -0600 (MDT) Date: Mon, 13 Apr 1998 07:17:05 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804131317.HAA19663@narnia.plutotech.com> To: Mark Murray cc: scsi@FreeBSD.ORG Subject: Re: SCBtimeouts with CAM and AIC7880 Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804131000.MAA07754@greenpeace.grondar.za> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199804131000.MAA07754@greenpeace.grondar.za> you wrote: > Hi > > I have a GA586DX with 2xP5/200's and an on-board AIC7880. I have been > running CAM for the last month or so, and it is a LOT more stable than > the previous code, but there is a problem with SCB's. > > If I stress the disks too much, I start getting the message > "Timedout SCB handled by another timeout" (from aic7xxx.c). > This message repeats itself ad nauseam at about 5-10-sec intervals, and > the machine is unuseable. A reset is necessary to get it going again. > > Any clues? Could this be a race condition in the SMP case? It could be an SMP problem, but I don't know for sure. Is the "Timedout SCB handled by another timeout" message how the whole cycle starts or does some other message occur first? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 06:45:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25100 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 06:45:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA25091 for ; Mon, 13 Apr 1998 13:45:31 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id PAA16656; Mon, 13 Apr 1998 15:45:27 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id PAA01971; Mon, 13 Apr 1998 15:45:26 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804131345.PAA01971@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: SCBtimeouts with CAM and AIC7880 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Apr 1998 15:45:25 +0200 From: Mark Murray Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: > > Any clues? Could this be a race condition in the SMP case? > > It could be an SMP problem, but I don't know for sure. Is the > "Timedout SCB handled by another timeout" message how the whole > cycle starts or does some other message occur first? It starts with that message (or it has on the occaisons when I've been able to catch it). The usual situation is a total hang in X. Very occaisionally a ctrl-alt-f1 gets me back to the console, but only after a longish wait (5 mins?), and I'm not that patient :-). Only once did I see "other stuff", and it was followed by an immediate reboot after _one_ "Timedout SCB ...." message. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 06:51:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA26353 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 06:51:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA26322 for ; Mon, 13 Apr 1998 13:51:35 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id HAA24436; Mon, 13 Apr 1998 07:51:26 -0600 (MDT) Message-Id: <199804131351.HAA24436@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mark Murray cc: scsi@FreeBSD.ORG Subject: Re: SCBtimeouts with CAM and AIC7880 In-reply-to: Your message of "Mon, 13 Apr 1998 15:45:25 +0200." <199804131345.PAA01971@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Apr 1998 07:47:44 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It starts with that message (or it has on the occaisons when I've been >able to catch it). > >The usual situation is a total hang in X. Very occaisionally a >ctrl-alt-f1 gets me back to the console, but only after a longish wait >(5 mins?), and I'm not that patient :-). Can you hook up a serial console and record a session where this occurs and send me the output? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 13 16:49:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26334 for freebsd-scsi-outgoing; Mon, 13 Apr 1998 16:49:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26328 for ; Mon, 13 Apr 1998 23:49:17 GMT (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id QAA14638; Mon, 13 Apr 1998 16:49:06 -0700 (PDT) Date: Mon, 13 Apr 1998 16:49:06 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199804132349.QAA14638@math.berkeley.edu> To: joerg_wunsch@uriah.heep.sax.de Subject: Re: SCSI EOT fixed J"org? Cc: dan@math.berkeley.edu, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. > EOF/EOM _must_ return a partial write, *and no error*. Anything else > breaks the Unix semantics, and thus all programs that rely on Unix > semantics (dump(8), multi-volume tar(1)). I think this was "discussed" this several months ago. The 6th Edition UNIX manual says quite clearly that incomplete writes are errors. Any other behavior is likely to have been heavily influenced by System-V which I consider to be not-exactly-unix. When I write "UNIX", I use it as a technical term. I am not referring to the trademark. I have no idea who owns the trademark these days or what the owner uses it to mean. Note: the POSIX standards are also not-exactly-unix UNIX. They are POSIX. I consider FreeBSD and the other BSD derivatives to be almost-unix. Of all the unix derivatives, these are the most unix-like. Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 12:43:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27439 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 12:43:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frodo.epigram.com (gated.epigram.com [209.0.75.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27373 for ; Tue, 14 Apr 1998 19:42:49 GMT (envelope-from brandon@epigram.com) Received: from epigram.com (berio [10.100.100.31]) by frodo.epigram.com (8.8.5/8.8.5) with ESMTP id MAA10192 for ; Tue, 14 Apr 1998 12:42:48 -0700 (PDT) Message-ID: <3533BBE4.DF09519@epigram.com> Date: Tue, 14 Apr 1998 12:41:24 -0700 From: Brandon Huey Reply-To: bh@epigram.com Organization: Epigram, Inc. X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: RAID performance/benchmarking Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dell PowerEdge 4200/300, 96MB RAM, 3 9GB Seagate Barracuda SCA drives DPT PM3334UW w/64MB cache FreeBSD 2.2.6 DPT kernel options: DPTOPT DPT_MEASURE_PERFORMANCE DPT_FREELIST_IS_STACK i created an array group with the dos util 'dptmgr' from default settings. using IOZONE and Bonnie, i create a 128MB file for read/write benchmarking. i am aware of the performance implications of RAID-5, but I am getting about 2MByte/sec max write transfer rate compared with 19MByte/sec on reads. For a pci ultrawide controller, are these figures suspect? What kind of write performance hit should one expect w/RAID-5 ? Thanks, -bh -- Brandon Huey Epigram, Inc. bh@epigram.com +1 408 720 3027 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 14:13:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15724 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 14:13:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from klemm.gtn.com (klemm-isdn.gtn.com [194.77.2.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA15673 for ; Tue, 14 Apr 1998 21:13:36 GMT (envelope-from andreas@klemm.gtn.com) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id XAA06313; Tue, 14 Apr 1998 23:12:37 +0200 (CEST) (envelope-from andreas) Message-ID: <19980414231237.30098@klemm.gtn.com> Date: Tue, 14 Apr 1998 23:12:37 +0200 From: Andreas Klemm To: bh@epigram.com, freebsd-scsi@FreeBSD.ORG Subject: Re: RAID performance/benchmarking References: <3533BBE4.DF09519@epigram.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <3533BBE4.DF09519@epigram.com>; from Brandon Huey on Tue, Apr 14, 1998 at 12:41:24PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 14, 1998 at 12:41:24PM -0700, Brandon Huey wrote: > For a pci ultrawide controller, are these figures suspect? What kind of > write performance hit should one expect w/RAID-5 ? external raid array, 5 x 4 GB HD, 233 MHz PII, AHA 2940 U Bonnie benchmark values FreeBSD 2.2.6 FreeBSD klemm2.hightek.com 2.2.6-STABLE FreeBSD 2.2.6-STABLE #0: Thu Apr 2 19:30:20 CEST 1998 root@klemm2.hightek.com:/usr/src/sys/compile/KLEMM2 i386 Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd1c 17245898 2 15866225 0% /data -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU FreeBSD A) sync 300 12480 94.1 13527 26.1 8734 24.9 11958 95.5 24792 45.0 101.8 2.2 B) async 300 12402 93.1 13556 25.8 8899 25.0 11707 92.5 24905 44.2 103.7 2.2 SCO Unix 300 2995 84.3 5512 36.2 3020 23.8 3578 97.5 11605 59.1 43.9 4.4 -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html powered by ,,symmetric multiprocessor FreeBSD'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 14:16:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16214 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 14:16:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from klemm.gtn.com (klemm-isdn.gtn.com [194.77.2.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16203 for ; Tue, 14 Apr 1998 21:16:10 GMT (envelope-from andreas@klemm.gtn.com) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id XAA06313; Tue, 14 Apr 1998 23:12:37 +0200 (CEST) (envelope-from andreas) Message-ID: <19980414231237.30098@klemm.gtn.com> Date: Tue, 14 Apr 1998 23:12:37 +0200 From: Andreas Klemm To: bh@epigram.com, freebsd-scsi@FreeBSD.ORG Subject: Re: RAID performance/benchmarking References: <3533BBE4.DF09519@epigram.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <3533BBE4.DF09519@epigram.com>; from Brandon Huey on Tue, Apr 14, 1998 at 12:41:24PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 14, 1998 at 12:41:24PM -0700, Brandon Huey wrote: > For a pci ultrawide controller, are these figures suspect? What kind of > write performance hit should one expect w/RAID-5 ? external raid array, 5 x 4 GB HD, 233 MHz PII, AHA 2940 U Bonnie benchmark values FreeBSD 2.2.6 FreeBSD klemm2.hightek.com 2.2.6-STABLE FreeBSD 2.2.6-STABLE #0: Thu Apr 2 19:30:20 CEST 1998 root@klemm2.hightek.com:/usr/src/sys/compile/KLEMM2 i386 Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd1c 17245898 2 15866225 0% /data -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU FreeBSD A) sync 300 12480 94.1 13527 26.1 8734 24.9 11958 95.5 24792 45.0 101.8 2.2 B) async 300 12402 93.1 13556 25.8 8899 25.0 11707 92.5 24905 44.2 103.7 2.2 SCO Unix 300 2995 84.3 5512 36.2 3020 23.8 3578 97.5 11605 59.1 43.9 4.4 -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html powered by ,,symmetric multiprocessor FreeBSD'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 16:43:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18076 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 16:43:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero-fddi.simon-shapiro.org (sendero-fddi.Simon-Shapiro.ORG [206.190.148.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA18049 for ; Tue, 14 Apr 1998 23:43:24 GMT (envelope-from shimon@sendero-fddi.simon-shapiro.org) Received: (qmail 18400 invoked by uid 1000); 14 Apr 1998 23:52:46 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-040798 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3533BBE4.DF09519@epigram.com> Date: Tue, 14 Apr 1998 16:52:46 -0700 (PDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: bh@epigram.com Subject: RE: RAID performance/benchmarking Cc: freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14-Apr-98 Brandon Huey wrote: > Dell PowerEdge 4200/300, 96MB RAM, 3 9GB Seagate Barracuda SCA drives > DPT PM3334UW w/64MB cache > > FreeBSD 2.2.6 > DPT kernel options: DPTOPT > DPT_MEASURE_PERFORMANCE > DPT_FREELIST_IS_STACK > > i created an array group with the dos util 'dptmgr' from default > settings. > > using IOZONE and Bonnie, i create a 128MB file for read/write > benchmarking. > > i am aware of the performance implications of RAID-5, but I am getting > about 2MByte/sec max write transfer rate compared with 19MByte/sec on > reads. > > For a pci ultrawide controller, are these figures suspect? What kind of > write performance hit should one expect w/RAID-5 ? Depends on array size, type of controller, amount of cache, type of access. RAID arrays are not a good benefit for sequential access. RAID-5 are evel less of a match. I perfrom ALL my tests on random seeks, 2GB data sets or better. 128MB dataset will have in the vicinity of 50% cache hit rate on a full controller. Expect something between 21 and 6 MB/Sec for RAID-5 WRITE perfromace. configuration dependant. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 17:58:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA03473 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 17:58:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA03468 for ; Wed, 15 Apr 1998 00:58:18 GMT (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id SAA24735; Tue, 14 Apr 1998 18:54:24 -0600 (MDT) Date: Tue, 14 Apr 1998 18:54:24 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804150054.SAA24735@narnia.plutotech.com> To: shimon@simon-shapiro.org cc: scsi@FreeBSD.ORG Subject: Re: RAID performance/benchmarking Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Depends on array size, type of controller, amount of cache, type of access. > RAID arrays are not a good benefit for sequential access. This really depends. For Pluto's application, using RAID 3 not only gives us reliability, but also the ability to have one of the drives in a stripe "return late", but still maintain low latency by replacing the data through parity reconstruction. Since we are a realtime system where being even a little late is unacceptable, the use of RAID gives us a big advantage. Almost all of our accesses are sequential. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 18:49:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13134 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 18:49:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA13121; Wed, 15 Apr 1998 01:49:33 GMT (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id SAA01815; Tue, 14 Apr 1998 18:46:48 -0700 (PDT) Message-Id: <199804150146.SAA01815@dingo.cdrom.com> Date: Tue, 14 Apr 1998 18:46:47 -0700 From: Mike Smith Subject: HEADS UP: CAM cutover in two weeks. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To: undisclosed-recipients:; ------- Blind-Carbon-Copy X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org Subject: HEADS UP: CAM cutover in two weeks. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Apr 1998 18:46:47 -0700 From: Mike Smith One of the major feature goals for 3.0 is the transition to the new CAM-inspired SCSI subsystem. This transition requires a hard cutover date. The proposed cutover date is the 28th of April. On or about this point in time, the following steps will be taken: - A CVS tag will be applied to mark the last checkout date prior to the cutover. - The CAM code will be committed to the -current branch. - GENERIC and LINT will be translated to suit. - MAKEDEV will be updated. - Non-CAM SCSI code and drivers will be *disabled*. There will be an announcement at least 24 hours preceeding the cutover. It is important to note that the cutover to CAM will result in a number of SCSI adapters and devices becoming *unsupported*. A number of these are significant items, and developers are encouraged to take the time to update drivers which they may have an interest in. FreeBSD Test Labs will endeavour to provide loan equipment to developers undertaking such updates. The following SCSI adapters will become unsupported: Driver Adapter Owner ------ ------- ----- aha Adaptec 1542 ? (*)(+) aic Adaptec aic6x60 ? (*)(+) amd NCR 53c974 ? (*) dpt DPT RAID controllers Simon Shapiro (*) nca NCR 53c400 ? sea Seagate ST01/ST02 ? uha Ultrastor 34F ? (*)(+) vpo Iomega ppa3 (eg. Zip) Nicolas Souchu (*)(+) wds Western Digital WD7000 ? The following SCSI peripherals will become unsupported: Driver Adapter ------ ------- od Optical-disk device (*)(+) uk Unknown SCSI device worm Write-once SCSI device Drivers marked (*) are considered to be currently supported, and desirable for 3.0. FreeBSD Test Labs has development hardware available for loan to developers for drivers marked (+). In some cases, documentation may also be available. If there are any significant issues (other than FUD) relating to the proposed cutover, now is the time to raise them. Followups should be directed as follows: - Technical matters relating to updating a driver for CAM: freebsd-scsi@freebsd.org - All other issues: freebsd-current@freebsd.org - -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 18:51:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13809 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 18:51:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA13770 for ; Wed, 15 Apr 1998 01:50:53 GMT (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yPGwg-0000UW-00; Tue, 14 Apr 1998 18:25:02 -0700 Date: Tue, 14 Apr 1998 18:24:49 -0700 (PDT) From: Tom To: bh@epigram.com cc: freebsd-scsi@FreeBSD.ORG Subject: Re: RAID performance/benchmarking In-Reply-To: <3533BBE4.DF09519@epigram.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, 14 Apr 1998, Brandon Huey wrote: > Dell PowerEdge 4200/300, 96MB RAM, 3 9GB Seagate Barracuda SCA drives > DPT PM3334UW w/64MB cache > > FreeBSD 2.2.6 > DPT kernel options: DPTOPT > DPT_MEASURE_PERFORMANCE > DPT_FREELIST_IS_STACK > > i created an array group with the dos util 'dptmgr' from default > settings. > > using IOZONE and Bonnie, i create a 128MB file for read/write > benchmarking. > > i am aware of the performance implications of RAID-5, but I am getting > about 2MByte/sec max write transfer rate compared with 19MByte/sec on > reads. > > For a pci ultrawide controller, are these figures suspect? What kind of > write performance hit should one expect w/RAID-5 ? No, those figures are typical for RAID5 on the DPT PM334 when used with the default stripe size. However, do you want to optimize your system for bonnie/iozone (sequentional and single-user)? If so, there are lot of things you can change. However, then random-access, multi-user things don't benchmark well! I have a DPT PM334UW in a mail server with a 5 disk RAID5 array, and I'm constantly amazed about how well it performs real-world tasks. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 21:09:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA11059 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 21:09:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero-fddi.simon-shapiro.org (sendero-fddi.Simon-Shapiro.ORG [206.190.148.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA11053 for ; Wed, 15 Apr 1998 04:09:54 GMT (envelope-from shimon@sendero-fddi.simon-shapiro.org) Received: (qmail 29886 invoked by uid 1000); 15 Apr 1998 04:19:13 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-040798 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199804150054.SAA24735@narnia.plutotech.com> Date: Tue, 14 Apr 1998 21:19:13 -0700 (PDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: RAID performance/benchmarking Cc: scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15-Apr-98 Justin T. Gibbs wrote: > In article you wrote: >> >> Depends on array size, type of controller, amount of cache, type of >> access. >> RAID arrays are not a good benefit for sequential access. > > This really depends. For Pluto's application, using RAID 3 not only > gives > us reliability, but also the ability to have one of the drives in a > stripe > "return late", but still maintain low latency by replacing the data > through > parity reconstruction. You are one of the few who still build RAID-3 arrays. Interesting... Since we are a realtime system where being even a > little late is unacceptable, the use of RAID gives us a big advantage. > Almost all of our accesses are sequential. I did not say that RAID arrays are not functionaly correct for Sequential access. Just that perfromance in RAID arrays is les than optimal when doing sequential access. In your case you ``do not have a choice'' but to use a RAID (3, 5 or otherwise), as you cannot afford data disruption. Simply, there is nothing free. If you want the reliability and availability that a redundant array provides, there will be a performance and capacity penalty. BTW, the next generation DPT cards does all the parity computations in hardware. Makes some difference in WRITE perfrormance and in degraded READ. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 22:24:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA23063 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 22:24:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail0.tor.acc.ca (mail0.tor.acc.ca [204.92.54.110]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23026 for ; Wed, 15 Apr 1998 05:24:26 GMT (envelope-from josh@staff.tor.acc.ca) Received: from staff.tor.acc.ca (staff.tor.acc.ca [204.92.55.27]) by mail0.tor.acc.ca (8.8.8/8.8.8) with ESMTP id BAA02472 for ; Wed, 15 Apr 1998 01:24:15 -0400 (EDT) Received: (from josh@localhost) by staff.tor.acc.ca (8.8.6/8.8.6) id BAA00572; Wed, 15 Apr 1998 01:24:15 -0400 (EDT) Message-ID: <19980415012415.17446@ican.net> Date: Wed, 15 Apr 1998 01:24:15 -0400 From: Josh Tiefenbach To: scsi@FreeBSD.ORG Subject: Still problems with CAM/NCR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just installed the 980413 snap of CAM, and I still cant get it to work. Extracts boot messages: Apr 15 01:09:55 asherah /kernel: BIOS Geometries: Apr 15 01:09:55 asherah /kernel: 0:03f8823f 0..1016=1017 cylinders, 0..130=131 heads, 1..63=63 sectors Apr 15 01:09:55 asherah /kernel: 0 accounted for Apr 15 01:09:55 asherah /kernel: Device configuration finished. Apr 15 01:09:55 asherah /kernel: Intel Pentium F00F detected, installing workaround Apr 15 01:09:55 asherah /kernel: bpf: lo0 attached Apr 15 01:09:55 asherah /kernel: ncr0: restart (scsi reset). Apr 15 01:09:55 asherah /kernel: ncr0: SCSI phase error fixup: CCB already dequeued (0xf083c200) Apr 15 01:09:55 asherah /kernel: ncr0: timeout nccb=f083c000 (skip) Apr 15 01:09:55 asherah /kernel: ncr0: timeout nccb=f0857400 (skip) [ Last line repeats until plug is pulled ] These are the same errors that I saw and reported with the 980308 snap. System recap: ncr0: rev 0x12 int a irq 10 on pci0.11.0 sd0: type 0 fixed SCSI 2 cd0: type 5 removable SCSI 2 ASUS TXP4 motherboard 3.0-CURRENT-980414. Other notable data: asherah /kernel: sd0: M_DISCONNECT received, but datapointer not saved: asherah /kernel: data=17b94 save=186b0 goal=186d4. Again, if there is any poking/testing/smacking I can do to get some more information for Justin/Kenneth/Stefan, lemme know. With the impending CAM cutover, I'd hate to see -current become unusable for me. Also, FWIW, I notice that things happen in different order between a CAM kernel, and a non-CAM kernel. The above sequence happens after all the sio/fdc initialization, whereas in a non-CAM kernel, the probe/detection of the hard drives takes place before. I dont know if this is significant, I'd just thought I'd mention it. josh -- Josh Tiefenbach - Member - ACC Corps of Internet Engineers - josh@ican.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 14 22:53:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29056 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 22:53:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA28996 for ; Wed, 15 Apr 1998 05:53:29 GMT (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id HAA10394 for scsi@FreeBSD.ORG; Wed, 15 Apr 1998 07:53:24 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id HAA12035; Wed, 15 Apr 1998 07:41:06 +0200 (CEST) (envelope-from roberto) Message-ID: <19980415074106.A11995@keltia.freenix.fr> Date: Wed, 15 Apr 1998 07:41:06 +0200 From: Ollivier Robert To: scsi@FreeBSD.ORG Subject: Re: Still problems with CAM/NCR Mail-Followup-To: scsi@FreeBSD.ORG References: <19980415012415.17446@ican.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980415012415.17446@ican.net>; from Josh Tiefenbach on Wed, Apr 15, 1998 at 01:24:15AM -0400 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4213 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Josh Tiefenbach: > Again, if there is any poking/testing/smacking I can do to get some more > information for Justin/Kenneth/Stefan, lemme know. With the impending CAM > cutover, I'd hate to see -current become unusable for me. Same here. Mike, do the FreeBSD test lab has a NCR-810 based card ? CAM seem to work fine with the NCR-875 but still pukes on my SC-200 card. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #2: Mon Apr 13 22:22:07 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 15 01:04:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA00255 for freebsd-scsi-outgoing; Wed, 15 Apr 1998 01:04:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from thing.dyn.ml.org (root@pm336-21.dialip.mich.net [35.9.11.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA00241 for ; Wed, 15 Apr 1998 08:04:06 GMT (envelope-from mcdougall@ameritech.net) Received: from ameritech.net (bsdx [192.168.1.2]) by thing.dyn.ml.org (8.8.8/8.8.7) with ESMTP id EAA14917 for ; Wed, 15 Apr 1998 04:04:01 -0400 (EDT) (envelope-from mcdougall@ameritech.net) Message-ID: <353469F0.DB7B165@ameritech.net> Date: Wed, 15 Apr 1998 04:04:00 -0400 From: Adam McDougall Reply-To: mcdougall@ameritech.net X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: scsi@FreeBSD.ORG Subject: dpt controller shutdown 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 have a dpt 2144, and I notice when halting the system, it says it shuts down the controller. I think the same is happening when the system panic's and thus cannot crashdump. Is there something I can do to make it not shutdown the controller? I have only tried forcing a panic from DDB, I dont know of any safe way otherwise to force a panic :P Any suggestions? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 15 01:59:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA08635 for freebsd-scsi-outgoing; Wed, 15 Apr 1998 01:59:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.4.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08624 for ; Wed, 15 Apr 1998 08:59:30 GMT (envelope-from Dario.Ercole@CSELT.IT) Received: from xrr1.cselt.stet.it by ss3000e.cselt.stet.it (PMDF V5.1-10 #29348) with ESMTP id <0ERG00JPQ6D26U@ss3000e.cselt.stet.it> for freebsd-scsi@FreeBSD.ORG; Wed, 15 Apr 1998 11:00:38 +0200 (MET DST) Received: by xrr1.cselt.stet.it with Internet Mail Service (5.5.1960.3) id <28WHY40V>; Wed, 15 Apr 1998 10:59:31 +0200 Content-return: allowed Date: Wed, 15 Apr 1998 10:59:30 +0200 From: Ercole Dario Subject: Problems with HP magneto-optical disk (od0) To: freebsd-scsi@FreeBSD.ORG Message-id: X-Envelope-to: freebsd-scsi@FreeBSD.ORG MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am running FreeBSD 2.2.5 on HP Vectra, with Adapted 152x SCSI controller (actually, a Jaz Jet with Adapted chipset). I need to mount a magneto-optical SCSI disk, HP SureStore 2600fx, aka C1113F, with 1024-byte blocks disks. I rebuilt the kernel including the "od0" device, and apparently the system recognizes the drive. Here is the relevant part of the "dmesg" output: --------------------------------------------------------------------- FreeBSD 2.2.5-RELEASE #0: Fri Apr 3 12:08:27 CEST 1998 CPU: Pentium (166.09-MHz 586-class CPU) real memory = 67108864 (65536K bytes) avail memory = 62529536 (61064K bytes) wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 2445MB (5008752 sectors), 4969 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 2445MB (5008752 sectors), 4969 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, accel, dma, iordis wcd0: 1378Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray wcd0: 120mm data disc loaded, unlocked aic0 at 0x340-0x35f irq 11 on isa aic0 waiting for scsi devices to settle (aic0:3:0): "HP C1113F 2.46" type 7 removable SCSI 2 od0(aic0:3:0): Optical 1243MB (1273011 1024 byte sectors) ccd0-3: Concatenated disk drivers --------------------------------------------------------- When I try to "fdisk od0", I get the following output: --------------------------------------------------------- ******* Working on device /dev/rod0 ******* parameters extracted from in-core disklabel are: cylinders=621 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=621 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 1024 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 1, size 1271807 (1241 Meg), flag 80 beg: cyl 0/ sector 2/ head 0; end: cyl 620/ sector 32/ head 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: ------------------------------------------------------- and the following error message: ------------------------------------------------------ od0: oops not queued od0: cannot find label (no disk label) od0s1: cannot find label (no disk label) ------------------------------------------------------ As I have no entry for this device in /etc/dsisktab, I use "disklabel -r -w od0 auto", that gives the followin message: ------------------------------------------------------ disklabel: ioctl DIOCSDINFO: No space left on device od0: cannot find label (no disk label) od0s1: cannot find label (no disk label) ------------------------------------------------------ The drive has a switch to configure it as "magneto-optical" or "direct access"; I configured it as "magneto-optical", as the "direct access" option allows me to see it as sd0, but the machine hangs when I try to write to the disk. Can anybody help me, please ? Thanks. -- Dario ================================================================ Dario ERCOLE - CSELT S.p.a. | I'm Winston Wolf, Via Reiss Romoli 274, 10148 Torino (Italy) | I solve problems Tel: +39 11 228 5051 - Fax: +39 11 228 5685 | e-mail: ercole@cselt.it | [Pulp Fiction] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 15 06:29:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23947 for freebsd-scsi-outgoing; Wed, 15 Apr 1998 06:29:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from psv.oss.uswest.net (psv.oss.uswest.net [204.147.85.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA23942 for ; Wed, 15 Apr 1998 13:29:50 GMT (envelope-from greg@psv.oss.uswest.net) Received: (from greg@localhost) by psv.oss.uswest.net (8.8.7/8.8.5) id IAA14522 for freebsd-scsi@FreeBSD.ORG; Wed, 15 Apr 1998 08:29:19 -0500 (CDT) From: "Greg Rowe" Message-Id: <9804151329.ZM14520@psv.oss.uswest.net> Date: Wed, 15 Apr 1998 13:29:19 +0000 X-Mailer: Z-Mail (3.2.1 10apr95) To: freebsd-scsi@FreeBSD.ORG Subject: SCSI Failures Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings, I'm having some crashes with a couple mail servers during nightly backups. The configuration is as follows: Tyan Tahoe, 300MZ Intel, 384MB 2 - Adaptec 2940UW SCSI's 3 - 4 GIG Seagate ST34572W OS Level is 2.2.5-Stable-980318 sd0-controller 0 contains /, /usr, /var, and swap sd1 & sd2 - controller 1 is ccd'd for /home and swap We are using Qmail with around 8000 maildirs on the /home partition. The problem occurs during backups of the ccd (/home) partition using cpio, but we've also seen the problem using rdist on that partition. We'll get a couple SCSI resets during the backups and then finally a crash. The crash usually occurs well into the backup. The problem does not seem to be due to bad hardware as it can be reproduced on multiple, duplicate configuration systems with a large number of maildirs. Kernel configuration for AHC is as follows: options AHC_TAGENABLE options AHC_ALLOW_MEMIO options AHC_SCBPAGING_ENABLE Dmesg on boot is: CPU: Pentium Pro (298.42-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80fbff,MTRR,PGE,MCA,CMOV> real memory = 402653184 (393216K bytes) avail memory = 392658944 (383456K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 fxp0 rev 2 int a irq 3 on pci0:11 fxp0: Ethernet address 00:a0:c9:81:1f:e1 vga0 rev 84 int a irq 11 on pci0:12 ahc0 rev 1 int a irq 9 on pci0:13 ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs ahc0 waiting for scsi devices to settle ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "SEAGATE ST34572W 0876" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4340MB (8888924 512 byte sectors) ahc1 rev 1 int a irq 10 on pci0:14 ahc1: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs ahc1 waiting for scsi devices to settle ahc1: target 0 Tagged Queuing Device (ahc1:0:0): "SEAGATE ST34572W 0876" type 0 fixed SCSI 2 sd1(ahc1:0:0): Direct-Access 4340MB (8888924 512 byte sectors) ahc1: target 1 Tagged Queuing Device (ahc1:1:0): "SEAGATE ST34572W 0876" type 0 fixed SCSI 2 sd2(ahc1:1:0): Direct-Access 4340MB (8888924 512 byte sectors) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 not found at 0x2f8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdt0 at 0x280 irq 7 on isa npx0 on motherboard npx0: INT 16 interface changing root device to sd0a ccd0-1: Concatenated disk drivers The errors we are seeing are (from dmesg): sd0(ahc0:0:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 Ordered Tag queued sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x3 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd0(ahc0:0:0): abort message in message buffer sd0(ahc0:0:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xf6 SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd0(ahc0:0:0): no longer in timeout sd0(ahc0:0:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 4 SCBs aborted sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 Ordered Tag queued sd0(ahc0:0:0): SCB 0x3 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd0(ahc0:0:0): Queueing an Abort SCB sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd0(ahc0:0:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 4 SCBs aborted sd0(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:2 sd0(ahc0:0:0): SCB 0x3 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 Ordered Tag queued sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x0 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x3 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd0(ahc0:0:0): abort message in message buffer sd0(ahc0:0:0): SCB 0x3 - timed out in dataout phase, SCSISIGI == 0xf6 SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd0(ahc0:0:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 4 SCBs aborted sd0(ahc0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 Ordered Tag queued sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x0 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x3 timedout while recovery in progress sd0(ahc0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd0(ahc0:0:0): Queueing an Abort SCB sd0(ahc0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd0(ahc0:0:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 5 SCBs aborted sd0(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:2 Again, these errors are occuring while we're backing up the sd1&sd2 ccd device. Any help would be greatly appreciated as we can't currently backup the data. Greg Rowe -- Greg Rowe US WEST - !NTERACT Internet Services "To err is human, to really foul up requires the root password." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 15 17:12:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00784 for freebsd-scsi-outgoing; Wed, 15 Apr 1998 17:12:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from psv.oss.uswest.net (psv.oss.uswest.net [204.147.85.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00729 for ; Wed, 15 Apr 1998 17:12:39 -0700 (PDT) (envelope-from greg@psv.oss.uswest.net) Received: (from greg@localhost) by psv.oss.uswest.net (8.8.7/8.8.5) id SAA17216 for freebsd-scsi@FreeBSD.ORG; Wed, 15 Apr 1998 18:42:06 -0500 (CDT) From: Greg Rowe Message-Id: <199804152342.SAA17216@psv.oss.uswest.net> Subject: Re: SCSI Failures In-Reply-To: <9804151329.ZM14520@psv.oss.uswest.net> from Greg Rowe at "Apr 15, 98 01:29:19 pm" To: freebsd-scsi@FreeBSD.ORG Date: Wed, 15 Apr 1998 18:42:06 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL32 (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 an update to this, I spent the day trying to duplicate the failures on one of the systems I'm having problems with. Using cpio to copy the /home files to /dev/null and doing similar copies of /usr on the other controller at the same time, I'm still getting failures but they are now only on sd1 and sd2 ?? This seems to make more sense, but doesn't solve the problem. My backups and rdist are over the network, so could I possibly be looking at a problem on the PCI BUS that changes the results when the ethernet card is involved ?? This is getting worrysome since I have a number of these systems in production !! A sample from todays messages: pr 15 17:29:43 muop /kernel: sd1(ahc1:0:0): SCB 0x2 - timed out in command phas e, SCSISIGI == 0x84 Apr 15 17:29:43 muop /kernel: SEQADDR = 0x47 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 Apr 15 17:29:43 muop /kernel: sd1(ahc1:0:0): abort message in message buffer Apr 15 17:29:43 muop /kernel: sd2(ahc1:1:0): SCB 0x6 timedout while recovery in progress Apr 15 17:29:43 muop /kernel: sd1(ahc1:0:0): SCB 0x3 timedout while recovery in progress Apr 15 17:29:43 muop /kernel: sd2(ahc1:1:0): SCB 0x7 timedout while recovery in progress Apr 15 17:29:44 muop /kernel: sd1(ahc1:0:0): SCB 0x5 timedout while recovery in progress Apr 15 17:29:44 muop /kernel: sd1(ahc1:0:0): SCB 0x1 timedout while recovery in progress Apr 15 17:29:44 muop /kernel: sd2(ahc1:1:0): SCB 0x4 timedout while recovery in progress Apr 15 17:29:44 muop /kernel: sd2(ahc1:1:0): SCB 0x0 timedout while recovery in progress Apr 15 17:29:45 muop /kernel: sd1(ahc1:0:0): SCB 0x2 - timed out in command phas e, SCSISIGI == 0x94 Apr 15 17:29:45 muop /kernel: SEQADDR = 0x47 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 Apr 15 17:29:45 muop /kernel: sd1(ahc1:0:0): no longer in timeout Apr 15 17:29:45 muop /kernel: ahc1: Issued Channel A Bus Reset. 8 SCBs aborted Apr 15 17:29:46 muop /kernel: sd2(ahc1:1:0): UNIT ATTENTION asc:29,2 field repl aceable unit: 2 Apr 15 17:29:46 muop /kernel: , retries:3 Apr 15 17:29:47 muop /kernel: sd1(ahc1:0:0): UNIT ATTENTION asc:29,2 field repl aceable unit: 2 Apr 15 17:29:47 muop /kernel: , retries:3 Apr 15 17:29:47 muop /kernel: sd1(ahc1:0:0): NOT READY asc:4,1 Apr 15 17:29:47 muop /kernel: sd1(ahc1:0:0): Logical unit is in process of beco ming ready field replaceable unit: 2 Apr 15 17:29:47 muop /kernel: , retries:3 Apr 15 17:29:47 muop /kernel: sd1(ahc1:0:0): NOT READY asc:4,1 Justin, Is CAM stable enough to try yet ? I can only go so long without backups (although the system runs fine as long as I don't try and back it up). Thanks, Greg > Greetings, > > I'm having some crashes with a couple mail servers during nightly backups. The > configuration is as follows: > > Tyan Tahoe, 300MZ Intel, 384MB > 2 - Adaptec 2940UW SCSI's > 3 - 4 GIG Seagate ST34572W > > OS Level is 2.2.5-Stable-980318 > sd0-controller 0 contains /, /usr, /var, and swap > sd1 & sd2 - controller 1 is ccd'd for /home and swap > > We are using Qmail with around 8000 maildirs on the /home partition. > > The problem occurs during backups of the ccd (/home) partition using cpio, but > we've also seen the problem using rdist on that partition. We'll get a couple > SCSI resets during the backups and then finally a crash. The crash usually > occurs well into the backup. The problem does not seem to be due to bad > hardware as it can be reproduced on multiple, duplicate configuration systems > with a large number of maildirs. > > Kernel configuration for AHC is as follows: > > options AHC_TAGENABLE > options AHC_ALLOW_MEMIO > options AHC_SCBPAGING_ENABLE > > Dmesg on boot is: > > CPU: Pentium Pro (298.42-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x633 Stepping=3 > Features=0x80fbff,MTRR,PGE,MCA,CMOV> > real memory = 402653184 (393216K bytes) > avail memory = 392658944 (383456K bytes) > Probing for devices on PCI bus 0: > chip0 rev 2 on pci0:0 > chip1 rev 1 on pci0:7:0 > chip2 rev 0 on pci0:7:1 > fxp0 rev 2 int a irq 3 on pci0:11 > fxp0: Ethernet address 00:a0:c9:81:1f:e1 > vga0 rev 84 int a irq 11 on pci0:12 > ahc0 rev 1 int a irq 9 on pci0:13 > ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs > ahc0 waiting for scsi devices to settle > ahc0: target 0 Tagged Queuing Device > (ahc0:0:0): "SEAGATE ST34572W 0876" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 4340MB (8888924 512 byte sectors) > ahc1 rev 1 int a irq 10 on pci0:14 > ahc1: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs > ahc1 waiting for scsi devices to settle > ahc1: target 0 Tagged Queuing Device > (ahc1:0:0): "SEAGATE ST34572W 0876" type 0 fixed SCSI 2 > sd1(ahc1:0:0): Direct-Access 4340MB (8888924 512 byte sectors) > ahc1: target 1 Tagged Queuing Device > (ahc1:1:0): "SEAGATE ST34572W 0876" type 0 fixed SCSI 2 > sd2(ahc1:1:0): Direct-Access 4340MB (8888924 512 byte sectors) > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <16 virtual consoles, flags=0x0> > sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa > sio0: type 16550A > sio1 not found at 0x2f8 > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: FIFO enabled, 8 bytes threshold > fd0: 1.44MB 3.5in > wdt0 at 0x280 irq 7 on isa > npx0 on motherboard > npx0: INT 16 interface > changing root device to sd0a > ccd0-1: Concatenated disk drivers > > The errors we are seeing are (from dmesg): > > sd0(ahc0:0:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > Ordered Tag queued > sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x3 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > sd0(ahc0:0:0): abort message in message buffer > sd0(ahc0:0:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xf6 > SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > sd0(ahc0:0:0): no longer in timeout > sd0(ahc0:0:0): no longer in timeout > ahc0: Issued Channel A Bus Reset. 4 SCBs aborted > sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == > 0x0 > SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > Ordered Tag queued > sd0(ahc0:0:0): SCB 0x3 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == > 0x0 > SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > sd0(ahc0:0:0): Queueing an Abort SCB > sd0(ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == > 0x0 > SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > sd0(ahc0:0:0): no longer in timeout > ahc0: Issued Channel A Bus Reset. 4 SCBs aborted > sd0(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:2 > sd0(ahc0:0:0): SCB 0x3 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > Ordered Tag queued > sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x0 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x3 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > sd0(ahc0:0:0): abort message in message buffer > sd0(ahc0:0:0): SCB 0x3 - timed out in dataout phase, SCSISIGI == 0xf6 > SEQADDR = 0x127 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > sd0(ahc0:0:0): no longer in timeout > ahc0: Issued Channel A Bus Reset. 4 SCBs aborted > sd0(ahc0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == > 0x0 > SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > Ordered Tag queued > sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x0 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x3 timedout while recovery in progress > sd0(ahc0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == > 0x0 > SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > sd0(ahc0:0:0): Queueing an Abort SCB > sd0(ahc0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == > 0x0 > SEQADDR = 0x175 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > sd0(ahc0:0:0): no longer in timeout > ahc0: Issued Channel A Bus Reset. 5 SCBs aborted > sd0(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:2 > > Again, these errors are occuring while we're backing up the sd1&sd2 ccd > device. Any help would be greatly appreciated as we can't currently backup the > data. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 15 22:44:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12970 for freebsd-scsi-outgoing; Wed, 15 Apr 1998 22:44:48 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles142.castles.com [208.214.165.142]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12909; Wed, 15 Apr 1998 22:44:31 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA01904; Wed, 15 Apr 1998 22:42:11 -0700 (PDT) Message-Id: <199804160542.WAA01904@antipodes.cdrom.com> Date: Wed, 15 Apr 1998 22:42:09 -0700 From: Mike Smith Subject: CAM cutover - important corrections Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To: undisclosed-recipients:; ------- Blind-Carbon-Copy X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org Subject: CAM cutover - important corrections Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Apr 1998 22:42:09 -0700 From: Mike Smith Due to a significant misunderstanding on my part, please disregard the deadline proposed in my initial post on this topic. The issues surrounding the transition to the CAM SCSI subsystem require considerably more discussion yet, and most importantly more input from both the CAM developers and the user community at large. My apologies for any confusion and/or anxiety that my extremely precipitate posting may have caused. If you have an interest in this issue, please stay tuned, as further items are likely to be raised and discussed in the near future. If at all feasible, you should endeavour to examine and experiment with the CAM test patches located at ftp://ftp.freebsd.org/pub/FreeBSD/cam Regards, - -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 17 03:51:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27110 for freebsd-scsi-outgoing; Fri, 17 Apr 1998 03:51:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from luckssv.lucksnet.or.jp (luckssv.tsuyama.lucksnet.or.jp [202.235.120.17]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA27048 for ; Fri, 17 Apr 1998 10:51:16 GMT (envelope-from sada@lucksnet.or.jp) Received: from lucksnet.or.jp (as109.tsuyama.lucksnet.or.jp [202.235.121.202]) by luckssv.lucksnet.or.jp (8.6.12+2.4W/CF3.4W-LUCKSNET-V1.00/96020510) with ESMTP id TAA25531 for ; Fri, 17 Apr 1998 19:51:14 +0900 Message-ID: <35373384.7939612F@lucksnet.or.jp> Date: Fri, 17 Apr 1998 19:48:36 +0900 From: Makoto Sadakane X-Mailer: Mozilla 4.03 [ja] (Win95; I) MIME-Version: 1.0 To: FreeBSD-scsi@FreeBSD.ORG Subject: scsi Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe FreeBSD-scsi@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 18 09:32:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11725 for freebsd-scsi-outgoing; Sat, 18 Apr 1998 09:32:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA11700 for ; Sat, 18 Apr 1998 16:32:32 GMT (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Sat, 18 Apr 1998 11:32:02 -0500 Message-ID: From: Raul Zighelboim To: "'scsi@freebsd.org'" Subject: Help ! Scsi buss going down ! Date: Sat, 18 Apr 1998 11:32:00 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello there; I have replace the drives, I have replaced the controller. I will replace the external cable, and switch from 'external active termination' to 'drive built in termination' for the scsi bus. It cannot be a driver/software issue, there are two busses involved, and it is always the same one the on with the problem. Is tehre something I am missing ? I keep getting this on the console: sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 Ordered Tag queued sd3(ahc0:2:0): SCB 0xc timedout while recovery in progress sd3(ahc0:2:0): SCB 0x5 timedout while recovery in progress sd3(ahc0:2:0): SCB 0xd timedout while recovery in progress sd4(ahc0:4:0): SCB 0xa timedout while recovery in progress sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd3(ahc0:2:0): abort message in message buffer sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xf6 SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd3(ahc0:2:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 10 SCBs aborted sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 Ordered Tag queued sd0(ahc0:3:0): SCB 0xf timedout while recovery in progress sd3(ahc0:2:0): SCB 0xd timedout while recovery in progress sd3(ahc0:2:0): SCB 0xc timedout while recovery in progress sd4(ahc0:4:0): SCB 0xa timedout while recovery in progress sd3(ahc0:2:0): SCB 0x5 timedout while recovery in progress sd0(ahc0:3:0): SCB 0x4 timedout while recovery in progress sd0(ahc0:3:0): SCB 0x2 timedout while recovery in progress sd3(ahc0:2:0): SCB 0x1 timedout while recovery in progress sd4(ahc0:4:0): SCB 0x0 timedout while recovery in progress sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd0(ahc0:3:0): Queueing an Abort SCB sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd0(ahc0:3:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 11 SCBs aborted sd0(ahc0:3:0): UNIT ATTENTION asc:29,0 sd0(ahc0:3:0): Power on, reset, or bus device reset occurred field replaceable unit: 80 , retries:2 sd3(ahc0:2:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:2 sd9(ahc0:5:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:4 sd4(ahc0:4:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:2 sd1(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:4 sd10(ahc0:6:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 , retries:4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 18 10:17:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21615 for freebsd-scsi-outgoing; Sat, 18 Apr 1998 10:17:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA21609 for ; Sat, 18 Apr 1998 17:17:19 GMT (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sat, 18 Apr 1998 13:16:45 -0400 (EDT) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA12720; Sat, 18 Apr 98 13:16:45 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id NAA03431; Sat, 18 Apr 1998 13:16:05 -0400 Message-Id: <19980418131605.A3370@ct.picker.com> Date: Sat, 18 Apr 1998 13:16:05 -0400 From: Randall Hopper To: scsi@FreeBSD.ORG Subject: SCSI Scanner question Mail-Followup-To: scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. I'm attempting to get my scanner (Microtek E6) working with -current and SANE. I'm not code-savy with SCSI, so I would appreciate any tips those with more experience could provide. I set this up first in MSW95. Works fine -- no problems. But I'd of course like to scan in FreeBSD if I could. The device probes up fine as uk0, Sane probes the device correctly as a Microtek ScanMaker E6, but when Sane tries to scan with it, it gives: scanimage: sane_start: Device busy and this appears in /var/log/messages: uk0: extraneous data discarded. uk0: COMMAND FAILED (9 0) @f0551000. Here are the particulars: dmesg: scbus0 target 6 lun 0: < Scanner 600 1.91> type 6 fixed SCSI 3 uk0 at scbus0 target 6 lun 0 uk0: Unknown setenv SANE_DEBUG_MICROTEK 100; scanimage -d microtek:/dev/scanner ... [microtek] sane_get_parameters... [microtek] sane_get_parameters: res_code = 16 (10) [microtek] sane_get_parameters: dots_per_mm: 3.937008 [microtek] sane_get_parameters: units_per_mm: 23.622047 [microtek] sane_get_parameters: lines: 0 [microtek] .wait_ready 3... [microtek] .mode_select_1 3... [microtek] .mode_sense_1... scanimage: sane_start: Device busy <----------------------- [microtek] sane_cancel...[microtek] sane_close... [microtek] sane_exit... [microtek] sane_exit: MICROTEK says goodbye. Tail of SCSIDEBUG output for "scanimage -d microtek:/dev/scanner" (enabled with "scsi -f /dev/uk0 -d 255"): /kernel: uk0(ncr0:6:0): back from sleep /kernel: uk0(ncr0:6:0): scsi_do_ioctl(0xc0605101) /kernel: uk0(ncr0:6:0): user_strategy /kernel: uk0(ncr0:6:0): scsi_cmd /kernel: uk0(ncr0:6:0): get_xs /kernel: uk0(ncr0:6:0): returning /kernel: xs(0xf06fdf00): flg(0x828)sc_link(0xf06fde80)retr(0x0)timo(0xea60)cmd(0xf06fdf58)len(0x6)data(0xf3e75f8a)len(0x24)res(0x0)err(0 x0)bp(0xf0851d00)uk0: command: 19,0,0,0,1e,0-[36 bytes] /kernel: ------------------------------ /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /kernel: 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 4f /kernel: 032: bf ef 75 a3 /kernel: ------------------------------ /kernel: uk0(ncr0:6:0): about to sleep /kernel: uk0: extraneous data discarded. <--------------------- /kernel: uk0: COMMAND FAILED (9 0) @f0551000. <--------------------- /kernel: uk0(ncr0:6:0): scsi_done /kernel: uk0: command: 19,0,0,0,1e,0-[36 bytes] /kernel: ------------------------------ /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /kernel: 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 4f /kernel: 032: bf ef 75 a3 /kernel: ------------------------------ /kernel: uk0(ncr0:6:0): calling user done() /kernel: uk0(ncr0:6:0): user-done /kernel: uk0(ncr0:6:0): timeout <--------------------- /kernel: uk0(ncr0:6:0): returned from user done() /kernel: uk0(ncr0:6:0): free_xs /kernel: uk0(ncr0:6:0): returning to adapter /kernel: uk0(ncr0:6:0): back from sleep /kernel: uk0(ncr0:6:0): ukclose: Closing device I notice that this is the the only occurance of "timeout" in the messages output. Is this significant? Regarding the "extraneous data discarded", I see in pci/ncr.c that this occurs when (cp->xerr_status == XE_EXTRA_DATA), which seems to be set in a script at the top. The comment for the set reference reads: ** The target wants to tranfer too much data ** or in the wrong direction. ** Remember that in extended error. Do I need to bump buffer sizes or timeouts somewhere? Sort of stabbing in the dark on this one, so anything you can suggest or clarify would be appreciated. Thanks, Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 18 11:18:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00915 for freebsd-scsi-outgoing; Sat, 18 Apr 1998 11:18:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00891 for ; Sat, 18 Apr 1998 18:18:12 GMT (envelope-from mike@sentex.net) Received: from ospf-mdt.sentex.net (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.6/8.6.9) with SMTP id OAA19008; Sat, 18 Apr 1998 14:16:58 -0400 (EDT) From: mike@sentex.net (Mike Tancsa) To: rzig@verio.net (Raul Zighelboim) Cc: scsi@FreeBSD.ORG Subject: Re: Help ! Scsi buss going down ! Date: Sat, 18 Apr 1998 18:06:17 GMT Message-ID: <3538eb27.495088980@mail.sentex.net> References: In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 18 Apr 1998 11:32:00 -0500, in sentex.lists.freebsd.misc you wrote: > >Hello there; I have replace the drives, I have replaced the controller. Try turning down the speed of the drives. I had a similar problem with the AHC controller on my news server. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 18 12:31:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15930 for freebsd-scsi-outgoing; Sat, 18 Apr 1998 12:31:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA15924 for ; Sat, 18 Apr 1998 19:31:40 GMT (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Sat, 18 Apr 1998 14:31:13 -0500 Message-ID: From: Raul Zighelboim To: "'mike@sentex.net'" Cc: scsi@FreeBSD.ORG Subject: RE: Help ! Scsi buss going down ! Date: Sat, 18 Apr 1998 14:31:10 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks; That will be my next step. I have replaced the power supply on external case. and I broke scsi bus 0 into 2 (so 3 controllers now) in order to have the system drive on an independent bus.... ================================================== Raul Zighelboim rzig@verio.net > -----Original Message----- > From: mike@sentex.net [SMTP:mike@sentex.net] > Sent: Saturday, April 18, 1998 1:06 PM > To: Raul Zighelboim > Cc: scsi@FreeBSD.ORG > Subject: Re: Help ! Scsi buss going down ! > > On Sat, 18 Apr 1998 11:32:00 -0500, in sentex.lists.freebsd.misc you > wrote: > > > > >Hello there; I have replace the drives, I have replaced the > controller. > > Try turning down the speed of the drives. I had a similar problem with > the AHC controller on my news server. > > ---Mike > > 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 Sat Apr 18 16:03:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20763 for freebsd-scsi-outgoing; Sat, 18 Apr 1998 16:03:34 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA20741 for ; Sat, 18 Apr 1998 23:03:28 GMT (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Sat, 18 Apr 1998 18:02:57 -0500 Message-ID: From: Raul Zighelboim To: "'Mike Tancsa'" Cc: "'scsi@freebsd.org'" , "'n@nectar.com'" Subject: RE: Help ! Scsi buss going down ! Date: Sat, 18 Apr 1998 18:02:55 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello there; more news on this issue :-( Since broke again after I replaced the power supply and add an extra ahc2940 controller... So, let's recap: - It is not the controller (we replaced the one on the failing bus) - It is not the drives (we've replaced them since the problem started) - It is not the cables (maybe it is - I had to cut longer cables to get what I needed) - It is not a corrupted / file system (the last crash, the drives that went down were not on the same bus as the / ) - It is not power (this is on a dual balanced 350W PSs). - It is not the operating system (2.2.5 2.2-stable 2.2.6 they all do the same thing) Oh, I reduced the bus speed in the spool bus (the one with the problem) from 40mb/s to 20mb/s, and I newfs the partition, just in case. ie, I've disabled. Is there a way I can tell the drives to spin at 5200 rpm instead of 7200 rpm? How solid is ccd ? ================================================== Raul Zighelboim rzig@verio.net > -----Original Message----- > From: Mike Tancsa [SMTP:mike@sentex.net] > Sent: Saturday, April 18, 1998 2:33 PM > To: Raul Zighelboim > Subject: RE: Help ! Scsi buss going down ! > > At 02:31 PM 4/18/98 -0500, Raul Zighelboim wrote: > > > >Thanks; That will be my next step. I have replaced the power supply > on > >external case. and I broke scsi bus 0 into 2 (so 3 controllers now) > in > >order to have the system drive on an independent bus.... > > > Report back to the list (and cc me) if that solves the problem, or if > you > find something else that was it. > > ---Mike > ********************************************************************** > Mike Tancsa (mike@sentex.net) * To do is to be -- > Nietzsche > Sentex Communications Corp, * To be is to do -- Sartre > Cambridge, Ontario * Do be do be do -- Sinatra > (http://www.sentex.net/~mdtancsa) * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message