0

We have a kiosk Vue application running on Raspbian (Raspbian GNU/Linux 10 (buster)) / Chromium 92. For some unknown reason it seems to freeze after x hours (or days). It happens on a pi 3 and also pi 4. Some machines are running okay for weeks and some have daily problems, without any logic reason. Animation itself is still moving but touch doesn't respond anymore.

Today it happened again and I see this in the syslog right before we know it actually stopped responding, how should I know what it means? Or is this just some info logging which has nothing to do with the problem.

Feb 27 15:14:46 pi6542 rngd[347]: stats: bits sent to kernel pool: 33824
Feb 27 15:14:46 pi6542 rngd[347]: stats: entropy added to kernel pool: 33824
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2 successes: 4
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2 failures: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2(2001-10-10) Poker: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2(2001-10-10) Runs: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2(2001-10-10) Long run: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: HRNG source speed: (min=240.663; avg=519.908; max=1006.714)Kibits/s
Feb 27 15:14:46 pi6542 rngd[347]: stats: FIPS tests speed: (min=4.052; avg=6.377; max=12.385)Mibits/s
Feb 27 15:14:46 pi6542 rngd[347]: stats: Lowest ready-buffers level: 2
Feb 27 15:14:46 pi6542 rngd[347]: stats: Entropy starvations: 0
Feb 27 15:14:46 pi6542 rngd[347]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us```
Improve this question
7
  • Raspbian experiences occasional freezes of parts of the system when using GPU-heavy applications in continuous use. I've had this problem before and "solved" it with a watchdog which reboots if a file (which is written to by the application which causes the freezes) hasn't been updated in x minutes.
    – eDonkey
    Commented Feb 28, 2022 at 9:14
  • It's not that heavy.. but it sounds like the same problem. Rebooting on the fly isn't really an option for us. Did you also try to play around with Chromium flags (if you use it as well) or maybe disabling the Fake KMS driver?
    – Inovaro_NL
    Commented Feb 28, 2022 at 11:45
  • I didn't. I had a problem with the RasPi Camera Module. Are you using any kind of WebGL? That could make your RasPi basically unusable as it usually takes about 100% of your CPU. Sadly, there wouldn't even be a solution.
    – eDonkey
    Commented Feb 28, 2022 at 12:37
  • We do use the flag "--use-gl=egl" for Chromium but we don't have any WebGL running. The strange this is that the animations still work, so the GPU is redrawing the screen. I don't see any errors in the log files. Sometimes (but not always) restarting the eGalax touch driver solves the problem, but there is no way to see it actually fails. The status of it still returns "ACTIVE".
    – Inovaro_NL
    Commented Feb 28, 2022 at 20:14
  • Can you maybe check how much the CPU usage is, when it's all up and running? I actually can't think of a any solution with all the information you gave... Maybe you want to check out Odroid (alternative to RasPi with better specs). Please keep me updated if you find anything new.
    – eDonkey
    Commented Mar 3, 2022 at 8:03

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.