From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 30 02:39:50 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 F38C416A4CE; Tue, 30 Nov 2004 02:39:49 +0000 (GMT) Received: from skippyii.compar.com (skippyii.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF4943D55; Tue, 30 Nov 2004 02:39:49 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])iAU2l4K2022765; Mon, 29 Nov 2004 21:47:05 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <003801c4d685$81192640$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: , , References: <16811.51043.987275.174410@canoe.dclg.ca> Date: Mon, 29 Nov 2004 21:37:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: 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 02:39:50 -0000 Dave, > 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. Here's what I found by walking through the code. Mind you, given that I'm no expert on this code either, I may be missing things. 1) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 probes the device for capacity information. 2) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then calls dasetgeom(). The parameters to dasetgeom() are obtained from 1), are updated in softc->params and later the ccg. All variables involved in these assignments have matching types, so there should be no truncation. 3) dasetgeom() then calls xpt_action() [ which I'm assuming is redirected to dev/isp/isp_freebsd.c::isp_action() ] with a function id of XPT_CALC_GEOMETRY, which ultimately calls cam_calc_geometry(). 4) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then prints out a probe of the device size. You indicate that this probe is done properly. >From what I see, cam_calc_geometry() is called *before* the device probe prints out the device size, so I'm unsure of how what you are describing can occur. Have you built & run a kernel compiled with "options CAMDEBUG" ? This may provide more insight into where things are going wrong. -- Matt Emmerton