[PATCH][SCSI] scsi: ufs: get a TM service response from the correct offset

[Kiwoong Kim]

From: Kiwoong Kim 

When any UFS host controller receives a TM(Task Management)
response from a UFS device,
UFS driver has been recognize like receiving a message of
"Task Management Function Complete"(00h) in all cases, so far.
That means there is no pending task for a tag of the TM request
sent before in the UFS device.
That's because the byte offset 6 in TM response which has been used
to get a TM service response so far
represents just whether or not a TM transmission passes.

Regarding UFS spec, the correct byte offset to
get TM service response is 15, not 6.

I tested that UFS driver responds properly for the TM response
>From a UFS device with an reference board with exynos8890, as follow:
No pending task -> Task Management Function Complete (00h)
Pending task -> Task Management Function Succeeded (08h)

Signed-off-by: Kiwoong Kim 
Signed-off-by: HeonGwang Chu 
Tested-by: : Kiwoong Kim 
---
 drivers/scsi/ufs/ufs.h|1 +
 drivers/scsi/ufs/ufshcd.c |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 42c459a..89c121e 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -295,6 +295,7 @@ enum {
MASK_QUERY_DATA_SEG_LEN = 0x,
MASK_RSP_UPIU_DATA_SEG_LEN  = 0x,
MASK_RSP_EXCEPTION_EVENT= 0x1,
+   MASK_TM_SERVICE_RESP= 0xFF,
 };

 /* Task management service response */
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e8a706b..c641cd3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3013,8 +3013,8 @@ static int ufshcd_task_req_compl(struct ufs_hba *hba, u32 
index, u8 *resp)
if (ocs_value == OCS_SUCCESS) {
task_rsp_upiup = (struct utp_upiu_task_rsp *)
task_req_descp[index].task_rsp_upiu;
-   task_result = be32_to_cpu(task_rsp_upiup->header.dword_1);
-   task_result = ((task_result & MASK_TASK_RESPONSE) >> 8);
+   task_result = be32_to_cpu(task_rsp_upiup->output_param1);
+   task_result = task_result & MASK_TM_SERVICE_RESP;
if (resp)
*resp = (u8)task_result;
} else {
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V4 2/2] aacraid: remove wildcard for series 9 controllers

[James Bottomley]

On September 8, 2016 2:33:52 PM EDT, Scott Benesh  
wrote:
>> 
>> On Thu, 2016-09-08 at 18:15 +, Don Brace wrote:
>> > > > -{ 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /*
>> > > > Adaptec PMC
>> > > > Series 9 */
>> > > >
>> > > > How are people that load aacraid in their initrd going to boot
>> > > > after this?
>> > > >
>> > > > --
>> > > > Martin K. Petersen  Oracle Linux Engineering
>> > >
>> > > I updated smartpqi/Kconfig and added
>Documentation/scsi/smartpqi.txt
>> > > to inform users of the need to configure the smartpqi driver
>moving
>> > > forward for aacraid Series 9 controllers.
>> > >
>> > > Hope this helps.
>> 
>> That's not going to be enough: this ID has been in the aacriad driver
>since
>> 2011.  That means anyone who finally gets hold of one of these new
>cards
>> but uses a distro that doesn't have the new smartpqi driver will be
>attached
>> via the aacraid one.
>> 
>
>That's ok because for previous distros the new controller will work
>with the previous aacraid driver, although with non-optimal
>performance.

Not after this change hits. Then systems that only have aacraid in the initrd 
will fail to boot.

>What we want to do is sync up at 4.9 so going forward only the new
>smartpqi driver will attach to these new controllers.

So you have a plan in place with the distros to migrate the initrd images? 
Without being told, some will only install the modules the previous initrd  was 
configured for.

James

>Scott
>
>> Given that the life times of enterprise distributions is two years
>and you're
>> releasing this smartpqi soon, the overlap is unavoidable.
>> 
>> James
>> 


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] scsi: ibmvfc: fix typo in parameter description

[Tyrel Datwyler]

On 09/08/2016 08:04 AM, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix typo in parameter description.
> 
> Signed-off-by: Wei Yongjun 

Reviewed-by: Tyrel Datwyler 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V4 2/2] aacraid: remove wildcard for series 9 controllers

[Scott Benesh]

> 
> On Thu, 2016-09-08 at 18:15 +, Don Brace wrote:
> > > > -{ 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /*
> > > > Adaptec PMC
> > > > Series 9 */
> > > >
> > > > How are people that load aacraid in their initrd going to boot
> > > > after this?
> > > >
> > > > --
> > > > Martin K. Petersen  Oracle Linux Engineering
> > >
> > > I updated smartpqi/Kconfig and added Documentation/scsi/smartpqi.txt
> > > to inform users of the need to configure the smartpqi driver moving
> > > forward for aacraid Series 9 controllers.
> > >
> > > Hope this helps.
> 
> That's not going to be enough: this ID has been in the aacriad driver since
> 2011.  That means anyone who finally gets hold of one of these new cards
> but uses a distro that doesn't have the new smartpqi driver will be attached
> via the aacraid one.
> 

That's ok because for previous distros the new controller will work with the 
previous aacraid driver, although with non-optimal performance.

What we want to do is sync up at 4.9 so going forward only the new smartpqi 
driver will attach to these new controllers.

Scott

> Given that the life times of enterprise distributions is two years and you're
> releasing this smartpqi soon, the overlap is unavoidable.
> 
> James
> 

[Bug 156411] scsi host6: runtime PM trying to activate child device host6 but parent (3-4:1.0) is not active

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=156411

--- Comment #1 from Cristian Aravena Romero  ---
Created attachment 232721
  --> https://bugzilla.kernel.org/attachment.cgi?id=232721=edit
lspci -vvnn

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 156411] New: scsi host6: runtime PM trying to activate child device host6 but parent (3-4:1.0) is not active

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=156411

Bug ID: 156411
   Summary: scsi host6: runtime PM trying to activate child device
host6 but parent (3-4:1.0) is not active
   Product: IO/Storage
   Version: 2.5
Kernel Version: 4.8.0-040800rc5-lowlatency
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: SCSI
  Assignee: linux-scsi@vger.kernel.org
  Reporter: carav...@gmail.com
Regression: No

Created attachment 232711
  --> https://bugzilla.kernel.org/attachment.cgi?id=232711=edit
dmesg_4.8.0-040800rc5-lowlatency

dmesg:

[ 8604.247753] scsi host6: runtime PM trying to activate child device host6 but
parent (3-4:1.0) is not active

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

patch "libata: Add support for SCT Write Same" breaks system

[Mike Krinkin]

Hi,

i tried recent linux-next on my laptop, and after boot system is
almost unusable because most of apps just crash with segfaults and
in dmesg output there are a lot of errors like this:

[   17.641510] do_general_protection: 51 callbacks suppressed
[   17.641514] traps: dpkg[2831] general protection ip:40be90 sp:7ffd6daad9b8 
error:0 in dpkg[40+43000]
[   17.648882] apport[2832]: segfault at 8 ip 00485896 sp 
7ffece3b6c40 error 6 in python3.5[40+3a7000]
[   17.648965] Process 2832(apport) has RLIMIT_CORE set to 1
[   17.648967] Aborting core
[   17.653463] gpu-manager[2818]: segfault at 0 ip 7f77c4b8eb5a sp 
7ffc7a01b348 error 4 in libc-2.23.so[7f77c4af+1c]
[   17.660760] apport[2833]: segfault at 8 ip 00485896 sp 
7ffddfe2a650 error 6 in python3.5[40+3a7000]
[   17.660841] Process 2833(apport) has RLIMIT_CORE set to 1
[   17.660843] Aborting core
[   18.192604] apport[2847]: segfault at 8 ip 00485896 sp 
7ffd2d4a82c0 error 6 in python3.5[40+3a7000]
[   18.192630] Process 2847(apport) has RLIMIT_CORE set to 1
[   18.192633] Aborting core
[   19.089476] traps: dpkg[2861] general protection ip:40be90 sp:7ffcabc70fa8 
error:0 in dpkg[40+43000]
[   19.096747] apport[2862]: segfault at 8 ip 00485896 sp 
7ffeda308490 error 6 in python3.5[40+3a7000]
[   19.096827] Process 2862(apport) has RLIMIT_CORE set to 1
[   19.096829] Aborting core
[   19.101197] gpu-manager[2849]: segfault at 0 ip 7fdccfef8b5a sp 
7ffeb4758488 error 4 in libc-2.23.so[7fdccfe5a000+1c]
[   19.106683] apport[2863]: segfault at 8 ip 00485896 sp 
7ffcf8955d10 error 6 in python3.5[40+3a7000]
[   19.106708] Process 2863(apport) has RLIMIT_CORE set to 1
[   19.106709] Aborting core
[   19.616176] apport[2898]: segfault at 8 ip 00485896 sp 
7ffd12c29180 error 6 in python3.5[40+3a7000]
[   19.616216] Process 2898(apport) has RLIMIT_CORE set to 1
[   19.616217] Aborting core
[   23.182904] lsb_release[2911]: segfault at 8 ip 00485896 sp 
7ffca2f6bec0 error 6 in python3.5[40+3a7000]
[   23.185672] apport[2913]: segfault at 8 ip 00485896 sp 
7ffcf199e160 error 6 in python3.5[40+3a7000]
[   23.185698] Process 2913(apport) has RLIMIT_CORE set to 1
[   23.185698] Aborting core
[   23.212363] apport[2921]: segfault at 8 ip 00485896 sp 
7ffe934094c0 error 6 in python3.5[40+3a7000]
[   23.212389] Process 2921(apport) has RLIMIT_CORE set to 1
[   23.212390] Aborting core
[   23.223112] apport[2926]: segfault at 8 ip 00485896 sp 
7ffcc68e1240 error 6 in python3.5[40+3a7000]
[   23.223137] Process 2926(apport) has RLIMIT_CORE set to 1
[   23.223137] Aborting core

git bisect points at commit 7b20309428598df00ffe ("libata: Add support for SCT
Write Same". I temporary fixed problem with the following change:

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 08d9c8e..0dcd59e 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1159,6 +1159,7 @@ static void ata_scsi_sdev_config(struct scsi_device *sdev)
 {
sdev->use_10_for_rw = 1;
sdev->use_10_for_ms = 1;
+   sdev->no_write_same = 1;
 
/* Schedule policy is determined by ->qc_defer() callback and
 * it needs to see every deferred qc.  Set dev_blocked to 1 to

Don't know whether it will help or not, but here is my hdparm output:

sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
Model Number:   SAMSUNG MZNLN512HCJH-000L1  
Serial Number:  S201NX0H404301  
Firmware Revision:  EMT22L0Q
Transport:  Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, 
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0039) 
Supported: 9 8 7 6 5 
Likely used: 9
Configuration:
Logical max current
cylinders   16383   16383
heads   16  16
sectors/track   63  63
--
CHS current addressable sectors:   16514064
LBAuser addressable sectors:  268435455
LBA48  user addressable sectors: 1000215216
Logical  Sector size:   512 bytes
Physical Sector size:   512 bytes
Logical Sector-0 offset:  0 bytes
device size with M = 1024*1024:  488386 MBytes
device size with M = 1000*1000:  512110 MBytes (512 GB)
cache/buffer size  = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16  Current = 16
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 

Re: [PATCH V4 2/2] aacraid: remove wildcard for series 9 controllers

[James Bottomley]

On Thu, 2016-09-08 at 18:15 +, Don Brace wrote:
> > > -{ 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /*
> > > Adaptec PMC
> > > Series 9 */
> > > 
> > > How are people that load aacraid in their initrd going to boot
> > > after
> > > this?
> > > 
> > > --
> > > Martin K. Petersen  Oracle Linux Engineering
> > 
> > I updated smartpqi/Kconfig and added
> > Documentation/scsi/smartpqi.txt to
> > inform users of the
> > need to configure the smartpqi driver moving forward for aacraid
> > Series 9
> > controllers.
> > 
> > Hope this helps.

That's not going to be enough: this ID has been in the aacriad driver
since 2011.  That means anyone who finally gets hold of one of these
new cards but uses a distro that doesn't have the new smartpqi driver
will be attached via the aacraid one.

Given that the life times of enterprise distributions is two years and
you're releasing this smartpqi soon, the overlap is unavoidable.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V4 2/2] aacraid: remove wildcard for series 9 controllers

[Don Brace]

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Don Brace
> Sent: Wednesday, September 07, 2016 4:05 PM
> To: Martin K. Petersen
> Cc: j...@linux.vnet.ibm.com; Viswas G; Mahesh Rajashekhara;
> h...@infradead.org; Scott Teel; Kevin Barnett; Justin Lindley; Scott Benesh;
> elli...@hpe.com; linux-scsi@vger.kernel.org
> Subject: RE: [PATCH V4 2/2] aacraid: remove wildcard for series 9 controllers
> 
> EXTERNAL EMAIL
> 
> 
> > -Original Message-
> > From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> > Sent: Friday, August 12, 2016 3:09 PM
> > To: Don Brace
> > Cc: j...@linux.vnet.ibm.com; Viswas G; Mahesh Rajashekhara;
> > h...@infradead.org; Scott Teel; Kevin Barnett; Justin Lindley; Scott Benesh;
> > elli...@hpe.com; linux-scsi@vger.kernel.org
> > Subject: Re: [PATCH V4 2/2] aacraid: remove wildcard for series 9
> controllers
> >
> > EXTERNAL EMAIL
> >
> >
> > > "Don" == Don Brace  writes:
> >
> > Don,
> >
> > Don> Depends on smartpqi driver adoption
> >
> > -{ 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /* Adaptec PMC
> > Series 9 */
> >
> > How are people that load aacraid in their initrd going to boot after
> > this?
> >
> > --
> > Martin K. Petersen  Oracle Linux Engineering
> 
> I updated smartpqi/Kconfig and added Documentation/scsi/smartpqi.txt to
> inform users of the
> need to configure the smartpqi driver moving forward for aacraid Series 9
> controllers.
> 
> Hope this helps.
> 
> Thanks,
> Don Brace
> ESC - Smart Storage
> Microsemi Corporation
> 
> 

One more note:
A little extra clarification. Removing these IDs from the aacraid driver has no 
impact on the driver
loading for currently available controllers.

These IDs are only used on new controllers and we want the new smartpqi driver
to only be used with these new controllers. Now that the smartpqi
driver is in for-next we need to get rid of this overlap.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bnx2fc: Simplify code

[Chad Dupuis]

On Sat, 3 Sep 2016, 7:05am -, Christophe JAILLET wrote:

> Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
> 'list_splice_init'.
> 
> This has been spotted with the following coccinelle script:
> /
> @@
> expression y,z;
> @@
> 
> -   list_splice(y,z);
> -   INIT_LIST_HEAD(y);
> +   list_splice_init(y,z);
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
> b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> index a5052dd8d7e6..88be12a02764 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> @@ -2765,8 +2765,7 @@ static void __exit bnx2fc_mod_exit(void)
>* held.
>*/
>   mutex_lock(_dev_lock);
> - list_splice(_list, _be_deleted);
> - INIT_LIST_HEAD(_list);
> + list_splice_init(_list, _be_deleted);
>   adapter_count = 0;
>   mutex_unlock(_dev_lock);
>  
> 

Looks ok to me.

Acked-by: Chad Dupuis 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [SCSI] bnx2fc: mark symbols static where possible

[Chad Dupuis]

On Sun, 4 Sep 2016, 6:52am -, Baoyou Xie wrote:

> We get a few warnings when building kernel with W=1:
> drivers/scsi/bnx2fc/bnx2fc_els.c:257:6: warning: no previous prototype for 
> 'bnx2fc_srr_compl' [-Wmissing-prototypes]
> drivers/scsi/bnx2fc/bnx2fc_els.c:367:6: warning: no previous prototype for 
> 'bnx2fc_rec_compl' [-Wmissing-prototypes]
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c:628:5: warning: no previous prototype for 
> 'bnx2fc_percpu_io_thread' [-Wmissing-prototypes]
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1413:26: warning: no previous prototype for 
> 'bnx2fc_interface_create' [-Wmissing-prototypes]
> drivers/scsi/bnx2fc/bnx2fc_hwi.c:997:21: warning: no previous prototype for 
> 'bnx2fc_alloc_work' [-Wmissing-prototypes]
> drivers/scsi/bnx2fc/bnx2fc_io.c:1082:5: warning: no previous prototype for 
> 'bnx2fc_abts_cleanup' [-Wmissing-prototypes]
> 
> 
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/scsi/bnx2fc/bnx2fc_els.c  | 4 ++--
>  drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 9 +
>  drivers/scsi/bnx2fc/bnx2fc_hwi.c  | 2 +-
>  drivers/scsi/bnx2fc/bnx2fc_io.c   | 2 +-
>  4 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_els.c 
> b/drivers/scsi/bnx2fc/bnx2fc_els.c
> index 5beea77..68ca518 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_els.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_els.c
> @@ -254,7 +254,7 @@ int bnx2fc_send_rls(struct bnx2fc_rport *tgt, struct 
> fc_frame *fp)
>   return rc;
>  }
>  
> -void bnx2fc_srr_compl(struct bnx2fc_els_cb_arg *cb_arg)
> +static void bnx2fc_srr_compl(struct bnx2fc_els_cb_arg *cb_arg)
>  {
>   struct bnx2fc_mp_req *mp_req;
>   struct fc_frame_header *fc_hdr, *fh;
> @@ -364,7 +364,7 @@ srr_compl_done:
>   kref_put(_io_req->refcount, bnx2fc_cmd_release);
>  }
>  
> -void bnx2fc_rec_compl(struct bnx2fc_els_cb_arg *cb_arg)
> +static void bnx2fc_rec_compl(struct bnx2fc_els_cb_arg *cb_arg)
>  {
>   struct bnx2fc_cmd *orig_io_req, *new_io_req;
>   struct bnx2fc_cmd *rec_req;
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
> b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> index a5052dd..5eb38c7 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> @@ -625,7 +625,7 @@ static void bnx2fc_recv_frame(struct sk_buff *skb)
>   *
>   * @arg: ptr to bnx2fc_percpu_info structure
>   */
> -int bnx2fc_percpu_io_thread(void *arg)
> +static int bnx2fc_percpu_io_thread(void *arg)
>  {
>   struct bnx2fc_percpu_s *p = arg;
>   struct bnx2fc_work *work, *tmp;
> @@ -1410,9 +1410,10 @@ bind_err:
>   return NULL;
>  }
>  
> -struct bnx2fc_interface *bnx2fc_interface_create(struct bnx2fc_hba *hba,
> -   struct net_device *netdev,
> -   enum fip_state fip_mode)
> +static struct bnx2fc_interface *
> +bnx2fc_interface_create(struct bnx2fc_hba *hba,
> + struct net_device *netdev,
> + enum fip_state fip_mode)
>  {
>   struct fcoe_ctlr_device *ctlr_dev;
>   struct bnx2fc_interface *interface;
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c 
> b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> index 28c671b..5ff9f89 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> @@ -994,7 +994,7 @@ void bnx2fc_arm_cq(struct bnx2fc_rport *tgt)
>  
>  }
>  
> -struct bnx2fc_work *bnx2fc_alloc_work(struct bnx2fc_rport *tgt, u16 wqe)
> +static struct bnx2fc_work *bnx2fc_alloc_work(struct bnx2fc_rport *tgt, u16 
> wqe)
>  {
>   struct bnx2fc_work *work;
>   work = kzalloc(sizeof(struct bnx2fc_work), GFP_ATOMIC);
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
> index 8f24d60..f501095 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_io.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
> @@ -1079,7 +1079,7 @@ int bnx2fc_eh_device_reset(struct scsi_cmnd *sc_cmd)
>   return bnx2fc_initiate_tmf(sc_cmd, FCP_TMF_LUN_RESET);
>  }
>  
> -int bnx2fc_abts_cleanup(struct bnx2fc_cmd *io_req)
> +static int bnx2fc_abts_cleanup(struct bnx2fc_cmd *io_req)
>  {
>   struct bnx2fc_rport *tgt = io_req->tgt;
>   int rc = SUCCESS;
> 

Looks ok.

Acked-by: Chad Dupuis 
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH -next] scsi: ibmvfc: fix typo in parameter description

[Wei Yongjun]

From: Wei Yongjun 

Fix typo in parameter description.

Signed-off-by: Wei Yongjun 
---
 drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 6b92169..56b9f45 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -88,7 +88,7 @@ module_param_named(log_level, log_level, uint, 0);
 MODULE_PARM_DESC(log_level, "Set to 0 - 4 for increasing verbosity of device 
driver. "
 "[Default=" __stringify(IBMVFC_DEFAULT_LOG_LEVEL) "]");
 module_param_named(cls3_error, cls3_error, uint, 0);
-MODULE_PARM_DESC(log_level, "Enable FC Class 3 Error Recovery. "
+MODULE_PARM_DESC(cls3_error, "Enable FC Class 3 Error Recovery. "
 "[Default=" __stringify(IBMVFC_CLS3_ERROR) "]");
 
 static const struct {

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: squash lines for simple wrapper functions

[Johannes Thumshirn]

On Wed, Sep 07, 2016 at 07:38:58AM +0900, Masahiro Yamada wrote:
> Remove unneeded variables and assignments.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/scsi/aic7xxx/aic79xx_osm.c  |  6 +-
>  drivers/scsi/arcmsr/arcmsr_hba.c|  4 +---
>  drivers/scsi/esas2r/esas2r_ioctl.c  | 20 
>  drivers/scsi/lpfc/lpfc_attr.c   |  8 ++--
>  drivers/scsi/lpfc/lpfc_ct.c |  6 +-
>  drivers/scsi/lpfc/lpfc_scsi.c   |  5 +
>  drivers/scsi/lpfc/lpfc_sli.c|  5 +
>  drivers/scsi/megaraid/megaraid_mm.c |  6 +-
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c  | 30 ++
>  drivers/scsi/osd/osd_initiator.c|  5 +
>  drivers/scsi/pm8001/pm8001_ctl.c| 10 ++
>  drivers/scsi/sg.c   | 10 +++---
>  12 files changed, 32 insertions(+), 83 deletions(-)
> 
> diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c 
> b/drivers/scsi/aic7xxx/aic79xx_osm.c
> index 2588b8f..1169e85 100644
> --- a/drivers/scsi/aic7xxx/aic79xx_osm.c
> +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
> @@ -767,11 +767,7 @@ ahd_linux_biosparam(struct scsi_device *sdev, struct 
> block_device *bdev,
>  static int
>  ahd_linux_abort(struct scsi_cmnd *cmd)
>  {
> - int error;
> - 
> - error = ahd_linux_queue_abort_cmd(cmd);
> -
> - return error;
> + return ahd_linux_queue_abort_cmd(cmd);
>  }
>  
>  /*

I think here the whole wrapper can be deleted. It's doesn't even change the 
function signature.

static int ahd_linux_abort(struct scsi_cmnd *cmd)
vs.
static int ahd_linux_queue_abort_cmd(struct scsi_cmnd *cmd)


> diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c 
> b/drivers/scsi/arcmsr/arcmsr_hba.c
> index 7640498..f1c86f5 100644
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> @@ -3946,9 +3946,7 @@ sleep:
>  static int arcmsr_abort_one_cmd(struct AdapterControlBlock *acb,
>   struct CommandControlBlock *ccb)
>  {
> - int rtn;
> - rtn = arcmsr_polling_ccbdone(acb, ccb);
> - return rtn;
> + return arcmsr_polling_ccbdone(acb, ccb);
>  }
>  
>  static int arcmsr_abort(struct scsi_cmnd *cmd)

Ditto.

> diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c 
> b/drivers/scsi/esas2r/esas2r_ioctl.c
> index 3e84834..12c6284 100644
> --- a/drivers/scsi/esas2r/esas2r_ioctl.c
> +++ b/drivers/scsi/esas2r/esas2r_ioctl.c
> @@ -373,18 +373,14 @@ static bool csmi_ioctl_tunnel(struct esas2r_adapter *a,
>  
>  static bool check_lun(struct scsi_lun lun)
>  {
> - bool result;
> -
> - result = ((lun.scsi_lun[7] == 0) &&
> -   (lun.scsi_lun[6] == 0) &&
> -   (lun.scsi_lun[5] == 0) &&
> -   (lun.scsi_lun[4] == 0) &&
> -   (lun.scsi_lun[3] == 0) &&
> -   (lun.scsi_lun[2] == 0) &&
> -/* Byte 1 is intentionally skipped */
> -   (lun.scsi_lun[0] == 0));
> -
> - return result;
> + return (lun.scsi_lun[7] == 0) &&
> +(lun.scsi_lun[6] == 0) &&
> +(lun.scsi_lun[5] == 0) &&
> +(lun.scsi_lun[4] == 0) &&
> +(lun.scsi_lun[3] == 0) &&
> +(lun.scsi_lun[2] == 0) &&
> + /* Byte 1 is intentionally skipped */
> +(lun.scsi_lun[0] == 0);
>  }
>  
>  static int csmi_ioctl_callback(struct esas2r_adapter *a,

Looks OK.

> diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
> index f101990..79cb019 100644
> --- a/drivers/scsi/lpfc/lpfc_attr.c
> +++ b/drivers/scsi/lpfc/lpfc_attr.c
> @@ -2625,12 +2625,8 @@ lpfc_oas_lun_state_change(struct lpfc_hba *phba, 
> uint8_t vpt_wwpn[],
> uint8_t tgt_wwpn[], uint64_t lun,
> uint32_t oas_state, uint8_t pri)
>  {
> -
> - int rc;
> -
> - rc = lpfc_oas_lun_state_set(phba, vpt_wwpn, tgt_wwpn, lun,
> - oas_state, pri);
> - return rc;
> + return lpfc_oas_lun_state_set(phba, vpt_wwpn, tgt_wwpn, lun,
> +   oas_state, pri);
>  }
>  
>  /**

static ssize_t lpfc_oas_lun_state_change(struct lpfc_hba *phba, uint8_t 
vpt_wwpn[],
 uint8_t tgt_wwpn[], uint64_t lun,
 uint32_t oas_state, uint8_t pri)
vs.
static size_t lpfc_oas_lun_state_set(struct lpfc_hba *phba, uint8_t vpt_wwpn[],
 uint8_t tgt_wwpn[], uint64_t lun,
 uint32_t oas_state, uint8_t pri)

And only one caller lpfc_oas_lun_store()
  


> diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
> index 63e48d4..383943d 100644
> --- a/drivers/scsi/lpfc/lpfc_ct.c
> +++ b/drivers/scsi/lpfc/lpfc_ct.c
> @@ -188,12 +188,8 @@ lpfc_ct_unsol_event(struct lpfc_hba *phba, struct 
> lpfc_sli_ring *pring,
>  int
>  lpfc_ct_handle_unsol_abort(struct lpfc_hba *phba, struct hbq_dmabuf *dmabuf)
>  {
> - int 

Re: Observing Softlockup's while running heavy IOs

[Neil Horman]

On Thu, Sep 08, 2016 at 11:12:40AM +0530, Sreekanth Reddy wrote:
> On Wed, Sep 7, 2016 at 6:54 PM, Neil Horman  wrote:
> > On Wed, Sep 07, 2016 at 11:30:04AM +0530, Sreekanth Reddy wrote:
> >> On Tue, Sep 6, 2016 at 8:36 PM, Neil Horman  wrote:
> >> > On Tue, Sep 06, 2016 at 04:52:37PM +0530, Sreekanth Reddy wrote:
> >> >> On Fri, Sep 2, 2016 at 4:34 AM, Bart Van Assche
> >> >>  wrote:
> >> >> > On 09/01/2016 03:31 AM, Sreekanth Reddy wrote:
> >> >> >>
> >> >> >> I reduced the ISR workload by one third in-order to reduce the time
> >> >> >> that is spent per CPU in interrupt context, even then I am observing
> >> >> >> softlockups.
> >> >> >>
> >> >> >> As I mentioned before only same single CPU in the set of CPUs(enabled
> >> >> >> in affinity_hint) is busy with handling the interrupts from
> >> >> >> corresponding IRQx. I have done below experiment in driver to limit
> >> >> >> these softlockups/hardlockups. But I am not sure whether it is
> >> >> >> reasonable to do this in driver,
> >> >> >>
> >> >> >> Experiment:
> >> >> >> If the CPUx is continuously busy with handling the remote CPUs
> >> >> >> (enabled in the corresponding IRQ's affinity_hint) IO works by 1/4th
> >> >> >> of the HBA queue depth in the same ISR context then enable a flag
> >> >> >> called 'change_smp_affinity' for this IRQ. Also created a thread with
> >> >> >> will poll for this flag for every IRQ's (enabled by driver) for every
> >> >> >> second. If this thread see that this flag is enabled for any IRQ then
> >> >> >> it will write next CPU number from the CPUs enabled in the IRQ's
> >> >> >> affinity_hint to the IRQ's smp_affinity procfs attribute using
> >> >> >> 'call_usermodehelper()' API.
> >> >> >>
> >> >> >> This to make sure that interrupts are not processed by same single 
> >> >> >> CPU
> >> >> >> all the time and to make the other CPUs to handle the interrupts if
> >> >> >> the current CPU is continuously busy with handling the other CPUs IO
> >> >> >> interrupts.
> >> >> >>
> >> >> >> For example consider a system which has 8 logical CPUs and one MSIx
> >> >> >> vector enabled (called IRQ 120) in driver, HBA queue depth as 8K.
> >> >> >> then IRQ's procfs attributes will be
> >> >> >> IRQ# 120, affinity_hint=0xff, smp_affinity=0x00
> >> >> >>
> >> >> >> After starting heavy IOs, we will observe that only CPU0 will be busy
> >> >> >> with handling the interrupts. This experiment driver will change the
> >> >> >> smp_affinity to next CPU number i.e. 0x01 (using cmd 'echo 0x01 >
> >> >> >> /proc/irq/120/smp_affinity', driver issue's this cmd using
> >> >> >> call_usermodehelper() API) if it observes that CPU0 is continuously
> >> >> >> processing more than 2K of IOs replies of other CPUs i.e from CPU1 to
> >> >> >> CPU7.
> >> >> >>
> >> >> >> Whether doing this kind of stuff in driver is ok?
> >> >> >
> >> >> >
> >> >> > Hello Sreekanth,
> >> >> >
> >> >> > To me this sounds like something that should be implemented in the I/O
> >> >> > chipset on the motherboard. If you have a look at the Intel Software
> >> >> > Developer Manuals then you will see that logical destination mode 
> >> >> > supports
> >> >> > round-robin interrupt delivery. However, the Linux kernel selects 
> >> >> > physical
> >> >> > destination mode on systems with more than eight logical CPUs (see 
> >> >> > also
> >> >> > arch/x86/kernel/apic/apic_flat_64.c).
> >> >> >
> >> >> > I'm not sure the maintainers of the interrupt subsystem would welcome 
> >> >> > code
> >> >> > that emulates round-robin interrupt delivery. So your best option is
> >> >> > probably to minimize the amount of work that is done in interrupt 
> >> >> > context
> >> >> > and to move as much work as possible out of interrupt context in such 
> >> >> > a way
> >> >> > that it can be spread over multiple CPU cores, e.g. by using
> >> >> > queue_work_on().
> >> >> >
> >> >> > Bart.
> >> >>
> >> >> Bart,
> >> >>
> >> >> Thanks a lot for providing lot of inputs and valuable information on 
> >> >> this issue.
> >> >>
> >> >> Today I got one more observation. i.e. I am not observing any lockups
> >> >> if I use 1.0.4-6 versioned irqbalance.
> >> >> Since this versioned irqbalance is able to shift the load to other CPU
> >> >> when one CPU is heavily loaded.
> >> >>
> >> >
> >> > This isn't happening because irqbalance is no longer able to shift load 
> >> > between
> >> > cpus, its happening because of commit 
> >> > 996ee2cf7a4d10454de68ac4978adb5cf22850f8.
> >> > irqs with higher interrupt volumes sould be balanced to a specific cpu 
> >> > core,
> >> > rather than to a cache domain to maximize cpu-local cache hit rates.  
> >> > Prior to
> >> > that change we balanced to a cache domain and your workload didn't have 
> >> > to
> >> > serialize multiple interrupts to a single core.  My suggestion to you is 
> >> > to use
> >> > the --policyscript option to make your storage irqs get balanced to the 
> >> > 

Re: [REPOST PATCH 1/5] scsi: bnx2i: convert to kworker

[Johannes Thumshirn]

On Wed, Aug 17, 2016 at 12:09:59PM +0200, Sebastian Andrzej Siewior wrote:
> The driver creates its own per-CPU threads which are updated based on CPU
> hotplug events. It is also possible to use kworkers and remove some of the
> infrastructure get the same job done while saving a few lines of code.
> 
> The DECLARE_PER_CPU() definition is moved into the header file where it
> belongs. bnx2i_percpu_io_thread() becomes bnx2i_percpu_io_work() which is
> mostly the same code. The outer loop (kthread_should_stop()) gets removed and
> the remaining code is shifted to the left.
> bnx2i_queue_scsi_cmd_resp() is mostly the same. The code checked ->iothread to
> decide if there is an active per-CPU thread. With the kworkers this is no
> longer possible nor required.
> The allocation of struct bnx2i_work does not happen with ->p_work_lock held
> which is not required. I am unsure about the call-stack so I can't say
> if this qualifies it for the allocation with GFP_KERNEL instead of
> GFP_ATOMIC (it is not _bh lock but as I said, I don't know the context).
> The allocation case has been reversed so the inner if case is called on
> !bnx2i_work and is just the invocation one function since the lock is not
> held during allocation. The init of the new bnx2i_work struct is now
> done also without the ->p_work_lock held: it is a new object, nobody
> knows about it yet. It should be enough to hold the lock while adding
> this item to the list. I am unsure about that atomic_inc() so I keep
> things as they were.
> 
> The remaining part is the removal CPU hotplug notifier since it is taken
> care by the kworker code.
> 
> This patch was only compile-tested due to -ENODEV.
> 
> Cc: qlogic-storage-upstr...@qlogic.com
> Cc: Christoph Hellwig 
> Signed-off-by: Sebastian Andrzej Siewior 

I'm sorry it took so long but for the whole series:
Tested-by: Johannes Thumshirn 
Acked-by: Johannes Thumshirn 

Testing was conducted by booting from a QLogic BCM57840 CNA.

Johannes
-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 156321] mpt3sas timeout with xen, works only with mpt3sas.msix_disable=1 (SAS3008 card)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=156321

--- Comment #2 from john.wy...@gmx.de ---
Hi, Sreekanth!

I'm sorry - I was a bit too little specific:

The physical card in question is a "LSI 9300-8i". I took the SAS3008 from the
lspci output which I considered to be more generic.

The firmware in used is the latest available from
http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9300-8i#downloads
which is P12 from April 2016.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 156321] mpt3sas timeout with xen, works only with mpt3sas.msix_disable=1 (SAS3008 card)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=156321

Sreekanth Reddy  changed:

   What|Removed |Added

 CC||sreekanth.re...@broadcom.co
   ||m

--- Comment #1 from Sreekanth Reddy  ---
Hi John,

Can you please try once with latest Phase13 SAS3008 HBA firmware.

Thanks,
Sreekanth

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: introduce a quirk for false cache reporting

[Oliver Neukum]

On Thu, 2016-08-18 at 22:19 -0400, Martin K. Petersen wrote:
> > "Oliver" == Oliver Neukum  writes:
> 
> Oliver> Some SATA to USB bridges fail to cooperate with some drives
> Oliver> resulting in no cache being present being reported to the
> Oliver> host. That causes the host to skip sending a command to
> Oliver> synchronize caches. That causes data loss when the drive is
> Oliver> powered down.
> 
> Reviewed-by: Martin K. Petersen 
> 

Hi,

may I ask about the fate of this patch? Has it been lost?
Should I resubmit? Are any further changes necessary?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE

[Service Membre Zimbra]

Sua cota de webmail excedeu a cota, que é de 2 GB. Eles atualmente totalizaram 
2,3 GB.
Para reviver e aumentar a sua quota de correio web, clique no link a seguir ou 
copie o link para atualizar sua conta de e-mail da web
Para ativá-lo.

https://formcrafts.com/a/22734


Caso contrário, arrisca-se o cancelamento da sua conta de e-mail.
Obrigado e desculpe o inconveniente
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][SCSI] ufs: fix a wrong string in power mode change

[Kiwoong Kim]

From: Kiwoong Kim 

I modified a string as described in UFS spec as follow:
umpcrs -> upmcrs 

Signed-off-by: Kiwoong Kim 
---
 drivers/scsi/ufs/ufshcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b0ade73..e8a706b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2268,7 +2268,7 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, 
struct uic_command *cmd)
status = ufshcd_get_upmcrs(hba);
if (status != PWR_LOCAL) {
dev_err(hba->dev,
-   "pwr ctrl cmd 0x%0x failed, host umpcrs:0x%x\n",
+   "pwr ctrl cmd 0x%0x failed, host upmcrs:0x%x\n",
cmd->command, status);
ret = (status != PWR_OK) ? status : -1;
}
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Observing Softlockup's while running heavy IOs

[Sreekanth Reddy]

On Wed, Sep 7, 2016 at 6:54 PM, Neil Horman  wrote:
> On Wed, Sep 07, 2016 at 11:30:04AM +0530, Sreekanth Reddy wrote:
>> On Tue, Sep 6, 2016 at 8:36 PM, Neil Horman  wrote:
>> > On Tue, Sep 06, 2016 at 04:52:37PM +0530, Sreekanth Reddy wrote:
>> >> On Fri, Sep 2, 2016 at 4:34 AM, Bart Van Assche
>> >>  wrote:
>> >> > On 09/01/2016 03:31 AM, Sreekanth Reddy wrote:
>> >> >>
>> >> >> I reduced the ISR workload by one third in-order to reduce the time
>> >> >> that is spent per CPU in interrupt context, even then I am observing
>> >> >> softlockups.
>> >> >>
>> >> >> As I mentioned before only same single CPU in the set of CPUs(enabled
>> >> >> in affinity_hint) is busy with handling the interrupts from
>> >> >> corresponding IRQx. I have done below experiment in driver to limit
>> >> >> these softlockups/hardlockups. But I am not sure whether it is
>> >> >> reasonable to do this in driver,
>> >> >>
>> >> >> Experiment:
>> >> >> If the CPUx is continuously busy with handling the remote CPUs
>> >> >> (enabled in the corresponding IRQ's affinity_hint) IO works by 1/4th
>> >> >> of the HBA queue depth in the same ISR context then enable a flag
>> >> >> called 'change_smp_affinity' for this IRQ. Also created a thread with
>> >> >> will poll for this flag for every IRQ's (enabled by driver) for every
>> >> >> second. If this thread see that this flag is enabled for any IRQ then
>> >> >> it will write next CPU number from the CPUs enabled in the IRQ's
>> >> >> affinity_hint to the IRQ's smp_affinity procfs attribute using
>> >> >> 'call_usermodehelper()' API.
>> >> >>
>> >> >> This to make sure that interrupts are not processed by same single CPU
>> >> >> all the time and to make the other CPUs to handle the interrupts if
>> >> >> the current CPU is continuously busy with handling the other CPUs IO
>> >> >> interrupts.
>> >> >>
>> >> >> For example consider a system which has 8 logical CPUs and one MSIx
>> >> >> vector enabled (called IRQ 120) in driver, HBA queue depth as 8K.
>> >> >> then IRQ's procfs attributes will be
>> >> >> IRQ# 120, affinity_hint=0xff, smp_affinity=0x00
>> >> >>
>> >> >> After starting heavy IOs, we will observe that only CPU0 will be busy
>> >> >> with handling the interrupts. This experiment driver will change the
>> >> >> smp_affinity to next CPU number i.e. 0x01 (using cmd 'echo 0x01 >
>> >> >> /proc/irq/120/smp_affinity', driver issue's this cmd using
>> >> >> call_usermodehelper() API) if it observes that CPU0 is continuously
>> >> >> processing more than 2K of IOs replies of other CPUs i.e from CPU1 to
>> >> >> CPU7.
>> >> >>
>> >> >> Whether doing this kind of stuff in driver is ok?
>> >> >
>> >> >
>> >> > Hello Sreekanth,
>> >> >
>> >> > To me this sounds like something that should be implemented in the I/O
>> >> > chipset on the motherboard. If you have a look at the Intel Software
>> >> > Developer Manuals then you will see that logical destination mode 
>> >> > supports
>> >> > round-robin interrupt delivery. However, the Linux kernel selects 
>> >> > physical
>> >> > destination mode on systems with more than eight logical CPUs (see also
>> >> > arch/x86/kernel/apic/apic_flat_64.c).
>> >> >
>> >> > I'm not sure the maintainers of the interrupt subsystem would welcome 
>> >> > code
>> >> > that emulates round-robin interrupt delivery. So your best option is
>> >> > probably to minimize the amount of work that is done in interrupt 
>> >> > context
>> >> > and to move as much work as possible out of interrupt context in such a 
>> >> > way
>> >> > that it can be spread over multiple CPU cores, e.g. by using
>> >> > queue_work_on().
>> >> >
>> >> > Bart.
>> >>
>> >> Bart,
>> >>
>> >> Thanks a lot for providing lot of inputs and valuable information on this 
>> >> issue.
>> >>
>> >> Today I got one more observation. i.e. I am not observing any lockups
>> >> if I use 1.0.4-6 versioned irqbalance.
>> >> Since this versioned irqbalance is able to shift the load to other CPU
>> >> when one CPU is heavily loaded.
>> >>
>> >
>> > This isn't happening because irqbalance is no longer able to shift load 
>> > between
>> > cpus, its happening because of commit 
>> > 996ee2cf7a4d10454de68ac4978adb5cf22850f8.
>> > irqs with higher interrupt volumes sould be balanced to a specific cpu 
>> > core,
>> > rather than to a cache domain to maximize cpu-local cache hit rates.  
>> > Prior to
>> > that change we balanced to a cache domain and your workload didn't have to
>> > serialize multiple interrupts to a single core.  My suggestion to you is 
>> > to use
>> > the --policyscript option to make your storage irqs get balanced to the 
>> > cache
>> > level, rather than the core level.  That should return the behavior to 
>> > what you
>> > want.
>> >
>> > Neil
>>
>> Hi Neil,
>>
>> Thanks for reply.
>>
>> Today I tried with setting balance_level to 'cache' for mpt3sas driver
>> IRQ's using below policy script and used 1.0.9