Re: [PATCH v4 5/5] g_NCR5380: Re-work PDMA loops

I'm afraid I accidentally introduced a regression into v4 of this patch. Ondrej, please test the patch below instead. Sorry for the inconvenience. diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c index b1e0a08e49c1..98d5360b0c78 100644 --- a/drivers/scsi/g_NCR5380.c +++

[no subject]

внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Tue, 27 Jun 2017, Ondrej Zary wrote: > On Tuesday 27 June 2017 14:42:29 Finn Thain wrote: > > > > ... it triggers sometimes: the value is 1 instead of 0. As we use > > > only 16-bit writes, I don't see how the value could ever be odd. > > > Looks like a bug in the chip. The index register

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Tue, 27 Jun 2017, Ondrej Zary wrote: > On Tuesday 27 June 2017 03:49:16 Finn Thain wrote: > > > > ... As long as there's no gated IRQ, we poll for buffer readiness > > until timeout. And when there is a gated IRQ, we break both the > > polling loop and the transfer loop immediately. Your

Re: Permanently change thin provisioning method from user space?

28.06.2017 00:01, Ewan D. Milne пишет: > On Tue, 2017-06-27 at 14:02 +0300, Andrei Borzenkov wrote: >> I'm facing storage system that while generally advertising support for >> WRITE_SAME_16 with UNMAP in reality fails this request depending on >> exact volume configuration. This configuration is

[PATCH v4 4/5] g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on DTC3181E

From: Ondrej Zary The corruption is always the same: one byte missing at the beginning of a 128 B block. It happens only with slow Quantum LPS 240 drive, not with faster IBM DORS-32160. It's not clear what causes this. Documentation for the DTC436 chip has not been

[PATCH v4 5/5] g_NCR5380: Re-work PDMA loops

From: Ondrej Zary The polling loops in pread() and pwrite() can easily become infinite loops and hang the machine. On DTC chips, IRQ can arrive late and we miss it because we only check once. Merge the IRQ check into host buffer wait and add polling limit. Also

[PATCH v4 3/5] g_NCR5380: Cleanup comments and whitespace

Signed-off-by: Finn Thain --- drivers/scsi/g_NCR5380.c | 61 ++-- 1 file changed, 28 insertions(+), 33 deletions(-) diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c index 911a4300ea51..9f18082415c4 100644

[PATCH v4 2/5] g_NCR5380: End PDMA transfer correctly on target disconnection

From: Ondrej Zary When an IRQ arrives during PDMA transfer, pread() and pwrite() return without waiting for the 53C80 registers to be ready and this ends up messing up the chip state. This was observed with SONY CDU-55S which is slow enough to disconnect during

[PATCH v4 0/5] g_NCR5380: PDMA fixes and cleanup

Ondrej, would you please test this new series? Changed since v1: - PDMA transfer residual is calculated earlier. - End of DMA flag check is now polled (if there is any residual). Changed since v2: - Bail out of transfer loops when Gated IRQ gets asserted. - Make udelay conditional on board type.

[PATCH v4 1/5] g_NCR5380: Fix PDMA transfer size

From: Ondrej Zary generic_NCR5380_dma_xfer_len() incorrectly uses cmd->transfersize which causes rescan-scsi-bus and CD-ROM access to hang the system. Use cmd->SCp.this_residual instead, like other NCR5380 drivers. Signed-off-by: Ondrej Zary

Re: [PATCH] ses: do not add a device to an enclosure if enclosure_add_links() fails.

On Tue, 2017-06-27 at 21:10 -0400, Martin K. Petersen wrote: > Maurizio, > > > > > The enclosure_add_device() function should fail if it can't > > create the relevant sysfs links. > > James? It's essentially the patch I proposed, so I'm fine with it.  Although I would like more root cause

Re: [PATCH v2 0/6] qla2xxx: Add NVMe FC Fabric support in driver

Himanshu, > This patch series adds NVMe FC fabric support for qla2xxx initiator > mode driver. Applied to 4.13/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH RESEND] scsi: sun_esp: fix device reference leaks

Johan, > Make sure to drop the reference to the dma device taken by > of_find_device_by_node() on probe errors and on driver unbind. Looks good to me. Applied to 4.13/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2] qla2xxx: Protect access to qpair members with qpair->qp_lock

Hi Martin, On 6/27/17, 6:32 PM, "Martin K. Petersen" wrote: > In qla2xx_start_scsi_mq() and qla2xx_dif_start_scsi_mq() we grab the > qpair->qp_lock but do access members of the qpair before having the lock. > Re-order the locking sequence to have all

Re: [PATCH 1/1] fnic: Zero io_cmpl_skip on fw reset completion

Satish, > io_cmpl_skip keep track of number of completions to skip when stats > are reset. If a fw_reset happens immediately after stats reset it > could put it out of sync so need to reset io_cmpl_skip when fw reset > is completed. Applied patches 1-4 to 4.13/scsi-queue. Thank you! -- Martin

Re: [PATCH 0/7] bnx2fc: Update driver to version 2.11.8.

Chad, > Please apply the following patches at your earliest convenience. Applied to 4.13/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: ufs: set host_byte to DID_REQUEUE when ocs = OCS_ABORTED

> Host set ocs to OCS_ABORTED when clear a doorbell in err handler. > Then scsi_decide_disposition return SUCCESS. This may cause some > filesystem panic because a FAILED REQUESET. Requeue and complete is > better. Subhash: Please review the three ufs patches from Zang.

Re: [PATCH v2] qla2xxx: Protect access to qpair members with qpair->qp_lock

> In qla2xx_start_scsi_mq() and qla2xx_dif_start_scsi_mq() we grab the > qpair->qp_lock but do access members of the qpair before having the lock. > Re-order the locking sequence to have all read and write access to qpair > members under the qpair->qp_lock. Cavium folks, please review! --

Re: [PATCH] scsi: sas: scsi_queue_work can fail, so make callers aware

Johannes, > libsas uses scsi_queue_work() to queue it's internal event > notifications. scsi_queue_work() can return -EINVAL if the work queue > doesn't exist and it does call queue_work() which can return false if > the work is already queued. Applied to 4.13/scsi-queue, thanks! -- Martin K.

Re: [PATCH] ses: do not add a device to an enclosure if enclosure_add_links() fails.

Maurizio, > The enclosure_add_device() function should fail if it can't > create the relevant sysfs links. James? -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH RESEND] scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state

Ewan, > The addition of the STARGET_REMOVE state had the side effect of > introducing a race condition that can cause a crash. > > scsi_target_reap_ref_release() checks the starget->state to > see if it still in STARGET_CREATED, and if so, skips calling > transport_remove_device() and

Re: Permanently change thin provisioning method from user space?

Ewan, > sd_fops->revalidate_disk() will cause the properties that cause the > provisioning_mode to be evaluated to be re-read, and sd_config_discard() > to set the determined mode. We might want to re-think this, since the > user overrode what was probed earlier. However, we might also want to

Re: [PATCH] sd: add support for TCG OPAL self encrypting disks

Tejun, >> Looks good to me. I'll queue it up for 4.13 as soon as Linus has pulled >> in the ata bits. > > I can route it through libata tree w/ your ack if that's more convenient. I don't think it will cause any headaches. I'm just a bit cautious since I already have a ton of conflicts in

Re: [PATCH 29/35] bnx2fc: remove obsolete bnx2fc_eh_host_reset() definition

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 23/35] qedf: drop bus reset handler

This is a clear change of behavior, so we should run it past the maintainer. The old behavior looks wrong, but it's probably papering over something else..

Re: [PATCH 18/35] qlogicfas: move bus_reset to host_reset

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 16/35] acornscsi: move bus reset to host reset

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 15/35] qlogicpti: move bus reset to host reset

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 13/35] scsi: drop bus reset for wd33c93-compatible boards

On Fri, Jun 23, 2017 at 03:02:33PM +0200, Hannes Reinecke wrote: > The bus reset function is just a wrapper around host reset, so drop it. It also takes the host_lock, which the direct host_reset invokation doesn't. Given that before we'd always get the bus reset first that probably was the

Re: [PATCH 14/35] rtsx: drop bus reset function

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 11/35] hptiop: Simplify reset handling

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH 09/35] libsas: move bus_reset_handler() to target_reset_handler()

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 10/35] bfa: move bus reset to target reset

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 08/35] lpfc: drop lpfc_no_handler and lpfc_bus_reset_handler()

On Fri, Jun 23, 2017 at 03:02:28PM +0200, Hannes Reinecke wrote: > lpfc_bus_reset_handler() is really just a loop calling > lpfc_target_reset_handler() over all targets, which is what > the error handler will be doing anyway. > And lpfc_no_handler() will return FAILED, just like SCSI EH > does if

Re: [PATCH 06/35] visorhba: sanitze private device data allocation

On Fri, Jun 23, 2017 at 03:02:26PM +0200, Hannes Reinecke wrote: > There's no need to keep the private data for a device in a separate > list; better to store it in ->hostdata and do away with the additional > list. Nice improvement, although that driver is a complete mess.. And I guess you need

Re: [PATCH 05/35] fnic: do not call host reset from command abort

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH 07/35] uas: move eh_bus_reset_handler to eh_device_reset_handler

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 03/35] ibmvfc: Do not call fc_block_scsi_eh() on host reset

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH 01/35] scsi: fix comment in scsi_device_set_state()

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH 04/35] fc_fcp: do not call fc_block_scsi_eh() from host reset

Loks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH 02/35] mptfc: Do not call fc_block_scsi_eh() on host reset

Looks fine, Reviewed-by: Christoph Hellwig

Re: [RFC PATCH 00/35] SCSI EH argument reshuffling

Can you send a series with just the prep patches in the beginning? I think some of this could be 4.13 material still, leaving the actual prototype changes for 4.14.

[PATCH] scsi: osst: remove useless variable assignments in osst_int_ioctl()

Value assigned to variable blkno at lines 4123:if (blkno >= 0) blkno += arg; and 4127:if (blkno >= 0) blkno -= arg; is overwritten at line 4131:blkno = STps->drv_block; before it can be used. This makes such variable assignments useless. Addresses-Coverity-ID: 1397685 Signed-off-by: Gustavo A.

Re: [PATCH 0/5] v3 block subsystem refcounter conversions

On Tue, Jun 27, 2017 at 6:26 AM, Jens Axboe wrote: > On 06/27/2017 05:39 AM, Elena Reshetova wrote: >> Changes in v3: >> No changes in patches apart from trivial rebases, but now by >> default refcount_t = atomic_t and uses all atomic standard operations >> unless

Re: [PATCH RESEND] scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state

On 06/27/2017 02:55 PM, Ewan D. Milne wrote: From: "Ewan D. Milne" The addition of the STARGET_REMOVE state had the side effect of introducing a race condition that can cause a crash. scsi_target_reap_ref_release() checks the starget->state to see if it still in

Re: Permanently change thin provisioning method from user space?

On Tue, 2017-06-27 at 14:02 +0300, Andrei Borzenkov wrote: > I'm facing storage system that while generally advertising support for > WRITE_SAME_16 with UNMAP in reality fails this request depending on > exact volume configuration. This configuration is done on storage side > and may happen after

[PATCH RESEND] scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state

From: "Ewan D. Milne" The addition of the STARGET_REMOVE state had the side effect of introducing a race condition that can cause a crash. scsi_target_reap_ref_release() checks the starget->state to see if it still in STARGET_CREATED, and if so, skips calling

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Tuesday 27 June 2017 03:49:16 Finn Thain wrote: > On Mon, 26 Jun 2017, Ondrej Zary wrote: > > No apparent change in behavior, the first write test resulted in: > > [ 842.830802] sd 2:0:1:0: [sdb] tag#0 53c80 registers not accessible, > > device will be reset [ 842.830802] sd 2:0:1:0: [sdb]

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Tuesday 27 June 2017 14:42:29 Finn Thain wrote: > On Tue, 27 Jun 2017, Ondrej Zary wrote: > > BTW. I've probably found the DTC write corruption. Added the following > > check (13 is host buffer index register) - > > That register is not mentioned in my 53c400 datasheet. Yes, it's not there.

Re: [PATCH] libata: Support for an ATA PASS-THROUGH(32) command.

On Sat, Jun 24, 2017 at 03:41:10AM +0900, Minwoo Im wrote: > SAT-4(SCSI/ATA Translation) supports for an ata pass-thru(32). > This patch will allow to translate an ata pass-thru(32) SCSI cmd > to an ATA cmd. > > Signed-off-by: Minwoo Im > Reviewed-by: Bart Van Assche

Re: [PATCH 0/5] v3 block subsystem refcounter conversions

On 06/27/2017 05:39 AM, Elena Reshetova wrote: > Changes in v3: > No changes in patches apart from trivial rebases, but now by > default refcount_t = atomic_t and uses all atomic standard operations > unless CONFIG_REFCOUNT_FULL is enabled. This is a compromize for the > systems that are critical

Re: [PATCH] ses: do not add a device to an enclosure if enclosure_add_links() fails.

On 06/27/2017 04:53 AM, Maurizio Lombardi wrote: The enclosure_add_device() function should fail if it can't create the relevant sysfs links. Signed-off-by: Maurizio Lombardi --- drivers/misc/enclosure.c | 14 ++ 1 file changed, 10 insertions(+), 4

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Tue, 27 Jun 2017, Michael Schmitz wrote: > Ondrej, > > could this be a partial write (target did not transfer the last byte)? > We do wait for TCR_LAST_BYTE_SENT, but only when there is no residual. Perhaps we should wait for TCR_LAST_BYTE_SENT whenever the 53c400 asserts /EOP. That is,

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Tue, 27 Jun 2017, Ondrej Zary wrote: > BTW. I've probably found the DTC write corruption. Added the following > check (13 is host buffer index register) - That register is not mentioned in my 53c400 datasheet. > and it triggers sometimes: the value is 1 instead of 0. As we use only >

[PATCH 3/5] block: convert blkcg_gq.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 4/5] block: convert io_context.active_ref from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 5/5] block: convert bsg_device.ref_count from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 1/5] block: convert bio.__bi_cnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 2/5] block: convert blk_queue_tag.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 0/5] v3 block subsystem refcounter conversions

Changes in v3: No changes in patches apart from trivial rebases, but now by default refcount_t = atomic_t and uses all atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled. This is a compromize for the systems that are critical on performance and cannot accept even slight delay on the

Permanently change thin provisioning method from user space?

I'm facing storage system that while generally advertising support for WRITE_SAME_16 with UNMAP in reality fails this request depending on exact volume configuration. This configuration is done on storage side and may happen after host initially discovered LUN. I though about simply overriding

Re: [PATCH 1/1] qedi: Add support for offload iSCSI Boot

On 26/06/17, 10:29 PM, "Martin K. Petersen" wrote: > >Nilesh, > >> This patch adds support for offload iSCSI boot (Boot from SAN >> over iSCSI offload). >> >> The dependent qed patches for this support are, >> - qed: Support NVM-image reading API >> - qed: Share

[PATCH] ses: do not add a device to an enclosure if enclosure_add_links() fails.

The enclosure_add_device() function should fail if it can't create the relevant sysfs links. Signed-off-by: Maurizio Lombardi --- drivers/misc/enclosure.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/misc/enclosure.c

[PATCH v1 1/1] qedi: Add support for Boot from SAN over iSCSI offload

This patch adds support for Boot from SAN over iSCSI offload. The iSCSI boot information in the NVRAM is populated under /sys/firmware/iscsi_bootX/ using qed NVM-image reading API and further exported to open-iscsi to perform iSCSI login enabling boot over offload iSCSI interface in a Boot from

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

Ondrej, could this be a partial write (target did not transfer the last byte)? One would suppose the chip posts a phase mismatch in that case ... Cheers, Michael Am 27.06.2017 um 18:28 schrieb Ondrej Zary: > On Monday 26 June 2017, Ondrej Zary wrote: >> On Monday 26 June 2017

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

On Monday 26 June 2017, Ondrej Zary wrote: > On Monday 26 June 2017 09:30:33 Finn Thain wrote: > > Ondrej, would you please test this new series? > > > > Changed since v1: > > - PDMA transfer residual is calculated earlier. > > - End of DMA flag check is now polled (if there is any residual). > >

Re: [PATCH] scsi: default to scsi-mq

On Mon, 2017-06-26 at 20:55 +0200, Martin Wilck wrote: > I personally find it odd that the compile-time choice goes away while > the run-time choice remains available. I understand what Christoph is > trying to achieve, but if it was up to me, I'd prefer to change the > default and mark the "n"