100% процессора на 4 из 8 ядер в Oracle Linux

У меня есть настольный компьютер (Intel i4770), на котором работает Oracle Linux 7.9 с ядром 4.1.12-61. Обычно я его выключаю и включаю только в редкие моменты, когда мне нужно что-то протестировать. Месяц назад я включил его и заметил, что вентиляторы работают на максимальной скорости – я проверил top и услышал, что setroubleshoot загружен на 100%, поэтому я убил этот процесс. Процесс продолжал возвращаться, и я снова его убивал, но в конечном итоге это не имело большого значения, потому что мои тесты были завершены, и я снова выключил компьютер. (Да, я всегда выключаю его корректно.)

Теперь пытаясь разобраться в проблеме, setroubleshoot больше не показывает 100% в top. На самом деле, ничего даже близко к 100%. Запустив htop, я вижу детали о процессорах, и 4 из 8 ядер постоянно загружены на 100%. С момента, когда компьютер позволяет мне войти в систему, до момента, когда я его выключаю. Но в списке процессов нет ничего выше 5.2%.

Когда я запускаю perf на каждом ядре с perf top -C 1 --sort comm, я вижу, что ядра с 0 по 3 загружены на 100% в пространстве ядра.

Вот отчет perf, полученный при выполнении perf record -a -F 999 -- sleep 10. Я не знаю, указывает ли сбой в нахождении полезных символов на проблему, которую я ищу, является ли это другой проблемой, в решении которой мне понадобится помощь, или же это что-то, что следует игнорировать.

На рабочем столе этого компьютера я заметил кучу ошибок SELinux. Все они, похоже, указывают на то, что была попытка выполнить что-то, что не должно было разрешаться.

И просто чтобы подтвердить, что htop прав относительно своих отчетов, вот отчет из Системного Монитора.

Загрузка предыдущей версии ядра не помогла. И загрузка в “резервное” ядро тоже не помогла.

Я попытался обновить ядро, но это не помогло. Я произвел обновление программного обеспечения, и это тоже не помогло. Заметьте, что перед началом этой проблемы я не делал никаких обновлений и не устанавливал нового программного обеспечения. Эта установка была стабильной в течение многих лет, когда она мне была нужна.

Я также попытался установить ту же ОС еще раз на новый внешний диск. Это сработало. Никаких проблем на этом диске. Но когда я загружаюсь на этот диск и затем выбираю ядро, которое находится на основном диске, проблема возвращается. Это все кажется доказывающим, что ядро не является проблемой, но на основном диске системы что-то не так.

Я не знаю, как дальше дебажить. Я не могу понять, что изменилось и почему, поэтому не знаю, как начать его исправление. Любая помощь по тому, куда смотреть и что проверять, будет оценена!

___ Редактирование 1: ___

Вывод из ps -efl|sort -rk14|head:

F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY       TIME CMD
0 S gdm       2085  2041  2  80   0 - 905731 -     17:42 ?        00:00:02 /usr/bin/gnome-shell
4 S root         1     0  1  80   0 - 54811 -      17:41 ?        00:00:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
4 S root       837     1  1  80   0 - 22671 -      17:42 ?        00:00:01 /sbin/rngd -f
1 S root       405     2  0  60 -20 -     0 -      17:41 ?        00:00:00 [xfs_mru_cache]
1 S root       407     2  0  60 -20 -     0 -      17:41 ?        00:00:00 [xfs-data/sda1]
1 S root       408     2  0  60 -20 -     0 -      17:41 ?        00:00:00 [xfs-conv/sda1]
1 S root       409     2  0  60 -20 -     0 -      17:41 ?        00:00:00 [xfs-cil/sda1]
1 S root       406     2  0  60 -20 -     0 -      17:41 ?        00:00:00 [xfs-buf/sda1]
1 S root       404     2  0  60 -20 -     0 -      17:41 ?        00:00:00 [xfsalloc]

вывод из dmesg | grep libsystem

[    3.344918] audit: type=1400 audit(1731105719.768:4): avc:  denied  { execute } for  pid=496 comm="systemd-journal" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
[    3.351928] audit: type=1400 audit(1731105719.775:6): avc:  denied  { execute } for  pid=502 comm="systemd-readahe" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:readahead_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
[    3.351929] audit: type=1400 audit(1731105719.775:5): avc:  denied  { execute } for  pid=503 comm="systemd-readahe" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:readahead_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
[    3.374010] audit: type=1400 audit(1731105719.797:7): avc:  denied  { execute } for  pid=513 comm="systemd-tmpfile" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
[    3.386383] audit: type=1400 audit(1731105719.810:8): avc:  denied  { execute } for  pid=525 comm="systemd-sysctl" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
[    3.397457] audit: type=1400 audit(1731105719.821:9): avc:  denied  { execute } for  pid=536 comm="hostname" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:hostname_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
[    3.673352] audit: type=1400 audit(1731105720.097:10): avc:  denied  { execute } for  pid=657 comm="alsactl" path="/usr/local/lib/libsystem.so" dev="sda1" ino=136977390 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0