Re: [PATCH V2 1/1] scsi: Handle MLQUEUE busy response in scsi_send_eh_cmnd

2013-04-23 Thread Hannes Reinecke
On 04/16/2013 10:26 PM, wenxi...@linux.vnet.ibm.com wrote: We discussed James's concern. We intergated James's patch and generated this updated patch. Fix scsi_send_eh_cmnd to check the return code of queuecommand when sending commands and retry for a bit if the LLDD returns a busy response.

[PATCH] libcxgbi: supress warning when we request to much space from kmalloc

2013-04-23 Thread Neil Horman
cxgbi_alloc_big_mem allocates large chunks of memory, and can occasionally request amounts from kmalloc that exceed the allocators capacity. This typically leads to a stack trace from the zoned buddy allocator in the message log. But if kmalloc fails, cxgbi_alloc_big_mem backs off and uses

[PATCH 1/1] scsi: ufs: Generalize UFS Interconnect Layer (UIC) command support

2013-04-23 Thread Sujit Reddy Thumma
Currently, only DME_LINKSTARTUP UIC command is fully supported, generalize this to send any UIC command. A new uic_cmd_mutex is introduced and the callers are expected to hold this mutex lock before preparing and sending UIC command as the specification doesn't allow more than one UIC command at a

[PATCH v2] qla2xxx: Fix for locking issue between driver ISR and mailbox routines

2013-04-23 Thread gurinder . shergill
The driver uses ha-mbx_cmd_flags variable to pass information between its ISR and mailbox routines, however, it does so without the protection of any locks. Under certain conditions, this can lead to multiple mailbox command completions being signaled, which, in turn, leads to a false mailbox

[PATCH 1/1] cciss: bug fix to prevent cciss from loading in kdump crash kernel

2013-04-23 Thread Mike Miller
PATCH 1/1 By default the cciss driver supports all older HP Smart Array controllers and hpsa supports all controllers starting with the G6 family. There are module parameters that allow a user to override those defaults and use hpsa for any HP Smart Array controller. If the user does override the

T10 WCE interpretation in Linux device level access

2013-04-23 Thread Ric Wheeler
For many years, we have used WCE as an indication that a device has a volatile write cache (not just a write cache) and used this as a trigger to send down SYNCHRONIZE_CACHE commands as needed. Some arrays with non-volatile cache seem to have WCE set and simply ignore the command. Some

Re: T10 WCE interpretation in Linux device level access

2013-04-23 Thread James Bottomley
On Tue, 2013-04-23 at 15:41 -0400, Ric Wheeler wrote: For many years, we have used WCE as an indication that a device has a volatile write cache (not just a write cache) and used this as a trigger to send down SYNCHRONIZE_CACHE commands as needed. Some arrays with non-volatile cache seem

Re: T10 WCE interpretation in Linux device level access

2013-04-23 Thread Douglas Gilbert
On 13-04-23 03:41 PM, Ric Wheeler wrote: For many years, we have used WCE as an indication that a device has a volatile write cache (not just a write cache) and used this as a trigger to send down SYNCHRONIZE_CACHE commands as needed. Some arrays with non-volatile cache seem to have WCE set

Re: T10 WCE interpretation in Linux device level access

2013-04-23 Thread Jeremy Linton
On 4/23/2013 3:07 PM, James Bottomley wrote: I bet they don't; they probably obey the spec. There's a SYNC_NV bit which if unset (which it is in our implementation) means only sync your non-NV cache. For a device with all NV, that equates to nop. Yes, linux leaves the SYNC_NV bit

RE: T10 WCE interpretation in Linux device level access

2013-04-23 Thread Elliott, Robert (Server Storage)
If the writeback cache is enabled (per the WCE bit in the Caching mode page), prudent software uses the FUA bit in WRITE commands when writing metadata and/or sends the SYNCHRONIZE CACHE command at important checkpoints to ensure the data is not going to be lost due to a power loss. Some