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.
> 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.
> 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.
On Thu, 2009-05-28 at 10:19 +0200, Leif Asbrink wrote:
> 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.
> > 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.
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.)
I tried 03.04. Build was Ok. Starts Ok. When I click in the waterfall 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)
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'm currently running Linrad with a Delta-44 and using to feed packets 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.
> 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.
> 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.
On Sat, 2009-05-30 at 23:02 +0200, Leif Asbrink wrote:
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.
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...
On Sun, 2009-05-31 at 23:37 +0200, Leif Asbrink wrote: > 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)
> 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.
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 ...
> 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.)
On Wed, 2009-06-03 at 00:26 +0200, Leif Asbrink wrote: > 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
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
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,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.
|
