Sir, is there any way we can start the target without setting the pause parameters? my nic doesn't support pause (autonegotiation,rx tx is not supported) if i try starting the target without setting pause the following error: fcconf: fcc_fcoe_config: FCoE create of eth0 failed fcconf: fcc_fcoe_config: error 95 (null) fcconf: fcc_fcoe_config: exiting at fcc_fcoe.c:142
I tried commenting the code in *fcoe_if.c* whcih checks for pause but it returns a *segmentation fault.* and the system hangs (so cant send you the syslog) thank you, -vinvishwa On Fri, Feb 12, 2010 at 12:03 AM, <[email protected]> wrote: > Vishwa, > > We can help you more if you can help us with the full spec of the setup > that you are using. > > -Steeve > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Joe Eykholt > Sent: Thursday, February 11, 2010 11:32 PM > To: vinvishwa > Cc: [email protected] > Subject: Re: [Open-FCoE] Help with FCoE login process > > vinvishwa wrote: > > hi Sir > > sorry to disturb you once again > > > > As it implies from the previous discussions that configurations in > > virtual environment(Sun Virtual Box) seems clumsy and unreal , > > > > I tried to switch to real hardware > > wanted to get some issues answered > > > > * I do not have a server architecture nor a scsi disk ; *so will > > normal SATA disk work as target disk?* > > Yes. SCST even has a way of using a regular file as a target LUN. > > > * Also i have set up FCoE target on Fedora 8 and then added the > > target disk, but *fcconf returns* error as pause settings are > not > > enabled > > > > o linux-ihct:/home/pxe123 # ethtool -A eth0 tx on rx on > > Cannot get device pause settings: *Operation not > supported* > > o *linux-g557:/ # ethtool -a eth0* > > Pause parameters for eth0: > > Cannot get device pause settings: Operation not supported > > You need a different Ethernet device, one that supports pause. > I would think most 1 gig or 10G NICs support pause. > > Joe > > > > > Please help me with this. > > Thank you, > > -vinvishwa > > > > > > On Thu, Feb 11, 2010 at 1:23 AM, Joe Eykholt <[email protected] > > <mailto:[email protected]>> wrote: > > > > vinvishwa wrote: > > > > Have you tried putting both sides in promiscuous mode? > > > > > > No I didn't (as i didn't know how to) > > But I will surely do this > > > > I looked at the traces. showed FLOGIs > > from both sides but no accepts from either. I can't > explain > > that. > > The other trace showed FLOGIs only from the initiator, > nothing > > received from the target. Why the difference? Was the > wireshark > > done on the target side? Wireshark will go promiscuous, so > maybe > > that's the difference. > > > > > > The trace > > fcoe_pcap_100110.pcap is from Wireshark running on host > > m/c(windows XP.) > > > > (the target and initiator are VMs in Sun Virtual box and both > > are using bridged network) > > > > and the 2nd trace named file was taken at the *initiator side > > *with the tcpdump cmd > > tcpdump -p -i ethX -w /tmp/file -s 0 > > *Does that mean that the inititor did not receive any of the > > FLOGIs sent by the target?* > > (but both the initiator and target m/cs can ping each other) > > > > > > One problem is that the unicast address used by the FLOGI doesn't > > work on switches, it's really meant to be point-to point (no > switch). > > The FLOGI is sent to MAC 0e:fc:00:ff:ff:fe, a unicast address. > > The switch should flood that to all ports since it doesn't know > > the address. The virtual switch may not do that since it "thinks" > > it knows all the MAC addresses on the guests. That would explain > > why none of the ports receive the FLOGI. > > > > If there was a way to directly connect the NICs of the two guests, > > that would be nice, but there probably isn't since this is such > > a special case. > > > > I will do the steps suggested by you and will send it to you > > > > Thank you really very much > > -vinvishwa > > > > > > On Wed, Feb 10, 2010 at 11:31 PM, Joe Eykholt > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > Joe Eykholt wrote: > > > > vinvishwa wrote: > > > > hello Sir, > > > > > > On Mon, Feb 8, 2010 at 5:25 PM, Joe Eykholt > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>>> wrote: > > > > vinvishwa wrote: > > > > Thank you sir for replying > > It made many things clear and also the > problem > > with my > > configuration. > > > > but the issue with my configuration still > remains > > unsolved. > > > > and you said its currently broken > > so is there any workaround to get my point > to > > point > > setup working? > > > > > > > > * (*my setup in Sun > > Virtual Box > > *initiator*: 2.6.33-rc4 on > > Fedora Core > > 12 with > > fcoeadm tool > > *target*: 2.6.23 on Suse > Linux > > Enterprise Server > > initiator-target > connected > > over lossless > > connection in Sun Virtual Box(intel e1000 > :bridged > > *pause frames > > enabled*) > > *)* > > > > > > Actually, I may have mis-spoken earlier. I just > > tried it > > and a similar > > setup just worked for me. I'm running the same > > release > > on the > > initiator, > > and the target is 2.6.23-1. I'm running on real > > servers, > > though, > > not under a virtual machine. It really > shouldn't > > matter, > > however, > > as long as the virtual NIC works correctly. I'm > > running > > Fedora 8 > > on my target, and Fedora 10 on the initiator. > > > > I tried it with the initiator having the larger > > WWPN and > > also with > > the target having the larger WWPN, in case there > > was a bug > > related to that. > > > > It will take a few retries for FLOGI to go > through > > because > > it waits to see if FIP will work first. > > If it doesn't work for you, then I don't know > what > > it is. > > You could send me binary tcpdump capture and I > > might be able > > to point out the problem. Use > > > > tcpdump -p -i ethX -w /tmp/file -s 0 > > > > before you do 'fcoeadm -c ethX' on the initiator > side. > > > > i am attaching the tcp dump file > > also the wireshark tcpdump > > please have a look and help me solve the issue. > > > > You could also try putting the interface on both > > sides into > > promiscuous mode, in case its a MAC filter > problem. > > > > The reason I gave the -p parameter on tcpdump is > > so that > > it *doesn't* go promiscuous, since it might hide > > the problem. > > > > Good luck, > > Joe > > > > thank you. > > > > > > > > > > On Mon, Feb 8, 2010 at 11:39 PM, Joe Eykholt > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>>> <mailto:[email protected] > > <mailto:[email protected]> > > > > <mailto:[email protected] > <mailto:[email protected]>> > > <mailto:[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > vinvishwa wrote: > > > > hi, > > i am trying to figure out the fcoe > login > > process in a > > point to point > > architecture > > > > In my setup the *target sends out > FLOGIs* > > (this is right > > as per the > > quickstart guide at open-fcoe) > > > > when the initiator is started it > sends > > an *FIP > > solicitation* > > and then starts sending FLOGIs but is > *not > > able to login* > > > > Can someone please elaborate the > *point to > > point fcoe > > login* process > > > > > > It is currently broken. The old target > > expects a > > non-standard interface > > in which the other end accepts the FLOGI > > with the > > fabric flag off > > indicating > > point to point, and with the assigned > FC_IDs in > > the FLOGI accept. > > I'm not sure why that's been broken in > the > > initiator, but > > point-to-point > > mode hasn't been enough of a priority. > > > > The correct, standard FC way of doing it > is for > > both sides to > > send a > > LS_ACC for FLOGI from fffffe to 0 and > then > > for the > > one with the > > higher WWPN > > to decide the FC_IDs and do a PLOGI. > > > > There's a FIP proposal (at least one) to > do > > VN to > > VN port > > without a > > fabric, > > and I hope we'll implement that at some > point. > > > > The current initiator sends out both a > FIP > > solicitation and > > non-FIP > > FLOGIs > > until it receives either a FIP frame, at > which > > point it > > enters FIP mode, > > or an LS_ACC for the FLOGI, at which > point it > > continues in > > non-FIP mode. > > > > > > Also i tried to figure out the fcoe > > initiator > > code but > > couldn't > > get the > > starting point > > Plz help me with the entry > > point of > > the code > > > > > > The module_init fcoe_init() is one entry > point. > > Another is > > the code > > that handles > > the creation of an new initiator thru > /sys > > write: > > fcoe_create(). > > > > Joe > > > > > > > > > > -- -vinvishwa > > > > > > I don't know what the problem is. > > > > Have you tried putting both sides in promiscuous mode? > > > > ifconfig ethX promisc > > > > I don't really think that will fix it, but it is worth > a try. > > > > I looked at the traces. fcoe_pcap_100110.pcap showed > FLOGIs > > from both sides but no accepts from either. I can't > > explain that. > > The other trace showed FLOGIs only from the initiator, > > nothing > > received from the target. Why the difference? Was the > > wireshark > > done on the target side? Wireshark will go > promiscuous, > > so maybe > > that's the difference. > > > > On the initiator side, you could enable debug logging > and > > that > > might help us figure it out. Do this as root after the > > initiator is started: > > > > echo 15 > > /sys/module/libfc/parameters/debug_logging > > echo 3 > > /sys/module/fcoe/parameters/debug_logging > > > > > > Also add: > > > > echo 3 > > /sys/module/libfcoe/parameters/debug_logging > > > > We might as well get everything we can get! > > > > > > dmesg -n 8 > > # wait at least 10 seconds with the initiator > > running then: > > dmesg | tail > > > > > > Make that > > dmesg | tail -100 > > > > so we get a good hunk of log. If you could send that, it > may > > help. > > > > > > Good luck. > > > > Joe > > > > > > _______________________________________________ > > devel mailing list > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > http://www.open-fcoe.org/mailman/listinfo/devel > > > > > > > > > > > > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
