From owner-freebsd-scsi Sun Feb 4 13:15: 0 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from falcon.home.hentschel.net (w002.z064221160.smf-ca.dsl.cnc.net [64.221.160.2]) by hub.freebsd.org (Postfix) with ESMTP id 963D237B4EC for ; Sun, 4 Feb 2001 13:14:38 -0800 (PST) Received: from hentschel.net (booocnc.net@localhost [127.0.0.1]) by falcon.home.hentschel.net (8.11.1/8.11.1) with ESMTP id f14LESk09844; Sun, 4 Feb 2001 13:14:30 -0800 (PST) (envelope-from thomas@hentschel.net) Message-Id: <200102042114.f14LESk09844@falcon.home.hentschel.net> Date: Sun, 4 Feb 2001 13:14:27 -0800 (PST) From: thomas@hentschel.net Subject: Re: CANNOT ACCESS T20 TAPE To: mjacob@feral.com Cc: wash@iconnect.co.ke, freebsd-scsi@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 3 Feb, Matthew Jacob wrote: > > >> (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 >> (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >> (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 [snip] >> (sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 >> (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 >> (sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 >> (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > > Well, it keeps saying h/w error. It speaks for itself. > Sorta what I guessed. Thanks for giving it a shot, though. -Th To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 13:28:10 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 7A0DC37B401 for ; Sun, 4 Feb 2001 13:27:52 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14PVyo-0003Ph-00 for freebsd-scsi@freebsd.org; Sun, 4 Feb 2001 12:41:50 -0800 Date: Sun, 4 Feb 2001 12:41:49 -0800 (PST) From: Tom Samplonius To: freebsd-scsi@freebsd.org Subject: Tags and the mly driver 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 According to camcontrol, SCSI disks attached via the mly driver are not using tagged command queuing by default. I've been investigating why the performance of the a Mylex AccelRAID 352 (mly driver) was about 30 to 40% slower than an older Mylex AccelRAID 250 (mlx driver). mly uses the CAM layer, and mlx does not. Performance was measured with postmark using 10,000 files, and 50,000 transactions. Anyhow, attempts to raise the number of tags via camcontrol via seems to work (camcontrol tags da0 -N 4), however shortly after increasing it to 16, the entire disk array hung. Are tags just unsupported on drivers that provide a virtualized SCSI interface like the mly driver? Or are there driver and/or hardware limitations that prevent them working? Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 15:28:18 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 9807E37B401 for ; Sun, 4 Feb 2001 15:27:59 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14PXr2-0003Wp-00 for freebsd-scsi@freebsd.org; Sun, 4 Feb 2001 14:41:56 -0800 Date: Sun, 4 Feb 2001 14:41:56 -0800 (PST) From: Tom Samplonius To: freebsd-scsi@freebsd.org Subject: Re: Tags and the mly driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 4 Feb 2001, Tom Samplonius wrote: ... > Anyhow, attempts to raise the number of tags via camcontrol via seems to > work (camcontrol tags da0 -N 4), however shortly after increasing it to > 16, the entire disk array hung. ... Actually even when using 2 tags (camcontrol da0 -N 2), a bit of extra disk IO will eventually hang. The mly outputs a "got AM completion on illegal slot" error to the console. I suspect that tags + mly driver is a bad combination. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 18: 9:51 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id E994037B491 for ; Sun, 4 Feb 2001 18:09:33 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f152AUc01543; Sun, 4 Feb 2001 18:10:30 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102050210.f152AUc01543@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tom Samplonius Cc: freebsd-scsi@freebsd.org Subject: Re: Tags and the mly driver In-reply-to: Your message of "Sun, 04 Feb 2001 12:41:49 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 2001 18:10:30 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > According to camcontrol, SCSI disks attached via the mly driver are not > using tagged command queuing by default. > > I've been investigating why the performance of the a Mylex AccelRAID 352 > (mly driver) was about 30 to 40% slower than an older Mylex AccelRAID 250 > (mlx driver). mly uses the CAM layer, and mlx does not. Performance was > measured with postmark using 10,000 files, and 50,000 transactions. > > Anyhow, attempts to raise the number of tags via camcontrol via seems to > work (camcontrol tags da0 -N 4), however shortly after increasing it to > 16, the entire disk array hung. > > Are tags just unsupported on drivers that provide a virtualized SCSI > interface like the mly driver? Or are there driver and/or hardware > limitations that prevent them working? I'm not entirely sure what the problem is here; it was my impression that by returning PI_TAG_ABLE in hba_inquiry from XPT_PATH_INQ that tagged command queueing would automatically be enabled. As it stands, this is probably a vindication of my general preference not to make RAID volumes look like SCSI disks - they don't typically behave anything like them, and stupid things happen when you try. Inre: your other message; the "AM completion for illegal slot" message means that the controller returned a completion status indicator for a command ID that was not actually in use. I've recently fetched all my controllers back out of storage, so with any luck, I'll be able to post a followup to this in a little while with a better answer for you. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 18:19:38 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 1BDC337B401; Sun, 4 Feb 2001 18:19:20 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14PaWr-0003fR-00; Sun, 4 Feb 2001 17:33:17 -0800 Date: Sun, 4 Feb 2001 17:33:16 -0800 (PST) From: Tom Samplonius To: Mike Smith Cc: freebsd-scsi@freebsd.org Subject: Re: Tags and the mly driver In-Reply-To: <200102050210.f152AUc01543@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 4 Feb 2001, Mike Smith wrote: ... > I've recently fetched all my controllers back out of storage, so with any > luck, I'll be able to post a followup to this in a little while with a > better answer for you. It is not hard to replicate. I happen to be using a RAID volume with 3 x 18GB disks. "camcontrol tags da0" says that there is only one opening. Setting the openings to 4 ("camcontrol tags da0 -N 4") and do a bit of heavy IO, and it will be hung within a minute. I'm doing this on a 4.2-STABLE system. P3-1000, 512MB of RAM, Mylex AccelRAID 352 with 64MB of cache. I will post some postmark results of a AccelRAID 250 vs. AccelRAID 352 on Monday. Even though the 250 only uses Ultra 2, has a slowish processor, and 16MB of cache, it is consistantly faster that the AccelRAID 352. Each was using a single RAID1 volume. The 352 was connected to faster disks though. > Regards, > Mike > > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 18:43:35 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id F3C6937B69E; Sun, 4 Feb 2001 18:43:13 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id TAA79333; Sun, 4 Feb 2001 19:43:02 -0700 (MST) (envelope-from ken) Date: Sun, 4 Feb 2001 19:43:02 -0700 From: "Kenneth D. Merry" To: Tom Samplonius Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010204194302.A79212@panzer.kdm.org> References: <200102050210.f152AUc01543@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from tom@sdf.com on Sun, Feb 04, 2001 at 05:33:16PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Feb 04, 2001 at 17:33:16 -0800, Tom Samplonius wrote: > > On Sun, 4 Feb 2001, Mike Smith wrote: > > ... > > I've recently fetched all my controllers back out of storage, so with any > > luck, I'll be able to post a followup to this in a little while with a > > better answer for you. > > It is not hard to replicate. I happen to be using a RAID volume with 3 > x 18GB disks. "camcontrol tags da0" says that there is only one opening. > Setting the openings to 4 ("camcontrol tags da0 -N 4") and do a bit of > heavy IO, and it will be hung within a minute. Hmm, that's odd, generally if there is only one opening, that means that tagged queueing is not enabled. We have a default quirk entry in the transport layer to limit any unquirked device to a minimum of two tags, if tagged queueing is enabled. What does 'camcontrol negotiate da0 -v' say? If tagged queueing isn't enabled, I wouldn't think that changing the number of tags would have any effect. In experiments here, bumping the tag count doesn't really work if the device doesn't support tagged queueing: {vladivostok:/usr/home/ken:20:0} camcontrol tags cd0 -N 4 (pass4:ahc1:0:6:0): tagged openings now 4 (pass4:ahc1:0:6:0): device openings: 1 Notice the second line. If you use the -v switch you can verify that the openings haven't been used: {vladivostok:/usr/home/ken:21:0} camcontrol tags cd0 -N 4 -v (pass4:ahc1:0:6:0): tagged openings now 4 (pass4:ahc1:0:6:0): dev_openings 1 (pass4:ahc1:0:6:0): dev_active 0 (pass4:ahc1:0:6:0): devq_openings 1 (pass4:ahc1:0:6:0): devq_queued 0 (pass4:ahc1:0:6:0): held 0 (pass4:ahc1:0:6:0): mintags 2 (pass4:ahc1:0:6:0): maxtags 255 openings + active == total Although mintags is 2 and maxtags is 255, you can't really increase it above 1 since the device doesn't support tagged queueing: {vladivostok:/usr/home/ken:22:0} camcontrol negotiate cd0 -v Current Parameters: (pass4:ahc1:0:6:0): sync parameter: 25 (pass4:ahc1:0:6:0): frequency: 10.000MHz (pass4:ahc1:0:6:0): offset: 32 (pass4:ahc1:0:6:0): bus width: 8 bits (pass4:ahc1:0:6:0): disconnection is enabled (pass4:ahc1:0:6:0): tagged queueing is disabled ahc1: SIM/HBA version: 1 ahc1: supports tag queue messages ahc1: supports SDTR message ahc1: supports 16 bit wide SCSI ahc1: HBA engine count: 0 ahc1: maximum target: 15 ahc1: maximum LUN: 63 ahc1: highest path ID in subsystem: 0 ahc1: initiator ID: 7 ahc1: SIM vendor: FreeBSD ahc1: HBA vendor: Adaptec ahc1: bus ID: 0 ahc1: base transfer speed: 3.300MB/sec You have to first attempt to enable tagged queueing like this: camcontrol negotiate da0 -T enable -a -v And if that is successful, increase the tag count. e.g.: {vladivostok:/usr/home/ken:23:0} camcontrol negotiate cd0 -T enable -a -v Current Parameters: (pass4:ahc1:0:6:0): sync parameter: 25 (pass4:ahc1:0:6:0): frequency: 10.000MHz (pass4:ahc1:0:6:0): offset: 32 (pass4:ahc1:0:6:0): bus width: 8 bits (pass4:ahc1:0:6:0): disconnection is enabled (pass4:ahc1:0:6:0): tagged queueing is disabled ahc1: SIM/HBA version: 1 ahc1: supports tag queue messages ahc1: supports SDTR message ahc1: supports 16 bit wide SCSI ahc1: HBA engine count: 0 ahc1: maximum target: 15 ahc1: maximum LUN: 63 ahc1: highest path ID in subsystem: 0 ahc1: initiator ID: 7 ahc1: SIM vendor: FreeBSD ahc1: HBA vendor: Adaptec ahc1: bus ID: 0 ahc1: base transfer speed: 3.300MB/sec Unit is ready New Parameters: (pass4:ahc1:0:6:0): sync parameter: 25 (pass4:ahc1:0:6:0): frequency: 10.000MHz (pass4:ahc1:0:6:0): offset: 32 (pass4:ahc1:0:6:0): bus width: 8 bits (pass4:ahc1:0:6:0): disconnection is enabled (pass4:ahc1:0:6:0): tagged queueing is disabled In that case, the device doesn't support tagged queueing, so I can't enable it. (When you use the -a switch, you'll see the second display of the sync, bus width, disconnection, tagged queueing, etc., which reflects the new parameters.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 20:25:36 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 26AB537B401; Sun, 4 Feb 2001 20:25:16 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14PcUY-0003lw-00; Sun, 4 Feb 2001 19:39:02 -0800 Date: Sun, 4 Feb 2001 19:38:52 -0800 (PST) From: Tom Samplonius To: "Kenneth D. Merry" Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver In-Reply-To: <20010204194302.A79212@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 4 Feb 2001, Kenneth D. Merry wrote: > On Sun, Feb 04, 2001 at 17:33:16 -0800, Tom Samplonius wrote: > > > > On Sun, 4 Feb 2001, Mike Smith wrote: > > > > ... > > > I've recently fetched all my controllers back out of storage, so with any > > > luck, I'll be able to post a followup to this in a little while with a > > > better answer for you. > > > > It is not hard to replicate. I happen to be using a RAID volume with 3 > > x 18GB disks. "camcontrol tags da0" says that there is only one opening. > > Setting the openings to 4 ("camcontrol tags da0 -N 4") and do a bit of > > heavy IO, and it will be hung within a minute. > > Hmm, that's odd, generally if there is only one opening, that means that > tagged queueing is not enabled. We have a default quirk entry in the > transport layer to limit any unquirked device to a minimum of two tags, if > tagged queueing is enabled. > > What does 'camcontrol negotiate da0 -v' say? If tagged queueing isn't > enabled, I wouldn't think that changing the number of tags would have any > effect. In experiments here, bumping the tag count doesn't really work if > the device doesn't support tagged queueing: "camcontrol tags da0 -v" output after a fresh boot: (pass0:mly0:2:0:0): dev_openings 1 (pass0:mly0:2:0:0): dev_active 0 (pass0:mly0:2:0:0): devq_openings 1 (pass0:mly0:2:0:0): devq_queued 0 (pass0:mly0:2:0:0): held 0 (pass0:mly0:2:0:0): mintags 2 (pass0:mly0:2:0:0): maxtags 255 da0 is a virtual SCSI disk via the mly driver. Since there is only one dev_opening, I'm assuming that one IO can be done at a time. Is that right? After increasing the number of tags to 4, I did run "camcontrol tags da0 -v" repeatedly, and noticed that dev_active varied between 0 and 4. However, da0 hung a short while later, just after outputting an error message from the mly driver. ... > {vladivostok:/usr/home/ken:22:0} camcontrol negotiate cd0 -v "camcontrol negotiate da0 -v" output: Current Parameters: camcontrol: XPT_GET_TRANS_SETTINGS CCB failed, status 0x6 I guess "negotiate" isn't supportted by the mly driver. That seems quite typical for virtual disks accessed via a RAID driver. The dpt driver does the same thing, but the dpt driver does seem to be using up to two tags (output from a different system with a DPT SmartRAID IV card): (pass0:dpt0:0:0:0): dev_openings 2 (pass0:dpt0:0:0:0): dev_active 0 (pass0:dpt0:0:0:0): devq_openings 2 (pass0:dpt0:0:0:0): devq_queued 0 (pass0:dpt0:0:0:0): held 0 (pass0:dpt0:0:0:0): mintags 0 (pass0:dpt0:0:0:0): maxtags 255 > Ken > -- > Kenneth Merry > ken@kdm.org Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 20:36:21 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 27EE737B65D; Sun, 4 Feb 2001 20:36:00 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA80039; Sun, 4 Feb 2001 21:35:41 -0700 (MST) (envelope-from ken) Date: Sun, 4 Feb 2001 21:35:41 -0700 From: "Kenneth D. Merry" To: Tom Samplonius Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010204213541.A79966@panzer.kdm.org> References: <20010204194302.A79212@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from tom@sdf.com on Sun, Feb 04, 2001 at 07:38:52PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Feb 04, 2001 at 19:38:52 -0800, Tom Samplonius wrote: > > On Sun, 4 Feb 2001, Kenneth D. Merry wrote: > > > On Sun, Feb 04, 2001 at 17:33:16 -0800, Tom Samplonius wrote: > > > > > > On Sun, 4 Feb 2001, Mike Smith wrote: > > > > > > ... > > > > I've recently fetched all my controllers back out of storage, so with any > > > > luck, I'll be able to post a followup to this in a little while with a > > > > better answer for you. > > > > > > It is not hard to replicate. I happen to be using a RAID volume with 3 > > > x 18GB disks. "camcontrol tags da0" says that there is only one opening. > > > Setting the openings to 4 ("camcontrol tags da0 -N 4") and do a bit of > > > heavy IO, and it will be hung within a minute. > > > > Hmm, that's odd, generally if there is only one opening, that means that > > tagged queueing is not enabled. We have a default quirk entry in the > > transport layer to limit any unquirked device to a minimum of two tags, if > > tagged queueing is enabled. > > > > What does 'camcontrol negotiate da0 -v' say? If tagged queueing isn't > > enabled, I wouldn't think that changing the number of tags would have any > > effect. In experiments here, bumping the tag count doesn't really work if > > the device doesn't support tagged queueing: > > "camcontrol tags da0 -v" output after a fresh boot: > > (pass0:mly0:2:0:0): dev_openings 1 > (pass0:mly0:2:0:0): dev_active 0 > (pass0:mly0:2:0:0): devq_openings 1 > (pass0:mly0:2:0:0): devq_queued 0 > (pass0:mly0:2:0:0): held 0 > (pass0:mly0:2:0:0): mintags 2 > (pass0:mly0:2:0:0): maxtags 255 > > da0 is a virtual SCSI disk via the mly driver. Since there is only one > dev_opening, I'm assuming that one IO can be done at a time. Is that > right? Right. > After increasing the number of tags to 4, I did run "camcontrol tags da0 > -v" repeatedly, and noticed that dev_active varied between 0 and 4. > However, da0 hung a short while later, just after outputting an error > message from the mly driver. Were there any error messages when it hung? Does the device claim to support tagged queueing in its inquiry information? (dmesg or camcontrol inquiry da0 should tell you) Since we can't determine via camcontrol negotiate whether it supports tagged queueing, we can look at the inquiry data. If it doesn't support tagged queueing, then increasing the tags is probably a bad idea. We should probably have a check in the transport layer that rejects any attempt to raise the number of tags above 1 if the device doesn't support tagged queueing. > > {vladivostok:/usr/home/ken:22:0} camcontrol negotiate cd0 -v > > "camcontrol negotiate da0 -v" output: > > Current Parameters: > camcontrol: XPT_GET_TRANS_SETTINGS CCB failed, status 0x6 > > > I guess "negotiate" isn't supportted by the mly driver. That seems > quite typical for virtual disks accessed via a RAID driver. Yep (from sys/dev/mly/mly_cam.c): default: /* we can't do this */ debug(2, "unspported func_code = 0x%x", ccb->ccb_h.func_code); ccb->ccb_h.status = CAM_REQ_INVALID; break; } > The dpt > driver does the same thing, but the dpt driver does seem to be using up to > two tags (output from a different system with a DPT SmartRAID IV card): > > (pass0:dpt0:0:0:0): dev_openings 2 > (pass0:dpt0:0:0:0): dev_active 0 > (pass0:dpt0:0:0:0): devq_openings 2 > (pass0:dpt0:0:0:0): devq_queued 0 > (pass0:dpt0:0:0:0): held 0 > (pass0:dpt0:0:0:0): mintags 0 > (pass0:dpt0:0:0:0): maxtags 255 There is a quirk entry for the DPT volumes to disable serial number inquiries and probing multiple luns. It bogusly sets mintags to 0, though. In general mintags and maxtags should be 0 and 0 for devices that don't support tagged queueing, 2 and 255 for devices that do, or some other range of values for devices that can't properly handle queue fulls. So the DPT quirk entry should be changed, but how it should be changed depends on whether or not it supports tagged queueing. What does dmesg or camcontrol inquiry say about either array? That should tell you whether the device itself believes it supports tagged queueing. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 21: 9:27 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 1718F37B401; Sun, 4 Feb 2001 21:09:05 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14PdB3-0003on-00; Sun, 4 Feb 2001 20:22:57 -0800 Date: Sun, 4 Feb 2001 20:22:56 -0800 (PST) From: Tom Samplonius To: "Kenneth D. Merry" Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver In-Reply-To: <20010204213541.A79966@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 4 Feb 2001, Kenneth D. Merry wrote: > > After increasing the number of tags to 4, I did run "camcontrol tags da0 > > -v" repeatedly, and noticed that dev_active varied between 0 and 4. > > However, da0 hung a short while later, just after outputting an error > > message from the mly driver. > > Were there any error messages when it hung? Does the device claim to > support tagged queueing in its inquiry information? (dmesg or camcontrol > inquiry da0 should tell you) > > Since we can't determine via camcontrol negotiate whether it supports > tagged queueing, we can look at the inquiry data. > > If it doesn't support tagged queueing, then increasing the tags is probably > a bad idea. We should probably have a check in the transport layer that > rejects any attempt to raise the number of tags above 1 if the device > doesn't support tagged queueing. Yes, the mly driver reported an error. I mentioned it in a previous e-mail, and it eludes me now. Something about receiving a completion for an invalid/unknown slot. If it doesn't support tags, wouldn't it die immediately, rather than try to use them for a minute or so, and then hang the disk? Since, the tag handling is likely done completely within the mly driver, it seems like something could be done to at least prevent the hang from occuring even if tags can't be used. "camcontrol inquiry da0" isn't helpful: pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number camcontrol: error getting transfer settings dmesg isn't much more helpful: da0 at mly0 bus 2 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 34680MB (71024640 512 byte sectors: 255H 63S/T 4421C) I do get the following messages just before the probe messages: mly0: physical device 0:8 gone mly0: physical device 0:8 gone mly0: physical device 0:8 gone mly0: physical device 0:8 gone mly0: physical device 0:8 gone I've always assumed this is the SAF-TE device builtin the enclosure. The Mylex card deals with the SAF-TE device events directly, and I think this is an attempt by the mly driver to attach it. Again, lots of assumptions. Either way, it seems harmless. Everything is 100% stable as long as tags = 1. > > > {vladivostok:/usr/home/ken:22:0} camcontrol negotiate cd0 -v > > > > "camcontrol negotiate da0 -v" output: > > > > Current Parameters: > > camcontrol: XPT_GET_TRANS_SETTINGS CCB failed, status 0x6 > > > > > > I guess "negotiate" isn't supportted by the mly driver. That seems > > quite typical for virtual disks accessed via a RAID driver. > > Yep (from sys/dev/mly/mly_cam.c): > > default: /* we can't do this */ > debug(2, "unspported func_code = 0x%x", ccb->ccb_h.func_code); > ccb->ccb_h.status = CAM_REQ_INVALID; > break; > } > > > The dpt > > driver does the same thing, but the dpt driver does seem to be using up to > > two tags (output from a different system with a DPT SmartRAID IV card): > > > > (pass0:dpt0:0:0:0): dev_openings 2 > > (pass0:dpt0:0:0:0): dev_active 0 > > (pass0:dpt0:0:0:0): devq_openings 2 > > (pass0:dpt0:0:0:0): devq_queued 0 > > (pass0:dpt0:0:0:0): held 0 > > (pass0:dpt0:0:0:0): mintags 0 > > (pass0:dpt0:0:0:0): maxtags 255 > > There is a quirk entry for the DPT volumes to disable serial number > inquiries and probing multiple luns. It bogusly sets mintags to 0, though. > In general mintags and maxtags should be 0 and 0 for devices that don't > support tagged queueing, 2 and 255 for devices that do, or some other range > of values for devices that can't properly handle queue fulls. > > So the DPT quirk entry should be changed, but how it should be changed > depends on whether or not it supports tagged queueing. What does dmesg or > camcontrol inquiry say about either array? > > That should tell you whether the device itself believes it supports tagged > queueing. I don't much care about the dpt issue as much as the mly one. The dpt driver at least seems to be support two outstanding IOs, which is much better than one. I've brought dpt as another example of a virtual SCSI disk driver. The dpt driver, limited to 2 openings, seems quite stable. I've never seen a problem with it under 3.5-STABLE. I've never attempted to increase the number of tags though. "camcontrol inquiry da0", where da0 is attached via a dpt driver: pass0: Fixed Direct Access SCSI-2 device camcontrol: error getting transfer settings > Ken > -- > Kenneth Merry > ken@kdm.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 21:56:59 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.dis.org (linuxgate.linuxcare.com [167.216.157.206]) by hub.freebsd.org (Postfix) with ESMTP id 1223F37B4EC for ; Sun, 4 Feb 2001 21:56:42 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f155vBs00494; Sun, 4 Feb 2001 21:57:11 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102050557.f155vBs00494@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Tom Samplonius Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver In-reply-to: Your message of "Sun, 04 Feb 2001 20:22:56 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 2001 21:57:10 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Since we can't determine via camcontrol negotiate whether it supports > > tagged queueing, we can look at the inquiry data. Well, the array supports multiple outstanding commands per logical unit (it wouldn't make a lot of sense if it didn't), but there's no need to have tags associated with them (since the driver/adapter protocol contains the equivalent of the 'tag' already). > > If it doesn't support tagged queueing, then increasing the tags is probably > > a bad idea. We should probably have a check in the transport layer that > > rejects any attempt to raise the number of tags above 1 if the device > > doesn't support tagged queueing. How do we go about telling the transport layer that multiple commands per target is OK, but that we don't care about tags? More specifically, the limit on total outstanding commands is per HBA, not per channel or per target. > Yes, the mly driver reported an error. I mentioned it in a previous > e-mail, and it eludes me now. Something about receiving a completion for > an invalid/unknown slot. This is separate, and probably represents a problem in either the firmware of the adapter (possible) or in my handling of the queues between the driver and the adapter (more likely, although I have searched long and hard for race conditions and not had much luck actually catching any). > I've always assumed this is the SAF-TE device builtin the enclosure. The > Mylex card deals with the SAF-TE device events directly, and I think this > is an attempt by the mly driver to attach it. Again, lots of assumptions. Actually, the driver should probably block attempts to access the enclosure device as well as disks listed in the array config, since the controller is meant to handle these. The driver doesn't actually attach to it - this is the generic CAM code. I'm not sure what's up with non-disk devices going away; again, probably a bug in the passthrough command handling. > I don't much care about the dpt issue as much as the mly one. The dpt The mly adapter *should* support up to the maximum number of commands supprted by the adapter per logical unit (eg. if the adapter supports 512 commands, you should be able to have that many outstanding per unit). The fact that it appears not to be doing this now is a bug, and I need to fix it. Thanks for mentioning it - Ken, if you have any suggestions based on the code in sys/dev/mly/mly_cam.c, I'd be thankful. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Feb 4 23:59:31 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from clifford.inch.com (clifford.inch.com [216.223.192.27]) by hub.freebsd.org (Postfix) with ESMTP id 41A8537B401; Sun, 4 Feb 2001 23:59:09 -0800 (PST) Received: (from omar@localhost) by clifford.inch.com (8.9.3/8.8.5) id DAA29711; Mon, 5 Feb 2001 03:03:21 -0500 Message-ID: <20010205030320.A29449@clifford.inch.com> Date: Mon, 5 Feb 2001 03:03:20 -0500 From: Omar Thameen To: Mike Smith Cc: freebsd-hardware@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Mylex AcceleRAID 150 problems [solved] References: <20010131031815.A26661@clifford.inch.com> <200101310824.f0V8ONe04278@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200101310824.f0V8ONe04278@mass.dis.org>; from Mike Smith on Wed, Jan 31, 2001 at 12:24:23AM -0800 X-Keywords: Mylex AcceleRAID 150 RAID problem booting tips hang hanging Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 31, 2001 at 12:24:23AM -0800, Mike Smith wrote: > > # mlxcontrol status -v mlxd0 > > mlxcontrol: couldn't get controller/drive for /dev/mlxd0 > > mlxd0: online > > You haven't created the /dev/mlx0 control node (bug in the application > not telling you this). Thanks - one thing that went right the other day. > > I read up on the booting process and figured I must be getting past > > boot[012] to the loader since I get the "press enter to boot immediately" > > autocount prompt, so the problem must be when it tries to read "kernel". After many days of trial & error, mailing list searching, Mylex tech support calling, and rebooting (the latter making me feel like an NT admin), I believe I've found the source of the problems. To summarize, about 3 out of 5 times, boot-up would hang at the "hit enter to continue" prompt just before reading the kernel. This abruptly changed to drive 0:0 being dead to the AcceleRAID 150 controller. To make matters worse, the Ezassist software kept hanging when I tried to access the failed drive (which was spinning and seemed fine). First problem: I had an old video card in the server which was not Plug-n-Play. This caused IRQ conflicts which I think were the reason for my frequent hangs with the Ezassist software. A new $25 card has fixed this issue. I've concluded that the more serious issue of the system hanging just as it tried to read the kernel is due to the fact that I didn't initialize the logical drive. This isn't as dumb as it sounds. The problem was that I actually believed the Ezassist software, which, after creating the RAID array stated: "RAID drive configuration is successful. You may utilize this drive immediately." I took that to mean, "Go ahead and install the OS," but apparently, initialization does something very important to the logical drive. This takes on the order of hours, depending on the size of the drives - mine were 2x9G and took 1-2 hours. For my information, what does the initialization do? Is the initialization step documented somewhere that I missed (it's not in the Mylex Install guide)? I thought that newfs'ing the filesystem would take care of things. Finally, before I put this issue to rest and get on with my life, I'll share some other things I learned along the way for the list archives (in light of putting up a separate web page of my own). - Mylex tech support were very good. They didn't find the source of my problem, but they had plenty of good ideas, and were willing to escalate the issue to an engineer. Their hours are very convenient at 6 a.m. to 6 p.m. PST, and they were always immediately available on the phone (no holding). Just as impressive was that they knew about FreeBSD, didn't once try to blame the OS, and didn't jump to the "reinstall everything" solution that seems to solve many Windows problems. - To format the drive using the RAID card, you have to change the SCSI id of the drive so the controller thinks it's a new drive, format it, then change it back. - Back up your RAID configuration to a floppy. If the config gets wiped from the card, it does read it from the hard drive, but be safe. - I upgraded the BIOS, firmware, and Ezassist software with no problems (as Mike stated it should go). To be safe, I disconnected all drives to eliminate any potential for communication problems while doing this. Warning: in my case, a config file backed up with an earlier version of Ezassist was not readable by a later version, so back up your config immediately after upgrading. This may not be true and may simply be related to my issues. - The latest version of Ezassist (2.02-00) shows the drive capacity to 3 decimal places; earlier versions (1.00-16, which came on the card) had only one. This is important because if you try and replace a failed drive in the future, that original 9G IBM Ultrastar may provide 8.542G of space, but another 9G IBM Ultrastar may provide only 8.511G. If you don't want to upgrade the software on the card, you can put the latest Ezassist on a bootable (Win95/98) disk and run it from the floppy. - Mylex tech support told me that the biggest factor in matching drives is size. The array will perform as well as the worst drive. Obviously, identical drives are ideal, but if you can't do that, match as much as possible, making sure your size is equal to or greater than the existing drive. Hope this helps someone else out there! Omar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 2:51:27 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from synology.com (dns1.synology.com [202.173.37.131]) by hub.freebsd.org (Postfix) with ESMTP id F338937B503 for ; Mon, 5 Feb 2001 02:51:09 -0800 (PST) Received: from derrenltest ([192.168.1.227]) by synology.com (8.9.3/8.9.3) with SMTP id SAA18817; Mon, 5 Feb 2001 18:53:54 +0800 Message-ID: <003901c08f63$02e6fa80$e301a8c0@derrenltest> From: "Derren" To: Cc: "JustinT. Gibbs" , Subject: Re: More target mode observations Date: Mon, 5 Feb 2001 19:01:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Following up to myself with a bit more info, >I've been tied up with things, but I'll try to look into this tomorrow. >Target mode has worked, but I must have broken something recently. >I'm sure it won't take me long to figure out what. I've let the target mode run successfully on my machine. The key is the "targbh" device. You should add it in your kernel configuration if you want to trigger the target mode functionality. Let's check ahc_handle_en_lun() in aic7xxx.c /* Allow select-in operations */ if (ahc->black_hole != NULL && ahc->enabled_luns > 0) { scsiseq = ahc_inb(ahc, SCSISEQ_TEMPLATE); scsiseq |= ENSELI; ahc_outb(ahc, SCSISEQ_TEMPLATE, scsiseq); scsiseq = ahc_inb(ahc, SCSISEQ); scsiseq |= ENSELI; ahc_outb(ahc, SCSISEQ, scsiseq); } By the way, the chip I worked on is Aic-7890. Derren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 14:28:41 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 7432137B401; Mon, 5 Feb 2001 14:28:18 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA86135; Mon, 5 Feb 2001 15:28:05 -0700 (MST) (envelope-from ken) Date: Mon, 5 Feb 2001 15:28:04 -0700 From: "Kenneth D. Merry" To: Tom Samplonius Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010205152804.A85729@panzer.kdm.org> References: <20010204213541.A79966@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from tom@sdf.com on Sun, Feb 04, 2001 at 08:22:56PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Feb 04, 2001 at 20:22:56 -0800, Tom Samplonius wrote: > On Sun, 4 Feb 2001, Kenneth D. Merry wrote: > > > > After increasing the number of tags to 4, I did run "camcontrol tags da0 > > > -v" repeatedly, and noticed that dev_active varied between 0 and 4. > > > However, da0 hung a short while later, just after outputting an error > > > message from the mly driver. > > > > Were there any error messages when it hung? Does the device claim to > > support tagged queueing in its inquiry information? (dmesg or camcontrol > > inquiry da0 should tell you) > > > > Since we can't determine via camcontrol negotiate whether it supports > > tagged queueing, we can look at the inquiry data. > > > > If it doesn't support tagged queueing, then increasing the tags is probably > > a bad idea. We should probably have a check in the transport layer that > > rejects any attempt to raise the number of tags above 1 if the device > > doesn't support tagged queueing. > > Yes, the mly driver reported an error. I mentioned it in a previous > e-mail, and it eludes me now. Something about receiving a completion for > an invalid/unknown slot. > > If it doesn't support tags, wouldn't it die immediately, rather than try > to use them for a minute or so, and then hang the disk? Since, the tag > handling is likely done completely within the mly driver, it seems like > something could be done to at least prevent the hang from occuring even if > tags can't be used. A lot of the tag handling is done in the transport layer, actually. The transport layer decides how many transactions to queue to the HBA driver. So if the transport layer thinks the HBA can handle tagged queueing, it will queue more than one transaction to the device at a time. > "camcontrol inquiry da0" isn't helpful: > > pass0: Fixed Direct Access SCSI-2 device > pass0: Serial Number > camcontrol: error getting transfer settings > > > dmesg isn't much more helpful: > > da0 at mly0 bus 2 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 34680MB (71024640 512 byte sectors: 255H 63S/T 4421C) For the dmesg at least, you would have gotten a 'Tagged Queueing Enabled' message if the device were capable of it, even though the transfer settings aren't printed out. > I do get the following messages just before the probe messages: > > mly0: physical device 0:8 gone > mly0: physical device 0:8 gone > mly0: physical device 0:8 gone > mly0: physical device 0:8 gone > mly0: physical device 0:8 gone > > I've always assumed this is the SAF-TE device builtin the enclosure. The > Mylex card deals with the SAF-TE device events directly, and I think this > is an attempt by the mly driver to attach it. Again, lots of assumptions. > Either way, it seems harmless. Everything is 100% stable as long as tags > = 1. I don't know what that message is about, but from what I can see, we should only be sending one command to that device at a time, and there shouldn't be any way we could send any more, since the device doesn't claim to support tagged queueing. So, in short, it doesn't look like your problem is related to trying to increase the tags, since I don't think you can. To verify this, try: camcontrol tags da0 -N 4 -v If the output looks like this: {lindon:/usr/home/ken:22:0} camcontrol tags cd0 -N 4 -v (pass4:ahc4:0:0:0): tagged openings now 4 (pass4:ahc4:0:0:0): dev_openings 1 (pass4:ahc4:0:0:0): dev_active 0 (pass4:ahc4:0:0:0): devq_openings 1 (pass4:ahc4:0:0:0): devq_queued 0 (pass4:ahc4:0:0:0): held 0 (pass4:ahc4:0:0:0): mintags 2 (pass4:ahc4:0:0:0): maxtags 255 Then you can't do tagged queueing and the settings aren't having any effect. If dev_openings + dev_active are greater than 1, we've got a problem, since we shouldn't be allowing that to happen for a device that doesn't claim to support tagged queueing. > > There is a quirk entry for the DPT volumes to disable serial number > > inquiries and probing multiple luns. It bogusly sets mintags to 0, though. > > In general mintags and maxtags should be 0 and 0 for devices that don't > > support tagged queueing, 2 and 255 for devices that do, or some other range > > of values for devices that can't properly handle queue fulls. > > > > So the DPT quirk entry should be changed, but how it should be changed > > depends on whether or not it supports tagged queueing. What does dmesg or > > camcontrol inquiry say about either array? > > > > That should tell you whether the device itself believes it supports tagged > > queueing. > > I don't much care about the dpt issue as much as the mly one. The dpt > driver at least seems to be support two outstanding IOs, which is much > better than one. I've brought dpt as another example of a virtual SCSI > disk driver. The dpt driver, limited to 2 openings, seems quite stable. > I've never seen a problem with it under 3.5-STABLE. I've never attempted > to increase the number of tags though. > > "camcontrol inquiry da0", where da0 is attached via a dpt driver: > > pass0: Fixed Direct Access SCSI-2 device > camcontrol: error getting transfer settings Yeah, camcontrol bails if the get transfer settings CCB fails, although you'll still see 'Tagged Queueing Enabled' in the dmesg if the array actually supports it. My guess is that the DPT driver reports queue full until we've reduced the number of tags to 2, thus the reason you get two. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 14:57:54 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id B5B0C37B69D; Mon, 5 Feb 2001 14:57:34 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA86312; Mon, 5 Feb 2001 15:57:30 -0700 (MST) (envelope-from ken) Date: Mon, 5 Feb 2001 15:57:30 -0700 From: "Kenneth D. Merry" To: Mike Smith Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010205155730.A85912@panzer.kdm.org> References: <200102050557.f155vBs00494@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102050557.f155vBs00494@mass.dis.org>; from msmith@FreeBSD.ORG on Sun, Feb 04, 2001 at 09:57:10PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ please remember to CC me ] On Sun, Feb 04, 2001 at 21:57:10 -0800, Mike Smith wrote: > > > Since we can't determine via camcontrol negotiate whether it supports > > > tagged queueing, we can look at the inquiry data. > > Well, the array supports multiple outstanding commands per logical unit > (it wouldn't make a lot of sense if it didn't), but there's no need to > have tags associated with them (since the driver/adapter protocol > contains the equivalent of the 'tag' already). > > > > If it doesn't support tagged queueing, then increasing the tags is probably > > > a bad idea. We should probably have a check in the transport layer that > > > rejects any attempt to raise the number of tags above 1 if the device > > > doesn't support tagged queueing. > > How do we go about telling the transport layer that multiple commands per > target is OK, but that we don't care about tags? There are two numbers that get passed in to cam_sim_alloc(), the maximum number of untagged commands and the maximum number of tagged commands per device. You're currently setting the number untagged commands per device to 1. Since the inquiry data from the Mylex array doesn't claim that it supports tagged queueing, the transport layer uses the number of untagged commands to determine how many transactions to send down at a time. I don't know how the board works, but one thing to keep in mind is that if you bump up the number of untagged commands, you may be able to send multiple commands to the RAID array, but you'll have to limit the number of commands you send to any other device to just one. So you'll have to do some internal queueing and checking to make sure you don't send any more than one untagged command to a device that isn't the RAID array. It might be easier to set the SID_CmdQue bit in the inquiry data, and let the transport layer handle how many commands get sent down. The only thing you'd really need to worry about as far as the tags go is the head of queue tag type -- when you get one of those, stick it at the front of the queue. :) The other tag types (simple, ordered) could just be done in FIFO order. Of course if the board doesn't support tagged queueing for devices that are accessed in passthrough mode, that might present a problem, and you might be better off using untagged commands and just making sure you don't send more than one command at a time to the non-RAID devices. > More specifically, the limit on total outstanding commands is per HBA, > not per channel or per target. The maximum number of commands per HBA is specified as an argument for cam_simq_alloc(). > > I've always assumed this is the SAF-TE device builtin the enclosure. The > > Mylex card deals with the SAF-TE device events directly, and I think this > > is an attempt by the mly driver to attach it. Again, lots of assumptions. > > Actually, the driver should probably block attempts to access the > enclosure device as well as disks listed in the array config, since the > controller is meant to handle these. The driver doesn't actually attach > to it - this is the generic CAM code. You could probably return selection timeouts for any device you didn't want CAM to talk to, if you have a way of knowing which devices those are. That would keep CAM from trying to talk to it. > I'm not sure what's up with non-disk devices going away; again, probably > a bug in the passthrough command handling. > > > I don't much care about the dpt issue as much as the mly one. The dpt > > The mly adapter *should* support up to the maximum number of commands > supprted by the adapter per logical unit (eg. if the adapter supports > 512 commands, you should be able to have that many outstanding per unit). > > The fact that it appears not to be doing this now is a bug, and I need to > fix it. Thanks for mentioning it - Ken, if you have any suggestions > based on the code in sys/dev/mly/mly_cam.c, I'd be thankful. Hopefully my comments above will help. Thanks to Justin for explaining some of it to me. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 15:17:31 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from firebat.bushong.net (c128625-a.frmt1.sfba.home.com [24.176.225.90]) by hub.freebsd.org (Postfix) with ESMTP id 8472D37B65D for ; Mon, 5 Feb 2001 15:17:14 -0800 (PST) Received: (from dbushong@localhost) by firebat.bushong.net (8.11.0/8.11.0) id f15NHEn01802 for freebsd-scsi@freebsd.org; Mon, 5 Feb 2001 15:17:14 -0800 (PST) (envelope-from dbushong) Date: Mon, 5 Feb 2001 15:17:14 -0800 From: David Bushong To: freebsd-scsi@freebsd.org Subject: confirmation: SCSI on 370DL3 is happy? Message-ID: <20010205151714.N16505@bushong.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Floating-Sheep-Port: 0xbaa Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Months back I built a machine around a SuperMicro 370DL3 motherboard with an onboard Adaptec 29160 (AIC-7892). At the time, this chipset/motherboard (/hard drive?.. was never sure) combination caused timeouts and the machine was unusable, (it has IBM 36ZX drives off of it), I popped in a Tekram DC-390U3W controller, which has been working great. I really need a spare SCSI card now, however, and would like to pull the Tekram out of this box and use it somewhere else, but the machine it's in is not one I can take down frequently. The short question being: can someone confirm that this motherboard's onboard SCSI works for them? (Hopefully someone with IBM 36ZX drives on it) Thanks! --David Bushong To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 18:48:43 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id AE6BD37B491; Mon, 5 Feb 2001 18:48:23 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14PxSP-0005UY-00; Mon, 5 Feb 2001 18:02:13 -0800 Date: Mon, 5 Feb 2001 18:02:04 -0800 (PST) From: Tom Samplonius To: "Kenneth D. Merry" Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver In-Reply-To: <20010205152804.A85729@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 5 Feb 2001, Kenneth D. Merry wrote: ... > I don't know what that message is about, but from what I can see, we should > only be sending one command to that device at a time, and there shouldn't > be any way we could send any more, since the device doesn't claim to > support tagged queueing. > > So, in short, it doesn't look like your problem is related to trying to > increase the tags, since I don't think you can. Well, that it isn't too good. That would mean CAM is serializing all IO to the mly driver, right? That would be a likely reason why the mlx based cards are faster than the mly based cards, as the mlx driver does not go through the CAM layer. In practice, cards using the mly based cards are quite a bit slower than mlx cards, even though mly based cards all have faster processors, more cache, faster SCSI channels, and 64bit PCI. > To verify this, try: > > camcontrol tags da0 -N 4 -v ... > > Then you can't do tagged queueing and the settings aren't having any > effect. If dev_openings + dev_active are greater than 1, we've got a > problem, since we shouldn't be allowing that to happen for a device that > doesn't claim to support tagged queueing. "camcontrol tags da0 -N 4" increases the number openings. I can even see that actually working a bit, as dev_active is > 1 when repeatedly checking with camcontrol. However, shortly there after, the mly driver hangs. ... > Yeah, camcontrol bails if the get transfer settings CCB fails, although > you'll still see 'Tagged Queueing Enabled' in the dmesg if the array > actually supports it. It really isn't what the array supports, but the driver, isn't it? The dpt driver presents a single virtualized SCSI disk to the CAM layer. > My guess is that the DPT driver reports queue full until we've reduced the > number of tags to 2, thus the reason you get two. > > Ken > -- > Kenneth Merry > ken@kdm.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 19: 2:57 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 491E037B401; Mon, 5 Feb 2001 19:02:38 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id UAA88324; Mon, 5 Feb 2001 20:02:30 -0700 (MST) (envelope-from ken) Date: Mon, 5 Feb 2001 20:02:30 -0700 From: "Kenneth D. Merry" To: Tom Samplonius Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010205200229.A88285@panzer.kdm.org> References: <20010205152804.A85729@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from tom@sdf.com on Mon, Feb 05, 2001 at 06:02:04PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 05, 2001 at 18:02:04 -0800, Tom Samplonius wrote: > On Mon, 5 Feb 2001, Kenneth D. Merry wrote: > > ... > > I don't know what that message is about, but from what I can see, we should > > only be sending one command to that device at a time, and there shouldn't > > be any way we could send any more, since the device doesn't claim to > > support tagged queueing. > > > > So, in short, it doesn't look like your problem is related to trying to > > increase the tags, since I don't think you can. > > Well, that it isn't too good. That would mean CAM is serializing all IO > to the mly driver, right? That would be a likely reason why the mlx > based cards are faster than the mly based cards, as the mlx driver does > not go through the CAM layer. In practice, cards using the mly based > cards are quite a bit slower than mlx cards, even though mly based cards > all have faster processors, more cache, faster SCSI channels, and 64bit > PCI. Right, all I/O to the board is being serialized. That could explain why things are slower. > > To verify this, try: > > > > camcontrol tags da0 -N 4 -v > ... > > > > Then you can't do tagged queueing and the settings aren't having any > > effect. If dev_openings + dev_active are greater than 1, we've got a > > problem, since we shouldn't be allowing that to happen for a device that > > doesn't claim to support tagged queueing. > > "camcontrol tags da0 -N 4" increases the number openings. I can even > see that actually working a bit, as dev_active is > 1 when repeatedly > checking with camcontrol. However, shortly there after, the mly driver > hangs. That shouldn't be possible. What version of FreeBSD are you using? > ... > > Yeah, camcontrol bails if the get transfer settings CCB fails, although > > you'll still see 'Tagged Queueing Enabled' in the dmesg if the array > > actually supports it. > > It really isn't what the array supports, but the driver, isn't it? The > dpt driver presents a single virtualized SCSI disk to the CAM layer. Well, it's a combination of what the card firmware supports and what the driver supports. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Feb 5 20:15: 2 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 9078E37B4EC; Mon, 5 Feb 2001 20:14:41 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14Pynu-0005aq-00; Mon, 5 Feb 2001 19:28:30 -0800 Date: Mon, 5 Feb 2001 19:28:24 -0800 (PST) From: Tom Samplonius To: "Kenneth D. Merry" Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver In-Reply-To: <20010205200229.A88285@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 5 Feb 2001, Kenneth D. Merry wrote: > > Well, that it isn't too good. That would mean CAM is serializing all IO > > to the mly driver, right? That would be a likely reason why the mlx > > based cards are faster than the mly based cards, as the mlx driver does > > not go through the CAM layer. In practice, cards using the mly based > > cards are quite a bit slower than mlx cards, even though mly based cards > > all have faster processors, more cache, faster SCSI channels, and 64bit > > PCI. > > Right, all I/O to the board is being serialized. > > That could explain why things are slower. I can't do more than about 150 to 200 tps as reported by iostat. > > > To verify this, try: > > > > > > camcontrol tags da0 -N 4 -v > > ... > > > > > > Then you can't do tagged queueing and the settings aren't having any > > > effect. If dev_openings + dev_active are greater than 1, we've got a > > > problem, since we shouldn't be allowing that to happen for a device that > > > doesn't claim to support tagged queueing. > > > > "camcontrol tags da0 -N 4" increases the number openings. I can even > > see that actually working a bit, as dev_active is > 1 when repeatedly > > checking with camcontrol. However, shortly there after, the mly driver > > hangs. > > That shouldn't be possible. What version of FreeBSD are you using? 4.2-STABLE as of a week or so ago. > > ... > > > Yeah, camcontrol bails if the get transfer settings CCB fails, although > > > you'll still see 'Tagged Queueing Enabled' in the dmesg if the array > > > actually supports it. > > > > It really isn't what the array supports, but the driver, isn't it? The > > dpt driver presents a single virtualized SCSI disk to the CAM layer. > > Well, it's a combination of what the card firmware supports and what the > driver supports. I don't anyone is making a RAID card that can only accept IO at at time from the OS. > Ken > -- > Kenneth Merry > ken@kdm.org > > Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 6 10:52: 6 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from adsl-63-193-27-229.dsl.snfc21.pacbell.net (adsl-63-193-27-229.dsl.snfc21.pacbell.net [63.193.27.229]) by hub.freebsd.org (Postfix) with SMTP id 1623137B401 for ; Tue, 6 Feb 2001 10:51:48 -0800 (PST) Received: (qmail 67755 invoked by uid 1000); 6 Feb 2001 18:51:48 -0000 Date: 6 Feb 2001 18:51:48 -0000 Message-ID: <20010206185148.67754.qmail@adsl-63-193-27-229.dsl.snfc21.pacbell.net> From: Jeff To: freebsd-scsi@freebsd.org Subject: SCSI errors with adv0 adapter and SAF CD-R8020 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm hoping someone can help shed some light on this problem. I am running FreeBSD 4.2-RELEASE and trying to use cdrecord 1.9 (from a freshly cvsup'd ports collection). The problems occur below with the stock generic kernel, and also with custom kernel with "options _KPOSIX_VERSION=199309L" line added in for priority scheduling (some discussions suggest this is helpful for cdrecord to work properly) The CD burner is a Smart And Friendly 8020 8x's writer. Relevant output from dmesg: ---------- adv0: port 0xa800-0xa8ff mem 0xe1000000-0x10000ff irq 10 at device 10.0 on pci0 adv0: Warning EEPROM Checksum mismatch. Using default device parameters adv0: AdvanySys SCSI Host Adapter, SCSI ID 7, queue depth 16 ... cd0 at adv0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) ---------- I have a 429142016 byte (~429M) .iso file (created with mkisofs) I'm trying to burn, so I run the following as root: cdrecord device=0,6,0 speed=4 mybackup.iso I have also tried with speed values of 1 and 8, with the same results. cdrecord starts up, the 'write' light on the cd burner comes on, the 'read' light flashes; a minute or two thereafter, I get the following output: (pass0:adv0:0:6:0): Timed out (pass0:adv0:0:6:0): Attempting abort (pass0:adv0:0:6:0): Timed out (pass0:adv0:0:6:0): Resetting bus adv0: No longer in timeout cdrecord: Input/output error. write_g1: scsi sendcmd: cmd timeout after 42.200 (40) s CDB: 2A 00 00 00 5E 36 00 00 1F 00 write track data: error after 49393664 bytes Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 cdrecord: Input/output error. flush cache: scsi sendcmd: retryable error CDB: 35 00 00 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 06 00 00 00 00 0A 00 00 00 00 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x6 Unit Attention, Segment 0 Sense Code: 0x29 Qual 0x00 (power on, reset, or bus device reset occurred) Fru 0x0 Sense flags: Blk 0 (not valid) resid: 14 cmd finished after 0.001s timeout 120s Trouble flushing the cache cdrecord: Input/output error. close track/session: scsi sencmd: retryable error CDB: 5B 00 02 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 72 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x72 Qual 0x04 (empty or partially written reserved track) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 480s In the error output above, it seems to have written about 49M before dying. Sometimes it gets to about 100M, it seems to vary a great deal. Has anyone seen errors like this? I'm assuming the "(pass0:adv0:0:6:0): Timed out" messages are kernel-level output: does this suggest SCSI driver or subsystem issues? The device works properly under Windows NT. If these are timeouts, are there values I can tune somewhere to fix/prevent them? I have a small stack of failed cd-r's lying uselessly in the trash, it's been frustrating. Thanks for any help, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 6 15:31:21 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CA4A937B401 for ; Tue, 6 Feb 2001 15:31:01 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA96115; Tue, 6 Feb 2001 16:30:51 -0700 (MST) (envelope-from ken) Date: Tue, 6 Feb 2001 16:30:51 -0700 From: "Kenneth D. Merry" To: Jeff Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI errors with adv0 adapter and SAF CD-R8020 Message-ID: <20010206163051.A96033@panzer.kdm.org> References: <20010206185148.67754.qmail@adsl-63-193-27-229.dsl.snfc21.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010206185148.67754.qmail@adsl-63-193-27-229.dsl.snfc21.pacbell.net>; from jeff@drunkenchipmunk.com on Tue, Feb 06, 2001 at 06:51:48PM -0000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Feb 06, 2001 at 18:51:48 -0000, Jeff wrote: > > I'm hoping someone can help shed some light on this problem. > > I am running FreeBSD 4.2-RELEASE and trying to use cdrecord 1.9 (from > a freshly cvsup'd ports collection). The problems occur below with the > stock generic kernel, and also with custom kernel with "options > _KPOSIX_VERSION=199309L" line added in for priority scheduling (some > discussions suggest this is helpful for cdrecord to work properly) > > The CD burner is a Smart And Friendly 8020 8x's writer. Relevant > output from dmesg: > ---------- > adv0: port 0xa800-0xa8ff mem 0xe1000000-0x10000ff irq 10 at device 10.0 on pci0 > adv0: Warning EEPROM Checksum mismatch. Using default device parameters > adv0: AdvanySys SCSI Host Adapter, SCSI ID 7, queue depth 16 > ... > cd0 at adv0 bus 0 target 6 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 8) > ---------- > > I have a 429142016 byte (~429M) .iso file (created with mkisofs) I'm > trying to burn, so I run the following as root: > > cdrecord device=0,6,0 speed=4 mybackup.iso > > I have also tried with speed values of 1 and 8, with the same results. > cdrecord starts up, the 'write' light on the cd burner comes on, the > 'read' light flashes; a minute or two thereafter, I get the following > output: > > (pass0:adv0:0:6:0): Timed out > (pass0:adv0:0:6:0): Attempting abort > (pass0:adv0:0:6:0): Timed out > (pass0:adv0:0:6:0): Resetting bus > adv0: No longer in timeout > cdrecord: Input/output error. write_g1: scsi sendcmd: cmd timeout after 42.200 (40) s > CDB: 2A 00 00 00 5E 36 00 00 1F 00 > write track data: error after 49393664 bytes > Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 > cdrecord: Input/output error. flush cache: scsi sendcmd: retryable error Those messages mean that the CD-R took longer than the timeout period (40 seconds) to return a write command. [ ... ] > In the error output above, it seems to have written about 49M before > dying. Sometimes it gets to about 100M, it seems to vary a great deal. > > Has anyone seen errors like this? I'm assuming the > "(pass0:adv0:0:6:0): Timed out" messages are kernel-level output: does > this suggest SCSI driver or subsystem issues? The device works > properly under Windows NT. If these are timeouts, are there values I > can tune somewhere to fix/prevent them? I have a small stack of failed > cd-r's lying uselessly in the trash, it's been frustrating. Are you using the same media under NT that you're using under FreeBSD? Do you have any other devices on that controller, and do they function properly? I talked to Justin Gibbs (author of the driver) about this, and he says that it's possible that the NT driver for that board is using different firmware than the FreeBSD driver, which could explain a difference in behavior. Anyway, he's planning on working on the Advansys driver soon, so he'd like you to file a PR describing your problem as you have in this message, except perhaps you may want to include full dmesg information, and also indicate what brand/model motherboard you're using. Also, you'll want to answer the two questions above in the PR and perhaps here on the -scsi list as well. It isn't entirely clear what the problem is, perhaps when Justin looks at the driver he may be able to reproduce your problem. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Feb 6 16:50:21 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from adsl-63-193-27-229.dsl.snfc21.pacbell.net (adsl-63-193-27-229.dsl.snfc21.pacbell.net [63.193.27.229]) by hub.freebsd.org (Postfix) with SMTP id A06C237B65D for ; Tue, 6 Feb 2001 16:49:59 -0800 (PST) Received: (qmail 69118 invoked by uid 1000); 7 Feb 2001 00:49:59 -0000 Date: 7 Feb 2001 00:49:59 -0000 Message-ID: <20010207004959.69117.qmail@adsl-63-193-27-229.dsl.snfc21.pacbell.net> From: Jeff To: ken@kdm.org Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: <20010206163051.A96033@panzer.kdm.org> (ken@kdm.org) Subject: Re: SCSI errors with adv0 adapter and SAF CD-R8020 References: <20010206185148.67754.qmail@adsl-63-193-27-229.dsl.snfc21.pacbell.net> <20010206163051.A96033@panzer.kdm.org> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ken, Thanks for the reply! To answer your questions: Yes, the same media seems to work under NT but not FreeBSD: the discs are blue TDK 650MB cd-rs. There is nothing else on the controller except for the cd writer device. Incidentally, Mike Squires replied to my message with the observation that the EEPROM checksum failed in the adv0 init part of the dmesg output. I hadn't paid too much attention to it before, but perhaps this is simply a case of controller failure...? I suppose burning a CD under Windows NT would provide more insight in that direction, but my NT installation got wrecked beyond repair over the weekend after installing some silly application (now it won't boot beyond the initial blue screen anymore). The last time I burned a CD under NT was last week, so the assumption that the device/adapter would still work under NT can't really be verified. FYI, the motherboard is an Asus P2B, with Award BIOS rev 1006. I will go ahead and file the PR with the additional information you specified. Thanks again, Jeff > > I'm hoping someone can help shed some light on this problem. > > > > I am running FreeBSD 4.2-RELEASE and trying to use cdrecord 1.9 (from > > a freshly cvsup'd ports collection). The problems occur below with the > > stock generic kernel, and also with custom kernel with "options > > _KPOSIX_VERSION=199309L" line added in for priority scheduling (some > > discussions suggest this is helpful for cdrecord to work properly) > > > > The CD burner is a Smart And Friendly 8020 8x's writer. Relevant > > output from dmesg: > > ---------- > > adv0: port 0xa800-0xa8ff mem 0xe1000000-0x10000ff irq 10 at device 10.0 on pci0 > > adv0: Warning EEPROM Checksum mismatch. Using default device parameters > > adv0: AdvanySys SCSI Host Adapter, SCSI ID 7, queue depth 16 > > ... > > cd0 at adv0 bus 0 target 6 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 10.000MB/s transfers (10.000MHz, offset 8) > > ---------- > > > > I have a 429142016 byte (~429M) .iso file (created with mkisofs) I'm > > trying to burn, so I run the following as root: > > > > cdrecord device=0,6,0 speed=4 mybackup.iso > > > > I have also tried with speed values of 1 and 8, with the same results. > > cdrecord starts up, the 'write' light on the cd burner comes on, the > > 'read' light flashes; a minute or two thereafter, I get the following > > output: > > > > (pass0:adv0:0:6:0): Timed out > > (pass0:adv0:0:6:0): Attempting abort > > (pass0:adv0:0:6:0): Timed out > > (pass0:adv0:0:6:0): Resetting bus > > adv0: No longer in timeout > > cdrecord: Input/output error. write_g1: scsi sendcmd: cmd timeout after 42.200 (40) s > > CDB: 2A 00 00 00 5E 36 00 00 1F 00 > > write track data: error after 49393664 bytes > > Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 > > cdrecord: Input/output error. flush cache: scsi sendcmd: retryable error > > Those messages mean that the CD-R took longer than the timeout period (40 > seconds) to return a write command. > > [ ... ] > > > In the error output above, it seems to have written about 49M before > > dying. Sometimes it gets to about 100M, it seems to vary a great deal. > > > > Has anyone seen errors like this? I'm assuming the > > "(pass0:adv0:0:6:0): Timed out" messages are kernel-level output: does > > this suggest SCSI driver or subsystem issues? The device works > > properly under Windows NT. If these are timeouts, are there values I > > can tune somewhere to fix/prevent them? I have a small stack of failed > > cd-r's lying uselessly in the trash, it's been frustrating. > > Are you using the same media under NT that you're using under FreeBSD? > > Do you have any other devices on that controller, and do they function > properly? > > I talked to Justin Gibbs (author of the driver) about this, and he says > that it's possible that the NT driver for that board is using different > firmware than the FreeBSD driver, which could explain a difference in > behavior. > > Anyway, he's planning on working on the Advansys driver soon, so he'd like > you to file a PR describing your problem as you have in this message, > except perhaps you may want to include full dmesg information, and also > indicate what brand/model motherboard you're using. > > Also, you'll want to answer the two questions above in the PR and perhaps > here on the -scsi list as well. > > It isn't entirely clear what the problem is, perhaps when Justin looks at > the driver he may be able to reproduce your problem. > > Ken > -- > Kenneth Merry > ken@kdm.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 7 14:51:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 32EB437B6BF; Wed, 7 Feb 2001 14:51:27 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA05444; Wed, 7 Feb 2001 15:51:19 -0700 (MST) (envelope-from ken) Date: Wed, 7 Feb 2001 15:51:19 -0700 From: "Kenneth D. Merry" To: Tom Samplonius Cc: Mike Smith , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010207155119.B5264@panzer.kdm.org> References: <20010205200229.A88285@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from tom@sdf.com on Mon, Feb 05, 2001 at 07:28:24PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 05, 2001 at 19:28:24 -0800, Tom Samplonius wrote: > On Mon, 5 Feb 2001, Kenneth D. Merry wrote: > > > > camcontrol tags da0 -N 4 -v > > > ... > > > > > > > > Then you can't do tagged queueing and the settings aren't having any > > > > effect. If dev_openings + dev_active are greater than 1, we've got a > > > > problem, since we shouldn't be allowing that to happen for a device that > > > > doesn't claim to support tagged queueing. > > > > > > "camcontrol tags da0 -N 4" increases the number openings. I can even > > > see that actually working a bit, as dev_active is > 1 when repeatedly > > > checking with camcontrol. However, shortly there after, the mly driver > > > hangs. > > > > That shouldn't be possible. What version of FreeBSD are you using? > > 4.2-STABLE as of a week or so ago. Okay, here's something to try. Boot with -v, and see if you get any tagged openings messages after you issue the 'camcontrol tags da0 -N 4' command. If you do, then for some reason the inquiry data for the RAID array is reporting that it can do tagged queueing, despite the fact that dmesg doesn't show it. If you don't see those messages, then I don't see how you're seeing more than one tag in the output of 'camcontrol tags da0 -v'. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 7 20:10:17 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 42BF037B401 for ; Wed, 7 Feb 2001 20:09:58 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f184BH907296; Wed, 7 Feb 2001 20:11:17 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102080411.f184BH907296@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Kenneth D. Merry" Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver In-reply-to: Your message of "Mon, 05 Feb 2001 15:57:30 MST." <20010205155730.A85912@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Feb 2001 20:11:17 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > How do we go about telling the transport layer that multiple commands per > > target is OK, but that we don't care about tags? > > There are two numbers that get passed in to cam_sim_alloc(), the maximum > number of untagged commands and the maximum number of tagged commands per > device. cam_sim_alloc(mly_cam_action, mly_cam_poll, "mly", sc, device_get_unit(sc->mly_dev), max untagged -> 1, max tagged -> sc->mly_controllerinfo->maximum_parallel_commands, devq) > You're currently setting the number untagged commands per device to 1. Gotcha. > Since the inquiry data from the Mylex array doesn't claim that it supports > tagged queueing, the transport layer uses the number of untagged commands > to determine how many transactions to send down at a time. Ah, ok. Since I create a separate sim for each channel, and since the array devices are on virtual channels separate from the passthrough devices, it should be relatively straightforward to adjust this accordingly so that the untagged command limit is raised for the array devices. > Of course if the board doesn't support tagged queueing for devices that are > accessed in passthrough mode, that might present a problem, and you might > be better off using untagged commands and just making sure you don't send > more than one command at a time to the non-RAID devices. It does, but they're kept segregated. > > > I've always assumed this is the SAF-TE device builtin the enclosure. The > > > Mylex card deals with the SAF-TE device events directly, and I think this > > > is an attempt by the mly driver to attach it. Again, lots of assumptions. > > > > Actually, the driver should probably block attempts to access the > > enclosure device as well as disks listed in the array config, since the > > controller is meant to handle these. The driver doesn't actually attach > > to it - this is the generic CAM code. > > You could probably return selection timeouts for any device you didn't want > CAM to talk to, if you have a way of knowing which devices those are. That > would keep CAM from trying to talk to it. This is how I currently handle the disks that are part of the array. > Hopefully my comments above will help. Thanks to Justin for explaining > some of it to me. Very much so, I think. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Feb 7 20:12:58 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id E10B537B401; Wed, 7 Feb 2001 20:12:39 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA07989; Wed, 7 Feb 2001 21:12:39 -0700 (MST) (envelope-from ken) Date: Wed, 7 Feb 2001 21:12:39 -0700 From: "Kenneth D. Merry" To: Mike Smith Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010207211239.A7966@panzer.kdm.org> References: <20010205155730.A85912@panzer.kdm.org> <200102080411.f184BH907296@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200102080411.f184BH907296@mass.dis.org>; from msmith@FreeBSD.ORG on Wed, Feb 07, 2001 at 08:11:17PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Feb 07, 2001 at 20:11:17 -0800, Mike Smith wrote: > > > How do we go about telling the transport layer that multiple commands per > > > target is OK, but that we don't care about tags? > > > > There are two numbers that get passed in to cam_sim_alloc(), the maximum > > number of untagged commands and the maximum number of tagged commands per > > device. > > > cam_sim_alloc(mly_cam_action, > mly_cam_poll, > "mly", > sc, > device_get_unit(sc->mly_dev), > max untagged -> 1, > max tagged -> sc->mly_controllerinfo->maximum_parallel_commands, > devq) Correct. > > Since the inquiry data from the Mylex array doesn't claim that it supports > > tagged queueing, the transport layer uses the number of untagged commands > > to determine how many transactions to send down at a time. > > Ah, ok. Since I create a separate sim for each channel, and since the > array devices are on virtual channels separate from the passthrough > devices, it should be relatively straightforward to adjust this > accordingly so that the untagged command limit is raised for the array > devices. That'll work. > > > Actually, the driver should probably block attempts to access the > > > enclosure device as well as disks listed in the array config, since the > > > controller is meant to handle these. The driver doesn't actually attach > > > to it - this is the generic CAM code. > > > > You could probably return selection timeouts for any device you didn't want > > CAM to talk to, if you have a way of knowing which devices those are. That > > would keep CAM from trying to talk to it. > > This is how I currently handle the disks that are part of the array. Cool! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 8 6:40:45 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail2.caramail.com (mail2.caramail.com [195.68.99.69]) by hub.freebsd.org (Postfix) with ESMTP id 73EE837B401 for ; Thu, 8 Feb 2001 06:40:27 -0800 (PST) Received: from caramail.com (www5.caramail.com [195.68.99.25]) by mail2.caramail.com (8.8.8/8.8.8) with SMTP id PAA29639 for freebsd-scsi@freebsd.org; Thu, 8 Feb 2001 15:43:00 GMT Posted-Date: Thu, 8 Feb 2001 15:43:00 GMT From: patatorz@caramail.com To: freebsd-scsi@freebsd.org Message-ID: <981646980007631@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [192.11.224.101] Mime-Version: 1.0 Subject: initio 9100 driver & kernel Date: Thu, 08 Feb 2001 15:43:00 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_007631981646980_ID" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_007631981646980_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm new at FreeBSD (not Unix), and I want to use my 9100UW initio scsi card with FreeBSD 4.1; I have the driver for the card (available on www.initio.com, that are design for FreeBSD 4.x ), but instructions (see at the end of message) they give are for 3.x serie (I think); so what lines I must include in the config files (and may be in /dev) to get the driver work ? thanks -------------------------------------------------------- Copy the 3 source code files to /usr/src/sys/pci Add one line in /usr/src/sys/conf/files: /pci/i91u.c Enter /usr/src/sys/i386/conf, copy the GENERIC configuration file to the name you want to give your kernel, MY9100 for example. Add one line in MY9100: controller iha0 Type the following to compile and install your kernel: # /usr/sbin/config MY9100 # cd ../../compile/MY9100 # make depend # make # make install --------------------------------------------------------- _________________________________________________________ Le journal des abonn=E9s Caramail - http://www.carazine.com --=_NextPart_Caramail_007631981646980_ID-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 8 13:55:59 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 3E47D37B4EC for ; Thu, 8 Feb 2001 13:55:41 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 8 Feb 2001 21:55:40 +0000 (GMT) To: scsi@freebsd.org Cc: iedowse@maths.tcd.ie Subject: Solved: Corruption on ahc reads - seems PCI latency related In-Reply-To: Your message of "Wed, 31 Jan 2001 22:53:10 GMT." <200101312253.aa86550@salmon.maths.tcd.ie> Date: Thu, 08 Feb 2001 21:55:40 +0000 From: Ian Dowse Message-ID: <200102082155.aa15040@salmon.maths.tcd.ie> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200101312253.aa86550@salmon.maths.tcd.ie>, Ian Dowse writes: > >We have a heavily loaded 4.2-STABLE NFS fileserver machine that >has recently developed a file corruption problem. The corruption >seems to be occurring during reads from one SCSI disk (da0). It >appears that small regions (usually 18 bytes) of a read are 'missed', >so the buffer cache ends up with mostly the new data, but some >bytes are from whatever happened to be in the buffer cache before >the read. Just so that this information goes into the archives: Tor Egge spotted a case in the ahc sequencer code where a known hardware bug in this card might not have been dealt with correctly. Justin Gibbs suggested the patch below, which is a slight simplification of Tor's proposal. The FIFOEMP status bit suffers from glitches, so the optimisation removed by this patch would occasionally skip a necessary manual flush operation. Since applying this patch, we have seen no more corruption. Justin has this fix in his local tree now, so it will get committed soon. Ian Index: aic7xxx.seq =================================================================== RCS file: /FreeBSD/FreeBSD-CVS/src/sys/dev/aic7xxx/aic7xxx.seq,v retrieving revision 1.94.2.8 diff -u -r1.94.2.8 aic7xxx.seq --- aic7xxx.seq 2001/01/27 20:56:27 1.94.2.8 +++ aic7xxx.seq 2001/02/06 23:22:00 @@ -904,9 +904,6 @@ test DFCNTRL, DIRECTION jnz ultra2_dmafifoempty; and DFCNTRL, ~SCSIEN; test DFCNTRL, SCSIEN jnz .; - if ((ahc->bugs & AHC_AUTOFLUSH_BUG) != 0) { - test DFSTATUS, FIFOEMP jnz ultra2_dmafifoempty; - } ultra2_dmafifoflush: if ((ahc->bugs & AHC_AUTOFLUSH_BUG) != 0) { /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 8 15:15:17 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail2.clarkson.edu (mail2.clarkson.edu [128.153.4.13]) by hub.freebsd.org (Postfix) with SMTP id C697137C157 for ; Thu, 8 Feb 2001 15:14:58 -0800 (PST) Received: (qmail 27736 invoked by uid 0); 8 Feb 2001 23:14:56 -0000 Received: from vador.aoc.clarkson.edu (128.153.130.33) by mail.clarkson.edu with SMTP; 8 Feb 2001 23:14:56 -0000 Date: Thu, 8 Feb 2001 18:13:18 -0500 (EST) From: Todd Cohen X-Sender: cohentl@vador.aoc.clarkson.edu To: freebsd-scsi@freebsd.org Subject: compile error/DC315U Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I figured I'd forward this here since someone else may be able to help. Sorry if it's not on-topic enough. -Todd ---------- Forwarded message ---------- Date: Wed, 7 Feb 2001 18:43:14 -0500 (EST) From: Todd Cohen To: erich@tekram.com.tw Subject: compile error Hi, I'm trying to compile in support for my DC315U into FreeBSD 4.2-STABLE. I used the files you sent me in an e-mail a few weeks ago and made the following changes: I copied dc395x_trm.c and dc395x_trm.h to /usr/src/sys/pci I added the following to /usr/src/sys/conf/files pci/dc395x_trm.c optional tekram_trm (NOTE: I removed device-driver, since config complained about it) I then added the following to the end of my kernel config file device tekram_trm0 when I tried compiling, I got the following error, any ideas on how to fix this? -Todd cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing -prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -no stdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c linking kernel dc395x_trm.o: In function `DC395x_trm_ExecuteSRB': dc395x_trm.o(.text+0x31e): undefined reference to `xpt_done' dc395x_trm.o: In function `DC395x_trm_action': dc395x_trm.o(.text+0x58f): undefined reference to `xpt_done' dc395x_trm.o(.text+0x616): undefined reference to `xpt_freeze_simq' dc395x_trm.o(.text+0x672): undefined reference to `xpt_done' dc395x_trm.o(.text+0x94c): undefined reference to `xpt_done' dc395x_trm.o(.text+0x9b5): undefined reference to `xpt_done' dc395x_trm.o: In function `DC395x_trm_reset': dc395x_trm.o(.text+0xbab): undefined reference to `xpt_async' dc395x_trm.o: In function `DC395x_trm_SetXferRate': dc395x_trm.o(.text+0x1b3d): undefined reference to `xpt_setup_ccb' dc395x_trm.o(.text+0x1b4b): undefined reference to `xpt_async' dc395x_trm.o: In function `DC395x_trm_SRBdone': dc395x_trm.o(.text+0x217d): undefined reference to `xpt_done' dc395x_trm.o: In function `DC395x_trm_DoingSRB_Done': dc395x_trm.o(.text+0x21e0): undefined reference to `xpt_done' dc395x_trm.o: In function `DC395x_trm_attach': dc395x_trm.o(.text+0x2fc6): undefined reference to `cam_simq_alloc' dc395x_trm.o(.text+0x2ffe): undefined reference to `cam_sim_alloc' dc395x_trm.o(.text+0x3019): undefined reference to `cam_simq_free' dc395x_trm.o(.text+0x3026): undefined reference to `xpt_bus_register' dc395x_trm.o(.text+0x3051): undefined reference to `xpt_create_path' dc395x_trm.o(.text+0x3079): undefined reference to `xpt_bus_deregister' dc395x_trm.o(.text+0x3083): undefined reference to `cam_sim_free' *** Error code 1 Stop in /usr/src/sys/compile/TOAD. supertoad# __________________________________________________________________________ ICMP: The protocol that goes PING! I like angles, but only to a degree. cthread. cthread_fork(). Fork, thread, fork! Black holes suck. http://wckn.clarkson.edu/~cohentl/ Real_men_don't_need_spacebars. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 8 15:53:44 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 75F1237B684 for ; Thu, 8 Feb 2001 15:53:26 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA15644; Thu, 8 Feb 2001 16:53:20 -0700 (MST) (envelope-from ken) Date: Thu, 8 Feb 2001 16:53:20 -0700 From: "Kenneth D. Merry" To: Todd Cohen Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: compile error/DC315U Message-ID: <20010208165319.A15329@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from cohentl@clarkson.edu on Thu, Feb 08, 2001 at 06:13:18PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Feb 08, 2001 at 18:13:18 -0500, Todd Cohen wrote: > I figured I'd forward this here since someone else may be able to help. > Sorry if it's not on-topic enough. You probably need the scbus, da, cd, pass, sa, etc. devices. Have a look in GENERIC and see the standard SCSI devices. > ---------- Forwarded message ---------- > Date: Wed, 7 Feb 2001 18:43:14 -0500 (EST) > From: Todd Cohen > To: erich@tekram.com.tw > Subject: compile error [ ... ] > when I tried compiling, I got the following error, any ideas on how to fix > this? > > -Todd > > > cc -c -O -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing > -prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -ansi -no > stdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h > -elf > -mpreferred-stack-boundary=2 vers.c > linking kernel > dc395x_trm.o: In function `DC395x_trm_ExecuteSRB': > dc395x_trm.o(.text+0x31e): undefined reference to `xpt_done' > dc395x_trm.o: In function `DC395x_trm_action': > dc395x_trm.o(.text+0x58f): undefined reference to `xpt_done' > dc395x_trm.o(.text+0x616): undefined reference to `xpt_freeze_simq' > dc395x_trm.o(.text+0x672): undefined reference to `xpt_done' > dc395x_trm.o(.text+0x94c): undefined reference to `xpt_done' > dc395x_trm.o(.text+0x9b5): undefined reference to `xpt_done' [ ... ] Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 8 16: 6:52 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail2.clarkson.edu (majordomo.clarkson.edu [128.153.4.13]) by hub.freebsd.org (Postfix) with SMTP id 9DE2637B491 for ; Thu, 8 Feb 2001 16:06:33 -0800 (PST) Received: (qmail 4744 invoked by uid 0); 9 Feb 2001 00:06:28 -0000 Received: from vador.aoc.clarkson.edu (128.153.130.33) by mail.clarkson.edu with SMTP; 9 Feb 2001 00:06:28 -0000 Date: Thu, 8 Feb 2001 19:04:52 -0500 (EST) From: Todd Cohen X-Sender: cohentl@vador.aoc.clarkson.edu To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: compile error/DC315U In-Reply-To: <20010208165319.A15329@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ooops.. thanks for pointing out my obvious error :) Can't believe I forgot those... -Todd On Thu, 8 Feb 2001, Kenneth D. Merry wrote: > On Thu, Feb 08, 2001 at 18:13:18 -0500, Todd Cohen wrote: > > I figured I'd forward this here since someone else may be able to help. > > Sorry if it's not on-topic enough. > > You probably need the scbus, da, cd, pass, sa, etc. devices. > > Have a look in GENERIC and see the standard SCSI devices. > > > ---------- Forwarded message ---------- > > Date: Wed, 7 Feb 2001 18:43:14 -0500 (EST) > > From: Todd Cohen > > To: erich@tekram.com.tw > > Subject: compile error > > [ ... ] > > > when I tried compiling, I got the following error, any ideas on how to fix > > this? > > > > -Todd > > > > > > cc -c -O -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing > > -prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > > -ansi -no > > stdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h > > -elf > > -mpreferred-stack-boundary=2 vers.c > > linking kernel > > dc395x_trm.o: In function `DC395x_trm_ExecuteSRB': > > dc395x_trm.o(.text+0x31e): undefined reference to `xpt_done' > > dc395x_trm.o: In function `DC395x_trm_action': > > dc395x_trm.o(.text+0x58f): undefined reference to `xpt_done' > > dc395x_trm.o(.text+0x616): undefined reference to `xpt_freeze_simq' > > dc395x_trm.o(.text+0x672): undefined reference to `xpt_done' > > dc395x_trm.o(.text+0x94c): undefined reference to `xpt_done' > > dc395x_trm.o(.text+0x9b5): undefined reference to `xpt_done' > > [ ... ] > > Ken > -- > Kenneth Merry > ken@kdm.org > __________________________________________________________________________ ICMP: The protocol that goes PING! I like angles, but only to a degree. cthread. cthread_fork(). Fork, thread, fork! Black holes suck. http://wckn.clarkson.edu/~cohentl/ Real_men_don't_need_spacebars. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 9 9:22:23 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by hub.freebsd.org (Postfix) with ESMTP id 5538437D642 for ; Fri, 9 Feb 2001 09:21:21 -0800 (PST) Received: (from j@localhost) by ida.interface-business.de id f19HLGj03791 for freebsd-scsi@freebsd.org; Fri, 9 Feb 2001 18:21:16 +0100 (MET) Date: Fri, 9 Feb 2001 18:21:16 +0100 From: J Wunsch To: freebsd-scsi@freebsd.org Subject: Problems with AIC7770-based controller on -current Message-ID: <20010209182116.P822@ida.interface-business.de> Reply-To: Joerg Wunsch Mail-Followup-To: freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface systems GmbH, Dresden Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Please retain me in the Cc list when replying, i'm currently not subscribed to this list.] Hello *, after upgrading this old EISA machine to -current (as of a couple of days ago), it no longer works. First there was a typo in eisaconf.c (i just committed a fix), but now that it at least scans the EISA bus again, the ahc driver no longer wants to talk to my disks. With a kernel from June 2000, the machine shows the following SCSI- related hardware: isab0: at device 2.0 on pci0 eisa0: on isab0 mainboard0: on eisa0 slot 0 ahc0: at 0x2c00-0x2cff, irq 11 (level) ahc0: on eisa0 slot 2 ahc0: aic7770 >= Rev E, Twin Channel, A SCSI Id=7, B SCSI Id=7, primary B, 4/255 SCBs ... da0 at ahc0 bus 1 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1717MB (3517856 512 byte sectors: 255H 63S/T 218C) da1 at ahc0 bus 1 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 1033MB (2117025 512 byte sectors: 255H 63S/T 131C) da2 at ahc0 bus 1 target 4 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 1033MB (2117025 512 byte sectors: 255H 63S/T 131C) Now, as soon as /etc/rc is starting, i get error messages as shown below. Note that i typed that manually from the terminal, so any typos are mine. I tried disconnecting all the disks except da0, i tried compiling a kernel with mintags=0, no help. Anybody any ideas about it? The machine is not highly important, but it would be great to get it running again. ahc0: Unexpexted busfree in Data-in phase SEQADDR == 0x14b ahc0:B:4: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_SCSIID == 0xc7, SAVED_LUN == 0x0, ARG_1 == 0xff ACCUM = 0x80 SEQ_FLAGS == 0x0, SCBPTR == 0x1, BTT == 0xf, SINDEX == 0x31 SCCSID == 0x17, SCB_SCCSID == 0x97, SCB_LUN == 0x0, SCB_TAG == 0x8, SCB_CONTROL == 0x44 SCSIBUSL == 0x7, SCSISIGI == 0x44 SXFRCTL0 == 0x8 SEQCTL == 0x10 ahc0: Dumping Card State at SEQADDR 0x19a SCB count = 20 Kernel NEXTQSCB = 9 Card NEXTQSCB = 9 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 1:8 2:0 0:15 QOUTFIFO entries: Sequencer Free SCB list: 3 Pending list: 8 0 15 Kernel Free SCB list: 5 16 17 1 18 19 2 3 4 6 7 14 13 12 11 10 Untagged Q(1): 8 Untagged Q(4): 15 -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 9 21: 5:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from uxtpaprx1.pwcglobal.com (uxtpaprx1.pwcglobal.com [12.26.159.121]) by hub.freebsd.org (Postfix) with ESMTP id 54BD137B503 for ; Fri, 9 Feb 2001 21:05:26 -0800 (PST) Received: by uxtpaprx1.pwcglobal.com; id AAA29215; Sat, 10 Feb 2001 00:02:12 -0500 (EST) From: Received: from uxtpabuf1.us.pw.com(10.26.104.81) by uxtpaprx1.us.pw.com via smap (V5.5) id xma028727; Sat, 10 Feb 01 00:01:40 -0500 Received: from us-amsmta005.us.pw.com by uxtpabuf1.us.pw.com (PMDF V5.1-12 #U3932) with ESMTP id <0G8I00KHTZDMRW@uxtpabuf1.us.pw.com> for scsi@freebsd.org; Sat, 10 Feb 2001 00:03:22 -0500 (EST) Date: Sat, 10 Feb 2001 00:04:20 -0500 Subject: Re: Unsupported Hardware To: scsi@freebsd.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.6 |December 14, 2000) at 02/10/2001 12:04:40 AM Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was ondering if anyone is working on a CAM for the ULTRASTOR 14F SCSI card. I was refered to this list by Mike Meyer... Any sugestions or comments will be greatly appreciated! Thanks, Sam Maniotes ---------------------- Forwarded by Sam Maniotes/US/GTS/PwC on 02/10/2001 12:01 AM --------------------------- Mike Meyer on 02/09/2001 10:19:02 PM To: Sam Maniotes/US/GTS/PwC cc: questions@freebsd.org Subject: Re: Unsupported Hardware sam.maniotes@us.pwcglobal.com types: > I recently purchased FreeBSD and I have an UltraStor 14F SCSI card in the > PC I wish to install the OS. > > Is there any estimated time frame when the drivers for this SCSI card will > be available to run with the CAM? Please remember that FreeBSD is a volunteer project. People do things because they need them themselves, think they are interesting, or out of the goodness of their hearts. That includes reading and answering this list, BTW. With that in mind, you need to find out if anyone is working on this card, and ask them. You are most likely to find that person on scsi@freebsd.org. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 9 22: 6:18 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail1.panix.com (mail1.panix.com [166.84.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 0DE7937B401 for ; Fri, 9 Feb 2001 22:05:56 -0800 (PST) Received: from panix2.panix.com (panix2.panix.com [166.84.0.227]) by mail1.panix.com (Postfix) with ESMTP id 937A548784; Sat, 10 Feb 2001 00:59:32 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.8.8/8.7.1/PanixN1.0) id AAA23954; Sat, 10 Feb 2001 00:59:32 -0500 (EST) Date: Sat, 10 Feb 2001 0:59:32 EST From: Ken Harrenstien Reply-To: klh@alum.mit.edu To: Darren Joy Cc: klh@panix.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release Message-ID: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Was searching through the archives to see if anyone else has had problems similar to mine, and found yours. I was wondering if there had been any further resolution since the last round of messages circa 7-Jan-2001? If not, perhaps my info will add some data for Gerard or others. My story is that I just now began trying to move from 3.3 to 4.2 (because only 4.x can understand large ATA drives, sigh) and ran into some odd error messages that look like this: sym0:0: message d sent on bad reselection. sym0:0:control msgout: 80 20 35 d. I have a Tekram DC390-U2W and this problem is happening with a Conner CFP1080S (Conner again... hmmm). Tagged Queueing is enabled. It isn't frequent, but I haven't tried much yet. Happened once during shutdown for a reboot (which wedged things and required a fsck after resetting the CPU), again upon logging in after a night of running idle. There are currently two other devices on the SCSI chain but they should be completely unused (nothing is mounted from them). I would have used the NCR driver, except I couldn't figure out how to coerce the new 4.2 /usr/sbin/config to accept the setting of SCSI_NCR_DFLT_SYNC=6 which is required in order to use LVD drives at full 80Mb/s speed. Grumble. Different topic. Was hoping SYM would work without this fussing, but until I understand what's going on with "bad reselection" I'm not going to put my LVD drives on this system. Here's the dmesg since it always seems to be asked for. Apologies if it turns out to be unnecessary! --Ken -------------- ghost:~> dmesg Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-RELEASE #0: Fri Feb 9 01:52:53 PST 2001 klh@ghost:/usr/src/sys/compile/PCKLH-300 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300683344 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 268419072 (262128K bytes) avail memory = 257679360 (251640K bytes) Preloaded elf kernel "kernel" at 0xc039f000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: at 4.2 chip1: port 0xe800-0xe80f at device 4.3 on pci0 sym0: <895> port 0xd000-0xd0ff mem 0xe0800000-0xe0800fff,0xe1000000-0xe10000ff irq 11 at device 10.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-40, SE, parity checking pci0: at 12.0 dc0: <82c169 PNIC 10/100BaseTX> port 0xb800-0xb8ff mem 0xe0000000-0xe00000ff irq 10 at device 13.0 on pci0 dc0: Ethernet address: 00:c0:f0:2d:89:bc miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 1000 packets/entry by default ad0: 43979MB [89355/16/63] at ata0-master UDMA33 Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS mode change from SE to SE. Mounting root from ufs:/dev/da0s1a cd0 at sym0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 15) cd0: cd present [1304908 x 512 byte records] da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) sym0:0: message d sent on bad reselection. sym0:0:control msgout: 80 20 35 d. ghost:~> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Feb 10 1:19:47 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by hub.freebsd.org (Postfix) with ESMTP id 584D937B401 for ; Sat, 10 Feb 2001 01:19:25 -0800 (PST) Received: from nas1-62.mea.club-internet.fr (nas1-62.mea.club-internet.fr [195.36.139.62]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id KAA09969; Sat, 10 Feb 2001 10:19:13 +0100 (MET) Date: Sat, 10 Feb 2001 09:18:14 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: klh@alum.mit.edu Cc: Darren Joy , klh@panix.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 10 Feb 2001, Ken Harrenstien wrote: > Hi, >=20 > Was searching through the archives to see if anyone else has had > problems similar to mine, and found yours. I was wondering if there > had been any further resolution since the last round of messages > circa 7-Jan-2001? >=20 > If not, perhaps my info will add some data for Gerard or others. >=20 > My story is that I just now began trying to move from 3.3 to 4.2 > (because only 4.x can understand large ATA drives, sigh) and ran into > some odd error messages that look like this: >=20 > =09sym0:0: message d sent on bad reselection. > =09sym0:0:control msgout: 80 20 35 d. As seen from the driver this is a SCSI protocol violation from the device. The device wanted to reselect for the tag 0x35 and the corresponding nexus= =20 didn't exist (as seen by the driver). > I have a Tekram DC390-U2W and this problem is happening with a Conner > CFP1080S (Conner again... hmmm). Tagged Queueing is enabled. It This hardware and and its firmware=3Dsoftware are probably no more supported. We know by experience that any software has still bugs even after years of maintainance. In my opinion, trying to make work something that is not supported/maintained is full time lost. I have had a CFP1080S years ago and was using it with 8 tags max on a=20 P90/24MB/NCR53C825 system. It worked reliably for me. Newer systems are a lot much faster and may trigger device bugs that didnt bite us with slower systems. Btw, I donnot use such antic drive anymore. This drive is probably wasting a lot your SCSI BUS bandwidth and nobody will give more than half an euro for it, in my opinion. > isn't frequent, but I haven't tried much yet. Happened once during > shutdown for a reboot (which wedged things and required a fsck after > resetting the CPU), again upon logging in after a night of running > idle. There are currently two other devices on the SCSI chain but > they should be completely unused (nothing is mounted from them). If you really like this drive, I would recommend you to disable tagged command queuing for it. Given the actual drive performance, this will not make significant difference and will avoid the offending bad reselection issue. > I would have used the NCR driver, except I couldn't figure out how to > coerce the new 4.2 /usr/sbin/config to accept the setting of > SCSI_NCR_DFLT_SYNC=3D6 which is required in order to use LVD drives at > full 80Mb/s speed. Grumble. Different topic. Was hoping SYM would work > without this fussing, but until I understand what's going on with "bad > reselection" I'm not going to put my LVD drives on this system. If you plan to keep with the Conner thing on your SCSI BUS, the BUS bandwidth wastage due to the Conner thing will be a significant penalty=20 for your system, in my opinion. > Here's the dmesg since it always seems to be asked for. Apologies if > it turns out to be unnecessary! I would recommend you the following: 1) Disable TCQ for the Conner (or disable the drive definitely as I did=20 years ago with mine :-) ) 2) In case of you still like a lot this drive, put it on the SE part=20 of the BUS (behind the LVD-SE converter). 3) Install your LVD drives on the LVD part of the SCSI BUS. Use any driver you want and send problem reports if any. Now some explanations and questions: > sym0: Tekram NVRAM, ID 7, Fast-40, SE, parity checking Means that your 895 is operating in SE =3D Single Ended SCSI mode. > (noperiph:sym0:0:-1:-1): SCSI BUS mode change from SE to SE. This one should be harmless but it is strange, since the driver does=20 waits 100 ms to ensure SCSI BUS mode is stable after a reset. OTOH, the driver message that tells that the SCSI BUS has been reset is missing. You may have configured you BIOS for this RESET not to be performed at start up. If it is the case, could you please change this BIOS setting for the driver to reset the BUS prior to any IO. Are you playing with multi-initiator SCSI BUS ? Regards, G=E9rard. > --Ken > =09=09-------------- >=20 > ghost:~> dmesg > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.2-RELEASE #0: Fri Feb 9 01:52:53 PST 2001 > klh@ghost:/usr/src/sys/compile/PCKLH-300 > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 300683344 Hz > CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x660 Stepping =3D 0 > Features=3D0x183f9ff > real memory =3D 268419072 (262128K bytes) > avail memory =3D 257679360 (251640K bytes) > Preloaded elf kernel "kernel" at 0xc039f000. > Pentium Pro MTRR support enabled > md0: Malloc disk > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on pci= 0 > pci1: on pcib1 > isab0: at device 4.0 on pci0 > isa0: on isab0 > atapci0: port 0xd800-0xd80f at device 4.1 = on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > pci0: at 4.2 > chip1: port 0xe800-0xe80f at = device 4.3 on pci0 > sym0: <895> port 0xd000-0xd0ff mem 0xe0800000-0xe0800fff,0xe1000000-0xe10= 000ff irq 11 at device 10.0 on pci0 > sym0: Tekram NVRAM, ID 7, Fast-40, SE, parity checking > pci0: at 12.0 > dc0: <82c169 PNIC 10/100BaseTX> port 0xb800-0xb8ff mem 0xe0000000-0xe0000= 0ff irq 10 at device 13.0 on pci0 > dc0: Ethernet address: 00:c0:f0:2d:89:bc > miibus0: on dc0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model IntelliMouse, device ID 3 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > IP packet filtering initialized, divert enabled, rule-based forwarding en= abled, default to deny, logging limited to 1000 packets/entry by default > ad0: 43979MB [89355/16/63] at ata0-master UDMA33 > Waiting 5 seconds for SCSI devices to settle > (noperiph:sym0:0:-1:-1): SCSI BUS mode change from SE to SE. > Mounting root from ufs:/dev/da0s1a > cd0 at sym0 bus 0 target 5 lun 0 > cd0: Removable CD-ROM SCSI-2 device=20 > cd0: 4.237MB/s transfers (4.237MHz, offset 15) > cd0: cd present [1304908 x 512 byte records] > da0 at sym0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device=20 > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > da0: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C) > da1 at sym0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device=20 > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing = Enabled > da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) > sym0:0: message d sent on bad reselection. > sym0:0:control msgout: 80 20 35 d. > ghost:~>=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message