discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] pipes for today


From: Krzysztof Kamieniecki
Subject: Re: [Discuss-gnuradio] pipes for today
Date: Wed, 20 Apr 2005 12:54:27 -0400
User-agent: Internet Messaging Program (IMP) 3.2.2

Eric,

Have you made any progress with this? 

I'm having a problem that may be related. The blocks are layed out like this.

USRP Rx -> ... -> pipe

gr_sig_source -> ... -> USRP Tx

When running in gdb:
1. I wait for it to lockup
2. hit Ctrl-Z (to get into gdb)
3. type continue
4. more data is processed with a bunch of uU printed
5. software lockups again
6. goto 2

When I hit Ctrl-Z the Tx thread always seems to be in ioctl in _reap. Is this
normal?

Attached is a file with bt's for each of the threads
Thread 1 is Python/Wx, which seems to lockup
Thread 2 seems to be the USRP Tx graph
Thread 3 seems to be the USRP Rx graph
Thread 4 is my pipe monitoring thread, which does not lockup

Quoting Eric Blossom:
> On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote:
> > This is a curious behavior: if
> > 
> > 1) Use a vector source at the head and the USRP at the tail all is OK
> > 
> > 2) Use the pipe fd source at the head and a file sink at the tail all is
> > OK
> > 
> > but if
> > 
> > 3) Use a pipe fd source at the head and the USRP (with a parallel file
> > sink to monitor) at the tail data very slowly trickles into the file,
> > much slower than the 1.6Msps that it should - UNTIL I close the process
> > feeding the pipe, THEN it goes full blast and processes the backed up
> > pipe A-OK.
> > 
> > very interesting ;)
> 
> Chuck, if you send me the code to test example (3), I'll take a look at it.
> 
> Eric

Attachment: kkdeadlockinfo.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]