OpenCPN Freezing

[BlackSea]

Hi @transmitterdan,


I'm afraid I can't confirm what you suggested.
Hardware: RPI 3B
OS: Raspbian Buster
Kernel: 4.19.75
Tested with "Real" KMS and "Fake"

Have patched chart1.h

#ifdef ocpnARM

#define TIMER_GFRAME_1 1999
#else
#define TIMER_GFRAME_1 999
#endif

Recompiled. I have published package in my Repo

https://www.free-x.de/debian/pool/main/o/opencpn/opencpn_5.0.0-20190922_armhf.deb


Used charts: homebrew KAPs
OpenGL is "ON" in Setting. But I have disabled "Texture Caching"
OpenCPN freezes after a few seconds when zooming in/out and jumping between charts

[transmitterdan]

I experienced a return of the freezing too. So last night I rebuilt and installed the Linux kernel. Same kernel as already installed but just new copies of all the files. Now things are stable.

Frankly, I think that RPi using Micro-SD card is not a totally reliable platform. OpenCPN is often writing to the log, track and configuration files. I think the SD card suffers some degradation due to all the writing.

I plan to find a suitable SSD USB drive and see if that helps.

[BlackSea]

I think that RPi using Micro-SD card is not a totally reliable platform. OpenCPN is often writing to the log, track and configuration files. I think the SD card suffers some degradation due to all the writing.

I plan to find a suitable SSD USB drive and see if that helps.

It might be a plausible explanation, but it's not. First I have a proof-of-concept: I have mounted a tmpfs with 100MB at $HOME/.opencpn. With the same result: FREEZE
Then I called "opencpn" from command line

opencpn > otrace.log 2>&1

and after the freeze I have in otrace.log the following at the end

Draw call returned Cannot allocate memory.  Expect corruption.

i have grabbed whole Opencpn source through, but can't find a suitable place. Is definitely a library call

[transmitterdan]

I have been running now for 18 hours with no crash or freeze. I have the San Francisco Bay AIS feed showing as well as a VDR from a sailboat race so this is close to real sailing. If you can get a backtrack post what you find. Right now my RPi is working stable.

[transmitterdan]

Originally Posted by BlackSea

It might be a plausible explanation, but it's not. First I have a proof-of-concept: I have mounted a tmpfs with 100MB at $HOME/.opencpn. With the same result: FREEZE
Then I called "opencpn" from command line

opencpn > otrace.log 2>&1

and after the freeze I have in otrace.log the following at the end

Draw call returned Cannot allocate memory.  Expect corruption.

i have grabbed whole Opencpn source through, but can't find a suitable place. Is definitely a library call

Post your /boot/config.txt file.

[NahanniV]

Originally Posted by BlackSea

It might be a plausible explanation, but it's not. First I have a proof-of-concept: I have mounted a tmpfs with 100MB at $HOME/.opencpn. With the same result: FREEZE
Then I called "opencpn" from command line

opencpn > otrace.log 2>&1

and after the freeze I have in otrace.log the following at the end

Draw call returned Cannot allocate memory.  Expect corruption.

i have grabbed whole Opencpn source through, but can't find a suitable place. Is definitely a library call

If you are using .KAP (RNC) charts there may be a fix for your problem, see my previous posts; Updating firmware and setting a limit on the amount of memory that OpenCPN uses fixed similar problems for me.

The OP is only having problems with MBtiles.

[BlackSea]

I have good news and bad news.
The good news: I managed to make the RNC's run more stable. Several hours without crashes
Medicine: adding parameter "cma=384M" in cmdline.txt
Without parameterization vc4-kms-v3d and vc4-fkms-v3d allocate 256MB CMA. And that seems to be too little for OpenCPN. gpu_mem doesn't play a big role. Can also stay default value 64MB.
The bad: MBTiles crash after a few minutes of intense paning. I ran the following command in the background

watch -n 1 "cat /proc/meminfo | grep CmaFree"

Result:
CmaFree: 215240 kB
CmaFree: 210060 kB
CmaFree: 194964 kB
CmaFree: 189076 kB
CmaFree: 189088 kB
CmaFree: 186792 kB
...
CmaFree: 28508 kB
Here was then crash/freezing.
Cause: Leak in release of textures?
I will still try to test the ENC. Stay tuned

[NahanniV]

What are we doing differently ?

Some comments below:

Originally Posted by BlackSea

.....
Medicine: adding parameter "cma=384M" in cmdline.txt
Without parameterization vc4-kms-v3d and vc4-fkms-v3d allocate 256MB CMA. And that seems to be too little for OpenCPN.

Did you try the MEMCACHELIMIT=200 in opencpn config file ?
That limits the amount of memory OpenCPN will use.
It solves the problem with ENC and RNC charts without permanently allocating extra memory to CMA.

Add Memory limit to OpenCPN config:
shutdown OpenCPN
edit /home/pi/.opencpn/opencpn.conf
add line "MEMCacheLimit=200" just after the config version (3rd line).
re-start OpenCPN.

Originally Posted by BlackSea

gpu_mem doesn't play a big role. Can also stay default value 64MB.

The gpu memory parameter set in RPiconfig is not used when the new graphics driver is used, set it to 16MB

Originally Posted by BlackSea

The bad: MBTiles crash after a few minutes of intense paning. I ran the following command in the background

There is obviously a problem with MBtiles that can not be fixed by either increasing CMA memory or limiting OpenCPN.

[transmitterdan]

In the latest kernel using the real KMS gl driver gpu_mem should not be used. The raspi-config always comments that line out.

I think there are possibly multiple issues and may not be anything OpenCPN can do. The RPi team are trying to improve gl support. But frankly, I think the RPi 4 is the ultimate path forward. The Pi 3 just doesn’t have the horsepower in my opinion. The X11 system is too fragile making debugging problems like this next to impossible.

[BlackSea]

@NahanniV

Did you try the MEMCACHELIMIT=200 in opencpn config file ?
That limits the amount of memory OpenCPN will use.
It solves the problem with ENC and RNC charts without permanently allocating extra memory to CMA.

Yes. I have activated this option also, but with default value for CMA (256MB) this was not enough. Only with an increase CMA from 256 to 384 I had noticeable success.


@transmitterdan

But frankly, I think the RPi 4 is the ultimate path forward. The Pi 3 just doesn’t have the horsepower in my opinion.

I don't have rpi4 at hand now but I would say that only with tweaking from CMA OpenCPN on rpi4 will work well

[BlackSea]

but I would say that only with tweaking from CMA OpenCPN on rpi4 will work well

I withdraw my statement.
I borrowed an RPi4 from my students and tested it. What should I say? WOW!
OpenCPN runs fluently on RPi4. You don't need any extra settings for CMA or MemCacheLimit. All ENC(OESENC), RNC(BSB3/KAP) and MBTiles without problems with default parameters for OS. For RPi 4 only FKMS GL driver is available. The only thing to keep in mind is: good power supply and cooling.

[NahanniV]

I tried my previous test with a NOAA Mbtiles file on Rpi3B+.

After adding parameter "cma=384M" in /boot/cmdline.txt
and rebooting.

I could not make it crash with the same amount of testing that I did before.

[transmitterdan]

I confirm that CMA=384M in /boot/cmdline.txt prevents freezes for me too. I can zoom and pan all over an mbtiles chart and nothing bad happens.

It’s very strange because the video driver author says this parameter isn’t used. But it sure seems to make a difference.

[NahanniV]

Originally Posted by transmitterdan

........
It’s very strange because the video driver author says this parameter isn’t used. But it sure seems to make a difference.

CMA memory is what the new driver uses.
GPU memory as configured in rpiconfig is not used.

[transmitterdan]

Just a brief update:

My Raspberry PI 3 (not +) has been running OpenCPN for 2 weeks continuously. No freezes or other problems. I have been feeding it a steady stream of NMEA data over WifI and also connected it to the SF Bay area AIS feed over the internet the whole time. It routinely tracks 200+ AIS targets as well as numerous on-board instruments (wind, depth, speed, position, etc.).

The CMA=384M option in /boot/cmdline.txt is what does the trick. No more freezes.