From owner-freebsd-scsi@FreeBSD.ORG Sun May 11 22:46:21 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E456F37B404 for ; Sun, 11 May 2003 22:46:21 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id EAF1B43FDD for ; Sun, 11 May 2003 22:46:20 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 73111 invoked by uid 1000); 12 May 2003 05:46:23 -0000 Date: Sun, 11 May 2003 22:46:23 -0700 (PDT) From: Nate Lawson To: Chuck McCrobie In-Reply-To: <20030509194425.35530.qmail@web14811.mail.yahoo.com> Message-ID: <20030511224413.T73059@root.org> References: <20030509194425.35530.qmail@web14811.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Error handling of SERIAL NUMBER probe during device probing X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 05:46:22 -0000 On Fri, 9 May 2003, Chuck McCrobie wrote: > I have a Powerfile Firewire device. It contains two > DVD-RAM drives, a TOSHIBA and a PANASONIC. One of the > drives does not support the probe for SERIAL NUMBER, > specifically the following command: > > sbp0:0:1 XPT_SCSI_IO: cmd: 12 21 80 00 ff 00 00 00 00 > 00, flags: 0x40, 6b cmd/255b data/18b sense > sbp0:0:1 SCSI status 2 sfmt 0 valid 0 key 5 code 24 > qlfr 0 len 3 > > I suppose I need a quirk entry in cam_xpt.c for > CAM_QUIRK_NOSERIAL, but shouldn't the serial number > probe simply give up on ILLEGAL_COMMAND (key=5, > code=24 => INVALID FIELD IN CDB). Something is retransmitting the command, possibly the firewire driver since CAM doesn't retransmit for that particular error. The drive appears to be responding correctly. -Nate From owner-freebsd-scsi@FreeBSD.ORG Mon May 12 11:02:56 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04CA637B409 for ; Mon, 12 May 2003 11:02:56 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E68E43F93 for ; Mon, 12 May 2003 11:02:53 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4CI2rUp035980 for ; Mon, 12 May 2003 11:02:53 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4CI2qqK035974 for scsi@freebsd.org; Mon, 12 May 2003 11:02:52 -0700 (PDT) Date: Mon, 12 May 2003 11:02:52 -0700 (PDT) Message-Id: <200305121802.h4CI2qqK035974@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: scsi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 18:02:56 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1999/12/21] kern/15608 scsi acd0 / cd0 give inconsistent errors on em 1 problem total. From owner-freebsd-scsi@FreeBSD.ORG Mon May 12 12:45:29 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F363437B401 for ; Mon, 12 May 2003 12:45:28 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id F17AD43FAF for ; Mon, 12 May 2003 12:45:27 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 93C443D28 for ; Mon, 12 May 2003 15:45:26 -0400 (EDT) From: "Dan Langille" To: freebsd-scsi@freebsd.org Date: Mon, 12 May 2003 15:45:24 -0400 MIME-Version: 1.0 Message-ID: <3EBFC194.23070.5D6681F1@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: do we have MTIOCLRERR on ioctl? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 19:45:29 -0000 Anyone any any ideas about this issue? ------- Forwarded message follows ------- Subject: Re: [Bacula-users] Too many errors trying to mount From: Kern Sibbald To: Dan Langille Copies to: bacula-users Organization: Date sent: 12 May 2003 21:38:43 +0200 Hello Dan, No, I don't mind you forwarding my email. You can always do so. Best regards, Kern PS: Just to amplify a bit: When Bacula gets an EOM, it immediately writes two EOF marks. One would be sufficient, but this way I am sure that the tape is terminated for ALL drives. It then does two backspace files followed by a backspace record, if that succeeds, it re-reads the last record and compares the CRC and block number with what it wrote and reports success or failure. On FreeBSD (at least your case), it was the backspace record that failed as is the case on a certain number of tape drives. However, what was unusual was that it "froze" the tape. Bacula then does an ioctl() MTIOCLRERR on all systems that support it -- hoping to clear the error condition. On Mon, 2003-05-12 at 19:39, Dan Langille wrote: > Do you mind if I forward this message to the freebsd-scsi list in > case someone can suggest something? > > On 12 May 2003 at 19:32, Kern Sibbald wrote: > > > Hello Dan, > > > > Thanks for researching this. I also looked for MTIOCLRERR, > > but it doesn't seem to exist on FreeBSD. > > > > I looked over the off list email you sent, but it > > doesn't help much since the problem is not the handling > > at the soft EOM, but rather what happens when I > > try to backup and check the last record. That works > > fine on Linux and Solaris, but not on FreeBSD, so > > the solution is to turn off Backward Space Record > > on FreeBSD. > > > > Though I am not too happy about it, I have also > > added a rewind() when Bacula releases the tape > > before acquiring the next tape. That should "unfreeze" > > the drive. I don't like the rewind because it can > > potentially be time consuming, and if the user > > really wants it he could use the non-rewinding > > drive. Just the same, if that corrects this > > problem, then at least for the moment I'll leave > > the rewind in. > > > > Best regards, > > > > Kern > > > > On Mon, 2003-05-12 at 17:49, Dan Langille wrote: > > > On 10 May 2003 at 10:18, Kern Sibbald wrote: > > > > > > > After looking over the code, I see that if you have not > > > > configured the device to do an offline on closing, Bacula > > > > simply closes the device without rewinding it. If one does a > > > > strict interpretation of your kernel output, the error would > > > > have then persisted from one tape to another (not really > > > > correct). Whatever the case may be, I've now added code to > > > > Bacula to rewind the drive before releasing it when it is > > > > asking for another tape. > > > > > > > > If your kernel supports MTIOCLRERR, Bacula does issue that > > > > command (ioctl()) after any such error attempting to clear the > > > > error condition. However, that function is not implemented on > > > > all systems. If there is some other way of doing it on your > > > > system, please let me know and I'll add the code. > > > > > > I could find no reference to MTIOCLRERR in either the mtio or > > > the ioctl man pages. But I did speak with a FreeBSD coder about > > > this issue. I suggest asking on the freebsd-scsi@freebsd.org > > > mailing list. They're a very helpful group. > > > > > ------- End of forwarded message ------- -- Dan Langille : http://www.langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Tue May 13 16:57:12 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8937937B401 for ; Tue, 13 May 2003 16:57:12 -0700 (PDT) Received: from mobile.hub.org (u153n214.eastlink.ca [24.224.153.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D6643F93 for ; Tue, 13 May 2003 16:57:11 -0700 (PDT) (envelope-from scrappy@hub.org) Received: by mobile.hub.org (Postfix, from userid 1001) id 475981CD; Fri, 9 May 2003 22:25:51 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mobile.hub.org (Postfix) with ESMTP id 41FBB1C9 for ; Fri, 9 May 2003 22:25:51 -0300 (ADT) Date: Fri, 9 May 2003 22:25:51 -0300 (ADT) From: The Hermit Hacker To: freebsd-scsi@freebsd.org Message-ID: <20030509222154.N728@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RAID5 capacities / usable drive space ... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 23:57:12 -0000 I have someone telling me something that I'd never heard before, and find difficult to believe ... Apparently, he is under the impression that altho a file system shows a capacity of, say, 100G, its usable space is around 50% of that ... anything higher then that, you risk problems ... (significantly reduced MTBF of the drives, degradation in performance, etc) ... His opinion seems to be based on some talks he had with ppl at IBM and Seagate way back in '89, but still seems to feel they are applicable today ... Is there any fact behind his opinion? If not, anything I can point him at to read? If so, anything I can be pointed at to read? Thanks ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org From owner-freebsd-scsi@FreeBSD.ORG Tue May 13 17:57:41 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D75F737B401 for ; Tue, 13 May 2003 17:57:41 -0700 (PDT) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32D6C43F93 for ; Tue, 13 May 2003 17:57:40 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 0885951A94; Wed, 14 May 2003 10:27:38 +0930 (CST) Date: Wed, 14 May 2003 10:27:38 +0930 From: Greg 'groggy' Lehey To: The Hermit Hacker Message-ID: <20030514005737.GA68496@wantadilla.lemis.com> References: <20030509222154.N728@hub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20030509222154.N728@hub.org> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-scsi@freebsd.org Subject: Re: RAID5 capacities / usable drive space ... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 00:57:42 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 9 May 2003 at 22:25:51 -0300, The Hermit Hacker wrote: > > I have someone telling me something that I'd never heard before, and find > difficult to believe ... > > Apparently, he is under the impression that altho a file system shows a > capacity of, say, 100G, its usable space is around 50% of that ... > anything higher then that, you risk problems ... (significantly reduced > MTBF of the drives, degradation in performance, etc) ... > > His opinion seems to be based on some talks he had with ppl at IBM and > Seagate way back in '89, but still seems to feel they are applicable today > ... > > Is there any fact behind his opinion? It's difficult to say if he hasn't specified reasons. I can think of a couple of possibilities. One would be, of course, that RAID-5 always has overhead for parity, and the other is the fact that file system performance deteriorates when the file system fills up (thus the 10% left over by UFS). None of these sound like good reasons, though. MTBF depends on the activity, not what kind of data (allocated/non-allocated) is on the drives. Greg -- See complete headers for address and phone numbers --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+wZSBIubykFB6QiMRAnyHAJ9pALn6i2gMaJCteDEvzEYB7QO3QgCghnpR dqRg3kni7ux1rfKzdvwWEd4= =OpmP -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-scsi@FreeBSD.ORG Tue May 13 18:13:49 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57EE337B401; Tue, 13 May 2003 18:13:49 -0700 (PDT) Received: from hub.org (hub.org [64.117.224.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id A00C743FA3; Tue, 13 May 2003 18:13:48 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [64.117.224.146]) by hub.org (Postfix) with ESMTP id B067B184D26F; Tue, 13 May 2003 22:13:45 -0300 (ADT) Date: Tue, 13 May 2003 22:13:45 -0300 (ADT) From: "Marc G. Fournier" To: Greg 'groggy' Lehey In-Reply-To: <20030514005737.GA68496@wantadilla.lemis.com> Message-ID: <20030513220947.L3557@hub.org> References: <20030509222154.N728@hub.org> <20030514005737.GA68496@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: RAID5 capacities / usable drive space ... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 01:13:49 -0000 'K ... I'm going to be setting up a server to test my knowledge here, but, I've had someone tell me: "the fact that you need a minimum of three drives in Raid 5, so a three drive configuration in Raid5 is not hot swappable nor will it boot with less than three working drives." .... My understanding was that if I had three drives in a RAID5 configuration, and one died, the file system would still function with the 2 drives ... Thanks ... On Wed, 14 May 2003, Greg 'groggy' Lehey wrote: > On Friday, 9 May 2003 at 22:25:51 -0300, The Hermit Hacker wrote: > > > > I have someone telling me something that I'd never heard before, and find > > difficult to believe ... > > > > Apparently, he is under the impression that altho a file system shows a > > capacity of, say, 100G, its usable space is around 50% of that ... > > anything higher then that, you risk problems ... (significantly reduced > > MTBF of the drives, degradation in performance, etc) ... > > > > His opinion seems to be based on some talks he had with ppl at IBM and > > Seagate way back in '89, but still seems to feel they are applicable today > > ... > > > > Is there any fact behind his opinion? > > It's difficult to say if he hasn't specified reasons. > > I can think of a couple of possibilities. One would be, of course, > that RAID-5 always has overhead for parity, and the other is the fact > that file system performance deteriorates when the file system fills > up (thus the 10% left over by UFS). None of these sound like good > reasons, though. MTBF depends on the activity, not what kind of data > (allocated/non-allocated) is on the drives. > > Greg > -- > See complete headers for address and phone numbers > From owner-freebsd-scsi@FreeBSD.ORG Tue May 13 19:23:12 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 527E137B401 for ; Tue, 13 May 2003 19:23:12 -0700 (PDT) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8821343F75 for ; Tue, 13 May 2003 19:23:10 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 6F3BF51A95; Wed, 14 May 2003 11:53:08 +0930 (CST) Date: Wed, 14 May 2003 11:53:08 +0930 From: Greg 'groggy' Lehey To: "Marc G. Fournier" Message-ID: <20030514022308.GA70087@wantadilla.lemis.com> References: <20030509222154.N728@hub.org> <20030514005737.GA68496@wantadilla.lemis.com> <20030513220947.L3557@hub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20030513220947.L3557@hub.org> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-scsi@freebsd.org Subject: Re: RAID5 capacities / usable drive space ... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 02:23:12 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 13 May 2003 at 22:13:45 -0300, Marc G. Fournier wrote: > On Wed, 14 May 2003, Greg 'groggy' Lehey wrote: > >> On Friday, 9 May 2003 at 22:25:51 -0300, The Hermit Hacker wrote: >>> >>> I have someone telling me something that I'd never heard before, and find >>> difficult to believe ... >>> >>> Apparently, he is under the impression that altho a file system shows a >>> capacity of, say, 100G, its usable space is around 50% of that ... >>> anything higher then that, you risk problems ... (significantly reduced >>> MTBF of the drives, degradation in performance, etc) ... >>> >>> His opinion seems to be based on some talks he had with ppl at IBM and >>> Seagate way back in '89, but still seems to feel they are applicable today >>> ... >>> >>> Is there any fact behind his opinion? >> >> It's difficult to say if he hasn't specified reasons. >> >> I can think of a couple of possibilities. One would be, of course, >> that RAID-5 always has overhead for parity, and the other is the fact >> that file system performance deteriorates when the file system fills >> up (thus the 10% left over by UFS). None of these sound like good >> reasons, though. MTBF depends on the activity, not what kind of data >> (allocated/non-allocated) is on the drives. > > 'K ... I'm going to be setting up a server to test my knowledge here, but, > I've had someone tell me: "the fact that you need a minimum of three > drives in Raid 5, so a three drive configuration in Raid5 is not hot > swappable nor will it boot with less than three working drives." > .... Hmm. You know some interesting someones. Yes, it doesn't make sense to have a RAID-5 volume with less than three drives, but in degraded mode it'll run with two. Or it should, bar implementation constraints. And theoretically you could hot swap them. > My understanding was that if I had three drives in a RAID5 > configuration, and one died, the file system would still function > with the 2 drives ... Yes, that's the intention. Greg -- See complete headers for address and phone numbers --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+waiMIubykFB6QiMRAr0eAJ9vuhHLWqeRGJ3hg3J2hh0fkc+pWQCdGiD1 RcK4TaU1WtWHVwXXTStr2TM= =KdzE -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-scsi@FreeBSD.ORG Tue May 13 19:50:00 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56D0937B401; Tue, 13 May 2003 19:50:00 -0700 (PDT) Received: from hub.org (hub.org [64.117.224.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF84C43FBD; Tue, 13 May 2003 19:49:59 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [64.117.224.146]) by hub.org (Postfix) with ESMTP id 4AEBF184D243; Tue, 13 May 2003 23:49:56 -0300 (ADT) Date: Tue, 13 May 2003 23:49:56 -0300 (ADT) From: "Marc G. Fournier" To: Greg 'groggy' Lehey In-Reply-To: <20030514022308.GA70087@wantadilla.lemis.com> Message-ID: <20030513234434.V3557@hub.org> References: <20030509222154.N728@hub.org> <20030514005737.GA68496@wantadilla.lemis.com> <20030514022308.GA70087@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: RAID5 capacities / usable drive space ... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 02:50:00 -0000 On Wed, 14 May 2003, Greg 'groggy' Lehey wrote: > Hmm. You know some interesting someones. Yup ... > Yes, it doesn't make sense to have a RAID-5 volume with less than three > drives, but in degraded mode it'll run with two. Or it should, bar > implementation constraints. And theoretically you could hot swap them. 'K, I'm going to test the 'theory' out tomorrow just to make double sure about the 3->2 drive configuration ... since you already know the vinum internals, I'm more worried about how hardware RAID will handle things ... Actually, Scott, are you out there anywhere? Do you know how the Adaptec RAID controllers would handle things? Thanks ... From owner-freebsd-scsi@FreeBSD.ORG Wed May 14 00:56:25 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A34737B401; Wed, 14 May 2003 00:56:25 -0700 (PDT) Received: from franky.speednet.com.au (franky.speednet.com.au [203.57.65.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2831E43FA3; Wed, 14 May 2003 00:56:24 -0700 (PDT) (envelope-from andyf@speednet.com.au) Received: from hewey.af.speednet.com.au (hewey.af.speednet.com.au [203.38.96.242])h4E7uLYr082526; Wed, 14 May 2003 17:56:22 +1000 (EST) (envelope-from andyf@speednet.com.au) Received: from hewey.af.speednet.com.au (hewey.af.speednet.com.au [172.22.2.17])h4E7uJYm070954; Wed, 14 May 2003 17:56:21 +1000 (EST) (envelope-from andyf@speednet.com.au) Date: Wed, 14 May 2003 17:56:19 +1000 (EST) From: Andy Farkas X-X-Sender: andyf@hewey.af.speednet.com.au To: "Marc G. Fournier" In-Reply-To: <20030513234434.V3557@hub.org> Message-ID: <20030514175000.E69707-100000@hewey.af.speednet.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Greg 'groggy' Lehey cc: freebsd-scsi@freebsd.org Subject: Re: RAID5 capacities / usable drive space ... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 07:56:25 -0000 On Tue, 13 May 2003, Marc G. Fournier wrote: > On Wed, 14 May 2003, Greg 'groggy' Lehey wrote: > > > Hmm. You know some interesting someones. > > Yup ... > > > Yes, it doesn't make sense to have a RAID-5 volume with less than three > > drives, but in degraded mode it'll run with two. Or it should, bar > > implementation constraints. And theoretically you could hot swap them. > > 'K, I'm going to test the 'theory' out tomorrow just to make double sure > about the 3->2 drive configuration ... since you already know the vinum > internals, I'm more worried about how hardware RAID will handle things ... I had a vinum raid-5 volume lose a disk a few months ago. vinum handled it fine for the couple of weeks while waiting for a replacement (including reboots). Adding in the replacement disk is a whole other story. It may well be worth practicing. Documentation in this area is lacking. -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ From owner-freebsd-scsi@FreeBSD.ORG Wed May 14 15:44:42 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A65837B401 for ; Wed, 14 May 2003 15:44:42 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id EBB0543F3F for ; Wed, 14 May 2003 15:44:39 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 79389 invoked by uid 1000); 14 May 2003 22:44:41 -0000 Date: Wed, 14 May 2003 15:44:41 -0700 (PDT) From: Nate Lawson To: scsi@freebsd.org Message-ID: <20030514151752.B79363@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: SCSI geometry calculation? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 22:44:42 -0000 I am reviewing our current geometry calculation and have a few questions. Here is what I found in my review. Most drivers use >1G: 255/63, else 64/32. Exceptions are: * aac - >=2G: 255/63, >=1G 128/32, else 64/32 * aha - same * amr - >2G: 255/63, else 64/32 * asr - >4G: 255/63, >2G: 128/63, >1G: 65/63, else 64/32 * ata-raid - always 255/63 * bt - same as aha * ciss - 255/32 if fault_tolerance is invalid else what the logical drive reports. * mlx - if MLX_GEOM_256_63 set: 255/63, else 128/32. Since nothing seems to set mlx_geom, 128/32 is probably always used. * mly - same * pst - always 255/63 * twe - >2G: 255/63, else 64/32 Some of these seem to be bugs, especially for volumes exactly on a boundary (2G). Since many of the stranger ones are RAID controllers, they won't have to support drive portability to other controllers. What should actually be done in CALC_GEOMETRY? -Nate From owner-freebsd-scsi@FreeBSD.ORG Wed May 14 15:54:16 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F002237B401 for ; Wed, 14 May 2003 15:54:16 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 34B4943F3F for ; Wed, 14 May 2003 15:54:16 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 79406 invoked by uid 1000); 14 May 2003 22:54:17 -0000 Date: Wed, 14 May 2003 15:54:17 -0700 (PDT) From: Nate Lawson To: Dan Langille , Kern Sibbald In-Reply-To: <3EBFC194.23070.5D6681F1@localhost> Message-ID: <20030514155057.R79399@root.org> References: <3EBFC194.23070.5D6681F1@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: do we have MTIOCLRERR on ioctl? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 22:54:17 -0000 On Mon, 12 May 2003, Dan Langille wrote: > ------- Forwarded message follows ------- > From: Kern Sibbald > > PS: Just to amplify a bit: When Bacula gets an EOM, > it immediately writes two EOF marks. One would be > sufficient, but this way I am sure that the tape > is terminated for ALL drives. It then does > two backspace files followed by a backspace > record, if that succeeds, it re-reads the last > record and compares the CRC and block number with > what it wrote and reports success or failure. > > On FreeBSD (at least your case), it was the backspace > record that failed as is the case on a certain number > of tape drives. However, what was unusual was that > it "froze" the tape. Bacula then does an ioctl() > MTIOCLRERR on all systems that support it -- hoping > to clear the error condition. I'm not very familiar with tape drives but I think what you want is MTIOCERRSTAT. It reads the current error condition and then zeros it (see /sys/cam/scsi/scsi_sa.c). Try using that for Bacula on FreeBSD. -Nate From owner-freebsd-scsi@FreeBSD.ORG Wed May 14 16:08:57 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ED1637B433 for ; Wed, 14 May 2003 16:08:52 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 824B543FBD for ; Wed, 14 May 2003 16:08:51 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4EN4wZ01024; Wed, 14 May 2003 16:04:58 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA13970; Wed, 14 May 2003 16:08:40 -0700 (PDT) Message-ID: <3EC2CBD0.3020102@btc.adaptec.com> Date: Wed, 14 May 2003 17:05:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20030514151752.B79363@root.org> In-Reply-To: <20030514151752.B79363@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: scsi@freebsd.org Subject: Re: SCSI geometry calculation? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 23:08:57 -0000 Nate Lawson wrote: > I am reviewing our current geometry calculation and have a few questions. > Here is what I found in my review. > > Most drivers use >1G: 255/63, else 64/32. Exceptions are: > * aac - >=2G: 255/63, >=1G 128/32, else 64/32 > * aha - same > * amr - >2G: 255/63, else 64/32 > * asr - >4G: 255/63, >2G: 128/63, >1G: 65/63, else 64/32 > * ata-raid - always 255/63 > * bt - same as aha > * ciss - 255/32 if fault_tolerance is invalid else what the logical drive > reports. > * mlx - if MLX_GEOM_256_63 set: 255/63, else 128/32. Since nothing seems > to set mlx_geom, 128/32 is probably always used. > * mly - same > * pst - always 255/63 > * twe - >2G: 255/63, else 64/32 > > Some of these seem to be bugs, especially for volumes exactly on a > boundary (2G). Since many of the stranger ones are RAID controllers, they > won't have to support drive portability to other controllers. What should > actually be done in CALC_GEOMETRY? > Remember that with most RAID controllers, the volumes that you see are logical and have no bearing on the physical drives that compose them. The 'odd' geometry requirements usually stem from the requirements of the controller BIOS. FreeBSD needs to respect their geometry in order for the arrays to remain bootable and portable to other OS's (i.e. remain compatible with their BIOS). I'm really not sure what to say about the boundary cases other than if they are buggy, few people notice. mlx and mly are special in that you can set the geometry that the BIOS uses from the BIOS POST menu; I think it's assumed that if you change this then you know what you're doing. Scott From owner-freebsd-scsi@FreeBSD.ORG Wed May 14 16:16:47 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 800BE37B401 for ; Wed, 14 May 2003 16:16:47 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0AB9E43FA3 for ; Wed, 14 May 2003 16:16:47 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 79475 invoked by uid 1000); 14 May 2003 23:16:48 -0000 Date: Wed, 14 May 2003 16:16:48 -0700 (PDT) From: Nate Lawson To: Scott Long In-Reply-To: <3EC2CBD0.3020102@btc.adaptec.com> Message-ID: <20030514161256.N79399@root.org> References: <20030514151752.B79363@root.org> <3EC2CBD0.3020102@btc.adaptec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: scsi@freebsd.org Subject: Re: SCSI geometry calculation? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 23:16:47 -0000 On Wed, 14 May 2003, Scott Long wrote: > > Most drivers use >1G: 255/63, else 64/32. Exceptions are: > > * aac - >=2G: 255/63, >=1G 128/32, else 64/32 > > * aha - same > > * bt - same as aha Why are aha and bt using an extra 2G step instead of the normal 1G step? They're not RAID controllers. Did you use that geometry for aac intentionally or was it just a cut/paste? > I'm really not sure what to say > about the boundary cases other than if they are buggy, few people > notice. Would it be ok to move them all to > and not use >=? -Nate From owner-freebsd-scsi@FreeBSD.ORG Wed May 14 16:32:19 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B720137B401 for ; Wed, 14 May 2003 16:32:19 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 349D343F3F for ; Wed, 14 May 2003 16:32:17 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4ENSQZ13578; Wed, 14 May 2003 16:28:26 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA23927; Wed, 14 May 2003 16:32:11 -0700 (PDT) Message-ID: <3EC2D157.5000705@btc.adaptec.com> Date: Wed, 14 May 2003 17:29:27 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20030514151752.B79363@root.org> <3EC2CBD0.3020102@btc.adaptec.com> <20030514161256.N79399@root.org> In-Reply-To: <20030514161256.N79399@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: scsi@freebsd.org Subject: Re: SCSI geometry calculation? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 23:32:20 -0000 Nate Lawson wrote: > On Wed, 14 May 2003, Scott Long wrote: > >>>Most drivers use >1G: 255/63, else 64/32. Exceptions are: >>>* aac - >=2G: 255/63, >=1G 128/32, else 64/32 >>>* aha - same >>>* bt - same as aha > > > Why are aha and bt using an extra 2G step instead of the normal 1G step? > They're not RAID controllers. Did you use that geometry for aac > intentionally or was it just a cut/paste? > The aac definition was taken from the aac spec. The aac spec coincidentally is similar to other adaptec products, though Justin can speak definitively on aic7xxx/aic79xx. > >>I'm really not sure what to say >>about the boundary cases other than if they are buggy, few people >>notice. > > > Would it be ok to move them all to > and not use >=? > Probably yes, though it might be useful to get build some experimental evidence first. Scott From owner-freebsd-scsi@FreeBSD.ORG Thu May 15 00:22:25 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 245C737B401 for ; Thu, 15 May 2003 00:22:25 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A94743FA3 for ; Thu, 15 May 2003 00:22:23 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h4F7Lvf29630; Thu, 15 May 2003 09:21:57 +0200 From: Kern Sibbald To: Nate Lawson In-Reply-To: <20030514155057.R79399@root.org> References: <3EBFC194.23070.5D6681F1@localhost> <20030514155057.R79399@root.org> Content-Type: text/plain Organization: Message-Id: <1052983316.6566.219.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 May 2003 09:21:57 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-scsi@freebsd.org Subject: Re: do we have MTIOCLRERR on ioctl? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 07:22:25 -0000 Hello, Thanks for the tip. In reading your email and looking at mtio.h, I do believe that it is exactly what I need to clear error conditions on FreeBSD, so I will implement it. Thanks for the help. Best regards, Kern On Thu, 2003-05-15 at 00:54, Nate Lawson wrote: > On Mon, 12 May 2003, Dan Langille wrote: > > ------- Forwarded message follows ------- > > From: Kern Sibbald > > > > PS: Just to amplify a bit: When Bacula gets an EOM, > > it immediately writes two EOF marks. One would be > > sufficient, but this way I am sure that the tape > > is terminated for ALL drives. It then does > > two backspace files followed by a backspace > > record, if that succeeds, it re-reads the last > > record and compares the CRC and block number with > > what it wrote and reports success or failure. > > > > On FreeBSD (at least your case), it was the backspace > > record that failed as is the case on a certain number > > of tape drives. However, what was unusual was that > > it "froze" the tape. Bacula then does an ioctl() > > MTIOCLRERR on all systems that support it -- hoping > > to clear the error condition. > > I'm not very familiar with tape drives but I think what you want is > MTIOCERRSTAT. It reads the current error condition and then zeros it (see > /sys/cam/scsi/scsi_sa.c). Try using that for Bacula on FreeBSD. > > -Nate From owner-freebsd-scsi@FreeBSD.ORG Thu May 15 13:07:05 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFF1637B401; Thu, 15 May 2003 13:07:05 -0700 (PDT) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8E4243F93; Thu, 15 May 2003 13:07:04 -0700 (PDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (250-217.customer.cloud9.net [168.100.250.217])h4FK7075069027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 15 May 2003 16:07:02 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: scsi@FreeBSD.org Date: Thu, 15 May 2003 16:07:02 -0400 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305151607.02102.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) cc: gibbs@FreeBSD.org cc: ken@FreeBSD.org cc: aschneider@murex.com Subject: troubles with an Exhabyte tape drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 20:07:06 -0000 Hello! We can read the tapes using this drive: sym0: <875> port 0x2400-0x24ff mem 0x42000000-0x42000fff,0x42100000-0x421000ff irq 11 at device 16.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sa0 at sym0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) but we can not write anything :-( The kernel's messages logged are: (sa0:sym0:0:0:0): WRITE(06). CDB: a 0 0 28 0 0 (sa0:sym0:0:0:0): ILLEGAL REQUEST asc:30,5 (sa0:sym0:0:0:0): Cannot write medium - incompatible format Is it our clumsiness, or the tapes (we tried about a dozen), or the drive? Thanks a lot! -mi From owner-freebsd-scsi@FreeBSD.ORG Thu May 15 13:14:28 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4A4E37B401; Thu, 15 May 2003 13:14:28 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA61B43FA3; Thu, 15 May 2003 13:14:27 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.9/8.12.5) with ESMTP id h4FKDXPM000681; Thu, 15 May 2003 14:13:33 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.9/8.12.5/Submit) id h4FKDXeX000680; Thu, 15 May 2003 14:13:33 -0600 (MDT) (envelope-from ken) Date: Thu, 15 May 2003 14:13:33 -0600 From: "Kenneth D. Merry" To: Mikhail Teterin Message-ID: <20030515141332.A668@panzer.kdm.org> References: <200305151607.02102.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200305151607.02102.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Thu, May 15, 2003 at 04:07:02PM -0400 cc: gibbs@FreeBSD.org cc: aschneider@murex.com cc: scsi@FreeBSD.org Subject: Re: troubles with an Exhabyte tape drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 20:14:29 -0000 On Thu, May 15, 2003 at 16:07:02 -0400, Mikhail Teterin wrote: > Hello! > > We can read the tapes using this drive: > > sym0: <875> port 0x2400-0x24ff mem 0x42000000-0x42000fff,0x42100000-0x421000ff > irq 11 at device 16.0 on pci0 > sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking > sym0: open drain IRQ line driver, using on-chip SRAM > sym0: using LOAD/STORE-based firmware. > sa0 at sym0 bus 0 target 0 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) > > > but we can not write anything :-( The kernel's messages logged are: > > (sa0:sym0:0:0:0): WRITE(06). CDB: a 0 0 28 0 0 > (sa0:sym0:0:0:0): ILLEGAL REQUEST asc:30,5 > (sa0:sym0:0:0:0): Cannot write medium - incompatible format > > Is it our clumsiness, or the tapes (we tried about a dozen), or the > drive? Thanks a lot! I'm guessing it's the tapes. That's what the message seems to say. Are you *sure* your tapes are write compatible with the drive? I know there are various Exabyte drives that can read, but not write, old format tapes. Since you can read the tapes but can't write them, I'm guessing that that's the problem. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-scsi@FreeBSD.ORG Thu May 15 13:15:48 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE3F37B401; Thu, 15 May 2003 13:15:48 -0700 (PDT) Received: from harik.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19EE943F3F; Thu, 15 May 2003 13:15:47 -0700 (PDT) (envelope-from Anthony.SCHNEIDER@murex.com) Received: from interscan.murex.fr (interscan.murex.fr [172.21.17.206]) by harik.murex.com with ESMTP id h4FJv6om024509; Thu, 15 May 2003 21:57:06 +0200 (CEST) Received: from bilbo.murex.com (localhost.murex.com [127.0.0.1] (may be forged)) by interscan.murex.fr (8.11.6/8.11.6) with ESMTP id h4FJKIc09283; Thu, 15 May 2003 21:20:18 +0200 Received: from mercury.us.murex.com ([172.21.128.11]) by bilbo.murex.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 15 May 2003 22:14:55 +0200 Date: Thu, 15 May 2003 16:14:52 -0400 MIME-Version: 1.0 Message-ID: <7691488D1955AC4AB0667FCFEED4499154C84E@mercury.us.murex.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: troubles with an Exhabyte tape drive Thread-Index: AcMbHZp4snydfR8oRFmOVBAlSmELuQAAMsOg From: "SCHNEIDER Anthony" To: "Mikhail Teterin" , X-OriginalArrivalTime: 15 May 2003 20:14:55.0372 (UTC) FILETIME=[A68CCCC0:01C31B1E] cc: gibbs@FreeBSD.org cc: ken@FreeBSD.org Subject: RE: troubles with an Exhabyte tape drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 20:15:48 -0000 Also of use might be: 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Tue Sep 3 11:56:05 GMT 2002 GENERIC i386 Thanks! -Anthony. > -----Original Message----- > From: Mikhail Teterin [mailto:mi+mx@aldan.algebra.com] > Sent: Thursday, May 15, 2003 4:07 PM > To: scsi@FreeBSD.org > Cc: ken@FreeBSD.org; gibbs@FreeBSD.org; SCHNEIDER Anthony > Subject: troubles with an Exhabyte tape drive >=20 > Hello! >=20 > We can read the tapes using this drive: >=20 > sym0: <875> port 0x2400-0x24ff mem 0x42000000-0x42000fff,0x42100000- > 0x421000ff > irq 11 at device 16.0 on pci0 > sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking > sym0: open drain IRQ line driver, using on-chip SRAM > sym0: using LOAD/STORE-based firmware. > sa0 at sym0 bus 0 target 0 lun 0 > sa0: Removable Sequential Access SCSI-2 > device > sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) >=20 >=20 > but we can not write anything :-( The kernel's messages logged are: >=20 > (sa0:sym0:0:0:0): WRITE(06). CDB: a 0 0 28 0 0 > (sa0:sym0:0:0:0): ILLEGAL REQUEST asc:30,5 > (sa0:sym0:0:0:0): Cannot write medium - incompatible format >=20 > Is it our clumsiness, or the tapes (we tried about a dozen), or the > drive? Thanks a lot! >=20 > -mi >=20 From owner-freebsd-scsi@FreeBSD.ORG Thu May 15 14:06:53 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E185A37B401; Thu, 15 May 2003 14:06:52 -0700 (PDT) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22A1A43F3F; Thu, 15 May 2003 14:06:52 -0700 (PDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (250-217.customer.cloud9.net [168.100.250.217])h4FL6c75069291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 15 May 2003 17:06:39 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "Kenneth D. Merry" Date: Thu, 15 May 2003 17:06:39 -0400 User-Agent: KMail/1.5.1 References: <200305151607.02102.mi+mx@aldan.algebra.com> <20030515141332.A668@panzer.kdm.org> In-Reply-To: <20030515141332.A668@panzer.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305151706.39871.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) cc: gibbs@FreeBSD.org cc: aschneider@murex.com cc: scsi@FreeBSD.org Subject: Re: troubles with an Exhabyte tape drive X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 21:06:53 -0000 Thanks for a prompt response! On Thursday 15 May 2003 04:13 pm, Kenneth D. Merry wrote: = On Thu, May 15, 2003 at 16:07:02 -0400, Mikhail Teterin wrote: = > We can read the tapes using this drive: = > = > sa0 at sym0 bus 0 target 0 lun 0 = > sa0: Removable Sequential Access SCSI-2 device = > sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) = > but we can not write anything :-( The kernel's messages logged are: = > = > (sa0:sym0:0:0:0): WRITE(06). CDB: a 0 0 28 0 0 = > (sa0:sym0:0:0:0): ILLEGAL REQUEST asc:30,5 = > (sa0:sym0:0:0:0): Cannot write medium - incompatible format = I'm guessing it's the tapes. That's what the message seems to say. = = Are you *sure* your tapes are write compatible with the drive? I know = there are various Exabyte drives that can read, but not write, old = format tapes. Could be. I just found the following table: http://www.8mm.com/support/online/kb/display.cfm?id=152 it can only write in its own format, but can read 8500c, 8500, 8200. I guess, we need to find a EXB-8500c to be able to exchange data with various clients... -mi From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 00:48:08 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F23537B401 for ; Fri, 16 May 2003 00:48:08 -0700 (PDT) Received: from scanmail.mediatraffic.fi (scanmail.mediatraffic.fi [212.83.107.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1142F43FF9 for ; Fri, 16 May 2003 00:48:06 -0700 (PDT) (envelope-from toni@extra.mediatraffic.fi) Received: from localhost (localhost [127.0.0.1]) by scanmail.mediatraffic.fi (Postfix) with ESMTP id A96BE1FDC8; Fri, 16 May 2003 10:48:03 +0300 (EEST) Received: from extra.mediatraffic.fi (extra.mediatraffic.fi [212.83.107.136]) by scanmail.mediatraffic.fi (Postfix) with ESMTP id 25CBE1FD24; Fri, 16 May 2003 10:48:03 +0300 (EEST) Received: by extra.mediatraffic.fi (Postfix, from userid 1000) id 036EDC39E6; Fri, 16 May 2003 10:48:04 +0300 (EEST) Date: Fri, 16 May 2003 10:48:04 +0300 From: Toni Viemero To: Scott Long Message-ID: <20030516074804.GA24769@extra.mediatraffic.fi> Mail-Followup-To: Scott Long , freebsd-scsi@freebsd.org References: <20030511065545.GC1832@hollin.btc.adaptec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030511065545.GC1832@hollin.btc.adaptec.com> User-Agent: Mutt/1.5.4i cc: freebsd-scsi@freebsd.org Subject: Re: ServeRAID driver now in the tree X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 07:48:08 -0000 Scott Long wrote: > At long last, there is support for the IBM ServeRAID line of SCSI RAID > controllers. The 'ips' driver can be loaded as a module or compiled > into the kernel as noted in /sys/i386/conf/NOTES. I've only tested > this driver with a 4L model and only on ia32 (SMP), so more testing is > welcomed and encouraged. Does the current.freebsd.org iso images/kernel provide this driver? All our machines have only ServeRAID disks, so installing into another disk and compiling custom kernel is not an option. I'm eager to test this baby out. -- Toni Viemerö | http://selfdestruct.net "When life hands you a lemon, say, 'Oh yeah, I like lemons. What else ya got?'" From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 00:50:35 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8E4E37B401 for ; Fri, 16 May 2003 00:50:35 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44FB343F3F for ; Fri, 16 May 2003 00:50:35 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4G7kcZ13893; Fri, 16 May 2003 00:46:38 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id AAA13587; Fri, 16 May 2003 00:50:28 -0700 (PDT) Message-ID: <3EC4982C.4040906@btc.adaptec.com> Date: Fri, 16 May 2003 01:50:04 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toni Viemero References: <20030511065545.GC1832@hollin.btc.adaptec.com> <20030516074804.GA24769@extra.mediatraffic.fi> In-Reply-To: <20030516074804.GA24769@extra.mediatraffic.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-scsi@freebsd.org Subject: Re: ServeRAID driver now in the tree X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 07:50:36 -0000 Toni Viemero wrote: > Scott Long wrote: > > >>At long last, there is support for the IBM ServeRAID line of SCSI RAID >>controllers. The 'ips' driver can be loaded as a module or compiled >>into the kernel as noted in /sys/i386/conf/NOTES. I've only tested >>this driver with a 4L model and only on ia32 (SMP), so more testing is >>welcomed and encouraged. > > > Does the current.freebsd.org iso images/kernel provide this driver? > All our machines have only ServeRAID disks, so installing into another > disk and compiling custom kernel is not an option. > I'm eager to test this baby out. > Yeah, it should be on any of the builds after the check-in date. It'll of course also be on 5.1. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 05:23:20 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69DD037B401 for ; Fri, 16 May 2003 05:23:20 -0700 (PDT) Received: from chuggalug.clues.com (chuggalug.clues.com [194.159.1.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 690B743FBD for ; Fri, 16 May 2003 05:23:19 -0700 (PDT) (envelope-from geoffb@chuggalug.clues.com) Received: from chuggalug.clues.com (localhost [127.0.0.1]) by chuggalug.clues.com (8.12.8p1/8.12.8) with ESMTP id h4GD5XRO046247; Fri, 16 May 2003 14:05:33 +0100 (BST) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.12.8p1/8.12.8/Submit) id h4GD5WUk046246; Fri, 16 May 2003 14:05:32 +0100 (BST) Date: Fri, 16 May 2003 14:05:32 +0100 From: Geoff Buckingham To: Nate Lawson Message-ID: <20030516130532.GA29627@chuggalug.clues.com> References: <20030514151752.B79363@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030514151752.B79363@root.org> User-Agent: Mutt/1.4i cc: scsi@freebsd.org Subject: Re: SCSI geometry calculation? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 12:23:20 -0000 On Wed, May 14, 2003 at 03:44:41PM -0700, Nate Lawson wrote: Can I add that these Geometries are also reported inconsistently at boot time. This is unimportent to anyone who isn't trying to parse dmesg output to layout dos/W2K partitions, but I am :-( Would I be wating my time putting togethter a PR with consistently formatted printf's? From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 07:05:17 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DE0B37B401 for ; Fri, 16 May 2003 07:05:17 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA5D143F85 for ; Fri, 16 May 2003 07:05:16 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4GE1JZ03685; Fri, 16 May 2003 07:01:19 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id HAA02789; Fri, 16 May 2003 07:05:05 -0700 (PDT) Message-ID: <3EC4EFFD.4010102@btc.adaptec.com> Date: Fri, 16 May 2003 08:04:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Buckingham References: <20030514151752.B79363@root.org> <20030516130532.GA29627@chuggalug.clues.com> In-Reply-To: <20030516130532.GA29627@chuggalug.clues.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: scsi@freebsd.org Subject: Re: SCSI geometry calculation? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 14:05:17 -0000 Geoff Buckingham wrote: > On Wed, May 14, 2003 at 03:44:41PM -0700, Nate Lawson wrote: > Can I add that these Geometries are also reported inconsistently at boot > time. This is unimportent to anyone who isn't trying to parse dmesg output > to layout dos/W2K partitions, but I am :-( > > Would I be wating my time putting togethter a PR with consistently formatted > printf's? > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" A patch to fix this would certainly be worth consideration. From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 10:57:08 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2791237B404 for ; Fri, 16 May 2003 10:57:08 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0821243F3F for ; Fri, 16 May 2003 10:57:07 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 82964 invoked by uid 1000); 16 May 2003 17:57:07 -0000 Date: Fri, 16 May 2003 10:57:07 -0700 (PDT) From: Nate Lawson To: scsi@freebsd.org Message-ID: <20030516105356.E82960@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: PATCH: merge calc geometry calls into convenience function X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 17:57:08 -0000 Left out of this are aha(4) and bt(4) although they probably should be added. They use a 2G/1G/<1G scheme. --- Merge common XPT_CALC_GEOMETRY functions into a single convenience function. Devices below may experience a change in geometry. * Due to a bug, aic(4) never used extended geometry. Changes all drives >1G to now use extended translation. * sbp(4) drives exactly 1 GB in size now no longer use extended geometry. * umass(4) drives exactly 1 GB in size now no longer use extended geometry. For all other controllers in this commit, this should be a no-op. --- Index: sys/cam/cam.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam.c,v retrieving revision 1.5 diff -u -r1.5 cam.c --- sys/cam/cam.c 9 Jan 2002 03:38:58 -0000 1.5 +++ sys/cam/cam.c 14 May 2003 22:16:17 -0000 @@ -358,3 +358,28 @@ } #endif /* _KERNEL/!_KERNEL */ + +/* + * Common calculate geometry fuction + * + * Caller should set ccg->volume_size and block_size. + * The extended parameter should be zero if extended translation + * should not be used. + */ +void +cam_calc_geometry(struct ccb_calc_geometry *ccg, int extended) +{ + uint32_t size_mb, secs_per_cylinder; + + size_mb = ccg->volume_size / ((1024L * 1024L) / ccg->block_size); + if (size_mb > 1024 && extended) { + ccg->heads = 255; + ccg->secs_per_track = 63; + } else { + ccg->heads = 64; + ccg->secs_per_track = 32; + } + secs_per_cylinder = ccg->heads * ccg->secs_per_track; + ccg->cylinders = ccg->volume_size / secs_per_cylinder; + ccg->ccb_h.status = CAM_REQ_CMP; +} Index: sys/cam/cam_ccb.h =================================================================== RCS file: /home/ncvs/src/sys/cam/cam_ccb.h,v retrieving revision 1.23 diff -u -r1.23 cam_ccb.h --- sys/cam/cam_ccb.h 29 Apr 2003 13:35:58 -0000 1.23 +++ sys/cam/cam_ccb.h 14 May 2003 22:46:49 -0000 @@ -794,6 +794,7 @@ u_int8_t heads; u_int8_t secs_per_track; }; +void cam_calc_geometry(struct ccb_calc_geometry *ccg, int extended); /* * Rescan the given bus, or bus/target/lun Index: sys/cam/scsi/scsi_low.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_low.c,v retrieving revision 1.19 diff -u -r1.19 scsi_low.c --- sys/cam/scsi/scsi_low.c 8 Mar 2003 08:01:26 -0000 1.19 +++ sys/cam/scsi/scsi_low.c 16 May 2003 01:45:45 -0000 @@ -1282,26 +1282,7 @@ } case XPT_CALC_GEOMETRY: { /* not yet HN2 */ - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended; - - extended = 1; - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/advansys/advansys.c =================================================================== RCS file: /home/ncvs/src/sys/dev/advansys/advansys.c,v retrieving revision 1.23 diff -u -r1.23 advansys.c --- sys/dev/advansys/advansys.c 10 Apr 2003 23:50:05 -0000 1.23 +++ sys/dev/advansys/advansys.c 16 May 2003 01:46:37 -0000 @@ -431,26 +431,10 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; int extended; - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); extended = (adv->control & ADV_CNTL_BIOS_GT_1GB) != 0; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, extended); xpt_done(ccb); break; } Index: sys/dev/advansys/adwcam.c =================================================================== RCS file: /home/ncvs/src/sys/dev/advansys/adwcam.c,v retrieving revision 1.14 diff -u -r1.14 adwcam.c --- sys/dev/advansys/adwcam.c 10 Apr 2003 23:50:05 -0000 1.14 +++ sys/dev/advansys/adwcam.c 16 May 2003 01:47:03 -0000 @@ -724,30 +724,11 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended; - /* * XXX Use Adaptec translation until I find out how to * get this information from the card. */ - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - extended = 1; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/ahb/ahb.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ahb/ahb.c,v retrieving revision 1.27 diff -u -r1.27 ahb.c --- sys/dev/ahb/ahb.c 10 Apr 2003 23:50:05 -0000 1.27 +++ sys/dev/ahb/ahb.c 16 May 2003 07:36:31 -0000 @@ -1171,24 +1171,7 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - - if (size_mb > 1024 && (ahb->extended_trans != 0)) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, ahb->extended_trans); xpt_done(ccb); break; } Index: sys/dev/aic/aic.c =================================================================== RCS file: /home/ncvs/src/sys/dev/aic/aic.c,v retrieving revision 1.18 diff -u -r1.18 aic.c --- sys/dev/aic/aic.c 28 Sep 2002 17:14:21 -0000 1.18 +++ sys/dev/aic/aic.c 16 May 2003 07:53:15 -0000 @@ -254,25 +254,7 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended = 0; - - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - - if (size_mb >= 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/aic7xxx/aic79xx_osm.c =================================================================== RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_osm.c,v retrieving revision 1.10 diff -u -r1.10 aic79xx_osm.c --- sys/dev/aic7xxx/aic79xx_osm.c 10 Apr 2003 23:50:05 -0000 1.10 +++ sys/dev/aic7xxx/aic79xx_osm.c 16 May 2003 01:49:46 -0000 @@ -550,26 +550,10 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - uint32_t size_mb; - uint32_t secs_per_cylinder; int extended; - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); extended = ahd->flags & AHD_EXTENDED_TRANS_A; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, extended); xpt_done(ccb); break; } Index: sys/dev/aic7xxx/aic7xxx_osm.c =================================================================== RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic7xxx_osm.c,v retrieving revision 1.33 diff -u -r1.33 aic7xxx_osm.c --- sys/dev/aic7xxx/aic7xxx_osm.c 10 Apr 2003 23:50:05 -0000 1.33 +++ sys/dev/aic7xxx/aic7xxx_osm.c 14 May 2003 22:16:43 -0000 @@ -819,28 +819,12 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - uint32_t size_mb; - uint32_t secs_per_cylinder; int extended; - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); extended = SIM_IS_SCSIBUS_B(ahc, sim) ? ahc->flags & AHC_EXTENDED_TRANS_B : ahc->flags & AHC_EXTENDED_TRANS_A; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, extended); xpt_done(ccb); break; } Index: sys/dev/amr/amr_cam.c =================================================================== RCS file: /home/ncvs/src/sys/dev/amr/amr_cam.c,v retrieving revision 1.7 diff -u -r1.7 amr_cam.c --- sys/dev/amr/amr_cam.c 1 Apr 2003 15:06:22 -0000 1.7 +++ sys/dev/amr/amr_cam.c 16 May 2003 01:51:17 -0000 @@ -265,22 +265,7 @@ case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg = &ccb->ccg; - u_int32_t size_in_mb; - u_int32_t secs_per_cylinder; - - size_in_mb = ccg->volume_size / ((1024L * 1024L) / ccg->block_size); - - if (size_in_mb > 1024) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, /*extended*/1); break; } Index: sys/dev/ata/atapi-cam.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.15 diff -u -r1.15 atapi-cam.c --- sys/dev/ata/atapi-cam.c 8 Mar 2003 08:01:28 -0000 1.15 +++ sys/dev/ata/atapi-cam.c 16 May 2003 01:52:04 -0000 @@ -323,26 +323,8 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - unsigned int size_mb; - unsigned int secs_per_cylinder; - int extended; - CAM_DEBUG(ccb->ccb_h.path, CAM_DEBUG_SUBTRACE, ("CALC_GEOMETRY\n")); - ccg = &ccb->ccg; - size_mb = ccg->volume_size / ((1024L * 1024L) / ccg->block_size); - extended = 1; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, /*extended*/1); xpt_done(ccb); return; } Index: sys/dev/dpt/dpt_scsi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/dpt/dpt_scsi.c,v retrieving revision 1.41 diff -u -r1.41 dpt_scsi.c --- sys/dev/dpt/dpt_scsi.c 10 Apr 2003 23:50:05 -0000 1.41 +++ sys/dev/dpt/dpt_scsi.c 16 May 2003 01:53:27 -0000 @@ -1034,30 +1034,11 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended; - /* * XXX Use Adaptec translation until I find out how to * get this information from the card. */ - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - extended = 1; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&ccb->ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/firewire/sbp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/firewire/sbp.c,v retrieving revision 1.43 diff -u -r1.43 sbp.c --- sys/dev/firewire/sbp.c 24 Apr 2003 15:27:06 -0000 1.43 +++ sys/dev/firewire/sbp.c 16 May 2003 01:54:46 -0000 @@ -2222,11 +2222,8 @@ case XPT_CALC_GEOMETRY: { struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended = 1; - ccg = &ccb->ccg; + ccg = &ccb->ccg; if (ccg->block_size == 0) { printf("sbp_action1: block_size is 0.\n"); ccb->ccb_h.status = CAM_REQ_INVALID; @@ -2241,19 +2238,7 @@ ccg->volume_size); END_DEBUG - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - - if (size_mb >= 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/isp/isp_freebsd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/isp/isp_freebsd.c,v retrieving revision 1.89 diff -u -r1.89 isp_freebsd.c --- sys/dev/isp/isp_freebsd.c 3 Mar 2003 12:15:42 -0000 1.89 +++ sys/dev/isp/isp_freebsd.c 16 May 2003 07:48:13 -0000 @@ -2532,8 +2532,6 @@ case XPT_CALC_GEOMETRY: { struct ccb_calc_geometry *ccg; - u_int32_t secs_per_cylinder; - u_int32_t size_mb; ccg = &ccb->ccg; if (ccg->block_size == 0) { @@ -2544,17 +2542,7 @@ xpt_done(ccb); break; } - size_mb = ccg->volume_size /((1024L * 1024L) / ccg->block_size); - if (size_mb > 1024) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/mpt/mpt_freebsd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mpt/mpt_freebsd.c,v retrieving revision 1.9 diff -u -r1.9 mpt_freebsd.c --- sys/dev/mpt/mpt_freebsd.c 10 Apr 2003 23:50:06 -0000 1.9 +++ sys/dev/mpt/mpt_freebsd.c 16 May 2003 01:55:52 -0000 @@ -1399,8 +1399,6 @@ case XPT_CALC_GEOMETRY: { struct ccb_calc_geometry *ccg; - u_int32_t secs_per_cylinder; - u_int32_t size_mb; ccg = &ccb->ccg; if (ccg->block_size == 0) { @@ -1409,17 +1407,7 @@ break; } - size_mb = ccg->volume_size /((1024L * 1024L) / ccg->block_size); - if (size_mb > 1024) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(ccg, /*extended*/1); xpt_done(ccb); break; } Index: sys/dev/trm/trm.c =================================================================== RCS file: /home/ncvs/src/sys/dev/trm/trm.c,v retrieving revision 1.7 diff -u -r1.7 trm.c --- sys/dev/trm/trm.c 10 Apr 2003 23:50:06 -0000 1.7 +++ sys/dev/trm/trm.c 16 May 2003 01:57:06 -0000 @@ -984,29 +984,10 @@ * Calculate the geometry parameters for a device give * the sector size and volume size. */ - case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended; - + case XPT_CALC_GEOMETRY: TRM_DPRINTF(" XPT_CALC_GEOMETRY \n"); - ccg = &pccb->ccg; - size_mb = ccg->volume_size / - ((1024L * 1024L) / ccg->block_size); - extended = 1; - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - pccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&pccb->ccg, /*extended*/1); xpt_done(pccb); - } break; case XPT_ENG_INQ: TRM_DPRINTF(" XPT_ENG_INQ \n"); Index: sys/dev/amd/amd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/amd/amd.c,v retrieving revision 1.17 diff -u -r1.17 amd.c --- sys/dev/amd/amd.c 10 Apr 2003 23:50:05 -0000 1.17 +++ sys/dev/amd/amd.c 16 May 2003 07:39:05 -0000 @@ -680,25 +680,10 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; int extended; - ccg = &pccb->ccg; - size_mb = ccg->volume_size/((1024L * 1024L)/ccg->block_size); extended = (amd->eepromBuf[EE_MODE2] & GREATER_1G) != 0; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - pccb->ccb_h.status = CAM_REQ_CMP; + cam_calc_geometry(&pccb->ccg, extended); xpt_done(pccb); break; } Index: sys/dev/sym/sym_hipd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v retrieving revision 1.40 diff -u -r1.40 sym_hipd.c --- sys/dev/sym/sym_hipd.c 10 Apr 2003 23:50:06 -0000 1.40 +++ sys/dev/sym/sym_hipd.c 16 May 2003 01:59:46 -0000 @@ -8554,28 +8554,7 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg; - u32 size_mb; - u32 secs_per_cylinder; - int extended; - - /* - * Silly DOS geometry. - */ - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - extended = 1; - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; + cam_calc_geometry(&ccb->ccg, /*extended*/1); sym_xpt_done2(np, ccb, CAM_REQ_CMP); break; } Index: sys/dev/usb/umass.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v retrieving revision 1.81 diff -u -r1.81 umass.c --- sys/dev/usb/umass.c 11 May 2003 23:55:27 -0000 1.81 +++ sys/dev/usb/umass.c 16 May 2003 01:59:09 -0000 @@ -2458,25 +2457,7 @@ } case XPT_CALC_GEOMETRY: { - struct ccb_calc_geometry *ccg = &ccb->ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended = 1; - - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - - if (size_mb >= 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; - + cam_calc_geometry(&ccb->ccg, /*extended*/1); xpt_done(ccb); break; } From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 11:59:31 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7157637B401 for ; Fri, 16 May 2003 11:59:31 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A0A43F3F for ; Fri, 16 May 2003 11:59:30 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4GItWZ22223; Fri, 16 May 2003 11:55:32 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id LAA13558; Fri, 16 May 2003 11:59:24 -0700 (PDT) Message-ID: <3EC53467.9080101@btc.adaptec.com> Date: Fri, 16 May 2003 12:56:39 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20030516105356.E82960@root.org> In-Reply-To: <20030516105356.E82960@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: scsi@freebsd.org Subject: Re: PATCH: merge calc geometry calls into convenience function X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 18:59:31 -0000 cam_calc_std_geometry() might be a better name. I like the idea in any case. However, could you hold off until after the 5.1 branch? Scott Nate Lawson wrote: > Left out of this are aha(4) and bt(4) although they probably should be > added. They use a 2G/1G/<1G scheme. > > --- > Merge common XPT_CALC_GEOMETRY functions into a single convenience > function. > Devices below may experience a change in geometry. > > * Due to a bug, aic(4) never used extended geometry. Changes all drives > >1G to now use extended translation. > * sbp(4) drives exactly 1 GB in size now no longer use extended > geometry. > * umass(4) drives exactly 1 GB in size now no longer use extended > geometry. > > For all other controllers in this commit, this should be a no-op. > --- > > Index: sys/cam/cam.c > =================================================================== > RCS file: /home/ncvs/src/sys/cam/cam.c,v > retrieving revision 1.5 > diff -u -r1.5 cam.c > --- sys/cam/cam.c 9 Jan 2002 03:38:58 -0000 1.5 > +++ sys/cam/cam.c 14 May 2003 22:16:17 -0000 > @@ -358,3 +358,28 @@ > } > > #endif /* _KERNEL/!_KERNEL */ > + > +/* > + * Common calculate geometry fuction > + * > + * Caller should set ccg->volume_size and block_size. > + * The extended parameter should be zero if extended translation > + * should not be used. > + */ > +void > +cam_calc_geometry(struct ccb_calc_geometry *ccg, int extended) > +{ > + uint32_t size_mb, secs_per_cylinder; > + > + size_mb = ccg->volume_size / ((1024L * 1024L) / > ccg->block_size); > + if (size_mb > 1024 && extended) { > + ccg->heads = 255; > + ccg->secs_per_track = 63; > + } else { > + ccg->heads = 64; > + ccg->secs_per_track = 32; > + } > + secs_per_cylinder = ccg->heads * ccg->secs_per_track; > + ccg->cylinders = ccg->volume_size / secs_per_cylinder; > + ccg->ccb_h.status = CAM_REQ_CMP; > +} > Index: sys/cam/cam_ccb.h > =================================================================== > RCS file: /home/ncvs/src/sys/cam/cam_ccb.h,v > retrieving revision 1.23 > diff -u -r1.23 cam_ccb.h > --- sys/cam/cam_ccb.h 29 Apr 2003 13:35:58 -0000 1.23 > +++ sys/cam/cam_ccb.h 14 May 2003 22:46:49 -0000 > @@ -794,6 +794,7 @@ > u_int8_t heads; > u_int8_t secs_per_track; > }; > +void cam_calc_geometry(struct ccb_calc_geometry *ccg, int extended); > > /* > * Rescan the given bus, or bus/target/lun > Index: sys/cam/scsi/scsi_low.c > =================================================================== > RCS file: /home/ncvs/src/sys/cam/scsi/scsi_low.c,v > retrieving revision 1.19 > diff -u -r1.19 scsi_low.c > --- sys/cam/scsi/scsi_low.c 8 Mar 2003 08:01:26 -0000 1.19 > +++ sys/cam/scsi/scsi_low.c 16 May 2003 01:45:45 -0000 > @@ -1282,26 +1282,7 @@ > } > > case XPT_CALC_GEOMETRY: { /* not yet HN2 */ > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended; > - > - extended = 1; > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/advansys/advansys.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/advansys/advansys.c,v > retrieving revision 1.23 > diff -u -r1.23 advansys.c > --- sys/dev/advansys/advansys.c 10 Apr 2003 23:50:05 -0000 1.23 > +++ sys/dev/advansys/advansys.c 16 May 2003 01:46:37 -0000 > @@ -431,26 +431,10 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > int extended; > > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > extended = (adv->control & ADV_CNTL_BIOS_GT_1GB) != 0; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, extended); > xpt_done(ccb); > break; > } > Index: sys/dev/advansys/adwcam.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/advansys/adwcam.c,v > retrieving revision 1.14 > diff -u -r1.14 adwcam.c > --- sys/dev/advansys/adwcam.c 10 Apr 2003 23:50:05 -0000 1.14 > +++ sys/dev/advansys/adwcam.c 16 May 2003 01:47:03 -0000 > @@ -724,30 +724,11 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended; > - > /* > * XXX Use Adaptec translation until I find out how to > * get this information from the card. > */ > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - extended = 1; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/ahb/ahb.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ahb/ahb.c,v > retrieving revision 1.27 > diff -u -r1.27 ahb.c > --- sys/dev/ahb/ahb.c 10 Apr 2003 23:50:05 -0000 1.27 > +++ sys/dev/ahb/ahb.c 16 May 2003 07:36:31 -0000 > @@ -1171,24 +1171,7 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - > - if (size_mb > 1024 && (ahb->extended_trans != 0)) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, ahb->extended_trans); > xpt_done(ccb); > break; > } > Index: sys/dev/aic/aic.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/aic/aic.c,v > retrieving revision 1.18 > diff -u -r1.18 aic.c > --- sys/dev/aic/aic.c 28 Sep 2002 17:14:21 -0000 1.18 > +++ sys/dev/aic/aic.c 16 May 2003 07:53:15 -0000 > @@ -254,25 +254,7 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended = 0; > - > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - > - if (size_mb >= 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/aic7xxx/aic79xx_osm.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_osm.c,v > retrieving revision 1.10 > diff -u -r1.10 aic79xx_osm.c > --- sys/dev/aic7xxx/aic79xx_osm.c 10 Apr 2003 23:50:05 -0000 > 1.10 > +++ sys/dev/aic7xxx/aic79xx_osm.c 16 May 2003 01:49:46 -0000 > @@ -550,26 +550,10 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - uint32_t size_mb; > - uint32_t secs_per_cylinder; > int extended; > > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > extended = ahd->flags & AHD_EXTENDED_TRANS_A; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, extended); > xpt_done(ccb); > break; > } > Index: sys/dev/aic7xxx/aic7xxx_osm.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic7xxx_osm.c,v > retrieving revision 1.33 > diff -u -r1.33 aic7xxx_osm.c > --- sys/dev/aic7xxx/aic7xxx_osm.c 10 Apr 2003 23:50:05 -0000 > 1.33 > +++ sys/dev/aic7xxx/aic7xxx_osm.c 14 May 2003 22:16:43 -0000 > @@ -819,28 +819,12 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - uint32_t size_mb; > - uint32_t secs_per_cylinder; > int extended; > > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > extended = SIM_IS_SCSIBUS_B(ahc, sim) > ? ahc->flags & AHC_EXTENDED_TRANS_B > : ahc->flags & AHC_EXTENDED_TRANS_A; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, extended); > xpt_done(ccb); > break; > } > Index: sys/dev/amr/amr_cam.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/amr/amr_cam.c,v > retrieving revision 1.7 > diff -u -r1.7 amr_cam.c > --- sys/dev/amr/amr_cam.c 1 Apr 2003 15:06:22 -0000 1.7 > +++ sys/dev/amr/amr_cam.c 16 May 2003 01:51:17 -0000 > @@ -265,22 +265,7 @@ > > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg = &ccb->ccg; > - u_int32_t size_in_mb; > - u_int32_t secs_per_cylinder; > - > - size_in_mb = ccg->volume_size / ((1024L * 1024L) / > ccg->block_size); > - > - if (size_in_mb > 1024) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > break; > } > > Index: sys/dev/ata/atapi-cam.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v > retrieving revision 1.15 > diff -u -r1.15 atapi-cam.c > --- sys/dev/ata/atapi-cam.c 8 Mar 2003 08:01:28 -0000 1.15 > +++ sys/dev/ata/atapi-cam.c 16 May 2003 01:52:04 -0000 > @@ -323,26 +323,8 @@ > } > > case XPT_CALC_GEOMETRY: { > - struct ccb_calc_geometry *ccg; > - unsigned int size_mb; > - unsigned int secs_per_cylinder; > - int extended; > - > CAM_DEBUG(ccb->ccb_h.path, CAM_DEBUG_SUBTRACE, > ("CALC_GEOMETRY\n")); > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size / ((1024L * 1024L) / > ccg->block_size); > - extended = 1; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > xpt_done(ccb); > return; > } > Index: sys/dev/dpt/dpt_scsi.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/dpt/dpt_scsi.c,v > retrieving revision 1.41 > diff -u -r1.41 dpt_scsi.c > --- sys/dev/dpt/dpt_scsi.c 10 Apr 2003 23:50:05 -0000 1.41 > +++ sys/dev/dpt/dpt_scsi.c 16 May 2003 01:53:27 -0000 > @@ -1034,30 +1034,11 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended; > - > /* > * XXX Use Adaptec translation until I find out how to > * get this information from the card. > */ > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - extended = 1; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/firewire/sbp.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/firewire/sbp.c,v > retrieving revision 1.43 > diff -u -r1.43 sbp.c > --- sys/dev/firewire/sbp.c 24 Apr 2003 15:27:06 -0000 1.43 > +++ sys/dev/firewire/sbp.c 16 May 2003 01:54:46 -0000 > @@ -2222,11 +2222,8 @@ > case XPT_CALC_GEOMETRY: > { > struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended = 1; > - ccg = &ccb->ccg; > > + ccg = &ccb->ccg; > if (ccg->block_size == 0) { > printf("sbp_action1: block_size is 0.\n"); > ccb->ccb_h.status = CAM_REQ_INVALID; > @@ -2241,19 +2238,7 @@ > ccg->volume_size); > END_DEBUG > > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - > - if (size_mb >= 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/isp/isp_freebsd.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/isp/isp_freebsd.c,v > retrieving revision 1.89 > diff -u -r1.89 isp_freebsd.c > --- sys/dev/isp/isp_freebsd.c 3 Mar 2003 12:15:42 -0000 1.89 > +++ sys/dev/isp/isp_freebsd.c 16 May 2003 07:48:13 -0000 > @@ -2532,8 +2532,6 @@ > case XPT_CALC_GEOMETRY: > { > struct ccb_calc_geometry *ccg; > - u_int32_t secs_per_cylinder; > - u_int32_t size_mb; > > ccg = &ccb->ccg; > if (ccg->block_size == 0) { > @@ -2544,17 +2542,7 @@ > xpt_done(ccb); > break; > } > - size_mb = ccg->volume_size /((1024L * 1024L) / > ccg->block_size); > - if (size_mb > 1024) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/mpt/mpt_freebsd.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/mpt/mpt_freebsd.c,v > retrieving revision 1.9 > diff -u -r1.9 mpt_freebsd.c > --- sys/dev/mpt/mpt_freebsd.c 10 Apr 2003 23:50:06 -0000 1.9 > +++ sys/dev/mpt/mpt_freebsd.c 16 May 2003 01:55:52 -0000 > @@ -1399,8 +1399,6 @@ > case XPT_CALC_GEOMETRY: > { > struct ccb_calc_geometry *ccg; > - u_int32_t secs_per_cylinder; > - u_int32_t size_mb; > > ccg = &ccb->ccg; > if (ccg->block_size == 0) { > @@ -1409,17 +1407,7 @@ > break; > } > > - size_mb = ccg->volume_size /((1024L * 1024L) / > ccg->block_size); > - if (size_mb > 1024) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(ccg, /*extended*/1); > xpt_done(ccb); > break; > } > Index: sys/dev/trm/trm.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/trm/trm.c,v > retrieving revision 1.7 > diff -u -r1.7 trm.c > --- sys/dev/trm/trm.c 10 Apr 2003 23:50:06 -0000 1.7 > +++ sys/dev/trm/trm.c 16 May 2003 01:57:06 -0000 > @@ -984,29 +984,10 @@ > * Calculate the geometry parameters for a device give > * the sector size and volume size. > */ > - case XPT_CALC_GEOMETRY: { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended; > - > + case XPT_CALC_GEOMETRY: > TRM_DPRINTF(" XPT_CALC_GEOMETRY \n"); > - ccg = &pccb->ccg; > - size_mb = ccg->volume_size / > - ((1024L * 1024L) / ccg->block_size); > - extended = 1; > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * > ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / > secs_per_cylinder; > - pccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&pccb->ccg, /*extended*/1); > xpt_done(pccb); > - } > break; > case XPT_ENG_INQ: > TRM_DPRINTF(" XPT_ENG_INQ \n"); > Index: sys/dev/amd/amd.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/amd/amd.c,v > retrieving revision 1.17 > diff -u -r1.17 amd.c > --- sys/dev/amd/amd.c 10 Apr 2003 23:50:05 -0000 1.17 > +++ sys/dev/amd/amd.c 16 May 2003 07:39:05 -0000 > @@ -680,25 +680,10 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > int extended; > > - ccg = &pccb->ccg; > - size_mb = ccg->volume_size/((1024L * > 1024L)/ccg->block_size); > extended = (amd->eepromBuf[EE_MODE2] & GREATER_1G) != 0; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - pccb->ccb_h.status = CAM_REQ_CMP; > + cam_calc_geometry(&pccb->ccg, extended); > xpt_done(pccb); > break; > } > Index: sys/dev/sym/sym_hipd.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v > retrieving revision 1.40 > diff -u -r1.40 sym_hipd.c > --- sys/dev/sym/sym_hipd.c 10 Apr 2003 23:50:06 -0000 1.40 > +++ sys/dev/sym/sym_hipd.c 16 May 2003 01:59:46 -0000 > @@ -8554,28 +8554,7 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg; > - u32 size_mb; > - u32 secs_per_cylinder; > - int extended; > - > - /* > - * Silly DOS geometry. > - */ > - ccg = &ccb->ccg; > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - extended = 1; > - > - if (size_mb > 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > sym_xpt_done2(np, ccb, CAM_REQ_CMP); > break; > } > Index: sys/dev/usb/umass.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v > retrieving revision 1.81 > diff -u -r1.81 umass.c > --- sys/dev/usb/umass.c 11 May 2003 23:55:27 -0000 1.81 > +++ sys/dev/usb/umass.c 16 May 2003 01:59:09 -0000 > @@ -2458,25 +2457,7 @@ > } > case XPT_CALC_GEOMETRY: > { > - struct ccb_calc_geometry *ccg = &ccb->ccg; > - u_int32_t size_mb; > - u_int32_t secs_per_cylinder; > - int extended = 1; > - > - size_mb = ccg->volume_size > - / ((1024L * 1024L) / ccg->block_size); > - > - if (size_mb >= 1024 && extended) { > - ccg->heads = 255; > - ccg->secs_per_track = 63; > - } else { > - ccg->heads = 64; > - ccg->secs_per_track = 32; > - } > - secs_per_cylinder = ccg->heads * ccg->secs_per_track; > - ccg->cylinders = ccg->volume_size / secs_per_cylinder; > - ccb->ccb_h.status = CAM_REQ_CMP; > - > + cam_calc_geometry(&ccb->ccg, /*extended*/1); > xpt_done(ccb); > break; > } > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Fri May 16 15:17:15 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEFB937B401 for ; Fri, 16 May 2003 15:17:15 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0347F43F85 for ; Fri, 16 May 2003 15:17:15 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 83301 invoked by uid 1000); 16 May 2003 22:17:16 -0000 Date: Fri, 16 May 2003 15:17:16 -0700 (PDT) From: Nate Lawson To: Scott Long In-Reply-To: <3EC53467.9080101@btc.adaptec.com> Message-ID: <20030516151546.S83293@root.org> References: <20030516105356.E82960@root.org> <3EC53467.9080101@btc.adaptec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: scsi@freebsd.org Subject: Re: PATCH: merge calc geometry calls into convenience function X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 22:17:16 -0000 On Fri, 16 May 2003, Scott Long wrote: > cam_calc_std_geometry() might be a better name. I like the idea in any > case. However, could you hold off until after the 5.1 branch? Of course. This was just something I had in my tree that I wanted to get out for review. It is not being considered for 5.1. I'd also like comments about the location of the function and prototype (in cam.c and cam_ccb.h). This is a minor thing but good since several bugs were uncovered in the previous cut/pasted functions. -Nate From owner-freebsd-scsi@FreeBSD.ORG Sat May 17 06:01:50 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28EC737B404 for ; Sat, 17 May 2003 06:01:50 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25A6243F93 for ; Sat, 17 May 2003 06:01:49 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 063C53FF4 for ; Sat, 17 May 2003 09:01:47 -0400 (EDT) From: "Dan Langille" To: freebsd-scsi@freebsd.org Date: Sat, 17 May 2003 09:01:46 -0400 MIME-Version: 1.0 Message-ID: <3EC5FA7A.23911.75B535D2@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: ad0: READ command timeout.... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2003 13:01:50 -0000 This morning I found a frozen box. On the console was this: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. ata0-slave: ATA identify retries exceeded done After reboot, those messages were found in /var/log/messages. Any ideas? -- Dan Langille : http://www.langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sat May 17 10:49:15 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91E1D37B401 for ; Sat, 17 May 2003 10:49:15 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id EB75F43FDF for ; Sat, 17 May 2003 10:49:14 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 86993 invoked by uid 1000); 17 May 2003 17:49:15 -0000 Date: Sat, 17 May 2003 10:49:15 -0700 (PDT) From: Nate Lawson To: Dan Langille In-Reply-To: <3EC5FA7A.23911.75B535D2@localhost> Message-ID: <20030517104841.C86977@root.org> References: <3EC5FA7A.23911.75B535D2@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org Subject: Re: ad0: READ command timeout.... X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2003 17:49:15 -0000 On Sat, 17 May 2003, Dan Langille wrote: > This morning I found a frozen box. On the console was this: > > ad0: READ command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. ata0-slave: ATA identify retries exceeded > done > > After reboot, those messages were found in /var/log/messages. > > Any ideas? No idea. You might want to ask about ATA problems on -current or -stable. -Nate From owner-freebsd-scsi@FreeBSD.ORG Sat May 17 16:11:05 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CB5A37B401 for ; Sat, 17 May 2003 16:11:05 -0700 (PDT) Received: from mobile.hub.org (u153n214.eastlink.ca [24.224.153.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5BC243F3F for ; Sat, 17 May 2003 16:11:04 -0700 (PDT) (envelope-from scrappy@hub.org) Received: by mobile.hub.org (Postfix, from userid 1001) id 68E924792; Sat, 17 May 2003 20:11:03 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mobile.hub.org (Postfix) with ESMTP id 44F9B44F7 for ; Sat, 17 May 2003 20:11:03 -0300 (ADT) Date: Sat, 17 May 2003 20:11:03 -0300 (ADT) From: The Hermit Hacker To: freebsd-scsi@freebsd.org Message-ID: <20030517200209.Q598@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: talking to iir driver ... ? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2003 23:11:05 -0000 Morning all ... Is there a way, with camcontrol, of probing the iir drive to find out what drives are sitting behind it? Or a command line interface to talk to the controller similar to Adaptec's aacli? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org