From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 30 01:05:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3365116A4CE; Tue, 30 Nov 2004 01:05:48 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id F361743D3F; Tue, 30 Nov 2004 01:05:47 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 6572CC747; Mon, 29 Nov 2004 20:05:47 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 0FFE66819; Mon, 29 Nov 2004 20:05:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16811.51043.987275.174410@canoe.dclg.ca> Date: Mon, 29 Nov 2004 20:05:39 -0500 To: freebsd-amd64@freebsd.org, freebsd-hackers@freebsd.org From: freebsd-list@dclg.ca X-Mailer: VM 7.17 under 21.5 (beta17) "chayote" (+CVS-20040321) XEmacs Lucid Subject: isp driver not 64 bit? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 01:05:48 -0000 After a bunch of frustrating debugging, I've tenatively come to the conclusion that the isp(4) driver is not 64 bit safe --- at the very least insofar as the amd64 platform is concerned. The test setup was a quad opteron 248 system connected via two isp 2340 cards to switches which interconnect to an EMC^2 disk array. I've made a couple of interim posts on this subject. The message from scsi_da.c indicates the correct probe is received from the disk. In the test, it was a 131 gig disk of 512 byte sectors. However, by the time we get to cam_calc_geometry() in cam.c, the structure is corrupt --- containing bad values for both volume_size and sector_size. The data is bogus enough at this point, that it can't be repaired ... and I gave up on the "quick fix" effort. Origionally, it manifested as a divide by zero error (the block size was so huge, it brought the denominator in the first few lines to zero). But both the block_size and the volume_size are bogus making efforts by geom to taste the last sector fail. The isp driver is quite complex. I havn't encountered much of the SCSI or CAM stack before. It would seem a brief overview of where things go from the momment when scsi_da prints out the correct size to the point at which cam_calc_geometry() receives corrupt data would help greately. Our hardware vendor is going to try to obtain test hardware for the LSI logic HBA and an Adaptec HBA --- so we can test them. The test machine remains somewhat available, but it looks like the production machines will be linux (unless I can solve this problem this week). Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================