History log of /openbmc/linux/drivers/scsi/libfc/fc_rport.c (Results 76 – 100 of 279)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# f90377ab 20-Jul-2010 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: provide space for LLD after remote port structure

Add pre-zeroed space after the allocation for fc_rport_priv
for use by the lower-level driver.

This is primarily for VN2VN FIP mode,

[SCSI] libfc: provide space for LLD after remote port structure

Add pre-zeroed space after the allocation for fc_rport_priv
for use by the lower-level driver.

This is primarily for VN2VN FIP mode, but could be used in
other ways someday.

The space required is specified in lport->rport_priv_size.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 42e90414 20-Jul-2010 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: convert rport lookup to be RCU safe

To allow LLD to do lookups on rports without grabbing a mutex,
make them RCU-safe. The caller of lport->tt.rport_lookup will
have the choice of hol

[SCSI] libfc: convert rport lookup to be RCU safe

To allow LLD to do lookups on rports without grabbing a mutex,
make them RCU-safe. The caller of lport->tt.rport_lookup will
have the choice of holding disc_mutex or the rcu_read_lock().

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.35-rc5, v2.6.35-rc4, v2.6.35-rc3
# f034260d 11-Jun-2010 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: fix indefinite rport restart

Remote ports were restarting indefinitely after getting
rejects in PRLI.

Fix by adding a counter of restarts and limiting that with
the port login retry l

[SCSI] libfc: fix indefinite rport restart

Remote ports were restarting indefinitely after getting
rejects in PRLI.

Fix by adding a counter of restarts and limiting that with
the port login retry limit as well.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 4b2164d4 11-Jun-2010 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: Fix remote port restart problem

This patch somewhat combines two fixes to remote port handing in libfc.

The first problem was that rport work could be queued on a deleted
and freed rp

[SCSI] libfc: Fix remote port restart problem

This patch somewhat combines two fixes to remote port handing in libfc.

The first problem was that rport work could be queued on a deleted
and freed rport. This is handled by not resetting rdata->event
ton NONE if the rdata is about to be deleted.

However, that fix led to the second problem, described by
Bhanu Gollapudi, as follows:
> Here is the sequence of events. T1 is first LOGO receive thread, T2 is
> fc_rport_work() scheduled by T1 and T3 is second LOGO receive thread and
> T4 is fc_rport_work scheduled by T3.
>
> 1. (T1)Received 1st LOGO in state Ready
> 2. (T1)Delete port & enter to RESTART state.
> 3. (T1)schdule event_work, since event is RPORT_EV_NONE.
> 4. (T1)set event = RPORT_EV_LOGO
> 5. (T1)Enter RESTART state as disc_id is set.
> 6. (T2)remember to PLOGI, and set event = RPORT_EV_NONE
> 6. (T3)Received 2nd LOGO
> 7. (T3)Delete Port & enter to RESTART state.
> 8. (T3)schedule event_work, since event is RPORT_EV_NONE.
> 9. (T3)Enter RESTART state as disc_id is set.
> 9. (T3)set event = RPORT_EV_LOGO
> 10.(T2)work restart, enter PLOGI state and issues PLOGI
> 11.(T4)Since state is not RESTART anymore, restart is not set, and the
> event is not reset to RPORT_EV_NONE. (current event is RPORT_EV_LOGO).
> 12. Now, PLOGI succeeds and fc_rport_enter_ready() will not schedule
> event_work, and hence the rport will never be created, eventually losing
> the target after dev_loss_tmo.

So, the problem here is that we were tracking the desire for
the rport be restarted by state RESTART, which was otherwise
equivalent to DELETE. A contributing factor is that we dropped
the lock between steps 6 and 10 in thread T2, which allows the
state to change, and we didn't completely re-evaluate then.

This is hopefully corrected by the following minor redesign:

Simplify the rport restart logic by making the decision to
restart after deleting the transport rport. That decision
is based on a new STARTED flag that indicates fc_rport_login()
has been called and fc_rport_logoff() has not been called
since then. This replaces the need for the RESTART state.

Only restart if the rdata is still in DELETED state
and only if it still has the STARTED flag set.

Also now, since we clear the event code much later in the
work thread, allow for the possibility that the rport may
have become READY again via incoming PLOGI, and if so,
queue another event to handle that.

In the problem scenario, the second LOGO received will
cause the LOGO event to occur again.

Reported-by: Bhanu Gollapudi <bprakash@broadcom.com>
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# f8fc6c2c 11-Jun-2010 Bhanu Prakash Gollapudi <bprakash@broadcom.com>

[SCSI] libfc: Handle unsolicited PRLO request

Resubmitting after incorporating Joe's review comment.

Unsolicited PRLO request is now handled by sending LS_ACC,
and then relogin to the remote port i

[SCSI] libfc: Handle unsolicited PRLO request

Resubmitting after incorporating Joe's review comment.

Unsolicited PRLO request is now handled by sending LS_ACC,
and then relogin to the remote port if an N-port login
session exists for that remote port.

Note that this patch should be applied on top of Joe Eykholt's
"Fix remote port restart problem" patch.

Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 618461c0 11-Jun-2010 Bhanu Prakash Gollapudi <bprakash@broadcom.com>

[SCSI] libfc: Honor LS_ACC response codes for PRLI

As per FC-LS Rev 1.62 table 46, response codes are handled as follows:

1. If the Req executed is true, PRLI is accepted.
2. If Req executed is not

[SCSI] libfc: Honor LS_ACC response codes for PRLI

As per FC-LS Rev 1.62 table 46, response codes are handled as follows:

1. If the Req executed is true, PRLI is accepted.
2. If Req executed is not set, if resp code is 5,
PRLI is not retried and port is logged out.
3. If resp code is anything apart from 1 or 5, PRLI is retired
upto max retry count.

Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 292e40b9 11-Jun-2010 Bhanu Prakash Gollapudi <bprakash@broadcom.com>

[SCSI] libfc: Retry a rejected PRLI request

Retry upto max_rport_retry_count when a target responds with
LS_RJT for a PRLI request.

Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Si

[SCSI] libfc: Retry a rejected PRLI request

Retry upto max_rport_retry_count when a target responds with
LS_RJT for a PRLI request.

Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 732bee7a 11-Jun-2010 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

fix typos concerning "hierarchy"

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>


Revision tags: v2.6.35-rc2, v2.6.35-rc1, v2.6.34, v2.6.34-rc7, v2.6.34-rc6, v2.6.34-rc5, v2.6.34-rc4, v2.6.34-rc3, v2.6.34-rc2
# a2f6a024 12-Mar-2010 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: recode incoming PRLI handling

Reduce indentation in fc_rport_recv_prli_req() using gotos.
Also add payload length checks.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by

[SCSI] libfc: recode incoming PRLI handling

Reduce indentation in fc_rport_recv_prli_req() using gotos.
Also add payload length checks.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 5a0e3ad6 24-Mar-2010 Tejun Heo <tj@kernel.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when bu

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

show more ...


Revision tags: v2.6.34-rc1, v2.6.33
# 5b7a381e 16-Feb-2010 Hugh Daschbach <hdasch@broadcom.com>

[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.

Both PLOGI and RTV response processing conditionally scale e_d_tov,
but use different scaling factors. The scaling factor is cor

[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.

Both PLOGI and RTV response processing conditionally scale e_d_tov,
but use different scaling factors. The scaling factor is correct in
RTV response processing. Bring PLOGI e_d_tov scaling in line with RTV
common service parameter inspection.

Signed-off-by: Hugh Daschbach <hdasch@broadcom.com>
Acked-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.33-rc8, v2.6.33-rc7, v2.6.33-rc6, v2.6.33-rc5
# 3b709150 21-Jan-2010 Hugh Daschbach <hdasch@broadcom.com>

[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.

Both PLOGI and RTV response processing conditionally scale e_d_tov,
but use different scaling factors. The scaling factor is cor

[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.

Both PLOGI and RTV response processing conditionally scale e_d_tov,
but use different scaling factors. The scaling factor is correct in
RTV response processing. Bring PLOGI e_d_tov scaling in line with RTV
common service parameter inspection.

Signed-off-by: Hugh Daschbach <hdasch@broadcom.com>
Acked-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.33-rc4, v2.6.33-rc3, v2.6.33-rc2, v2.6.33-rc1
# 5543c72e 10-Dec-2009 Abhijeet Joglekar <abjoglek@cisco.com>

[SCSI] libfc: remote port gets stuck in restart state without really restarting

We ran into a scenario where a remote port goes into RESTART state, but
never gets added to scsi transport. The runnin

[SCSI] libfc: remote port gets stuck in restart state without really restarting

We ran into a scenario where a remote port goes into RESTART state, but
never gets added to scsi transport. The running vmcore showed the following:
a) Port was in RESTART state
b) rdata->event was STOP
c) no work gets scheduled for the remote work to fc_rport_work

After this point, shut/no-shut of the remote port did not cause the port
to get re-discovered. The port would move betwen DELETE and RESTART states,
but the event would always be STOP, no work would get scheduled to
fc_rport_work and the port would not get added to scsi_transport.

The problem is that rdata->event is not set to NONE after a port is
restarted. After this point, no more work gets scheduled for the remote port
since new work is scheduled only if rdata->event is non-NONE. So, the event
and state keep changing, but fc_rport_work does not get scheduled to actually
handle the event.

Here's a transition of states that explains the above observation:

) Port is first in READY State, event is NONE

2) RSCN on shut, port goes to DELETED, event is stop

3) Before fc_rport_work runs, RSCN on no-shut, port goes to RESTART, event is
still STOP

4) fc_rport_work gets scheduled, removes the port from transport, sees state
as RESTART, begins the PLOGI state machine, event remains as STOP (event NOT
changed to NONE, this is the bug)

5) Plogi state machine completes, port state goes to READY, event goes to
READY, but no work is scheduled since event was STOP (non-NONE) before.
Fc_rport_work is not scheduled, port remains in READY state, but is not added
to transport.

Things are broken at this point. Libfc rport is ready, but no transport rport
created.

6) now a shut causes port state to change to DELETE, event to change to STOP,
no work gets scheduled

7) no-shut causes port state to change to RESTART, event remains at STOP,
no work gets scheduled

(6) and (7) now get repeated everytime we do shut/no-shut. No way to get out
of this state. Fcc reset does not help too.

Only way to get out is to load/unload module.

Fix is to set rdata->event to NONE while processing the STOP/LOGO/FAILED
events, inside the discovery and rport locks.

Signed-off-by: Abhijeet Joglekar <abjoglek@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.32
# 63e27fb8 20-Nov-2009 Yi Zou <yi.zou@intel.com>

[SCSI] libfc: add support of receiving ELS_RLS

Upon receiving ELS_RLS, send the Link Error Status Block (LESB) back.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Robert Love <robert.w.lo

[SCSI] libfc: add support of receiving ELS_RLS

Upon receiving ELS_RLS, send the Link Error Status Block (LESB) back.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.32-rc8, v2.6.32-rc7
# b94f8951 03-Nov-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc fcoe: increase ELS and CT timeouts

The FC-LS spec. says ELS timeouts should be 2 x R_A_TOV.
The FC-GS spec. says CT timeouts should be 3 x R_A_TOV.

We've been using E_D_TOV for both of

[SCSI] libfc fcoe: increase ELS and CT timeouts

The FC-LS spec. says ELS timeouts should be 2 x R_A_TOV.
The FC-GS spec. says CT timeouts should be 3 x R_A_TOV.

We've been using E_D_TOV for both of those.

Change for all ELS and CT requests except FLOGI, which we
leave at 2 seconds (using E_D_TOV). One could argue that
R_A_TOV is locally determined until after FLOGI succeeds.

This does change FLOGI for vports which becomes FDISC.
This does not change the REC/SRR timeout which is 2 seconds.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 3a3b42bf 03-Nov-2009 Robert Love <robert.w.love@intel.com>

[SCSI] libfc: Formatting cleanups across libfc

This patch makes a variety of cleanup changes to all libfc files.

This patch adds kernel-doc headers to all functions lacking them
and attempts to bet

[SCSI] libfc: Formatting cleanups across libfc

This patch makes a variety of cleanup changes to all libfc files.

This patch adds kernel-doc headers to all functions lacking them
and attempts to better format existing headers. It also add kernel-doc
headers to structures.

This patch ensures that the current naming conventions for local ports,
remote ports and remote port private data is upheld in the following
manner.

struct instance (i.e. variable name)
--------------------------------------------------
fc_lport lport
fc_rport rport
fc_rport_libfc_priv rpriv
fc_rport_priv rdata

I also renamed dns_rp and ptp_rp to dns_rdata and ptp_rdata
respectively.

I used emacs 'indent-region' and 'tabify' on all libfc files
to correct spacing alignments.

I feel sorry for anyone attempting to review this patch.

Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 8866a5d9 03-Nov-2009 Robert Love <robert.w.love@intel.com>

[SCSI] libfc: Add libfc/fc_libfc.[ch] for libfc internal routines

include/scsi/libfc.h is currently loaded with common code
shared between libfc's sub-modules as well as shared between
libfc and fco

[SCSI] libfc: Add libfc/fc_libfc.[ch] for libfc internal routines

include/scsi/libfc.h is currently loaded with common code
shared between libfc's sub-modules as well as shared between
libfc and fcoe. Previous patches attempted to move out
non-common code. This patch creates two files for common
libfc routines that will not be shared with fcoe, fnic or
any other LLDs.

Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.32-rc6
# b4a9c7ed 21-Oct-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: fix free of fc_rport_priv with timer pending

Timer crashes were caused by freeing a struct fc_rport_priv
with a timer pending, causing the timer facility list to be
corrupted. This wa

[SCSI] libfc: fix free of fc_rport_priv with timer pending

Timer crashes were caused by freeing a struct fc_rport_priv
with a timer pending, causing the timer facility list to be
corrupted. This was during FC uplink flap tests with a lot
of targets.

After discovery, we were doing an PLOGI on an rdata that was
in DELETE state but not yet removed from the lookup list.
This moved the rdata from DELETE state to PLOGI state.
If the PLOGI exchange allocation failed and needed to be
retried, the timer scheduling could race with the free
being done by fc_rport_work().

When fc_rport_login() is called on a rport in DELETE state,
move it to a new state RESTART. In fc_rport_work, when
handling a LOGO, STOPPED or FAILED event, look for restart
state. In the RESTART case, don't take the rdata off the
list and after the transport remote port is deleted and
exchanges are reset, re-login to the remote port.

Note that the new RESTART state also corrects a problem we
had when re-discovering a port that had moved to DELETE state.
In that case, a new rdata was created, but the old rdata
would do an exchange manager reset affecting the FC_ID
for both the new rdata and old rdata. With the new state,
the new port isn't logged into until after any old exchanges
are reset.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 8f550f93 21-Oct-2009 Chris Leech <christopher.leech@intel.com>

[SCSI] libfc: fix memory corruption caused by double frees and bad error handling

I was running into several different panics under stress, which I traced down
to a few different possible slab corru

[SCSI] libfc: fix memory corruption caused by double frees and bad error handling

I was running into several different panics under stress, which I traced down
to a few different possible slab corruption issues in error handling paths.
I have not yet looked into why these exchange sends fail, but with these
fixes my test system is much more stable under stress than before.

fc_elsct_send() could fail and either leave the passed in frame intact
(failure in fc_ct/els_fill) or the frame could have been freed if the
failure was is fc_exch_seq_send(). The caller had no way of knowing, and
there was a potential double free in the error handling in fc_fcp_rec().

Make fc_elsct_send() always free the frame before returning, and remove the
fc_frame_free() call in fc_fcp_rec().

While fc_exch_seq_send() did always consume the frame, there were double free
bugs in the error handling of fc_fcp_cmd_send() and fc_fcp_srr() as well.

Numerous calls to error handling routines (fc_disc_error(),
fc_lport_error(), fc_rport_error_retry() ) were passing in a frame pointer that
had already been freed in the case of an error. I have changed the call
sites to pass in a NULL pointer, but there may be more appropriate error
codes to use.

Question: Why do these error routines take a frame pointer anyway? I
understand passing in a pointer encoded error to the response handlers, but
the error routines take no action on a valid pointer and should never be
called that way.

Signed-off-by: Chris Leech <christopher.leech@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 473e2856 21-Oct-2009 Robert Love <robert.w.love@intel.com>

[SCSI] libfc, fcoe: Don't EXPORT_SYMBOLS unnecessarily

These are a few functions that were not used by other
modules. They did not need to be exported so this patch
removes the EXPORT_SYMBOLS call f

[SCSI] libfc, fcoe: Don't EXPORT_SYMBOLS unnecessarily

These are a few functions that were not used by other
modules. They did not need to be exported so this patch
removes the EXPORT_SYMBOLS call for each.

Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 85b5893c 21-Oct-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: fix typo in retry check on received PRLI

A received Fibre Channel ELS PRLI request contains a bit that
indicates whether the remote port supports certain retry processing
sequences. T

[SCSI] libfc: fix typo in retry check on received PRLI

A received Fibre Channel ELS PRLI request contains a bit that
indicates whether the remote port supports certain retry processing
sequences. The test for this bit was somehow coded to use multiply
instead of AND!

This case would apply only for target mode operation, and it is
unlikely to be noticed as an initiator.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


Revision tags: v2.6.32-rc5, v2.6.32-rc4, v2.6.32-rc3, v2.6.32-rc1, v2.6.32-rc2, v2.6.31, v2.6.31-rc9, v2.6.31-rc8
# 8abbe3a4 25-Aug-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: fix handling of incoming Discover Address (ADISC) requests

The local port facility has been replying to ADISC requests without
looking to see if the remote port is logged in. This is

[SCSI] libfc: fix handling of incoming Discover Address (ADISC) requests

The local port facility has been replying to ADISC requests without
looking to see if the remote port is logged in. This is incorrect.
An ADISC request requires PLOGI first. It should be rejected if
the sending remote port is not logged in.

This is like other incoming requests that require login, all of
which should be handled in the remote port module.

Move the ADISC request handling from fc_lport.c to fc_rport.c.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 370c3bd0 25-Aug-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: use ADISC to verify rport login state

When rport_login is called on an rport that is already thought
to be logged in, use ADISC. If that fails, redo PLOGI.
This is less disruptive aft

[SCSI] libfc: use ADISC to verify rport login state

When rport_login is called on an rport that is already thought
to be logged in, use ADISC. If that fails, redo PLOGI.
This is less disruptive after fabric changes that don't affect
the state of the target.

Implement the sending of ADISC via fc_els_fill.

Add ADISC state to the rport state machine. This is entered from READY
and returns to READY after successful completion. If it fails, the rport
is either logged off and deleted or re-does PLOGI.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# 68a1750b 25-Aug-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: LOGO response code had extraeous enter_rtv

fc_rport_logo_resp() had a call to fc_rport_enter_rtv() if the
LOGO was accepted. This must've been a copy/paste mistake, but
it didn't matt

[SCSI] libfc: LOGO response code had extraeous enter_rtv

fc_rport_logo_resp() had a call to fc_rport_enter_rtv() if the
LOGO was accepted. This must've been a copy/paste mistake, but
it didn't matter since we don't stay in the LOGO state long enough
to hit this code.

Change fc_rport_logo_resp() to just enter the delete state
no matter what.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


# feab4ae7 25-Aug-2009 Joe Eykholt <jeykholt@cisco.com>

[SCSI] libfc: re-login to remote ports that send us LOGO

After a quick link flap, a target was seen to send us a LOGO.
Apparently, it saw an RSCN reporting that we had dropped out of the
fabric afte

[SCSI] libfc: re-login to remote ports that send us LOGO

After a quick link flap, a target was seen to send us a LOGO.
Apparently, it saw an RSCN reporting that we had dropped out of the
fabric after we had logged back into it.

This is likely in larger fabrics (more than 2 FC switches) after
a quick link flap at the initiator. Each link transition causes
an port-specific RSCN to the target. After the link comes back up,
the initiator successfully discovers and does a PLOGI to the target
before the target sees the first RSCN reporting the initiator is gone,
and it sends a LOGO. The target may see a subsequent RSCN saying the
port is back, but probably wouldn't send a PLOGI and leaves it
up to the initiator to re-login.

An RSCN can be delayed by the switches due to software layers but a
PLOGI is forwarded in hardware causing the PLOGI to beat the RSCN.

If a remote port is in the discovered set and sends a LOGO, re-login to it.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

show more ...


12345678910>>...12