On 09/25/2013 07:48 AM, Hannes Reinecke wrote:
On 09/24/2013 10:51 PM, Ric Wheeler wrote:
On 08/29/2013 09:06 AM, Hannes Reinecke wrote:
Hi James,
On 08/07/2013 08:43 AM, Ren Mingxin wrote:
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this
On 08/29/2013 09:06 AM, Hannes Reinecke wrote:
Hi James,
On 08/07/2013 08:43 AM, Ren Mingxin wrote:
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewan D. Milneemi...@redhat.com
Do you think this patchset can be applied?
On 09/24/2013 10:51 PM, Ric Wheeler wrote:
On 08/29/2013 09:06 AM, Hannes Reinecke wrote:
Hi James,
On 08/07/2013 08:43 AM, Ren Mingxin wrote:
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewan D. Milneemi...@redhat.com
Hi James,
On 08/07/2013 08:43 AM, Ren Mingxin wrote:
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewan D. Milneemi...@redhat.com
Do you think this patchset can be applied? If so, When? Perhaps you
are waiting for
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewan D. Milneemi...@redhat.com
Do you think this patchset can be applied? If so, When? Perhaps you
are waiting for someone's feedback?
We've also tested and got the duration
Hi, Hannes:
On 07/15/2013 06:33 PM, Ren Mingxin wrote:
I noticed that the dd time had been reduced from 6m+ to 2m+ when the
'eh_deadline' was set as 30s, but the dd time was 6m+(nearly the same
as default - 'eh_deadline' was 0) when the 'eh_deadline' was set as
10s. I havn't been able to dig
Hi, Ewan:
On 07/12/2013 09:30 PM, Ewan Milne wrote:
On Fri, 2013-07-12 at 13:54 +0800, Ren Mingxin wrote:
I'm wondering how do you test, with a special hardware or self-made
module?Would you mind pasting your test method() and result?
This was tested in a SAN environment with an EMC Symmetrix
On Fri, 2013-07-12 at 13:54 +0800, Ren Mingxin wrote:
Hi, Ewan:
I'm wondering how do you test, with a special hardware or self-made
module?Would you mind pasting your test method() and result?
Hi Rex-
This was tested in a SAN environment with an EMC Symmetrix and
Brocade FC switches. The
Hi, Ewan:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
On Mon, 2013-07-01 at 08:50 +0200, Hannes Reinecke wrote:
This patchset implements a new 'eh_deadline' attribute to the
SCSI host. It will limit the overall SCSI EH runtime by a given
timeout. If the timeout is reached all intermediate EH
On Mon, 2013-07-01 at 08:50 +0200, Hannes Reinecke wrote:
This patchset implements a new 'eh_deadline' attribute to the
SCSI host. It will limit the overall SCSI EH runtime by a given
timeout. If the timeout is reached all intermediate EH steps
will be skipped and host reset will be scheduled
On Mon, 2013-07-01 at 16:55 -0400, Jörn Engel wrote:
On Mon, 1 July 2013 19:23:25 +, James Bottomley wrote:
On Mon, 2013-07-01 at 13:44 -0400, Jörn Engel wrote:
If a single device is bad, don't ever do a host
reset.
This isn't a tenable position. Sometimes a device looks bad
On Tue, 2 July 2013 06:37:05 +, James Bottomley wrote:
I don't understand what you're getting at. In a dual HBA situation,
whether the second HBA is implicated or not depends on configuration and
what the first HBA is doing. If it's just passively lost device state,
then the second HBA
On Tue, 2013-07-02 at 10:58 -0400, Jörn Engel wrote:
On Tue, 2 July 2013 06:37:05 +, James Bottomley wrote:
I don't understand what you're getting at. In a dual HBA situation,
whether the second HBA is implicated or not depends on configuration and
what the first HBA is doing. If
On Tue, 2 July 2013 16:33:40 +, James Bottomley wrote:
On Tue, 2013-07-02 at 10:58 -0400, Jörn Engel wrote:
On Tue, 2 July 2013 06:37:05 +, James Bottomley wrote:
I don't understand what you're getting at. In a dual HBA situation,
whether the second HBA is implicated or not
On Mon, 1 July 2013 08:50:48 +0200, Hannes Reinecke wrote:
This patchset implements a new 'eh_deadline' attribute to the
SCSI host. It will limit the overall SCSI EH runtime by a given
timeout. If the timeout is reached all intermediate EH steps
will be skipped and host reset will be
On Mon, 2013-07-01 at 13:44 -0400, Jörn Engel wrote:
If a single device is bad, don't ever do a host
reset.
This isn't a tenable position. Sometimes a device looks bad because the
host state for it has gone insane. At that point, the only safe action
is a reset of the host to sane state.
I
On Mon, 1 July 2013 19:23:25 +, James Bottomley wrote:
On Mon, 2013-07-01 at 13:44 -0400, Jörn Engel wrote:
If a single device is bad, don't ever do a host
reset.
This isn't a tenable position. Sometimes a device looks bad because the
host state for it has gone insane. At that
On 07/01/2013 10:55 PM, Jörn Engel wrote:
On Mon, 1 July 2013 19:23:25 +, James Bottomley wrote:
On Mon, 2013-07-01 at 13:44 -0400, Jörn Engel wrote:
If a single device is bad, don't ever do a host
reset.
This isn't a tenable position. Sometimes a device looks bad because the
host
18 matches
Mail list logo
