Re: [PATCH RFC 1/2] scatterlist: add mempool based chained SG alloc/free api

[Ming Lin]

On Thu, Apr 7, 2016 at 9:43 AM, Ming Lin  wrote:
> On Thu, Apr 7, 2016 at 7:56 AM, Bart Van Assche
>  wrote:
>> On 03/15/16 15:39, Ming Lin wrote:
>>>
>>> +static void sg_mempoll_free(struct scatterlist *sgl, unsigned int nents)
>>
>>
>> Please change mempoll into mempool.
>
> Good catch. Thanks Bart!

Hi Bart,

This is actually the previous old RFC patch.
The v2 and v3 patch series doesn't have this typo.

Thanks.
--
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: Cant write to max_sectors_kb on 4.5.0 SRP target

[Nicholas A. Bellinger]

Hi Laurence,

On Thu, 2016-04-07 at 17:15 -0400, Laurence Oberman wrote:
> Hello
> 
> I have been testing the SRP initiator code to an LIO array here and
> part of the testing requires me to set the max_sectors_kb size to get
> 4k I/O's.
> This has been due to me having to debug various sg_map issues.
> 
> Linux srptest 4.5.0 #2 SMP Thu Apr 7 16:14:38 EDT 2016 x86_64 x86_64
> x86_64 GNU/Linux
> This kernel has the scan patch from Hannes, as well as the "[PATCH]
> IB/mlx5: Expose correct max_sge_rd limit" patch. 
> However, I also tested with vanilla 4.5.0 as well and its the same
> issue.
> 
> For some reason I cannot change the max_sectors_kb size on 4.5.0 here.
> 
> I chatted with Ewan about it as well and he reminded me about Martins
> changes so wondering if that's playing into this.
> 
> Take /dev/sdb as an example
> 
> [root@srptest queue]# sg_inq --p 0xb0 /dev/sdb
> VPD INQUIRY: Block limits page (SBC)
>   Maximum compare and write length: 1 blocks
>   Optimal transfer length granularity: 256 blocks
>   Maximum transfer length: 256 blocks
>   Optimal transfer length: 768 blocks
>   Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
> 

Just curious what target backend this is with..?

Specifically the optimal transfer length granularity and optimal
transfer length may be reported by underlying backend device (eg:
IBLOCK) in spc_emulate_evpd_b0(). 

What does 'head /sys/kernel/config/target/core/$HBA/$DEV/attrib/*'
of the backend device in question look like..?

--
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: Cant write to max_sectors_kb on 4.5.0 SRP target

[Martin K. Petersen]

> "Laurence" == Laurence Oberman  writes:

Laurence,

The target is reporting inconsistent values here:

> [root@srptest queue]# sg_inq --p 0xb0 /dev/sdb
> VPD INQUIRY: Block limits page (SBC)
>   Maximum compare and write length: 1 blocks
>   Optimal transfer length granularity: 256 blocks
>   Maximum transfer length: 256 blocks
>   Optimal transfer length: 768 blocks

OPTIMAL TRANSFER LENGTH GRANULARITY roughly translates to physical block
size or RAID chunk size. It's the smallest I/O unit that does not
require read-modify-write. It would typically be either 1 or 8 blocks
for a drive and maybe 64, 128 or 256 for a RAID5 array. io_min in
queue_limits.

OPTIMAL TRANSFER LENGTH indicates the stripe width and is a multiple of
OPTIMAL TRANSFER LENGTH GRANULARITY. io_opt in queue_limits.

MAXIMUM TRANSFER LENGTH indicates the biggest READ/WRITE command the
device can handle in a single command. In this case 256 blocks so that's
128K. max_dev_sectors in queue_limits.

>From SBC:

"A MAXIMUM TRANSFER LENGTH field set to a non-zero value indicates the
maximum transfer length in logical blocks that the device server accepts
for a single command shown in table 250. If a device server receives one
of these commands with a transfer size greater than this value, then the
device server shall terminate the command with CHECK CONDITION status
[...]"

So those reported values are off.

   logical block size <= physical block size <= OTLG <= OTL <= MTL

Or in terms of queue_limits:

   lbs <= pbs <= io_min <= io_opt <=
   min_not_zero(max_dev_sectors, max_hw_sectors, max_sectors)

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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: Cant write to max_sectors_kb on 4.5.0 SRP target

[Bart Van Assche]

On 04/07/16 14:16, Laurence Oberman wrote:

I have been testing the SRP initiator code to an LIO array here and

> part of the testing requires me to set the max_sectors_kb size to
> get 4k I/O's.
   .
Hello Laurence,

Have you already tried to set the max_sect parameter in 
/etc/srp_daemon.conf (assuming you are using srptools >= 1.0.3 for SRP 
login) ? Additionally, writing something like "options ib_srp 
cmd_sg_entries=255" into /etc/modprobe.d/ib_srp.conf will increase the 
maximum SRP transfer size.


Bart.
--
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

[no subject]

[contact]

nd of smlast
--
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 v2 8/8] scsi: ufs: connect to RPMB subsystem

[Winkler, Tomas]

On Wed, 2016-04-06 at 09:51 +0100, Joao Pinto wrote:
> Hi!
> 
> On 4/4/2016 12:11 PM, Tomas Winkler wrote:
> > Register UFS RPMB LUN with the RPMB subsystem and provide
> > implementation for the RPMB access operations. RPMB partition is
> > accessed via a sequence of security protocol in and security
> > protocol
> > out commands with UFS specific parameters. This multi step process
> > is
> > abstracted into 4 basic RPMB commands.
> 
> [snip]
> 
> >  * "UFS device" W-LU.
> >  */
> > struct scsi_device *sdev_ufs_device;
> > +   struct scsi_device *sdev_ufs_rpmb;
> >  
> > enum ufs_dev_pwr_mode curr_dev_pwr_mode;
> > enum uic_link_state uic_link_state;
> > 
> 
> I have a UFS device emulator that has the RPMB capability. What are
> the expected
> good results for me to validate?

Hi Joao, thanks for that. I'm attaching an archive with few basic
samples via user space interface. 
You should run the program key first (program-key.sh), just don't do it
on a real device it's one in life time operation. 

Thanks
Tomas

rpmb-scripts.tar.bz2
Description: rpmb-scripts.tar.bz2

Cant write to max_sectors_kb on 4.5.0 SRP target

[Laurence Oberman]

Hello

I have been testing the SRP initiator code to an LIO array here and part of the 
testing requires me to set the max_sectors_kb size to get 4k I/O's.
This has been due to me having to debug various sg_map issues.

Linux srptest 4.5.0 #2 SMP Thu Apr 7 16:14:38 EDT 2016 x86_64 x86_64 x86_64 
GNU/Linux
This kernel has the scan patch from Hannes, as well as the "[PATCH] IB/mlx5: 
Expose correct max_sge_rd limit" patch. 
However, I also tested with vanilla 4.5.0 as well and its the same issue.

For some reason I cannot change the max_sectors_kb size on 4.5.0 here.

I chatted with Ewan about it as well and he reminded me about Martins changes 
so wondering if that's playing into this.

Take /dev/sdb as an example

[root@srptest queue]# sg_inq --p 0xb0 /dev/sdb
VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 256 blocks
  Maximum transfer length: 256 blocks
  Optimal transfer length: 768 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks

[root@srptest queue]# sg_inq --p 0x83 /dev/sdb
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 20
designator_type: NAA,  code_set: Binary
associated with the addressed logical unit
  NAA 6, IEEE Company_id: 0x1405
  Vendor Specific Identifier: 0x3ec95b43d
  Vendor Specific Identifier Extension: 0xaf74871a5f1a0117
  [0x60014053ec95b43daf74871a5f1a0117]
  Designation descriptor number 2, descriptor length: 57
designator_type: T10 vendor identification,  code_set: ASCII
associated with the addressed logical unit
  vendor id: LIO-ORG
  vendor specific: block-1:3ec95b43-daf7-4871-a5f1-a0117ecc9c87
  Designation descriptor number 3, descriptor length: 8
transport: SCSI RDMA Protocol (SRP)
designator_type: Relative target port,  code_set: Binary
associated with the target port
  Relative target port: 0x2
  Designation descriptor number 4, descriptor length: 8
transport: SCSI RDMA Protocol (SRP)
designator_type: Target port group,  code_set: Binary
associated with the target port
  Target port group: 0x0
  Designation descriptor number 5, descriptor length: 8
designator_type: Logical unit group,  code_set: Binary
associated with the addressed logical unit
  Logical unit group: 0x0
  Designation descriptor number 6, descriptor length: 48
transport: SCSI RDMA Protocol (SRP)
designator_type: SCSI name string,  code_set: UTF-8
associated with the target port
  SCSI name string:
  0xfe807cfe900300726e4f,t,0x0001
  Designation descriptor number 7, descriptor length: 40
transport: SCSI RDMA Protocol (SRP)
designator_type: SCSI name string,  code_set: UTF-8
associated with the target device that contains addressed lu
  SCSI name string:
  0xfe807cfe900300726e4f

[root@srptest queue]# cat max_hw_sectors_kb max_sectors_kb
4096
1280
[root@srptest queue]# echo 4096 > max_sectors_kb
-bash: echo: write error: Invalid argument

The exact same targets served by the same array work fine when I test with the 
RHEL 7.2 kernel

Linux srptest 3.10.0-327.10.1.el7.bz1313814.x86_64 #1 SMP Fri Mar 11 14:10:52 
EST 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@srptest ~]# cd /sys/block/sdb/queue

cat max_hw_sectors_kb max_sectors_kb 
4096
512
echo 4096 > max_sectors_kb

cat max_hw_sectors_kb max_sectors_kb
4096
4096

[root@srptest ~]# sg_inq --p 0xb0 /dev/sdb
VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 256 blocks
  Maximum transfer length: 256 blocks
  Optimal transfer length: 768 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks

This is an SRP device served by LVM via target LIO on my SRp target server

[root@srptest ~]# sg_inq --p 0x83 /dev/sdb
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 20
designator_type: NAA,  code_set: Binary
associated with the addressed logical unit
  NAA 6, IEEE Company_id: 0x1405
  Vendor Specific Identifier: 0x3ec95b43d
  Vendor Specific Identifier Extension: 0xaf74871a5f1a0117
  [0x60014053ec95b43daf74871a5f1a0117]
  Designation descriptor number 2, descriptor length: 57
designator_type: T10 vendor identification,  code_set: ASCII
associated with the addressed logical unit
  vendor id: LIO-ORG
  vendor specific: block-1:3ec95b43-daf7-4871-a5f1-a0117ecc9c87
  Designation descriptor number 3, descriptor length: 8
transport: SCSI RDMA Protocol (SRP)
designator_type: Relative target port,  code_set: Binary
associated with the target port
  Relative target port: 0x1
  Designation descriptor number 4, descriptor length: 8
transport: SCSI RDMA Protocol (SRP)
designator_type: Target port group,  code_set: Binary
associated with the target port
  Target port group: 0x0
  Designation descriptor 

[PATCH v3] mvsas: Generalize Marvell 9485 in pci_device_id

[Leonid Moiseichuk]

For generic subvendor has sense to use generic subdevice.
If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.

Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

v3: add comment and changelog according to Andy's findings
v2: re-phrased commit message

Signed-off-by: Leonid Moiseichuk 
Reviewed-by: Andy Shevchenko 
---
 drivers/scsi/mvsas/mv_init.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index c7c250519c4b..8280046fd1f0 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9445,
},
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9480,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9485,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
+   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 }, /* Marvell 9480/9485 
(any vendor/model) */
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
-- 
2.8.0.rc3

--
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 114401] crash dump aic94xx

[bugzilla-daemon]

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

--- Comment #3 from bastienphilb...@gmail.com ---
That seems to be due to a WARN_ON that only triggers once. Does this work OK
now besides the warning.

-- 
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 v2] mvsas: Generalize Marvell 9485 in pci_device_id

[Andy Shevchenko]

On Thu, Apr 7, 2016 at 8:06 PM, Leonid Moiseichuk
 wrote:
> For generic subvendor has sense to use generic subdevice.
> If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.
>
> Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

Minors below.

FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Leonid Moiseichuk 
> ---

Missed changelog vfrom v1 to v2.

>  drivers/scsi/mvsas/mv_init.c | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index c7c250519c4b..a6a4f09df0be 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
> .class_mask = 0,
> .driver_data= chip_9445,
> },
> -   {
> -   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> -   .device = 0x9485,
> -   .subvendor  = PCI_ANY_ID,
> -   .subdevice  = 0x9480,
> -   .class  = 0,
> -   .class_mask = 0,
> -   .driver_data= chip_9485,
> -   },
> -   {
> -   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> -   .device = 0x9485,
> -   .subvendor  = PCI_ANY_ID,
> -   .subdevice  = 0x9485,
> -   .class  = 0,
> -   .class_mask = 0,
> -   .driver_data= chip_9485,
> -   },
> +   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },

+ commentary line?

... /* MARVELL bla-bla-bla */

> { PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
> { PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
> (exact model unknown) */
> { PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
> (exact model unknown) */
> --
> 2.8.0.rc3
>
> --
> 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



-- 
With Best Regards,
Andy Shevchenko
--
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 v2] mvsas: Generalize Marvell 9485 in pci_device_id

[Leonid Moiseichuk]

For generic subvendor has sense to use generic subdevice.
If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated.

Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

Signed-off-by: Leonid Moiseichuk 
---
 drivers/scsi/mvsas/mv_init.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index c7c250519c4b..a6a4f09df0be 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -704,24 +704,7 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9445,
},
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9480,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
-   {
-   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
-   .device = 0x9485,
-   .subvendor  = PCI_ANY_ID,
-   .subdevice  = 0x9485,
-   .class  = 0,
-   .class_mask = 0,
-   .driver_data= chip_9485,
-   },
+   { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
-- 
2.8.0.rc3

--
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 114401] crash dump aic94xx

[bugzilla-daemon]

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

Bulanov Maxim  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #2 from Bulanov Maxim  ---
Thank you, look like this help me. I not get crash more, just error.

[ 1193.833040] sas: Enter sas_scsi_recover_host busy: 1 failed: 1
[ 1193.833047] sas: trying to find task 0x8800bb0e7700
[ 1193.833049] sas: sas_scsi_find_task: aborting task 0x8800bb0e7700
[ 1193.833153] sas: sas_scsi_find_task: querying task 0x8800bb0e7700
[ 1193.833155] sas: sas_scsi_find_task: aborting task 0x8800bb0e7700
[ 1193.833247] sas: sas_scsi_find_task: querying task 0x8800bb0e7700
[ 1193.833249] sas: sas_scsi_find_task: aborting task 0x8800bb0e7700
[ 1193.833350] sas: sas_scsi_find_task: querying task 0x8800bb0e7700
[ 1193.833355] sas: sas_scsi_find_task: aborting task 0x8800bb0e7700
[ 1193.833456] sas: sas_scsi_find_task: querying task 0x8800bb0e7700
[ 1193.833458] sas: sas_scsi_find_task: aborting task 0x8800bb0e7700
[ 1193.833554] sas: sas_scsi_find_task: querying task 0x8800bb0e7700
[ 1193.833556] sas: task 0x8800bb0e7700 is not at LU: I_T recover
[ 1193.833558] sas: I_T nexus reset for dev 5003048000257da6
[ 1194.334256] sas: I_T 5003048000257da6 recovered
[ 1194.334279] sas: ata7: end_device-6:0: dev error handler
[ 1194.334291] sas: ata8: end_device-6:1: dev error handler
[ 1194.334297] sas: ata9: end_device-6:2: dev error handler
[ 1194.334301] sas: ata10: end_device-6:3: dev error handler
[ 1194.334307] sas: ata11: end_device-6:4: dev error handler
[ 1194.334314] sas: ata12: end_device-6:5: dev error handler
[ 1194.334315] sas: ata13: end_device-6:6: dev error handler
[ 1194.334322] sas: ata14: end_device-6:7: dev error handler
[ 1194.334327] ata14.00: retrying FLUSH 0xea Emask 0x0

-- 
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 v12 8/9] add TC G210 platform driver

[Rob Herring]

On Mon, Apr 04, 2016 at 11:48:23AM +0100, Joao Pinto wrote:
> 
> Hi Rob,
> 
> On 4/4/2016 6:15 AM, Rob Herring wrote:
> > On Thu, Mar 31, 2016 at 07:57:21PM +0100, Joao Pinto wrote:
> >> This patch adds a glue platform driver for the Synopsys G210 Test Chip.
> >>
> >> Signed-off-by: Joao Pinto 
> >> ---
> 
> [snip]
> 
> >> +
> >> +Required properties:
> >> +- compatible  : compatible list must contain the PHY type & version:
> >> +  "snps, g210-tc-6.00-20bit"
> >> +  "snps, g210-tc-6.00-40bit"
> > Remove the space  ^
> > 
> >> +complemented with the Controller IP version:
> >> +  "snps, dwc-ufshcd-1.40a"
> > 
> > ditto
> 
> Ok, will do that!
> 
> > 
> > Combining the phy and controller compatible strings is a bit strange. 
> > Generally, they would be separate nodes using the common phy binding.
> > 
> 
> Correct, but in this case is just the compatibility string is just to tell the
> dw ufs host that it has a 40-bit or a 20-bit test chip connected. The Test 
> chip
> is initialized by a unipro command sequence and there is no more ops related 
> to it.

Okay. In that case, I think it should be a separate property unless the 
controller h/w is synthesized for one or the other.

Rob
--
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 RFC 1/2] scatterlist: add mempool based chained SG alloc/free api

[Ming Lin]

On Thu, Apr 7, 2016 at 7:56 AM, Bart Van Assche
 wrote:
> On 03/15/16 15:39, Ming Lin wrote:
>>
>> +static void sg_mempoll_free(struct scatterlist *sgl, unsigned int nents)
>
>
> Please change mempoll into mempool.

Good catch. Thanks Bart!
--
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: LSF/MM Schedule and improving discard support

[James Bottomley]

On Thu, 2016-04-07 at 08:39 -0700, Bart Van Assche wrote:
> Hello James,
> 
> Some time ago I proposed to discuss how to improve discard support 
> during the LSF/MM (http://thread.gmane.org/gmane.linux.scsi/110048). 
> I would appreciate it if this would be added to the LSF/MM agenda 
> since there has been no progress yet for the patch series I posted in
> December 2015.

Well, adding a cc to the lsf@ list to interest the attendees might have
been a good idea.

The basic problem with this topic is that it didn't really garner any
interest when you proposed it.  It also really just looks like there's
nothing to discuss: you just propose the unifying patch and people
discuss and modify that and it either gets accepted or not depending on
the level of the objections.

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

LSF/MM Schedule and improving discard support

[Bart Van Assche]

Hello James,

Some time ago I proposed to discuss how to improve discard support 
during the LSF/MM (http://thread.gmane.org/gmane.linux.scsi/110048). I 
would appreciate it if this would be added to the LSF/MM agenda since 
there has been no progress yet for the patch series I posted in December 
2015.


Thanks,

Bart.
--
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: [RFC PATCH 0/4] dm mpath: vastly improve blk-mq IO performance

[Mike Snitzer]

On Thu, Apr 07 2016 at 10:58am -0400,
Hannes Reinecke  wrote:

> On 03/31/2016 10:04 PM, Mike Snitzer wrote:
> > I developed these changes some weeks ago but have since focused on
> > regression and performance testing on larger NUMA systems.
> > 
> > For regression testing I've been using mptest:
> > https://github.com/snitm/mptest
> > 
> > For performance testing I've been using a null_blk device (with
> > various configuration permutations, e.g. pinning memory to a
> > particular NUMA node, and varied number of submit_queues).
> > 
> > By eliminating multipath's heavy use of the m->lock spinlock in the
> > fast IO paths serious performance improvements are realized.
> > 
> [ .. ]
> > Jeff Moyer has been helping review these changes (and has graciously
> > labored over _really_ understanding all the concurrency at play in DM
> > mpath) -- his review isn't yet complete but I wanted to get this
> > patchset out now to raise awareness about how I think DM multipath
> > will be changing (for inclussion during the Linux 4.7 merge window).
> > 
> > Mike Snitzer (4):
> >   dm mpath: switch to using bitops for state flags
> >   dm mpath: use atomic_t for counting members of 'struct multipath'
> >   dm mpath: move trigger_event member to the end of 'struct multipath'
> >   dm mpath: eliminate use of spinlock in IO fast-paths
> > 
> >  drivers/md/dm-mpath.c | 351 
> > --
> >  1 file changed, 195 insertions(+), 156 deletions(-)
> > 
> Finally got around to test this.
> The performance is comparable to the previous (RCU-ified) patchset,
> however, this one is the far superious approach.
> In fact, the first two are pretty much identical to what I've
> already had, but I've shirked at modifying the path selectors.
> So well done here.

Awesome, thanks for reviewing and testing, very much appreciated.

I'll get this set staged in linux-next for 4.7 shortly.
--
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: [RFC PATCH 3/4] dm mpath: move trigger_event member to the end of 'struct multipath'

[Hannes Reinecke]

On 03/31/2016 10:04 PM, Mike Snitzer wrote:
> Allows the 'work_mutex' member to no longer cross a cacheline.
> 
> Signed-off-by: Mike Snitzer 
> ---
>  drivers/md/dm-mpath.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
> index 780e5d0..54daf96 100644
> --- a/drivers/md/dm-mpath.c
> +++ b/drivers/md/dm-mpath.c
> @@ -89,8 +89,6 @@ struct multipath {
>   atomic_t pg_init_in_progress;   /* Only one pg_init allowed at once */
>   atomic_t pg_init_count; /* Number of times pg_init called */
>  
> - struct work_struct trigger_event;
> -
>   /*
>* We must use a mempool of dm_mpath_io structs so that we
>* can resubmit bios on error.
> @@ -98,6 +96,7 @@ struct multipath {
>   mempool_t *mpio_pool;
>  
>   struct mutex work_mutex;
> + struct work_struct trigger_event;
>  };
>  
>  /*
> 
Reviewed-by: Hannes Reinecke 
Tested-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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: [RFC PATCH 4/4] dm mpath: eliminate use of spinlock in IO fast-paths

[Hannes Reinecke]

On 03/31/2016 10:04 PM, Mike Snitzer wrote:
> The primary motivation of this commit is to improve the scalability of
> DM multipath on large NUMA systems where m->lock spinlock contention has
> been proven to be a serious bottleneck on really fast storage.
> 
> The ability to atomically read a pointer, using lockless_dereference(),
> is leveraged in this commit.  But all pointer writes are still protected
> by the m->lock spinlock (which is fine since these all now occur in the
> slow-path).
> 
> The following functions no longer require the m->lock spinlock in their
> fast-path: multipath_busy(), __multipath_map(), and do_end_io()
> 
> And choose_pgpath() is modified to _not_ update m->current_pgpath unless
> it also switches the path-group.  This is done to avoid needing to take
> the m->lock everytime __multipath_map() calls choose_pgpath().
> But m->current_pgpath will be reset if it is failed via fail_path().
> 
> Suggested-by: Jeff Moyer 
> Signed-off-by: Mike Snitzer 
> ---
>  drivers/md/dm-mpath.c | 170 
> +++---
>  1 file changed, 93 insertions(+), 77 deletions(-)
> 
I really like this :-)

Reviewed-by: Hannes Reinecke 
Tested-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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: [RFC PATCH 2/4] dm mpath: use atomic_t for counting members of 'struct multipath'

[Hannes Reinecke]

On 03/31/2016 10:04 PM, Mike Snitzer wrote:
> The use of atomic_t for nr_valid_paths, pg_init_in_progress and
> pg_init_count will allow relaxing the use of the m->lock spinlock.
> 
> Suggested-by: Hannes Reinecke 
> Signed-off-by: Mike Snitzer 
> ---
>  drivers/md/dm-mpath.c | 61 
> ---
>  1 file changed, 33 insertions(+), 28 deletions(-)
> 
Reviewed-by: Hannes Reinecke 
Tested-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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: [RFC PATCH 1/4] dm mpath: switch to using bitops for state flags

[Hannes Reinecke]

On 03/31/2016 10:04 PM, Mike Snitzer wrote:
> Mechanical change that doesn't make any real effort to reduce the use of
> m->lock; that will come later (once atomics are used for counters, etc).
> 
> Suggested-by: Hannes Reinecke 
> Signed-off-by: Mike Snitzer 
> ---
>  drivers/md/dm-mpath.c | 131 
> +-
>  1 file changed, 75 insertions(+), 56 deletions(-)
> 
Reviewed-by: Hannes Reinecke 
Tested-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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: [RFC PATCH 0/4] dm mpath: vastly improve blk-mq IO performance

[Hannes Reinecke]

On 03/31/2016 10:04 PM, Mike Snitzer wrote:
> I developed these changes some weeks ago but have since focused on
> regression and performance testing on larger NUMA systems.
> 
> For regression testing I've been using mptest:
> https://github.com/snitm/mptest
> 
> For performance testing I've been using a null_blk device (with
> various configuration permutations, e.g. pinning memory to a
> particular NUMA node, and varied number of submit_queues).
> 
> By eliminating multipath's heavy use of the m->lock spinlock in the
> fast IO paths serious performance improvements are realized.
> 
[ .. ]
> Jeff Moyer has been helping review these changes (and has graciously
> labored over _really_ understanding all the concurrency at play in DM
> mpath) -- his review isn't yet complete but I wanted to get this
> patchset out now to raise awareness about how I think DM multipath
> will be changing (for inclussion during the Linux 4.7 merge window).
> 
> Mike Snitzer (4):
>   dm mpath: switch to using bitops for state flags
>   dm mpath: use atomic_t for counting members of 'struct multipath'
>   dm mpath: move trigger_event member to the end of 'struct multipath'
>   dm mpath: eliminate use of spinlock in IO fast-paths
> 
>  drivers/md/dm-mpath.c | 351 
> --
>  1 file changed, 195 insertions(+), 156 deletions(-)
> 
Finally got around to test this.
The performance is comparable to the previous (RCU-ified) patchset,
however, this one is the far superious approach.
In fact, the first two are pretty much identical to what I've
already had, but I've shirked at modifying the path selectors.
So well done here.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 RFC 1/2] scatterlist: add mempool based chained SG alloc/free api

[Bart Van Assche]

On 03/15/16 15:39, Ming Lin wrote:

+static void sg_mempoll_free(struct scatterlist *sgl, unsigned int nents)


Please change mempoll into mempool.

Thanks,

Bart.

--
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 v2 4/5] bnx2fc: Check sc_cmd device and host pointer before returning the command to the mid-layer.

[Johannes Thumshirn]

On Donnerstag, 7. April 2016 09:07:59 CEST Chad Dupuis wrote:
> When we are in connection recovery and the internal command timer on a
> request pops, either the scsi_cmnd->device or scsi_cmnd->device->host back
> pointers may be NULL as the device that the command that the request was
> submitted on may have been subsequently reaped due to the connection
> recovery. This can cause one or both of the pointers above to be NULL and
> cause a system crash if we try to return the command to the midlayer.
> 
> Instead, double check the pointers before the return to the midlayer so as
> to prevent the crash and let the upper layers finish the session recovery
> and rediscover the device.
> 
> Signed-off-by: Chad Dupuis 
> ---

Reviewed-by: Johannes Thumshirn 

-- 
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

Re: [PATCH v2 5/5] bnx2fc: Update version number to 2.10.3.

[Johannes Thumshirn]

On Donnerstag, 7. April 2016 09:08:00 CEST Chad Dupuis wrote:
> Signed-off-by: Chad Dupuis 
> ---

Reviewed-by: Johannes Thumshirn 

-- 
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

Re: [PATCH v2 3/5] bnx2fc: Print netdev device name when FCoE is successfully initialized.

[Johannes Thumshirn]

On Donnerstag, 7. April 2016 09:07:58 CEST Chad Dupuis wrote:
> Signed-off-by: Chad Dupuis 
> ---

Reviewed-by: Johannes Thumshirn 

-- 
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

Re: [PATCH v2 2/5] bnx2fc: Print when we send a fip keep alive.

[Johannes Thumshirn]

On Donnerstag, 7. April 2016 09:07:57 CEST Chad Dupuis wrote:
> Signed-off-by: Chad Dupuis 
> ---

Reviewed-by: Johannes Thumshirn 

-- 
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

Re: [PATCH v2 1/5] bnx2fc: Add driver tunables.

[Johannes Thumshirn]

On Donnerstag, 7. April 2016 09:07:56 CEST Chad Dupuis wrote:
> From: Joe Carnuccio 
> 
> Per customer request, add the following driver tunables:
> 
> o devloss_tmo
> o max_luns
> o queue_depth
> o tm_timeout
> 
> tm_timeout is set per scsi_host in /sys/class/scsi_host/hostX/tm_timeout.
> 
> Signed-off-by: Joe Carnuccio 
> Signed-off-by: Chad Dupuis 
> ---

Looks good to me,
Reviewed-by: Johannes Thumshirn 

-- 
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

[PATCH v2 5/5] bnx2fc: Update version number to 2.10.3.

[Chad Dupuis]

Signed-off-by: Chad Dupuis 
---
 drivers/scsi/bnx2fc/bnx2fc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index 106788f..fdd4eb4 100644
--- a/drivers/scsi/bnx2fc/bnx2fc.h
+++ b/drivers/scsi/bnx2fc/bnx2fc.h
@@ -65,7 +65,7 @@
 #include "bnx2fc_constants.h"
 
 #define BNX2FC_NAME"bnx2fc"
-#define BNX2FC_VERSION "2.9.6"
+#define BNX2FC_VERSION "2.10.3"
 
 #define PFX"bnx2fc: "
 
-- 
2.0.0.rc0.26.g779792a

--
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 v2 4/5] bnx2fc: Check sc_cmd device and host pointer before returning the command to the mid-layer.

[Chad Dupuis]

When we are in connection recovery and the internal command timer on a request
pops, either the scsi_cmnd->device or scsi_cmnd->device->host back pointers may
be NULL as the device that the command that the request was submitted on may
have been subsequently reaped due to the connection recovery. This can cause
one or both of the pointers above to be NULL and cause a system crash if we try
to return the command to the midlayer.

Instead, double check the pointers before the return to the midlayer so as to
prevent the crash and let the upper layers finish the session recovery and
rediscover the device.

Signed-off-by: Chad Dupuis 
---
 drivers/scsi/bnx2fc/bnx2fc_io.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index ac8fb2a..25a1e19 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -179,12 +179,24 @@ static void bnx2fc_scsi_done(struct bnx2fc_cmd *io_req, 
int err_code)
 
bnx2fc_unmap_sg_list(io_req);
io_req->sc_cmd = NULL;
+
+   /* Sanity checks before returning command to mid-layer */
if (!sc_cmd) {
printk(KERN_ERR PFX "scsi_done - sc_cmd NULL. "
"IO(0x%x) already cleaned up\n",
   io_req->xid);
return;
}
+   if (!sc_cmd->device) {
+   pr_err(PFX "0x%x: sc_cmd->device is NULL.\n", io_req->xid);
+   return;
+   }
+   if (!sc_cmd->device->host) {
+   pr_err(PFX "0x%x: sc_cmd->device->host is NULL.\n",
+   io_req->xid);
+   return;
+   }
+
sc_cmd->result = err_code << 16;
 
BNX2FC_IO_DBG(io_req, "sc=%p, result=0x%x, retries=%d, allowed=%d\n",
-- 
2.0.0.rc0.26.g779792a

--
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 v2 2/5] bnx2fc: Print when we send a fip keep alive.

[Chad Dupuis]

Signed-off-by: Chad Dupuis 
---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index b0305b0..365101a 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -122,6 +122,11 @@ module_param_named(queue_depth, bnx2fc_queue_depth, uint, 
S_IRUGO);
 MODULE_PARM_DESC(queue_depth, " Change the default queue depth of SCSI devices 
"
"attached via bnx2fc.");
 
+uint bnx2fc_log_fka;
+module_param_named(log_fka, bnx2fc_log_fka, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(log_fka, " Print message to kernel log when fcoe is "
+   "initiating a FIP keep alive when debug logging is enabled.");
+
 static int bnx2fc_cpu_callback(struct notifier_block *nfb,
 unsigned long action, void *hcpu);
 /* notification function for CPU hotplug events */
@@ -1076,6 +1081,20 @@ static u8 *bnx2fc_get_src_mac(struct fc_lport *lport)
  */
 static void bnx2fc_fip_send(struct fcoe_ctlr *fip, struct sk_buff *skb)
 {
+   struct fip_header *fiph;
+   struct ethhdr *eth_hdr;
+   u16 op;
+   u8 sub;
+
+   fiph = (struct fip_header *) ((void *)skb->data + 2 * ETH_ALEN + 2);
+   eth_hdr = (struct ethhdr *)skb_mac_header(skb);
+   op = ntohs(fiph->fip_op);
+   sub = fiph->fip_subcode;
+
+   if (op == FIP_OP_CTRL && sub == FIP_SC_SOL && bnx2fc_log_fka)
+   BNX2FC_MISC_DBG("Sending FKA from %pM to %pM.\n",
+   eth_hdr->h_source, eth_hdr->h_dest);
+
skb->dev = bnx2fc_from_ctlr(fip)->netdev;
dev_queue_xmit(skb);
 }
-- 
2.0.0.rc0.26.g779792a

--
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 v2 0/5] bnx2fc: Update driver to version 2.10.3.

[Chad Dupuis]

Hi James, Martin,

Please apply the patch series for the next merge window at your earliest
convenience.

V2 changes:

- Made netdev device name print pr_info instead of pr_err.
- Made TMF timeout settable via sysfs node instead of modparam.

Thanks,
Chad

Chad Dupuis (4):
  bnx2fc: Print when we send a fip keep alive.
  bnx2fc: Print netdev device name when FCoE is successfully
initialized.
  bnx2fc: Check sc_cmd device and host pointer before returning the
command to the mid-layer.
  bnx2fc: Update version number to 2.10.3.

Joe Carnuccio (1):
  bnx2fc: Add driver tunables.

 drivers/scsi/bnx2fc/bnx2fc.h  |   3 +-
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 100 +-
 drivers/scsi/bnx2fc/bnx2fc_io.c   |  14 +-
 3 files changed, 114 insertions(+), 3 deletions(-)

-- 
2.0.0.rc0.26.g779792a

--
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 v2 3/5] bnx2fc: Print netdev device name when FCoE is successfully initialized.

[Chad Dupuis]

Signed-off-by: Chad Dupuis 
---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 365101a..a188199 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -2039,6 +2039,8 @@ static void bnx2fc_ulp_init(struct cnic_dev *dev)
return;
}
 
+   pr_info(PFX "FCoE initialized for %s.\n", dev->netdev->name);
+
/* Add HBA to the adapter list */
mutex_lock(_dev_lock);
list_add_tail(>list, _list);
-- 
2.0.0.rc0.26.g779792a

--
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 10/12] Limit bio_endio recursion

[Ming Lei]

On Thu, Apr 7, 2016 at 1:44 PM, Ming Lei  wrote:
> On Thu, 7 Apr 2016 11:54:49 +0800
> Ming Lei  wrote:
>

> @@ -1737,6 +1739,46 @@ static inline bool bio_remaining_done(struct bio *bio)
> return false;
>  }
>
> +/* disable local irq when manipulating the percpu bio_list */
> +static void unwind_bio_endio(struct bio *bio)
> +{
> +   struct bio_list bl_in_stack;
> +   struct bio_list *bl;
> +   unsigned long flags;
> +   bool clear_list = false;
> +
> +   local_irq_save(flags);
> +
> +   bl = this_cpu_read(bio_end_list);
> +   if (!bl) {
> +   bl = _in_stack;
> +   bio_list_init(bl);
> +   clear_list = true;

oops, forget to write the pointer into the percpu bio_list pointer.
But it is still working after I fix that by the following line:

 this_cpu_write(bio_end_list, bl);

thanks,
--
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