:
- check retry timeout in scsi_io_completion() instead of scsi_softirq_done()
Signed-off-by: Eiichi Tsukata
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/scsi/scsi_lib.c |7 +++
1 file changed, 7 insertions(+)
di
:
- check retry timeout in scsi_io_completion() instead of scsi_softirq_done()
Signed-off-by: Eiichi Tsukata
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/scsi/scsi_lib.c |7 +++
1 file changed, 7 insertions(+)
di
(2014/02/07 15:15), Libo Chen wrote:
On 2014/2/7 13:46, James Bottomley wrote:
On Fri, 2014-02-07 at 09:22 +0900, Eiichi Tsukata wrote:
Currently, scsi error handling in scsi_io_completion() tries to
unconditionally requeue scsi command when device keeps some error state.
For example
s/X:X:X:X/retry_timeout
Changes in v2:
- check retry timeout in scsi_io_completion() instead of scsi_softirq_done()
Signed-off-by: Eiichi Tsukata
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/scsi/scsi_lib.c| 22 ++
(2014/02/06 1:55), James Bottomley wrote:
On Wed, 2014-02-05 at 14:47 +0900, Eiichi Tsukata wrote:
Currently, scsi error handling in scsi_decide_disposition() tries to
unconditionally requeue scsi command when device keeps some error state.
This is because retryable errors are thought to be
'retry_timeout' sysfs attribute which limits the retry time
of each scsi command. Once scsi command retry time is longer than this timeout,
the command is treated as failure. 'retry_timeout' is set to '0' by default
which means no timeout set.
Signed-off-by:
ace application.
Here the allowed count(scmd->allowed) is currently used as finite retry
limit count. Once retry count exceeds the allowed count on a device,
the message is suppressed on the device to avoid too much messages
outputted in dmesg.
Signed-off-by: Eiichi Tsukata
Cc: "James E.J. Bottomley&
the allowed count(scmd->allowed) is currently used as finite retry
limit count. Once retry count exceeds the allowed count on a device,
the message is suppressed on the device to avoid too much messages
outputted in dmesg.
---
Eiichi Tsukata (1):
scsi: Add printk to detect retry loop
(2013/08/23 21:26), Ric Wheeler wrote:
On 08/23/2013 05:10 AM, Eiichi Tsukata wrote:
(2013/08/21 3:09), Ewan Milne wrote:
On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote:
(2013/08/19 23:30), James Bottomley wrote:
On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote:
Hello,
This
(2013/08/24 4:36), Ewan Milne wrote:
On Fri, 2013-08-23 at 06:19 -0700, James Bottomley wrote:
On Fri, 2013-08-23 at 18:10 +0900, Eiichi Tsukata wrote:
Yes, basically the device should be offlined on error detection.
Just offlining the disk is enough when an error occurs on "not" os
(2013/08/23 22:19), James Bottomley wrote:
On Fri, 2013-08-23 at 18:10 +0900, Eiichi Tsukata wrote:
(2013/08/21 3:09), Ewan Milne wrote:
On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote:
(2013/08/19 23:30), James Bottomley wrote:
On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote
(2013/08/21 3:09), Ewan Milne wrote:
On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote:
(2013/08/19 23:30), James Bottomley wrote:
On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote:
Hello,
This patch adds scsi device failfast mode to avoid infinite retry loop.
Currently, scsi
(2013/08/19 23:30), James Bottomley wrote:
On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote:
Hello,
This patch adds scsi device failfast mode to avoid infinite retry loop.
Currently, scsi error handling in scsi_decide_disposition() and
scsi_io_completion() unconditionally retries on
some errors but
too few on other errors.
Which would be the appropriate implementation?
Any comments or suggestions are welcome as usual.
Signed-off-by: Eiichi Tsukata
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
14 matches
Mail list logo
