[GIT PULL] Final round of SCSI updates for the 3.9+ merge window

2013-05-10 Thread James Bottomley
This is the final round of SCSI patches for the merge window. It consists mostly of driver updates (bnx2fc, ibmfc, fnic, lpfc, be2iscsi, pm80xx, qla4x and ipr). There's also the power management updates that complete the patches in Jens' tree, an iscsi refcounting problem fix from the last pull,

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Baruch Even
On Fri, May 10, 2013 at 11:18 PM, Hannes Reinecke wrote: > On 05/10/2013 07:51 PM, Baruch Even wrote: >> >> The error handling I have in mind (admittedly, not fully thought out) >> should work for both FC and SAS. Currently the error recovery >> progresses at the host level regardless of if the er

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Hannes Reinecke
On 05/10/2013 07:51 PM, Baruch Even wrote: On Fri, May 10, 2013 at 5:01 PM, Ewan Milne wrote: On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: On Fri, May 10, 2013 at 3:43 PM, Ewan Milne wrote: On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: Introduce eh_timeout which can

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Baruch Even
On Fri, May 10, 2013 at 5:53 PM, Martin K. Petersen wrote: >> "Baruch" == Baruch Even writes: > > Baruch> Actually reducing the timeouts is probably not a good approach > Baruch> since it will cause the host to take a more radical approach > Baruch> without waiting sufficiently for a potentia

Re: [PATCH 0/3] Update the driver version to 3.2.21.1

2013-05-10 Thread James Bottomley
On Fri, 2013-05-10 at 10:03 -0700, Rasesh Mody wrote: > Vijay, > > Although we intend to update the driver version to 3.2.21.1, patch 0 > mentions version as v3.2.21.0. We may get away with it as it's a > trivial miss, however we should take care of such things in future > submissions. The patch

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Baruch Even
On Fri, May 10, 2013 at 5:01 PM, Ewan Milne wrote: > On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: >> On Fri, May 10, 2013 at 3:43 PM, Ewan Milne wrote: >> > >> > On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: >> > > Introduce eh_timeout which can be used for error handling

RE: [PATCH 0/3] Update the driver version to 3.2.21.1

2013-05-10 Thread Rasesh Mody
Vijay, Although we intend to update the driver version to 3.2.21.1, patch 0 mentions version as v3.2.21.0. We may get away with it as it's a trivial miss, however we should take care of such things in future submissions. Thanks Rasesh >-Original Message- >From: Vijay Mohan Guvva >Sent

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Ewan Milne
On Fri, 2013-05-10 at 16:24 +0200, Hannes Reinecke wrote: > On 05/10/2013 04:01 PM, Ewan Milne wrote: > > On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: > >> On Fri, May 10, 2013 at 3:43 PM, Ewan Milne wrote: > >>> > >>> On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: > I

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Martin K. Petersen
> "Martin" == Martin K Petersen writes: Martin> I'm also working on a patch to add some heuristics to avoid the Martin> HBA and bus resets Or rather: Defer the HBA and bus resets... Martin> if I/O is completing successfully on other attached targets. But Martin> that's an orthogonal issue.

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Martin K. Petersen
> "Baruch" == Baruch Even writes: Baruch> Actually reducing the timeouts is probably not a good approach Baruch> since it will cause the host to take a more radical approach Baruch> without waiting sufficiently for a potential recovery. Reducing the eh timeout is a requirement in many cluste

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Martin K. Petersen
> "Bart" == Bart Van Assche writes: Bart> Have you considered to move the eh_timeout assignment statement to Bart> just before the transport_configure_device() and slave_configure() Bart> calls ? That would allow transport drivers and LLD drivers to Bart> override the default eh_timeout valu

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Bryn M. Reeves
On 05/10/2013 03:24 PM, Hannes Reinecke wrote: However, this time is only defined _on the initiator_. The specification does _NOT_ have any fixed timeout values for _any_ command. As such it could in theory (and does, if you happen to run against certain arrays under certain conditions) take seve

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Hannes Reinecke
On 05/10/2013 04:01 PM, Ewan Milne wrote: > On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: >> On Fri, May 10, 2013 at 3:43 PM, Ewan Milne wrote: >>> >>> On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: Introduce eh_timeout which can be used for error handling purposes. This

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Ewan Milne
On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: > On Fri, May 10, 2013 at 3:43 PM, Ewan Milne wrote: > > > > On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: > > > Introduce eh_timeout which can be used for error handling purposes. This > > > was previously hardcoded to 10 second

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Baruch Even
On Fri, May 10, 2013 at 3:43 PM, Ewan Milne wrote: > > On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: > > Introduce eh_timeout which can be used for error handling purposes. This > > was previously hardcoded to 10 seconds in the SCSI error handling > > code. However, for some fast-fa

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Bryn M. Reeves
On 05/10/2013 01:43 PM, Ewan Milne wrote: On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: Introduce eh_timeout which can be used for error handling purposes. This was previously hardcoded to 10 seconds in the SCSI error handling code. However, for some fast-fail scenarios it is nece

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Hannes Reinecke
On 05/10/2013 02:43 PM, Ewan Milne wrote: > On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: >> Introduce eh_timeout which can be used for error handling purposes. This >> was previously hardcoded to 10 seconds in the SCSI error handling >> code. However, for some fast-fail scenarios it

Re: [PATCH] scsi: Allow error handling timeout to be specified

2013-05-10 Thread Ewan Milne
On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: > Introduce eh_timeout which can be used for error handling purposes. This > was previously hardcoded to 10 seconds in the SCSI error handling > code. However, for some fast-fail scenarios it is necessary to be able > to tune this as it c

[PATCH resend] scsi: ufs: use devres functions for ufshcd

2013-05-10 Thread Seungwon Jeon
This patches replaces normal calls for resource allocation with devm_*() derivative functions. It makes the routine to free resources simpler. Signed-off-by: Seungwon Jeon --- drivers/scsi/ufs/ufshcd-pci.c|1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 72 +

RE: [PATCH] scsi: ufs: use devres functions for ufshcd

2013-05-10 Thread Seungwon Jeon
Please ignore this one which is wrong sending. Friday, May 10, 2013, Seungwon Jeon wrote: > This patches replaces normal calls for resource allocation with devm_*() > derivative functions. It makes the routine to free resources simpler. > > Signed-off-by: Seungwon Jeon > --- > drivers/scsi/ufs/

[PATCH] scsi: ufs: use devres functions for ufshcd

2013-05-10 Thread Seungwon Jeon
This patches replaces normal calls for resource allocation with devm_*() derivative functions. It makes the routine to free resources simpler. Signed-off-by: Seungwon Jeon --- drivers/scsi/ufs/ufshcd-pci.c|1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 69 +

[PATCH] sd: avoid deadlocks when running under multipath

2013-05-10 Thread Hannes Reinecke
When multipathed systems run into an all-paths-down scenario all devices might be dropped, too. This causes 'del_gendisk' to be called, which will unregister the kobj_map->probe() function for all disk device numbers. When the device comes back the default ->probe() function is run which will call