- 28 7月, 2010 19 次提交
-
-
由 Joe Eykholt 提交于
Incoming requests shouldn't require a local exchange if we're just going to reply with one or two frames and don't expect anything further. Don't allocate exchanges for such requests until requested by the upper-layer protocol. The sequence is always NULL for new requests, so remove that as an argument to request handlers. Also change the first argument to lport->tt.seq_els_rsp_send from the sequence pointer to the received frame pointer, to supply the exchange IDs and destination ID info. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
Add module parameter create_vn2vn that behaves like the create parameter except that the new instance is created in FIP vn2vn mode. This can be replaced once we change create to allow modifying per-instance attributes before starting the instance. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
In VN2VN mode, map_dest means to use the default VN2VN OUI. Change code that uses the default FCoE OUI to use the one set in the fcoe_ctlr struct. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
When sending a FLOGI LS_ACC, which we only do in point-to-multipoint mode, the MAC descriptor should have the granted MAC set to 0x0efd00 || D_ID. When sending an LS_RJT, there should be no MAC descriptor. When sending either an LS_ACC or LS_RJT, the subcode should indicate an reply, not a request. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
The FC-BB-6 committee is proposing a new FIP usage model called VN_port to VN_port mode. It allows VN_ports to discover each other over a loss-free L2 Ethernet without any FCF or Fibre-channel fabric services. This is point-to-multipoint. There is also a variant of this called point-to-point which provides for making sure there is just one pair of ports operating over the Ethernet fabric. We add these new states: VNMP_START, _PROBE1, _PROBE2, _CLAIM, and _UP. These usually go quickly in that sequence. After waiting a random amount of time up to 100 ms in START, we select a pseudo-random proposed locally-unique port ID and send out probes in states PROBE1 and PROBE2, 100 ms apart. If no probe responses are heard, we proceed to CLAIM state 400 ms later and send a claim notification. We wait another 400 ms to receive claim responses, which give us a list of the other nodes on the network, including their FC-4 capabilities. After another 400 ms we go to VNMP_UP state and should start interoperating with any of the nodes for whic we receivec claim responses. More details are in the spec.j Add the new mode as FIP_MODE_VN2VN. The driver must specify explicitly that it wants to operate in this mode. There is no automatic detection between point-to-multipoint and fabric mode, and the local port initialization is affected, so it isn't anticipated that there will ever be any such automatic switchover. It may eventually be possible to have both fabric and VN2VN modes on the same L2 network, which may be done by two separate local VN_ports (lports). When in VN2VN mode, FIP replaces libfc's fabric-oriented discovery module with its own simple code that adds remote ports as they are discovered from incoming claim notifications and responses. These hooks are placed by fcoe_disc_init(). A linear list of discovered vn_ports is maintained under the fcoe_ctlr struct. It is expected to be short for now, and accessed infrequently. It is kept under RCU for lock-ordering reasons. The lport and/or rport mutexes may be held when we need to lookup a fcoe_vnport during an ELS send. Change fcoe_ctlr_encaps() to lookup the destination vn_port in the list of peers for the destination MAC address of the FIP-encapsulated frame. Add a new function fcoe_disc_init() to initialize just the discovery portion of libfcoe for VN2VN mode. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
Enhancement: add debug messages at all state transitions. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
There are three modes that libfcoe currently supports, and a new one is coming. Change the fcoe_ctlr_init() interface to add the mode desired. This should not change any functionality. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
It turns out most of the FIP work is now done from worker threads or process context now, so there's no need to use a spin lock. Change to use mutex instead of spin lock and delayed_work instead of a timer. This will make it nicer for the VN_port to VN_port feature that will interact more with the libfc layers requiring that spinlocks not be held. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Vasu Dev 提交于
This is per FC-BB-5 Annex-D recommendation and per that if address checking fails then drop the frame. FIP code paths are already doing this so only needed for fcoe frames. The src address checking is limited to only fip mode since this might break non-fip mode used in p2p due to used OUI based addressing in some p2p code paths, going forward FIP will be the only mode, therefore limited this to only FIP mode so that it won't break non-fip p2p mode for now. -v2 Removes FCOE packet type checking since fcoe_rcv is registered to receive only FCoE type packets from netdev and it is already checked by netdev. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Vasu Dev 提交于
The fc_fabric_logoff and fc_fabric_login are redundant here after recently added fcoe_ctlr_link_down/up to these functions, therefore this patch removes logoff and login to only use link down and up here. This works best for their current usages with fcoe DCB link down or up. This also works well to avoid EIO errors when fcoe DCB link goes down as lport state moves out of ready quickly from fcoe_ctlr_link_down and that allows re-queuing timed out IOs for this case also. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Bhanu Prakash Gollapudi 提交于
As per FC-BB-5 rev.2, section 7.8.7.1, strict ordering of FIP descriptors is required for ELS requests. Also, look for missing and duplicate critical descriptors. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Bhanu Prakash Gollapudi 提交于
Clear virtual link for NPIV ports is now handled by resetting the matching vnport. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Bhanu Prakash Gollapudi 提交于
As per FC-BB-5 rev 2, section 7.8.6.2, malformed FIP frame shall be discarded. Drop discovery adv, ELS and CLV's with duplicate critical descriptors. [Resending after incorporating Joe's review comments] Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
Allow the D flag (indicating that keep-alives are not needed) to be updated dynamically from received FIP advertisements. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
keep alives are disabled due to fd_flags set and also stop updating keep alive values in that case. Update select fcf time only if fcf is not already selected or select time is not already determined from parse adv, and then have select time cleared only once after fcf is selected. Changed deadline check to time_after_eq() from time_after() since now next timeout will be on exact 2.5 times FKA followed by first advertisement. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
[This patch has several improvements to the code in the fip timers. It hasn't been tested yet. I'm sending it out for review. Vasu, perhaps you can merge this with your patch and test it together.] The current code allows an advertisement to be used even if it has been 3 times the FCF keep-alive advertisement period (FKA) since one was received from that FCF. The spec. calls for 2.5 times FKA. Fix this and make sure we detect missed keep-alives promptly. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Bhanu Prakash Gollapudi 提交于
Host does not send discovery solicitation messages if Disc. Adv from FCF are dropped. It restarts sending solicitation only after receiving a Discovery Adv. from FCF. Fix is to restart solicitation immediately after CVL processing. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Bhanu Prakash Gollapudi 提交于
Avoid infinite loop while processing FIP ELS or discovery advertisement with non-critical descriptors. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Acked-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
A check in fcoe_ctlr_send_keep_alive() returns if there's no port_id for the local port. This could miss a keep alive if we just did a host reset and have logged off and will log back in. Return only if we are doing the port keep alive, in which case we need to be logged in. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
- 25 5月, 2010 1 次提交
-
-
由 Alexey Dobriyan 提交于
- C99 knows about USHRT_MAX/SHRT_MAX/SHRT_MIN, not USHORT_MAX/SHORT_MAX/SHORT_MIN. - Make SHRT_MIN of type s16, not int, for consistency. [akpm@linux-foundation.org: fix drivers/dma/timb_dma.c] [akpm@linux-foundation.org: fix security/keys/keyring.c] Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Acked-by: NWANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 5月, 2010 8 次提交
-
-
由 Vasu Dev 提交于
Currently fcoe module ref count is used for tracking active fcoe instances, it means each fcoe instance create increments the count while destroy dec the count. The dec is done only if fcoe instance is destroyed from /sysfs but not if destroyed due to NETDEV_UNREGISTER event. So this patch moves only module_put doing dec to common fcoe_if_destroy function, so that dec would occur on ever fcoe instance destroy. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Kaladhar Musunuru 提交于
All VNports are sending FIP Keep-Alive messages with port_id and wwpn of the parent host instead of it's own port_id and wwpn. Standard FIP descriptor type 11 indicates to send own port_id and port_name. Signed-off-by: NKaladhar Musunuru <kmusunuru@juniper.net> Acked-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Kaladhar Musunuru 提交于
Fix typo in memset. Incorrect length parameter to memset resulting non-zero MAC address in FPMA messages. Signed-off-by: NKaladhar Musunuru <kmusunuru@juniper.net> Acked-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Vasu Dev 提交于
Currently rtnl mutex is grabbed during fcoe create, destroy, enable and disable operations while sysfs s_active read mutex is already held, but simultaneously other networking events could try grabbing write s_active mutex while rtnl is already held and that is causing circular lock warning, its detailed log pasted at end. In this log, the rtnl was held before write s_active during device renaming but there are more such cases as Joe reported another instance with tg3 open at:- http://www.open-fcoe.org/pipermail/devel/2010-February/008263.html This patch fixes this issue by not waiting for rtnl mutex during fcoe ops, that means if rtnl mutex is not immediately available then restart_syscall() to allow others waiting in line to grab s_active along with rtnl mutex to finish their work first under these mutex. Currently rtnl mutex was grabbed twice during fcoe_destroy call flow, second grab was from fcoe_if_destroy called from fcoe_destroy after dropping rtnl mutex before calling fcoe_if_destroy, so instead made fcoe_if_destroy always called with rtnl mutex held to have this mutex grabbed only once in this code path. However left matching rtnl_unlock as-is in its original place as it was dropped there for good reason since very next call causes synchronous fip worker flush and if rtnl mutex is still held before flush then that would cause new circular warning between fip->recv_work and rtnl mutex, I've added detailed comment for this on fcoe_if_destroy calling and rtnl muxtes unlocking. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.33.1linux-stable-2.6.33 #1 ------------------------------------------------------- fcoemon/18823 is trying to acquire lock: (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] but task is already holding lock: (s_active){++++.+}, at: [<ffffffff8115ef93>] sysfs_get_active_two+0x31/0x48 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (s_active){++++.+}: [<ffffffff81077bdb>] __lock_acquire+0xb73/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8115e5df>] sysfs_deactivate+0x8b/0xe0 [<ffffffff8115edfb>] sysfs_addrm_finish+0x36/0x55 [<ffffffff8115d0cc>] sysfs_hash_and_remove+0x53/0x6a [<ffffffff8115f353>] sysfs_remove_link+0x21/0x23 [<ffffffff812b6c93>] device_rename+0x99/0xcb [<ffffffff8138dbf0>] dev_change_name+0xd5/0x1d2 [<ffffffff8138deee>] dev_ifsioc+0x201/0x2ac [<ffffffff8138e4ba>] dev_ioctl+0x521/0x632 [<ffffffff81379e43>] sock_do_ioctl+0x3d/0x47 [<ffffffff8137a254>] sock_ioctl+0x213/0x222 [<ffffffff81114614>] vfs_ioctl+0x32/0xa6 [<ffffffff81114b94>] do_vfs_ioctl+0x490/0x4d6 [<ffffffff81114c30>] sys_ioctl+0x56/0x79 [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #1 (rtnl_mutex){+.+.+.}: [<ffffffff81077bdb>] __lock_acquire+0xb73/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffff813959f9>] rtnl_lock+0x17/0x19 [<ffffffff8138ccae>] register_netdevice_notifier+0x1e/0x19b [<ffffffffa02580c1>] 0xffffffffa02580c1 [<ffffffff81002069>] do_one_initcall+0x5e/0x15e [<ffffffff81084094>] sys_init_module+0xd8/0x23a [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #0 (fcoe_config_mutex){+.+.+.}: [<ffffffff81077a85>] __lock_acquire+0xa1d/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff810635b1>] param_attr_store+0x27/0x35 [<ffffffff81063619>] module_attr_store+0x26/0x2a [<ffffffff8115dae3>] sysfs_write_file+0x108/0x144 [<ffffffff81107bd1>] vfs_write+0xae/0x10b [<ffffffff81107cee>] sys_write+0x4a/0x6e [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b other info that might help us debug this: 3 locks held by fcoemon/18823: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8115da17>] sysfs_write_file+0x3c/0x144 #1: (s_active){++++.+}, at: [<ffffffff8115ef86>] sysfs_get_active_two+0x24/0x48 #2: (s_active){++++.+}, at: [<ffffffff8115ef93>] sysfs_get_active_two+0x31/0x48 stack backtrace: Pid: 18823, comm: fcoemon Tainted: G W 2.6.33.1linux-stable-2.6.33 #1 Call Trace: [<ffffffff81076c38>] print_circular_bug+0xa8/0xb6 [<ffffffff81077a85>] __lock_acquire+0xa1d/0xd2b [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff8106ac70>] ? cpu_clock+0x43/0x5e [<ffffffff81074e12>] ? lockstat_clock+0x11/0x13 [<ffffffff81074e40>] ? lock_release_holdtime+0x2c/0x127 [<ffffffff8115ef93>] ? sysfs_get_active_two+0x31/0x48 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff810635b1>] param_attr_store+0x27/0x35 [<ffffffff81063619>] module_attr_store+0x26/0x2a [<ffffffff8115dae3>] sysfs_write_file+0x108/0x144 [<ffffffff81107bd1>] vfs_write+0xae/0x10b [<ffffffff81076596>] ? trace_hardirqs_on_caller+0x125/0x150 [<ffffffff81107cee>] sys_write+0x4a/0x6e [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Robert Love 提交于
This patch creates a port_id member in struct fc_lport. This allows libfc to just deal with fc_lport instances instead of calling into the fc_host to get the port_id. This change helps in only using symbols necessary for operation from the libfc structures. libfc still needs to change the fc_host_port_id() if the port_id changes so the presentation layer (scsi_transport_fc) can provide the user with the correct value, but libfc shouldn't rely on the presentation layer for operational values. Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Robert Love 提交于
It doesn't make sense to update the link speed in the is_link_ok() routine. Move it to it's own routine and acquire the device speed when we're configuring the device initially as well as if there are any netdev events received. Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Robert Love 提交于
The fcf pointer is checked again after this verification making the first check redundant. Remote the first check. Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Vasu Dev 提交于
fcoe_create exits using out_nodev label when module is not yet LIVE but this exit path unlocks the rtnl_lock though rtnl lock was not held in this case. So this patch replaces out_nodev with out_nomod to exit w/o unlocking rtnl_lock. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
- 12 4月, 2010 6 次提交
-
-
由 Chris Leech 提交于
Print all world wide node names (node, port and fabric) with the same format specifier of "%16.16llx". That makes sure they all print as a 16 character hex string, with lower case letters, no 0x prefix, and without stripping off any leading 0s. Signed-off-by: NChris Leech <christopher.leech@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Vasu Dev 提交于
No reason to restrict CDB size to 12 bytes in fcoe, so increased to 16 so that 16 bytes SCSI CDB doesn't fail. Uses common define to set max_cmd_len for fcoe and fnic, fnic is already setting max_cmd_len to 16. sg_readcap -l fails without this fix. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Vasu Dev 提交于
Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Chris Leech 提交于
Allow for dormant states while link configuration completes. In the default link mode, this is equivalent to the old check. Signed-off-by: NChris Leech <christopher.leech@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Chris Leech 提交于
The FIP controler state wasn't being reset on a disable. A disable/enable sequence should be treated as a link event. Otherwise, when using disable to mask a time when the link is up but unusable, FCF discovery would attempt to continue and login would jump directly to the non-FIP fallback on enable. Signed-off-by: NChris Leech <christopher.leech@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Robert Love 提交于
FPMA indicates that the Fabric will provide the host's N_Port's MAC address. When sending a FLOGI/FDISC frame and FPMA was negotiated through FIP discovery we still need to provide the MAC descriptor, as per the specification, but the MAC should be zero'd out since the FCF will be providing it in the FLOGI/FDISC ACC. In FC-BB-5 section 7.8.7.4.2 (Fabric login) it states: The MAC address field in the MAC address descriptor of a FIP FLOGI Request operation or a FIP NPIV FDISC Request operation shall contain: a) the proposed MAC address to use as VN_Port MAC address if the ENode is requesting to use SPMA (see table 27); b) all zeroes to indicate no MAC address is proposed if the ENode is requesting to use FPMA (see table 27); or c) the proposed MAC address to use as VN_Port MAC address if the ENode supports both SPMA and FPMA and leaves the decision of which addressing scheme to use to the FCF (i.e., if both the FP and SP bits are set to one, see table 27). This patch fixes case B. This patch also adds debug statements to illustrate whether a FPMA or SPMA MAC is added to a FLOGI/FDISC frame. Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NChris Leech <christopher.leech@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
- 11 4月, 2010 6 次提交
-
-
由 Joe Eykholt 提交于
When the kernel is configured for preemption, using smp_processor_id() when preemption is enabled causes a warning backtrace and is wrong since we could move off of that CPU as soon as we get the ID, and we would be referencing the wrong CPU, and possibly an invalid one if it could be hotswapped out. Remove the fc_lport_get_stats() function and explicitly use per_cpu_ptr() to get the statistics. Where preemption has been disabled by holding a _bh lock continue to use smp_processor_id(), but otherwise use get_cpu()/put_cpu(). In fcoe_recv_frame() also changed the cases where we return in the middle to do a goto to the code which bumps ErrorFrames and does a put_cpu(). Two of these cases didn't bump ErrorFrames before, but doing so is harmless because they "can't happen", due to prior length checks. Also rearranged code in fcoe_recv_frame() to have only one call to fc_exch_recv(). It's just as efficient and saves a call to put_cpu(). In fc_fcp.c, adjusted a FIXME comment for code which doesn't need fixing. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
The link and last_link fields in the fcoe_ctlr struct are no longer useful, since they are always set to the same value, and FIP always calls libfc to pass link information to the lport. Eliminate those fields and rename link_work to timer_work, since it no longer has any link change work to do. Thanks to Brian Uchino for discovering this issue. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
Remove an unused variable, mac, in fcoe_recv_frame(). Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
In point-to-point mode, we need to save the source MAC from received FLOGI requests to use as the destination MAC for all outgoing frames. We stopped doing that at some point. Use the lport_set_port_id method to catch incoming FLOGI frames and pass them to fcoe_ctlr_recv_flogi() so it can save the source MAC. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
The debug message that indicated we are using non-FIP mode was being printed only if we were already in non-FIP mode. Also changed the message text to make it more clear the mode is being set, not that the message is indicating how FLOGI was received. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Joe Eykholt 提交于
In point-to-point mode, the destination MAC address for the FLOGI response was zero because the LS_ACC for the FLOGI wasn't getting intercepted by FIP. Change to call fcoe_ctlr_els_send when sending any ELS, not just requests. Signed-off-by: NJoe Eykholt <jeykholt@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-