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

2013-05-10 Thread Bart Van Assche
On 05/10/13 05:11, 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 can take several

[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

[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 tgih@samsung.com --- drivers/scsi/ufs/ufshcd-pci.c|1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 69

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 tgih@samsung.com ---

[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 tgih@samsung.com --- drivers/scsi/ufs/ufshcd-pci.c|1 - drivers/scsi/ufs/ufshcd-pltfrm.c | 72

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 can

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 is

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

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 emi...@redhat.com 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

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 emi...@redhat.com 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

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 emi...@redhat.com 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.

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

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

2013-05-10 Thread Martin K. Petersen
Bart == Bart Van Assche bvanass...@acm.org 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

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

2013-05-10 Thread Martin K. Petersen
Baruch == Baruch Even bar...@ev-en.org 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

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 emi...@redhat.com wrote: On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote:

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 Baruch Even
On Fri, May 10, 2013 at 5:01 PM, Ewan Milne emi...@redhat.com wrote: On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: On Fri, May 10, 2013 at 3:43 PM, Ewan Milne emi...@redhat.com wrote: On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen wrote: Introduce eh_timeout which can be

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:53 PM, Martin K. Petersen martin.peter...@oracle.com wrote: Baruch == Baruch Even bar...@ev-en.org 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

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 emi...@redhat.com wrote: On Fri, 2013-05-10 at 16:22 +0300, Baruch Even wrote: On Fri, May 10, 2013 at 3:43 PM, Ewan Milne emi...@redhat.com wrote: On Thu, 2013-05-09 at 23:11 -0400, Martin K. Petersen

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 h...@suse.de 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

[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,