Hi Marcus, On the USRP2 side, the green LED turns on when the link speed changes to 1000, and goes off once the speed goes to 0, showing a solid green for about 4/10s of a second, and no activity on the orange or yellow light unless I run find_usrps as soon as the speed changes to 1000, as I described before, at which point I'll see an orange flash on the USRP2 side and a proper response on the host machine.
--Ricky On Mar 19, 2011, at 6:27 PM, Marcus D. Leech wrote: > > Ricky: > > When the link is rapidly cycling between 1000 and 0, what is the green LED on > the GigE interface RJ-45 doing? Is it on solidly, or does it > go on and off? Does the yellow/orange lamp on the same RJ-45 connector > flash with traffic? > > On 03/19/2011 07:18 PM, Ricky A. Melgares wrote: >> >> Hello, >> >> I recently starting having ethernet connectivity issues with our USRP2. >> Whenever I run "find_usrps", I get a no USRP2 found message. The USRP2 >> worked perfectly before without any issues on a Thinkpad T410 running Ubuntu >> 10.10 with a repo install of gnuradio, along with the latest corresponding >> FPGA and firmware (XCVR2450) images. I figured that the gnuradio environment >> had somehow become broken, so I decided to do a clean install of gnuradio >> and the corresponding packages/dependencies from repo (as well as reflashing >> the FPGA and firmware images on the old and a new SD card) on a new system >> to no avail. I next tried every suggestion I could find on the mailing list >> and forums. This included making sure that my network-manager and firewall >> were disabled, using ethtool to turn rx on, setting up networking according >> to the UHD - USRP2 and N Serial Application Notes (as well as using the >> USRP2 recovery tool to set the USRP2's IP address), monitoring my ethernet >> interface with tcpdump and Wireshark, and disconnecting the daughterboard >> card, all to no avail. >> >> When monitoring the network interface, I sometimes see the broadcast >> packet(s) sent by find_usrps, and very rarely actually get a response. When >> I do get a response, the connection seems to die immediately after, as >> find_usrps is unable to find the USRP2 when I ran again. All the lights on >> the front blink upon power up, LEDs D and F remain on afterward, I am using >> a gigabit interface and cable, and the fuse is okay. USRP2 and >> system/package info is listed below, as well as the output from serial and >> ethtool. The output from serial is most interesting, because the eth link >> speed changes to 1000 and then to 0 immediately after roughly every 3 >> seconds. Running find_usrps immediately (like a split second after, almost >> simultaneously) and only after the eth link speed changes to 1000 yields a >> proper response from the USRP2 momentarily. >> >> Has anyone seen this behavior before or have any other suggestions? >> >> --Ricky >> >> USRP2 Rev 4.0 >> XCVR2450 (Rev 753) >> >> $ cat /etc/issue >> Ubuntu 10.10 \n \l >> >> $ uname -a >> Linux gares-e5400 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC >> 2011 i686 GNU/Linux >> >> $ dpkg -s gnuradio >> Package: gnuradio >> Status: install ok installed >> Priority: optional >> Section: comm >> Installed-Size: 40 >> Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com> >> Architecture: all >> Version: 3.2.2.dfsg-1ubuntu3 >> Recommends: libgnuradio, libgnuradio-dev, gnuradio-doc, python-gnuradio, >> gnuradio-utils, gnuradio-examples, gnuradio-apps >> Description: The GNU Software Radio Toolkit >> This is a virtual package that installs the entire GNU Radio and USRP >> software >> set. >> Original-Maintainer: Bdale Garbee <bd...@gag.com> >> >> ------------------ >> find_usrps output (when it actually works, which is very rarely) >> >> $ find_usrps >> 00:50:c2:85:32:c3 hw_rev = 0x0400 >> >> ------------------ >> ethtool output >> >> $ sudo ethtool eth0 >> Settings for eth0: >> Supported ports: [ TP ] >> Supported link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Half 1000baseT/Full >> Supports auto-negotiation: Yes >> Advertised link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Half 1000baseT/Full >> Advertised pause frame use: No >> Advertised auto-negotiation: Yes >> Speed: 1000Mb/s >> Duplex: Full >> Port: Twisted Pair >> PHYAD: 1 >> Transceiver: internal >> Auto-negotiation: on >> MDI-X: Unknown >> Supports Wake-on: g >> Wake-on: g >> Current message level: 0x000000ff (255) >> Link detected: yes >> >> ------------------ >> Serial output (after running "sudo ethtool -A eth0 rx on," otherwise >> ethernet flow control set to none) >> >> $ screen /dev/tty.usbserial-A700eBUj 230400 >> TX dbid: 0x60 >> Rx dbid: 0x61 >> >> TxRx-NEWETH >> 00:50:C2:85:32:C3 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >> eth link changed: speed = 0 >> >> .... the eth link speed continuos to alternate indefinitely, and every 3 >> seconds the eth link speed changes to 1000, and then to 0 immediately after
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
