Forum: GNU Radio uspr2 working intermittently/segmentation fault

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5807290886e8a06db8e9150980c85108?d=identicon&s=25 Pham, Thanh (Guest)
on 2009-04-01 23:02
(Received via mailing list)
Hello,

I am running gnuradio on a Linux x86_64 box, fedora10. I downloaded the
code from the development trunk on 2/26/09.  Lately I notice that my
uspr2 has been working intermittently.  Sometimes, even running the
example code would give me a segmentation fault error or errors like the
one listed below.

If I turn the uspr2 off and back on then rerun the program, the program
will run again okay.

Has someone seen this behavior before or had any explanation for why it
behaves that way.

Also, is there a command to reboot/reset the uspr2 instead of turning
the power off and on?

Thanks!





./usrp2_fft_copy.py      (which is an exact copy of the usrp2_fft.py in
the example)

usrp2: failed to enable realtime scheduling

Traceback (most recent call last):

  File "./usrp2_fft_copy.py", line 290, in <module>

    main ()

  File "./usrp2_fft_copy.py", line 286, in main

    app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)

  File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 36, in __init__

    wx.App.__init__ (self, redirect=False)

  File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7935, in __init__

    self._BootstrapApp()

  File
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7509, in _BootstrapApp

    return _core_.PyApp__BootstrapApp(*args, **kwargs)

  File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 39, in OnInit

    frame = stdframe (self.top_block_maker, self.title, self._nstatus)

  File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 60, in __init__

    self.panel = stdpanel (self, self, top_block_maker)

  File
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 81, in __init__

    self.top_block = top_block_maker (frame, self, vbox, sys.argv)

  File "./usrp2_fft_copy.py", line 70, in __init__

    self.u = usrp2.source_32fc(options.interface, options.mac_addr)

  File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py",
line 577, in source_32fc

    return _usrp2.source_32fc(*args, **kwargs)

RuntimeError: Unable to retrieve daughterboard info
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-04-01 23:16
(Received via mailing list)
On Wed, Apr 01, 2009 at 03:00:57PM -0600, Pham, Thanh wrote:
>
> Has someone seen this behavior before or had any explanation for why it
> behaves that way.
>
> Also, is there a command to reboot/reset the uspr2 instead of turning
> the power off and on?
>
> Thanks!

It appears that you do not have the current firmware (and possibly
FPGA image) installed on the SD Card.  Please grab the latest from:
http://gnuradio.org/releases/usrp2-bin/trunk/

Eric
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2009-04-02 00:47
(Received via mailing list)
Eric Blossom wrote:
> It appears that you do not have the current firmware (and possibly
> FPGA image) installed on the SD Card.  Please grab the latest from:
> http://gnuradio.org/releases/usrp2-bin/trunk/
>
> Eric
>
>
set-curmudgeon-mode(True)

Segmentation Fault on the host should *never* be the correct response to
buggy firmware on the USRP2.  Ever.

set-curmudgeon-mode(False)


--
Marcus Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
C0e3469c73bb03f03b60e43032a7db93?d=identicon&s=25 Jeff Brower (Guest)
on 2009-04-02 00:57
(Received via mailing list)
Marcus-

> buggy firmware on the USRP2.  Ever.
Not everything the FPGA does -- register format/contents, FIFO widths,
etc -- can be
error checked.  There has to be some reasonable expectation on the
software side.
The typical method is a "revision id" register, the software checks this
and adjusts
capabilities.  If the revision is too far behind or doesn't match
expectation then
the software gives an error message.

-Jeff
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-04-02 01:25
(Received via mailing list)
On Wed, Apr 01, 2009 at 06:45:59PM -0400, Marcus D. Leech wrote:
> buggy firmware on the USRP2.  Ever.
>
> set-curmudgeon-mode(False)
>

I agree whole heartedly.  (There was no evidence of a segfault in the
back trace presented.)  FWIW, Johnathan fixed a problem not long ago
where there was a missing throw(...) annotation in a .i file.

We've also got ticket:346 open, "write python QA code for all possible
exceptions from all blocks".  It's on the list of tickets to be fixed
before 3.2.0 goes out the door.

For those of you wondering where we are on 3.2.0, this query
will get you all of the gating tickets:

  http://gnuradio.org/trac/query?status=assigned&sta...

Eric
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2009-04-02 01:29
(Received via mailing list)
Jeff Brower wrote:
>
> Not everything the FPGA does -- register format/contents, FIFO widths, etc -- can be
> error checked.  There has to be some reasonable expectation on the software side.
> The typical method is a "revision id" register, the software checks this and adjusts
> capabilities.  If the revision is too far behind or doesn't match expectation then
> the software gives an error message.
>
> -Jeff
>
>
An error in the (expected) format of an external input should never
result in a Seg Fault.  Nothing wrong with doing
  "Gee, this parameter seems rather odd, I'm leaving".

Two decades of writing network protocol implementations has taught me
that  making dangerous assumptions about external
  inputs leads to  various  not-nice things happening, and notorious in
the press in the context of network protocols, those
  assumptions often lead to ugly security problems (note the SNMPV3
parser issues of a few years ago!).  No security issues
  here, to be sure, but being insufficiently paranoid about external
inputs of *any* kind has leads to spectacular downfall...

Provoking a Segmentation Fault is just impolite, if nothing else.

--
Marcus Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
5807290886e8a06db8e9150980c85108?d=identicon&s=25 Pham, Thanh (Guest)
on 2009-04-03 03:06
(Received via mailing list)
It seems to run a lot better now after I reinstalled the latest firmware
on the SD Card.
Thank you.

Thanh
5807290886e8a06db8e9150980c85108?d=identicon&s=25 Pham, Thanh (Guest)
on 2009-04-03 03:31
(Received via mailing list)
I am using the two lines in the rx_nop_handler.h to print out the
timestamp.
   printf("W0: %08x  TS: %08x\n", metadata->word0,
metadata->timestamp);
       printf("I0: %08x\n", items[0]);


Looking at the timestamp that was printed out from usrp2_fft.py, I
notice that there is always a few extra ticks in the first frame.
I'm trying to understand why. Does someone have an explanation? Thanks!



TS (hex)  TS(decimal)  # of ticks in frame
(decim_rate=16)
507c5e55  1350327893
507c7594  1350333844  5951    (1st frame has 15 extra ticks,
this number changes with decimation rate but not consistent)
507c8cc4  1350339780  5936
507ca3f4  1350345716  5936
507cbb24  1350351652  5936
507cd254  1350357588  5936
507ce984  1350363524  5936
507d00b4  1350369460  5936
507d17e4  1350375396  5936
507d2f14  1350381332  5936
507d4644  1350387268  5936
507d5d74  1350393204  5936
507d74a4  1350399140  5936
507d8bd4  1350405076  5936
507da304  1350411012  5936
507dba34  1350416948  5936
507dd164  1350422884  5936
507de894  1350428820  5936
507dffc4  1350434756  5936
507e16f4  1350440692  5936
507e2e24  1350446628  5936
This topic is locked and can not be replied to.