[PATCH] [SCSI] mpt3sas: Fix secure erase premature termination.

Problem: This is a work around for a bug with LSI Fusion MPT SAS2 when pefroming secure erase. Due to the very long time the operation takes commands issued during the erase will time out and will trigger execution of abort hook. Even though the abort hook is called for the specifc command which

[PATCH 2/2] g_NCR5380: Test the IRQ before accepting it

Trigger an IRQ first with a test IRQ handler to find out if it really works. Disable the IRQ if not. This prevents hang when incorrect IRQ was specified by user. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 31 +-- 1 file

Re: [PATCH] scsi_dh_alua: fix wrong scsi_device_put() in alua_rtpg_queue()

On 10/28/2016 05:05 PM, Bart Van Assche wrote: On 10/28/2016 01:21 AM, tang.jun...@zte.com.cn wrote: From: "tang.junhui" scsi_device_put() is called when the conditions pg->rtpg_sdev!=NULL and queue_delayed_work() failure satisfied, actually it should be not to call

[PATCH 1/2] NCR5380: Use probe_irq_*() for IRQ probing

Use standard probe_irq_on() and probe_irq_off() functions instead of own implementation. This prevents warning messages like this in the kernel log: genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080 (i8042) Move the IRQ trigger code to a separate function so it can be used for other

[PATCH 1/3] NCR5380: Use probe_irq_*() for IRQ probing

Use standard probe_irq_on() and probe_irq_off() functions instead of own implementation. This prevents warning messages like this in the kernel log: genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080 (i8042) Move the IRQ trigger code to a separate function so it can be used for other

Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock

On Sun, 2016-10-30 at 19:22 +, Bart Van Assche wrote: > On 10/28/16 19:08, James Bottomley wrote: > > This is a deadlock caused by an inversion issue in kernfs (suicide > > vs > > non-suicide removes); so fixing it in SCSI alone really isn't > > appropriate. I count at least five other

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

On 10/29/2016 5:44 PM, Nicholas A. Bellinger wrote: On Sat, 2016-10-29 at 14:10 -0400, TomK wrote: On 10/29/2016 3:50 AM, Nicholas A. Bellinger wrote: Hi TomK & Co, On Fri, 2016-10-28 at 02:01 -0400, TomK wrote: On 10/26/2016 8:08 AM, TomK wrote: On 10/26/2016 3:20 AM, Nicholas A. Bellinger

Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock

On 10/28/16 19:08, James Bottomley wrote: > This is a deadlock caused by an inversion issue in kernfs (suicide vs > non-suicide removes); so fixing it in SCSI alone really isn't > appropriate. I count at least five other subsystems all using this > mechanism, so they'll all be similarly affected.

Re: Need some pointers to debug a target hang

On Sat, Oct 29, 2016 at 03:53:25PM -0700, Nicholas A. Bellinger wrote: > Hi Johannes & Zhu, > > On Tue, 2016-10-18 at 23:29 -0700, Nicholas A. Bellinger wrote: > > On Tue, 2016-10-18 at 19:35 +0200, Johannes Thumshirn wrote: > > > On Tue, Oct 18, 2016 at 09:01:34AM +0200, Johannes Thumshirn

Re: [PATCH 2/3] g_NCR5380: Test the IRQ before accepting it

On Sun, 30 Oct 2016, Ondrej Zary wrote: > Trigger an IRQ first with a test IRQ handler to find out if it really > works. Disable the IRQ if not. > > This prevents hang when incorrect IRQ was specified by user. > > Signed-off-by: Ondrej Zary > --- >

Re: [PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

On Sun, 30 Oct 2016, Ondrej Zary wrote: > Read back MODE_REG after writing it in NCR5380_init() to check if the > chip is really there. > > This prevents hang when incorrect I/O address was specified by user. > > Signed-off-by: Ondrej Zary > --- >

Re: [PATCH] [SCSI] mpt3sas: Fix secure erase premature termination.

On 10/30/2016 01:43 PM, Andrey Grodzovsky wrote: Problem: This is a work around for a bug with LSI Fusion MPT SAS2 when pefroming secure erase. Due to the very long time the operation takes commands issued during the erase will time out and will trigger execution of abort hook. Even though the

[PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

Read back MODE_REG after writing it in NCR5380_init() to check if the chip is really there. This prevents hang when incorrect I/O address was specified by user. Signed-off-by: Ondrej Zary --- drivers/scsi/NCR5380.c |5 + 1 file changed, 5 insertions(+) diff

[PATCH 2/3] g_NCR5380: Test the IRQ before accepting it

Trigger an IRQ first with a test IRQ handler to find out if it really works. Disable the IRQ if not. This prevents hang when incorrect IRQ was specified by user. Signed-off-by: Ondrej Zary --- drivers/scsi/g_NCR5380.c | 32 ++-- 1 file

Re: [PATCH 1/3] NCR5380: Use probe_irq_*() for IRQ probing

On Sun, 30 Oct 2016, Ondrej Zary wrote: > Use standard probe_irq_on() and probe_irq_off() functions instead of own > implementation. Thanks for doing this. > This prevents warning messages like this in the kernel log: > genirq: Flags mismatch irq 1. (NCR-probe) vs. 0080 (i8042) >

RE: iscsi target kernel error log support

Hi, Thanks for reply:) Actually when configure second target, I execute targetcli /iscsi create iqn.2016-08.nokia.lab:omu-0 which will automatically create the 0.0.0.0 3260 listening socket for me. But I think we do not need it at all, because we will delete it later, after that configure own

Re: [PATCH 3/3] NCR5380: Check for chip presence in NCR5380_init()

On Sun, 30 Oct 2016, Ondrej Zary wrote: > Read back MODE_REG after writing it in NCR5380_init() to check if the > chip is really there. > > This prevents hang when incorrect I/O address was specified by user. Do you know whereabouts in the driver the hang happens? Maybe there is a robustness

Re: [PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On Fri, Oct 28, 2016 at 11:53:46AM +0200, Steffen Maier wrote: [...] > > > > > > > @@ -3937,6 +3944,7 @@ fc_bsg_request_handler(struct request_queue *q, > > > > struct Scsi_Host *shost, > > > > struct request *req; > > > > struct fc_bsg_job *job; > > > > enum