isp driver not 64 bit?

[Matt Emmerton]

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