freebsd-scsi Digest, Vol 360, Issue 2

Thu Mar 18 15:06:05 UTC 2010

Un fucking subscribe
Unsubscribe
Fucking unsubscribe

-----Original Message-----
From: owner-freebsd-scsi at freebsd.org
[mailto:owner-freebsd-scsi at freebsd.org] On Behalf Of
freebsd-scsi-request at freebsd.org
Sent: Thursday, March 18, 2010 5:00 AM
To: freebsd-scsi at freebsd.org
Subject: freebsd-scsi Digest, Vol 360, Issue 2

Send freebsd-scsi mailing list submissions to
	freebsd-scsi at freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
or, via email, send a message with subject or body 'help' to
	freebsd-scsi-request at freebsd.org

You can reach the person managing the list at
	freebsd-scsi-owner at freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-scsi digest..."

Today's Topics:

   1. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Kenneth D. Merry)
   2. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Andriy Gapon)
   3. problems with mfi/DELL Perc6? (Daniel Braniss)

----------------------------------------------------------------------

Message: 1
Date: Wed, 17 Mar 2010 11:28:47 -0600
From: "Kenneth D. Merry" <ken at kdm.org>
Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs
To: Andriy Gapon <avg at icyb.net.ua>
Cc: freebsd-scsi at freebsd.org
Message-ID: <20100317172847.GA15531 at nargothrond.kdm.org>
Content-Type: text/plain; charset=us-ascii

On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote:
> 
> At present pass(4) never retries a request (or performs any other kind
of error
> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set.
> This gives applications a control over error checking and handling.
> But I think that in the case of CAM_REQUEUE_REQ status error recovery,
> specifically a request retry, should always be performed.
> 
> Rationale:
> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem.
> It doesn't convey any information about state of medium, device, bus,
controller
> or the ccb itself.  Application can not make any meaningful
differentiation
> based on this status.  It either should always retry a ccb with this
status or
> face truly random failures.  As such, I haven't encountered so far any
> application that expects to get CAM_REQUEUE_REQ status.
> So I think that CAM_REQUEUE_REQ should be contained within the CAM and
never be
> leaked to applications unless retry count is exhausted (to prevent
endless loops
> in case of programming errors, primarily).
> 
> What do you think?
> Do you see any reason not to do it?

Is there a particular case you're running into where CAM_REQUEUE_REQ is
getting returned?

I think it's better to keep the model as-is, to avoid confusion.  Either
the application is handling errors, and it can get any CAM status value,
or
it is asking the pass(4) driver to do error recovery and it doesn't have
to
handle things until error recovery is done and retries are exhausted.

If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it
shouldn't, we should probably look at that.  Retries can get used up for
various target-related reasons, like unit attention conditions, and we
don't want to use CAM_REQUEUE_REQ when it isn't really needed.

Ken
-- 
Kenneth Merry
ken at kdm.org

------------------------------

Message: 2
Date: Wed, 17 Mar 2010 20:00:13 +0200
From: Andriy Gapon <avg at icyb.net.ua>
Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs
To: "Kenneth D. Merry" <ken at kdm.org>
Cc: freebsd-scsi at freebsd.org
Message-ID: <4BA118AD.6050102 at icyb.net.ua>
Content-Type: text/plain; charset=ISO-8859-1

on 17/03/2010 19:28 Kenneth D. Merry said the following:
> On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote:
>> At present pass(4) never retries a request (or performs any other
kind of error
>> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set.
>> This gives applications a control over error checking and handling.
>> But I think that in the case of CAM_REQUEUE_REQ status error
recovery,
>> specifically a request retry, should always be performed.
>>
>> Rationale:
>> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem.
>> It doesn't convey any information about state of medium, device, bus,
controller
>> or the ccb itself.  Application can not make any meaningful
differentiation
>> based on this status.  It either should always retry a ccb with this
status or
>> face truly random failures.  As such, I haven't encountered so far
any
>> application that expects to get CAM_REQUEUE_REQ status.
>> So I think that CAM_REQUEUE_REQ should be contained within the CAM
and never be
>> leaked to applications unless retry count is exhausted (to prevent
endless loops
>> in case of programming errors, primarily).
>>
>> What do you think?
>> Do you see any reason not to do it?
> 
> Is there a particular case you're running into where CAM_REQUEUE_REQ
is
> getting returned?

Yes, access to ATAPI devices with ahci(4).

> I think it's better to keep the model as-is, to avoid confusion.
Either
> the application is handling errors, and it can get any CAM status
value, or
> it is asking the pass(4) driver to do error recovery and it doesn't
have to
> handle things until error recovery is done and retries are exhausted.

I've had a chat with Justin Gibbs and he is of the same opinion.  His
explanation
makes sense to me.  I didn't look beyond 'for home use' applications
when I came
up with the suggestion.
So, I think that we'd better teach affected applications about
CAM_REQUEUE_REQ.

> If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it
> shouldn't, we should probably look at that.  Retries can get used up
for
> various target-related reasons, like unit attention conditions, and we
> don't want to use CAM_REQUEUE_REQ when it isn't really needed.

I guess that this would be ideal.
I think that it is an implementation detail in ahci(4) that some
commands may get
CAM_REQUEUE_REQ status.  But I am not sure if there is an easy way to
fix that
given the general logic in that driver.

-- 
Andriy Gapon

------------------------------

Message: 3
Date: Thu, 18 Mar 2010 10:59:43 +0200
From: Daniel Braniss <danny at cs.huji.ac.il>
Subject: problems with mfi/DELL Perc6?
To: freebsd-scsi at freebsd.org
Message-ID: <E1NsBZv-000PH9-MK at kabab.cs.huji.ac.il>
Content-Type: text/plain; charset=us-ascii

hi,
we keep seeing these timeouts when there is heavy writes to the mfi:
...
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS
mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS
mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS
mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS
mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS
mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS
mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS
mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS
...
mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS

the card is:

mfi1: <Dell PERC 6> port 0xec00-0xecff mem
0xdf280000-0xdf2bffff,0xdf2c0000-0xd
f2fffff irq 38 at device 0.0 on pci6
mfi1: Megaraid SAS driver Ver 3.00 

any idea what the message means?

thanks,
	danny

------------------------------

_______________________________________________
freebsd-scsi at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"

End of freebsd-scsi Digest, Vol 360, Issue 2
********************************************