cosmetic changes:
- removed tabs in Doc file - replaced with expanded spaces
- minor copyright text and author text updates
- removed a bunch of trailing whitespace
-- james s
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/Documentation/scsi/scsi_fc_transport.txt
b/Documentation
All,
For the past several months, Emulex has been updating our driver to support
the N_Port ID Virtualization (NPIV). We have reached a maturity point
where we would like to move the NPIV support into our upstream driver.
The patches, as an RFC, were posted 5/1 for review:
FYI - we have reworked this patch and include it in our 8.2.1 patch
set, which adds NPIV support.
-- james s
FUJITA Tomonori wrote:
This converts lpfc to use the data buffer accessors.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/lpfc/lpfc_scsi.c | 55
The only thing that should keep the attribute being shown is whether
you have a non-zero value for the template .vport_disable function.
Double-checked it on my systems...
-- james s
Seokmann Ju wrote:
Hello James,
I've got a question on NPIV framwork that is included in FC transport
layer.
ACK - missed in our merge. Thank You...
-- james s
Boaz Harrosh wrote:
This is an addendum to:
commit a0b4f78f9a4c869e9b29f254054ad7441cb40bbf
Author: FUJITA Tomonori [EMAIL PROTECTED]
[SCSI] lpfc: convert to use the data buffer accessors
One place was missed in the merge
ACK - looks fine..
Thanks
-- james s
FUJITA Tomonori wrote:
I forgot to CC James Smart and send a lpfc patch.
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: Re: NPIV mapping problems (was Re: [PATCH 1/19] add data buffer
accessors)
Date: Wed, 04 Jul 2007 17:25:36 +0900
Sorry
Adrian,
Thanks.
Syntax-wise, it is incorrect. However there's no risk. The datastructure
its indexing into is a union, and its size is sufficient for the index.
The union supports old and new firmware interfaces. We mistakenly used the
array for the old interface and should have used the
This set of patches updates the lpfc driver to revision 8.2.2.
It is mainly bug fixes, further splitting of parameters between physical
port and virtual port, and expanded debug logging.
The patches contain the following:
- Error messages and debugfs updates
- Fix locking around HBA's
Fix locking around HBA's port_list
Cleans up a lot of bad behaviors that have been in this area a while
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2007-07-20 13:38
-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2007-08-02 09:26:46.0 -0400
+++ b/drivers/scsi/lpfc/lpfc_attr.c 2007-08-02 09:28:15.0 -0400
@@ -734,6 +734,77 @@ lpfc_##attr
-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2007-08-02 06:55:42.0 -0400
+++ b/drivers/scsi/lpfc/lpfc_attr.c 2007-08-02 07:12:04.0 -0400
@@ -68,12 +68,6
Error messages and debugfs updates:
- Fix up GID_FT error messages
- Enhance debugfs with slow_ring_trace, dumpslim and nodelist information
- Add log type (and messages) for vport state changes
- Enhance log messages when retries ELS fail
Signed-off-by: James Smart [EMAIL PROTECTED
.
- Fix index-out-of-range error in iocb. Spotted by Coverity.
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2007-08-02 07:12:04.0 -0400
+++ b/drivers/scsi/lpfc/lpfc_attr.c
Style cleanups:
- Clean up all instances of mixed tab-space indentation
- Clean up sparse build errors
- Add appropriate static's
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c
Change version number to 8.2.2
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h
--- a/drivers/scsi/lpfc/lpfc_version.h 2007-08-02 07:07:46.0 -0400
+++ b/drivers/scsi/lpfc/lpfc_version.h 2007-08-02 09:13
ACK
-- james s
Mariusz Kozlowski wrote:
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
drivers/scsi/lpfc/lpfc_init.c | 65932 - 65881 (-51 bytes)
drivers/scsi/lpfc/lpfc_init.o | 219760 - 219616 (-144 bytes)
drivers/scsi/lpfc/lpfc_init.c |3 +--
1 file changed, 1 insertion(+), 2
Sorry, Attempting to sync our pools with the variance of upstream is difficult.
Leave this patch 4 in place. I'll submit a patch shortly to address you concern
and get the 8.2.2 sources in line.
-- james s
Boaz Harrosh wrote:
Big NACK
The code was converted to Accessors. look Here:
-
It was pointed out by Boaz Harrosh [EMAIL PROTECTED] that our
8.2.2 lpfc patches revert a change to using SCSI command accessor
functions.
This patch, to be applied on top of the 8.2.2. patches, updates the
driver for the accessor functions.
-- james s
Signed-off-by: James Smart [EMAIL
In defense of my maintainer, who was working on my behalf! ...
The lpfc mods were the bulk of the +/- counts. We batch our bug fixes
together and then push to James as a large lump. Unfortunately, we had
a change that changed logging from a base object to a subobject. Although
not risky, it did
Jeff Garzik wrote:
The lpfc update was probably the biggest thing, LOC-wise. And even
though that was mostly bug fixes -- and notably NOT 100% fixes -- it is
big enough to warrant integration testing and exposure prior to
mainline. Definitely merge-window-open material AFAICS.
FYI - it is
ACK
-- james s
Jesper Juhl wrote:
I propose this patch, that simply changes the 'hbqno LPFC_MAX_HBQS'
into 'hbqno = LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno LPFC_MAX_HBQS'
into 'hbqno = LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Acked-by: James Smart [EMAIL PROTECTED]
---
drivers/scsi/lpfc
.
- Coding-wise, you are right, we still didn't fix the range check.
Since this really is just something to keep the tools happy - I'll recind the
NACK.
I'll worry about simply removing this if-check later...
James/Andrew, accept this patch - ACK.
-- james s
Jesper Juhl wrote:
On 13/08/07, James
A little more
The -EEXIST matches http://marc.info/?l=linux-scsim=117699334422336w=2
I had a bug fix at http://marc.info/?l=linux-scsim=117856436302690w=2
Mathew's fix below superceeded my patch and supposedly also corrects it.
-- james s
PS: Emulex's testing has been with my fix. We
on the container were freed. This allowed the release to
happen in the background to the LLDD removal.
Assuming this is how we want to handle this scenario, the other SCSI transports
need to be updated accordingly.
-- james s
This patch was cut against 2.6.23-rc3
Signed-off-by: James Smart [EMAIL
James Bottomley wrote:
I'm afraid if you look at your solution, you'll see it still doesn't
quite work: If the next thing the user does after unloading lpfc is to
unload the transport class, the module is blown away with potentially a
live release callback to now freed code.
You're right...
This patch cut against 2.6.23-rc3 plus the following patch:
http://marc.info/?l=linux-scsim=118289275414202w=2
PS: there really should be better hooks for knowing if the driver expects
async or background scanning (perhaps the whole pre-state should be set
by the driver).
Signed-off-by: James
:10:35AM -0400, James Smart wrote:
In testing 2.6.23-rc3, there is a small window where the async-per-target
scan of the transport can beat the call from the LLDD to scsi_scan_host().
I'd assumed that events wouldn't come in until -scan_start was called.
I see lpfc doesn't have one; is it possible
I'd prefer a flag/bit in the fc template to indicate no scanning by the
transport. Thus, it's up to the driver to call __scsi_add_device, or
perform the appropriate scans...
Note: this doesn't stop the problem in absolute. as long as there's scan
interfaces via sysfs, any tool/admin could
Nit (but preferred) : change no_target_scan to disable_target_scan.
Otherwise, patch is good.
Christof Schmitt wrote:
I attached a new patch that adds a flag to the fc template. So far, it
is untested. What is the better approach? Avoid scanning with the flag
being 1 or use the 1 to enable
ACK
In the future, if the patch has already been pushed upstream independently
I would not embed it again in a set of zfcp patches- I would simply reference
it.
-- james s
Swen Schillig wrote:
From: Christof Schmitt [EMAIL PROTECTED]
This change has already been discussed on linux-scsi:
The midlayer is written to accept scsi i/o completion (via scsi_done())
from the context of an interrupt handler. The scsi_done() path actually
just traverses up the stack a little, then queues the request on a done
queue, and scheduls a softirq thread for actual completion processing.
The
A customer passed this fix to me...
In a system with double-digit adapter counts, after a few
rmmod/insmod attempts, the system oops. It always occurs when
the scsi host number reaches 100.
What is happening is that scsi_add_host() detects a transport that
needs to allocate a workqueue, thus
Any history on why the limit exists ?
-- james s
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Christoph Hellwig
Sent: Tuesday, August 09, 2005 12:32 PM
To: Smart, James
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] shorten workqueue name
SCSI_MLQUEUE_HOST_BUS from queuecommand() for
nodes in NPR states complete it with retry-able error code DID_BUS_BUSY
Signed-off-by: James Smart [EMAIL PROTECTED]
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -746,6 +746,10 @@ lpfc_queuecommand(struct scsi_cmnd *cmnd
Clear task management bits when preparing SCSI commands
In lpfc_scsi_prep_cmnd, clear the task management bits (fcpCntl2 member
in the fcp_cmd structure) when preparing regular SCSI commands.
Signed-off-by: James Smart [EMAIL PROTECTED]
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi
/transport structure in our structure caused
need for more files to include midlayer/transport headers.
Signed-off-by: James Smart [EMAIL PROTECTED]
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -1339,14 +1339,12 @@ lpfc_pci_probe_one(struct pci_dev *pdev
structure caused
need for more files to include midlayer headers.
Signed-off-by: James Smart [EMAIL PROTECTED]
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -24,6 +24,7 @@
#include linux/kthread.h
#include linux/interrupt.h
+#include scsi/scsi.h
#include scsi
Change version to 8.0.30
Change version to 8.0.30.
Signed-off-by: James Smart [EMAIL PROTECTED]
--- a/drivers/scsi/lpfc/lpfc_version.h
+++ b/drivers/scsi/lpfc/lpfc_version.h
@@ -18,7 +18,7 @@
* included with this package
+P: James Smart
+M: [EMAIL PROTECTED]
+L: linux-scsi@vger.kernel.org
+W: http://sourceforge.net/projects/lpfc
+S: Supported
+
EPSON 1355 FRAMEBUFFER DRIVER
P: Christopher Hoover
M: [EMAIL PROTECTED], [EMAIL PROTECTED]
-
To unsubscribe from this list: send
In prior conversations with folks doing utilities such as lsscsi, it became
rather apparent that it is difficult to establish the relationships between
the class device and its base device. The class-device symlink is good for
one direction, but the reverse direction didn't exist. In order to go
On Mon, 2005-08-15 at 20:52 -0400, [EMAIL PROTECTED] wrote:
What is :00:04:0 in this case ? The device is not a serial
port, which is what the ttyXX back link would lead you to believe.
Thus, it's a serial port multiplexer that supports up to N ports,
right ? and wouldn't the more
They are class devices called ttyS0, ttyS1, ttyS2 so you can say
they're uniquely named.
The problem is that Matthew wants to add a symlink from the device
device to the class device to complement the class device to device
symlink, since we end up with multiple symlinks in the devices
I can live with this. I would have liked the class: prefix, but the name
does start to get long, and this is ok.
-- james s
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 18, 2005 2:37 AM
To: James Bottomley
Cc: Matthew Wilcox; Smart, James;
Christoph,
I like it, and have no real complaints.
As familiar as this looks, there were a couple of conventions in the FC
transport that I thought should have carried over here. Namely, I saw
not all attributes being the same, thus I created 3 categories of
attributes:
Private:
These
Ok, so I'm going to have to revert my statement. After perusing the
sas transport, I went to the previous patch, which added pre-init
data to scsi_scan_target calls. I didn't understand why this was
needed.
In tracking how you were using the patch, it highlighted that you
were skipping a step.
I don't agree with the need for this patch.
See http://marc.theaimsgroup.com/?l=linux-scsim=112437379823295w=2
I think it's also a wart to add this to the scan logic, and error prone.
The error (or inconsistency) exists when the scan is not initiated by
the transport, and the target doesn't
One more thing missing...
As there is a transport object between the scsi_host and scsi_target,
the transport needs to pick up the changes made to deal with scans
made outside of the transport (after a scsi_target has been removed).
The fix that got merged into the scsi-misc tree can be seen at:
I was trying to avoid the need for an rport object, but I'm
not yet sure
it's feasible. We certainly won't put in target-persistency support
similar to FC, that was just a hack to get the existing
drivers migrated
without lots of complaints, it's not going in for new transports like
SAS
This is a heck of a statement... The customers don't see it
as SAS vs FC
vs SPI, they just see it as SCSI, and there's a lot of
expectations on
consistent behavior. We take a lot of heat defending the community's
position, even from companies that you would have thought
had signed on
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id), and
then we also want an abstract iterator in fc transport for the id for
usage in scsi_scan.c:scsi_scan_channel. Then you can lose all the
I thought by the target id is logical for everything but
SPI you meant
that FC enumerated the scsi_device id.
Yes, I meant that.
I didn't mean to address problems with persistent names, just map the
scsi_device id to an FC value.
True. Port ID is just a bad example. Unfortunately, there's
+/**
+ * sas_rport_alloc -- allocates and initialize a SAS
remote port structure
+ * @grandparent: Parent device of the parent SAS port
+ * @port:Port number of the parent SAS port
+ * @channel: SCSI Core channel number
+ * @id: SCSI Core
So this is odd... grandparent ? why pass in port # (you should
know the object already)? why is channel skipping over / not
associated with the local port ?
I didn't really want to need the drivers to keep around arrays
or lists of sas_port objects.
They're going to have to if they
One question
Does this assume that an hba is both initiator and target ? target only ?
Do we have any issues if a scsi_host is a target only ?
-- james s
FUJITA Tomonori wrote:
The following patchset adds the target mode support in
user-space. This has been living in the -mm tree for a
for this ? Are there transport-level
libraries in-between the LLDD and the SCSI Target ? Is it reflected in the
LLDD to SCSI Target messaging ?
-- james
Mike Christie wrote:
James Smart wrote:
One question
Does this assume that an hba is both initiator and target ? target only ?
Do we have any issues if a scsi_host
FUJITA Tomonori wrote:
As Mike said, now a scsi_host can be used as a target only. We need
some more work to make one scsi_host support both initiator and target
mode. Can a LLD use two scsi_hosts (for initiator and target mode
respectively)?
Sure.. a small amount of programming :)
It does
Matthew Wilcox wrote:
On Wed, Nov 29, 2006 at 11:04:22AM +0100, Adrian Bunk wrote:
+#include scsi_transport_api.h
scsi_transport_api.h is a weird little file. It's not included by
anything in the drivers/scsi directory, only
drivers/scsi/libsas/sas_scsi_host.c:#include
This patch set updates the lpfc driver to revision 8.1.11.
The patches address the following items:
- Discovery Fixes
- Fix lpfc_multi_ring_support.
- Fix Memory leaks
- Adjust LOG_FCP logging to be more meaningful.
- Add MSI (Message Signalled Interrupts) support
- Removed decoding of PCI
Add MSI (Message Signalled Interrupts) support
Actual use must be enabled via the new module parameter lpfc_use_msi
Defaults to no use
Many thanks to Frederic Temporelli who implemented the initial patch.
Signed-off-by: Frederic Temporelli [EMAIL PROTECTED]
Signed-off-by: James Smart
Adjust LOG_FCP logging to be more meaningful.
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2006-12-02 11:57:07.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_attr.c 2006-12-02 12
Add soft_wwnn sysfs attribute, rename soft_wwn_enable
The driver now allows both wwpn and wwnn to be set.
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2006-12-02 12:13
Fix lpfc_multi_ring_support.
It was not accounted for in the fast/slow rings.
Genericize the implementation and control it via sysfs
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c
Removed decoding of PCI Subsystem Id.
To avoid continually updating the driver for new subsystem ids
(as adapter modules are proliferating), remove this 2nd level decode.
Genericize the reported Adapter names to be consistent across
Emulex product line.
Signed-off-by: James Smart [EMAIL
els command
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
--- a/drivers/scsi/lpfc/lpfc_ct.c 2006-12-01 12:13:54.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_ct.c 2006-12-02 11:50:58.0 -0500
@@ -558,6
Change version number to 8.1.11
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h
--- a/drivers/scsi/lpfc/lpfc_version.h 2006-12-01 12:13:54.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_version.h 2006-12-02 12:42
Misc Fixes:
- Prevent references to NULL node list element in reset routines.
- Add missing IOCB types to switch tables
- Reset the card on Port Error 5
- Fix infinite loop in LUN reset
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_hw.h b/drivers/scsi
Fix Memory leaks associated with mbox cmds READ_LA, READ_SPARAM, REG_LOGIN
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
--- a/drivers/scsi/lpfc/lpfc_els.c 2006-12-02 11:57:07.0 -0500
+++ b/drivers/scsi/lpfc
to the
Emulex Lightpulse Fibrechannel (lpfc) SCSI device driver.
Lightly tested at this point, works.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James Smart [EMAIL PROTECTED]
drivers/scsi/lpfc/lpfc_init.c | 91 ++
1 file changed, 91 insertions
This patch adds PCI Error recovery support to the
Emulex Lightpulse Fibrechannel (lpfc) SCSI device driver.
Lightly tested at this point, works.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James Smart [EMAIL PROTECTED]
drivers/scsi/lpfc/lpfc_init.c | 91
ACK
-- james
Mariusz Kozlowski wrote:
Hello,
Add kmalloc failure check and fix the loop on error path. Without the
patch pool element at index [0] will not be freed.
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
drivers/scsi/lpfc/lpfc_mem.c |6 +-
1 file changed, 5
I don't believe this is a valid fix. This is yet another case
of the reuse-after-free issues on sdevs. The real issue is the
deleted sdev isn't truly getting deleted due to references, and
we're deadlocked trying to allocate a new one while the old one
is outstanding. This fix just jumps over
PROTECTED]
I got the oops after some hotplug events. And the similar oops can
reproduce by the following step.
James Smart already pointed out that this fix isn't valid ... it's a
bandaid that doesn't fix the underlying problem.
That's why I included his comments in the changelog.
Is anyone going
Everything is working, as it should, on a 2.6 kernel. see comments below...
Chris Knipe wrote:
Hi,
I have a RedHat 9 system running kernel 2.6.16... The system is attached
to 3 x EMC FC4700 DOE's operating as simple JBODs
Looking at /proc/scsi/scsi, I can clearly see all the devices are
You can see if a white paper we put together, which includes information
on tapes, can help you. There's also a small section on boot from SAN
which talks about configuring udev in initrd for boot devices. Although
the content references distros, it should be applicable to the kernel
generically.
Pete Wyckoff wrote:
The only place that bsg_register_rq is called is via
blk_register_queue, which is only called by add_disk. But not all
devices have a block interface or need the gendisk that these
functions assume.
FYI - very shortly, we expect dynamic transport entities to start calling
ACK - the patch is fine for lpfc
-- james s
Linas Vepstas wrote:
James,
Please review and forward upstream. This is a patch I'd previously
submitted, and reworked by [EMAIL PROTECTED] in January.
Not clear if I need to also nag James Smart (who is listed as the
maintainer) for an Acked
a existence device up. In
this case it is SDEV_DEL device, not newly added device by first scan.
This patch fixes the oops by excluding the SDEV_DEL devices in
__scsi_device_lookup_by_target().
Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED]
Cc: James Smart [EMAIL PROTECTED]
On Wed, 10 Jan
/scsi_transport_fc.c 2007-02-05 15:51:13.0 -0500
+++ b/drivers/scsi/scsi_transport_fc.c 2007-02-22 18:20:12.0 -0500
@@ -19,7 +19,7 @@
*
*
*
- * Copyright (C) 2004-2005 James Smart, Emulex Corporation
+ * Copyright (C) 2004-2007 James Smart, Emulex Corporation
*Rewrite
ACK... Looks good...
-- james s
Linas Vepstas wrote:
Bino, James,
Please review, sign-off and forward upstream.
--linas
If a PCI error is detected that cannot be recovered from, there
will be a double call of lpfc_pci_remove_one(), with the second call
resulting in a null-pointer
This patch updates the FC transport for all speeds identified in SM-HBA.
Note: it does not sync the bit definitions, as that is actually insulated
from user-space via the sysfs text string. (I could do it, but it does introduce
a potential binary-incompatibility).
-- james s
Signed-off-by: James
Per the comment in the change - it's not always prudent to immediately
remove the rport upon first notice of a disconnect. Make all rports
wait dev_loss_tmo before being deleted (and each could have a separate
dev_loss_tmo value).
-- james s
Signed-off-by: James Smart [EMAIL PROTECTED]
diff
@@ -1768,7 +1781,8 @@ static void iscsi_start_session_recovery
* flush queues.
*/
spin_lock_bh(session-lock);
- fail_all_commands(conn);
+ fail_all_commands(conn,
+ STOP_CONN_RECOVER ? DID_BUS_BUSY : DID_ERROR);
[EMAIL PROTECTED] wrote:
fast_io_fail_tmo
iscsi: session recovery_tmo
fc: rport fast_io_fail_tmo
The difference is that when the timer fires, for iscsi we unblock the
queue and fail commands in the blocked queue. FC just fails IO running
in the driver/fw/hw. The IO in the blocked queue sits
Background:
The states, in the transport are:
event state
n/arunning
lose connectivityblocked
fastfail timeout still blocked, but with fastfail indicator
dev_loss timeout unblocked/removed
). But this is largely stylistic. Preferences ? I can
post an alternative.
-- james
Mike Christie wrote:
James Smart wrote:
Background:
The states, in the transport are:
event state
n/arunning
lose connectivityblocked
So my position changes a little now that you pointed out that you
release the request queue when fastfail kicks in.
Mike Christie wrote:
Do we want to fail IO that was sitting in the queue _and_ all new
incoming IO or just what was sitting in the queue?
I believe all i/o - so that the upper
ACK.
To my knowledge bad VPD data had only been found on early prototypes, as they
avoided the typical manufacturing process. Regardless, we do try to be
preventative about this type of thing, just in case.
Thanks
-- james s
Anton Blanchard wrote:
We have seen two cases where VPD on an
Richard,
When we put this in, the kernel code that we inspected allowed for
the call if msi was not enabled (check on dev-msi_enabled), and did
nothing. Thus, we believed it was in the scope of the interface.
kfree does the same kind of thing. Testing on 2.6.21-rc4 on a machine
w/o MSI also
fyi...
For FC, we have several async events, and allow for LLDDs to send their own
data or augment the generic transport event w/ additional LLDD-data. The
infrastructure is implemented generically within the scsi midlayer.
We are using Netlink w/ broadcasts to deliver the events rather than
Jeff Garzik wrote:
Fair enough, though I definitely lean towards some use of sysfs / device
model for AN-style events specifically. The media change events are
generated by the device, not the transport, and we should definitely
have an object in the device model that represents the device
Matt,
Have your resolved the unload race conditions yet?
We'd like to update lpfc for the async scans, but our testing gets blocked
very quickly by the bugs. The bugs are not necessarily specific to lpfc
or to FC.
Stack traces are below. Simple ismod/rmmod loop can trigger them
-- james s
James Bottomley wrote:
-- each SAS object (host, device, expander, etc) has the own bsg
device
I think so; probably attached via the transport class.
FYI - I understand the idea of a bsg device per object, but really, for
something that is used rarely, it's a bunch of overhead. Objects,
This set of patches updates the lpfc driver to revision 8.2.4
All bug fixes are targeted for 2.6.25. Patches cut against scsi-misc-2.6
- Miscellaneous Discovery/ELS Fixes
- Correct Abort handler logic.
- Add parameters to enable and disable heartbeat and hba resets
- Miscellaneous Fixes
- Make
Miscellaneous Discovery/ELS Fixes:
- Delay free's of ELS requests if adapter reject conditions
- Fix concurrent PLOGI vs ADISC state handling
- Add retry mechanism for GFF_ID
- Correct some illegal state transitions around RSCN timeouts
- Fix missing return in FAN handling
Signed-off-by: James
Correct Abort handler logic. It was unconditionally waiting a minimum
of 2 seconds rather than looking for abort completion.
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
--- a/drivers/scsi/lpfc/lpfc_scsi.c 2007-11-09
Add parameters to enable and disable heartbeat and hba resets
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2007-11-09 15:54:47.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_attr.c
timeout error case due to missing clear_la
- Tighten mailbox polling code to speed up detection of fast completions
- Only allow DUMP_MEMORY if adapter offline due to overtemp errors
- Added extended error information to the log messages in chip init.
Signed-off-by: James Smart [EMAIL PROTECTED
Fix Drivers Unsolicited CT command handling - we did not handle multiframe
sequences well.
Fix error due to delay in replenishing buffers for unsolicited data.
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
--- a/drivers
Rework misplaced reference taking on node structure
Signed-off-by: James Smart [EMAIL PROTECTED]
diff -upNr a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
--- a/drivers/scsi/lpfc/lpfc_ct.c 2008-01-11 01:25:48.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_ct.c 2008-01
301 - 400 of 1457 matches
Mail list logo
