commit 0181944fe6 adds a
'extended_error_logging' global variable to qla2xxx which is defined by
qla4xxx too.
Trying to build both drivers results in the following error:
LD drivers/scsi/built-in.o
drivers/scsi/qla4xxx/built-in.o: In function `qla4xxx_slave_configure':
drivers/scsi/qla4xxx/ql4_os.c:1433: multiple definition of `extended_error_logging'
drivers/scsi/qla2xxx/built-in.o:drivers/scsi/qla2xxx/qla_os.c:2166:
first defined here
make[2]: *** [drivers/scsi/built-in.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2
The following patch simply adds a qla2_ (qla4_ respectively) prefix to
the variable name.
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Stall error handler if attempting recovery while an rport is
blocked. This avoids device offline scenarios due to errors in
the error handler.
Reference implementation from lpfc/mptfc.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
iIDMA (Intelligent Interleaved Direct Memory Access) allows for
the HBA hardware to send FC frames at the rate at which they can
be received by a target device. By taking advantage of the
higher link rate, the HBA can maximize bandwidth utilization in a
heterogeneous multi-speed SAN.
Within a fabric topology, port speed detection is done via a Name
Server command (GFPN_ID) followed by a Fabric Management command
(GPSC). In an FCAL/N2N topology, port speed is based on the HBA
link-rate.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Original code attempts to retry PLOGIs to fcports that are
FCP_TARGETs only. If the driver never performed a successful
PLOGI/PRLI, the port-type would never be assigned, and the
relogin logic would silently drop the request (and thus the port
would not be recognized and registered).
The fix is relatively straightforward, drop the FCP_TARGET-only
check.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Currently it is impossible to reset provided by Qlogic QLA2xxx driver
SCSI devices externally using corresponding sg devices, particularly via
sg_reset utility, because qla2xxx driver in qla2xxx_eh_device_reset()
function checks if the input scsi_cmnd has its private data (CMD_SP())
attached. Then the found pointer isn't used anywhere inside of
qla2xxx_eh_device_reset(). If the RESET request comes from sg device, it
doesn't have such private data.
The attached patch removes check for non-NULL CMD_SP() from
qla2xxx_eh_device_reset(), hence allows to reset QLA2xxx's devices using
corresponding sg devices.
AV: change applies to bus/host reset handlers as well.
Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net>
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Conflicts:
drivers/scsi/nsp32.c
drivers/scsi/pcmcia/nsp_cs.c
Removal of randomness flag conflicts with SA_ -> IRQF_ global
replacement.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Add a few spaces to MODULE_PARM_DESC() text for qla2xxx. Without these
spaces text runs together when modinfo prints the text.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Also remove qla2xxx_probe_one/qla2xxx_remove_one stubs previously
used with external firmware module loaders.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Similar in form to QLogic's standard offering -- via
the 'extended_error_logging' module parameter.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
- macro usage statements should terminate with a ';'
- remove unused macros.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
- Defer firmware dump-data raw-to-textual conversion to
user-space.
- Add module parameter (ql2xallocfwdump) to allow for per-HBA
allocations of firmware dump memory.
- Dump request and response queue data as per firmware group
request.
- Add extended firmware trace support for ISP24XX/ISP54XX chips.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Simplify and centralise buffer allocation/deallocation, as
there's no point in having two memory request methods.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Expandind on the previous commit:
commit 79f89a4296
Author: andrew.vasquez@qlogic.com <andrew.vasquez@qlogic.com>
Date: Fri Jan 13 17:05:58 2006 -0800
[SCSI] qla2xxx: Disable port-type RSCN handling via driver state-machine.
and given:
- the process-context requirements of the FC transport
rport-APIs.
- lack of port-type RSCN processing logic for ISP24xx and newer
chips.
it's time now to remove the state-machine logic from mainline.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Fix the driver to return SUCCESS if the firmware or driver doesn't
have a command to abort, i.e., it's already been returned. Without
this patch, error recovery will take the target offline as it tries
harder and harder to get the driver to return the command it no longer
has.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
If qla2x00_probe_one() fails before calling request_irq() but gets to
qla2x00_free_device() then it will mistakenly try to free an irq it didn't
request. It's chosing to free based on ha->pdev->irq which is always set.
host->irq is set after request_irq() succeeds so let's use that to decide
to free or not.
This was observed and tested when a silly set of circumstances lead to
firmware loading failing on a 2100.
Signed-off-by: Zach Brown <zach.brown@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Modify well over a dozen mempool users to call mempool_create_slab_pool()
rather than calling mempool_create() with extra arguments, saving about 30
lines of code and increasing readability.
Signed-off-by: Matthew Dobson <colpatch@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
ISP24XX FW does not support Mbx 0x74 ie Login Local Port.
Added the equivalent code for ISP24XX ie to relogin in non
fabric case for ISP24XX use login iocb.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Only support ZIO mode 6 on specific ISP types.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
As new 23xx firmware will accomidate ISP63xx types.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Chip is similar in form to our ISP24xx offering.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Use the kthread_ API instead of opencoding lots of hairy code for kernel
thread creation and teardown.
Also switch from semaphore-based thread wakeup to wake_up_process.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-By: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Commit 854165f424
inadvertently added some code meant only for testing -- the
driver was ignoring the non-zero function numbers of a
multi-port HBA.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Fcport visibility is recognized during interrupt time, but,
rport removal can only occur during a process
(sleeping)-context. Return a DID_IMM_RETRY status for
commands submitted within this window to insure I/Os do not
prematurely run-out of retries.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
A target can LOGO an initiator at any time (i.e. during I/O,
due to a controller hicup, or as a simple authentication
mechanism after an initial CDB command), when this occurs,
the driver attempts to relogin (PLOGI) to the device via the
DPC thread. Add code to make the appropriate upcall to the
FC transport layer (fc_remote_port_add()) upon successful
completion of the PLOGI.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The driver can typically detect port-loss during an
interrupt context (i.e. via interrogation of a status IOCB's
completion status [CS_PORT_LOGGED_OUT]. Due to the calling
requirements of the fc_rport APIs, the driver would defer
removal of the device to the default workqueue. If the
work-item was preceded by an event which caused the port to
obtain visibility (relogin successful, target re-logged into
the topology), deferred removal could inadvertently drop the
rport. The code also no longer defers removal via the
default workqueue, instead opting for use of the driver's
own DPC thread.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Given the semantic changes in both the device-model and
fc-transport APIs, the driver's handling of port-type RSCNs
via a series of ADISCs and PLOGIs can cause series of
badness ranging from unexpectedly device loss to devices not
being discovered.
In the interim, disable (via a module-parameter) this
feature and allow RSCN management to continue to occur
within the driver's DPC thread.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Transition driver to exclusively use the request_firmware()
interfaces to retrieve firmware-blobs from user-space. This
will be the default behaviour going forward until the
embedded firmware-binary images are removed from the
upstream kernel.
Upon request, the driver caches the firmware image until the
driver is unloaded.
NOTE: The option is present to allow the user to continue to
use the firmware-loader modules, but, should be considered
deprecated.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Rejections fixed up and
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
We recently went back to implement a board reset. When we perform the
reset, we wanted to tear down the internal data structures and rebuild
them. Unfortunately, when it came to the rport structure, things were
odd. If we deleted them, the scsi targets and sdevs would be
torn down. Not a good thing for a temporary reset. We could block the
rports, but we either maintain the internal structures to keep the
rport reference (perhaps even replicating what's in the transport),
or we have to fatten the fc transport with new search routines to find
the rport (and deal with a case of a dangling rport that the driver
forgets).
It dawned on me that we had actually reached this state incorrectly.
When the fc transport first started, we did the block/unblock first, then
added the rport interface. The purpose of block/unblock is to hide the
temporary disappearance of the rport (e.g. being deleted, then readded).
Why are we making the driver do the block/unblock ? We should be making
the transport have only an rport add/delete, and the let the transport
handle the block/unblock.
So... This patch removes the existing fc_remote_port_block/unblock
functions. It moves the block/unblock functionality into the
fc_remote_port_add/delete functions. Updates for the lpfc driver are
included. Qlogic driver updates are also enclosed, thanks to the
contributions of Andrew Vasquez. [Note: the qla2xxx changes are
relative to the scsi-misc-2.6 tree as of this morning - which does
not include the recent patches sent by Andrew]. The zfcp driver does
not use the block/unblock functions.
One last comment: The resulting behavior feels very clean. The LLDD is
concerned only with add/delete, which corresponds to the physical
disappearance. However, the fact that the scsi target and sdevs are
not immediately torn down after the LLDD calls delete causes an
interesting scenario... the midlayer can call the xxx_slave_alloc and
xxx_queuecommand functions with a sdev that is at the location the
rport used to be. The driver must validate the device exists when it
first enters these functions. In thinking about it, this has always
been the case for the LLDD and these routines. The existing drivers
already check for existence. However, this highlights that simple
validation via data structure dereferencing needs to be watched.
To deal with this, a new transport function, fc_remote_port_chkready()
was created that LLDDs should call when they first enter these two
routines. It validates the rport state, and returns a scsi result
which could be returned. In addition to solving the above, it also
creates consistent behavior from the LLDD's when the block and deletes
are occuring.
Rejections fixed up and
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Ok, here's a patch to add such a common API for fc transport users.
Relevant LLD changes (lpfc and qla2xxx) also present.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Here's a patch which drops the eh_active checks in the qla2xxx
eh_handler callbacks.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
ISP23xx and ISP24xx chips have support for an adaptive
method of posting SCSI command completions for multiple SCSI
commands during a single system interrupt.
SCSI commands are placed on the system response queue
without interrupting the host until 1) a delay timer
expires; or 2) a SCSI command completes with an error.
As long as the host software (qla2xxx) services the response
queue for completions (this polling is done during
queuecommand()) within the 'delay timer' period, the
firmware will not generate system interrupt.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
