- 27 May, 2011 6 commits
-
-
Nicholas Bellinger authored
This patch converts target core and follwing scsi-misc upstream fabric modules to use include/scsi/scsi_tcq.h includes for SIMPLE, HEAD_OF_QUEUE and ORDERED SCSI tasks instead of scsi/libsas.h with TASK_ATTR* *) tcm_loop: Convert tcm_loop_allocate_core_cmd() + tcm_loop_device_reset() to scsi_tcq.h *) tcm_fc: Convert ft_send_cmd() from FCP_PTA_* to scsi_tcq.h Reported-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by:
James Bottomley <jbottomley@parallels.com>
-
Nicholas Bellinger authored
This patch converts transport_core_report_lun_response() to use drivers/scsi/scsi_scan.c:int_to_scsilun instead of using the struct target_core_fabric_ops->pack_lun() fabric provided API vector. It also removes the tfo->pack_lun check from target_fabric_tf_ops_check() and removes from struct target_core_fabric_ops->pack_lun() from target_core_fabric_ops.h, and the following mainline scsi-misc fabric modules: *) tcm_loop: Drop tcm_loop_pack_lun() usage *) tcm_fc: Drop ft_pack_lun() usage Reported-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Nicholas Bellinger authored
This patch fixes a bug where task->task_execute_queue=1 was not being cleared once se_task had been removed from se_device->execute_task_list, resulting in an OOPs in core_tmr_lun_reset() for the task->task_active=0 case where transport_remove_task_from_execute_queue() was incorrectly being called. This patch fixes two cases in transport_get_task_from_execute_queue() and transport_remove_task_from_execute_queue() to properly clear task->task_execute_queue=0 once list_del(&task->t_execute_list) has been called. It also adds an explict check in transport_remove_task_from_execute_queue() to dump_stack + return if called with task->task_execute_queue=0. Signed-off-by:
-
Nicholas Bellinger authored
This patch addresses a bug in the target core release path for HW operation where transport_free_dev_tasks() was incorrectly being called from transport_lun_remove_cmd() while releasing a se_cmd reference and calling struct target_core_fabric_ops->queue_data_in(). This would result in a OOPs with HW target mode when the release of se_task->task_sg[] would happen before pci_unmap_sg() can be called in HW target mode fabric module code. This patch addresses the issue by moving transport_free_dev_tasks() from transport_lun_remove_cmd() into transport_generic_free_cmd(), and adding TRANSPORT_FREE_CMD_INTR and transport_generic_free_cmd_intr() to allow se_cmd descriptor release to happen fromfrom within transport_processing_thread() process context when release of se_cmd is not possible from HW interrupt context. Signed-off-by:
-
Nicholas Bellinger authored
This patch fixes two bugs wrt to the interrupt context usage of target core with HW target mode drivers. It first converts the usage of struct se_device->stats_lock in transport_get_lun_for_cmd() and core_tmr_lun_reset() to properly use spin_lock_irq() to address an BUG with CONFIG_LOCKDEP_SUPPORT=y enabled. This patch also adds a 'in_interrupt()' check to allow GFP_ATOMIC usage from core_tmr_alloc_req() to fix a 'sleeping in interrupt context' BUG with HW target fabrics that require this logic to function. Signed-off-by:
-
Nicholas Bellinger authored
This patch fixes a bug in transport_do_task_sg_chain() used by HW target mode modules with sg_chain() to provide a single sg_next() walkable memory layout for use with pci_map_sg() and friends. This patch addresses an issue with mapping multiple small block max_sector tasks across multiple struct se_task->task_sg[] mappings for HW target mode operation. This was causing OOPs with (cmd->t_task->t_tasks_no > 1) I/O traffic for HW target drivers using transport_do_task_sg_chain(), and has been tested so far with tcm_fc(openfcoe), tcm_qla2xxx, and ib_srpt fabrics with t_tasks_no > 1 IBLOCK backends using a smaller max_sectors to trigger the original issue. Signed-off-by:
Kiran Patil <kiran.patil@intel.com> Cc: stable@kernel.org Signed-off-by:
-
- 20 May, 2011 1 commit
-
-
Nicholas Bellinger authored
Merge branch 'master' of /pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 into for-40-iscsi-target-merge-v3
-
- 17 May, 2011 33 commits
-
-
Joe Carnuccio authored
Eliminate duplicate code by refactoring the calls to qla2xxx_read_sfp() in qla2x00_get_thermal_temp(). This keeps the parameter values separate from the mailbox register mechanics. This also allows qla2xxx_read_sfp() to be the sole "spec" for READ SFP semantics. Signed-off_by: Joe Carnuccio <joe.carnuccio@qlogic.com> Signed-off-by:
Madhuranath Iyengar <Madhu.Iyengar@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Joe Carnuccio authored
Make the read/write sfp mailbox command routines uniform, and remove redundancy. Also protect against attempting to do a single byte dma in these routines. Signed-off-by:
Joe Carnuccio <joe.carnuccio@qlogic.com> Signed-off-by:
-
Andrew Vasquez authored
Use proper init_cb_size member which takes into account MID/non-MID init-cb structure sizes. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Andrew Vasquez authored
The 'max_lun' value registered for each scsi_host is currently capped at 0xffff. The new module parameter can allow for 2nd-level flat-space addressing method-infrastructure to be supported. Signed-off-by:
-
Saurav Kashyap authored
Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
-
Joe Carnuccio authored
When reading a single byte using the READ SFP mailbox command, the single byte of data is returned in MB[1] and not MB[8]. The reason that MB[8] was being used is that the spec was unclear as it evolved over time; and we have not needed to read a single byte until recently. Signed-off-by:
-
Chad Dupuis authored
Encapsulate the unlocking of the ROM lock in a function for better code readability. Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Chad Dupuis authored
Signed-off-by:
-
Madhuranath Iyengar authored
Signed-off-by:
-
Joe Carnuccio authored
The debug print prints the first byte of the buffer which is buf[8]. Signed-off-by:
-
Saurav Kashyap authored
The driver keeps a copy of the fw_version within the ha structure. For ISP82xx, this local copy doesn't get updated, and as a result, the old firmware version ends up getting displayed. This patch fixes this issue. Signed-off-by:
-
Arun Easi authored
Bumping ref count during fc_vport_terminate() was the cause. vport delete would wait for ref count to drop to zero and that would never happen. Cc: stable@kernel.org Signed-off-by:
Arun Easi <arun.easi@qlogic.com> Signed-off-by:
-
Andrew Vasquez authored
The firmware spec has the fcp_data_dseg_len defined as a 32-bit value, while the corresponding field in the driver structure has it defined as a 16-bit value. Cc: stable@kernel.org Signed-off-by:
-
Saurav Kashyap authored
This patch ensures qla82xx_watchdog is not being run for the vport. It also makes sure that beacon ON is not done for the vport, as it will lead to the waking up of the dpc thread again and again. Signed-off-by:
-
Arun Easi authored
Timer is required to flush out entries that may be present in work queues. Cc: stable@kernel.org Signed-off-by:
-
Joe Perches authored
Not at all sure this is correct or appropriate to change, but this seems odd. Found via coccinelle script @@ type T; T* ptr; expression E1; @@ * memset(E1, 0, sizeof(ptr)); Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Anton Blanchard authored
I noticed a stream of errors from the IPR driver while doing IOMMU fault injection. Rate limit the errors so we don't clog up the console and logfiles. Signed-off-by:
Anton Blanchard <anton@samba.org> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
Scott Teel <scott.stacy.teel@hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Just go straight to the soft-reset method instead. Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
on driver load, if reset_devices is set, and the hard reset attempts fail, try to bring up the controller to the point that a command can be sent, and send it a soft reset command, then after the reset undo whatever driver initialization was done to get it to the point to take a command, and re-do it after the reset. This is to get kdump to work on all the "non-resettable" controllers (except 64xx controllers which can't be reset due to the potentially shared cache module.) Signed-off-by:
-
Stephen M. Cameron authored
The bit-2-doorbell reset method seemed to cause (survivable) NMIs on some systems and (unsurvivable) IOCK NMIs on some G7 servers. Firmware guys implemented a new doorbell method to alleviate these problems triggered by bit 5 of the doorbell register. We want to use it if it's available. Signed-off-by:
-
Stephen M. Cameron authored
hpsa_scsi_setup at one time contained enough code to justify its existence, but that time has passed. Signed-off-by:
-
Stephen M. Cameron authored
When waiting for the board to become "not ready" don't print a message saying "waiting for board to become ready" (possibly followed by a message saying "failed waiting for board to become not ready". Instead, it should be "waiting for board to reset" and "failed waiting for board to reset." Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
This is to avoid the usual two or three messages about the command timing out. We're obviously not waiting long enough. Signed-off-by:
-
Stephen M. Cameron authored
Detect failure of controller reset by noticing if the 32 bytes of "driver version" we store on the hardware in the config table fail to get zeroed out. Previously we noticed if the controller did not transition to "simple mode", but this did not detect reset failure if the controller was already in simple mode prior to the reset attempt (e.g. due to module parameter hpsa_simple_mode=1). Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
This is to ensure the board interrupts are really off when these functions return. Signed-off-by:
-
Stephen M. Cameron authored
Apparently we've been doin it rong for a decade, but only lately do we run into problems. Signed-off-by:
-
