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>