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>