From owner-freebsd-scsi Sun Oct 29 23:25: 9 2000 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 6FB3337B4CF for ; Sun, 29 Oct 2000 23:25:06 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id AAA45628 for scsi@FreeBSD.org; Mon, 30 Oct 2000 00:25:05 -0700 (MST) (envelope-from ken) Date: Mon, 30 Oct 2000 00:25:05 -0700 From: "Kenneth D. Merry" To: scsi@FreeBSD.org Subject: cd(4) write support Message-ID: <20001030002505.A37704@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've committed a set of patches in -current that provide write support for randomly writeable CD-type drives. (Mainly DVD-RAM and PD-type drives.) The driver should function the same as before with read-only media. It is now possible to do things like burn a UFS disklabel and filesystem on a CD-R, or disklabel and newfs a DVD-RAM disk. The disklabel semantics may be a little confusing with writeable media, since until you actually put a disklabel on the disk, you'll see the faked-up disklabel when you type 'disklabel cd0'. (With the da(4) driver, for instance, you wouldn't get any label back in that case.) This may be helpful in creating a label, though, since you can do something like: disklabel cd0 > cd0.label vi cd0.label [ modify the label somewhat ] disklabel -rR cd0 cd0.label Anyway, feedback and comments are welcome. 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 Oct 31 7:48:49 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from hub.org (hub.org [216.126.84.1]) by hub.freebsd.org (Postfix) with ESMTP id 6133137B4C5 for ; Tue, 31 Oct 2000 07:48:47 -0800 (PST) Received: from localhost (scrappy@localhost) by hub.org (8.10.1/8.11.0) with ESMTP id e9VFma574450 for ; Tue, 31 Oct 2000 10:48:37 -0500 (EST) (envelope-from scrappy@hub.org) Date: Tue, 31 Oct 2000 10:48:34 -0500 (EST) From: "Marc G. Fournier" To: freebsd-scsi@freebsd.org Subject: iostat: tps for SCSI drives ... 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 morning all ... what is considered to be a 'saturated drive', as far as tps is concerned? I have a database server that I found one drive to be overused with another not used at all, so I started moving around databases to balance off the load a bit ... which helped alot. But am wondering if there is an "acceptable tps level" for a drive before you should look at moving things around ? Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@{postgresql|isc}.org ICQ#7615664 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 9:38:55 2000 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 0C84337B479 for ; Tue, 31 Oct 2000 09:38:51 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 13qeyw-0007TU-00; Tue, 31 Oct 2000 09:13:54 -0800 Date: Tue, 31 Oct 2000 09:13:52 -0800 (PST) From: Tom Samplonius To: "Marc G. Fournier" Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Marc G. Fournier wrote: > morning all ... > > what is considered to be a 'saturated drive', as far as tps is > concerned? I have a database server that I found one drive to be overused > with another not used at all, so I started moving around databases to > balance off the load a bit ... which helped alot. But am wondering if > there is an "acceptable tps level" for a drive before you should look at > moving things around ? Well, if you assume that each transfer requires a seek, and you know the average seek time of your drive, you'll be about to figure out the number of transfers per second your drive can do (assuming each transfer requires a seek). If you are using SCSI drives with tagged command queues, you can use camcontrol to see how many pending commands there are. > Marc G. Fournier scrappy@hub.org > Systems Administrator @ hub.org > scrappy@{postgresql|isc}.org ICQ#7615664 Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 16:45:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id 0CF2737B4C5 for ; Tue, 31 Oct 2000 16:45:33 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA10hRv54785; Tue, 31 Oct 2000 20:43:27 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 31 Oct 2000 20:43:27 -0400 (AST) From: The Hermit Hacker To: Tom Samplonius Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Tom Samplonius wrote: > > On Tue, 31 Oct 2000, Marc G. Fournier wrote: > > > morning all ... > > > > what is considered to be a 'saturated drive', as far as tps is > > concerned? I have a database server that I found one drive to be overused > > with another not used at all, so I started moving around databases to > > balance off the load a bit ... which helped alot. But am wondering if > > there is an "acceptable tps level" for a drive before you should look at > > moving things around ? > > Well, if you assume that each transfer requires a seek, and you know the > average seek time of your drive, you'll be about to figure out the number > of transfers per second your drive can do (assuming each transfer requires > a seek). If you are using SCSI drives with tagged command queues, you can > use camcontrol to see how many pending commands there are. Okay, how do I read this: pgsql# camcontrol tags da0 -v (pass0:ahc0:0:0:0): dev_openings 41 (pass0:ahc0:0:0:0): dev_active 0 (pass0:ahc0:0:0:0): devq_openings 41 (pass0:ahc0:0:0:0): devq_queued 0 (pass0:ahc0:0:0:0): held 0 (pass0:ahc0:0:0:0): mintags 2 (pass0:ahc0:0:0:0): maxtags 255 pgsql# camcontrol tags da1 -v (pass1:ahc0:0:1:0): dev_openings 1 (pass1:ahc0:0:1:0): dev_active 0 (pass1:ahc0:0:1:0): devq_openings 1 (pass1:ahc0:0:1:0): devq_queued 0 (pass1:ahc0:0:1:0): held 0 (pass1:ahc0:0:1:0): mintags 2 (pass1:ahc0:0:1:0): maxtags 255 pgsql# iostat -n5 -t da 5 tty da0 da1 da2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 77083887 48.00 36 1.67 0.00 0 0.00 0.00 0 0.00 23 0 9 0 68 0 9856 42.97 34 1.45 0.00 0 0.00 8.07 23 0.18 0 0 0 0 0 0 9856 39.77 41 1.57 0.00 0 0.00 8.00 23 0.18 0 0 0 0 0 max/mintags aren't a problem ... I take it, from what I'm reading in the man page, the 'pending' is the dev_active field? So, there is nothing pending? The two drives in use above are: da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 17431MB (35700480 512 byte sectors: 255H 63S/T 2222C) So, for the Seagate, according to Seagate, the avg seek time is 5.2ms ... so I should max out around 192.3 tps on that drive? I know, not set in stone, but a reasonable number to work with, right? And, from what I can tell about the Fujitso, they are running around 7ms, so ~142tps? Does this make sense? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 20:10:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 59BE037B6A4 for ; Tue, 31 Oct 2000 20:10:15 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA14A9a05310; Tue, 31 Oct 2000 21:10:09 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011010410.eA14A9a05310@aslan.scsiguy.com> To: scottmm Cc: FREEBSD-SCSI@FreeBSD.ORG Subject: Re: ahc0: ahc_intr - referenced scb ... In-Reply-To: Your message of "Wed, 25 Oct 2000 09:17:44 CDT." <39F6EB88.646614AB@cifnet.com> Date: Tue, 31 Oct 2000 21:10:08 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hello All > >I have been using FBSD 3.4 for the last few months, and have recently >run into a backup problem that I cannot figure out. I am using v 3.4 >with a newly rebuilt kernel. My MB is a Tiger-133 with x2 p3 500's. >The SCSI controller is an Adaptec 2940U/UW. The devices I have on this >SCSI device are: >SCSI ID 3: HP 12/24GB >SCSI ID 4: Plextor 12/2/20 CDRW I would recommend upgrading to 4.1-stable or a 4.2 release candidate. Once you are running a more recent code base, I can do more to help diagnose your problem if it still exists. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 20:37:26 2000 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 CCB6437B479 for ; Tue, 31 Oct 2000 20:37:20 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 13qpGF-0000Nq-00; Tue, 31 Oct 2000 20:12:27 -0800 Date: Tue, 31 Oct 2000 20:12:25 -0800 (PST) From: Tom Samplonius To: The Hermit Hacker Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, The Hermit Hacker wrote: > Okay, how do I read this: > > pgsql# camcontrol tags da0 -v > (pass0:ahc0:0:0:0): dev_openings 41 > (pass0:ahc0:0:0:0): dev_active 0 > (pass0:ahc0:0:0:0): devq_openings 41 > (pass0:ahc0:0:0:0): devq_queued 0 > (pass0:ahc0:0:0:0): held 0 > (pass0:ahc0:0:0:0): mintags 2 > (pass0:ahc0:0:0:0): maxtags 255 I wonder why dev_openings is lower than maxtags? > pgsql# camcontrol tags da1 -v > (pass1:ahc0:0:1:0): dev_openings 1 > (pass1:ahc0:0:1:0): dev_active 0 > (pass1:ahc0:0:1:0): devq_openings 1 > (pass1:ahc0:0:1:0): devq_queued 0 > (pass1:ahc0:0:1:0): held 0 > (pass1:ahc0:0:1:0): mintags 2 > (pass1:ahc0:0:1:0): maxtags 255 Here dev_openings is 1, so that would mean that the kernel can't have more than one pending command. Since it is a (crappy) Fijitsu drive, I would expect that either the drive told that the kernel it won't queue commands, or there is quirk entry that disables tags for this drive. > pgsql# iostat -n5 -t da 5 > tty da0 da1 da2 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 77083887 48.00 36 1.67 0.00 0 0.00 0.00 0 0.00 23 0 9 0 68 > 0 9856 42.97 34 1.45 0.00 0 0.00 8.07 23 0.18 0 0 0 0 0 > 0 9856 39.77 41 1.57 0.00 0 0.00 8.00 23 0.18 0 0 0 0 0 > > max/mintags aren't a problem ... I take it, from what I'm reading in the > man page, the 'pending' is the dev_active field? So, there is nothing > pending? > > The two drives in use above are: > > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) > da2 at ahc0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled > da2: 17431MB (35700480 512 byte sectors: 255H 63S/T 2222C) > > So, for the Seagate, according to Seagate, the avg seek time is 5.2ms ... > so I should max out around 192.3 tps on that drive? I know, not set in > stone, but a reasonable number to work with, right? And, from what I can > tell about the Fujitso, they are running around 7ms, so ~142tps? > > Does this make sense? > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 20:52:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id 97F2437B4C5 for ; Tue, 31 Oct 2000 20:52:34 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA14oaf04895; Wed, 1 Nov 2000 00:50:36 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 1 Nov 2000 00:50:36 -0400 (AST) From: The Hermit Hacker To: Tom Samplonius Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Tom Samplonius wrote: > > On Tue, 31 Oct 2000, The Hermit Hacker wrote: > > > Okay, how do I read this: > > > > pgsql# camcontrol tags da0 -v > > (pass0:ahc0:0:0:0): dev_openings 41 > > (pass0:ahc0:0:0:0): dev_active 0 > > (pass0:ahc0:0:0:0): devq_openings 41 > > (pass0:ahc0:0:0:0): devq_queued 0 > > (pass0:ahc0:0:0:0): held 0 > > (pass0:ahc0:0:0:0): mintags 2 > > (pass0:ahc0:0:0:0): maxtags 255 > > I wonder why dev_openings is lower than maxtags? anything I can look at/check to find out? > > pgsql# camcontrol tags da1 -v > > (pass1:ahc0:0:1:0): dev_openings 1 > > (pass1:ahc0:0:1:0): dev_active 0 > > (pass1:ahc0:0:1:0): devq_openings 1 > > (pass1:ahc0:0:1:0): devq_queued 0 > > (pass1:ahc0:0:1:0): held 0 > > (pass1:ahc0:0:1:0): mintags 2 > > (pass1:ahc0:0:1:0): maxtags 255 > > Here dev_openings is 1, so that would mean that the kernel can't have > more than one pending command. Since it is a (crappy) Fijitsu drive, I > would expect that either the drive told that the kernel it won't queue > commands, or there is quirk entry that disables tags for this drive. > > > pgsql# iostat -n5 -t da 5 > > tty da0 da1 da2 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 77083887 48.00 36 1.67 0.00 0 0.00 0.00 0 0.00 23 0 9 0 68 > > 0 9856 42.97 34 1.45 0.00 0 0.00 8.07 23 0.18 0 0 0 0 0 > > 0 9856 39.77 41 1.57 0.00 0 0.00 8.00 23 0.18 0 0 0 0 0 > > > > max/mintags aren't a problem ... I take it, from what I'm reading in the > > man page, the 'pending' is the dev_active field? So, there is nothing > > pending? > > > > The two drives in use above are: > > > > da0 at ahc0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled > > da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) > > da2 at ahc0 bus 0 target 2 lun 0 > > da2: Fixed Direct Access SCSI-2 device > > da2: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled > > da2: 17431MB (35700480 512 byte sectors: 255H 63S/T 2222C) > > > > So, for the Seagate, according to Seagate, the avg seek time is 5.2ms ... > > so I should max out around 192.3 tps on that drive? I know, not set in > > stone, but a reasonable number to work with, right? And, from what I can > > tell about the Fujitso, they are running around 7ms, so ~142tps? > > > > Does this make sense? > > > > > > > > > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 20:57:32 2000 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 2616537B479 for ; Tue, 31 Oct 2000 20:57:30 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 13qpZl-0000P0-00; Tue, 31 Oct 2000 20:32:37 -0800 Date: Tue, 31 Oct 2000 20:32:36 -0800 (PST) From: Tom Samplonius To: The Hermit Hacker Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... 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 Wed, 1 Nov 2000, The Hermit Hacker wrote: > On Tue, 31 Oct 2000, Tom Samplonius wrote: > > > > > On Tue, 31 Oct 2000, The Hermit Hacker wrote: > > > > > Okay, how do I read this: > > > > > > pgsql# camcontrol tags da0 -v > > > (pass0:ahc0:0:0:0): dev_openings 41 > > > (pass0:ahc0:0:0:0): dev_active 0 > > > (pass0:ahc0:0:0:0): devq_openings 41 > > > (pass0:ahc0:0:0:0): devq_queued 0 > > > (pass0:ahc0:0:0:0): held 0 > > > (pass0:ahc0:0:0:0): mintags 2 > > > (pass0:ahc0:0:0:0): maxtags 255 > > > > I wonder why dev_openings is lower than maxtags? > > anything I can look at/check to find out? Don't know... do you get kernel messages that the kernel is reducing openings? Lots of stuff in the archives about how the kernel can reduce openings if a drive reports errors. If openings is getting lower, that must be happening. See what it is like after a fresh boot. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 21: 6:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id D5E4137B4D7 for ; Tue, 31 Oct 2000 21:06:32 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA154d505130; Wed, 1 Nov 2000 01:04:39 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 1 Nov 2000 01:04:39 -0400 (AST) From: The Hermit Hacker To: Tom Samplonius Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Tom Samplonius wrote: > > On Wed, 1 Nov 2000, The Hermit Hacker wrote: > > > On Tue, 31 Oct 2000, Tom Samplonius wrote: > > > > > > > > On Tue, 31 Oct 2000, The Hermit Hacker wrote: > > > > > > > Okay, how do I read this: > > > > > > > > pgsql# camcontrol tags da0 -v > > > > (pass0:ahc0:0:0:0): dev_openings 41 > > > > (pass0:ahc0:0:0:0): dev_active 0 > > > > (pass0:ahc0:0:0:0): devq_openings 41 > > > > (pass0:ahc0:0:0:0): devq_queued 0 > > > > (pass0:ahc0:0:0:0): held 0 > > > > (pass0:ahc0:0:0:0): mintags 2 > > > > (pass0:ahc0:0:0:0): maxtags 255 > > > > > > I wonder why dev_openings is lower than maxtags? > > > > anything I can look at/check to find out? > > Don't know... do you get kernel messages that the kernel is reducing > openings? Lots of stuff in the archives about how the kernel can reduce > openings if a drive reports errors. If openings is getting lower, that > must be happening. See what it is like after a fresh boot. not that I've noticed, but its been up 35 days and I don't have /var/log/messages that go back that far ... will take a peak for that, and check camcontrol, after next reboot ... thanks again To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Oct 31 21:11:13 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 0335237B4C5 for ; Tue, 31 Oct 2000 21:11:11 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA15Aja05833; Tue, 31 Oct 2000 22:10:45 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011010510.eA15Aja05833@aslan.scsiguy.com> To: Tom Samplonius Cc: The Hermit Hacker , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Your message of "Tue, 31 Oct 2000 20:12:25 PST." Date: Tue, 31 Oct 2000 22:10:43 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >On Tue, 31 Oct 2000, The Hermit Hacker wrote: > >> Okay, how do I read this: >> >> pgsql# camcontrol tags da0 -v >> (pass0:ahc0:0:0:0): dev_openings 41 >> (pass0:ahc0:0:0:0): dev_active 0 >> (pass0:ahc0:0:0:0): devq_openings 41 >> (pass0:ahc0:0:0:0): devq_queued 0 >> (pass0:ahc0:0:0:0): held 0 >> (pass0:ahc0:0:0:0): mintags 2 >> (pass0:ahc0:0:0:0): maxtags 255 > > I wonder why dev_openings is lower than maxtags? Maxtags is the limit imposed by the quirk entry matching the device. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 1 5: 9:24 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front3.grolier.fr (front3.grolier.fr [194.158.96.53]) by hub.freebsd.org (Postfix) with ESMTP id 7AD9E37B479 for ; Wed, 1 Nov 2000 05:09:19 -0800 (PST) Received: from nas6-74.vlt.club-internet.fr (nas6-74.vlt.club-internet.fr [194.158.108.74]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id OAA27659; Wed, 1 Nov 2000 14:09:15 +0100 (MET) Date: Wed, 1 Nov 2000 13:09:48 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: freebsd-scsi@freebsd.org, linux-scsi@vger.kernel.org Subject: Preliminary SYM-2 driver version available. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-751398602-973080588=:501" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323584-751398602-973080588=:501 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hello, I am glad to announce the availability of a preliminary version of=20 the SYM-2 driver. It is versionned sym-2.0.3. The first official release will be sym-2.1.0 and will replace all=20 the drivers for [ncr|sym|lsi][53c8xx|53c1010] PCI-SCSI controllers I currently maintain, namely: - Linux ncr53c8xx driver. - Linux sym53c8xx driver. - FreeBSD sym driver. I used a variety of shoehorns in order to have O/S glue code as=20 short as possible. :-) The result is obviously not perfect, but it looks good enough for=20 me to be quite happy of it. Hopefully version 2.1.0 will be better :). The aim of SYM-2.1 is: - To decrease time spent for maintainance, thus allowing more time=20 for development. - To allow, at least me, to port the driver to some other O/S(es) in=20 a reasonnable time, if it ever makes interest. SYM-2.0.3 can be downloaded from the following location: ftp://ftp.tux.org/roudier/drivers/portable/experimental/sym-2.0.3-20001101.= tar.gz I only tried this driver version under Linux-2.2.16 and FreeBSD-4.0. It does not, at least for the moment, provide more features than stock sym drivers, but may well provide some additionnal bugs :-) due to the merge and somes rewrite of the O/S glue code parts. People who like playing with dangerous code should enjoy giving this=20 prelimary sym-2 driver version a try (Btw, in fact, I am under the=20 impression that this driver version does work quite well). :-) G=E9rard. --8323584-751398602-973080588=:501 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=README-sym-2 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=README-sym-2 U1lNLTIgZHJpdmVyIGRldmVsb3BtZW50IFJFQURNRSBmaWxlICAgICAgICAg ICAgICAgICAgICAgICAgMjAwMC0xMS0zMQ0KDQpDdXJyZW50IFNZTSBkcml2 ZXIgdmVyc2lvbiBpcyAyLjAuMy4NCg0KVGhpcyBpcyBhIGZ1bGwtZnVuY3Rp b25uYWwgcHJlbGltaW5hcnkgdmVyc2lvbiBvZiB0aGUgbXVsdGktTy9TIA0K U1lNIGRyaXZlci4NCg0KLSBVbmRlciBGcmVlQlNELCB0aGlzIGRyaXZlciBp cyBhIGZ1bGwtZmVhdHVyZWQgcmVwbGFjZW1lbnQgDQogIG9mIHRoZSBzdG9j ayBgc3ltJyBkcml2ZXIsIGdpdmVuIHRoYXQgaXQgaXMganVzdCB0aGUgdmVy c2lvbiANCiAgMiBvZiB0aGlzIGRyaXZlciA6KS4gQnV0IGl0IGhhcyBvbmx5 IGJlZW4gdHJpZWQgb24gDQogIEZyZWVCU0QtNC4wL2kzODYgZm9yIG5vdy4N Cg0KLSBVbmRlciBMaW51eCwgaXQgcmVwbGFjZXMgYm90aCBzeW01M2M4eHgg YW5kIG5jcjUzYzh4eCBkcml2ZXJzLA0KICB3aXRoIHRoZSBmb2xsb3dpbmcg cmVzdHJpY3Rpb25zOg0KICAxKSBUaGUgYm9vdCBjb21tYW5kIGxpbmUgaXMg bm90IHlldCBzdXBwb3J0ZWQgKGJhY2twb3J0ZWQpLg0KICAyKSBPbi1saW5l IGNvbW1hbmRzIHRocm91Z2ggdGhlIHByb2MvRlMgYXJlIG5vdCBzdXBwb3J0 ZWQsDQogICAgIGFuZCB3aWxsIG5vdCBiZSwgc2luY2UgdGhpcyBmZWF0dXJl IGhhc24ndCBwcm92ZW4gdG8gYmUgDQogICAgIHRoaXMgdXNlZnVsLg0KICAz KSBJdCBoYXMgb25seSBiZWVuIHRyaWVkIG9uIHN0b2NrIGxpbnV4LTIuMi4x Ni9pMzg2LCBzdGF0aWNhbGx5IA0KICAgICBsaW5rZWQgd2l0aCB0aGUga2Vy bmVsIGltYWdlLg0KDQpzeW0tMiBkcml2ZXIgc2VyaWVzIHRvZG8gbGlzdDoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kc3ltLTIuMC4wOglB Q0hJRVZFRA0KCU1vdmUgTy9TIGdsdWUgY29kZSB0byBzZXBhcmF0ZSBmaWxl cy4NCglNYWtlIHRoZSBkcml2ZXIgd29yayBhZ2FpbiB1bmRlciBGcmVlQlNE Lg0Kc3ltLTIuMC5YOglJTiBQUk9HUkVTUw0KCUltcGxlbWVudCBnbHVlIGNv ZGUgZm9yIExpbnV4IGJhc2VkIG9uIHN5bTUzYzh4eCANCglkcml2ZXIuDQoJ SW50ZXJmYWNlIHdpdGggdGhlIG5ldyBTQ1NJIGVycm9yIGhhbmRsaW5nIG1l dGhvZC4NCnN5bS0yLjEuMDoJUExBTk5FRCBGT1IgU09PTiA6LSkNCglNYWtl IHRoZSBkcml2ZXIgd29yayB1bmRlciBMaW51eC4NCglNYWtlIHRoZSBkcml2 ZXIgd29yayBhZ2FpbiB1bmRlciBGcmVlQlNELg0Kc3ltLTIuMS5YOg0KCU1h a2UgdGhlIGRyaXZlciByb2NrIHNvbGlkLg0KCUNvbW1pdCB0aGUgcmVzdWx0 ZWQgZHJpdmVyIHZlcnNpb24uDQpzeW0tMi4yLjA6DQoJQWRkIGZyYW1ld29y ayBhbmQgbWFpbiBjb2RlIGZvciB0YXJnZXQgbW9kZSBzdXBwb3J0Lg0KCU1h a2UgdGhlIGRyaXZlciB3b3JrIGFnYWluLg0Kc3ltLTIuMi5YOg0KCUNvbXBs ZXRlIGRldmVsb3BtZW50IG9mIHRhcmdldCBtb2RlIHN1cHBvcnQuDQoJTWFr ZSB0aGlzIGZlYXR1cmUgd29yayByZWFzb25uYWJseSB1bmRlciBGcmVlQlNE Lg0KDQpUaGlzIGRyaXZlciBoYXZlIHRlc3RlZCBpdCAoYSBiaXQgOikpIHVu ZGVyIEZyZWVCU0QtNC4wIGFuZCBMaW51eC0yLjIuMTYuDQpUaGUgZHJpdmVy IHNob3VsZCBwcm9iYWJseSBjb21waWxlIGFuZCBob3BlZnVsbHkgd29yayB1 bmRlciBGcmVlQlNELTQuWCANCmFuZCBwcm9iYWJseSB1bmRlciBMaW51eC0y LjIuMTcvMi4yLjE4Lg0KDQpTWU0tMiBkcml2ZXIgc2VyaWVzIGRyb3AgU3Vw cG9ydCBmb3IgTGludXgtMi4wLnguDQpTdXBwb3J0IGZvciBGcmVlQlNEIDMu eCB3aWxsIG5vdCBiZSBkcm9wcGVkLCBidXQgdGhlIG5ldyBkcml2ZXIgDQp2 ZXJzaW9uIHdpbGwgbm90IGJlIGNvbW1pdHRlZCB0byB0aGF0IGJyYW5jaC4N Cg0KRHJpdmVyIGZpbGVzOg0KLS0tLS0tLS0tLS0tLQ0KDQpGcmVlQlNEIHNw ZWNpZmljIGZpbGVzOg0KICBGcmVlQlNELw0KICAgIHN5bV9nbHVlLmgJIE1h aW4gaGVhZGVyIGZpbGUgLSBhbHNvIGNvbnRhaW5zIE8vUyBzcGVjaWZpYyBk ZWZpbml0aW9ucw0KICAgIHN5bV9nbHVlLmMJIE8vUyBzcGVjaWZpYyBjb2Rl DQogICAgc3ltLTIuMC4zLWtjb25mLmRpZmYgIFRpbnkgcGF0Y2ggZm9yIGtl cm5lbCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpMaW51eCBzcGVjaWZpYyBm aWxlczoNCiAgTGludXgvDQogICAgc3ltNTNjOHh4LmggIEhvc3QgdGVtcGxh dGUgZGVmaW5pdGlvbiArIGtlcm5lbCBjb25maWcgd3JhcHBlcg0KICAgIHN5 bV9nbHVlLmgJIE1haW4gaGVhZGVyIGZpbGUgLSBhbHNvIGNvbnRhaW5zIE8v UyBzcGVjaWZpYyBkZWZpbml0aW9ucw0KICAgIHN5bV9nbHVlLmMJIE8vUyBz cGVjaWZpYyBjb2RlDQogICAgc3ltLTIuMC4zLWtjb25mLmRpZmYgIFRpbnkg cGF0Y2ggZm9yIGtlcm5lbCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpDb21t b24gZHJpdmVyIGZpbGVzIChub3QgcGxhdGZvcm0tc3BlY2lmaWMpIDoNCiAg Q29tbW9uLw0KICAgIHN5bV9jb25mLmgJIERyaXZlciBkZWZhdWx0IGNvbmZp Z3VyYXRpb24gYW5kIG9wdGlvbnMNCiAgICBzeW1fZGVmcy5oCSBTWU1CSU9T IGNoaXBzIGFuZCBTQ1NJIHJlbGF0ZWQgZGVmaW5pdGlvbnMNCiAgICBzeW1f ZncuaAkgRmlybXdhcmUgaW50ZXJmYWNlIGRlZmluaXRpb25zDQogICAgc3lt X2Z3MS5oCSBOQ1ItR2VuZXJpYyBmaXJtd2FyZQ0KICAgIHN5bV9mdzIuaAkg TE9BRC9TVE9SRSBiYXNlZCBmaXJtd2FyZQ0KICAgIHN5bV9mdy5jCSBGaXJt d2FyZSBpbnRlcmZhY2UgY29kZQ0KICAgIHN5bV9oaXBkLmgJIERyaXZlciBk YXRhIHN0cnVjdHVyZXMgYW5kIGNvbnN0YW50cyBkZWZpbml0aW9ucw0KICAg IHN5bV9oaXBkLmMJIENvcmUgZHJpdmVyIGNvZGUNCiAgICBzeW1fbWlzYy5o CSBGb3Igbm93IExJU1QvUVVFVUUgYW5kIGJ5dGUgT1JERVJJTkcgc3R1ZmYN CiAgICBzeW1fbnZyYW0uYwkgTlZSQU0gcmVhZGluZyBhbmQgcGFyc2luZyBj b2RlDQoNCkluc3RhbGxhdGlvbiB1bmRlciBGcmVlQlNELTQuMCAoc3VnZ2Vz dGlvbik6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KVGhlIGRpcmVjdG9yeSB3aGVyZSB0aGUgZHJpdmVyIGZpbGVz IGhhdmUgYmVlbiBkb3dsb2FkZWQgaXMgZGVub3RlZDoNCiAgICAgICAgPGRy aXZlcl9zb3VyY2U+DQoNCjEpIFNhdmUgb3JpZ2luYWwgZHJpdmVyIGZpbGVz Og0KICAgIyBjZCAvdXNyL3NyYy9zeXMvZGV2Lw0KICAgIyBtdiBzeW0gc3lt LW9yaWcNCiAgICMgbWtkaXIgc3ltDQoNCjIpIEFkZCB0aGUgbmV3IGRyaXZl ciBmaWxlczoNCiAgICMgY2QgPGRyaXZlcl9zb3VyY2U+DQogICAjIGNwIENv bW1vbi8qLmggIENvbW1vbi8qLmMgIC91c3Ivc3JjL3N5cy9kZXYvc3ltLw0K ICAgIyBjcCBGcmVlQlNELyouaCBGcmVlQlNELyouYyAvdXNyL3NyYy9zeXMv ZGV2L3N5bS8NCg0KMykgU2F2ZSBrZXJuZWwgY29uZmlnIGZpbGVzIHRoYXQg bmVlZCBjaGFuZ2VzOg0KICAgIyBjZCAvdXNyL3N5cy9jb25mDQogICAjIG12 IGZpbGVzIGZpbGVzLW9yaWcNCg0KNCkgQXBwbHkgdGhlIHRpbnkgcGF0Y2gg dG8gJ2NvbmYvZmlsZXMnDQogICAjIGNkIC91c3INCiAgICMgY2F0IDxkcml2 ZXJfc291cmNlPi9GcmVlQlNEL3N5bS0yLjAuMy1rY29uZi5kaWZmIHwgcGF0 Y2ggLXAwDQoNCkZvciBvdGhlciBGcmVlQlNEIHZlcnNpb25zLCB0aGUgZGlm ZnMgKDQpIG1heSBoYXZlIHRvIGJlIA0KYXBwbGllZCBtYW51YWxseS4gQnR3 LCB0aGV5IGFyZSBqdXN0IHRpbnkgdHJpdmlhbCBjaGFuZ2VzLg0KDQpJbnN0 YWxsYXRpb24gdW5kZXIgTGludXgtMi4yLjE2IChzdWdnZXN0aW9uKToNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQox KSBTYXZlIG9yaWdpbmFsIGRyaXZlciBmaWxlczoNCiAgICMgY2QgL3Vzci9z cmMvbGludXgvZHJpdmVycy9zY3NpDQogICAjIG1rZGlyIFNBVkVEDQogICAj IG12IHN5bTUzYzh4eCouKiBTQVZFRC8NCiAgICMgbXYgbmNyNTNjOHh4Ki4q IFNBVkVELw0KDQoyKSBBZGQgdGhlIG5ldyBkcml2ZXIgZmlsZXM6DQogICAj IGNkIDxkcml2ZXJfc291cmNlPg0KICAgIyBjcCBDb21tb24vKi5oIENvbW1v bi8qLmMgL3Vzci9zcmMvbGludXgvZHJpdmVycy9zY3NpLw0KICAgIyBjcCBM aW51eC8qLmggIExpbnV4LyouYyAgL3Vzci9zcmMvbGludXgvZHJpdmVycy9z Y3NpLw0KDQozKSBTYXZlIGtlcm5lbCBmaWxlcyB0aGF0IG5lZWQgY2hhbmdl czoNCiAgICMgY2QgL3Vzci9zcmMvbGludXgvZHJpdmVycy9zY3NpDQogICAj IG12IE1ha2VmaWxlIE1ha2VmaWxlLW9yaWcNCg0KNCkgQXBwbHkgdGhlIHRp bnkgcGF0Y2ggdG8gdGhlIHNjc2kgTWFrZWZpbGU6DQogICAjIGNkIC91c3Iv c3JjDQogICAjIGNhdCA8ZHJpdmVyX3NvdXJjZT4vTGludXgvc3ltLTIuMC4z LWtjb25mLmRpZmYgfCBwYXRjaCAtcDANCg0KNSkgQ29uZmlndXJlIHRoZSBr ZXJuZWwgZm9yIFNZTTUzQzhYWCBhbmQgbm90IGZvciBOQ1I1M0M4WFguDQoN CkZvciBvdGhlciBMaW51eCB2ZXJzaW9ucywgdGhlIGRpZmZzICg0KSBtYXkg aGF2ZSB0byBiZSANCmFwcGxpZWQgbWFudWFsbHkuIEJ0dywgdGhleSBhcmUg anVzdCB0aW55IHRyaXZpYWwgY2hhbmdlcy4NCg0KLS0NCkdlcmFyZCBST1VE SUVSLiAgZ3JvdWRpZXJAY2x1Yi1pbnRlcm5ldC5mciwgZ3JvdWRpZXJARnJl ZUJTRC5vcmcuDQo= --8323584-751398602-973080588=:501-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 1 10:11:48 2000 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 E215437B4CF for ; Wed, 1 Nov 2000 10:11:44 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 13r1yE-0001Fd-00; Wed, 1 Nov 2000 09:46:42 -0800 Date: Wed, 1 Nov 2000 09:46:39 -0800 (PST) From: Tom Samplonius To: "Justin T. Gibbs" Cc: The Hermit Hacker , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: <200011010510.eA15Aja05833@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Justin T. Gibbs wrote: > >On Tue, 31 Oct 2000, The Hermit Hacker wrote: > > > >> Okay, how do I read this: > >> > >> pgsql# camcontrol tags da0 -v > >> (pass0:ahc0:0:0:0): dev_openings 41 > >> (pass0:ahc0:0:0:0): dev_active 0 > >> (pass0:ahc0:0:0:0): devq_openings 41 > >> (pass0:ahc0:0:0:0): devq_queued 0 > >> (pass0:ahc0:0:0:0): held 0 > >> (pass0:ahc0:0:0:0): mintags 2 > >> (pass0:ahc0:0:0:0): maxtags 255 > > > > I wonder why dev_openings is lower than maxtags? > > Maxtags is the limit imposed by the quirk entry matching the device. Then I'm guessing that the kernel has reduced the number of dev_openings because the drive has reported errors when there were lots of outstanding tags? > -- > Justin > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 1 12:46:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 0B70C37B4CF for ; Wed, 1 Nov 2000 12:46:53 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA1Kkga63110; Wed, 1 Nov 2000 13:46:43 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011012046.eA1Kkga63110@aslan.scsiguy.com> To: Tom Samplonius Cc: The Hermit Hacker , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Your message of "Wed, 01 Nov 2000 09:46:39 PST." Date: Wed, 01 Nov 2000 13:46:42 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > I wonder why dev_openings is lower than maxtags? >> >> Maxtags is the limit imposed by the quirk entry matching the device. > > Then I'm guessing that the kernel has reduced the number of dev_openings >because the drive has reported errors when there were lots of outstanding >tags? Most likely. A verbose boot would tell you for sure. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 1 13:57:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.infolibria.com (mail.infolibria.com [199.103.137.198]) by hub.freebsd.org (Postfix) with ESMTP id 8F74737B4D7 for ; Wed, 1 Nov 2000 13:57:51 -0800 (PST) Received: from h201.infolibria.com (unknown [199.103.137.201]) by mail.infolibria.com (Postfix) with ESMTP id 8AC44DDBBE for ; Wed, 1 Nov 2000 16:59:36 -0500 (EST) Received: from loverso.southborough.ma.us (localhost [127.0.0.1]) by h201.infolibria.com (8.9.3/8.9.3) with ESMTP id QAA91048 for ; Wed, 1 Nov 2000 16:57:47 -0500 (EST) (envelope-from loverso@loverso.southborough.ma.us) Message-Id: <200011012157.QAA91048@h201.infolibria.com> To: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... X-Face: "UZ!}1W2N?eJdN(`1%|/OOPqJ).Idk?UyvWw'W-%`Gto8^IkEm>.g1O$[.;~}8E=Ire0|lO .o>:NlJS1@vO9bVmswRoq3j DdX9YGSeJ5a(mfX[1u>Z63G5_^+'8LVqjqvn X-Url: http://surf.to/loverso Date: Wed, 01 Nov 2000 16:57:46 -0500 From: "John R. LoVerso" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This thread has made me wonder. I have a RAID-5 array connected to a DPT-5 controller using the "asr" driver in 4.1.1-R, but it is not using tagged queueing. The DPT-5 does use tagged queueing on another disk on the same controller: % camcontrol tags da0 (pass0:asr0:0:0:0): device openings: 255 % camcontrol tags da1 -v (pass1:asr0:0:1:0): dev_openings 1 (pass1:asr0:0:1:0): dev_active 0 (pass1:asr0:0:1:0): devq_openings 1 (pass1:asr0:0:1:0): devq_queued 0 (pass1:asr0:0:1:0): held 0 (pass1:asr0:0:1:0): mintags 0 (pass1:asr0:0:1:0): maxtags 255 and from a verbose boot: domino0: mem 0xfc000000-0xfdffffff,0xf8200000-0xf820ffff irq 23 at device 3.0 on pci1 asr0: port 0x2000-0x20ff mem 0xf8400000-0xf85fffff irq 16 at device 4.0 on pci1 asr0: major=154 asr0: DPT PM3754U2 FW Rev. 3010, 3 channel, 256 CCBs, Protocol I2O pass0 at asr0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number 13011695HA pass0: Tagged Queueing Enabled pass1 at asr0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device da0 at asr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number 13011695HA da0: Tagged Queueing Enabled da0: 8754MB (17928681 512 byte sectors: 255H 63S/T 1116C) da1 at asr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 17507MB (35854336 512 byte sectors: 255H 63S/T 2231C) The RAID-5 is a "2+1" of three Seagate 39103LW drives. On a different machine with just an NCR controller, I do get tagged queueing with the drives: da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) Any idea why I don't see tagged queueing? Am I just confused (i.e., it shouldn't be enabled with a DPT-5 with a RAID-5)? Is I2O doing it under (and thus, transparent to) CAM? If I use "tags da1 -N 100", and start several concurrent operations on the disk, I do see tags in use: % camcontrol tags da1 -v (pass1:asr0:0:1:0): dev_openings 91 (pass1:asr0:0:1:0): dev_active 9 John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 1 14:46: 8 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id 9B21837B4C5 for ; Wed, 1 Nov 2000 14:46:04 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA1Mhui28940; Wed, 1 Nov 2000 18:43:56 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 1 Nov 2000 18:43:55 -0400 (AST) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: <200011010510.eA15Aja05833@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Justin T. Gibbs wrote: > > > >On Tue, 31 Oct 2000, The Hermit Hacker wrote: > > > >> Okay, how do I read this: > >> > >> pgsql# camcontrol tags da0 -v > >> (pass0:ahc0:0:0:0): dev_openings 41 > >> (pass0:ahc0:0:0:0): dev_active 0 > >> (pass0:ahc0:0:0:0): devq_openings 41 > >> (pass0:ahc0:0:0:0): devq_queued 0 > >> (pass0:ahc0:0:0:0): held 0 > >> (pass0:ahc0:0:0:0): mintags 2 > >> (pass0:ahc0:0:0:0): maxtags 255 > > > > I wonder why dev_openings is lower than maxtags? > > Maxtags is the limit imposed by the quirk entry matching the device. Okay, under what conditions would dev_openings == maxtags? My best drive that I can find on my various machines is a brand new LVD drive: da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 8755MB (17930694 512 byte sectors: 255H 63S/T 1116C) mailserv# camcontrol tags da0 -v (pass0:ahc0:0:0:0): dev_openings 64 (pass0:ahc0:0:0:0): dev_active 0 (pass0:ahc0:0:0:0): devq_openings 64 (pass0:ahc0:0:0:0): devq_queued 0 (pass0:ahc0:0:0:0): held 0 (pass0:ahc0:0:0:0): mintags 2 (pass0:ahc0:0:0:0): maxtags 255 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 1 17: 0:11 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (mass.osd.bsdi.com [204.216.28.234]) by hub.freebsd.org (Postfix) with ESMTP id 51D0837B479 for ; Wed, 1 Nov 2000 17:00:05 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA214Pe01438; Wed, 1 Nov 2000 17:04:25 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011020104.eA214Pe01438@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "John R. LoVerso" Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... In-reply-to: Your message of "Wed, 01 Nov 2000 16:57:46 EST." <200011012157.QAA91048@h201.infolibria.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 2000 17:04:25 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This thread has made me wonder. I have a RAID-5 array connected to a DPT-5 > controller using the "asr" driver in 4.1.1-R, but it is not using tagged > queueing. The DPT-5 does use tagged queueing on another disk on the same > controller: 'asr' talks to the SCSI interface, but it doesn't behave quite the same way. Commands don't have "tags" at all; they're queued at the controller level and CAM doesn't have to do any tag management. > Any idea why I don't see tagged queueing? Am I just confused (i.e., it > shouldn't be enabled with a DPT-5 with a RAID-5)? Is I2O doing it under > (and thus, transparent to) CAM? You are confused, yes. 8) -- ... 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 Nov 1 20:58: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 4C54E37B479 for ; Wed, 1 Nov 2000 20:58:01 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA24vea67590; Wed, 1 Nov 2000 21:57:41 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011020457.eA24vea67590@aslan.scsiguy.com> To: The Hermit Hacker Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Your message of "Wed, 01 Nov 2000 18:43:55 -0400." Date: Wed, 01 Nov 2000 21:57:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Maxtags is the limit imposed by the quirk entry matching the device. > >Okay, under what conditions would dev_openings == maxtags? My best drive >that I can find on my various machines is a brand new LVD drive: You will only see this very early in the boot process before a device indicates that it cannot handle "maxtags" via a queue full or if you have a device that can really achieve "maxtags". For instance, some RAID arrays can perform the full 256 tags that can be outstanding is SCSI-2, but most drives max out at 64 or 63 tags. Only recently have I found some IBM drives that will support 128 tags. That said, the system will only allocate resources to support the number of transactions it is determined a device can use. The "maxtags" value is just an upper bound. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 2 6:37: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 70ABA37B4CF for ; Thu, 2 Nov 2000 06:37:01 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rLU8-00057T-00 for freebsd-scsi@freebsd.org; Thu, 02 Nov 2000 06:36:56 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: FreeBSD SCSI Subject: eck(#da/12): b_bcount 5890 is not on a sector boundary (ssize 512) Message-Id: Date: Thu, 02 Nov 2000 06:36:56 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 8191 is not on a sector boundary (ssize 512) Nov 1 11:12:45 rip /kernel: ary (ssize 512) Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 5890 is not on a sector boundary (ssize 512) Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 5889 is not on a sector boundary (ssize 512) Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 5888 is not on a sector boundary (ssize 512) ... what is this?!? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 2 16:18:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id 83BCB37B4D7 for ; Thu, 2 Nov 2000 16:18:20 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA30GLe62593; Thu, 2 Nov 2000 20:16:21 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 2 Nov 2000 20:16:21 -0400 (AST) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: <200011020457.eA24vea67590@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 1 Nov 2000, Justin T. Gibbs wrote: > >> Maxtags is the limit imposed by the quirk entry matching the device. > > > >Okay, under what conditions would dev_openings == maxtags? My best drive > >that I can find on my various machines is a brand new LVD drive: > > You will only see this very early in the boot process before a device > indicates that it cannot handle "maxtags" via a queue full or if you > have a device that can really achieve "maxtags". For instance, > some RAID arrays can perform the full 256 tags that can be outstanding > is SCSI-2, but most drives max out at 64 or 63 tags. Only recently have > I found some IBM drives that will support 128 tags. That said, the > system will only allocate resources to support the number of transactions > it is determined a device can use. The "maxtags" value is just an > upper bound. So, what exactly does supporting 64, or 128, tags on a drive provide? From what I've been able to gleam from reading, my guess is a FIFO queue of commands to a drive, so that as soon as the results from command 0 finishes, it doesn't have to wait for command 1 to be sent from the system ... is this correct, albeit simplistic? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 2 16:20:31 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id E2AC037B479 for ; Thu, 2 Nov 2000 16:20:28 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA30KFa90886; Thu, 2 Nov 2000 17:20:16 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011030020.eA30KFa90886@aslan.scsiguy.com> To: The Hermit Hacker Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Your message of "Thu, 02 Nov 2000 20:16:21 -0400." Date: Thu, 02 Nov 2000 17:20:15 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >So, what exactly does supporting 64, or 128, tags on a drive >provide? Since modern drives perform seek optimization and command coalescing, it will usually result in fewer or shorter seeks and thus better throughput. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 2 16:22:10 2000 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 9216E37B4C5 for ; Thu, 2 Nov 2000 16:22:07 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA09573; Thu, 2 Nov 2000 17:22:03 -0700 (MST) (envelope-from ken) Date: Thu, 2 Nov 2000 17:22:03 -0700 From: "Kenneth D. Merry" To: Randy Bush Cc: FreeBSD SCSI Subject: Re: eck(#da/12): b_bcount 5890 is not on a sector boundary (ssize 512) Message-ID: <20001102172203.A9544@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 randy@psg.com on Thu, Nov 02, 2000 at 06:36:56AM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 02, 2000 at 06:36:56 -0800, Randy Bush wrote: > Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 8191 is not on a sector boundary (ssize 512) > Nov 1 11:12:45 rip /kernel: ary (ssize 512) > Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 5890 is not on a sector boundary (ssize 512) > Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 5889 is not on a sector boundary (ssize 512) > Nov 1 11:12:45 rip /kernel: dscheck(#da/12): b_bcount 5888 is not on a sector boundary (ssize 512) > ... > > what is this?!? It means someone tried to do I/O to da12 that was not a multiple of the sector size (512 bytes). 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 Nov 2 16:53:36 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id 9D10437B4C5 for ; Thu, 2 Nov 2000 16:53:33 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA30pEO63058; Thu, 2 Nov 2000 20:51:14 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 2 Nov 2000 20:51:14 -0400 (AST) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: <200011030020.eA30KFa90886@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 2 Nov 2000, Justin T. Gibbs wrote: > >So, what exactly does supporting 64, or 128, tags on a drive > >provide? > > Since modern drives perform seek optimization and command coalescing, > it will usually result in fewer or shorter seeks and thus better > throughput. How "smart" is it? In a multi-user system, I imagine that Cmd0->Cmd5 could be for information that UserA needs, while Cmd6->Cmd7 is for something UserB needs ... I imagine this would have to be "on the drive", but can they feed back information for Cmd6->Cmd7 while its processing Cmd0->Cmd5? Or is it purely FIFO? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 2 20:18:16 2000 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 48D2E37B479 for ; Thu, 2 Nov 2000 20:18:09 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA13167 for scsi@FreeBSD.ORG; Thu, 2 Nov 2000 21:18:07 -0700 (MST) (envelope-from ken) Date: Thu, 2 Nov 2000 21:18:07 -0700 From: "Kenneth D. Merry" To: scsi@FreeBSD.ORG Subject: Re: cd(4) write support Message-ID: <20001102211807.A13085@panzer.kdm.org> References: <20001030002505.A37704@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001030002505.A37704@panzer.kdm.org>; from ken@kdm.org on Mon, Oct 30, 2000 at 12:25:05AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 30, 2000 at 00:25:05 -0700, Kenneth D. Merry wrote: > > I've committed a set of patches in -current that provide write support for > randomly writeable CD-type drives. (Mainly DVD-RAM and PD-type drives.) > > The driver should function the same as before with read-only media. > > It is now possible to do things like burn a UFS disklabel and filesystem > on a CD-R, or disklabel and newfs a DVD-RAM disk. As it turns out, there was a problem with audio CD's. In general, you can't issue a standard READ(10) with an audio CD in a drive. (Well, you can on many drives, but it generally requires changing some mode page parameters first.) The disklabel code attempts to do a read on the device to see if there is a disklabel, which causes problems with audio CDs. (Since the mode page wasn't setup beforehand.) The solution is to look at the table of contents, and only attempt to read the disklabel for drives with data tracks at the beginning of the CD. Anyway, a patch is attached that should fix the problems with audio CDs. I'd appreciate it if folks running -current would test this with whatever strange CDs or DVDs you have. I'm especially interested in Video CDs, since I don't have any to test with here. Thanks, Ken -- Kenneth Merry ken@kdm.org --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="scsi_cd.c.writefix.20001102.new" ==== //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c#13 - /a/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c ==== *** /tmp/tmp.13048.0 Thu Nov 2 21:07:47 2000 --- /a/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c Thu Nov 2 21:05:02 2000 *************** *** 207,212 **** --- 207,213 ---- u_int32_t sense_flags); static void cdprevent(struct cam_periph *periph, int action); static int cdsize(dev_t dev, u_int32_t *size); + static int cdfirsttrackisdata(struct cam_periph *periph); static int cdreadtoc(struct cam_periph *periph, u_int32_t mode, u_int32_t start, struct cd_toc_entry *data, u_int32_t len); *************** *** 920,925 **** --- 921,937 ---- } /* + * If we get a non-zero return, revert back to not reading the + * label off the disk. The first track is likely audio, which + * won't have a disklabel. + */ + if ((error = cdfirsttrackisdata(periph)) != 0) { + softc->disk.d_dsflags &= ~DSO_COMPATLABEL; + softc->disk.d_dsflags |= DSO_NOLABELS; + error = 0; + } + + /* * Build prototype label for whole disk. * Should take information about different data tracks from the * TOC and put it in the partition table. *************** *** 993,998 **** --- 1005,1017 ---- cdprevent(periph, PR_ALLOW); /* + * Unconditionally set the dsopen() flags back to their default + * state. + */ + softc->disk.d_dsflags &= ~DSO_NOLABELS; + softc->disk.d_dsflags |= DSO_COMPATLABEL; + + /* * Since we're closing this CD, mark the blocksize as unavailable. * It will be marked as available whence the CD is opened again. */ *************** *** 2540,2545 **** --- 2559,2638 ---- return (error); + } + + /* + * The idea here is to try to figure out whether the first track is data or + * audio. If it is data, we can at least attempt to read a disklabel off + * the first sector of the disk. If it is audio, there won't be a + * disklabel. + * + * This routine returns 0 if the first track is data, and non-zero if there + * is an error or the first track is audio. (If either non-zero case, we + * should not attempt to read the disklabel.) + */ + static int + cdfirsttrackisdata(struct cam_periph *periph) + { + struct cdtocdata { + struct ioc_toc_header header; + struct cd_toc_entry entries[100]; + }; + struct cd_softc *softc; + struct ioc_toc_header *th; + struct cdtocdata *data; + int num_entries, i; + int error, first_track_audio; + + error = 0; + first_track_audio = -1; + + softc = (struct cd_softc *)periph->softc; + + data = malloc(sizeof(struct cdtocdata), M_TEMP, M_WAITOK); + + th = &data->header; + error = cdreadtoc(periph, 0, 0, (struct cd_toc_entry *)data, + sizeof(*data)); + + if (error) + goto bailout; + + if (softc->quirks & CD_Q_BCD_TRACKS) { + /* we are going to have to convert the BCD + * encoding on the cd to what is expected + */ + th->starting_track = + bcd2bin(th->starting_track); + th->ending_track = bcd2bin(th->ending_track); + } + th->len = scsi_2btoul((u_int8_t *)&th->len); + + if ((th->len - 2) > 0) + num_entries = (th->len - 2) / sizeof(struct cd_toc_entry); + else + num_entries = 0; + + for (i = 0; i < num_entries; i++) { + if (data->entries[i].track == th->starting_track) { + if (data->entries[i].control & 0x4) + first_track_audio = 0; + else + first_track_audio = 1; + break; + } + } + + if (first_track_audio == -1) + error = ENOENT; + else if (first_track_audio == 1) + error = EINVAL; + else + error = 0; + bailout: + free(data, M_TEMP); + + return(error); } static int --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 2 21:20:11 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C65FA37B4C5 for ; Thu, 2 Nov 2000 21:20:06 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eA35Jma93066; Thu, 2 Nov 2000 22:19:48 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011030519.eA35Jma93066@aslan.scsiguy.com> To: The Hermit Hacker Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: Your message of "Thu, 02 Nov 2000 20:51:14 -0400." Date: Thu, 02 Nov 2000 22:19:48 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I imagine this would have to be "on the drive", but can they feed back >information for Cmd6->Cmd7 while its processing Cmd0->Cmd5? Or is it >purely FIFO? That is exactly the point. The drive does not have to handle the transactions in FIFO order unless you specificly tell it to. You can do this on a per-command basis: re-order any way that is convenient, ensure all transactions queued prior to this command complete prior to its execution, or place this transaction at the head of the queue. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 7:29:26 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (CDR20-53.accesscable.net [24.138.20.53]) by hub.freebsd.org (Postfix) with ESMTP id 21DA337B4D7 for ; Fri, 3 Nov 2000 07:29:24 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id eA3FRYL64876; Fri, 3 Nov 2000 11:27:34 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Fri, 3 Nov 2000 11:27:34 -0400 (AST) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: Tom Samplonius , freebsd-scsi@FreeBSD.ORG Subject: Re: iostat: tps for SCSI drives ... In-Reply-To: <200011030519.eA35Jma93066@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cool ... thanks all for the patience and explanations ... On Thu, 2 Nov 2000, Justin T. Gibbs wrote: > >I imagine this would have to be "on the drive", but can they feed back > >information for Cmd6->Cmd7 while its processing Cmd0->Cmd5? Or is it > >purely FIFO? > > That is exactly the point. The drive does not have to handle the > transactions in FIFO order unless you specificly tell it to. You > can do this on a per-command basis: re-order any way that is convenient, > ensure all transactions queued prior to this command complete prior to > its execution, or place this transaction at the head of the queue. > > -- > Justin > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 12:24:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id DB9A537B479 for ; Fri, 3 Nov 2000 12:24:36 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rnO3-0000IT-00 for freebsd-scsi@freebsd.org; Fri, 03 Nov 2000 12:24:31 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Subject: 68-80 on curdle second scsi chan Message-Id: Date: Fri, 03 Nov 2000 12:24:31 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org the asus cur-dls has a sym dual controller sym0: <896> port 0xb400-0xb4ff mem 0xf9000000-0xf9001fff,\ 0xf9800000-0xf98003ff irq 9 at device 5.0 on pci1 sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym1: <896> port 0xb000-0xb0ff mem 0xf8000000-0xf8001fff,\ 0xf8800000-0xf88003ff irq 9 at device 5.1 on pci1 sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. da0 at sym0 bus 0 target 0 lun 0 da1 at sym0 bus 0 target 1 lun 0 Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. Mounting root from ufs:/dev/da0a da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) it seems quite happy with the two ultra-2 drives on a 68pin cable on chan 0. the second channel is also a 68pin. i want to put on two old cd-rom drives. so i got a nicely terminated cable [0], and put on two 68m-to-80f adapters, see . when booting, the system takes a loooooong time to scan the second scsi channel, and does not see the drives. i am probably doing something very naive/stoopid. clues solicited. randy [0] - is a *wonderful* vendor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 14:59:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id DAA9C37B4CF for ; Fri, 3 Nov 2000 14:59:35 -0800 (PST) Received: from nas14-179.vlt.club-internet.fr (nas14-179.vlt.club-internet.fr [195.36.164.179]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA24155; Fri, 3 Nov 2000 23:59:26 +0100 (MET) Date: Fri, 3 Nov 2000 22:59:58 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Randy Bush Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 68-80 on curdle second scsi chan 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 Fri, 3 Nov 2000, Randy Bush wrote: > the asus cur-dls has a sym dual controller >=20 > sym0: <896> port 0xb400-0xb4ff mem 0xf9000000-0xf9001fff,\ > 0xf9800000-0xf98003ff irq 9 at device 5.0 on pci1 > sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > sym0: open drain IRQ line driver, using on-chip SRAM > sym0: using LOAD/STORE-based firmware. > sym0: handling phase mismatch from SCRIPTS. > sym1: <896> port 0xb000-0xb0ff mem 0xf8000000-0xf8001fff,\ > 0xf8800000-0xf88003ff irq 9 at device 5.1 on pci1 > sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > sym1: open drain IRQ line driver, using on-chip SRAM > sym1: using LOAD/STORE-based firmware. > sym1: handling phase mismatch from SCRIPTS. > (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > da0 at sym0 bus 0 target 0 lun 0 > da1 at sym0 bus 0 target 1 lun 0 > Waiting 5 seconds for SCSI devices to settle > (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > Mounting root from ufs:/dev/da0a > da0 at sym0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device=20 > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ > =09 Tagged Queueing Enabled > da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > da1 at sym0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device=20 > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ > =09 Tagged Queueing Enabled > da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) >=20 > it seems quite happy with the two ultra-2 drives on a 68pin cable on chan= 0. >=20 > the second channel is also a 68pin. i want to put on two old cd-rom > drives. so i got a nicely terminated cable [0], and put on two 68m-to-80= f > adapters, see . >=20 > when booting, the system takes a loooooong time to scan the second scsi > channel, and does not see the drives. >=20 > i am probably doing something very naive/stoopid. clues solicited. It may well be a termination problem, in my opinion. Given what you want to achieve, the Wide BUS must be terminated with SE (single ended signaling) at controller side and the Narrow one must be SE terminated at the other end. The Wide-to-Narrow adapter you are using seems to just connect the low part of the Wide BUS to its output and just doesn't care of the high part. Cause can be, for example: - If your SCSI controller uses some kind of auto-termination magic, it may well be confused by your configuration and not terminate the Wide BUS=20 properly at the controller side. - If there is no terminator (normally LVD/SE capable) on the controller, then the BUS is just not terminated at this side. Basically, as long as you cannot make sure that the BUS is actually terminated as required by the tinking you want to achieve, you should not expect your SCSI system to work properly. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 15:55:13 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 89E6C37B4C5 for ; Fri, 3 Nov 2000 15:55:10 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rqfn-0000vT-00; Fri, 03 Nov 2000 15:55:03 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 68-80 on curdle second scsi chan References: Message-Id: Date: Fri, 03 Nov 2000 15:55:03 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> the asus cur-dls has a sym dual controller >> >> sym0: <896> port 0xb400-0xb4ff mem 0xf9000000-0xf9001fff,\ >> 0xf9800000-0xf98003ff irq 9 at device 5.0 on pci1 >> sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking >> sym0: open drain IRQ line driver, using on-chip SRAM >> sym0: using LOAD/STORE-based firmware. >> sym0: handling phase mismatch from SCRIPTS. >> sym1: <896> port 0xb000-0xb0ff mem 0xf8000000-0xf8001fff,\ >> 0xf8800000-0xf88003ff irq 9 at device 5.1 on pci1 >> sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking >> sym1: open drain IRQ line driver, using on-chip SRAM >> sym1: using LOAD/STORE-based firmware. >> sym1: handling phase mismatch from SCRIPTS. >> (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. >> (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. >> da0 at sym0 bus 0 target 0 lun 0 >> da1 at sym0 bus 0 target 1 lun 0 >> Waiting 5 seconds for SCSI devices to settle >> (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. >> (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. >> Mounting root from ufs:/dev/da0a >> da0 at sym0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-3 device >> da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ >> Tagged Queueing Enabled >> da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) >> da1 at sym0 bus 0 target 1 lun 0 >> da1: Fixed Direct Access SCSI-3 device >> da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ >> Tagged Queueing Enabled >> da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) >> >> it seems quite happy with the two ultra-2 drives on a 68pin cable on chan 0. >> >> the second channel is also a 68pin. i want to put on two old cd-rom >> drives. so i got a nicely terminated cable [0], and put on two 68m-to-80 >> adapters, see . >> >> when booting, the system takes a loooooong time to scan the second scsi >> channel, and does not see the drives. >> >> i am probably doing something very naive/stoopid. clues solicited. > > It may well be a termination problem, in my opinion. > > Given what you want to achieve, the Wide BUS must be terminated with SE > (single ended signaling) at controller side and the Narrow one must be SE > terminated at the other end. > > The Wide-to-Narrow adapter you are using seems to just connect the low > part of the Wide BUS to its output and just doesn't care of the high part. > > Cause can be, for example: > > - If your SCSI controller uses some kind of auto-termination magic, it may > well be confused by your configuration and not terminate the Wide BUS > properly at the controller side. > - If there is no terminator (normally LVD/SE capable) on the controller, > then the BUS is just not terminated at this side. > > Basically, as long as you cannot make sure that the BUS is actually > terminated as required by the tinking you want to achieve, you should not > expect your SCSI system to work properly. i think it is terminated properly. the mobo termination is enabled. there is a terminator at the end of the 68-pin cable, an LVD/SE TRM-8915 from . i ain't sayin' that termination is not the problem. i am saying that, if it needs to be done differently, please apply clue-by-four. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 19:29:48 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from midten.fast.no (midten.fast.no [213.188.8.11]) by hub.freebsd.org (Postfix) with ESMTP id 816EF37B4C5; Fri, 3 Nov 2000 19:29:43 -0800 (PST) Received: from fast.no (IDENT:tegge@midten.fast.no [213.188.8.11]) by midten.fast.no (8.9.3/8.9.3) with ESMTP id EAA10315; Sat, 4 Nov 2000 04:29:42 +0100 (CET) Message-Id: <200011040329.EAA10315@midten.fast.no> To: gibbs@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: aic7xxx problem in 4.2-BETA Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tor.Egge@fast.no X-Mailer: Mew version 1.70 on Emacs 19.34.1 Date: Sat, 04 Nov 2000 04:29:42 +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The aic7xxx driver in FreeBSD 4.2-BETA easily crashes during probing and error recovery. On a machine with 14 disks and 3 host adapters most boot attempts results in a panic. ahc0: port 0xec00-0xecff mem 0xfe002000-0xfe002fff irq 16 at device 2.0 on pci0 ahc1: port 0xdc00-0xdcff mem 0xf8fff000-0xf8ffffff irq 5 at device 4.0 on pci2 ahc2: port 0xd800-0xd8ff mem 0xf8ffe000-0xf8ffefff irq 10 at device 4.1 on pci2 (ahc2:A:10:5): Sending PPR bus_width 1, period 9, offset 3f, ppr_options 2 (ahc2:A:10:5): Received PPR width 9, period 1, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 Fatal trap 12: page fault while in kernel mode mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc014207c stack pointer = 0x10:0xff811ea4 frame pointer = 0x10:0xff811eb4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at ahc_match_scb+0x18: movl 0(%esi),%eax db> trace ahc_match_scb(c408a400,0,d,41,5,ff,0) at ahc_match_scb+0x18 ahc_search_qinfifo(c408a400,d,41,5,ff) at ahc_search_qinfifo+0x14b ahc_freeze_devq(c408a400,c409316c) at ahc_freeze_devq+0x5d ahc_handle_seqint(c408a400,71) at ahc_handle_seqint+0x1b5 ahc_freebsd_intr(c408a400,6c010420,0,1,0) at ahc_freebsd_intr+0xd1 intr_mux(c1c6d9a0,0,ff810018,c0270010,c40a0010) at intr_mux+0x1d Xresume10() at Xresume10+0x59 --- interrupt, eip = 0xc0268fa2, esp = 0xff811ff4, ebp = 0 --- idle_loop() at idle_loop+0x44 db> call cpu_reset O(ahc0:A:2:5): Received PPR width 9, period 1, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 panic: HOST_MSG_LOOP with invalid SCB e mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 Debugger("panic") Stopped at Debugger+0x34: movb $0,in_Debugger.597 db> trace Debugger(c028a652) at Debugger+0x34 panic(c02847e0,e,c408ac00,61,68000400) at panic+0xa4 ahc_handle_seqint(c408ac00,61) at ahc_handle_seqint+0x7a9 ahc_freebsd_intr(c408ac00,6b00049a,c4070018,c0250010,10) at ahc_freebsd_intr+0xd1 Xresume5() at Xresume5+0x56 --- interrupt, eip = 0xc027a0df, esp = 0xff8119d0, ebp = 0xff8119dc --- siocntxwait(3f8,3f8,286,ff811a14,c027a5bf) at siocntxwait+0x13 siocnclose(ff811a0c,3f8) at siocnclose+0x11 siocnputc(c02d63cc,20,5,ff811a40,c0172d3f) at siocnputc+0x9f cnputc(20,c4278800,1,20,ff811ad8) at cnputc+0x42 putchar(20,ff811afc) at putchar+0x97 kvprintf(c027ce96,c0172ca8,ff811afc,a,ff811b10) at kvprintf+0x86 printf(c027ce92,c4278800,c4278800,c42a9eb0,1) at printf+0x3d cam_periph_error(c4278800,0,5,c4278c0c) at cam_periph_error+0x416 probedone(c4269200,c4278800,c1c6d9a0,40000400,ffffffff) at probedone+0x14c camisr(c02d3f70,ff811f10,c025bab4,40000400,c026ffe4) at camisr+0x1eb swi_cambio(40000400,c026ffe4,c026faab,40000400,c4088800) at swi_cambio+0xd splz_swi(c1c6d9a0,0,ff810018,c0270010,c40a0010) at splz_swi+0x14 Xresume10() at Xresume10+0x59 --- interrupt, eip = 0xc026539c, esp = 0xff811f58, ebp = 0 --- MPgetlock_edx() at MPgetlock_edx+0x28 db> sg[0] - Addr 0x10809000 : Length 4096 sg[1] - Addr 0x116ea000 : Length 4096 sg[2] - Addr 0x1162b000 : Length 1536 (da4:ahc0:0:0:0): Queuing a BDR SCB ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message SCSIID = 47, target_mask = 10 panic: SCB = 17, SCB Control = 60, MSG_OUT = ff SCB flags = 4000 mp_lock = 00000002; cpuid = 0; lapic.id = 01000000 pDebugger("panic") Stopped at Debugger+0x34: movb $0,in_Debugger.597 Debugger(c028a652) at Debugger+0x34 panic(c0284f80,11,60,ff,4000) at panic+0xa4 ahc_setup_initiator_msgout(c4076600,e39cdd0c,c40853c0) at ahc_setup_initiator_msgout+0x1af ahc_handle_seqint(c4076600,61) at ahc_handle_seqint+0x7bf ahc_freebsd_intr(c4076600,0,18,10,c0160010) at ahc_freebsd_intr+0xd1 Xresume16() at Xresume16+0x59 --- interrupt, eip = 0xc026ffe4, esp = 0xe39cdd88, ebp = 0xe39cdda8 --- splx(cc0e9438,c02c6d80) at splx+0x30 ffs_rawread(e2ebe2c0,e39cded8,c43666c0,e2ebe2c0,e39cded8) at ffs_rawread+0x300 ffs_read(e39cde68,e39ad2a0,e39ad2a0,80000,80) at ffs_read+0x74 vn_read(c43666c0,e39cded8,c439bb00,1,e39ad2a0) at vn_read+0x118 dofileread(e39ad2a0,c43666c0,3,1b864000,80000) at dofileread+0xb0 pread(e39ad2a0,e39cdf80,77225800,0,80000) at pread+0x48 syscall2(2f,2f,2f,80000,0) at syscall2+0x219 Xint0x80_syscall() at Xint0x80_syscall+0x2b db> - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 20: 3: 0 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from steinbeck.gabor.org (cb846402-a.mdsn1.wi.home.com [24.10.222.94]) by hub.freebsd.org (Postfix) with ESMTP id 0295037B688 for ; Fri, 3 Nov 2000 20:02:56 -0800 (PST) Received: from acm.org (localhost [127.0.0.1]) by steinbeck.gabor.org (8.9.3/8.9.3) with ESMTP id WAA51772; Fri, 3 Nov 2000 22:02:01 -0600 (CST) (envelope-from gabor@acm.org) Message-ID: <3A038A39.D646F2F2@acm.org> Date: Fri, 03 Nov 2000 22:02:01 -0600 From: Gabor Kincses X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: randy@psg.com Cc: scsi@freebsd.org Subject: Re: CCD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, This is all I had to do: KERNEL config file: pseudo-device ccd 4 # Concatenated disk driver gabor@steinbeck: <1160> cat /etc/ccd.conf ccd0 512 0 /dev/ad0s3f /dev/ad2s1f I have been using this since June. Early on I measured performance and I got ~75% increased random read and sequential block read/write per bonnie. bonnie suffers from file system caching but I ran it with 2x the size of my ram, which should eliminate caching artifacts. BTW, the two disks are quite dissimilar (13 and 4 GB), I just made sure to create identical sized `f' partitions. Since performance speaks for itself, I consider the disk geometry a non-issue. Granted I had to increase the interleave factor to much bigger than what the man page recommended to get optimum performance. You may also want to strip swap like this (/etc/fstab): /dev/ad0s2b none swap sw 0 0 /dev/ad2s1b none swap sw 0 0 I may have had to fiddle with disklabel when installing, but it wasn't a big deal, I think I just followed ccdconfig(8). BTW, does anybody have numbers on IDE disk speeds to help decide if a third disk would max-out a 33MHz UDMA IDE controller? -- Gabor Kincses (gabor@acm.org) Running FreeBSD 4.0-STABLE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 20:10:14 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 869A237B4CF for ; Fri, 3 Nov 2000 20:10:13 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13rudV-0001St-00; Fri, 03 Nov 2000 20:08:57 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gabor Kincses Cc: scsi@freebsd.org Subject: Re: CCD References: <3A038A39.D646F2F2@acm.org> Message-Id: Date: Fri, 03 Nov 2000 20:08:57 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i was dealing with a more complex situation. i wanted /usr. /var, etc. on ccd. so what i finally did was o install non-ccd with one of the swap partitions as /usr o build and install a ccd kernel o config /etc/ccd.conf etc o reboot ccd enabled but single user o run ccdconfig -C, and mount the partitions o tar the /usr, /var, ... into the new places o fix fstab o reboot don't know what i would do if a swap partition was not big enough to hold enough of /usr to install and build kernels. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 3 22: 3:47 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from web10305.mail.yahoo.com (web10305.mail.yahoo.com [216.136.130.83]) by hub.freebsd.org (Postfix) with SMTP id 1014337B479 for ; Fri, 3 Nov 2000 22:03:46 -0800 (PST) Message-ID: <20001104060346.98598.qmail@web10305.mail.yahoo.com> Received: from [128.165.7.206] by web10305.mail.yahoo.com; Sat, 04 Nov 2000 19:03:46 NZDT Date: Sat, 4 Nov 2000 19:03:46 +1300 (NZDT) From: =?iso-8859-1?q?Graham=20Guttocks?= Subject: ILLEGAL REQUEST, CDB errors with CD-ROM To: freebsd-scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can anyone tell me why I get the following errors on my root window every time I access my CD-ROM drive? A simple "cdcd" command barfs up the following: # cdcd info Album name: portrait of an american family Album artist: marilyn manson Total tracks: 13 Disc length: 61:05 Stopped Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): Invalid field in CDB Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): Invalid field in CDB Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 2 40 1 0 0 5 0 18 0 Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): READ SUB-CHANNEL. CDB: 42 2 40 1 0 0 5 0 18 0 Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): Invalid field in CDB Nov 4 13:37:26 wilma /kernel: (cd0:ahc1:0:4:0): Invalid field in CDB _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Nov 4 2:15:39 2000 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 0389E37B479 for ; Sat, 4 Nov 2000 02:15:34 -0800 (PST) Received: from nas24-228.vlt.club-internet.fr (nas24-228.vlt.club-internet.fr [195.36.223.228]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id LAA22795; Sat, 4 Nov 2000 11:15:26 +0100 (MET) Date: Sat, 4 Nov 2000 10:15:57 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Randy Bush Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 68-80 on curdle second scsi chan 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 Fri, 3 Nov 2000, Randy Bush wrote: Let me quote your message here: > i think it is terminated properly. the mobo termination is enabled. the= re > is a terminator at the end of the 68-pin cable, an LVD/SE TRM-8915 from= =20 > . >=20 > i ain't sayin' that termination is not the problem. i am saying that, if= it > needs to be done differently, please apply clue-by-four. I just caught that you put the adapter on the LVD/SE cable. Your initial message was unclear to me and I thought your put it at adapter side. Based on the log messages below, the driver is telling that both channels are currently LVD mode: > >> sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > >> sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking Hmmm... I will not assume that you sent me the boot messages corresponding to the problem. If it was so, then the problem would be a termination problem, unless your old CD/ROMs are LVD capable which is pretty improbable. You must read at least the following when your CDROMs are connected, sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking ^^ for the problem to have a chance not to be a termination problem. But this is not enough to make sure it is not a termination problem. G=E9rard. PS: The switching to SE mode of all devices on a SCSI BUS, including initiators and terminators is based on the electrical level of the DIFFSENS signal. On SE devices, this signal must be provided as grounded by the device and actually connected to the SCSI BUS. > >> the asus cur-dls has a sym dual controller > >>=20 > >> sym0: <896> port 0xb400-0xb4ff mem 0xf9000000-0xf9001fff,\ > >> 0xf9800000-0xf98003ff irq 9 at device 5.0 on pci1 > >> sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > >> sym0: open drain IRQ line driver, using on-chip SRAM > >> sym0: using LOAD/STORE-based firmware. > >> sym0: handling phase mismatch from SCRIPTS. > >> sym1: <896> port 0xb000-0xb0ff mem 0xf8000000-0xf8001fff,\ > >> 0xf8800000-0xf88003ff irq 9 at device 5.1 on pci1 > >> sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > >> sym1: open drain IRQ line driver, using on-chip SRAM > >> sym1: using LOAD/STORE-based firmware. > >> sym1: handling phase mismatch from SCRIPTS. > >> (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > >> (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > >> da0 at sym0 bus 0 target 0 lun 0 > >> da1 at sym0 bus 0 target 1 lun 0 > >> Waiting 5 seconds for SCSI devices to settle > >> (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > >> (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > >> Mounting root from ufs:/dev/da0a > >> da0 at sym0 bus 0 target 0 lun 0 > >> da0: Fixed Direct Access SCSI-3 device=20 > >> da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ > >> =09 Tagged Queueing Enabled > >> da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > >> da1 at sym0 bus 0 target 1 lun 0 > >> da1: Fixed Direct Access SCSI-3 device=20 > >> da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ > >> =09 Tagged Queueing Enabled > >> da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > >>=20 > >> it seems quite happy with the two ultra-2 drives on a 68pin cable on c= han 0. > >>=20 > >> the second channel is also a 68pin. i want to put on two old cd-rom > >> drives. so i got a nicely terminated cable [0], and put on two 68m-to= -80 > >> adapters, see . > >>=20 > >> when booting, the system takes a loooooong time to scan the second scs= i > >> channel, and does not see the drives. > >>=20 > >> i am probably doing something very naive/stoopid. clues solicited. > >=20 > > It may well be a termination problem, in my opinion. > >=20 > > Given what you want to achieve, the Wide BUS must be terminated with SE > > (single ended signaling) at controller side and the Narrow one must be = SE > > terminated at the other end. > >=20 > > The Wide-to-Narrow adapter you are using seems to just connect the low > > part of the Wide BUS to its output and just doesn't care of the high pa= rt. > >=20 > > Cause can be, for example: > >=20 > > - If your SCSI controller uses some kind of auto-termination magic, it = may > > well be confused by your configuration and not terminate the Wide BUS= =20 > > properly at the controller side. > > - If there is no terminator (normally LVD/SE capable) on the controller= , > > then the BUS is just not terminated at this side. > >=20 > > Basically, as long as you cannot make sure that the BUS is actually > > terminated as required by the tinking you want to achieve, you should n= ot > > expect your SCSI system to work properly. >=20 > i think it is terminated properly. the mobo termination is enabled. the= re > is a terminator at the end of the 68-pin cable, an LVD/SE TRM-8915 from= =20 > . >=20 > i ain't sayin' that termination is not the problem. i am saying that, if= it > needs to be done differently, please apply clue-by-four. >=20 > randy >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Nov 4 14:11:28 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 93EAA37B4C5 for ; Sat, 4 Nov 2000 14:11:27 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13sBWx-0006v5-00; Sat, 04 Nov 2000 22:11:19 +0000 Date: Sat, 4 Nov 2000 22:11:18 +0000 From: Tony Finch To: "Marc G. Fournier" Cc: freebsd-scsi@freebsd.org Subject: Re: iostat: tps for SCSI drives ... Message-ID: <20001104221118.A4627@hand.dotat.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: Organization: Covalent Technologies, Inc Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Marc G. Fournier" wrote: > >what is considered to be a 'saturated drive', as far as tps is >concerned? Obviously it depends on the drive. My laptop maxes out at about 70tps but a good scsi disk can do 150. I use `systat -vm` to get some idea of disk load relative to capacity. Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Nov 4 19:44:30 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from steinbeck.gabor.org (cb846402-a.mdsn1.wi.home.com [24.10.222.94]) by hub.freebsd.org (Postfix) with ESMTP id 4582237B4CF for ; Sat, 4 Nov 2000 19:44:28 -0800 (PST) Received: from acm.org (localhost [127.0.0.1]) by steinbeck.gabor.org (8.9.3/8.9.3) with ESMTP id VAA55501; Sat, 4 Nov 2000 21:44:55 -0600 (CST) (envelope-from gabor@acm.org) Message-ID: <3A04D7B6.77E2AFEB@acm.org> Date: Sat, 04 Nov 2000 21:44:54 -0600 From: Gabor Kincses X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush Cc: scsi@freebsd.org Subject: Re: CCD References: <3A038A39.D646F2F2@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Randy Bush wrote: > > i was dealing with a more complex situation. i wanted /usr. /var, etc. on > ccd. > > so what i finally did was > o install non-ccd with one of the swap partitions as /usr > o build and install a ccd kernel > o config /etc/ccd.conf etc > o reboot ccd enabled but single user > o run ccdconfig -C, and mount the partitions > o tar the /usr, /var, ... into the new places > o fix fstab > o reboot > > don't know what i would do if a swap partition was not big enough to hold > enough of /usr to install and build kernels. An old disk lying around might do the trick. I actually had some extra space, since the two disks are of different size, which is where the original /usr was/is. I just tar'd and moved the directories in /usr to /usr2 (the ccd partition) and create symlinks. What sort of performance gain did you see (particularly random reads)? -- Gabor Kincses (gabor@acm.org) Running FreeBSD 4.0-STABLE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message