Semantic changes in ISP24xx firmware behaviour inadvertently
caused the driver to believe an F-port topology was present in an
N_port-to-N_port configuration.
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames 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: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Expandind on the previous commit:

	commit 79f89a42
	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: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

- structure definitions.
- structure members.
- #define's.
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

In qla2x00_reset_chip the driver first takes the hardware lock,
and then later on takes the mbx lock.

In the mailbox_command code.. it goes the other way around.

Discovered with the lock validator.

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

If firmware image is unavailable via request_firwmare(), then
attempt to load the image (likely out-of-date) stored in flash
memory.
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

With ISP24XX and ISP54XX parts.
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

update version
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Do not flush queues then block session. This will cause commands
to needlessly swing around on us and remove goofy
recovery_failed field and replace with state value.

And do not start recovery from within the host reset function.
This causeis too many problems becuase open-iscsi was desinged to
call out to userspace then have userpscae decide if we should
go into recovery or kill the session.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Patch from david.somayajulu@qlogic.com and cleaned up by Tomo.

qla4xxx is going to have a different daemon so this patch
just routes the events to the right daemon.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Discovered by steven@hayter.me.uk and patch by michaelc@cs.wisc.edu

The dtask mempool is reserving 261120 items per session! Since we are now
sending headers with sendmsg there is no reason for the mempool and that
was causing us to us carzy amounts of mem. We can preallicate a header in
the r2t and task struct and reuse them
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

We only use the mtask data buffer for login tasks so we do not
need to preallocate a buffer for every mtask. This saves
8 * 31 KB.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

From Zhen and ported by Mike:

Don't use sendpage for the headers. sendpage for the pdu headers
does not seem to have a performance impact, makes life harder
for mutiple data pdus to be in flight and still trips up some
network cards when it is from slab mem.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

The Coverity checker found a memory leak (bug nr. 1245) in
 drivers/block/DAC960.c::DAC960_V2_ProcessCompletedCommand()

The leak is pretty unlikely since it requires that the first of two
successive kmalloc() calls fail while the second one succeeds. But it can
still happen even if it's unlikely.

If the first call that allocates 'PhysicalDeviceInfo' fails but the one
that allocates 'InquiryUnitSerialNumber' succeeds, then we will leak the
memory allocated to 'InquiryUnitSerialNumber' when the variable goes out
of scope.

A simple fix for this is to change the existing code that frees
'PhysicalDeviceInfo' if that one was allocated but
'InquiryUnitSerialNumber' was not, into a check for either pointer
being NULL and if so just free both. This is safe since kfree() can
deal with being passed a NULL pointer and it avoids the leak.

While I was there I also removed the casts of the kmalloc() return
value since it's pointless.
I also updated the driver version since this patch changes the workings of
the code (however slightly).

This issue could probably be fixed a lot more elegantly, but the code
is a big mess IMHO and I just took the least intrusive route to a fix
that I could find instead of starting on a cleanup as well (that can
come later).

Please consider for inclusion.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received From Mark Salyzyn

The queue tracking is just not being used, not even for debugging. Information
about outstanding commands can be acquired from the scsi structures.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received From Mark Salyzyn

A race condition existed that could result in a lost completion of a
command to the ppc based cards.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received From Mark Salyzyn

Add the ability to adjust for unusual corner case failures. Both of
these additional module parameters deal with embedded, non-intel or
complicated system scenarios.

Aif_timeout can be increased past the default 2 minute timeout to drop
application registrations when a system has an unusually high event load
resulting from continuing management requests, or simultaneous builds,
or sluggish user space as a result of system load.

Startup_timeout can be increased past the default 3 minute timeout to
drop an adapter initialization for systems that have a very large number
of targets, or slow to spin-up targets, or a complicated set of array
configurations that extend the time for the firmware to declare that it
is operational. This timeout would only have an affect on non-intel
based systems, as the (more patient) BIOS would generally be where the
startup delay would be dealt with.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received From Mark Salyzyn

Slight space and speed efficiency improvement.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received From Mark Salyzyn

Since new commands to the card are quiesced, respect the changes in
the SCSI error path which dropped locking around the hba reset handler
and similarly drop the lock requirement in the driver's path.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Problem spotted by: Suzuki K P <suzuki@in.ibm.com>

A zero return on success isn't correct for filesystem write functions.
They should either return negative error or the length of bytes
consumed.  Add code to convert our zero on success error return to
return the length of bytes passed in.

This fixes the following:

$ echo "scsi remove-single-device 0 0 3 0" > /proc/scsi/scsi
bash: echo: write error: No such device or address"
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

debugged by wrwhitehead@novell.com
patch and analysis by fujita.tomonori@lab.ntt.co.jp

Only tcp_read_sock and recv_actor (iscsi_tcp_data_recv for us) see
desc.count. It is is used just for permitting tcp_read_sock to read
the portion of data in the socket.

When iscsi_tcp_data_recv sees a partial header, it sets
desc.count. However, it is possible that the next skb (containing the
rest of the header) still does not come. So I'm not sure that this
scheme is completely correct.

Ideally, we should use the exact length of the data in the socket for
desc.count. However, it is not so simple (see SIOCINQ in
tcp_ioctl). So I think that iscsi_tcp_data_recv can just stop playing
with desc.count and tell tcp_read_sock to read the all skbs. As
proposed already, if iscsi_tcp_data_ready sets desc.count to
non-zero, tcp_read_sock does that.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

debugged by Ming and Rohan:

The problem Ming and Rohan debugged was that during a normal session
login, open-iscsi is not incrementing the exp_statsn counter. It was
stuck at zero. From the RFC, it looks like if the login response PDU has
a successful status then we should be incrementing that value. Also from
the RFC, it looks like if when we drop a connection then reconnect, we
should be using the exp_statsn from the old connection in the next
relogin attempt.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

align printk output
Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

from patmans@us.ibm.com and michaelc@cs.wisc.edu

Fix bugs when forcing a mgmt task to fail and allow
session recovery to cleanup the session/connection
of any running mgmt tasks. When called during
the in login state.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

add transport end point callbacks so iscsi drivers that cannot connect
from userspace, like iscsi tcp, using sockets do not have to
implement their own socket infrastructure.
Signed-off-by: NOr Gerlitz <ogerlitz@voltaire.com>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

drivers/scsi/scsi_lib.c: In function `scsi_kmap_atomic_sg':
drivers/scsi/scsi_lib.c:2394: warning: unsigned int format, different type arg (arg 3)
drivers/scsi/scsi_lib.c:2394: warning: unsigned int format, different type arg (arg 4)
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

drivers/scsi/scsi_scan.c: In function `scsi_probe_and_add_lun':
drivers/scsi/scsi_scan.c:926: warning: unused variable `vend'
drivers/scsi/scsi_scan.c:926: warning: unused variable `mod'
drivers/scsi/scsi_scan.c: At top level:
drivers/scsi/scsi_scan.c:829: warning: `scsi_inq_str' defined but not used

Fix those, tighten up the (somewhat poorly-designed) logging macro and fix
some coding-style warts.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

The current dc395x driver uses PIO to transfer up to 4 bytes which do not
get transferred by DMA (under unclear circumstances). For this the driver
uses page_address() which is broken on highmem. Apart from this the
actual calculation of the virtual address is wrong (even without highmem).
So, e.g., for reading it reads bytes from the driver to a wrong address
and returns wrong data, I guess, for writing it would just output random
data to the device.

The proper fix, as suggested by many, is to dynamically map data using
kmap_atomic(page, KM_BIO_SRC_IRQ) / kunmap_atomic(virt). The reason why it
has not been done until now, although I've done some preliminary patches
more than a year ago was that nobody interested in fixing this problem was
able to reliably reproduce it. Now it changed - with the help from
Sebastian Frei (CC'ed) I was able to trigger the PIO path. Thus, I was
also able to test and debug it.

There are 4 cases when PIO is used in dc395x - data-in / -out with and
without scatter-gather. I was able to reproduce and test only data-in with
and without SG. So, the data-out path is still untested, but it is also
somewhat simpler than the data-in. Fredrik Roubert (also CC'ed) also had
PIO triggering on his system, and in his case it was data-out without SG.
It would be great if he could test the attached patch on his system, but
even if he cannot, I would still request to apply the patch and just wait
if anybody cries...

Implementation: I put 2 new functions in scsi_lib.c and their declarations
in scsi_cmnd.h. I exported them without _GPL, although, I don't feel
strongly about that - not many drivers are likely to use them. But there
is at least one more - I want to use them in tmscsim.c. Whether these are
the right files for the functions and their declarations - not sure
either. Actually, they are not scsi-specific, so, might go somewhere
around other scattergather magic? They are not platform specific either,
and most SG functions are defined under arch/*/... As these issues were
discussed previously there were some more routines suggested to manipulate
scattergather buffers, I think, some of them were needed around
crypto code... So, might be a common place reasonable, like
lib/scattergather.c? I am open here.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Convert kmalloc + memset to kcalloc in ibmvscsi
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: NDave Boutcher <sleddog@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Conflicts:

	include/scsi/scsi_devinfo.h

Same number for two BLIST flags:  BLIST_MAX_512 and BLIST_ATTACH_PQ3
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Any end device that can't support any of the scanning protocols
shouldn't be scanned, so set its id to -1 to prevent
scsi_scan_target() being called for it.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This just converts iscsi_tcp to the lib
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

There is a lot of code duplcited between iscsi_tcp
and the upcoming iscsi_iser driver. This patch puts
the duplicated code in a lib. There is more code
to move around but this takes care of the
basics. For iscsi_offload if they use the lib we will
probably move some things around. For example in the
queuecommand we will not assume that the LLD wants
to do queue_work, but it is better to handle that
later when we know for sure what iscsi_offload looks
like (we could probably do this for iscsi_iser though to).

Ideally I would like to get the iscsi_transports modules
to a place where all they really have to do is put data
on the wire, but how to do that will hopefully be more clear
when we see other modules like iscsi_offload. Or maybe
iscsi_offload will not use the lib and it will just be
iscsi_iser and iscsi_tcp and maybe the iscsi_tcp_tgt if that
is allowed in mainline.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>