Fusb::_reap: Interrupted System Call

GNU Radio
1

Does anyone know why I get “fusb::_reap: Interrupted System Call” fairly
frequently? There are no overruns, and my data seems good, but I keep
getting this error. If it’s meaningless, is there a way to suppress it?

Jared

2

On Thu, Oct 11, 2007 at 03:54:56PM -0400, Jared J. wrote:

Does anyone know why I get “fusb::_reap: Interrupted System Call” fairly frequently? There are no overruns, and my data seems good, but I keep getting this error. If it’s meaningless, is there a way to suppress it?

Jared

I’ve never seen it.

Can you tell me how you reproduce it?
What OS, distribution, etc?

Eric

3

Eric,

 Ubuntu, Feisty.  2.6.20-16-generic.  HP dv2000

laptop, Core 2 Duo, 1.6 GHz. 2 GB RAM, 160GB HDD 5400 RPM (But I’m not
doing much disk I/O at all).

 I get the error message

every 10-15 seconds or so. Sometimes I won’t see it for minutes at a
time, and other times, I’ll see it often; like multiple times in a few
seconds. Like I said, no data is missing (as far as I can tell), but
this pops up frequently; apparently from the libusb driver. I don’t
get overruns, just this. Also, as I said, I can’t see any missing
data, but I also can’t 100% guarantee that I’m not losing some data, so
it concerns me a little.

 To reproduce it, I just run my

code. :slight_smile: I’ve written some custom code to do MSK. It’s all in C++,
since management wasn’t down with Python, and I had to interface to our
existing C++ protocol libraries. (And other complications…) So I
ported the DBSRX tuning code over to C++, and implemented a read
thread. Then my consumer thread just takes the data and handles it.
The read thread is really brief. It’s just a while(1) loop

while(!bThreadStop){
// Toggling the ping pong buffers
(!bWhichBuf) ? arr = &array1[0] : arr = &array2[0];

    // The read
    nRead = myDev->read(arr,sizeof(array1),&bOverrun);

    // The resampler method just hands the data to my processing

thread.
// The processing thread then handles the polyphase rational
resampler.
if(bUseRationalResampler){
myDSP->rational(arr,nRead/sizeof(short));
}

else{  // Or just copy it out and do nothing with it.  (This still

produces the error message.) I did this to debug if maybe something
// was lacking CPU time, or resources. But it
seems like the error is independent of processing load.
myDSP->CopyData(arr,nRead/sizeof(short));
}

    // Keeping track of the amount of data
    nData += nRead/sizeof(short)/2 & ( INDEX_MAX - 1 );

    if(bOverrun){
        fprintf(stderr,"DISASTEROUS ERROR : Overrun!

(%ld)\n",nData);
if(bLogDebugging)
fprintf(logfileFID,“DISASTEROUS ERROR : Overrun!
(%ld)\n”,nData);
}

    // Switch buffers
    bWhichBuf = !bWhichBuf;

}

So
that’s the only code that reads the USRP. My read thread is MAX
PRIORITY, and it spends most of its time blocked. My other thread
takes about 15% of the CPU on my machine. I know that the read thread
resides on one core of my CPU, while the processing is on the other
core. (Processor affinity from Intel’s ICC compiler.) It always seems
like both threads have more than enough resources though. But again,
I’d be open to any suggestions/tips/tricks. It seems like nothing I do
changes it, so let me know if you have any insight and I’ll give it a
try.

Also, everything runs well and processes well. So I’m
talking to the USRP correctly and to the DBSRX correctly as well.
(Have been for a couple of months now.) Again, there may be some
subtlety I’m missing, but as for functionality, things appear to work.

Thanks for the help.

Jared

4

On Tue, Oct 16, 2007 at 12:47:59PM -0400, Jared J. wrote:

seconds. Like I said, no data is missing (as far as I can tell), but
this pops up frequently; apparently from the libusb driver. I don’t
get overruns, just this. Also, as I said, I can’t see any missing
data, but I also can’t 100% guarantee that I’m not losing some data, so
it concerns me a little.

Without chasing through more code than I just did, I can’t say with
certainty if you’re losing data or not, but I suspect that you’re not.

I would guess that you’re using some kind of time keeping alarm that’s
setting a periodic interrupt, and that’s what you’re seeing (E.g.,
sleep or alarm). Are you expecting to be getting a SIG* in this
thread? If not, you may want to take a look at pthread_sigmask.
Using threads and signals together is a bit of a black art.

Eric

5

That’s an idea. I do call usleep() occasionally in my other thread when
I know I won’t be processing for a while. (Like when I want to let my
buffer recover a little while after I run up to the end of it.) Maybe
the super high priority read thread is executing when a usleep() should
return and I get this error. I’ll look into it. Thanks for taking the
time to look at it. I’m not using any signaling between the two
threads. I just have that callback. So hopefully it’s just the usleep
issue. Thanks again.

Jared