On 3/30/19 10:38 AM, zhengbin (A) wrote:
> ping
>
> On 2019/3/26 21:29, zhengbin (A) wrote:
>> On 2019/3/25 19:55, zhengbin (A) wrote:
>>> On 2019/3/25 18:02, Pavel Tikhomirov wrote:
>>>> Likely we should do the same for host_eh_scheduled+
Likely we should do the same for host_eh_scheduled++ as we do for
host_failed++ in scsi_eh_inc_host_failed. Just put it in call_rcu. These
way rcu_read_lock would be enough: if we don't see RECOVERY state in
scsi_dec_host_busy, that means that host_eh_scheduled++ and
corresponding scsi_eh_wakeu
out! Now when I understand
it, your patch looks good for me:
Reviewed-by: Pavel Tikhomirov
By the way, I very much like your idea of using rcu for these case.
Thanks, Pavel.
Bart.
Hello, Bart!
On 12/06/2017 12:46 AM, Bart Van Assche wrote:
On Wed, 2017-12-06 at 00:17 +0300, ptikhomirov wrote:
I mean threads in scsi_dec_host_busy() the part under rcu_read_lock are
divided into two groups: a) finished before call_rcu, b) beginning rcu
section after call_rcu. So first, in s
ounter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov
References: https://marc.info/?l=linux-kernel&m=150461610630736
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off
t_busy counter
wake up the error handler if necessary and by protecting the
host_failed checks with the SCSI host lock.
Reported-by: Pavel Tikhomirov
Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
Signed-off-by: Bart Van Assche
Cc: Konstantin Khorenko
Cc: Stuart
g to reuse them for new
checks too.
I don't see another way to fix these problem.
Your patch puts spinlocks under check which should itself be under
spinlock, and breaks the initial fix (see Stuart's comment that the
problem still reproduces). And you does _not_ answer your own
n't see another way to fix these problem.
Your patch puts spinlocks under check which should itself be under
spinlock, and breaks the initial fix (see Stuart's comment that the
problem still reproduces). And you does _not_ answer your own question.
Reported-by: Pavel Tikhomirov
Fi
oblem.
Your patch puts spinlocks under check which should itself be under
spinlock, and breaks the initial fix (see Stuart's comment that the
problem still reproduces). And you does _not_ answer your own question.
Reported-by: Pavel Tikhomirov
Fixes: commit 746650160866 ("scsi:
17 2:09 AM, Pavel Tikhomirov wrote:
My patch should also fix your issue too, please see explanation in reply to
your patch. Do your testing show that it doesn't?
Thanks, Pavel.
On 11/21/2017 09:10 AM, Stuart Hayes wrote:
Pavel,
It turns out that the error handler on our systems was not g
JFYI these patch is in Virtuozzo7 kernel from September, and we have no
issues found with it until now by out testing, and initial problem does
not reproduce for 2.5 months.
10 minutes or less successfully ran for many days.
Thanks,
Stuart
On 11/9/2017 8:54 AM, Pavel Tikhomirov wrote:
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
On 11/20/2017 10:11 PM, Stuart Hayes wrote:
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_unbus
> 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.
Hi, Stuart, I asked James Bottomley about the patch status offlist and
ping
On 09/05/2017 03:54 PM, Pavel Tikhomirov wrote:
We have a problem on several our nodes with scsi EH. Imagine such an
order of execution of two threads:
CPU1 scsi_eh_scmd_add CPU2 scsi_host_queue_ready
/* shost->host_busy == 1 initialy */
Hi. Please tell if there is something I can do to help the patch get
processed? It is on the list without reply for almost a month.
On 09/05/2017 03:54 PM, Pavel Tikhomirov wrote:
We have a problem on several our nodes with scsi EH. Imagine such an
order of execution of two threads:
CPU1
ck/unlock, so at the time of busy==failed
we will trigger wakeup in at least one thread. (Thats why putting
recovery and failed checks under lock)
Signed-off-by: Pavel Tikhomirov
---
drivers/scsi/scsi_lib.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --
On 12/10/2015 03:43 AM, James Bottomley wrote:
On Wed, 2015-12-09 at 15:35 +0300, Pavel Tikhomirov wrote:
On 12/08/2015 07:16 PM, James Bottomley wrote:
On Mon, 2015-12-07 at 14:01 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=108771
On 12/08/2015 07:16 PM, James Bottomley wrote:
On Mon, 2015-12-07 at 14:01 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=108771
--- Comment #1 from Pavel Tikhomirov ---
Aditional info about enclosue(from that node, but older 3.10 based kernel
I have very similar problem with SAS2X28, please take a look on a bug
report here https://bugzilla.kernel.org/show_bug.cgi?id=108771
Thanks, Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
20 matches
Mail list logo
