Dell PowerEdge 1750 and mpt

[Kenneth D. Merry]

On Wed, Oct 15, 2003 at 21:41:30 -0400, David Sze wrote:
> At 01:38 PM 15/10/2003 -0700, Nate Lawson wrote this to All:
> >I'm out of time for this thread.  Find the diff between your code and
> >camcontrol inquiry -S and you'll find the bug.
> 
> Thanks for your help Nate.  I don't expect you to respond to this message, 
> I'm just replying so that it shows up in the archives for anyone else that 
> might have problems with the Dell 1750 and mpt.
> 
> For those who are interested, it doesn't appear to be a bug in my code.  I 
> replaced everything that I copied from camcontrol with what follows below, 
> which only uses the functions documented in cam(3).  The kernel still 
> panic'ed after a few hours, with an identical backtrace to the one posted 
> previously.
> 
> 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.

> 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.

> 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)

Ken
-- 
Kenneth Merry
ken at kdm.org