Just one extra note here since I didn't mention it, this is the output from the script on my machine:
sd...@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 Corgan < jcor...@corganenterprises.com> wrote: > 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
