I have been messing with the XG image for my X310 and have run into a strange issue. First, here is the system setup: - Intel X710 dual 10 Gb/s SFP+ NIC - 2x SFP+ direct attach copper cables - X310 (revision 4) - 2x UBX-160 (both v1 boards) - UHD_3.13.1.HEAD-0-ga0a71d10 - Ubuntu 16.04 When I updated the firmware of the radio I noted that port 0 was not showing up as having a link (per ethtool). I changed UHD versions several times and flashed the radio after each version change. At some point I walked away for ~ 15 minutes, and when I came back the link was established and uhd_find_devices was happy. I rebooted and was able to repeat this process several times. It seems that it takes ~ 10-20 minutes for the link to show as active in Linux. The radio shows lights on both port 0 and 1, but only port 1 comes up right away on the NIC. Any ideas as to why this is happening? It's a real bummer because while testing my current code, it's easy to get the radio into a bad state that requires restarting it. Then I get to wait for the link to come up. Thanks! -Dave

Dave, I can’t speak to anything that might be happening because of recent code changes, but I would recommend you doing a quick switch of the cables/ports to see if the problem follows the cable/SFP/Port jut in case it’s a coincidence that you did the firmware update at that time. I’ve had problems with those passive Twin-Ax cables being quirky occasionally, and there were some cheap brands we could never get to work when I originally qualified various SFP’s and Cables. It’s hard to imagine a firmware problem causing a long delay like this at the physical level, the link negotiation is a largely automatic process between both ends. -Ian > On Nov 26, 2018, at 3:17 PM, Dave NotTelling via USRP-users <usrp-users@lists.ettus.com> wrote: > > I have been messing with the XG image for my X310 and have run into a strange issue. First, here is the system setup: > Intel X710 dual 10 Gb/s SFP+ NIC > 2x SFP+ direct attach copper cables > X310 (revision 4) > 2x UBX-160 (both v1 boards) > UHD_3.13.1.HEAD-0-ga0a71d10 > Ubuntu 16.04 > When I updated the firmware of the radio I noted that port 0 was not showing up as having a link (per ethtool). I changed UHD versions several times and flashed the radio after each version change. At some point I walked away for ~ 15 minutes, and when I came back the link was established and uhd_find_devices was happy. I rebooted and was able to repeat this process several times. It seems that it takes ~ 10-20 minutes for the link to show as active in Linux. The radio shows lights on both port 0 and 1, but only port 1 comes up right away on the NIC. > > Any ideas as to why this is happening? It's a real bummer because while testing my current code, it's easy to get the radio into a bad state that requires restarting it. Then I get to wait for the link to come up. > > Thanks! > > -Dave > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

 I forgot to mention that I did test to see if the cable was at fault.

 Thankfully I have another X310 kicking around and was able to verify

- Intel X710 dual 10 Gb/s SFP+ NIC
- 2x SFP+ direct attach copper cables
- X310 (revision 4)
- 2x UBX-160 (both v1 boards)
- UHD_3.13.1.HEAD-0-ga0a71d10
- Ubuntu 16.04

Ian, I forgot to mention that I did test to see if the cable was at fault. I swapped the cables and still only got a link on port 1. Using either cable to either port on the NIC from port 0 on the radio results in no link for several minutes. The light on the radio port immediately comes on and blinks, but the X710 doesn't seem to think there is a link. Thankfully I have another X310 kicking around and was able to verify that both SFP+ ports work immediately with it. Perhaps something is wrong with the first X310? I've tried flashing it with both the onboard JTAG (USB-B connector up front) and the normal uhd_image_loader utility, so I don't think it's a misconfiguration issue on the radio firmware. Is there a way to flush the EEPROM without bricking the radio? Thanks! -Dave On Mon, Nov 26, 2018 at 11:13 PM Ian Buckley <ianb@ionconcepts.com> wrote: > Dave, > I can’t speak to anything that might be happening because of recent code > changes, but I would recommend you doing a quick switch of the cables/ports > to see if the problem follows the cable/SFP/Port jut in case it’s a > coincidence that you did the firmware update at that time. I’ve had > problems with those passive Twin-Ax cables being quirky occasionally, and > there were some cheap brands we could never get to work when I originally > qualified various SFP’s and Cables. > > It’s hard to imagine a firmware problem causing a long delay like this at > the physical level, the link negotiation is a largely automatic process > between both ends. > > -Ian > > > On Nov 26, 2018, at 3:17 PM, Dave NotTelling via USRP-users < > usrp-users@lists.ettus.com> wrote: > > I have been messing with the XG image for my X310 and have run into a > strange issue. First, here is the system setup: > > - Intel X710 dual 10 Gb/s SFP+ NIC > - 2x SFP+ direct attach copper cables > - X310 (revision 4) > - 2x UBX-160 (both v1 boards) > - UHD_3.13.1.HEAD-0-ga0a71d10 > - Ubuntu 16.04 > > When I updated the firmware of the radio I noted that port 0 was not > showing up as having a link (per ethtool). I changed UHD versions several > times and flashed the radio after each version change. At some point I > walked away for ~ 15 minutes, and when I came back the link was established > and uhd_find_devices was happy. I rebooted and was able to repeat this > process several times. It seems that it takes ~ 10-20 minutes for the link > to show as active in Linux. The radio shows lights on both port 0 and 1, > but only port 1 comes up right away on the NIC. > > Any ideas as to why this is happening? It's a real bummer because while > testing my current code, it's easy to get the radio into a bad state that > requires restarting it. Then I get to wait for the link to come up. > > Thanks! > > -Dave > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > >

 I take that back.  I didn't realize the other X310 was on the HG

 I don't have another system that I can test on at the moment, but I

  I forgot to mention that I did test to see if the cable was at

  Thankfully I have another X310 kicking around and was able to verify

- Intel X710 dual 10 Gb/s SFP+ NIC
- 2x SFP+ direct attach copper cables
- X310 (revision 4)
- 2x UBX-160 (both v1 boards)
- UHD_3.13.1.HEAD-0-ga0a71d10
- Ubuntu 16.04

Ian, I take that back. I didn't realize the other X310 was on the HG image. Once I updated it to the XG image port 0 stopped working properly. No matter what combination of cable arrangements I use, port 0 just does not want to come up even on the spare X310. I don't have another system that I can test on at the moment, but I see that as the next step to troubleshooting. Is there a known gold standard version that you've had success using the XG image with? Thanks! -Dave On Tue, Nov 27, 2018 at 8:47 AM Dave NotTelling <dmp250net@gmail.com> wrote: > Ian, > > I forgot to mention that I did test to see if the cable was at > fault. I swapped the cables and still only got a link on port 1. Using > either cable to either port on the NIC from port 0 on the radio results in > no link for several minutes. The light on the radio port immediately comes > on and blinks, but the X710 doesn't seem to think there is a link. > > Thankfully I have another X310 kicking around and was able to verify > that both SFP+ ports work immediately with it. Perhaps something is wrong > with the first X310? I've tried flashing it with both the onboard JTAG > (USB-B connector up front) and the normal uhd_image_loader utility, so I > don't think it's a misconfiguration issue on the radio firmware. Is there > a way to flush the EEPROM without bricking the radio? > > Thanks! > > -Dave > > On Mon, Nov 26, 2018 at 11:13 PM Ian Buckley <ianb@ionconcepts.com> wrote: > >> Dave, >> I can’t speak to anything that might be happening because of recent code >> changes, but I would recommend you doing a quick switch of the cables/ports >> to see if the problem follows the cable/SFP/Port jut in case it’s a >> coincidence that you did the firmware update at that time. I’ve had >> problems with those passive Twin-Ax cables being quirky occasionally, and >> there were some cheap brands we could never get to work when I originally >> qualified various SFP’s and Cables. >> >> It’s hard to imagine a firmware problem causing a long delay like this at >> the physical level, the link negotiation is a largely automatic process >> between both ends. >> >> -Ian >> >> >> On Nov 26, 2018, at 3:17 PM, Dave NotTelling via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >> I have been messing with the XG image for my X310 and have run into a >> strange issue. First, here is the system setup: >> >> - Intel X710 dual 10 Gb/s SFP+ NIC >> - 2x SFP+ direct attach copper cables >> - X310 (revision 4) >> - 2x UBX-160 (both v1 boards) >> - UHD_3.13.1.HEAD-0-ga0a71d10 >> - Ubuntu 16.04 >> >> When I updated the firmware of the radio I noted that port 0 was not >> showing up as having a link (per ethtool). I changed UHD versions several >> times and flashed the radio after each version change. At some point I >> walked away for ~ 15 minutes, and when I came back the link was established >> and uhd_find_devices was happy. I rebooted and was able to repeat this >> process several times. It seems that it takes ~ 10-20 minutes for the link >> to show as active in Linux. The radio shows lights on both port 0 and 1, >> but only port 1 comes up right away on the NIC. >> >> Any ideas as to why this is happening? It's a real bummer because while >> testing my current code, it's easy to get the radio into a bad state that >> requires restarting it. Then I get to wait for the link to come up. >> >> Thanks! >> >> -Dave >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >>

  I take that back.  I didn't realize the other X310 was on the HG image.  Once I updated it to the XG image port 0 stopped working properly.  No matter what combination of cable arrangements I use, port 0 just does not want to come up even on the spare X310.

  I don't have another system that I can test on at the moment, but I see that as the next step to troubleshooting.  Is there a known gold standard version that you've had success using the XG image with?

  I forgot to mention that I did test to see if the cable was at fault.  I swapped the cables and still only got a link on port 1.  Using either cable to either port on the NIC from port 0 on the radio results in no link for several minutes.  The light on the radio port immediately comes on and blinks, but the X710 doesn't seem to think there is a link.

  Thankfully I have another X310 kicking around and was able to verify that both SFP+ ports work immediately with it.  Perhaps something is wrong with the first X310?  I've tried flashing it with both the onboard JTAG (USB-B connector up front) and the normal uhd_image_loader utility, so I don't think it's a misconfiguration issue on the radio firmware.  Is there a way to flush the EEPROM without bricking the radio?  

Dave, I might be miss-reading what you are telling me here but…..are you saying that an “HG” image brought up both ports over a 10G Twinax passive cable to the X710, but not the “XG” image? Is it possible either you or someone at Ettus has got HG and XG switched in the latest release? Can you use ethtool or similar on the host to see what speeds the links are running at? I confess I have never thought to try deliberatly bringing 1G up over what I always regarded as a 10G only cable. (I’ve not personally qualified an XG image since UHD3.9 so no recent Golden XG version to offer you, I use HG images in my day to day.) -Ian > On Nov 27, 2018, at 6:22 AM, Dave NotTelling <dmp250net@gmail.com> wrote: > > Ian, > > I take that back. I didn't realize the other X310 was on the HG image. Once I updated it to the XG image port 0 stopped working properly. No matter what combination of cable arrangements I use, port 0 just does not want to come up even on the spare X310. > > I don't have another system that I can test on at the moment, but I see that as the next step to troubleshooting. Is there a known gold standard version that you've had success using the XG image with? > > Thanks! > > -Dave > > On Tue, Nov 27, 2018 at 8:47 AM Dave NotTelling <dmp250net@gmail.com <mailto:dmp250net@gmail.com>> wrote: > Ian, > > I forgot to mention that I did test to see if the cable was at fault. I swapped the cables and still only got a link on port 1. Using either cable to either port on the NIC from port 0 on the radio results in no link for several minutes. The light on the radio port immediately comes on and blinks, but the X710 doesn't seem to think there is a link. > > Thankfully I have another X310 kicking around and was able to verify that both SFP+ ports work immediately with it. Perhaps something is wrong with the first X310? I've tried flashing it with both the onboard JTAG (USB-B connector up front) and the normal uhd_image_loader utility, so I don't think it's a misconfiguration issue on the radio firmware. Is there a way to flush the EEPROM without bricking the radio? > > Thanks! > > -Dave > > On Mon, Nov 26, 2018 at 11:13 PM Ian Buckley <ianb@ionconcepts.com <mailto:ianb@ionconcepts.com>> wrote: > Dave, > I can’t speak to anything that might be happening because of recent code changes, but I would recommend you doing a quick switch of the cables/ports to see if the problem follows the cable/SFP/Port jut in case it’s a coincidence that you did the firmware update at that time. I’ve had problems with those passive Twin-Ax cables being quirky occasionally, and there were some cheap brands we could never get to work when I originally qualified various SFP’s and Cables. > > It’s hard to imagine a firmware problem causing a long delay like this at the physical level, the link negotiation is a largely automatic process between both ends. > > -Ian > > >> On Nov 26, 2018, at 3:17 PM, Dave NotTelling via USRP-users <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >> >> I have been messing with the XG image for my X310 and have run into a strange issue. First, here is the system setup: >> Intel X710 dual 10 Gb/s SFP+ NIC >> 2x SFP+ direct attach copper cables >> X310 (revision 4) >> 2x UBX-160 (both v1 boards) >> UHD_3.13.1.HEAD-0-ga0a71d10 >> Ubuntu 16.04 >> When I updated the firmware of the radio I noted that port 0 was not showing up as having a link (per ethtool). I changed UHD versions several times and flashed the radio after each version change. At some point I walked away for ~ 15 minutes, and when I came back the link was established and uhd_find_devices was happy. I rebooted and was able to repeat this process several times. It seems that it takes ~ 10-20 minutes for the link to show as active in Linux. The radio shows lights on both port 0 and 1, but only port 1 comes up right away on the NIC. >> >> Any ideas as to why this is happening? It's a real bummer because while testing my current code, it's easy to get the radio into a bad state that requires restarting it. Then I get to wait for the link to come up. >> >> Thanks! >> >> -Dave >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >