aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/scsi/ibmvscsi
Commit message (Collapse)AuthorAge
* includecheck fix: drivers/scsi, ibmvscsi.cJaswinder Singh Rajput2009-09-20
| | | | | | | | | | | | fix the following 'make includecheck' warning: drivers/scsi/ibmvscsi/ibmvscsi.c: asm/firmware.h is included more than once. Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Sam Ravnborg <sam@ravnborg.org> LKML-Reference: <1247067016.4382.78.camel@ht.satnam> Acked-by: Brian King <brking@linux.vnet.ibm.com>
* [SCSI] ibmvscsi: avoid unnecessary use of kzalloc_poolSage Weil2009-08-22
| | | | | | | | | | The allocated struct is manually zeroed after allocation, so avoid using the (broken) kzalloc mempool (which does not re-zero previously used items when they are returned to the pool). Acked-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Sage Weil <sage@newdream.net> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
* [SCSI] ibmvscsi: Fix module load hangBrian King2009-06-25
| | | | | | | | | | | Fixes a regression seen in the ibmvscsi driver when using the VSCSI server in SLES 9 and SLES 10. The VSCSI server in these releases has a bug in it in which it does not send responses to unknown MADs. Check the OS Type field in the adapter info response and do not send these unsupported commands when talking to an older server. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* ibmvfc: Fix endless PRLI loop in discoveryBrian King2009-06-21
| | | | | | | | | | | | Fixes a problem seen where sending a PRLI to a target resulted in it sending a LOGO. This caused the ibmvfc driver to go back through discovery again, which caused another PRLI attempt, which caused another LOGO. Fix this behavior by ignoring LOGO if we haven't even logged into the target yet. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* ibmvfc: Process async events before command responsesBrian King2009-06-21
| | | | | | | | | Since async events could indicate changes to link status, or events which could affect decisions made during discovery, we should process async events prior to command completion responses. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* ibmvscsi: gadget: at91_udc: remove driver_data direct access of struct deviceGreg Kroah-Hartman2009-06-16
| | | | | | | | | | | | | | | In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux-scsi@vger.kernel.org Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Robert Jennings <rcj@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [SCSI] ibmvscsi: Add support for capabilities MADBrian King2009-06-08
| | | | | | | | | | | | | | Add support to ibmvscsi for the capabilities MAD. This command gets sent to the Virtual I/O server prior to login in order to communicate client capabilities. Additionally it returns information regarding capabilities that the server supports. The two main capabilities communicated in this MAD are related to partition migration and client reserve. Client reserve allows for SCSI-2 reservations to be sent to virtual disks which are backed by physical LUNs and will result in the reservation being sent to the physical LUN. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Enable fast fail featureRobert Jennings2009-06-08
| | | | | | | | | | | | | | | | | | A new mode of error reporting, fast fail, has been added to the VIOS which allows failover to happen more quickly. If this new fast fail mode is enabled on the VIOS and the vSCSI client supports the mode, the VIOS will not return MEDIUM error on path failures, but rather return VIOSRP_ADAPTER_FAIL in the crq response, which ibmvscsi will translate to DID_ERROR. This new mode can be enabled for single path configurations as well, so it is the new default error reporting mode. A module parameter is provided to disable this new behavior on the off chance it causes a problem on some old VIOS version. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Send adapter info before loginBrian King2009-06-08
| | | | | | | | | | The ibmvscsi driver currently sends the SRP Login before sending the Adapter Info MAD, which can result in commands getting sent to the virtual adapter before we are ready for them. This results in a slight window where the target devices may not behave as expected. Change the order and close the window. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Add specific timeouts for operationsRobert Jennings2009-06-08
| | | | | | | | | Previously we had one timeout that was used for all types of operations. This adds specific timeout values for different operations (init, login, adapter info MAD, abort task, and LUN reset). Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Add 16 byte CDB supportBrian King2009-06-08
| | | | | | | Adds support for 16 byte CDBs to the ibmvscsi driver. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Driver version 1.0.6Brian King2009-06-08
| | | | | | | Bump driver version Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Improve LOGO/PRLO ELS handlingBrian King2009-06-08
| | | | | | | | | | | | | There are several scenarios where the ibmvfc driver needs to try to log back into a target on the fabric. Today when these events occur, we simply go through re-discovery for all attached targets, assuming that either the query of the name server or an ADISC will indicate we might need to log back into the target, which doesn't work for all scenarios. Fix this by taking note of the affected target(s) in these conditions and ensuring we try to PLOGI back into the target. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Improve device rediscoveryBrian King2009-06-08
| | | | | | | | | | | For certain scenarios during device rediscovery, we detect we need to log back into a target. Currently we do just that - PLOGI/PRLI back into the target. Change the code to delete and add the target from the FC transport layer as well, to ensure we handle any cases where the target may have changed. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Add flush on halt supportBrian King2009-06-08
| | | | | | | | | | | | | The virtual I/O server controlling the NPIV adapter associated with a virtual fibre channel adapter can send a HALT event to the client. When this occurs, the client can no longer send commands until a RESUME is received. By adding support for flush on halt, we will get all of our outstanding commands flushed back before the Virtual I/O server enters the halt state, eliminating potential command timeouts for outstanding commands which might occur if we did not support this feature. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Add support for NPIV LogoutBrian King2009-06-08
| | | | | | | | | | | | This patch adds support for a new command supported by the Virtual I/O Server, NPIV Logout. The command will abort all outstanding commands and log out of the fabric. Currently, the only way to do this is by breaking the CRQ, which can take a fairly long time when lots of commands are outstanding. The NPIV Logout commands provides a mechanism to accomplish virtually the same function, but is much faster. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix deadlock in EHBrian King2009-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following deadlock scenario shown below. We currently allow queuecommand to send commands when the ibmvfc workqueue is scanning for new rports, so we should also allow EH to function at this time as well. scsi_eh_3 D 0000000000000000 12304 1279 2 Call Trace: [c0000002f7257730] [c0000002f72577e0] 0xc0000002f72577e0 (unreliable) [c0000002f7257900] [c0000000000118f4] .__switch_to+0x158/0x1a0 [c0000002f72579a0] [c0000000004f8b40] .schedule+0x8d4/0x9dc [c0000002f7257b60] [c0000000004f8f08] .schedule_timeout+0xa8/0xe8 [c0000002f7257c50] [d0000000001d23e0] .ibmvfc_wait_while_resetting+0xe4/0x140 [ibmvfc] [c0000002f7257d20] [d0000000001d3984] .ibmvfc_eh_abort_handler+0x60/0xe4 [ibmvfc] [c0000002f7257dc0] [d000000000366714] .scsi_error_handler+0x38c/0x674 [scsi_mod] [c0000002f7257f00] [c0000000000a7470] .kthread+0x78/0xc4 [c0000002f7257f90] [c000000000029b8c] .kernel_thread+0x4c/0x68 ibmvfc_3 D 0000000000000000 12432 1280 2 Call Trace: [c0000002f7253540] [c0000002f72535f0] 0xc0000002f72535f0 (unreliable) [c0000002f7253710] [c0000000000118f4] .__switch_to+0x158/0x1a0 [c0000002f72537b0] [c0000000004f8b40] .schedule+0x8d4/0x9dc [c0000002f7253970] [c0000000004f8e98] .schedule_timeout+0x38/0xe8 [c0000002f7253a60] [c0000000004f80cc] .wait_for_common+0x138/0x220 [c0000002f7253b40] [c0000000000a2784] .flush_cpu_workqueue+0xac/0xcc [c0000002f7253c10] [c0000000000a2960] .flush_workqueue+0x58/0xa0 [c0000002f7253ca0] [d0000000000827fc] .fc_flush_work+0x4c/0x64 [scsi_transport_fc] [c0000002f7253d20] [d000000000082db4] .fc_remote_port_add+0x48/0x6c4 [scsi_transport_fc] [c0000002f7253dd0] [d0000000001d7d04] .ibmvfc_work+0x820/0xa7c [ibmvfc] [c0000002f7253f00] [c0000000000a7470] .kthread+0x78/0xc4 [c0000002f7253f90] [c000000000029b8c] .kernel_thread+0x4c/0x68 fc_wq_3 D 0000000000000000 10720 1283 2 Call Trace: [c0000002f559ac30] [c0000002f559ace0] 0xc0000002f559ace0 (unreliable) [c0000002f559ae00] [c0000000000118f4] .__switch_to+0x158/0x1a0 [c0000002f559aea0] [c0000000004f8b40] .schedule+0x8d4/0x9dc [c0000002f559b060] [c0000000004f8e98] .schedule_timeout+0x38/0xe8 [c0000002f559b150] [c0000000004f80cc] .wait_for_common+0x138/0x220 [c0000002f559b230] [c0000000002721c4] .blk_execute_rq+0xb4/0x100 [c0000002f559b360] [d00000000036a1f8] .scsi_execute+0x118/0x194 [scsi_mod] [c0000002f559b420] [d00000000036a32c] .scsi_execute_req+0xb8/0x124 [scsi_mod] [c0000002f559b500] [d0000000000c1330] .sd_sync_cache+0x8c/0x108 [sd_mod] [c0000002f559b5e0] [d0000000000c15b4] .sd_shutdown+0x9c/0x158 [sd_mod] [c0000002f559b660] [d0000000000c16d0] .sd_remove+0x60/0xb4 [sd_mod] [c0000002f559b700] [c000000000392ecc] .__device_release_driver+0xd0/0x118 [c0000002f559b7a0] [c000000000393080] .device_release_driver+0x30/0x54 [c0000002f559b830] [c000000000392108] .bus_remove_device+0x128/0x16c [c0000002f559b8d0] [c00000000038f94c] .device_del+0x158/0x234 [c0000002f559b960] [d00000000036f078] .__scsi_remove_device+0x5c/0xd4 [scsi_mod] [c0000002f559b9f0] [d00000000036f124] .scsi_remove_device+0x34/0x58 [scsi_mod] [c0000002f559ba80] [d00000000036f204] .__scsi_remove_target+0xb4/0x120 [scsi_mod] [c0000002f559bb10] [d00000000036f338] .__remove_child+0x2c/0x44 [scsi_mod] [c0000002f559bb90] [c00000000038f11c] .device_for_each_child+0x54/0xb4 [c0000002f559bc50] [d00000000036f2e0] .scsi_remove_target+0x70/0x9c [scsi_mod] [c0000002f559bce0] [d000000000083454] .fc_starget_delete+0x24/0x3c [scsi_transport_fc] [c0000002f559bd70] [c0000000000a2368] .run_workqueue+0x118/0x208 [c0000002f559be30] [c0000000000a2580] .worker_thread+0x128/0x154 [c0000002f559bf00] [c0000000000a7470] .kthread+0x78/0xc4 [c0000002f559bf90] [c000000000029b8c] .kernel_thread+0x4c/0x68 Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Reduce error logging noiseBrian King2009-06-08
| | | | | | | | | | | | | | The ibmvfc driver currently logs errors during discovery for several transient fabric errors, which generally get retried. If retries do not work, we see multiple errors in the log. If retries do work, we see errors in the log which may be confusing since the retry worked. This patch enhances the discovery time error logging to only log errors for command failures during discovery if all allowed retries have been used up. The existing behavior of logging all failures can be restored by setting the hosts log_level to a value of 3 or greater. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Use DEVICE_ATTR macroBrian King2009-06-08
| | | | | | | Use DEVICE_ATTR macro for defining device sysfs attributes. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fixup GFP flags for target allocationsBrian King2009-06-08
| | | | | | | | | Since target allocations can occur while resetting the virtual adapter, we shouldn't be using GFP_KERNEL for them as it could hang. Switch to use GFP_NOIO. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix invalid error response handlingBrian King2009-06-08
| | | | | | | | | Fix an obvious bug in processing error responses for SCSI commands which can result in successful responses being incorrectly returned with DID_ERROR. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Remove redundant test on unsigned.Roel Kluin2009-05-23
| | | | | | Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Driver version 1.0.5Brian King2009-04-03
| | | | | | | Bump driver version to 1.0.5. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Improve ADISC timeout handlingBrian King2009-04-03
| | | | | | | | | | | | The ibmvfc driver currently breaks the CRQ and essentially resets the entire virtual FC adapter, killing all outstanding ops to all attached targets, if an ADISC times out during target discover/rediscovery. This patch adds some code to cancel the ADISC if it times out, which prevents a single ADISC timeout from affecting the other devices attached to the fabric. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Show host maxframe_sizeBrian King2009-04-03
| | | | | | | | Set show_host_maxframe_size so that maxframe_size gets exported in sysfs for the host. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fixup module parms attributesBrian King2009-04-03
| | | | | | | | | | The ibmvfc driver really does not handle dynamically changing disc_threads. To change this dynamically would cause confusion in the driver regarding the number of event structs allocated. Fix this by simply not allowing disc_threads to be changed at runtime. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix dropped interruptsBrian King2009-04-03
| | | | | | | | | | | | | This patch fixes a problem of possible dropped interrupts. Currently, the ibmvfc driver has a race condition where after ibmvfc_interrupt gets run, the platform code clears the interrupt. This can result in lost interrupts and, in worst case scenarios, result in command timeouts. Fix this by implementing a tasklet similar to what the ibmvscsi driver does so that interrupt processing is no longer done in the actual interrupt handler, which eliminates the race. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Better handle other FC initiatorsBrian King2009-03-12
| | | | | | | | | | | | | | The ibmvfc driver currently always sets the role of all rports to FC_PORT_ROLE_FCP_TARGET, which is not correct for other initiators. This can cause problems if other initiators are on the fabric when we then try to scan the rport for LUNs. Fix this by looking at the service parameters returned in the PRLI to set the roles appropriately. Also look at the returned service parameters to decide whether or not we were actually able to successfully log into the target. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Increase cancel timeoutBrian King2009-02-10
| | | | | | | | | | | During cancel testing it has been shown that 15 seconds is not nearly long enough for the VIOS to respond to a cancel under loaded situations. Increasing this timeout to 60 seconds allows time for the VIOS to cancel the outstanding commands and prevents us from escalating to a full host reset, which can take much longer. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix rport reloginBrian King2009-02-10
| | | | | | | | | | | | | | The ibmvfc driver has a bug in its SCN handling. If it receives an ELS event such asn an N-Port SCN event or an unsolicited PLOGI, or any other SCN event which causes ibmvfc_reinit_host to be called, it is possible that we will call fc_remote_port_add for a target that already has an rport added, which can result in duplicate rports getting created for the same targets. Fix this by calling fc_remote_port_rolechg in this scenario instead to report any possible role change that may have occurred. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix command timeout errorsBrian King2009-02-10
| | | | | | | | | | | | Currently the ibmvfc driver sets the IBMVFC_CLASS_3_ERR flag in the VFC Frame if both the adapter and the device claim support for Class 3. However, this bit actually refers to Class 3 Error Recovery, which is currently not supported by the VIOS. Setting this bit can cause lots of command timeout responses from the VIOS resulting in general instability. Fix this by never setting this bit. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Correct DMA mapping leakRobert Jennings2009-02-10
| | | | | | | | | | | | The ibmvscsi client driver is not unmapping the SCSI command after encountering a DMA mapping error while trying to map an indirect scattergather list for the event pool. This leads to a leak of DMA entitlement that could result in the device failing future DMA operations in a CMO environment. Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com> Acked-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix DMA mapping leak on memory allocation failureBrian King2009-01-25
| | | | | | | | | | | | There is currently a DMA mapping leak that can occur in the ibmvfc driver if we fail to allocate a scatterlist. Fix this by unmapping the scatterlist in the failure path. Additionally, only log an error for a scatterlist allocation failure if the log level is greater than the default, since this can occur when running Active Memory Sharing and this is not considered an error. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* powerpc: Cleanup from l64 to ll64 change drivers/scsiStephen Rothwell2009-01-16
| | | | | | | This is a powerpc specific driver. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc: Change u64/s64 to a long long integer typeIngo Molnar2009-01-12
| | | | | | | | | | | | | | | | | | | | | | Convert arch/powerpc/ over to long long based u64: -#ifdef __powerpc64__ -# include <asm-generic/int-l64.h> -#else -# include <asm-generic/int-ll64.h> -#endif +#include <asm-generic/int-ll64.h> This will avoid reoccuring spurious warnings in core kernel code that comes when people test on their own hardware. (i.e. x86 in ~98% of the cases) This is what x86 uses and it generally helps keep 64-bit code 32-bit clean too. [Adjusted to not impact user mode (from paulus) - sfr] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* [SCSI] ibmvscsi: Make max_requests module parameter more accurateBrian King2009-01-02
| | | | | | | | | | | | In a previous patch to fix an issue with error recovery, the behavior of the max_requests module paramater was also changed. If, for some reason, max_requests is set to one by the user, we will end up with a negative number for can_queue. Fix this by making max_requests not include the two event structs needed to do error recovery. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fixup command response translationBrian King2009-01-02
| | | | | | | | | | | | If a link down event is received, outstanding commands may get returned to the ibmvfc driver with a "transaction cancelled implicit" response. This is currently translated to DID_ABORT, which does not get retried by SCSI core, but rather passes the failure up the stack. This can result in I/O errors at the filesystem level. Fix up this response a well as a few other error responses. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2009-01-02
| | | | | | | | [jejb: limit ioctl to returning 20 characters to avoid overrun on long device names and add a few more conversions] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Improve async event handlingBrian King2008-12-29
| | | | | | | | | | | | While doing various error injection testing, such as cable pulls and target moves, some issues were observed in handling these events. This patch improves the way these events are handled by increasing the delay waiting for the fabric to settle and also changes the behavior of Link Up to break the CRQ to ensure everything gets cleaned up properly on the VIOS. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvscsi: Don't fail EH due to insufficient resourcesBrian King2008-12-29
| | | | | | | | | | | | | | | The ibmvscsi driver currently has a bug in it which can result in it using up all its event structs for commands. If something results in all those commands timing out, we won't have any resources left to send aborts or resets. This results in escalating to a host reset in order to recover, which is a bit heavy handed. This fixes it by reducing can_queue by two in order to have resources to do EH. It also changes the max_requests module parameter so that it is not writable at runtime, since the code really does not handle it changing at runtime. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix errors due to inconsistent command dataBrian King2008-12-29
| | | | | | | | | In order to ensure the VIOS sees a consistent command buffer, we need to add a memory barrier after building the command buffer but before sending the command. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Delay NPIV login retry and add retriesBrian King2008-12-29
| | | | | | | | | | | | | Adds a delay prior to retrying a failed NPIV login. This fixes a scenario if the backing fibre channel adapter is getting reset due to an EEH event, NPIV login will fail. Currently, ibmvfc retries three times very quickly, resets the CRQ and tries one more time. If the adapter is getting reset due to EEH, this isn't enough time. This adds a delay prior to retrying a failed NPIV login and also increments the number of retries. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Driver version 1.0.4Brian King2008-12-29
| | | | | | | Bump driver version Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Handle port login required responseBrian King2008-12-29
| | | | | | | | | The virtual fibre channel stack can return a failure response for a command indicating the port login has been invalidated without sending the client an async event. Add code to handle this response and initiate a PLOGI. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix command timeouts due to cached CRQ accessBrian King2008-12-29
| | | | | | | | | | | | | The CRQs used by the ibmvfc driver are read and written by both the client and the server. Therefore, we need to mark them volatile so that we do not cache their contents when handling an interrupt. This fixes a problem which can surface as occasional command timeouts. No commands were actually timing out, but due to accessing cached data for the CRQ in the interrupt handler, the interrupt was not processing all command completions as it should. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix oops in interrupt handlerBrian King2008-12-29
| | | | | | | | Fixes an oops that can occur in the interrupt handler if we get a lot of async events. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Driver version 1.0.3Brian King2008-12-29
| | | | | | | Bump driver version. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Quiet gcc warning in ibmvfc_reset_deviceBrian King2008-12-29
| | | | | | | | Stops gcc from complaining about a possible uninitialized variable being used in ibmvfc_reset_device. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Fix target initialization failure retry handlingBrian King2008-12-29
| | | | | | | | | | | | | | | | If the ibmvfc driver is in discovery attempting to log into a target and it encounters an error, the command may get retried one or more times, depending on the error received. If the retries are unsuccessful such that the discovery thread gives up on discovery to that target, the target ends up in a state where, if SCSI core had previously known about the device, the host will get unblocked but the host will not be logged into the target, causing any commands sent to the target to fail. This patch fixes this so that if this occurs, the target is deleted such that the normal dev_loss processing can occur instead. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* [SCSI] ibmvfc: Error handling fixesBrian King2008-12-29
| | | | | | | | | | | | | | | Due to an ambiguity in the VIOS VFC interface specification, abort/cancel handling is not done correctly and can result in double completion of commands. In order to cancel all outstanding commands to a device, a cancel must be sent, followed by an abort task set. After the responses are received for these commands, there may still be commands outstanding, in the process of getting flushed back, in which case, we need to wait for them. This patch removes the assumption that if the abort and the cancel both complete successfully that the device queue has been flushed and waits for all the responses to come back. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>