On Sat, 2017-03-18 at 12:17 +0100, Hannes Reinecke wrote:
> On 03/17/2017 12:00 AM, Bart Van Assche wrote:
> > I hadn't seen this crash before kernel v4.11-rc1 but with kernel v4.11-rc1
> > and later I see it if I let the srp-test scripts run for a few minutes. The
> > patch I used to disable async
On 03/17/2017 12:00 AM, Bart Van Assche wrote:
> On Mon, 2017-03-13 at 14:55 -0700, James Bottomley wrote:
>> On Mon, 2017-03-13 at 20:33 +, Bart Van Assche wrote:
>>> On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote:
On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
>
On Thu, 2017-03-16 at 23:00 +, Bart Van Assche wrote:
> The following crash only occurs with async aborts enabled:
>
> general protection fault: [#1] SMP
> RIP: 0010:scsi_device_put+0xb/0x30
> Call Trace:
> scsi_disk_put+0x2d/0x40
> sd_release+0x3d/0xb0
> __blkdev_put+0x29e/0x360
> bl
On Mon, 2017-03-13 at 14:55 -0700, James Bottomley wrote:
> On Mon, 2017-03-13 at 20:33 +, Bart Van Assche wrote:
> > On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote:
> > > On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> > > > diff --git a/drivers/scsi/scsi.c b/drivers/scsi
On 3/16/2017 5:42 PM, Bart Van Assche wrote:
On Thu, 2017-03-16 at 11:02 +0200, Israel Rukshin wrote:
I tested your patches and the hang disappeared when fast_io_fail_tmo
expired. The warning from patch 1 still exist, so we need an additional
fix for that.
Hello Israel,
Thanks for the testing!
On Thu, 2017-03-16 at 11:02 +0200, Israel Rukshin wrote:
> I tested your patches and the hang disappeared when fast_io_fail_tmo
> expired. The warning from patch 1 still exist, so we need an additional
> fix for that.
Hello Israel,
Thanks for the testing! I will leave out patch 1 for now since i
Hi Bart,
I tested your patches and the hang disappeared when fast_io_fail_tmo
expired.
The warning from patch 1 still exist, so we need an additional fix for that.
Regards,
Israel
On 3/16/2017 1:27 AM, Bart Van Assche wrote:
On Tue, 2017-03-14 at 16:23 +0200, Israel Rukshin wrote:
Patch num
On Tue, 2017-03-14 at 16:23 +0200, Israel Rukshin wrote:
> Patch number 5 doesn't handle the case when device_for_each_child() is
> called. device_for_each_child() calls to target_unblock() that uses also
> starget_for_each_device(). After applying also the following change the
> hang disappeared
Hello Bart,
Patch number 5 doesn't handle the case when device_for_each_child() is
called.
device_for_each_child() calls to target_unblock() that uses also
starget_for_each_device().
After applying also the following change the hang disappeared but it
didn't fix the warning.
Those fixes are no
Hello Bart,
I applied and tested patches 3, 4 and 5.
I am sorry to tell you that it didn't work.
I saw the warning you added and the hang at device_del().
[ 333.696462] [ cut here ]
[ 333.696471] WARNING: CPU: 11 PID: 321 at
drivers/scsi/scsi_sysfs.c:1280 __scsi_remove
On Mon, 2017-03-13 at 14:55 -0700, James Bottomley wrote:
> This is true, but I don't see how it can cause the host to be freed
> before the sdev. The memory for struct Scsi_Host is freed in the
> shost_gendev release routine, which should be pinned by the parent
> traversal from sdev. So it shou
On Mon, 2017-03-13 at 20:33 +, Bart Van Assche wrote:
> On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote:
> > On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> > > diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> > > index 7bfbcfa7af40..b3bb49d06943 100644
> > > --- a/
On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote:
> On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> > diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> > index 7bfbcfa7af40..b3bb49d06943 100644
> > --- a/drivers/scsi/scsi.c
> > +++ b/drivers/scsi/scsi.c
> > @@ -602,7 +602
On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 7bfbcfa7af40..b3bb49d06943 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -602,7 +602,7 @@ EXPORT_SYMBOL(scsi_device_get);
> */
> void scsi_device_put(s
On Sun, 2017-03-12 at 12:26 +0200, Israel Rukshin wrote:
> scsi_device_get() affects I/O because scsi_target_unblock() use it and calls
> to blk_start_queue().
> terminate_rport_io() is called after scsi_target_unblock() and completes all
> the commands
> including the SYNCHRONIZE CACHE command.
Hi Bart,
scsi_device_get() affect I/O because scsi_target_unblock() use it and calls to
blk_start_queue().
terminate_rport_io() is called after scsi_target_unblock() and completes all
the commands
including the SYNCHRONIZE CACHE command.
I applied your patch and you can see that QUEUE_FLAG_STO
On Thu, 2017-03-09 at 18:37 +0200, Israel Rukshin wrote:
> The bug reproduce when unloading srp module with one port down.
> sd_shutdown() hangs when __scsi_remove_device() get scsi_device with
> state SDEV_OFFLINE or SDEV_TRANSPORT_OFFLINE.
> It hangs because sd_shutdown() is trying to send sync c
The bug reproduce when unloading srp module with one port down.
sd_shutdown() hangs when __scsi_remove_device() get scsi_device with
state SDEV_OFFLINE or SDEV_TRANSPORT_OFFLINE.
It hangs because sd_shutdown() is trying to send sync cache command
when the device is offline but with SDEV_CANCEL stat
18 matches
Mail list logo
