Date: Thu, 16 Oct 2003 09:20:33 -0400 From: David Sze <dsze@alumni.uwaterloo.ca> To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-scsi@freebsd.org Subject: Re: Dell PowerEdge 1750 and mpt Message-ID: <6.0.0.22.2.20031016090937.039ff8c8@mail.distrust.net> In-Reply-To: <20031016053120.GA49838@panzer.kdm.org> References: <6.0.0.22.2.20031014232154.03a0b990@mail.distrust.net> <6.0.0.22.2.20031015080310.03ac9b88@mail.distrust.net> <20031015100215.U34498@root.org> <20031015180131.GA25402@pooh.distrust.net> <20031015133813.O35236@root.org> <6.0.0.22.2.20031015212813.039fcd48@mail.distrust.net> <20031016053120.GA49838@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.0.22.2.20031016090937.039ff8c8>