- 17 May, 2012 27 commits
-
-
James Smart authored
Signed-off-by:
Alex Iannicelli <alex.iannicelli@emulex.com> Signed-off-by:
James Smart <james.smart@emulex.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Signed-off-by:
-
Jörn Engel authored
Signed-off-by:
Joern Engel <joern@logfs.org> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Jörn Engel authored
With the exception of the detached field, sg_mutex no longer adds any locking. detached handling has been broken before and is still broken and this patch does not seem to make things worse than they were to begin with. However, I have observed cases of tasks being blocked for >200s waiting for sg_mutex. So the removal clearly adds value for very little cost. Signed-off-by:
-
Jörn Engel authored
sfds is protected by sg_index_lock - except for sg_open(), where it isn't. Change that and add some documentation. Signed-off-by:
-
Jörn Engel authored
Changes since v1: set_exclude now returns the new value, which gets rid of the comma expression and the operator precedence bug. Thanks to Douglas for spotting it. sdp->exclude was previously protected by the BKL. The sg_mutex, which replaced the BKL, only semi-protected it, as it was missing from sg_release() and sg_proc_seq_show_debug(). Take an explicit spinlock for it. Signed-off-by:
-
Jörn Engel authored
srp->done is protected by sfp->rq_list_lock everywhere, except for this one case. Result can be that the wake-up happens before the cacheline with the changed srp->done has arrived, so the waiter can go back to sleep and never be woken up again. The wait_event_interruptible() means that anyone trying to debug this unlikely race will likely notice everything working fine again, as the next signal will unwedge things. Evil. Signed-off-by:
-
Jörn Engel authored
After sg_release() has been called, noone should be able to actually use that filedescriptor anymore. So if closed ever made a difference in the past five years or so, it would have meant a bug. Remove it. Signed-off-by:
-
Jörn Engel authored
Afaics the use of __wait_event_interruptible() as opposed to wait_event_interruptible() is purely historic. So let's follow the rest of the kernel and check the condition before prepare_to_wait() - and also make the code a bit nicer. Signed-off-by:
-
Jörn Engel authored
The while (1) construct isn't actually a loop at all. So let's not pretent and obfuscate the code. Signed-off-by:
-
Jörn Engel authored
blocking is de-facto a constant and the now-removed comment wasn't all that useful either. Without them and the resulting indentation the code is a bit nicer to read. Signed-off-by:
-
Dan Williams authored
sd injects and synchronizes probe work on the global kernel-wide domain. This runs into conflict with PM that wants to perform resume actions in async context: [ 494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds. [ 494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 494.360809] kworker/u:3 D 0000000000000000 0 554 2 0x00000000 [ 494.420739] ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8 [ 494.484392] ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160 [ 494.548038] ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398 [ 494.611685] Call Trace: [ 494.632649] [<ffffffff8149dd25>] schedule+0x5a/0x5c [ 494.674687] [<ffffffff8104b968>] async_synchronize_cookie_domain+0xb6/0x112 [ 494.734177] [<ffffffff810461ff>] ? __init_waitqueue_head+0x50/0x50 [ 494.787134] [<ffffffff8131a224>] ? scsi_remove_target+0x48/0x48 [ 494.837900] [<ffffffff8104b9d9>] async_synchronize_cookie+0x15/0x17 [ 494.891567] [<ffffffff8104ba49>] async_synchronize_full+0x54/0x70 <-- here we wait for async contexts to complete [ 494.943783] [<ffffffff8104b9f5>] ? async_synchronize_full_domain+0x1a/0x1a [ 495.002547] [<ffffffffa00114b1>] sd_remove+0x2c/0xa2 [sd_mod] [ 495.051861] [<ffffffff812fe94f>] __device_release_driver+0x86/0xcf [ 495.104807] [<ffffffff812fe9bd>] device_release_driver+0x25/0x32 <-- here we take device_lock() [ 853.511341] INFO: task kworker/u:4:549 blocked for more than 120 seconds. [ 853.568693] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 853.635119] kworker/u:4 D ffff88013097b5d0 0 549 2 0x00000000 [ 853.695129] ffff880132773c40 0000000000000046 ffff880130790000 ffff880132773fd8 [ 853.758990] ffff880132773fd8 0000000000012500 ffff88013288a0b0 ffff880130790000 [ 853.822796] 0000000000000246 0000000000000040 ffff88013097b5c8 ffff880130790000 [ 853.886633] Call Trace: [ 853.907631] [<ffffffff8149dd25>] schedule+0x5a/0x5c [ 853.949670] [<ffffffff8149cc44>] __mutex_lock_common+0x220/0x351 [ 854.001225] [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4 [ 854.049082] [<ffffffff81304bd7>] ? device_resume+0x58/0x1c4 [ 854.097011] [<ffffffff8149ce48>] mutex_lock_nested+0x2f/0x36 <-- here we wait for device_lock() [ 854.145591] [<ffffffff81304bd7>] device_resume+0x58/0x1c4 [ 854.192066] [<ffffffff81304d61>] async_resume+0x1e/0x45 [ 854.237019] [<ffffffff8104bc93>] async_run_entry_fn+0xc6/0x173 <-- ...while running in async context Provide a 'scsi_sd_probe_domain' so that async probe actions actions can be flushed without regard for the state of PM, and allow for the resume path to handle devices that have transitioned from SDEV_QUIESCE to SDEV_DEL prior to resume. Acked-by:
Alan Stern <stern@rowland.harvard.edu> [alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume] Signed-off-by:
Dan Williams <dan.j.williams@intel.com> [jejb: remove unneeded config guards in include file] Signed-off-by:
-
- 10 May, 2012 13 commits
-
-
Stephen M. Cameron authored
Dial back the aggressiveness of the controller lockup detection thread. Currently it will declare the controller to be locked up if it goes for 10 seconds with no interrupts and no change in the heartbeat register. Dial back this to 30 seconds with no heartbeat change, and also snoop the ioctl path and if a firmware flash command is detected, dial it back further to 4 minutes until the firmware flash command completes. The reason for this is that during the firmware flash operation, the controller apparently doesn't update the heartbeat register as frequently as it is supposed to, and we can get a false positive. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Mike Miller authored
Signed-off-by:
Mike Miller <mikem@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Matt Gates authored
Use spinlocks with finer granularity in the submission and completion paths to allow concurrent execution for multiple reply queues. In particular, do not hold a spin lock while submitting a request to the device, nor during most of the interrupt handler. Signed-off-by:
Matt Gates <matthew.gates@hp.com> Signed-off-by:
-
Matt Gates authored
Smart Arrays can support multiple reply queues onto which command completions may be deposited. It can help performance quite a bit to arrange for command completions to be processed on the same CPU from which they were submitted to increase the likelihood of cache hits. Signed-off-by:
-
Stephen M. Cameron authored
This is in order to smooth the way for upcoming changes to allow use of multiple reply queues for command completions. Signed-off-by:
-
Stephen M. Cameron authored
When aborting a command, the tag is supposed to be specified as 64-bit little endian. However, some smart arrays expect the tag of the command to be aborted to be specified in a strange byte order. How to tell which sort of Smart Array firmware we're dealing with is not obvious. However, because of the way we construct our tags, the values of any outstanding tag when specified with the "strange" byte order will not collide with the value specified in the correct order. That means we can safely attempt the abort both ways. Signed-off-by:
Stephen M. Cameron <stephenmcameron@gmail.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Instead of giving up after 3 immediate retries of driver initiated commands, back off the rate of retries and retry a bunch more times. Signed-off-by:
-
Matt Bondurant authored
In shared SAS configurations we might get a busy status during driver initiated commands (e.g. during rescan for devices). We should retry the command in such cases rather than giving up. Signed-off-by:
Matt Bondurant <Matthew.dav.bondurant@hp.com> Signed-off-by:
-
Stephen M. Cameron authored
MSI/MSI-X interrupts can't race the DMA completion they are communicating so no need to read from controller to flush the DMA to the host if MSI or MSI-X interrupts are being used. Signed-off-by:
-
