Multiple U4 freezes (with debug logs)

[gtwundke]

I've just had my U4 freeze (spinning wheel of doom on screen) two times in fairly quick succession, requiring a reboot via ssh each time. This happens probably a couple of times a month for me, but today is the first time that it has happened twice in a day. It always happens when I'm just changing channels using the up/down channel buttons. Nothing else special going on.

I have debug logs turned on, so I've attached the two from today.

[prl]

What firmware version are you running? (MENU>Information>About>Revision)

[peteru]

Looks like 19.3-20210826.0 beta that has not been update to the latest version.

I also notice that you are using OverlayHD. Please test for the issue after a USB reflash and without installing any additional plugins that are not already in the USB image.

[gtwundke]

Looks like 19.3-20210826.0 beta that has not been update to the latest version.

I also notice that you are using OverlayHD. Please test for the issue after a USB reflash and without installing any additional plugins that are not already in the USB image.

Yeah, I haven't yet installed today's beta update, but this issue has been going on for a year, maybe more, so it's not a recent update thing.

To be honest, I'm not going to reflash etc, etc because in general the issue happens just too rarely (other than today); I really can't "test for the issue" in any meaningful way. There's obviously a race condition somewhere in the code, and if you can't determine anything from the debug logs then there's not much to be gained by me having to go through all of that.

Note that someone else posted about a same/similar issue a few months ago (viewtopic.php?f=47&t=14707) although they posted the output from /var/log/messages, which I probably should have done but didn't think of it. Not sure if this is the same thing.

[peteru]

this issue has been going on for a year, maybe more, so it's not a recent update thing.

To be honest, I'm not going to reflash etc, etc because in general the issue happens just too rarely (other than today); I really can't "test for the issue" in any meaningful way. There's obviously a race condition somewhere in the code, and if you can't determine anything from the debug logs then there's not much to be gained by me having to go through all of that.

Note that someone else posted about a same/similar issue a few months ago (viewtopic.php?f=47&t=14707) although they posted the output from /var/log/messages, which I probably should have done but didn't think of it. Not sure if this is the same thing.

Fair enough. If it is indeed the front panel icon deadlock, it would be nice to have a matching set of kernel and application logs. Not that this would guarantee a fix. The problem appears to be in the U4 hardware drivers and I don't really expect to see any further updates in the future. Reducing the likelihood of triggering the problem from within enigma2 is probably the best chance of addressing this, but it may just not be possible.

[gtwundke]

Hmm, maybe something has changed that is making this more frequent, as it has happened again just now. I'm on the latest beta firmware (updated this morning).

Here's the debug log and /var/log/messages.

[prl]

There are definitely some problems:

Code: Select all

Aug 31 17:18:02 beyonwizu4 user.err kernel: INFO: task kworker/0:0:4 blocked for more than 120 seconds.

kworker is an internal kernel process responsible for much of what the kernel does.

I'm having a bit of a problem matching up the place in the /var/log/messages file where the first of those errors happen with the timestamps in the Enigma2-*log file.

The messages file says that the system was started at about 15:30 and the firsd "task kworker blocked" message was at about 17:18 (132 min or about 7900 seconds after boot time).

The timestamp in the Enigma2-*.log file says that the enigma2 process (which runs the PVR functionality) started at about 17:08, but its latest timestamp is about 480 seconds (about 8 minutes) after boot time.

[Grumpy_Geoff]

The messages file says that the system was started at about 15:30 and the firsd "task kworker blocked" message was at about 17:18 (132 min or about 7900 seconds after boot time).

The messages file timestamp starts in 1970. It gets current time at 17:08:10.

The timestamp in the Enigma2-*.log file says that the enigma2 process (which runs the PVR functionality) started at about 17:08, but its latest timestamp is about 480 seconds (about 8 minutes) after boot time.

I make the last write to the debug log to be ~17:15:49.

[prl]

Hmm. Quite right. I don't know what I did there. I'll try to have another look at it tomorrow.

[Grumpy_Geoff]

It appears to be the same front panel icon deadlock that I've previously posted details about.

[peteru]

Definitely front panel related deadlock issue. Piecing some of the clues together, it looks like there are three players involved. The recording indicator, the scrolling of a front panel message (one that is too long for the display) and an update of the front panel icons as a demux is being freed.

At a guess, the scrolling of the front panel is going to be the slowest to run and therefore increase the risk of deadlock the most. Sending shorter message strings to the front panel (to avoid scrolling) may be a feasible mitigation strategy.

[gtwundke]

Definitely front panel related deadlock issue. Piecing some of the clues together, it looks like there are three players involved. The recording indicator, the scrolling of a front panel message (one that is too long for the display) and an update of the front panel icons as a demux is being freed.

At a guess, the scrolling of the front panel is going to be the slowest to run and therefore increase the risk of deadlock the most. Sending shorter message strings to the front panel (to avoid scrolling) may be a feasible mitigation strategy.

To be perfectly honest, I'd be entirely happy if there was an option to turn off all of that information from the front panel display. I've never once looked at it for information, as it's just too small and too far away.

Maybe there's scope for multiple more nuanced options, in terms of what gets displayed, but I'm guessing that most people won't be that picky. Show it all, and risk the bug, or turn it all off (and just display the time, or whatever).

[gtwundke]

To be perfectly honest, I'd be entirely happy if there was an option to turn off all of that information from the front panel display. I've never once looked at it for information, as it's just too small and too far away.

Maybe there's scope for multiple more nuanced options, in terms of what gets displayed, but I'm guessing that most people won't be that picky. Show it all, and risk the bug, or turn it all off (and just display the time, or whatever).

Note that I realise that you can turn the front display completely off (which I'm assuming would fix this issue?), but the one thing that it is actually helpful for is seeing whether the box is turned on or not, and what state it's in, so it would be nice to at least have the time or something displayed.