*'fcoeadm -c eth2.10' * doesn't work, I receive the error: ' fcoeadm: Failed to open /sys/module/fcoe/parameters/create'
*'echo eth2.10 > /sys/module/libfcoe/parameters**/create_vn2vn'* Nothing happens, in Wireshark trace I see the following messages: Probe request Claim notification and a lot of beacon messages *'echo eth2.10 > /sys/module/libfcoe/parameters**/create'* I have the successful FLOGI , but the client can't connect me (I can't find the PLOGI and PRLI accept, see attached file) Natti On Thu, Jan 23, 2014 at 3:34 AM, Robert Love <[email protected]>wrote: > > On 01/16/2014 07:18 AM, Bart Van Assche wrote: > >> On 01/15/14 21:36, Robert Love wrote: >> >>> On 01/15/2014 05:23 AM, Natti Shwarts wrote: >>> >>>> Hello, >>>> >>>> I'm trying to work with SCSI target over FCoE. (using fileio sample of >>>> SCST) >>>> I'm using Linux 3.8.13 , Intel 10G card and HP5900 switch with VSAN 10 >>>> for >>>> FCoE. >>>> >>> I am not familiar with the SCST commands to be able to tell you if >>> you're using it right. I might be able to give you some pointers to help >>> debug though. >>> >>> The problem is that the target doesn't send FLOGI to the switch. >>>> (I have windows client that works with the same switch and configuration >>>> and succeed to login) >>>> >>>> The following is the operation sequence I perform: >>>> - vconfig add eth2 10 >>>> - load scst, scst_user >>>> - fileio_tgt disk0 file0 disk1 file1 >>>> - modprobe fcoe >>>> - echo eth2.10 > /sys/module/libfcoe/parameters/create_vn2vn (fcoeadm >>>> -c >>>> eth2.10 returned an error) >>>> >>> This is definitely a problem. >>> >>> * Does eth2.10 exist? Was the VLAN configured on the switch? How did you >>> configure it on the host/target? Did you manually create the vlan or did >>> you use the 'fipvlan' application to discover/create it? >>> >>> * What was the output of the 'echo' command? Why did it fail? >>> >>> * What did the log files say (dmesg/messages)? You can also turn on >>> debug_logging for the fcoe kernel modules to get more details. I >>> wouldn't bother with fcoe.ko at this point as its debug_logging is very >>> verbose. You could try the following commands after the modprobe. >>> >>> # echo 0xFFFF > /sys/module/libfcoe/parameters/debug_logging >>> # echo 0xFFFF > /sys/module/libfc/parameters/debug_logging >>> >>> - modprobe fcst >>>> - echo "add disk0 0" > >>>> /sys/kernel/scst_tgt/targets/fcst/20\:01\:b8\:ca\:3a\:62\: >>>> 82\:f9/luns/mgmt >>>> >>>> - echo "add disk1 1" > >>>> /sys/kernel/scst_tgt/targets/fcst/20\:01\:b8\:ca\:3a\:62\: >>>> 82\:f9/luns/mgmt >>>> >>>> - echo 1 > >>>> /sys/kernel/scst_tgt/targets/fcst/20\:01\:b8\:ca\:3a\:62\: >>>> 82\:f9/enabled >>>> >>>> My questions are: >>>> 1. What is wrong with the above sequence ? >>>> >>> You should have stopped at the fcoeadm fail, no need to proceed with the >>> failure. >>> >>>> 2. Do you have any idea why fcoeadm fails ? >>>> >>> No, I don't have any information about the failure to draw a conclusion. >>> >>> 3. Is "fcoeadm -c eth2.10" is exactly the same as "echo eth2.10 > >>>> /sys/module/libfcoe/parameters/create_vn2vn " ? >>>> >>> No. 'fcoeadm -c eth2.10' with do 'Fabric Mode' and not VN2VN. >>> >>> I'm not sure what kernel version you're using. For a while we did not >>> have VN2VN support in fcoeadm. Only in more recent kernels did we change >>> the sysfs interfaces to use files in /sys/bus/fcoe/. This change allowed >>> us to add VN2VN support to fcoeadm with the '-m|--mode' option. The >>> 'echo' method is how you enable VN2VN on older kernels. On newer kernels >>> that method will still work, but it is deprecated because of the new >>> interfaces. >>> >> I have tried the sequence mentioned by Natti myself. What I see on the >> initiator system with kernel 3.13-rc8 is the following: >> * When not using VLAN (eth0), login works fine - the SCSI devices exported >> by the target system appear at the initiator side. >> * When using VLAN, no SCSI devices appear after reloading the fcoe module >> on the initiator system. However, about 22 seconds later a kernel crash >> is triggered. From the netconsole output: >> > > I tried to reproduce this with TCM and fcoe with 3.13-rc8 and it sent me > in a slightly different direction from what you were testing, Bart. > > I tried the fcoe_sysfs vn2vn create (i.e. ethX > ctlr_create, vn2vn > > mode, 1 > enabled). I tried with a VLAN and without and neither worked. > > I tried the legacy create (i.e. echo ethX > create_vn2vn) with no-vlan and > it worked, luns discovered. > > I think the problem for me is that with fcoe_sysfs the mode defaults to > FABRIC until the user sets the mode to VN2VN. When the fcoe_interface is > created via the 'echo ethX > ctlr_create' it does the dev_uc_add based on > the fact that it's in FABRIC mode and it doesn't tell the networking layer > to listen for the VN2VN well-known addresses. When the mode is set by the > user later, these MACs aren't updated. > > if (fip->mode == FIP_MODE_VN2VN) { > printk(KERN_ERR "RWL RWL RWL - listening on ALL_VN2VN\n"); > dev_mc_add(netdev, FIP_ALL_VN2VN_MACS); > dev_mc_add(netdev, FIP_ALL_P2P_MACS); > } else > dev_mc_add(netdev, FIP_ALL_ENODE_MACS); > > I wrote a hacky patch to fix this, but it didn't seem to fix it for me, so > I've got something wrong. > > Natti, I'm curious what happens for you if you don't do the 'fcoeadm -c > eth2.10' and instead only do the 'echo eth2.10 > /sys/module/libfcoe/ > parameters/create_vn2vn'. > > //Rob >
_______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
