Date: Tue, 10 Apr 2012 23:16:56 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Cc: Jim Harris <jimharris@FreeBSD.org>, Scott Long <scottl@samsco.org>, Alexander Motin <mav@FreeBSD.org> Subject: Re: svn commit: r234106 - head/sys/dev/isci Message-ID: <4F849538.9000604@FreeBSD.org> In-Reply-To: <201204101633.q3AGXJjG031714@svn.freebsd.org> References: <201204101633.q3AGXJjG031714@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 10/04/2012 19:33 Jim Harris said the following: > Author: jimharris > Date: Tue Apr 10 16:33:19 2012 > New Revision: 234106 > URL: http://svn.freebsd.org/changeset/base/234106 > > Log: > Queue CCBs internally instead of using CAM_REQUEUE_REQ status. This fixes > problem where userspace apps such as smartctl fail due to CAM_REQUEUE_REQ > status getting returned when tagged commands are outstanding when smartctl > sends its I/O using the pass(4) interface. > > Sponsored by: Intel > Found and tested by: Ravi Pokala <rpokala at panasas dot com> > Reviewed by: scottl > Approved by: scottl > MFC after: 1 week Once upon a time I had an idea that CAM_REQUEUE_REQ should never be leaked to userland and always re-queued. But our SCSI experts were against that. (I don't recall the exact argument, but I think that it was something about target emulation). So there is at least one other driver that likely needs the same kind of change. Maybe we should have some common infrastructure to support "really re-queue this CCB" case, so that each driver doesn't have to re-implement it? Or maybe CAM_REQUEUE_REQ should become that kind of command, after all. [Just thinking out loud] -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F849538.9000604>