Dell PowerEdge 1750 and mpt

[David Sze]

At 11:31 PM 15/10/2003 -0600, Kenneth D. Merry wrote this to All:
>On Wed, Oct 15, 2003 at 21:41:30 -0400, David Sze wrote:
> > Notice how this snippet of code never directly sends 
> XPT_GET_TRAN_SETTINGS,
> > so the source of the junk pointer/CCB cannot be me.
>
>libcam sends the XPT_GET_TRAN_SETTINGS CCB, to fill in sync rate/bus width
>fields in the cam_device structure.

Right, I see where that is in libcam.  So if I just want the serial, then I 
should just open the appropriate /dev/passX and send a XPT_GDEV_TYPE, and 
that shouldn't tickle the panic with mpt(4).


> > Removing all traces of this serial # gathering code from our application
> > has gotten rid of the panics.
>
>Since it works on other drivers and fails with the mpt(4) driver, it may
>be a problem with the mpt(4) driver.

Or possibly with the hardware/firmware revision of the 53c1030 in the Dell 
1750.  I have three IBM eServer 345 boxes that also use mpt(4), and so far 
they aren't showing the panic problem when running the same code.


> > int main() {
> >     struct cam_device   device;
> >     char                kpcSerials[sizeof(device.serial_num)*DEVICE_MAX+1];
> >     unsigned int        unLen = 0;
> >
> >     for (int n = 0; n < DEVICE_MAX; ++n) {
> >         if (NULL == ::cam_open_spec_device("pass", n, O_RDWR, &device))
> >             break;
>
>You'd probably be better off going back to your original code that uses an
>XPT_DEV_MATCH CCB.
>
>With the above code, you'll run into problems if you've got sparse unit
>numbers.  e.g. if you've got a device hardwired, or if you rescan a bus or
>device and it goes away.  (e.g. you've got pass0, pass1, pass2, and pass4)

Not to mention that a ::cam_open_spec_device() followed by a 
::cam_close_spec_device() seems to result in a descriptor leak.  I wrapped 
the previous code in a while(1){}, and /dev/xpt0 wasn't being closed.