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 extensive
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: Ewa
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. Milne
Do you think this patchset can be applied? If so, When? Perhap
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. Milne
>
> Do you think this patchset can be applied? If so, When? Perhaps you
> are waiting for someone's
Hi, James:
On 07/11/2013 04:35 AM, Ewan Milne wrote:
Looks good. We have been testing this extensively.
Acked-by: Ewan D. Milne
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 could be shortened f
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 fur
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. Th
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 step
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 schedul
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 implicat
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 doin
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
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 l
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 th
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 tha
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 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 sch
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 immediately.
For this patch I've re-used the existing 'last_re
19 matches
Mail list logo