In the scenario that a link was broken, the devloss timer for each
rport was expire at roughly the same time, causing lots of "delete"
workqueue items being queued. Depth is dependent upon the number of
rports that were on the link.
The rport target remove calls were calling flush_scheduled_work(),
which would interrupt the stream, and start the next workqueue item,
which did the same thing, and so on until recursion depth was large.
This fix stops the recursion in the initial delete path, and pushes it
off to a host-level work item that reaps the dead rports.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This follows on from Jens' patch and consolidates all of the ULD
separate handlers for REQ_BLOCK_PC into a single call which has his
fix for our direction bug.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
scsi_send_eh_cmnd currently uses a semaphore and an overload of eh_timer
to either get a completion for a command for a timeout.
Switch to using a completion and wait_for_completion_timeout to simply
the code and not having to deal with the races ourselves.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This function has been superceeded by the block request based interfaces
and is unused (except for the uncompilable cpqfc driver).
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
now that the abuse in qla2xxx is gone this field can be remove.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Add an InfiniBand SCSI RDMA Protocol (SRP) initiator. This driver is
used to talk talk to InfiniBand SRP targets (storage devices).
Signed-off-by: Roland Dreier <rolandd@cisco.com>
I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.
In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch. This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other. So if any
hunk rejects or gets in the way of other patches, just drop it. My scripts
will pick it up again in the next round.
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
New dev_printk wrappers, which allow us to shrink code, and
eliminate direct references to host/channel/id/lun members:
scmd_printk()
Introduce wrappers for highly common idioms, which may also help us
eliminate some ->{channel,id} references in the future:
{scmd,sdev}_id()
{scmd,sdev}_channel()
The scmd_* wrappers are present in scsi/scsi_device.h because they all
employ the dereference chain cmd->device->$member. We would prefer to
use static inline functions rather than macros, but that would have a
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>
Add a flag to mark a PHY as attached to the HBA as opposed to beeing on
an expander. This is needed because various features are only supported
on those. This is a crude hack, the proper fix would be to use
different classes for host-attached vs expander phys. I'm looking into
that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
For now supporting the ->get_linkerrors method is mandatory. I'll
probably be beaten to implement the .show_foo variables and different
types of attributes soon..
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This should eliminate (at least in the mid layer) to make numeric
assumptions about any of the enumeration variables. As a side effect,
it will also make all the messages consistent and line us up nicely for
the error logging strategy (if it ever shows itself again).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Currently we just ignore the device, which means there are a few
arrays out there that we don't find.
This patch updates the scsi_report_lun_scan() to take a target instead
of a device so it can be called on a return of
SCSI_SCAN_TARGET_PRESENT, which is what a PQ 3 device returns.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
From: hare@suse.de
for a proper alignment between open-iscsi and iscsitarget the
definitions in include/iscsi_proto.h do not match exactly.
With this patch it's possible to have iscsitarget use
'include/iscsi_proto.h' instead of its own iscsi_hdr.h.
Signed-off-by: Alex Aizman <itn780@yahoo.com>
Signed-off-by: Dmitry Yusupov <dmitry_yus@yahoo.com>
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
From: michaelc@cs.wisc.edu
Cleanup some iscsi_proto defs, add some missing values, and
fix some defs.
Signed-off-by: Alex Aizman <itn780@yahoo.com>
Signed-off-by: Dmitry Yusupov <dmitry_yus@yahoo.com>
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
From: Alan Stern <stern@rowland.harvard.edu>
This patch (as561) fixes the error handler's thread-exit code. The
kthread_stop call won't wake the thread from a down_interruptible, so
the patch gets rid of the semaphore and simply does
set_current_state(TASK_INTERRUPTIBLE);
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Modified to simplify the termination loop and correct the sleep condition.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
We fix the oops by enforcing the host state model. There have also
been two extra states added: SHOST_CANCEL_RECOVERY and
SHOST_DEL_RECOVERY so we can take the model through host removal while
the recovery thread is active.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
obviously FC Port Speeds in scsi_transport_fc.h are defined according
to FC-HBA:
#define FC_PORTSPEED_1GBIT 1
#define FC_PORTSPEED_2GBIT 2
#define FC_PORTSPEED_10GBIT 4
#define FC_PORTSPEED_4GBIT 8
Problem is, whoever invented FC-HBA did not care about FC-FS or
FC-GS-x. Following FC-FS/FC-GS-x defintions of port speeds would look
like:
1 GBit: 0x0001
2 GBit: 0x0002
4 GBit: 0x0004
10GBit: 0x0008
(and new in FC-LS:
8 Gbit: 0x0010
16GBit: 0x0020)
I really appreciate if scsi_transport_fc.h would define port speeds
according to FC-GS-x/FC-FS. Thus mapping of port speed capabilities to
values defined in scsi_transport_fc.h can be avoided in the LLDD.
Attached is a patch to change the definitions.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The original API returned either an ERR_PTR() or a refcounted sdev.
Unfortunately, if it's successful, you need to do a scsi_device_put() on
the sdev otherwise the refcounting is wrong.
Everyone seems to expect that scsi_add_device() should be callable
without doing the ref put, so alter the API so it is (we still have
__scsi_add_device with the original behaviour).
The only actual caller that needs altering is the one in firewire ...
not because it gets this right, but because it acts on the error if one
is returned.
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
On some platforms the hard-casting of 8 byte node_name and
port_name arrays to an u64 would cause unaligned-access
warnings. Generalize the conversions with a transport
helper function which performs consistent shifting of WWN
bytes.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The SAS transport class contains common code to deal with SAS HBAs, an
aproximated representation of SAS topologies in the driver model,
and various sysfs attributes to expose these topologies and managment
interfaces to userspace.
In addition to the basic SCSI core objects this transport class introduces
two additional intermediate objects: The SAS PHY as represented by struct
sas_phy defines an "outgoing" PHY on a SAS HBA or Expander, and the SAS
remote PHY represented by struct sas_rphy defines an "incoming" PHY on a
SAS Expander or end device. Note that this is purely a software concept, the
underlying hardware for a PHY and a remote PHY is the exactly the same.
There is no concept of a SAS port in this code, users can see what PHYs
form a wide port based on the port_identifier attribute, which is the same
for all PHYs in a port.
This submission doesn't handle hot-plug addition or removal of SAS devices
and thus doesn't do scanning in a workqueue yet, that will be added in
phase2 after this submission. In a third phase I will add additional
managment infrastructure.
I think this submission is ready for 2.6.14, but additional comments are
of course very welcome.
I'd like to thanks James Smart a lot for his very useful input on the
design.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This one removes struct scsi_request entirely from sd. In the process,
I noticed we have no callers of scsi_wait_req who don't immediately
normalise the sense, so I updated the API to make it take a struct
scsi_sense_hdr instead of simply a big sense buffer.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This one's slightly more difficult. The transport class uses
REQ_FAILFAST, so another interface (scsi_execute) had to be invented to
take the extra flag. Also, the sense functions are shifted around to
allow spi_execute to place data directly into a struct scsi_sense_hdr.
With this change, there's probably a lot of unnecessary sense buffer
allocation going on which we can fix later.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
After this, we just have some drivers, all the ULDs and the SPI
transport class using scsi_wait_req().
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Original From: Mike Christie <michaelc@cs.wisc.edu>
Add scsi_execute_req() as a replacement for scsi_wait_req()
Fixed up various pieces (added REQ_SPECIAL and caught req use after
free)
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch is necessary if we begin exposing underlying physical disks
(which can attach to the SPI transport class) of the hardware RAID
cards, since we don't want any SPI parameters binding to the RAID
devices.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
We have some nasty issues with 2.6.12-rc6. Any request to scan on
the lpfc or qla2xxx FC adapters will oops. What is happening is the
system is defaulting to non-transport registered targets, which
inherit the parent of the scan. On this second scan, performed by
the attribute, the parent becomes the shost instead of the rport.
The slave functions in the 2 FC adapters use starget_to_rport()
routines, which incorrectly map the shost as an rport pointer.
Additionally, this pointed out other weaknesses:
- If the target structure is torn down outside of the transport,
we have no method for it to be regenerated at the proper parent.
- We have race conditions on the target being allocated by both
the midlayer scan (parent=shost) and by the fc transport
(parent=rport).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
There are certain rogue devices (and the aic7xxx driver) that return
BUSY or QUEUE_FULL forever. This code will apply a global timeout (of
the total number of retries times the per command timer) to a given
command. If it is exceeded, the command is completed regardless of its
state.
The patch also removes the unused field in the command: timeout and
timeout_total.
This solves the problem of detecting an endless loop in the mid-layer
because of BUSY/QUEUE_FULL bouncing, but will not recover the device.
In the aic7xxx case, the driver can be recovered by sending a bus reset,
so possibly this should be tied into the error handler?
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This parameter is important only to people who take the time to tune the
margin control settings, otherwise it's completely irrelevant. However,
just in case anyone should want to do this, it's appropriate to include
the parameter.
I don't do anything with it in DV by design, so the parameter will come
up as off by default, so if anyone actually wants to play with the
margin control settings they'll have to enable it under the
spi_transport class first.
I also updated the transfer settings display to report all of the PPR
settings instead of only DT, IU and QAS
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
