isp driver not 64 bit?
matt at gsicomp.on.ca
Mon Nov 29 18:39:50 PST 2004
> 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
2) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then calls
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
Have you built & run a kernel compiled with "options CAMDEBUG" ? This may
provide more insight into where things are going wrong.
More information about the freebsd-amd64