Retropie hangs in emulation station after update to ES 2.6.1
-
Retropie hangs in emulation station after update to ES 2.6.1.
System hangs after about 1 hour idle while in emulation station. The hang appears to be caused by recent emulation station update. I'm running on a combination of RPi3, Retropie 4.2, a known good SD card, and 2 Logitech wireless Rumblepad 2 joysticks. The system had been running flawlessly until my most recent updates of installed base packages (via apt-get update/upgrade), kernel (via rpi-update, currently at 4.9.45), and Retropie packages (via retropie_setup.sh), about a week ago (around August 20 or so). Previous full system update took place around end of June or beginning of July, and had been running fine, without any hangs, crashes, or other indicators of problems. Prior to this new hanging, system typically ran 24/7. Once this hanging behavior started, I thought maybe the update process had corrupted the file system (as that has happened to me before), so I did a completely clean install using the 7/5/17 raspian lite image (last official Jesse release) and a manual install of the retropie script (git clone, etc.). The hanging at idle problem immediately reappeared.
I am using a wired network connection; wifi is on but unused. Bluetooth is on, but no devices are connected. If left idle after booting into emulation station, the system will soft-hang in about an hour, with video and joysticks becoming unresponsive. If I attempt to log in via ssh, the terminal appears to hang, but I can Ctrl-C out of the hung logon process and get a prompt. A dmesg query returns a number of repeated warning about a hung kworker thread being unresponsive for over 120 seconds. That repeats in the log 4 or 5 times, and then the log ends. The process id of the hung kworker thread changes every time. A query with "journalctl -p 3 -xb" gives similar error messages. I haven't been able to find anything else in the logs. At this point in the process, if I attempt a "sudo reboot", my terminal session terminates, but the RPi never actually reboots, and I have to remove power to force a restart.
I have found that if I restart the system and quit out of emulation station to the command line, the system remains responsive and functions as expected (e.g. I can login via terminal normally, I can reboot, and dmesg and journalctl behave as expected), and has continued to run without hanging. If I again restart and leave ES running, the hang reappears within about an hour.
Any troubleshooting tips are appreciated.
-
@chauncyblack I just looked at this quickly but will hopefully get a chance to fully read it soon. Can I ask first of all why you are using that kernel? Current stable is 4.9.35-v7+ Perhaps that is causing issues. Try rolling back and see what happens.
-
@jonnykesh I'm using that kernel because it's the one rpi-update installed. At any rate, one of the first things I tested was to roll back the kernel to a version (unfortunately, I don't remember which version it was, and I had since done the clean reinstall mentioned in the first post) where the system was working correctly, and the hanging behavior persisted. So I believe that the newer kernel is very likely not the culprit.
-
@chauncyblack newer kernels often cause bugs, using rpi-update isn't really recommended unless you know what you're doing/have a purpose for it.
To eliminate the kernel as the culprit at least you can flash a new image and do all your updates again sans RPI update. It is also possible ES has a bug as there have been a few changes in the last little bit.
-
@herb_fargus Yes, I understand that. But as I indicated in the above post, I had already downgraded to a known good kernel, and the error was still appearing. As it is several hours worth of work to recopy all my data to a new image (again), I am reluctant to rewrite the image without something more than an unsupported guess that the kernel is the culprit.
-
are you running video snaps?
-
When in a frozen state, if you ssh into the Pi and run
top, what's the status of the processes? Anything topping the memory or CPU usage? -
@dankcushions No, I am not running any videos.
@pjft I looked at memory usage via htop several times, and nothing was hogging CPU time or memory. However, I do have new information that changes my prior conclusion that ES was the culprit: the hang did reappear even when ES was not running. I did not see that behavior before because it appears to be taking much longer when ES is not running (on the order of a day instead of a few hours).
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.