[mythtv-users] System freezes

Tue Mar 21 17:41:50 UTC 2023

On 21/03/2023 13:58, Stephen Worthington wrote:
> 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. 

My recollection of SysRq is that it needed too many fingers and a 
working keyboard.  Haven't tried it recently.

Just after my first freeze, rpmfusion put a new nVidia build into 
'testing';  I installed that, and it ran without problems for a day or 
two before freezing again.  It's still the current offering for 470xx, 
the latest supporting my GT710 card.

The first freeze came soon after 60+ kde package updates, and the last 
was before the latest pipewire.  I'm in wait-and-see mode at present, 
and looking out a 'live' image.

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.
> _______________________________________________