Date: Mon, 29 Nov 2004 21:37:13 -0500 From: "Matt Emmerton" <matt@gsicomp.on.ca> To: <freebsd-amd64@freebsd.org>, <freebsd-hackers@freebsd.org>, <freebsd-list@dclg.ca> Subject: Re: isp driver not 64 bit? Message-ID: <003801c4d685$81192640$1200a8c0@gsicomp.on.ca> References: <16811.51043.987275.174410@canoe.dclg.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003801c4d685$81192640$1200a8c0>