On 2018-05-24 10:58:44 [+0800], Jason Yan wrote:
> I think it's fine to delete this irq save code. As for the "TODO"
> comment, I think we can add:
>
> BUG_ON(!irqs_disabled());
>
> or
>
> WARN_ON_ONCE(!irqs_disabled());
no, please don't do this. Please add instead
lockdep_assert_held()
On Wed, May 23, 2018 at 02:17:14PM -0700, Kees Cook wrote:
>
> True, though I'm finding other robustness issues in the CDROM code.
> They're probably all insane corner cases, but it seems like it'd be
> nice to just fix them:
>
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index
On 2018/5/24 15:15, Sebastian Andrzej Siewior wrote:
On 2018-05-24 10:58:44 [+0800], Jason Yan wrote:
I think it's fine to delete this irq save code. As for the "TODO"
comment, I think we can add:
BUG_ON(!irqs_disabled());
or
WARN_ON_ONCE(!irqs_disabled());
no, please don't do this. Pleas
On Thu, May 24, 2018 at 03:38:51PM +0800, Jason Yan wrote:
>
>
> On 2018/5/24 15:15, Sebastian Andrzej Siewior wrote:
> > On 2018-05-24 10:58:44 [+0800], Jason Yan wrote:
> > > I think it's fine to delete this irq save code. As for the "TODO"
> > > comment, I think we can add:
> > >
> > > BUG_ON
On 2018-05-24 15:38:51 [+0800], Jason Yan wrote:
> > no, please don't do this. Please add instead
> > lockdep_assert_held()
> >
> > on the lock in question and let lockdep to its work. Lockdep has way
> > better coverage than your irqs_disabled() check which also breaks RT.
> >
>
> lockdep_a
On 2018-05-24 09:50:07 [+0200], Johannes Thumshirn wrote:
> > lockdep_assert_held() cannot detect the irq state, it can only detect
> > whether we have held the lock.
>
> I think Sebastian wanted to say lockdep_assert_irqs_disabled().
nope, meant the right thing.
> Byte,
> Johannes
Sebast
On 2018/5/24 15:50, Johannes Thumshirn wrote:
On Thu, May 24, 2018 at 03:38:51PM +0800, Jason Yan wrote:
On 2018/5/24 15:15, Sebastian Andrzej Siewior wrote:
On 2018-05-24 10:58:44 [+0800], Jason Yan wrote:
I think it's fine to delete this irq save code. As for the "TODO"
comment, I think
On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote:
> Ugh, so that would necessitate a change there too. As I said before,
> I don't really care where it lives. I know the SCSI folks seem bothered
> by moving it, but in reality, it's not like this stuff will likely ever
> really change. Of
On 2018/5/24 15:52, Sebastian Andrzej Siewior wrote:
On 2018-05-24 15:38:51 [+0800], Jason Yan wrote:
no, please don't do this. Please add instead
lockdep_assert_held()
on the lock in question and let lockdep to its work. Lockdep has way
better coverage than your irqs_disabled() check
On 2018-05-24 16:00:47 [+0800], Jason Yan wrote:
> > > Because you are trying to delete the irq-save code which will make the
> > > comment hard to understand, I'm just giving an advise. It's welcome
> > > if you have a better way.
> >
> > I am removing local_irq_save() prior an unlock of a lock w
On 2018/5/24 16:18, Sebastian Andrzej Siewior wrote:
On 2018-05-24 16:00:47 [+0800], Jason Yan wrote:
Because you are trying to delete the irq-save code which will make the
comment hard to understand, I'm just giving an advise. It's welcome
if you have a better way.
I am removing local_irq_s
On 2018-05-24 16:20:33 [+0800], Jason Yan wrote:
> NO, this:
>
> /* TODO: audit callers to ensure they are ready for qc_issue to
>* unconditionally re-enable interrupts
>*/
> local_irq_save(flags);
> spin_unlock(ap->lock);
indeed, I have no idea how I could have
Hi Himanshu
Thanks god get response from your side finally :)
I get qla2xxx-upstr...@qlogic.com from the maintainer information of
driver/scsi/qla2xxx
Looks like it should be modified.
Thanks
Jianchao
On 05/24/2018 12:21 PM, Madhani, Himanshu wrote:
> Hi,
>
> Yes. We'll look at this issue.
>
If the cmd has not be returned after aborted by qla2x00_eh_abort,
when qla2x00_eh_wait_on_command is invoked, it has to wait for it.
However, the time is 1000ms at least currently. If there are a lot
cmds need to be aborted, the delay could be long enough to lead to
panic due to such as hung task,
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Xose Vazquez Perez
[ Upstream commit 5f96f42b76e00e2871033745ff029056cc725c76 ]
"The DISK-SUBSYSTEM is a special model name returned when LUs
are not installed. For example, when LU#0 is not i
On 5/23/2018 6:57 PM, Sinan Kaya wrote:
>> The crash seems to indicate that the hpsa device attempted a DMA after
>> we cleared the Root Port's PCI_COMMAND_MASTER, which means
>> hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
>> shutdown methods don't disable device DMA, so i
Hi Sayali,
I have several notes about the patches:
1. New descriptors structures are redefinition of the descriptors info (see
definitions of device_desc_param, unit_desc_param, etc in
drivers/scsi/ufs/ufs.h)
2. You didn't took into consideration the recently added UFS sysfs
infostructure.
3. T
On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote:
> On 5/23/2018 6:57 PM, Sinan Kaya wrote:
> >> The crash seems to indicate that the hpsa device attempted a DMA after
> >> we cleared the Root Port's PCI_COMMAND_MASTER, which means
> >> hpsa_shutdown() didn't stop DMA from the device (it
On 2018-05-24 09:07, Bjorn Helgaas wrote:
On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote:
On 5/23/2018 6:57 PM, Sinan Kaya wrote:
>> The crash seems to indicate that the hpsa device attempted a DMA after
>> we cleared the Root Port's PCI_COMMAND_MASTER, which means
>> hpsa_shutdown()
Since commit 312d3e56119a ("[SCSI] libsas: remove ata_port.lock
management duties from lldds") the sas_ata_qc_issue() function unlocks
the ata_port.lock and disables interrupts before doing so.
That lock is always taken with disabled interrupts so at this point, the
interrupts are already disabled.
> +/* Make sure any sense buffer is the correct size. */
> +#define scsi_execute(sdev, cmd, data_direction, buffer, bufflen, sense,
> \
> + sshdr, timeout, retries, flags, rq_flags, resid) \
> +({ \
> + B
A barrier should be added to ensure proper ordering of memory mapped
writes.
Signed-off-by: Tomas Henzl
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index bf04fa90f..569392d0
On Thu, 2018-05-24 at 17:12 +0200, Tomas Henzl wrote:
> A barrier should be added to ensure proper ordering of memory mapped
> writes.
>
> Signed-off-by: Tomas Henzl
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas
On 05/24/2018 05:19 PM, James Bottomley wrote:
> On Thu, 2018-05-24 at 17:12 +0200, Tomas Henzl wrote:
>> A barrier should be added to ensure proper ordering of memory mapped
>> writes.
>>
>> Signed-off-by: Tomas Henzl
>> ---
>> drivers/scsi/mpt3sas/mpt3sas_base.c | 1 +
>> 1 file changed, 1 inse
On Thu, 2018-05-24 at 17:31 +0200, Tomas Henzl wrote:
> On 05/24/2018 05:19 PM, James Bottomley wrote:
> > On Thu, 2018-05-24 at 17:12 +0200, Tomas Henzl wrote:
> > > A barrier should be added to ensure proper ordering of memory
> > > mapped
> > > writes.
> > >
> > > Signed-off-by: Tomas Henzl
>
On 05/24/2018 05:33 PM, James Bottomley wrote:
> On Thu, 2018-05-24 at 17:31 +0200, Tomas Henzl wrote:
>> On 05/24/2018 05:19 PM, James Bottomley wrote:
>>> On Thu, 2018-05-24 at 17:12 +0200, Tomas Henzl wrote:
A barrier should be added to ensure proper ordering of memory
mapped
writ
This is patch version 3.
Generally target core and TCMUser seem to work fine for tape devices and
media changers.
But there is at least one situation, where TCMUser is not able to support
sequential access device emulation correctly.
The situation is when an initiator sends a SCSI READ CDB with a
memcmp() returns int, but variable of type u8 is used to store it. When
casting int to u8, one can lose significant bits and get 0 from non-0
value returned by the memcmp().
Signed-off-by: Ivan Bornyakov
---
drivers/scsi/isci/host.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On Thu, May 24, 2018 at 1:00 AM, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 03:14:19PM -0600, Jens Axboe wrote:
>> Ugh, so that would necessitate a change there too. As I said before,
>> I don't really care where it lives. I know the SCSI folks seem bothered
>> by moving it, but in reality
On Wed, May 23, 2018 at 06:57:18PM -0400, Sinan Kaya wrote:
> On 5/23/2018 5:32 PM, Bjorn Helgaas wrote:
> >
> > The crash seems to indicate that the hpsa device attempted a DMA after
> > we cleared the Root Port's PCI_COMMAND_MASTER, which means
> > hpsa_shutdown() didn't stop DMA from the device
Hi James,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/qedf/qedf.h
between commit:
8673daf4f55bf3b91 ("qedf: Add get_generic_tlv_data handler.")
from the net-next tree and commit:
4b9b7fabb39b3e9d7 ("scsi: qedf: Improve firmware debug dump handling")
from t
MDS diagnostics fail because of frame count mismatch.
Unavailability of SGL is the trigger for this issue. If ELS SGL
is not available to process MDS frame, IOCB is put in FCP txq
but not attempted to post afterwards. So, driver stops processing
incoming frames as it runs out of IOCB. lpfc_drain_
This patch contains lpfc bug fixes and a few message updates and
cleanups.
The patches were cut against the Martin's 4.18/scsi-queue tree
James Smart (6):
lpfc: Fix MDS diagnostics failure (Rx < Tx)
lpfc: correct oversubscription of nvme io requests for an adapter
lpfc: Fix crash in blk_mq
Under large configurations, the driver would start to log
message 6065 - NVME out of buffers (exchanges).
The driver is using the ndlp cmd_qdepth value when determining
the max outstanding ios for an adapter. This value, by default,
is set to 65536, which exceeds the maximum exchange counts
suppor
The driver exits port setup after failing the
lpfc_sli4_get_parameters command (messages 0356, 2541, & 1412).
The older CNA adapters do not support the MBX command. In the past
the code was allowed to fail and continue on with initialization.
However a nvme change moved a closing bracket and now m
Update the driver version to 12.0.0.4
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_version.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h
index 9fca71d7c297..18c23afcf
The lancer G5 chip family fails the CQ create with 16k page size.
The hardware incorrectly reports it supports large page sizes
when it is actually limited to 4k pages.
A prior patch resolved this for the A0 chip revision only.
This patch excludes all revisions of the G5 asic from using
large page
modprobe -r lpfc produces the following:
Call Trace:
__blk_mq_run_hw_queue+0xa2/0xb0
__blk_mq_delay_run_hw_queue+0x9d/0xb0
? blk_mq_hctx_has_pending+0x32/0x80
blk_mq_run_hw_queue+0x50/0xd0
blk_mq_sched_insert_request+0x110/0x1b0
blk_execute_rq_nowait+0x76/0x180
nvme_keep_alive_work+0x8a/0xd
Hi Himanshu
I'm afraid I cannot provide you the vmcore file, it is from our customer.
If any information needed in the vmcore, I could provide with you.
In this scene, there are two contexts:
1. the irq context, scsi_done() from qla2x00_sp_compl()
2. the kworker context, scmd_eh_abort_handler whi
39 matches
Mail list logo
