Linux acpi error ae not found

Операционная система: Linux Mint 19 64-разрядная
Процессор: AMD Athlon(tm) II X4 645
Материнская плата: Gigabyte 970a ud3
Видеокарта: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]

После выбора Linux Mint в GRUB появляется ошибка acpi error:ae_not_found,while resolving a named reference package element — lnkd(20180313/dspkginit-414) и монитор отключается. Сама система скорее всего стартует.

Что сделано?
1. Установил последний драйвер Mesa 18.3
2. Играл с параметрами запуска: noapic pci=nomsi,noaer acpi=strict/off.
Появляются разные другие ошибки, но результат тот же.
3. Обновил BIOS до последней версии.
4. Обновлял ядра с 4.15 до 4.18 и откатывал до 4.1

Нашёл баг ядра на чипе AMD

https://bugzilla.kernel.org/show_bug.cgi?id=198167

, но там указывается, что он присутствует, начиная с 4.14.3. У меня же не работает даже на 4.1. Чтобы проверить более старые ядра нужно уже удалять дополнительное ПО

Проблема прогрессировала. Изначально на Ubuntu 16.04 она возникала изредка и «решалась» перезагрузкой системы. Затем я купил SSD и поставил на него Linux Mint 19. На свежеустановленной системе было то же самое, но через 2 недели из периодической проблема стала регулярной. Теперь Linux Mint запускается только в режиме nomodeset, то есть с програмным рендерингом.

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

Windows 10 из grub запускается без проблем. Всегда.

Буду благодарен за любую помощь. Прикладываю фото ошибок при разных параметрах запуска

https://yadi.sk/i/RL52ovcxLnRW5g

по-умолчанию

https://yadi.sk/i/KSLWKxQ0EBMmTQ

acpi=strict

https://yadi.sk/i/DqnveOVrtctVoA

pci=nomsi,noaer acpi=off

karpo518, эта ошибка что спамит acpi — она вряд ли напрямую к видео.

Мне тоже думается что

karpo518 писал(а): ↑

01 окт 2018, 13:23

Сама система скорее всего стартует.

просто вывод либо куда-то в никуда, либо в неподдерживаемый режим.

Для начала попробуй на этом моменте, когда она стартует перейти в tty (ctrl-alt-f1) , залогиниться и вызвать DISPLAY=:0 xrandr

Ну и nomodeset — это тоже не свосем про программный рендеринг, или с ним корица ругается?

Chocobo, спасибо за ответ.

Ну и nomodeset — это тоже не совсем про программный рендеринг, или с ним корица ругается?

Именно так. Выражение «Программный рендеринг» я взял из предупреждения от Cinamon. Оболочка в этом режиме предупреждает о возможном увеличении нагрузки на CPU, но добавляет, что для отладки этот режим — то что надо.

Для начала попробуй на этом моменте, когда она стартует перейти в tty (ctrl-alt-f1) , залогиниться и вызвать DISPLAY=:0 xrandr

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

Может быть сразу лог какой-нибудь глянуть?

karpo518 писал(а): ↑

01 окт 2018, 16:08

Может быть сразу лог какой-нибудь глянуть?

Что бы сразу глянуть все логи, можно загрузиться с той флешки с которой ставили минт и сделать hw-probe (как это сделать, см. ссылку в шапке над форумом). А сюда уже выложишь, только ссылку на эти логи.
ИМХО, если проблема прогрессирует, то это скорее к железу, нежели к ПО.

Господа, дома не сразу удалось неудачно запустить систему. Это помогло мне получить 2 лога: успешной загрузки и неудачной. Я отфильтровал файлы по слову failed. В неудачном варианте есть строка:
окт 01 20:41:57 karpo518-GA-970A-UD3 cinnamon-session[1207]: GLib-GIO-CRITICAL: t+969,02138s: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

Получается, что cinnamon не смог стартовать. Но почему это случилось, я так и не смог понять. Когда я переустанавливал систему, я монтировал непустую папку /home. Подозреваю, что я перенёс в новую систему какой-то старый кривой конфиг. С учетом того, что ранее папка принадлежала пользователю Ubuntu 16.04, на который дополнительно был установлен Cinnamon, проблема могла каким-то образом обостриться.

Прикладываю полные и отфильтрованные логи. Просьба подсказать, что с этим делать.

https://yadi.sk/d/MPEqMLZVZCQJDw

Снёс gnome-keyring. Долго боролся с этой софтиной, но она меня победила. Постоянно создаёт дубли связок ключей, которые я замучился удалять. Когда увидел в логе 2 000 строк ошибок от него, удалил без всяких сожалений. Вот сама ошибка:
gnome-keyring-daemon[1204]: GLib: g_hash_table_unref: assertion 'hash_table != NULL' failed

Несколько раз cinnamon запустился без проблем, но потом снова не получилось. Продолжил анализировать ошибки и нашёл:

udisksd[735]: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory

Возможно эта ошибка и была причиной проблемы с gnome-keyring. Решилось установкой libblockdev-mdraid2. Пока cinnamon запускается без проблем. Вечером ещё перезапущу несколько раз проверю получше, ведь в логе всё ещё есть ошибки. Вообще странно, что свежая система не досчиталась пакета.

karpo518, Взаимосвяь между gnome-keyring и mdraid сложно придумать.

И опять же сам факт что gnome-kerying уже стартует, говорит о том, что за DM уже логин прошел и иксы не упали, т.к. дальше взлетают процессы от DE
Т.е сама система где-то там работает, а показывать тебе не хочет)

karpo518 писал(а): ↑

01 окт 2018, 21:16

Когда я переустанавливал систему, я монтировал непустую папку /home. Подозреваю, что я перенёс в новую систему какой-то старый кривой конфиг. С учетом того, что ранее папка принадлежала пользователю Ubuntu 16.04, на который дополнительно был установлен Cinnamon, проблема могла каким-то образом обостриться.

А создать нового «пустого» пользователя не пробовал для диагностики? Ну чтобы конфиги исключить… На нем же можно было бы обкатать какой-нибудь другой ДЕ.

А создать нового «пустого» пользователя не пробовал для диагностики? Ну чтобы конфиги исключить… На нем же можно было бы обкатать какой-нибудь другой ДЕ.

Если моя система не стартует, то до выбора пользователя дело не доходит. Прошло достаточно много времени, но проблема никуда не делась. Сейчас, чтобы удачно стартовать систему с флагом radeon.dpm=0
Эта ситуация меня жутко раздражает:

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

2. Система постоянно обновляется, и мой кастомный режим GRUB сползает вниз с дефолтной позиции., а значит не будет стартовать автоматически. Да и чтобы сразу после обновления использовать новое ядро приходится создавать новый кастомный режим с флагом radeon.dpm=0 на основе нового ядра. Это недолго, но угнетает мою нервную систему.

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

karpo518 писал(а): ↑

09 мар 2019, 01:04

Если моя система не стартует, то до выбора пользователя дело не доходит.

karpo518 писал(а): ↑

09 мар 2019, 01:04

Сейчас, чтобы удачно стартовать систему с флагом radeon.dpm=0

Чего-то вы нас путаете. У вас хоть при каком-то раскладе удаестя загрузиться?
Так сделайте второго пользователя. Выйдите из сеанса. И посмотрите сохраняется ли проблема у второго пользователя? Этим вы отсечете возможность перетаскивания некорректных конфигов… то, что вы писали

karpo518 писал(а): ↑

01 окт 2018, 21:16

Когда я переустанавливал систему, я монтировал непустую папку /home.

darkfenix писал(а): ↑

01 окт 2018, 16:57

в данном случае hw-probe соберет логи live-системы — они не помогут

если топик-стартеру все-таки удается загрузиться хоть в каком-нибудь состоянии, то давно уже можно было поделиться hw-probe…

а вот это все

karpo518 писал(а): ↑

09 мар 2019, 01:04

В целом достаточно досадно, что имея реальную проблему с системой, я весь такой готовый предоставить любую информацию так и не смог получить решения.

без реальных логов, больше похоже на троллинг

StarMAUGLI писал(а): ↑

09 мар 2019, 02:07

без реальных логов, больше похоже на троллинг

Просто человек никак не может осознать, что вот на этом —

karpo518 писал(а): ↑

01 окт 2018, 13:23

Видеокарта: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]

, которая даже кружки пива не стоит, ничего из современного нормально работать не будет. И что в —

karpo518 писал(а): ↑

01 окт 2018, 13:23

Материнская плата: Gigabyte 970a ud3

Hybrid EFI как минимум в первой ревизии. О чем его ОС Линукс, установленная в эмуляции БИОС ни ухом ни рылом. Ясен пень будет спамить еррорами по ацпи куда только можно, +большая вероятность, что присутствует разгон. Иначе Вин10 там будет просто, извините, усираться, а не работать, потому что

karpo518 писал(а): ↑

01 окт 2018, 13:23

AMD Athlon(tm) II X4 645

Core I5 то не догоняет, не говоря уж о Sandy.
Особенность железа. И никто это не будет фиксить.
Купить видяшку б/у получше, выше АМДшки 7000 серии и не нужно, установить LMDE2 + Каталист и сидеть на жопе ровно. Или ещё заменить Атлон на Феном, тогда уж что-то будет получаться и на amdgpu с новыми ядрами в современных дистрибутивах. И с ЦП без кэша 3-го уровня вообще не хрен делать х64 ОС, не работают они. Так, корячутся в однозадачном режиме.

Всем привет! Извините за долгое ожидание. Я не был подписан на тему, поэтому упустил её из виду. Подытожу информацию.

1. При запуске системы после выбора ядра монитор отключается (переходит в спящий режим). Системный блок продолжает работать.
2. Ранее, я анализировал приложенный лог неудачной загрузки и увидел ошибку, которая намекает на то, что cinnamon не смог стартовать. Сейчас уже не вспомню, что именно за ошибка.
3. Проблема не связана с выбором пользователя, потому что возникает до появления окна авторизации.
4. Система стартует успешно, если добавить в GRUB параметр запуска radeon.dpm=0

Прикладываю hw-probe, запрошенный вами ранее.

https://linux-hardware.org/?probe=9ebc8fd78b

Слепок сделан в режиме radeon.dpm=0

Очень рассчитываю на вашу помощь!

Купить видяшку б/у получше

Не играя ни в какие игры, совсем не рассчитывал, что мне в этом десятилетии потребуется новая видеокарта для запуска фильмов и редактора кода.

большая вероятность, что присутствует разгон

Никаким разгоном я не занимался. Процессор покупался из сегмента выше среднего для своего времени и он гораздо моложе видеокарты. Windows 10 работает прекрасно. С относительно тяжелыми программами компьютер справляется. Photoshop, Phpstorm работают без проблем. Тот же Kdenlive в Linux Mint в режиме radeon.dpm=0 работает без тормозов. Поэтому считаю, что говорить об устаревании процессора ещё рано. Его замена в ближайшие 5 лет ничем не оправдана. Ну если только, чтобы «починить» Linux Mint.

Купил Radeon rx570. Хотел решить проблему на несколько лет с запасом. Поставил драйвера с оф. сайта. Теперь cinnamon вообще не стартует. Секс продолжается

Code: Select all

systemd-analyze
systemd-analyze critical-chain
systemd-analyze blame

Code: Select all

user@computer:~$ systemd-analyze
Startup finished in 3.454s (kernel) + 3.083s (userspace) = 6.537s 
graphical.target reached after 3.049s in userspace
user@computer:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @3.049s
└─multi-user.target @3.049s
  └─networkd-dispatcher.service @2.310s +738ms
    └─basic.target @2.263s
      └─sockets.target @2.263s
        └─uuidd.socket @2.263s
          └─sysinit.target @2.260s
            └─apparmor.service @2.055s +97ms
              └─local-fs.target @2.054s
                └─boot-efi.mount @2.040s +13ms
                  └─systemd-fsck@dev-disk-byx2duuid-9934x2d6DD8.service @1.781s +258ms
                    └─dev-disk-byx2duuid-9934x2d6DD8.device @1.780s
user@computer:~$ systemd-analyze blame
1.811s apt-daily-upgrade.service                            
1.434s dev-sda2.device                                      
 738ms networkd-dispatcher.service                          
 563ms udisks2.service                                      
 374ms accounts-daemon.service                              
 306ms ubuntu-system-adjustments.service                    
 304ms systemd-journal-flush.service                        
 258ms systemd-fsck@dev-disk-byx2duuid-9934x2d6DD8.service
 248ms avahi-daemon.service                                 
 237ms NetworkManager.service                               
 230ms ufw.service                                          
 229ms systemd-logind.service                               
 225ms upower.service                                       
 223ms polkit.service                                       
 222ms ModemManager.service                                 
 205ms keyboard-setup.service                               
 190ms gpu-manager.service                                  
 183ms thermald.service                                     
 182ms e2scrub_reap.service                                 
 177ms systemd-journald.service                             
 175ms wpa_supplicant.service                               
 166ms systemd-udevd.service                                
 158ms systemd-modules-load.service                         
 152ms systemd-udev-trigger.service                         
 151ms systemd-resolved.service  

Code: Select all

systemd-analyze
systemd-analyze critical-chain
systemd-analyze blame

Code: Select all

28th Feb 2021 11:39hrs
user@computer:~$ systemd-analyze
Startup finished in 3.302s (kernel) + 35.977s (userspace) = 39.279s 
graphical.target reached after 28.153s in userspace
user@computer:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @28.153s
└─multi-user.target @28.153s
  └─postfix.service @28.146s +6ms
    └─postfix@-.service @24.114s +4.029s
      └─network-online.target @24.107s
        └─NetworkManager-wait-online.service @17.438s +6.668s
          └─NetworkManager.service @17.169s +266ms
            └─dbus.service @17.165s
              └─basic.target @17.147s
                └─sockets.target @17.147s
                  └─uuidd.socket @17.147s
                    └─sysinit.target @17.143s
                      └─apparmor.service @17.030s +112ms
                        └─local-fs.target @17.029s
                          └─run-user-1000-gvfs.mount @35.402s
                            └─run-user-1000.mount @32.935s
                              └─swap.target @524ms
                                └─swapfile.swap @391ms +133ms
                                  └─systemd-remount-fs.service @361ms +28ms
                                    └─systemd-journald.socket @343ms
user@computer:~$ systemd-analyze blame
18.731s fstrim.service                                       
16.606s dev-sda2.device                                      
 6.668s NetworkManager-wait-online.service                   
 4.029s postfix@-.service                                    
 1.056s man-db.service                                       
  925ms networkd-dispatcher.service                          
  757ms udisks2.service                                      
  538ms logrotate.service                                    
  511ms apt-daily-upgrade.service                            
  485ms ubuntu-system-adjustments.service                    
  482ms apt-daily.service                                    
  451ms systemd-logind.service                               
  449ms accounts-daemon.service                              
  349ms systemd-journal-flush.service                        
  323ms networking.service                                   
  290ms ModemManager.service                                 
  266ms NetworkManager.service                               
  260ms fwupd-refresh.service                                
  245ms avahi-daemon.service                                 
  238ms polkit.service                                       
  237ms systemd-resolved.service                             
  228ms ufw.service                                          
  214ms upower.service 

asked Apr 8, 2018 at 17:24

Adding onto this answer since I had the same happen with Linux Mint 20 recently, and none of the answers posted everywhere else were necessary in my case:

I ran the exit command, which suggested using the command fsck for one of my disk partitions. After I did that, the partition got fixed and my system was able to boot successfully after a restart.

Hope it helps someone in case they come across this same issue.

answered Jul 10, 2021 at 16:09