Whole OS freezes watching a video with MPV

Ok, this is the report before the freeze. There are some strange things

mag 10 15:01:01 enrico-fedora CROND[129088]: (root) CMD (run-parts /etc/cron.hourly)
mag 10 15:01:01 enrico-fedora run-parts[129092]: (/etc/cron.hourly) starting 0anacron
mag 10 15:01:01 enrico-fedora run-parts[129098]: (/etc/cron.hourly) finished 0anacron
mag 10 15:16:41 enrico-fedora systemd[1]: Starting dnf makecache...
mag 10 15:16:42 enrico-fedora dnf[134636]: Cache dei metadati aggiornata recentemente.
mag 10 15:16:42 enrico-fedora systemd[1]: dnf-makecache.service: Succeeded.
mag 10 15:16:42 enrico-fedora systemd[1]: Finished dnf makecache.
mag 10 15:16:42 enrico-fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
mag 10 15:16:42 enrico-fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
mag 10 15:39:49 enrico-fedora systemd-udevd[576]: hidpp_battery_0: Worker [138975] processing SEQNUM=3407 is taking a long time
mag 10 15:39:49 enrico-fedora systemd-udevd[138975]: hidpp_battery_0: Spawned process '/usr/sbin/tlp auto' [138976] is taking longer than 59s to complete
mag 10 15:41:49 enrico-fedora systemd-udevd[576]: hidpp_battery_0: Worker [138975] processing SEQNUM=3407 killed
mag 10 15:41:49 enrico-fedora systemd-udevd[576]: Worker [138975] terminated by signal 9 (KILL)
mag 10 15:41:49 enrico-fedora systemd-udevd[576]: hidpp_battery_0: Worker [138975] failed

HIDPP could be related to Logitech as I see here http://lkml.iu.edu/hypermail/linux/kernel/1702.0/01188.html and I have a Logitech trackball. @sonnycardona @zarathustra19 do you have any logitech device attached to your system?

I really don’t know. I don’t even know how to find out if I have it installed or not. To be honest with you, I’m giving up the search for the problem; I’ll live with it while it lasts.

I wish you all the best and I hope you can find the cause of the problem soon.

Thanks for everything, man. :nerd_face:

Did anyone try changing to scheduler to see if it helped? In that case, because it’s a CPU hang, no logs are written which made it difficult to debug in the first place.

Hello, I also experience this problem with Fedora MATE 32. I also had it with Fedora MATE 31 before I upgraded. It an happen when opening a video, when playing a game on Wine, or sometimes when opening an application. I think it does not leave logs because the syslog process is not running on close to 100% after I boot again, something which does happen when I have to reboot because of other problems.

Regarding the schedulers, I followed the links but I am not sure what do to to make changes.

$ grep "" /sys/block/*/queue/scheduler
/sys/block/dm-0/queue/scheduler:none
/sys/block/dm-1/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sdb/queue/scheduler:mq-deadline kyber [bfq] none

If I get it right I 'd have to echo to those files to change scheduler but I m not sure how or with what options.

1 Like

These are the relevant bits. You are using the bfq scheduler for these two disks: sda and sdb. To modify them, try:

# does not work if we use sudo echo ...
sudo -i 
echo "mq-deadline" > /sys/block/sdb/queue/scheduler

# then verify with:
cat /sys/block/sdb/queue/scheduler

If this helps with the issue, it is possible to make this persist over reboots.

Thanks for the reply. I will try this and see if I get an improvement. Because the bug is intermittent, hence requiring a lot of retries, and time constraints it will take some time.

edit: Actually on early testing I was “able” to freeze my system again. So the scheduler fix doesn’t seem to apply in my case.

I’ve reinstalled the whole system (not because of this bug). The freeze happened again on a brand-new Fedora 32 installation. I’ve not copied my /home or anything else.

It is the main way to update the system with dnf. “dnf upgrade” has been deprecated.

Hi Tim, actually it’s the other way around, “update” has been kept since the transition from yum as an alias to the “upgrade” command. After almost two decades, I always type update, I guess when it finally goes away I’ll get used to upgrade.

1 Like

@alexpl Ah, you’re right. I can never keep it straight, either.

Sorry.

1 Like

This is what official’s dnf web says about upgrade.

:nerd_face:

Hi, @enrico,@zarathustra19,@iolaum, here’s some information that might be useful:

I hope it serves you. :nerd_face:

@sonnycardona Yes, I had it backwards. See my reply to @alexpl, above.

1 Like

I wanna test the scheduler change suggested by @FranciscoD a little bit more. I think the way I tested it previously may have hit another bug.

I know how to make the change temporarily. With regards to making it permanent, how do I do it?

I found this webpage making a suggestion, is that the way to go? Is the way to do this to permanently add elevator=mq-deadline to the GRUB kernel arguments?

P.S. The reason I want to make this change permanent is that the freeze is so infrequent that I think I need to run the different scheduler for a month or so to see if I get that specific bug or not.

After doing some more searching I found that the elevator command line argument has been deprecated and removed from latest kernels. Hence the proper way to change scheduler is to add appropriate udev rules. This is described in this askfedora post that also references the relevant ArchWiki.

I have made the relevant change and verified it works. I 'll keep it around for a month to see If I don’t get freezes when opening programs or files anymore.

P.S. Note that information on the ArcchWiki may not always be appropriate for Fedora.

1 Like

Unfortunately I managed to break my installation (hint: dont mix release channels) and I had to re-install. I took the opportunity to distro hop from Fedora MATE to pure Fedora so I can no longer test this. While my testing last I did not encounter any more freezes with the mq-deadline scheduler.

1 Like

How to do that? I added elevator= in the kernel line on grub, but it was not applied after the reboot.

1 Like

Seems to be documented here:

1 Like

Hi, me again.

Do you think maybe this could be the solution? :thinking: