Emulation station freezing

triforcexp

@mahoneyt944 I'm checking directly over the EmulationStation version.
I went all the way back to 2.7.6 with the same result, so I'm not completely sure the problem is the ES version itself or some other component of the distro.

BTW, I thought that I could try playing around with the GL version and, albeit it didn't fix, I believe the RetroPie script is setting the GLES 1.0 define wrongly, and hence would always use GLES2 (?)

See https://github.com/RetroPie/EmulationStation/blob/064a1818ead9dce730ecf928f27860edddc8e745/es-core/src/renderers/Renderer_GLES10.cpp#L1

and

https://github.com/RetroPie/RetroPie-Setup/blob/0212b0249c96b5b355c1d180f24cff1ae9937518/scriptmodules/supplementary/emulationstation.sh#L168

triforcexp

@mahoneyt944 I just went all the way down to 450 mhz with the same result, maybe staying alive just a bit longer.

mitu

@triforcexp said in Emulation station freezing:

BTW, I thought that I could try playing around with the GL version and, albeit it didn't fix, I believe the RetroPie script is setting the GLES 1.0 define wrongly, and hence would always use GLES2 (?)

You're confusing the CMake's option (USE_GLES1) with the C++ macro with a similar name. EmulationStation didn't have a GLES2 renderer until version 2.9.1 and it's specifically disabled on VC4 because of the poor performance.

Can you post the config.txt you have ? What version of kernel/firmware do you have ?

triforcexp

@mitu Yeah you are right. I would have named both the same though 😅

So here is my config.txt

disable_overscan=1
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
hdmi_mode=4

arm_freq=1300
dtparam=audio=on
sdram_freq=500
over_voltage=6

gpu_mem=256 
gpu_freq=500 
v3d_freq=525 
usb_hid.mousepoll=0

I've tried removing v3d freq and moving gpu freq down to 450 without success.

dankcushions

@triforcexp said in Emulation station freezing:

sdram_freq=500

this caused my pi3 to be very unstable. i would remove all overclocks as a matter of course when you find instability. then if you must overclock, gradually introduce them one by one.

triforcexp

@dankcushions yeah but weirdly enough emulationstation is the only thing that freezes. Plus older versions worked just fine. If I leave the gpu freq with the default value works

thomas1234

@triforcexp still seeing freezing immediately after removing overclocking. I did the same thing in updating a really old version to buster and building ES from source.

mahoneyt944

@thomas1234 what I did was I built a fresh image then copied over a few settings at a time until I found what caused the freeze. Then I corrected that setting to fix my freezing issue.

thomas1234

@mahoneyt944 What setting was it that needed corrected? I have completely reverted config.txt

I guess I just need to start fresh.

mahoneyt944

@thomas1234 gpu_freq was effected after the update. Comment out any of these.

#gpu_freq= ?

roslof

Would like to confirm:

Since upgrading RetroPie to latest awhile back and also upgrading the RPi software with:

sudo apt update
sudo apt full-upgrade

The freeze occurs randomly, but only during the screensaver. I read above this was occurring with a slideshow. I use video, and each day return to a frozen video or a black screen.

Turning off GPU overclock dramatically affects some 3D system (N64, Dreamcast, Naomi, Atomiswave) so not a great option. Better to disable the screensaver, but that's such a great feature.

Has anybody been able to track down the source of the problem? ES update, or the Raspberry Pi upgrade?

roslof

@mahoneyt944 said in Emulation station freezing:

@thomas1234 gpu_freq was effected after the update. Comment out any of these.

#gpu_freq= ?

Clarifying: "after the update" of what? RPi software, or ES?

roslof

A couple of anecdotal data points:

The issue should not be with EmulationStation V2.9.6RP. I used to run it extensively without issue.
I've more recently been using EmulationStation-Dev V2.10.0RP-DEV without issue.

Then I updated Raspberry Pi software to latest and updated RetroPie Script. The later was common and I don't see any commits that should affect ES.

The freeze started here. #1 and #2 now freeze. Unless user-error on my side, the issue should reside with the Raspberry Pi software update (it did also update kernel). Possible a newer version of VLC. Not sure.

I'll see if I can find out more. It wouldn't be the first time a RPi upgrade adversely affected overclock settings.

Q: When updating Raspberry Pi software, is the output logged somewhere? I'd like to see what changed. It had been awhile, so A LOT changed.

mitu

@roslof said in Emulation station freezing:

Q: When updating Raspberry Pi software, is the output logged somewhere? I'd like to see what changed. It had been awhile, so A LOT changed.

The updates are logged to /var/log/apt/history.log or one of the gz files in the same folder.

roslof

@mitu said in Emulation station freezing:

@roslof said in Emulation station freezing:

Q: When updating Raspberry Pi software, is the output logged somewhere? I'd like to see what changed. It had been awhile, so A LOT changed.

The updates are logged to /var/log/apt/history.log or one of the gz files in the same folder.

Will investigate now. Thank you mitu.

roslof

Logs show that I ran apt full-upgrade on 2021-06-12.
Issues started on that date. Should rule-out an ES update, correct? I upgraded RetroPie regularly.

Kernel was updated
12 VLC related updates
...and lots more :|

Full log from history.log.1

Might start with rolling back VLC... then test for awhile
Then try ~~to find the previous stable kernel and try that next~~ my previous kernel (which, if I'm reading the log correctly was kernel dated: 20210303.

Also, this thread...
A change from Dec/Jan affected VLC. Should be unrelated, if my previous kernel was working well (20210303)...

mahoneyt944

I can't confirm what change occured exactly as I didn't dig that far. Though I did test different combinations of updates back when I discovered the effected setting, with and without updating the kernel, etc. Without testing every commit from that time one by one, it seemed to follow the ES update not the kernel. After removing the before mentioned gpu setting the freezing has been resolved and that was good enough for me. I've updated again fully, just 2 days ago, and I am still not experiencing issues. Mind you my build runs literally 24/7, so I'm confident in the results with my build.

This was just my experience though, if nothing else maybe a starting point for someone to dig further.

4.6.8 worked fine. 4.7.1 had freezes with the same gpu setting. So any commits in that time should be suspect. ES would be my target since it's all that froze for me. The pi still works fine other than that, as in its still working over network etc.

roslof

@mahoneyt944 said in Emulation station freezing:

4.6.8 worked fine. 4.7.1 had freezes with the same gpu setting. So any commits in that time should be suspect. ES would be my target since it's all that froze for me. The pi still works fine other than that, as in its still working over network etc.

Thank you @mahoneyt944
Are you currently running the experimental ES or non-experimental?

mahoneyt944

@roslof I believe I updated from binary. So latest stable.

roslof

@mahoneyt944 said in Emulation station freezing:

@roslof I believe I updated from binary. So latest stable.

Again, helpful. It's still early, but my issue is starting to look like a source-built ES-dev build. The only way I'm testing this is by simply letting the video screensaver run until it freezes, or until I give a ton of time.

Like you, @mahoneyt944, I appear stable with non-dev (so good news for RetroPie in general as dev is experimental).

If it turns out to be source-built ES-dev, I'll zero-in on whether or not it's how it's being built, or if a breaking change came in.

UPDATE: Freezes with latest pre-built binary of ES-dev. Convinced issue is indeed with EmulationStation-dev. Will manually build from older commits (looks like May timeframe has some good targets). It also would appear that my issue is something fairly new, as this thread started in Nov 2020...

UPDATE #2: When the video freezes, it appears that vcgencmd is hanging as seen in htop (status D):

D - uninterruptible sleep (usually IO)
Uninterruptable processes are USUALLY waiting for I/O following a page fault. The process/task cannot be interrupted in this state, because it can't handle any signals; if it did, another page fault would happen and it would be back where it was.