On Wed, 2009-02-25 at 12:27 +1300, Kieran Brownlees 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio