On Fri, Feb 15, 2019 at 8:35 AM Hannes Reinecke wrote:
>
> On 2/12/19 11:42 PM, Nathan Chancellor wrote:
> > On Tue, Feb 12, 2019 at 08:50:04AM +0100, Sedat Dilek wrote:
> >> On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor
> >> wrote:
> >>>
> >>> On Mon, Feb 11, 2019 at 06:07:51PM +0100, Sedat
On Fri, Feb 15, 2019 at 07:55:39AM +0100, Hannes Reinecke wrote:
>> Yeah, there is a few more. And the sad part is as of a few kernel
>> release ago we shouldn't even need the fallback 32-bit dma mask
>> anymore - we've cleaned up all the mess that required it.
>>
> Care to elaborate?
> Can you po
Signed-off-by is like a legal document to say that you haven't added
any proprietary SCO UNIXWARE code to the patch. You have sign every
patch if you email it.
Acked-by and Reviewed-by are less clear. Acked-by means you want it
to be merged, I guess? I never use Acked by because I'm not a
maint
Looks good,
Reviewed-by: Christoph Hellwig
Driver uses "reply descriptor post queues" in round robin
fashion so that IO's are distributed to all the available
reply descriptor post queues equally.
With this each reply descriptor post queue load is balanced.
This is enabled only if CPUs count to MSI-X vector
count ratio is X:1 (where X > 1)
In patch 4, driver uses irq poll, select it to
avoid below build error.
ERROR: "irq_poll_init" [drivers/scsi/mpt3sas/mpt3sas.ko] undefined!
ERROR: "irq_poll_enable" [drivers/scsi/mpt3sas/mpt3sas.ko] undefined!
ERROR: "irq_poll_sched" [drivers/scsi/mpt3sas/mpt3sas.ko] undefined!
ERROR: "irq_poll_di
We have seen cpu lock up issue from fields if
system has greater (more than 96) logical cpu count.
SAS3.0 controller (Invader series) supports at
max 96 msix vector and SAS3.5 product (Ventura)
supports at max 128 msix vectors.
This may be a generic issue (if PCI device support
completion on multi
* Reduce the threshold value to 1/4 of the queue depth.
* With this FW can find enough entries to post the Reply
Descriptors in the reply descriptor post queue.
* With module param, user can play with threshold value,
the same irqpoll_weight is used as the budget in processing
of reply descriptor p
Fixed typo in request_desript_type.
request_desript_type --> request_descript_type.
Signed-off-by: Suganath Prabu
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt
Separate out processing of reply descriptor post queue
from _base_interrupt to _base_process_reply_queue.
Signed-off-by: Suganath Prabu
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 49 +
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi
Updated driver version to 28.100.00.00,
which is equivalent to OOB Ph9
Signed-off-by: Suganath Prabu
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index
Issue Discription:
We have seen cpu lock up issue from fields if
system has greater (more than 96) logical cpu count.
SAS3.0 controller (Invader series) supports at
max 96 msix vector and SAS3.5 product (Ventura)
supports at max 128 msix vectors.
This may be a generic issue (if PCI device support
On 2/12/19 11:42 PM, Nathan Chancellor wrote:
On Tue, Feb 12, 2019 at 08:50:04AM +0100, Sedat Dilek wrote:
On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor
wrote:
On Mon, Feb 11, 2019 at 06:07:51PM +0100, Sedat Dilek wrote:
From: Sedat Dilek
commit 1917d42d14b7 ("fcoe: use enum for fip_mo
On 1/31/19 1:42 AM, James Bottomley wrote:
The aic94xx driver is currently failing to load with errors like
sysfs: cannot create duplicate filename
'/devices/pci:00/:00:03.0/:02:00.3/:07:02.0/revision'
Because the PCI code had recently added a file named 'revision' to
every PCI
On 2/14/19 10:57 PM, Martin Wilck wrote:
Up to 4.12, __scsi_error_from_host_byte() would reset the host
byte to DID_OK for various cases including DID_NEXUS_FAILURE.
Commit 2a842acab109 ("block: introduce new block status code type")
replaced this function with scsi_result_to_blk_status() and rem
On 2/14/19 6:31 PM, Christoph Hellwig wrote:
On Thu, Feb 14, 2019 at 09:29:05AM +, John Garry wrote:
On 13/02/2019 18:51, Ewan D. Milne wrote:
On Wed, 2019-02-13 at 12:42 +0100, Hannes Reinecke wrote:
The recent patchset to use dma_set_mask_and_coherent() introduced
a regression where a ca
Good, I had a quick test and the issue is fixed, thanks.
Reviewed-by: Jason Yan
From: "Ewan D. Milne"
[ Upstream commit c41f59884be5cca293ed61f3d64637dbba3a6381 ]
We cannot wait on a completion object in the lpfc_nvme_targetport structure
in the _destroy_targetport() code path because the NVMe/fc transport will
free that structure immediately after the .targetport_delete()
From: "Ewan D. Milne"
[ Upstream commit 7961cba6f7d8215fa632df3d220e5154bb825249 ]
We cannot wait on a completion object in the lpfc_nvme_lport structure in
the _destroy_localport() code path because the NVMe/fc transport will free
that structure immediately after the .localport_delete() callbac
From: Varun Prakash
[ Upstream commit fe35a40e675473eb65f2f5462b82770f324b5689 ]
Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to
avoid a NULL pointer dereference in csio_vport_set_state().
ln->fc_vport is dereferenced in csio_vport_set_state().
Signed-off-by: Varun Prak
From: "Ewan D. Milne"
[ Upstream commit c41f59884be5cca293ed61f3d64637dbba3a6381 ]
We cannot wait on a completion object in the lpfc_nvme_targetport structure
in the _destroy_targetport() code path because the NVMe/fc transport will
free that structure immediately after the .targetport_delete()
From: "Ewan D. Milne"
[ Upstream commit 7961cba6f7d8215fa632df3d220e5154bb825249 ]
We cannot wait on a completion object in the lpfc_nvme_lport structure in
the _destroy_localport() code path because the NVMe/fc transport will free
that structure immediately after the .localport_delete() callbac
From: Varun Prakash
[ Upstream commit fe35a40e675473eb65f2f5462b82770f324b5689 ]
Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to
avoid a NULL pointer dereference in csio_vport_set_state().
ln->fc_vport is dereferenced in csio_vport_set_state().
Signed-off-by: Varun Prak
From: Varun Prakash
[ Upstream commit fe35a40e675473eb65f2f5462b82770f324b5689 ]
Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to
avoid a NULL pointer dereference in csio_vport_set_state().
ln->fc_vport is dereferenced in csio_vport_set_state().
Signed-off-by: Varun Prak
From: Varun Prakash
[ Upstream commit fe35a40e675473eb65f2f5462b82770f324b5689 ]
Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to
avoid a NULL pointer dereference in csio_vport_set_state().
ln->fc_vport is dereferenced in csio_vport_set_state().
Signed-off-by: Varun Prak
From: Varun Prakash
[ Upstream commit fe35a40e675473eb65f2f5462b82770f324b5689 ]
Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to
avoid a NULL pointer dereference in csio_vport_set_state().
ln->fc_vport is dereferenced in csio_vport_set_state().
Signed-off-by: Varun Prak
From: Varun Prakash
[ Upstream commit fe35a40e675473eb65f2f5462b82770f324b5689 ]
Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to
avoid a NULL pointer dereference in csio_vport_set_state().
ln->fc_vport is dereferenced in csio_vport_set_state().
Signed-off-by: Varun Prak
Up to 4.12, __scsi_error_from_host_byte() would reset the host
byte to DID_OK for various cases including DID_NEXUS_FAILURE.
Commit 2a842acab109 ("block: introduce new block status code type")
replaced this function with scsi_result_to_blk_status() and removed
the host-byte resetting code for the D
On Thu, 2019-02-14 at 13:19 -0800, James Smart wrote:
>
> On 2/14/2019 11:39 AM, James Bottomley wrote:
> > On Thu, 2019-02-14 at 10:52 -0800, James Smart wrote:
> > > On 2/13/2019 5:51 PM, YueHaibing wrote:
> > > > Fixes gcc '-Wunused-but-set-variable' warning:
> > > >
> > > > drivers/scsi/lpfc/
On 2/14/2019 11:39 AM, James Bottomley wrote:
On Thu, 2019-02-14 at 10:52 -0800, James Smart wrote:
On 2/13/2019 5:51 PM, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/lpfc/lpfc_init.c: In function
'lpfc_cpu_affinity_check':
drivers/scsi/lpfc/lpfc_init.c:1059
From: Hannes Reinecke
When evaluating the 'block limits' VPD page we need to check if
the 'lbpme' (logical block provisioning management enable) bit
is set in the READ CAPACITY (16) output.
If it isn't we can safely assume that we cannot use DISCARD on
this device.
[JD: forward-ported to kernel
James,
> If you just want Martin to apply it now, and you don't want to gather
> and resend it with your other lpfc patches, I think the tag you want
> is Acked-by.
I usually fix these up when I commit so no need to resend. But please
make sure to use the right tag.
--
Martin K. Petersen
Hi Bart,
On 2/13/19, 4:57 PM, "Bart Van Assche" wrote:
External Email
--
On Wed, 2019-02-13 at 10:53 -0800, Himanshu Madhani wrote:
> + ha->free_fcport = create_workqueue("free_fcport");
> + if (!ha->
On Thu, 2019-02-14 at 10:52 -0800, James Smart wrote:
>
> On 2/13/2019 5:51 PM, YueHaibing wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/scsi/lpfc/lpfc_init.c: In function
> > 'lpfc_cpu_affinity_check':
> > drivers/scsi/lpfc/lpfc_init.c:10599:19: warning:
> > variabl
On 2/13/2019 5:51 PM, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_cpu_affinity_check':
drivers/scsi/lpfc/lpfc_init.c:10599:19: warning:
variable 'phys_id' set but not used [-Wunused-but-set-variable]
It never used since
On Thu, Feb 14, 2019 at 09:29:05AM +, John Garry wrote:
> On 13/02/2019 18:51, Ewan D. Milne wrote:
>> On Wed, 2019-02-13 at 12:42 +0100, Hannes Reinecke wrote:
>>> The recent patchset to use dma_set_mask_and_coherent() introduced
>>> a regression where a call to set a 64-bit DMA mask was follo
Hi Bart,
On 2/13/19, 4:55 PM, "Bart Van Assche" wrote:
On Wed, 2019-02-13 at 10:53 -0800, Himanshu Madhani wrote:
> static ssize_t
> +qla2x00_sysfs_set_port_speed(struct file *filp, struct kobject *kobj,
> +struct bin_attribute *bin_attr, char *buf, loff_t off, size_t cou
Hi Bill,
On 2/14/19, 7:52 AM, "Bill Kuzeja" wrote:
External Email
When sending an srb with qla2x00_start_sp, the sp can complete and be
freed by the time we log the debug message saying we sent it. This can
cause a panic if sp gets reused quickly or when running a kernel th
The sysfs phy_identifier attribute for a sas_end_device comes
from the rphy phy_identifier value.
Currently this is not being set for rphys with an end device attached,
so we see incorrect symlinks from systemd disk/by-path:
root@localhost:~# ls -l /dev/disk/by-path/
total 0
lrwxrwxrwx 1 root roo
(Sorry for the resend, forgot to put qla2xxx in the subject line)
When sending an srb with qla2x00_start_sp, the sp can complete and be
freed by the time we log the debug message saying we sent it. This can
cause a panic if sp gets reused quickly or when running a kernel that
poisons freed memor
When sending an srb with qla2x00_start_sp, the sp can complete and be
freed by the time we log the debug message saying we sent it. This can
cause a panic if sp gets reused quickly or when running a kernel that
poisons freed memory.
This was partially fixed by (not every case was addressed):
co
as you are already in a tasklet, it is unnecessary to call
spin_lock_bh, because softirq already disable BH.
Signed-off-by: Zhiwei Jiang
---
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
On Thu 07-02-19 08:35:06, Jens Axboe wrote:
[...]
> 2) Requests to attend the summit for those that are not proposing a
> topic should be sent to:
>
> lsf...@lists.linux-foundation.org
>
> Please summarize what expertise you will bring to the meeting, and
> what you would like to discuss. P
Hi Suganath,
I love your patch! Yet something to improve:
[auto build test ERROR on scsi/for-next]
[also build test ERROR on v5.0-rc4 next-20190214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On 13/02/2019 18:51, Ewan D. Milne wrote:
On Wed, 2019-02-13 at 12:42 +0100, Hannes Reinecke wrote:
The recent patchset to use dma_set_mask_and_coherent() introduced
a regression where a call to set a 64-bit DMA mask was followed
by a call to set a 32-bit DMA mask, leading to I/O errors and
data
45 matches
Mail list logo
