Date: Wed, 15 Oct 2003 23:31:20 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: David Sze <dsze@alumni.uwaterloo.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: Dell PowerEdge 1750 and mpt Message-ID: <20031016053120.GA49838@panzer.kdm.org> In-Reply-To: <6.0.0.22.2.20031015212813.039fcd48@mail.distrust.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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@kdm.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031016053120.GA49838>