- 30 Nov, 2012 22 commits
-
-
Saurav Kashyap authored
Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Saurav Kashyap authored
Signed-off-by:
-
Andrew Vasquez authored
Original code was not corrected for ISP83xx support. Instead code should used the cached reference from the req_que structure, rather than the legacy 'if (ISP-TYPE(X))... else if (ISP-TYPE(Y))...' codes. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Chad Dupuis authored
This message can fill up the system logs and is not a common occurrence so move it to the verbose logging level. Signed-off-by:
-
Saurav Kashyap authored
Reported-by:
Fengguang Wu <Fengguang.wu@intel.com> Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
Armen Baloyan authored
Signed-off-by:
Armen Baloyan <armen.baloyan@qlogic.com> Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Saurav Kashyap authored
The value of 2 is informational message and it means that port id has changed. The driver should honor the value and continue its normal course. Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Andrew Vasquez authored
Rather than returning stale mailbox values. Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
-
Steve Hodgson authored
Signed-off-by:
Steve Hodgson <steve@purestorage.com> Signed-off-by:
-
Giridhar Malavali authored
[SCSI] qla2xxx: Change in setting UNLOADING flag and FC vports logout sequence while unloading qla2xxx driver. Signed-off-by:
-
David Jeffery authored
When the qla2xxx driver loses access to multiple, remote ports, there is a race condition which can occur which will keep the request stuck on a scsi request queue indefinitely. This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED bit is set in qla2x00_schedule_rport_del(), and how it is cleared in qla2x00_do_dpc(). The problem port has its drport pointer set, but it has never been processed by the driver to inform the fc transport that the port has been lost. qla2x00_schedule_rport_del() sets drport, and then sets the FCPORT_UPDATE_NEEDED bit. In qla2x00_do_dpc(), the port lists are walked and any drport pointer is handled and the fc transport informed of the port loss, then the FCPORT_UPDATE_NEEDED bit is cleared. This leaves a race where the dpc thread is processing one port removal, another port removal is marked with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the bit for both removals, even though only the first removal was actually handled. Until another event occurs to set FCPORT_UPDATE_NEEDED, the later port removal is never finished and qla2xxx stays in a bad state which causes requests to become stuck on request queues. This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED atomically. This ensures the port state changes are processed and not lost. Signed-off-by:
David Jeffery <djeffery@redhat.com> Signed-off-by:
-
Armen Baloyan authored
FC transport on receiving bsg_job submission failure, calls bsg_job->job_done() and sets the bsg_job->reply->result the returned value. In contrast, when the success code (0) is returned fc transport doesn't call bsg_job->job_done() and doesn't populate bsg_job->reply->result. Signed-off-by:
-
Aaron Lu authored
Update sd driver to use the callbacks defined in dev_pm_ops. sd_freeze is NULL, the bus level callback has taken care of quiescing the device so there should be nothing needs to be done here. Consequently, sd_thaw is not needed here either. suspend, poweroff and runtime suspend share the same routine sd_suspend, which will sync flush and then stop the drive, this is the same as before. resume, restore and runtime resume share the same routine sd_resume, which will start the drive by putting it into active power state, this is also the same as before. Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Aaron Lu authored
Use of pm_message_t is deprecated and device driver is not supposed to use that. This patch migrates the SCSI bus level pm callbacks to call device's pm callbacks defined in its driver's dev_pm_ops. This is achieved by finding out which device pm callback should be used in bus callback function, and then pass that callback function pointer as a param to the scsi_bus_{suspend,resume}_common routine, which will further pass that callback to scsi_dev_type_{suspend,resume} after proper handling. The special case for freeze in scsi_bus_suspend_common is not necessary since there is no high level SCSI driver has implemented freeze, so no need to runtime resume the device if it is in runtime suspended state for system freeze, just return like the system suspend/hibernate case. Since only sd has implemented drv->suspend/drv->resume, and I'll update sd driver to use the new callbacks in the following patch, there is no need to fallback to call drv->suspend/drv->resume if dev_pm_ops is NULL. Signed-off-by: -
Aaron Lu authored
This reverts commit 28fd00d4. With commit 88d26136 (PM: Prevent runtime suspend during system resume), this patch is no longer needed. Signed-off-by:
-
Aaron Lu authored
This reverts commit 33a2285d. With commit 88d26136 (PM: Prevent runtime suspend during system resume), this patch is no longer needed. Signed-off-by:
-
Aaron Lu authored
When device is runtime suspended, put it to stopped power state to save some power. This will also make the behaviour consistent with what the scsi_pm.c thinks about sd as the comment says: sd treats runtime suspend, system suspend and system hibernate identical. With this patch, it is now identical. And sd_shutdown will also do nothing when it finds the device has been runtime suspended, if we do not spin down the disk in runtime suspend by putting it into stopped power state, the disk will be shut down incorrectly. And the the same problem can be solved for runtime power off after runtime suspended case by this change. With the current runtime scheme for disk, it will only be runtime suspended when no process opens the disk, so this shouldn't happen a lot, which makes it acceptable to spin down the disk when runtime suspended. If some day a more aggressive runtime scheme is used, like the 'request based runtime pm for disk' that Alan Stern and Lin Ming has been working, we can introduce some policy to control this. But for now, make it simple and correct by spinning down the disk. Signed-off-by:
-
Xi Wang authored
The macro bit(n) is defined as ((u32)1 << n), and thus it doesn't work with n >= 32, such as in mvs_94xx_assign_reg_set(): if (i >= 32) { mvi->sata_reg_set |= bit(i); ... } The shift ((u32)1 << n) with n >= 32 also leads to undefined behavior. The result varies depending on the architecture. This patch changes bit(n) to do a 64-bit shift. It also simplifies mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined. Signed-off-by:Xi Wang <xi.wang@gmail.com> Acked-by:
Xiangliang Yu <yuxiangl@marvell.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Sasha Levin authored
store_host_reset() has tried to re-invent the wheel to compare sysfs strings. Unfortunately it did so poorly and never bothered to check the input from userspace before overwriting stack with it, so something simple as: echo "WoopsieWoopsie" > /sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset would result in: [ 316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7 [ 316.310101] [ 316.320051] Pid: 6655, comm: sh Tainted: G W 3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129 [ 316.320051] Call Trace: [ 316.340058] pps pps0: PPS event at 1352918752.620355751 [ 316.340062] pps pps0: capture assert seq #303 [ 316.320051] [<ffffffff83b3856b>] panic+0xcd/0x1f4 [ 316.320051] [<ffffffff81f5bac7>] ? store_host_reset+0xd7/0x100 [ 316.320051] [<ffffffff8110b996>] __stack_chk_fail+0x16/0x20 [ 316.320051] [<ffffffff81f5bac7>] store_host_reset+0xd7/0x100 [ 316.320051] [<ffffffff81e55bb3>] dev_attr_store+0x13/0x30 [ 316.320051] [<ffffffff812f7db1>] sysfs_write_file+0x101/0x170 [ 316.320051] [<ffffffff8127acc8>] vfs_write+0xb8/0x180 [ 316.320051] [<ffffffff8127ae80>] sys_write+0x50/0xa0 [ 316.320051] [<ffffffff83c03418>] tracesys+0xe1/0xe6 Fix this by uninventing whatever was going on there and just use sysfs_streq. Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and firmware reset"). [jejb: added necessary const to prevent compile warnings] Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Cc: <stable@vger.kernel.org> #3.2+ Signed-off-by:
-
- 27 Nov, 2012 18 commits
-
-
Naresh Kumar Inna authored
Signed-off-by:
Naresh Kumar Inna <naresh@chelsio.com> Signed-off-by:
-
Naresh Kumar Inna authored
This patch contains updates to firmware/hardware header files shared between csiostor and cxgb4/cxgb4vf, and the resulting changes to the cxgb4/cxgb4vf source files. Signed-off-by:
-
Jason J. Herne authored
Force large capacity (> 0xFFFFFFFF blocks) drives to use READ/WRITE(16) instead of READ/WRITE(10). Some(most/all?) USB enclosures do not like READ(10) commands when a large capacity drive is installed. This issue was reported and discussed here: http://marc.info/?l=linux-usb&m=135247705222324Signed-off-by:
Jason J. Herne <hernejj@gmail.com> Signed-off-by:
-
Mahesh Rajashekhara authored
This patch handles SCSI dma mapping failure case. Reporting error code to the upper layer instead of BUG_ON(). Signed-off-by:
Mahesh Rajashekhara <Mahesh_Rajashekhara@pmc-sierra.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Eric Northup authored
virtscsi_queuecommand was leaking memory when the virtio queue was full. Tested: Guest operates correctly even with very small queue sizes, validated we're not leaking kmalloc-192 sized allocations anymore. Signed-off-by:
Eric Northup <digitaleric@google.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
James Smart authored
Signed-off-by:
James Smart <james.smart@emulex.com> Signed-off-by:
-
James Smart authored
Reported via: https://bugzilla.kernel.org/show_bug.cgi?id=48891Signed-off-by:
-
James Smart authored
Reported via: https://bugzilla.kernel.org/show_bug.cgi?id=48871Signed-off-by:
-
James Smart authored
Fixed setting sequential delivery bit in a service class that is not valid Signed-off-by:
-
James Smart authored
Signed-off-by:
-
James Smart authored
Fix bug with Target Resets and FCP2 devices Create module parameter to disable Target Reset on FCP-Tape devices when a "bus reset" is requested. Default is to reset all devices on bus reset. Signed-off-by:
-
James Smart authored
Fixed boot from san failure when SLI4 FC device presented on the same PCI bus The request_firmware interface can induce delays while looking for firmware files, even if no fw file is present. In some situations the delays exceeded scan_wait timeouts, resulting in situations in which the boot device had not been discovered in time. Boot Device does not need to be on a lpfc device. Change request_firmware use to be module paramater driven. Default is to not attempt firmware download on boot. Add sysfs parameter to invoke firmware update. Signed-off-by:
-
HighPoint Linux Team authored
Support IOP RR4520/RR4522 which are based on Marvell frey. Signed-off-by:
HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by:
-
Eddie Wai authored
Removed the individual PCI DEVICE ID checking inside bnx2i. The device type can easily be read from the corresponding cnic->flags. This will free bnx2i from having to get updated for every new device ID that gets added. Signed-off-by:
Eddie Wai <eddie.wai@broadcom.com> Acked-by:
Michael Chan <mchan@broadcom.com> Reviewed-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
John Soni Jose authored
Signed-off-by:
John Soni Jose <sony.john-n@emulex.com> Signed-off-by:
Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Reviewed-by:
-
John Soni Jose authored
Driver periodically checks adapter state,is up fine or not. Based on the value updates the internal structures of driver. Signed-off-by:
-
John Soni Jose authored
The MBX timeout value set to 100 and if adapter doesn;t return response in that time driver will return from waiting for completion with an error to the caller. In the earlier code driver use to wait until MBX response comes from adapter. Signed-off-by:
-
John Soni Jose authored
Signed-off-by:
-
