[mythtv-users] System freezes

[Stephen Worthington]

On Tue, 21 Mar 2023 11:09:13 +0000, you wrote:

>Stephen, thanks for your reply and suggestions.  I'll work on them, but 
>here's more info:
>
>The freezes have typically happened at night when screens are off. 
>First warning is that the disk access light is found on.  Keyboard and 
>mouse unresponsive; caps lock key doesn't affect its light.  ssh from 
>another box gets no response.

That sounds like a fairly full on freeze.  It would still be worth
enabling SysRq and seeing if that is still working.  If it is working,
it means the problem is less likely to be what I suspect, which is an
Nvidia driver problem.  It would be worth trying an older Nvidia
driver.  If you can remember, did a driver update happen just before
the freezes started happening?  If so, go back to the version before
they started.  If that fixes the problem (or even if it does not), it
would be worth updating to the very latest drivers and see if it is
also fixed there.  I am currently on 525.85 on Ubuntu, but if your
options do not go that high yet, try 515 or 520.

>Power down by front button long press.  Reboot with both vga monitor and 
>hdmi Sony Android tv active, at first looks normal but on completion the 
>tv screen may be seen as 'off' by nVidia-settings 470xx. and needs to be 
>reset (1360x768) and repositioned to abut the DELL monitor.  (I'm still 
>having problems in getting consistent screen assignments as monitor and 
>tv do their various power-saving changes of status).

It may be that you need to make local copies of your displays' EDID
data and set the drivers to use the copies, so that both sets of data
are available at all times.  If that does not work, then you will
likely need to make customised modelines for each monitor and that is
a big pain.

>At that point I have usually run the DB-optimise-and-backup from a 
>konsole tab, and an in-and-out mythtv-setup(.real) before restarting the 
>backend and frontend(.real), again in konsole tabs.  All back to normal.
>
>The usual boot fsck checks have been ok, but I haven't yet run one from 
>a live disk.  The system is still looking ok after yesterday's pipewire 
>update and reboot.

The automatic boot fsck checks are not sufficient.  With a freeze
happens when there are writes happening on the boot partition, there
can be complex damage to the filesystem.  I had one occasion on my
mother's MythTV box that needed fsck to be run 7 times before it did
not flag any more errors.  So after every freeze, you need to boot a
live image and use that to run fsck as many times as necessary until
it does a run where there are no errors found.  If you do get damage
that is not fixed by the single automatic boot time fsck, then another
freeze causing more damage on top of the existing damage can cause
unfixable errors and you will lose the boot partition and have to
reinstall.

And there is also the problem that the automatic boot time fsck does
not log what it fixed (on Ubuntu anyway), so you have no idea if it
actually had to fix anything or not and what fixes it applied.  At the
time that fsck is run, there is nowhere for it to log anything to
except RAM, so it is not set up to log at all.

After rebooting normally, you do still need to run a full check and
repair of the database.  And re-check any table that got fixed, until
there are no more fixes done.  In freezes like this, if I am recording
at the time, I almost always get the recordedseek table damaged.
Again, failing to fix the database before using it again can cause
irreparable damage.

>There are more details here, from earlier in the chase.  But I dislike 
>the HYPERKITTY  archive...
>
>https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/R4PC7CZWD2JYMSX645KYY6SWXKIITO2Z/

Another thing I have had that caused freezes similar to yours was on
an old PC where I think the thermal paste between the CPU and its
heatsink had dried out and was not working well.  The CPU overheated
and did an instant shutdown to save itself, and that often happened
while a command was active on the SATA controller, resulting in the
SATA activity LED being stuck on.  So, is it the hotter time of the
year for you?  Is it an older motherboard?

I think thermal shutdown is less likely than an Nvidia driver problem,
mainly because of it happening more at night, when things are
generally cooler.  With my Nvidia driver problems, freezes could
happen at any time, but were more likely when the screen was changing
mode, for example from 1080p for the MythTV GUI to 1080i for playback.