Hello all,
I seem to be having some strange behaviour when trying to lock and
unlock
multiple times. I am using a USRP2 with the latest trunk of GNU Radio
(just
compiled/update the firmware and updated FPGA code to the latest
release),
and Ubuntu 8.10 Server as the OS.
The test script I am using is:
class top_block(gr.top_block):
def init(self):
gr.top_block.init(self)
self._usrp_source = usrp2.source_32fc(‘eth1’,
‘00:50:c2:85:30:6d’)
self.connect(self._usrp_source, gr.null_sink(8))
if name == ‘main’:
app = top_block()
app.start()
for x in range (2):
print str(x) + " Lock"
app.lock()
print str(x) + " Unlock"
app.unlock()
print "Pass"
app.stop()
When I run this script it hangs on the second call of unlock and never
makes
it to pass.
Any ideas?
Thank You,
Kieran
On Tue, Feb 24, 2009 at 2:54 PM, Kieran B. [email protected]
wrote:
When I run this script it hangs on the second call of unlock and never makes
it to pass.
Thanks for the minimal error test case, that helps.
Is it possible for you to use gdb from another terminal window to see
where it is hung up?
I’ll test this here locally when I get a few moments, but that might
not happen soon.
Johnathan
On Wed, 2009-02-25 at 12:19 +1300, Kieran B. wrote:
Here is the backtrace from the main thread:
This is showing that the main thread is stopped waiting for the
flowgraph thread to finish as a result of an internal call to stop().
Can you post the other traceback?
Johnathan
Here is the backtrace from the main thread:
(gdb) bt
#0 0xb80ef424 in __kernel_vsyscall ()
#1 0xb80bc075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7bb5fef in boost:
:join ()
from /usr/lib/libboost_thread-mt.so.1.35.0
#3 0xb7bc4223 in gruel::thread_group::join_all (this=0x8f81cd4)
at thread_group.cc:78
#4 0xb7d48740 in gr_scheduler_tpb::wait (this=0x8f81cd0)
at gr_scheduler_tpb.cc:94
#5 0xb7d4ea69 in gr_top_block_impl::wait (this=0x8fccde0)
at gr_top_block_impl.cc:124
#6 0xb7d4f0ea in gr_top_block_impl::restart (this=0x8fccde0)
at gr_top_block_impl.cc:162
#7 0xb7d4f470 in gr_top_block_impl::unlock (this=0x8fccde0)
at gr_top_block_impl.cc:152
#8 0xb7d4e2c0 in gr_top_block::unlock (this=0x8fccd18) at
gr_top_block.cc:90
#9 0xb7dcd4f1 in _wrap_gr_top_block_sptr_unlock (args=0xb7ebaccc)
at gnuradio_swig_py_runtime.cc:14389
#10 0x0805d867 in PyObject_Call ()
#11 0x080cd502 in PyEval_EvalFrameEx ()
#12 0x080d0345 in PyEval_EvalCodeEx ()
#13 0x080ce728 in PyEval_EvalFrameEx ()
#14 0x080d0345 in PyEval_EvalCodeEx ()
—Type to continue, or q to quit—
#15 0x080d0557 in PyEval_EvalCode ()
#16 0x080edf8f in PyRun_FileExFlags ()
#17 0x080ee25a in PyRun_SimpleFileExFlags ()
#18 0x080595e7 in Py_Main ()
#19 0x08058962 in main ()
(gdb)
Kieran
On Wed, Feb 25, 2009 at 12:01 PM, Johnathan C. <
On Wed, 2009-02-25 at 12:27 +1300, Kieran B. wrote:
There are 3 threads running, I posted thread 1 before,
Here is thread 2:
When unlock() is called, it stops the flowgraph, waits for it to finish,
then restarts it in its (possibly) new configuration.
Thread 1 is your main thread waiting for the flowgraph to stop so it can
calculate the new flowgraph and restart it.
Thread 2 is the usrp2 source block work function, blocked waiting for
packets to show up in its ring buffer.
Thread 3 is the one reading packets from the kernel and putting them in
thread 2’s ring buffer. It is blocked waiting for packets to come in
over the GbE.
When the call to unlock() results in the flowgraph being stopped,
threads 2 and 3 should be gracefully exiting, but they are not. It’s
also suspicious that it works the first time but not the second time.
This is clearly a USRP2 host driver bug, but not clear where. I don’t
have a workaround for you in the meantime other than to not use
lock()/unlock() on flowgraphs that have USRP2 sources. (It does work
fine with USRP2 sinks.)
Thanks again for the minimal test case and gdb stack dumps–it makes it
much simpler to track down the problem.
Johnathan
There are 3 threads running, I posted thread 1 before,
Here is thread 2:
(gdb) bt
#0 0xb80ef424 in _kernel_vsyscall ()
#1 0xb80bc075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7bcd2ab in omni_condition::wait (this=0x90059f8) at posix.cc:152
#3 0xb700ed48 in usrp2:
:wait_for_not_empty (this=0x90059c8)
at ring.cc:45
#4 0xb7016649 in usrp2::usrp2::impl::rx_samples (this=0x9005270,
channel=0,
handler=0x8f5e098) at usrp2_impl.cc:704
#5 0xb700fa5d in usrp2::usrp2::rx_samples (this=0x8f1af10, channel=0,
handler=0x8f5e098) at usrp2.cc:246
#6 0xb702575f in usrp2_source_32fc::work (this=0x8fcce70,
noutput_items=4081,
input_items=@0xb45a92f8, output_items=@0xb45a9318)
at usrp2_source_32fc.cc:62
#7 0xb7d4d61a in gr_sync_block::general_work (this=0x8fcce70,
noutput_items=4081, ninput_items=@0xb45a92ec,
input_items=@0xb45a92f8,
output_items=@0xb45a9318) at gr_sync_block.cc:64
#8 0xb7d390f6 in gr_block_executor::run_one_iteration (this=0xb45a92d4)
at gr_block_executor.cc:298
#9 0xb7d50502 in gr_tpb_thread_body (this=0xb45a92d4, block=
{px = 0xb45a9324, pn = {pi = 0xb45a9340}}) at
gr_tpb_thread_body.cc:37
#10 0xb7d4a7ba in
boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>,
void>::invoke (function_obj_ptr=@0x8f25a70)
at gr_scheduler_tpb.cc:42
—Type to continue, or q to quit—
#11 0xb7bc4ffc in boost::function0<void,
std::allocatorboost::function_base >::operator() (this=0x8f25a6c)
at /usr/include/boost/function/function_template.hpp:825
#12 0xb7bc5152 in boost::thread_data<boost::function0<void,
std::allocatorboost::function_base > >::run (this=0x8f259b0)
at /usr/include/boost/thread/pthread/thread.hpp:130
#13 0xb7bb7938 in thread_proxy () from
/usr/lib/libboost_thread-mt.so.1.35.0
#14 0xb80b850f in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#15 0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
and Thread 3:
(gdb) bt
#0 0xb80ef424 in __kernel_vsyscall ()
#1 0xb7ffbf77 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb700a4a5 in usrp2::eth_buffer::rx_frames (this=0x8fcaa38,
f=0x9005270,
timeout_in_ms=100) at eth_buffer.cc:193
#3 0xb7011bb7 in usrp2::usrp2::impl::bg_loop (this=0x9005270)
at usrp2_impl.cc:337
#4 0xb701716a in usrp2::usrp2_thread::run_undetached (this=0x8fcd058,
arg=0x0)
at usrp2_thread.cc:58
#5 0xb7bccdc1 in omni_thread_wrapper (ptr=0x8fcd058) at posix.cc:450
#6 0xb80b850f in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#7 0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
On Wed, Feb 25, 2009 at 12:23 PM, Johnathan C. <
Just one extra note here since I didn’t mention it, this is the output
from
the script on my machine:
sdrts@sdrts:~/test$ sudo python usrp2_rx.py
0 Lock
0 Unlock
usrp2: channel 0 already streaming
1 Lock
1 Unlock
Sorry I didn’t mention this before.
Kieran
On Wed, Feb 25, 2009 at 1:08 PM, Johnathan C. <