much like your idea of using rcu for these case.
>
> Thanks, Pavel.
>
This patch tests ok on my system, too... it's run for over 24 hours, on a
system that typically fails within ten minutes without the patch...
Tested-by: Stuart Hayes
Thanks,
Stuart
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
; Signed-off-by: Bart Van Assche
> Cc: Konstantin Khorenko
> Cc: Stuart Hayes
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: Johannes Thumshirn
> Cc:
> ---
> drivers/scsi/scsi_error.c | 3 ++-
> drivers/scsi/scsi_lib.c | 22 ++
>
ing, given that
scsi_eh_scmd_add() also uses the spinlock.
I tested your patch on my issue, and it did indeed fix my issue.
So you can add...
Tested-by: Stuart Hayes
Thanks
Stuart
On 11/21/2017 2:09 AM, Pavel Tikhomirov wrote:
> My patch should also fix your issue too, please see explanatio
Pavel,
It turns out that the error handler on our systems was not getting woken up for
a different reason... I submitted a patch earlier today that fixes the issue I
were seeing (I CCed you on the patch).
Before I got my hands on the failing system and was able to root cause it, I
was pretty s
When a command is added to the host's error handler command queue, there is a
chance that the error handler will not be woken up. This can happen when one
CPU is running scsi_eh_scmd_add() at the same time as another CPU is running
scsi_device_unbusy() for a different command on the same host.
Are there any issues with this patch
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted
back in September? I am willing to help if there's anything I can do to help
get it accepted.
The failing case I'm working on involves lots of servers with disk read/write
activ
6 matches
Mail list logo
