- 17 May, 2012 1 commit
-
-
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:
James Bottomley <JBottomley@Parallels.com>
-
- 10 May, 2012 33 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:
-
Stephen M. Cameron authored
Default behavior for any CHECK CONDITION excepting a few special cases is to print out certain parts of the sense buffer and the CDB. Default behavior should be to print nothing and let the upper layers or applications decide what to do about these. The same information is already available by setting the appropriate bits of the scsi_logging_level kernel parameter or via /proc/sys/dev/scsi/logging_level. Signed-off-by:
-
Stephen M. Cameron authored
pci_disable_device() disables the bus master bit and pci_enable_device does not re-enable it. It needs to be enabled. Signed-off-by:
-
Stephen M. Cameron authored
There was code to skip "disabled" devices which was intended to skip devices disabled in the BIOS, but it really just checks to see if the device can write to host memory, which this is disabled by pci_disable_device on driver unload, so this check has the effect of preventing subsequent load of the driver. And devices disabled in the BIOS don't show up at all anyway, so this check never made any sense to begin with, and should be removed. Signed-off-by:
-
Stephen M. Cameron authored
As Jenx Axboe explained to me: "In earlier times (2.6.18 and pre, iirc), Linux disabled IO and mem bars on pci_disable_device(). Now in newer kernel it does not. And in the newer kernels you run into problems if you DON'T disable the device on exit, since when it later loads the device is already in the enabled state - and pci_enable_device() then does nothing. This typically screws MSI/MSI-X." This is what the big scary comment that says pci_disable_device does "something nasty" to smart arrays was evidently referring to. If pci_disable_device is not called on driver rmmod, subsequently insmod'ing the driver may in result in some cases fail to be able to receive interrupts, esp. if other drivers are loaded between unloading and loading hpsa. Signed-off-by:
-
Mike Maslenkin authored
Check the domain validation flag on the given device before referencing scsi_device instance, otherwise if the flag is already set we return without decrementing the reference count. Signed-off-by:
Mike Maslenkin <mihailm@parallels.com> Signed-off-by:
-
Eddie Wai authored
Old version: 2.7.0.3 New version: 2.7.2.2 Signed-off-by:
Eddie Wai <eddie.wai@broadcom.com> Reviewed-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Eddie Wai authored
This will set the target can_queue limit to the number of preallocated session tasks set during creation. "Could not send nopout" messages were observed without this when the iSCSI connection experiences dropped frames under heavy I/O stress. Signed-off-by:
-
Mark Salyzyn authored
This is a followup to a patch provided by Jack Wang on September 21 2011. After increasing the CAN_QUEUE to 510 in pm8001 we discovered some performance degredation from time to time. We needed to increase the MPI queue to compensate and ensure we never hit that limit. We also needed to double the margin to support event and administrivial commands that take from the pool resulting in an occasional largely unproductive command completion with soft error to the caller when the command pool is overloaded temporarily. Signed-off-by:
Mark Salyzyn <mark_salyzyn@xyratex.com> Acked-by:
Jack Wang <jack_wang@usish.com> Signed-off-by:
-
Santosh Yaraganavi authored
UTP Transfer request list base registers UTRLBA and UTRLBAU must be assigned, lower-32 and upper-32 bits of UTRLD list physical base addresses respectively. Currently UTRLBAU is being assigned lower-32 bits of UTRLD physical base address. This will cause an issue with controllers that can support 64-bit addressing. This patch correctly assigns upper-32 bits of UTRLD physical base address to UTRLBAU. Reported-by:
Rene De Jong <rene.dejong@arm.com> Signed-off-by:
Santosh Yaraganavi <santoshsy@gmail.com> Reviewed-by:
Vinayak Holikatti <vinholikatti@gmail.com> Signed-off-by:
-
Dan Carpenter authored
We moved the locking in dd060e74 "[SCSI] fcoe: remove frame dropping code from fcoe_percpu_clean" but this unlock was missed. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
-
Yi Zou authored
FC-BB-6 v1.04 7.9.8.14 N_Port_ID Beacon: "A N_Port_ID Beacon is multicast and uses the VN_Port MAC address as source address." Currently, libfcoe is using ENode MAC, this seems ok and functionality wise not a problem in my back to back testing setup, however, just fix this to make libfcoe VN2VN support more spec compliant. Signed-off-by:
Yi Zou <yi.zou@intel.com> Signed-off-by:
-
Robert Love authored
The rtnl_mutex was held to protect calls to dev_uc_add and dev_uc_del. Holding rtnl is not required as those functions make use of the netif_addr_lock* API to protect the MAC changing. This change fixes the following regression by removing the rtnl usage when fcoe_update_src_mac is called. https://bugzilla.kernel.org/show_bug.cgi?id=42918 the existing dependency chain (in reverse order) is: -> #1 (&fip->ctlr_mutex){+.+...}: [<c1091f70>] lock_acquire+0x80/0x1b0 [<c147655d>] mutex_lock_nested+0x6d/0x340 [<f8970c32>] fcoe_ctlr_link_up+0x22/0x180 [libfcoe] [<f894620e>] fcoe_create+0x47e/0x6e0 [fcoe] [<f8973dd3>] fcoe_transport_create+0x143/0x250 [libfcoe] [<c10527e0>] param_attr_store+0x30/0x60 [<c1052696>] module_attr_store+0x26/0x40 [<c11a201e>] sysfs_write_file+0xae/0x100 [<c11449df>] vfs_write+0x8f/0x160 [<c1144cbd>] sys_write+0x3d/0x70 [<c147a0c4>] syscall_call+0x7/0xb -> #0 (rtnl_mutex){+.+.+.}: [<c109164b>] __lock_acquire+0x140b/0x1720 [<c1091f70>] lock_acquire+0x80/0x1b0 [<c147655d>] mutex_lock_nested+0x6d/0x340 [<c13a10c4>] rtnl_lock+0x14/0x20 [<f89445ac>] fcoe_update_src_mac+0x2c/0xb0 [fcoe] [<f8971712>] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe] [<c104fb69>] process_one_work+0x179/0x5d0 [<c10502f1>] worker_thread+0x121/0x2d0 [<c10550ed>] kthread+0x7d/0x90 [<c1481a82>] kernel_thread_helper+0x6/0x10 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fip->ctlr_mutex); lock(rtnl_mutex); lock(&fip->ctlr_mutex); lock(rtnl_mutex); *** DEADLOCK *** Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Vasu Dev authored
The fcoe controller has back references, therefore defer releasing master lport which gets freed along scsi_host_put and then free it once fcoe interface is fully cleaned. Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Tested-by:
Ross Brattain <ross.b.brattain@intel.com> Signed-off-by:
-
Vasu Dev authored
The lport could get timeout armed while its getting disabled, so flush lport worker after its disabled and ignore lport retry in that case instead of WARN_ON. [13192.936858] WARNING: at drivers/scsi/libfc/fc_lport.c:1573 fc_lport_timeout+0x53/0xa9 [libfc]() [13192.938026] Hardware name: Bochs [13192.938620] Modules linked in: fcoe libfcoe libfc scsi_transport_fc scsi_tgt fuse 8021q garp stp llc sunrpc ipv6 uinput microcode joydev pcspkr ixgbe e1000 i2c_piix4 i2c_core virtio_balloon dca mdio virtio_blk virtio_pci virtio_ring virtio floppy [last unloaded: speedstep_lib] [13192.942589] Pid: 23605, comm: kworker/0:6 Tainted: G W 3.2.0+ #71 [13192.943587] Call Trace: [13192.944052] [<ffffffff810403f4>] warn_slowpath_common+0x85/0x9d [13192.944940] [<ffffffff81040426>] warn_slowpath_null+0x1a/0x1c [13192.945734] [<ffffffffa02746eb>] fc_lport_timeout+0x53/0xa9 [libfc] [13192.946665] [<ffffffff81058d88>] process_one_work+0x20c/0x3ad [13192.947541] [<ffffffff81058cbe>] ? process_one_work+0x142/0x3ad [13192.948423] [<ffffffffa0274698>] ? fc_lport_enter_ns+0x178/0x178 [libfc] [13192.949363] [<ffffffff8105a313>] worker_thread+0xfd/0x181 [13192.950191] [<ffffffff8105a216>] ? manage_workers.clone.15+0x173/0x173 [13192.951100] [<ffffffff8105e19b>] kthread+0xa4/0xac [13192.951755] [<ffffffff814edbb4>] kernel_thread_helper+0x4/0x10 [13192.952520] [<ffffffff814e5cb4>] ? retint_restore_args+0x13/0x13 [13192.953398] [<ffffffff8105e0f7>] ? __init_kthread_worker+0x5b/0x5b [13192.954278] [<ffffffff814edbb0>] ? gs_change+0x13/0x13 [13192.954911] ---[ end trace 9763213b95bbd803 ]--- Signed-off-by:
-
Vasu Dev authored
Remove lport from net device and then do synchronize net device to flush inflight rx frames for the lport before doing fcoe_percpu_clean. In case of master lport, remove all rx packet handlers completely and then only do fcoe_percpu_clean. This required splitting fcoe_interface_cleanup to do remove part separately and for that added func fcoe_interface_remove and then call it from fcoe_if_destory before doing fcoe_percpu_clean. However if fcoe_interface_remove() is already called then don't call again from fcoe_interface_cleanup() to preserve its existing flows. This patch along with Neil's other patch to avoid soft irq context on ingress will avoid passing up frames on disabled lport as discussed in this mail thread:- http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.htmlSigned-off-by:
-
Vinayak Holikatti authored
Add myself and Santosh Y as maintainers for drivers/scsi/ufs/ Signed-off-by:
-
Venkatraman S authored
While interpreting the result of UTP task completion status, by using boolean &&, the evaluation would fail when the UPIU_TASK_MANAGEMENT_FUNC_SUCCEEDED was received. Either UPIU_TASK_MANAGEMENT_FUNC_COMPL or UPIU_TASK_MANAGEMENT_FUNC_SUCCEEDED should be considered as a success result. Reported-by:
Joe Perches <joe@perches.com> Signed-off-by:
Venkatraman S <svenkatr@ti.com> Reviewed-by:
Namjae Jeon <linkinjeon@gmail.com> Acked-by:
-
Tomas Henzl authored
When scsi_add_host fails the scsi_host_put should be called. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Acked-by:
"Nandigama, Nagalakshmi" <Nagalakshmi.Nandigama@lsi.com> Signed-off-by:
-
Mike Christie authored
When a rport is added back or the role is changed the fc class will queue a scan and then call scsi_target_unblock. The problem with this is if the devices are in the SDEV_OFFLINE state and the scan is run before the scsi_target_unblock, then the scan will see LUN0 as offline and the scan will fail. This patch moves the unblock call to before the scan, so we know the device state will be set correctly when the scan is run. Signed-off-by:
-
David Jeffery authored
There is a memory leak in the st driver when sending large enough reads or writes using st's direct I/O path. As part of mapping the application's memory, a buffer to hold page pointers is allocated and the count of mapped pages is stored in field do_dio. A non-zero do_dio marks that direct I/O is in use. But do_dio is only 1 byte in size. Mapping 256 4k pages overflows do_dio and causes it to be set to 0, like direct I/O option was not used. When the I/O completes, the buffer to hold the page pointers is not freed, and the page counts of the mapped pages are not reduced. Every I/O of this size then leaks memory. The size of do_dio needs to be increased to prevent it wrapping around. Signed-off-by:
David Jeffery <djeffery@redhat.com> Acked-by:
Kai Mäkisara <kai.makisara@kolumbus.fi> Signed-off-by:
-
- 25 Apr, 2012 6 commits
-
-
Krishna Gudipati authored
Signed-off-by:
Krishna Gudipati <kgudipat@brocade.com> Signed-off-by:
-
Krishna Gudipati authored
Made changes to have the same logging level for Logical port online and offline events, to display these events in pairs. Signed-off-by:
-
Krishna Gudipati authored
Make changes to remove unsupported model numbers from the sysfs model description routine. Signed-off-by:
-
Krishna Gudipati authored
Made changes to avoid queuing the vport delete work to IM driver work queue in the bfa_fcb_lport_delete() - since at this stage we are not completely done with using the vport structure as we are still waiting for the LOGO response from the fw in online state or just doing some cleanup. Since queuing up the vport delete work at this stage will result in the FC transport layer to clean up the vport before we get the response from firmware. Made changes to queue the port delete work to the IM driver work queue - from the bfa_fcs_vport_free() function since at this state we are done with using the vport data structure and the FCS state machine is completely cleaned up. Signed-off-by:
-
K. Y. Srinivasan authored
Hyper-V cannot process some commands like ATA_12 and ATA_16. It also returns a very generic error when this happens (SRB_STATUS_ERROR). Most of the time we treat SRB_STATUS_ERROR as DID_TARGET_FAILURE which causes error handler retry, but in the case of pass through commands, they'll never succeed (and the error handler will offline the device), so put a discriminating block in the command completion routing and send the SRB_STATUS_ERROR upwards with DID_PASSTHROUGH for commands we know should not be retried. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
John Soni Jose authored
Implement ISCSI_HOST_PARAM_PORT_STATE and ISCSI_HOST_PARAM_PORT_SPEED to get the Adapter port state and port name Signed-off-by:
John Soni Jose <sony.john-n@emulex.com> Signed-off-by:
Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Signed-off-by:
-
