From owner-cvs-all@FreeBSD.ORG Wed Apr 30 10:51:40 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9065A37B401; Wed, 30 Apr 2003 10:51:40 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7738943F75; Wed, 30 Apr 2003 10:51:39 -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 h3UHpcPM004051; Wed, 30 Apr 2003 11:51:38 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.9/8.12.5/Submit) id h3UHpbcD004050; Wed, 30 Apr 2003 11:51:37 -0600 (MDT) (envelope-from ken) Date: Wed, 30 Apr 2003 11:51:37 -0600 From: "Kenneth D. Merry" To: Nate Lawson Message-ID: <20030430115137.A4010@panzer.kdm.org> References: <20030430003533.1684837B407@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nate@root.org on Wed, Apr 30, 2003 at 10:32:34AM -0700 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_all.c scsi_all.h scsi_da.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 17:51:41 -0000 On Wed, Apr 30, 2003 at 10:32:34 -0700, Nate Lawson wrote: > On Tue, 29 Apr 2003, Kenneth D. Merry wrote: > > Modified files: > > sys/cam cam_ccb.h > > sys/cam/scsi scsi_all.c scsi_all.h scsi_da.c > > Log: > > Add support to CAM for devices with more than 2^32 blocks. (2TB if you're > > using 512 byte blocks). > > Excellent! BTW, this could use more testing from people who have 16 byte > CDB equipment. Run sysctl kern.cam.da.%d.minimum_cmd_size=16 (where %d is > the device number). But be sure the equipment can handle it otherwise > your drive may hang. Julian said he may be able to test it. His box can't create an array larger than 2TB (unless they change their firmware), but it does accept 16 byte commands. If anyone else has equipment that can handle 16 byte commands, we could use the testing. > > @@ -1100,6 +1160,22 @@ > > (bytes[1] << 16) | > > (bytes[2] << 8) | > > bytes[3]; > > + return (rv); > > +} > > + > > +static __inline uint64_t > > +scsi_8btou64(uint8_t *bytes) > > +{ > > + uint64_t rv; > > + > > + rv = (((uint64_t)bytes[0]) << 56) | > > + (((uint64_t)bytes[1]) << 48) | > > + (((uint64_t)bytes[2]) << 40) | > > + (((uint64_t)bytes[3]) << 32) | > > + (((uint64_t)bytes[4]) << 24) | > > + (((uint64_t)bytes[5]) << 16) | > > + (((uint64_t)bytes[6]) << 8) | > > + bytes[7]; > > return (rv); > > } > > sys/endian.h? I'll try to get around to it. Ken -- Kenneth Merry ken@kdm.org