RX OVERRUN_ERROR
Thomas D. Dean
# ./xlinrad
C
-- or --
#nice -20 ./xlinrad
C
Linrad 03.06 freezes. Does not respond to any keyboard action.
If I close the gnome window by clicking "X", linrad does not return to
the console.
/var/log/messages has 71,603 messages like
Also, May 27 13:56:09 asus kernel: [100386.736199] ft245:
ft245_read_bulk_callback dropped 62 h/t/c 0/65534/65534
# ./xlinrad
C
X
Causes linrad to freeze every time.
What can I do to help fix this?
tomdean
Thomas D. Dean
#gdb ./xlinrad
r
Starting program: /home/tomdean/Radio/Linrad/linrad-03.06/xlinrad
[Thread debugging using libthread_db enabled]
[New Thread 0xb7cc08d0 (LWP 25794)]
[New Thread 0xb79d6b90 (LWP 25797)]
[New Thread 0xb71d5b90 (LWP 25798)]
[New Thread 0xb69d4b90 (LWP 25799)]
[New Thread 0xb61d3b90 (LWP 25800)]
C <-- in the linrad screen
[New Thread 0xb3c94b90 (LWP 25802)]
[New Thread 0xb3493b90 (LWP 25803)]
[New Thread 0xb2c92b90 (LWP 25804)]
[New Thread 0xb2491b90 (LWP 25805)]
[New Thread 0xb1c90b90 (LWP 25806)]
[New Thread 0xb148fb90 (LWP 25807)]
X <-- in the linrad screen
[Thread 0xb3493b90 (LWP 25803) exited]
flashes a [1284] message for several seconds and then returns to gdb.
[1284]The RX input device failed. Linrad does not know how
to stop a thread waiting for response from e.g. an unplugged
USB device so an exit from Linrad is forced.
In case you can repeatedly provoke this error by a reasonable
procedure please post a message on the Linrad mailing list.
And, after a few seconds,
[Thread 0xb148fb90 (LWP 25807) exited]
[Thread 0xb2491b90 (LWP 25805) exited]
[Thread 0xb79d6b90 (LWP 25797) exited]
[Thread 0xb1c90b90 (LWP 25806) exited]
[Thread 0xb3c94b90 (LWP 25802) exited]
[Thread 0xb2c92b90 (LWP 25804) exited]
[Thread 0xb61d3b90 (LWP 25800) exited]
[Thread 0xb69d4b90 (LWP 25799) exited]
[Thread 0xb71d5b90 (LWP 25798) exited]
Program exited with code 04.
(gdb)
Leif Asbrink
> I get an RX overrun error repeatedly, after about one minute.
>
> # ./xlinrad
> C
>
> -- or --
>
> #nice -20 ./xlinrad
> C
>
> Linrad 03.06 freezes. Does not respond to any keyboard action.
I would think that the CPU was busy so it could not take care of
the USB activities in time. The error could be within Linrad if
you have selected parameters that overload the processor. That
would not be possible if you use the parameters I suggested in
a previous mail and also not select a signal by clicking on it.
If problems occur only after you click a signal you should change the
mode for the baseband filter and resampler. There is a box in
the upper right corner of the baseband window where you can
toggle between '1' and '2'. Mode 2 can only be used for filters
with modest size because it causes a cpu load that increases
with the filter size. Mode 1 is always very fast, but it produces
artifacts in the transition region of the filter. For "normal"
filters both implementations work equally well.
> If I close the gnome window by clicking "X", linrad does not return to
> the console.
You have to press ctrl C to stop the thread that is waiting for USB.
> /var/log/messages has 71,603 messages like
>
> Also, May 27 13:56:09 asus kernel: [100386.736199] ft245:
> ft245_read_bulk_callback dropped 62 h/t/c 0/65534/65534
You may read in ft245.c what the exact reason is for this error.
As far as I know it only occurs when the CPU is overloaded.
> # ./xlinrad
> C
> X
>
> Causes linrad to freeze every time.
>
> What can I do to help fix this?
I suggest you remove all the par files and restart Linrad in
'newcomer mode'. If the problem remains, something may have
gone wrong with the ft245 module. After all you have done
various things to install it in a way that I have no experience
with.
73
Leif / SM5BSZ
Leif Asbrink
> #gdb ./xlinrad
This will most probably overload the CPU and cause an USB crasch.
I do not think the any useful information can be obtained this way.
73
Leif
Thomas D. Dean
>
> As far as I know it only occurs when the CPU is overloaded.
I am running xlinrad on a quad core 3GHz machine with 4G RAM and one
other process, trackerd.
I can not see a high CPU usage with top when xlinrad is running
normally. When I get an error, either overrun or A/D Speed and the
waterfall stops, xlinrad is using 100% of one cpu and bouncing between
0.5% and 1.1% memory.
If I start xlinrad and do not touch the mouse or keyboard, it seems to
not get to the 100% state, normally around 5% to 10%. After letting it
run for a few minutes, getting 85 overrun errors and seeing the A/D
error several times, when I press <esc>, the display stops and xlinrad
freezes using 100% of one cpu. I use ^C in the terminal to kill it.
I installed the ft245.ko built from your sources, in the normal
location. I see no change.
tomdean
Leif Asbrink
I have no idea what might happen on your system.
It looks like an error in Linrad but I have not seen anything similar here.
Maybe it is something that does not happen here because I do not have
a computer that is anywhere near as fast as your machine.
Nobody has reported something similar before. Maybe it is some error
I made recently and that is not detected by others who did not upgrade
to the latest version (to avoid possible new errors.)
Try to download an old version from here:
http://www.sm5bsz.com/linuxdsp/linroot.htm
The oldest that should work with the SDR-IQ is Linrad-02.34
Maybe other Linrad/SDR-IQ users can help. Is there something wrong in
the latest Linrad versions?
73
Leif / SM5BSZ
Thomas D. Dean
area, I get a floating point excepthion.
I went back to 03.06. It started Ok. I set the par files and
restarted.
# ./xlinrad
C
The display came up Ok, I think.
I clicked in the waterfall area. Then
X
Xlinrad went into a loop using 100% of one CPU. I caused a core dump
with gcore. Using gdb,
# gdb -c core.21626 xlinrad
...
Core was generated by `/home/tomdean/Radio/Linrad/linrad-03.06/xlinrad'.
[New process 21627]
[New process 21628]
[New process 21629]
[New process 21630]
[New process 21641]
[New process 21642]
[New process 21626]
#0 0xb8094430 in __kernel_vsyscall ()
(gdb) bt
#0 0xb8094430 in __kernel_vsyscall ()
#1 0xb7f833f5 in ?? ()
#2 0xb7ec849e in ?? ()
(gdb)
Looks like the stack is hosed???
tomdean
Thomas D. Dean
M_CIC2 [16]
M_CIC5 [32]
M_RCF [32]
OL_RCF [2]
Sampl. clk adjust [0]
Att [0]
Inp.sel [25]
Check [2150200]
1st FFT BW 12
sine 2
rest defaults
If I click in the waterfall area then press X, after several seconds, I
get the change parameter screen. Pressing X again returns me to the
main menu and things seem sort of normal.
The response to the keyboard or mouse is VERY slow! The CPU usage is
low.
tomdean
jeff millar
to MAP65. But I only have one downconverter and one polarization. So
far, I've configured it to put the same audio into both IQ inputs, and
linrad displays 45 degrees.
But I want to go the June VHF contest with a smaller PC an a USB sound
card. Can I use a single USB sound card and still configure linrad for
2 x 2 IQ channels? What happens with the undefined inputs? It seems to
_start_ to work on my desktop PC because Map65 reports the right Rx
audio level and 0% error. But after a minute, it reports "No Rx Data".
I'm currently testing with Linrad 2.56 and Map65 r1257 both running on
my Linux box.
any ideas?
jeff, wa1hco
Leif Asbrink
> I slowed things way down. It sort of works.
>
> M_CIC2 [16]
> M_CIC5 [32]
> M_RCF [32]
> OL_RCF [2]
> If I click in the waterfall area then press X, after several seconds, I
> get the change parameter screen. Pressing X again returns me to the
> main menu and things seem sort of normal.
>
> The response to the keyboard or mouse is VERY slow! The CPU usage is
> low.
I do not know why your ultra-fast computer misbehaves. One thing is that
the parameters above causes a very slow response to the mouse.
The reason is that Linrad reads blocks of 8192 bytes and that therefore
the the sampling speed of 4 kHz that the above parameters give leads
to an interrupt rate of 2 Hz only. The delay on mouse or keyboard
is therefore 0.5 seconds.
Mouse or keybouard commands are only serviced from the thread that
they belong to when the thread in question is not overloaded and
has waken up from waiting on a semaphore. The reason is that the
commands may change memory allocations and therefore must not be
serviced unless the thread is in its idle state. Under reasonable
operating conditions the delay is 20 ms or less.
Surely it would be possible to do something about this, but running
the SDR-IQ at extremely low sampling rates is not something that seems
reasonable in Linrad.
You may modify the routine lir_sdr14_read like this:
int lir_sdr14_read(void *s,int bytes)
{
int i;
qq("READ");
i=read(sdr, s, bytes);
qq(" OK");
return i;
}
The routine is near line 936 in lsetad.c
The qq function will write READ on the screen when calling the kernel
module and OK when returning from the kernel. This modification causes
frequent calls to the X11 server from the input thread that has the
responsibility to read from the USB before an overrun occurs. Nevertheless
Linrad runs without any error at all on my 2.67 GHz Pentium 4 as long as I do
not run other programs. When I grab the title bar of another window on
the desktop and move that other window around, I will see OK from the
qq routine for a long time. Moving windows has higher priority than
Linrad so Linrad does not get the time to process its data and
the read from the USB becomes delayed. When I stop moving the other
window around, OK becomes replaced by READ and Linrad would write
"No input" in the lower left corner of the screen. At this point the
USB subsystem has crashed. Linrad calls the ft245 kernel module, but
there is no return. Linrad will continue at negligible processor load
until ESC is pressed which would cause 100% cpu load. That is a misbehaviour
of Linrad, should be fixed some day, but not of high priority.
It happens only when the input thread hangs on a read.
It is possible, but not quite as easy to make the USB subsystem crasch
by moving around the Linrad window on the desktop.
Running Linrad on a dual core machine does not help at all. The USB
sub-system crasches when I move another window around just like on the
single core machine.
When Linrad is disturbed by my moving another window there are
overrun errors as well as several other types of errors. The X11
system is not designed for a real-time application like Linrad.
It gives priority to user commands (like moving a window) with
no respect for other applications. Setting the maximum possible
priority to the thread that does the reading from SDR-IQ does not
help. X11 window moves have higher priority:-(
int policy;
struct sched_param parms;
policy=SCHED_RR;
parms.sched_priority=sched_get_priority_max(policy);
pthread_setschedparam(thread_identifier[THREAD_RX_OUTPUT],policy,&parms);
i=pthread_getschedparam(thread_identifier[THREAD_RX_OUTPUT],&policy,&parms);
The retunded priority becomes 99. Max allowed.
Soundcard inputs recover automatically after not have been serviced
for a long time. With SDR-IQ a blocking of the USB-system causes
the software inside the SDR-IQ to crasch. After that an attempt to read
the SDR-IQ will not cause any data to be transferred over the
USB and consequently Linrad will hang on the blocking read on the USB.
Dear Thomas, it seems to me that your systems runs something that
other Linrad users do not run. Something that does not respect that
the USB subsystem has to be serviced in time ALWAYS. If an error
occurs the FT245 driver does not have the error handling required
so it hangs on a read statement. It would be possible to use a non-blocking
read and to put new routines into Linrad to try to reset a crashed
SDR-IQ. It would work sometimes, but not always. In some cases it
is necessary to hard reset the SDR-IQ by switching off the DC power.
The tests I have made were with normal sampling rates, decimation
700 for sampling at 96 kHz. Nobody else has reported the problems you
have. I would be interested in reports of similar problems and if
they have or have not been resolved.
73
Leif / SM5BSZ
Thomas D. Dean
Hi Leif,
I have another X problem on this machine with Ubuntu 9.04. The display
blurs and tears when moving a window such that it would extend beyond
the edge of the display.
I am writing a console application to handle the USB in the background,
executing a command file. May use shared memory.
If I get good results with that, maybe I can fork a process off linrad
to handle USB.
I am testing timing, etc.
I will keep posting here.
Tom
Leif Asbrink
Today I installed Ubuntu 9.04 and indeed I found the overrun
errors and other problems that you reported.
Go to System -> Preferences -> Appearance -> Visual Effects
and select "None."
It seems like the visual effects turn off interrupts for
long periods of time and thereby causes errors in the USB
sub-system. The log file /var/log/syslog reports numerous
errors even though Linrad seems to work for a couple of minutes
before overrun errors and other errors occur.
Moving the mouse outside the Linrad window, just hitting the border
lines, causes a crasch.
Ubuntu has "Visual Effects" = "Normal" by default. It is stated
to provide a good balance between attractiveness and moderate
performance requirements but that is not true at all. "Visual
Effects" completely destroy the realtime properties of the Linux
operating system. By orders of magnitude!!!
When I select "None" I can run xlinrad for long times without
a single line written to syslog even though chron executes
every 10 minutes.
It does not matter how many CPU cores you have and it does
not matter what priority one gives to the input thread of Linrad.
If some software switches off the interrupt, USB will stay
dead until interrupts are enabled. That is how I interpret
the problems.
I can not understand why "Visual Effects" have to behave like
that. I would guess it is a bug of some kind...
73
Leif / SM5BSZ
Thomas D. Dean
> Go to System -> Preferences -> Appearance -> Visual Effects
> and select "None."
My system was set to "None" a long time ago. I have been looking into X
smearing and tearing for a while.
I noticed another strange thing,
If I set
CIC2 8
CIC5 6
RCF 4
I get a message "Error the sampling speed is far too high for USB 1.0"
My USB port is 2.0
# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 008: ID 0403:6001 Future Technology Devices
International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A
Serial Port [pl2303]
Bus 001 Device 003: ID 0557:2008 ATEN International Co., Ltd UC-232A
Serial Port [pl2303]
Bus 001 Device 002: ID 050d:0237 Belkin Components F5U237 USB 2.0 7-Port
Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
The Bus is 001, via Belkin, Device 002 to Bus 001, Device 008: 0403:6001
# sudo lsusb -v -d 0403:6001
Bus 001 Device 008: ID 0403:6001 Future Technology Devices
International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 SDR-IQ
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 400mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 SDR-IQ
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Tom
Leif Asbrink
> I noticed another strange thing,
>
> If I set
> CIC2 8
> CIC5 6
> RCF 4
>
> I get a message "Error the sampling speed is far too high for USB 1.0"
>
> My USB port is 2.0
The SDR-IQ is USB 1.0 and limits the speed to something like 180 kHz.
With some Linux systems it can run as fast as 230 kHz, but only
in terminal mode, not under X11.
Leif / SM5BSZ
Thomas D. Dean
I believe the speed limitation.
However, the SDR-IQ Interface Specification Ver. 1.00 of Dec 16,2006 on
page 9, says it is "USB 2.0 Full Speed". The RFspace web paqge also
describes it as a USB 2.0 device.
For the SDR-IQ,
# lsusb -v -d 0403:6001,
...
bcdUSB 2.00
...
For a pl2303 serial device
# lsusb -v -d 0557:2008
...
bcdUSB 1.10
...
Is there something in the PIC that limits this?
Tom
Leif Asbrink
> However, the SDR-IQ Interface Specification Ver. 1.00 of Dec 16,2006 on
> page 9, says it is "USB 2.0 Full Speed". The RFspace web paqge also
> describes it as a USB 2.0 device.
>
> For the SDR-IQ,
> # lsusb -v -d 0403:6001,
> ...
> bcdUSB 2.00
> ...
>
> For a pl2303 serial device
> # lsusb -v -d 0557:2008
> ...
> bcdUSB 1.10
> ...
>
> Is there something in the PIC that limits this?
I do not have an SDR-IQ, I only have an SDR-14. The SDR-14 is
max 180 kHz or so according to RFspace specifications.
Based on experience a long time ago I have set a limit at 260 kHz.
The highest speed I could use on my Pentium 4 was about 130 kHz.
I made a test today - and now I can run the SDR-14 at 222 kHz
without any problems so I have changed the limit to 500 kHz.
In Linrad-03.07 it is a define in sdr14.c:
#define MAX_SDR14_SPEED 500000
I do not know exactly what changes that have made it possible to
run the USB faster, it could be a more modern kernel or something
I did in Linrad. Anyway, the speed is now much higher than expected:-)
Please change 260000 and 300000 in sdr14.c at lines 507 and 880 to
something higher and check where the limit is for SDR-IQ on your
computer. In case it is much above 250 kHz I will make the
tests different for SDR-14 and SDR-IQ.
(Old Linrad versions did not check the nominal speed and much
too high values caused hard to understand crashes for newcomers.)
73
Leif / SM5BSZ
Thomas D. Dean
> Please change 260000 and 300000 in sdr14.c at lines 507 and 880 to
> something higher and check where the limit is for SDR-IQ on your
> computer. In case it is much above 250 kHz I will make the
> tests different for SDR-14 and SDR-IQ.
In my sdr14.c, the line numbers are different, but, I found them.
I ran several tests, varying the decimation, keeping the FFT BW at 30Hz.
I found a combination that fails. See the bottom
CIC2, CIC5, RCF, RCF shift, sample clock shift, db
2,2,20,0,0,25 fft1 size 16K
Spectrum Ok
RX A/D Speed Error 252056 Hz (Nominal 833333 Hz)
2,2,15,0,0,25 fft1 size 16K (Nominal 1111111 Hz)
Spectrum Ok
RX A/D Speed Error 253224 Hz (Nominal 1666666 Hz)
2,2,10,0,0,25 fft1 size 32K
Spectrum Wrong - NLK at 24.8 KHz is not visible, just noise
RX A/D Speed Error 253224 Hz (Nominal 3333333 Hz)
2,2,5, 0,0,25 fft1 size 64K
Spectrum Wrong- NLK at 24.8 KHz is not visible, just noise
2,2,2, 0,0,25
Spectrum Wrong- NLK at 24.8 KHz is not visible, just noise
In all cases, I could press X and get to the mode help page and X again
to get to the main menu.
The timer error message seems to be limited around 250KHz. I started
looking at this, but,
This seems repeatable.
2,2,30,0,0,25
FFT BW 30
MEMORY ERROR mm=2[56] data is0 (56) Call no 198
MEMORY ERROR mm=2[57] data is0 (57) Call no 198
MEMORY ERROR mm=2[58] data is0 (58) Call no 198
MEMORY ERROR mm=2[59] data is0 (59) Call no 198
MEMORY ERROR mm=2[60] data is0 (60) Call no 198
MEMORY ERROR mm=2[61] data is0 (61) Call no 198
MEMORY ERROR mm=2[62] data is0 (62) Call no 198
MEMORY ERROR mm=2[63] data is0 (63) Call no 198
Error in fft1,fft2
# ../save-par.sh
Saving par* to /home/tomdean/Radio/Linrad/ParFiles/par200906022130.tgz
Tom
Leif Asbrink
"Thomas D. Dean" <tom...@speakeasy.org> wrote:
> I ran several tests, varying the decimation, keeping the FFT BW at 30Hz.
> I found a combination that fails. See the bottom
>
> CIC2, CIC5, RCF, RCF shift, sample clock shift, db
> 2,2,20,0,0,25 fft1 size 16K
> Spectrum Ok
> RX A/D Speed Error 252056 Hz (Nominal 833333 Hz)
This already failed. The data delivered by the SDR-IQ is only 252 kHz
so you are loosing 70% of the data. There should not be any errors
in /var/log/syslog because the errors are internal in the SDR-IQ which
is not capable of sending data faster than 252 kHz.
Presumably you get blocks of correct data but long sequences would
be missing. The spectrum might look nearly OK but if you look
at a single very strong signal you should see a broadening due
to the phase jumps that would happen for each block of missing data.
> 2,2,15,0,0,25 fft1 size 16K (Nominal 1111111 Hz)
> Spectrum Ok
> RX A/D Speed Error 253224 Hz (Nominal 1666666 Hz)
>
> 2,2,10,0,0,25 fft1 size 32K
> Spectrum Wrong - NLK at 24.8 KHz is not visible, just noise
> RX A/D Speed Error 253224 Hz (Nominal 3333333 Hz)
>
> 2,2,5, 0,0,25 fft1 size 64K
> Spectrum Wrong- NLK at 24.8 KHz is not visible, just noise
>
> 2,2,2, 0,0,25
> Spectrum Wrong- NLK at 24.8 KHz is not visible, just noise
>
> In all cases, I could press X and get to the mode help page and X again
> to get to the main menu.
>
> The timer error message seems to be limited around 250KHz. I started
> looking at this, but,
>
> This seems repeatable.
> 2,2,30,0,0,25
> FFT BW 30
> MEMORY ERROR mm=2[56] data is0 (56) Call no 198
Yes. This is the reason why there is a test to not allow far too
high sampling rates.
I no longer remember the exact cause, but as I can recall it has
something to do with overflow in the computation of a buffer size.
The limit you see at 252 kHz is close to what I see on my SDR-14
so I will set the limit to 300 kHz for future Linrad versions.
73
Leif / SM5BSZ