On Wed, Feb 25, 2009 at 1:08 PM, Johnathan Corgan
<address@hidden> 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