Date: Thu, 8 Sep 2011 16:30:50 -0600 From: "Kenneth D. Merry" <ken@freebsd.org> To: Douglas Gilbert <dgilbert@interlog.com> Cc: freebsd-scsi@freebsd.org, Matthew Jacob <mj@feral.com> Subject: Re: smp_utils: command line utilities for SAS expanders Message-ID: <20110908223050.GA70361@nargothrond.kdm.org> In-Reply-To: <4E68E43B.9080907@interlog.com> References: <4E60FD85.4070708@interlog.com> <20110907164313.GA20036@nargothrond.kdm.org> <alpine.BSF.2.00.1109070948390.3778@ns1.feral.com> <20110907172219.GA31291@nargothrond.kdm.org> <alpine.BSF.2.00.1109071119500.3778@ns1.feral.com> <20110908144948.GA76725@nargothrond.kdm.org> <4E68E43B.9080907@interlog.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 08, 2011 at 11:50:19 -0400, Douglas Gilbert wrote: > On 11-09-08 10:49 AM, Kenneth D. Merry wrote: > >On Wed, Sep 07, 2011 at 11:19:59 -0700, Matthew Jacob wrote: > >> > >>>It'll get fixed when we add SMP probe code into CAM. > >> > >>ETA? > > > >Last year I would have said this year. Right now I'm not sure. > > > >It'll probably happen along with the multipathing work we're planning to do > >for CAM, since our initial goal will be handling multiple paths in a SAS > >topology. > > > >Our management is currently figuring out our priorties for the next set of > >features they want. Once they figure that out I may have a better idea of > >when it'll happen. I'm pretty sure multipathing won't be the next feature > >we do, so my guess is that we wouldn't start on it until next year. > > > >If there are other folks who are interested in helping out so that the > >multipathing work happens sooner, that might influence our time frame for > >working on it to some extent. > > > >One short-term note -- I'm working on support for descriptor sense right > >now. Seagate's new 3TB SAS drives return descriptor sense by default. > > If you are working on sense data then you might find the > sg_decode_sense utility in the sg3_utils package useful. > [BTW I have ported most of my packages to FreeBSD: > sg3_utils, sdparm, smp_utils and ddpt.] Also the > sg_lib_data.c file in the sg3_utils' lib directory contains > an up to date list (in C) of asc/ascq strings. Thanks! > And then there is this nasty slipped into SAM-5 (sam5r07.pdf > section 5.3.1): "Sense data may be delivered in the buffer > defined by the Sense Data argument of the Execute Command > procedure call (see 5.1) for ANY status code." > The only example of this so far seems to be referrals (see > sbc3r27.pdf section 4.26.4). Now a successful SCSI READ may > return status=GOOD with sense data that contains > sense_key=COMPLETED and the asc/ascq pair for "INSPECT > REFERRALS SENSE DESCRIPTORS". I don't think Linux is even > close to handling this new wrinkle. That is very tricky. I guess it makes sense that they did that, but it does change some long-held assumptions about when sense data is present. FreeBSD won't look at the sense data either unless the status is CHECK CONDITION. Although it wouldn't be too difficult to check in the da(4) driver to see whether any sense data was reported, and collect any referral information if necessary. I'm guessing we'll wind up looking at the referrals at least when we do the multipathing work. It'll be interesting to see what other ways they use sense data later on. Ken -- Kenneth Merry ken@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110908223050.GA70361>