From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753957AbcBVKCt (ORCPT ); Mon, 22 Feb 2016 05:02:49 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:31604 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751614AbcBVKCr (ORCPT ); Mon, 22 Feb 2016 05:02:47 -0500 From: John Garry Subject: Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure() To: Hannes Reinecke , , References: <1455625351-165881-1-git-send-email-john.garry@huawei.com> <1455625351-165881-6-git-send-email-john.garry@huawei.com> <56C34163.70606@suse.de> <56C354A5.6080503@huawei.com> <56C5756A.9060700@suse.de> <56C59922.6070600@huawei.com> <56C59D47.30500@suse.de> <56C5A3A6.1090100@huawei.com> <56C6F28B.9090000@huawei.com> <56C72747.5070909@suse.de> CC: , , , , Message-ID: <56CADCA8.8030206@huawei.com> Date: Mon, 22 Feb 2016 10:02:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C72747.5070909@suse.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.46.95.245] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56CADCB5.012C,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1148716548265bfbdbce1a9415be508 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> I would like to make another point about why I am making this change >> in case it is not clear. The queue full events are form >> TRANS_TX_CREDIT_TIMEOUT_ERR and TRANS_TX_CLOSE_NORMAL_ERR errors in >> the slot: I want the slot retried when this occurs, so I set status >> as SAS_QUEUE_FULL just so we will report DID_SOFT_ERR to SCSI >> midlayer so we get a retry. I could use SAS_OPEN_REJECT >> alternatively as the error which would have the same affect. >> The queue full are not from all slots being consumed in the HBA. >> > Ah, right. So you might be getting those errors even with some free > slots on the HBA. As such they are roughly equivalent to a > QUEUE_FULL SCSI statue, right? > So after reading SPL I guess you are right here; using tags wouldn't > help for this situation. > Yes, I think we have 90% of slots free in the host when this occurs for one particular test - Our v2 hw has 2K slots, which is >> cmd_per_lun. The errors are equivalent to queue full for the device. Thanks, John > Cheers, > > Hannes >