Acpi bios error could not resolve symbol проблема
New or Quiet Penguin
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCIO.SAT0.S
I installed Leap 15.2 some weeks ago. It is in dual-boot with Windows 10. Sometimes during boot phase I have a critical issue: I receive a flood in dmesg like these:
In particular, If I turn on the PC directly into Leap, in doesn't boot, remaining in console with these messages above; if instead I first run Windows 10, then I reboot and choose Leap in GRUB, it doesn't happen and Leap is loaded.
My hardware is: ASUS P8P67, AMD Radeon HD 7950 Sapphire Dual-X, 16GB RAM, HD 1TB Western DIgital Cavial Blue (where I have the partition for Leap), SSD Samsung 830 (where I have Windows 10).
Omniscient Penguin
You have provided less than adequate information to work with, e.g. Asus website shows several models of P8P67.
What does "directly into Leap" mean? Leap from a Grub menu? Leap via selecting the HDD from the BBS menu?
How do you choose to boot Windows?
What do "remaining in console with these messages" and "doesn't boot" mean? Does a login prompt not appear at the end of those messages? From that screen, after it has stopped changing, does Ctrl-Alt-F3 change to another black screen with a login prompt?
Do you have Windows "fast boot" disabled?
Are both HDD and SSD formatted using GPT partitioning? Do you have an ESP partition on each disk?
To answer the motherboard and partitioning questions, and more, please paste here input and output from a successful Leap boot, using code tags, from:
New or Quiet Penguin
thank you for your reply! I will try to answer to all your points. This is the situation of my PC:
- /dev/sdb1: it is an SSD dedicated to Windows 10
- /dev/sda1: it is an HDwhere I store my files. It has a dedicated partition for Linux (about 30GB)
I installed GRUB on MBR of the /dev/sda. On boot, my PC load MBR from HD and I can choose Leap or Windows.
What I mean with "directly into Leap" is this. Suppose to have the PC turned off. If I turn on it, I arrive to GRUB. Here, if I choose Leap, after a while it remain in blank scrive with just console (see picture). Instead, if I first on GRUB choose Windows 10, then I reboot and choose Leap, it works.
I think I have Windows fast boot disable, need to double check.
These are the outputs of your commands:
New or Quiet Penguin
Administrator
Hi
Is the system BIOS the latest? Could try some acpi boot options (YaST -> Bootloader -> Kernel Parameters) and add;
Omniscient Penguin
Because you wrote "Sometimes during boot phase", I am suspicious you do not have Windows fast boot disabled. Please paste here using code tags the content of file /etc/fstab.
I cannot parse this:
It's still ambiguous what "doesn't boot" means.
Where is the "picture"?
You may be able to enjoy better graphics behavior by editing Grub to contain these additional parameters: radeon.si_support=0 amdgpu.si_support=1. To test whether this is, you can strike the E key at the Grub menu and add them to the end of the (probably wrapped) line that begins with linu. If this helps, they can be added to the GRUB_CMDLINE_LINUX_DEFAULT= line in /etc/default/grub. On next kernel update they will become part of /boot/grub2/grub.cfg. You can apply them immediately by running sudo grub2-mkconfig -o /boot/grub2/grub.cfg and rebooting. This should result in X using the amdgpu DDX driver instead of ATI/Radeon. If it doesn't, check to be sure xf86-video-amdgpu is installed. It is a standard part of most installations to systems with non-ancient AMD graphics.
[OT] Your Leap partition on sda2 is formatted BTRFS and only 30GB. To use such a small partition with BTRFS will take considerable care on your part to avoid having the filesystem fill to capacity as time goes on. You'll need to configure snapshotting to not save an excessive number before discarding older ones, and ensure personal files of any size are kept on your sda1 data filesystem. You would almost certainly be better off repartitioning and reinstalling to give Leap considerably more space than 30GB. Alternatively, it would probably be easier to maintain adequate freespace on the existing 30GB partition by reinstalling Leap using EXT4 instead of BTRFS.
Long term you should consider using UEFI booting and GPT partitioning on your Haswell Asus, for both Windows and Linux. This is the preferred way to use Windows 10. One reason is that it makes less likely that Windows would do something to cause you to be unable to boot Linux at all. UEFI is considerably more sophisticated than legacy MBR/CSM booting. Because of the immediate problem, it might be best to do this now.
New or Quiet Penguin
Originally Posted by malcolmlewis
Hi
Is the system BIOS the latest? Could try some acpi boot options (YaST -> Bootloader -> Kernel Parameters) and add;
Ok thanks, I am going to add that row in kernel parameters, I'll let you know.
Originally Posted by mrmazda
Because you wrote "Sometimes during boot phase", I am suspicious you do not have Windows fast boot disabled. Please paste here using code tags the content of file /etc/fstab.
I cannot parse this:It's still ambiguous what "doesn't boot" means.
Where is the "picture"?
You may be able to enjoy better graphics behavior by editing Grub to contain these additional parameters: radeon.si_support=0 amdgpu.si_support=1. To test whether this is, you can strike the E key at the Grub menu and add them to the end of the (probably wrapped) line that begins with linu. If this helps, they can be added to the GRUB_CMDLINE_LINUX_DEFAULT= line in /etc/default/grub. On next kernel update they will become part of /boot/grub2/grub.cfg. You can apply them immediately by running sudo grub2-mkconfig -o /boot/grub2/grub.cfg and rebooting. This should result in X using the amdgpu DDX driver instead of ATI/Radeon. If it doesn't, check to be sure xf86-video-amdgpu is installed. It is a standard part of most installations to systems with non-ancient AMD graphics.
[OT] Your Leap partition on sda2 is formatted BTRFS and only 30GB. To use such a small partition with BTRFS will take considerable care on your part to avoid having the filesystem fill to capacity as time goes on. You'll need to configure snapshotting to not save an excessive number before discarding older ones, and ensure personal files of any size are kept on your sda1 data filesystem. You would almost certainly be better off repartitioning and reinstalling to give Leap considerably more space than 30GB. Alternatively, it would probably be easier to maintain adequate freespace on the existing 30GB partition by reinstalling Leap using EXT4 instead of BTRFS.
Long term you should consider using UEFI booting and GPT partitioning on your Haswell Asus, for both Windows and Linux. This is the preferred way to use Windows 10. One reason is that it makes less likely that Windows would do something to cause you to be unable to boot Linux at all. UEFI is considerably more sophisticated than legacy MBR/CSM booting. Because of the immediate problem, it might be best to do this now.
I double checked the WIndows Fast Startup option and actually it was enabled. I unchecked that field.
I put the amdgpu parameter - I thought it was already enabled having xf86-video-amdgpu installed.
For the UEFI boot, should I choose UEFI USB PEN in boot priority when I put the USB pen with OpenSUSE for its installation?
При переходе на 5.6 после выхода из саспенда dmesg спамит, и много чего перестаёт работать:
На 5.5 такого не было.
Куда деваться то со своим «старым» (P8Z68) железом?
Куда деваться то со своим «старым» (P8Z68) железом?
На свалку. У меня на лаптопе еще не такое происходить стало со временем, и всем пофиг на мои баг-репорты. Так что либо придумывай собственные костыли, либо меняй железку.
Как? i7-2600K на свалку?
Разбить? Пол-литру!? Вдребезги? Да я тебя!
не знаю про i7, но на i5 2400 даже сайты уже притормаживают, а на всяком дне типа i5 2410m не стесняясь тормозят в полную силу.
Зачем ты суспендишь десктоп?
ryzen 5 2600/b450 aorus elite
это появилось на 5 ядре, на 4.xx (точно не помню на каком именно), такого не было
У 2600K райзены первого поколения по синглкору посасывают, тащемт.
Я даже растерялся… А почему бы мне его не суспендить?
Каждый день пользуюсь. Наверное, чтоб просто клацнуть кнопкой и сразу начать пользоваться?
Если его не суспендить тоже можно просто сразу пользоваться, лол.
Предлагаешь не выключать?
Ну а сколько он там жрёт? В простое частота падает до 800мгц или сколько там.
Нет, конечно. Это пока «нытик-тред».
оставайся на 4.19
Могут сказать точно, что жрёт 80+ Ватт, так он ещё и не бесшумный.
а есть вообще разумный довод использовать максимально свежее ядро ?
А лучше обновится до Darwin Kernel Version 19.4.0
Deleted ( 07.04.20 10:55:49 )
Последнее исправление: Deleted 07.04.20 10:56:31 (всего исправлений: 1)
а есть вообще разумный довод использовать максимально свежее ядро ?
Вообще, конечно, нет.
_GTF - acpi функция переводящая (s)ata порт в состояние по умолчанию (или просто - инициализация).
DSSP - это какой-то флаг, на который ссылается эта функция, и который не установлен. Баг acpi/bios.
Скорее всего, в предыдущих версиях ядра из-за жалоб на эту ошибку, эта функция не вызывалась, а ядро само инициализировало sata-порты (сделали заглушку для конкретной материнки). После очередной чистки кода от старья эту заглушку выкинули и честно дергают acpi-функцию
Если нет проблем с дисками, то эту ошибку можно игнорировать.
Если нет проблем с дисками, то эту ошибку можно игнорировать.
Смотря что считать за проблему с дисками, точно есть проблемы с кедами, последний раз начали крашится ksshaskpass и system settings и может ещё что, обратил внимание только на это, ну и общая отзывчивость системы падает - в этом плане проблемы с дисками несомненно есть.
Ты привел только одну ошибку. И эта acpi-функция в основном простая заглушка, которая ничего не делает, максимум установит еще какой-нибудь флаг, ничего не значащий для работающей системы, чисто внутренняя для acpi, что типа порт инициализирован.
Думаю, у тебя скорее всего поломалось где-то в другом месте. Иначе у тебя при нормальном старте (не пробуждении из suspend) так же глючила система из-за дисков.
Думаю, у тебя скорее всего поломалось где-то в другом месте.
Всё может быть. Но мне кажется, что это всё-таки в ядре дело. На 5.5 не глючит так после выхода из сна.
Куда деваться то со своим «старым» (P8Z68) железом?
Ладно со старым, у меня с новым за последний год дважды спящий режим ломали.
глючит так после выхода из сна.
Это нормальное состояние вплоть до того, что при смене минорной версии (версиии патча) могут поломать засыпание. Потому что это неважная часть линукса, могут глобально перелопатить логику засыпания между патчами с соответствующими последствиями.
Купи себе модный (китайский) ноутбук/нетбук/планшет - будет что припомнить, что забывать не будешь успевать :)
Кто-то еще выключает компьютеры, кроме тех, кто собирает шумные ящики?
ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20190703/psargs-330)
- саспенды всегда работали, работают, будут работать с линуксами через одно место. Проще не использовать, тем более, еcли у тебя корабасный десктоп. Выключай на ночь и нормально.
Так было и так будет всегда: кривые, не соответствующие стандартам прошивки на платах Asus. Поэтому в ядре фиксить это никогда не будут.
Впрочем, они почти везде кривые в потребительском железе. Из того, что можно купить за разумные деньги «для дома, для семьи» – только с Supermicro не бывает проблем. Ну, или смотрите списки сертифицированного оборудования, например, redhat.
Как я понимаю ты позорище опенсорса имеешь ввиду сайты как браузер, а не как сервер?
Как сервер www, ppp, ftp, samba, dns, router, и ррочая и прочая даже первый пень до сих пор работоспособным будет.
(и особенно первый, второй и третий пни, так как у них биос в съёмном ПЗУ, а не на флеше, их сейчас как золото беззондовое хранить нужно)
torvn77 ★★★★★ ( 07.04.20 13:10:29 )
Последнее исправление: torvn77 07.04.20 13:14:40 (всего исправлений: 3)
Debian. 4.19.0-5-amd64. UEFI (без опции Legaсy Bios). Acer A315-41-R8XR. AMD Ryzen™ 5 2500U. Radeon™ Vega 8.
Пытаюсь разобраться со всеми ошибками перед тем, как начать настраивать проброс видеокарты в kvm. На форуме acer пишут прописать в grub acpi=off, но лучше найти адекватное решение.
Что то не работает? С acpi-off ноутом невозможно будет пользоваться
Не только ноутом, любой железкой.
" - Доктор у меня болит голова…
- Ампутировать батенька. Немедленно ампутировать её полность. "
init_6 ★★★★★ ( 03.08.19 05:58:51 )
Последнее исправление: init_6 03.08.19 05:59:14 (всего исправлений: 1)
чем мешает/что не работает?
добавь в параметры ядра при загрузке acpi_osi="Windows" (возможно «Windows 2016» или «Windows 2018» или как-там сейчас принято — гугл в помощь)
P.S. Acer просто не приветствует установку других (linux based) OC на свои устройства. Возможно это требует от них «ненужных затрат».
anymouze ★★ ( 03.08.19 08:51:16 )
Последнее исправление: anymouze 03.08.19 08:53:29 (всего исправлений: 1)
Вроде бы пишут, что начиная с 4.19 есть драйвера на AMD Ryzen 5 2500U с Radeon Vega 8. *Не смогу решить, поставлю Arh обратно, посмотрю что в 5.2.5 есть.
- dmesg без ошибок?
- нет, не встречал.
// другое дело, что не все из них проявляются мешают
хочу пробросить видеокарту на ноутбуке (!с одной видеокартой поддерживающей AMD-Vi IOMMU) в гостивую windows
Кому нужно больше одного ядра одного потока в процессоре? Конечно добавляй.
ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
Это ядро предупреждает, что будет мимикрировать под windows и будет игнорировать запросы на то, что оно(ядро) является «Linux».
ACPI BIOS Error (bug): Failure creating [_SB.PCI0.LPC0.EC0._Q46], AE_ALREADY_EXISTS (20180810/dswload2-316)
А это явный баг acpi, возможно, специально занесенный.
ACPI BIOS Error (bug): Could not resolve [_SB.PCI0.GPP2.BCM5], AE_NOT_FOUND (20180810/dswload2-160)
Это тоже баг, скорее всего, не критичный. Обычно методы BCM_ (расшифровывается Brightness Control Method) - это алгоритм управления яркостью экрана. Если тебе не повезло, то у тебя не управляется яркость экрана, или просто твоя «очередная китайская подвальная сборка» использует другую партию экрана с другим управлением ярксотью, не предусмотренным в acpi. Но тебе может повезти, по стечению обстоятельств работает без всех этих замудреднных acpi методов.
А это явный баг acpi, возможно, специально занесенный.
Все баги acpi и эти вышеозвученные и все остальные от одной простой штуки - подсистему acpi ядра linux разрабатывали по официальным спецификациям а BIOS/UEFI для железа нет. И да в говновендазе для обхода всех этих ям и ловушек много своих подпорок и костылей которые делают вид что в целом всё нормально.
Ну вот взял бы и накатал в своем говнобложике эту инфу с подробностями и различными решениями по этой теме . Это же болючая тема , многих интересует .
подсистему acpi ядра linux разрабатывали по официальным спецификациям
Причем тут реализация acpi в linux, если здесь явно ошибка в acpi - повторное объявление.
Все баги acpi и эти вышеозвученные и все остальные от одной простой штуки .
.. ACPI - это очень неудобный язык (api) конфигурирования и нет нормальной среды для разработки. Еще усугбляется тем, что есть циклы - щас бы писать конфигурации на тьюринг полных языках.
Ну вот взял бы и накатал в своем говнобложике эту инфу
Это очевидно и не требует описания в любом говнобложике.
Причем тут реализация acpi в linux, если здесь явно ошибка в acpi - повторное объявление.
Причем здесь повторное объявление в чьём то говняном dsdt если корень прблемы в том, что «подсистему acpi ядра linux разрабатывали по официальным спецификациям а BIOS/UEFI для железа нет»?
ACPI это вся спецификация целиком а крайне неудобный язык это DSDT (Differentiated System Description Table).
Ясно. Ошибка не в ошибке, а в том что мы не знаем как обойти ошибку. А обойти ошибку можно блобами с bios/uefi для железа. Мы же за проприертарные решения. Зачем нам открытые решения на открытых спецификациях, когда видно кто и где ошибся?
ACPI это вся спецификация целиком а крайне неудобный язык это DSDT (Differentiated System Description Table).
DSDT - это всего лишь одна из таблиц, содержащая байт-код на AML (acpi machine lang). Наошибаться можно и в других местах.
Ошибка не в ошибке, а в том что мы не знаем как обойти ошибку.
Я предпологаю что все дело либо в компиляторе или в индусах особокомпетентных гражданах занимающихся сборкой и установкой проприетарных биосов у вендоров.
Наошибаться можно и в других местах.
Можно. Но чаще всего ошибки вылазят именно в dsdt.
Я предпологаю что все дело либо в компиляторе или в индусах особокомпетентных гражданах
Еще раз. Даная конкретная ошибка не из-за компилятора. Эта ошибка именно из-за сложности acpi (для придирчивых, из-за aml). При этом нет облегчающих написание aml-кода инструментов. Его пишут практичеси методом копи-пасты и инклудов копи-пасты. Там даже лауреат премии Тьюринга не сможет написать коректный код. Потому и занимаются этим неблагодарным делом «особокомпетентные граждане». А там куда кривая эволиции приведет, или докопипастят до более-менее рабочего состояния, или сгинет в конкурентной борбе багов и жучков.
После чего, поставил arch с ядром 5.2.7
Значит говно такая спецификация, если она существует в воображаемом мирке, а не описывает реальное железо.
Значит говно такая спецификация, если она существует в воображаемом мирке, а не описывает реальное железо.
anonymous да тебе никто не запрещает жить в том же воображаемом мирке. А реальность такова - вендоры зачастую кладут на специфкации и для корректной работы ядра на конкретно взятой железяке (комбинации железяк) зачастую требуется локальная доработка напильником.
Реальность такова, что есть только реальное железо, а твоя спецификация это даже не бумажка, которой подтереться. Место таких спецификаций обычно занимают описывающие реальное железо, нужно понимать у майкрософта есть своя, используемая вендорами железа. Но необучаемые всё продолжали выдумывать оправдания и наступать на те же грабли.
У тебя есть конкретные предложения? Пиши в lklm. А вот так же заниматься демагогией может кто угодно.
В lkml уже всё порешали, копируя поведение венды, например поддерживая вендовый wmi. Остаётся разобраться с лоровскими демагогами.
Остаётся разобраться с лоровскими демагогами.
Лоровские демагоги вообще зачастую без понятия о предмете разговора. Так что ну ты понял…
since upgrading to 5.12 i'm getting this error spamming dmesg / journalctl:
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR01._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR02._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR03._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR04._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR05._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR06._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR07._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR08._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR09._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR10._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR11._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR12._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR13._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR14._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR15._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR16._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR17._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR18._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
May 05 13:58:02 linux64 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20210105/psargs-330)
May 05 13:58:02 linux64 kernel: ACPI Error: Aborting method \_SB.PR19._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529)
never had these on 5.11, 5.10, 5.9, etc. system appears to be running fine. just don't know what they're about. i'm assuming its harmless.
What is your specific PC/motherboard? Output of `inxi -Fz` or a similar tool would be useful.
If there is no impact on functionality, I would ignore it.
i'm using a msi z490 unify, intel core i9, and a amd 6900xt. i do have the latest motherboard bios available installed. there is a beta version i could try though they only list "- Optimize Resizable BAR (Re-Size BAR) function" in its release notes.
hmmm seems like a lot of people are having issues with 5.12. on reddit a few people replied back to my comment i left on /r/archlinux about 5.12 hitting stable saying they are getting acpi issues with 5.12 too. seems like they did some big changes with acpi in 5.12.
i'll give the beta bios a try to see if that does anything. if not i'll probably just drop back to 5.11 to be safe. see if i can file a bug on bugzilla.
ACPI BIOS Error (bug): Could not resolve symbol [\_SB._OSC.CDW1] After Upgrading to LM20
ACPI BIOS Error (bug): Could not resolve symbol [\_SB._OSC.CDW1] After Upgrading to LM20
Post by newgreen » Fri Jul 10, 2020 6:26 pm
Newbie needing help after upgrading from Linux mint 19.3 to Linux Mint 20
Issue while booting
Dual boot Win 7 / Linux Mint 20 system
Followed upgrade instructions,
After upgrade to LM20, system boots, Grub boot select screen appears
After pressing enter key on keyboard to select Linux mint 20, I get the following message on the screen (see below). Message repeats 3 times dimmer each time for a total of about 8 seconds or so and then Linux mint 20 starts normally.
Does anyone know what this message even mean and how to fix this?
Any help with this would be appreciated.
Post by arvy » Fri Jul 10, 2020 6:56 pm
ACPI errors of that nature abound in various OEM implementations and they are generally harmless apart from the (usually brief) "hiccup" during the start-up process. See here for just a few other examples and here. Their "meaning" is often nothing more than just a quick report of OEM sloppiness and, unless they give rise to some actual operational problems, they seldom get corrected by firmware updates. LM 20's default config seems to make them somewhat more visible than its predecessor. If you want to pursue the issue in greater depth, see Debugging ACPI.
System: Asus ROG Maximus XI Code mobo, Intel i9-9900K CPU, Nvidia GTX1080 GPU, 32 GB DDR4-3600 RAM, Sumsung Pro 2x512GB NVMe & 3x1TB SSD, Multiboot
Post by newgreen » Fri Jul 10, 2020 7:17 pm
Thanks for the info, but this problem wasn't there before the upgrade to LM20. I was running LM19.3 with most up to date kernel and latest updates with no boot issues. After the upgrade to LM20, now this appears; very strange. If this was a real firmware or BIOS problem, I would expect the issue to be there with previous versions of Linux Mint, which it wasn't. Something to do with the upgrade to LM20, what, I don't know.
Post by arvy » Fri Jul 10, 2020 7:30 pm
Well, if you choose to believe that your system's ACPI BIOS error was actually created or falsified (rather than just more aggressively detected and reported) by LM 20, I suppose there's no real substantive harm in that either. I've told you where to find debugging information if you want it.
System: Asus ROG Maximus XI Code mobo, Intel i9-9900K CPU, Nvidia GTX1080 GPU, 32 GB DDR4-3600 RAM, Sumsung Pro 2x512GB NVMe & 3x1TB SSD, Multiboot
Post by newgreen » Fri Jul 10, 2020 8:09 pm
I will look into the links you provided, but I'm still in the dark as to the meaning of [\_SB._OSC.CDW1] or any of it for that matter. I would think the first step to diagnosing a problem would be to understand what the error message means? is "CDW1" referring to the built-in CD/DVD drive? Any idea as to the meaning of any part of the error message?
Post by arvy » Fri Jul 10, 2020 9:47 pm
You're making a mountain out of a molehill, but if you insist -- \_SB._OSC is used to convey platform-wide OSPM capabilities (a term defined in the ACPI specification) to the platform firmware for power management purposes, more specifically in order to meet firmware requirements for the D3cold power sub-state. More than you ever wanted to know (or certainly more that I ever wanted to know) about the technical details of device power management and its firmware requirements can be found here according to Microsoft's self-proclaimed "expertise" on the subject.
System: Asus ROG Maximus XI Code mobo, Intel i9-9900K CPU, Nvidia GTX1080 GPU, 32 GB DDR4-3600 RAM, Sumsung Pro 2x512GB NVMe & 3x1TB SSD, Multiboot
Post by newgreen » Fri Jul 10, 2020 11:12 pm
I do like to try and at least have some basic understanding of what's going on, so I thank you for the info you provided. Further, I did look at the links you provided and I'll dig a little deeper into the pages you provided. If I'm unable to resolve the actual error message/system hang, do you know of a way to suppress or 'MUTE" / bypass the checking and reporting of this error so as:
1) it doesn't slow down the boot time by 8 seconds
2) it doesn't display it.
Ideally, I'd like to eliminate this by way of editing the code in a file without messing up the Grub dual boot menu at boot time?
As I mentioned before, I had installed a couple of prior versions of Linux Mint and have never experienced any 8 second hang or error messages at boot time. It goes beyond just an error message when the system hangs for 8 seconds and boot time is slowed down. I have Linux Mint 19.3 on another machine and for now, I'll stick with that.
In my view, whatever the reason for this, if other versions of Mint can suppress/overcome/not check for this and not hang the system at startup, it makes LM20 boot process look and feel very sloppy. If this error is of little significance to the working of the OS, then I don't want LM20 to hang the system to check for this error. On the other hand, if this error is of significance with it's implications currently unknown or unclear to me, then a fix is required to fix this.
Thanks for the several replies you posted!
Post by arvy » Fri Jul 10, 2020 11:39 pm
Well, did you try any of the kernel loading parameters suggested in that debugging link that I gave you? The first one ("acpi=off") will confirm that it really is (or isn't) an ACPI issue and, if it is, you can narrow it down from there.
System: Asus ROG Maximus XI Code mobo, Intel i9-9900K CPU, Nvidia GTX1080 GPU, 32 GB DDR4-3600 RAM, Sumsung Pro 2x512GB NVMe & 3x1TB SSD, Multiboot
Post by newgreen » Sat Jul 11, 2020 4:01 am
Yes, after pressing "e" key on my keyboard while at at the Grub menu screen, another screen appeared. I used my down arrow key to go to the "Linux" line, and at the end of the line, I added the following:
After some seconds at that error message, the boot sequence continued and Linux Mint 20 appear to start normally.
"Dazed and confused but trying to continue" ? I think I'm a little "Dazed and confused but trying to continue" to solve this problem, if I can add a little humour to this
Anyway, no further along on this at this point.
Post by arvy » Sat Jul 11, 2020 6:13 am
I'm sorry, but you said that you wanted to pursue the issue and so I've given you a link to the debugging procedures that will let you do that. Each one of them explains, at least briefly, its own significance and it's up to you to draw the appropriate logical conclusions as applicable to your case. The first one ("acpi=off") is not intended to be regarded as any kind of complete or final answer. As I said, it just confirms that the issue really does originate in your system's ACPI implementation. It has done exactly that (nothing more) based on the criteria as stated for itself (i.e., if the error is the same with ACPI enabled and disabled, this may not be an ACPI issue). So you are, in fact, that much "further along" at least.
Carry on with the other debugging procedures at your own discretion, but take careful note of what each says about itself if you want to be able to draw any useful conclusions from the exercise. And note also that none of them is actually going to fix any OEM firmware issue, although one of them may let you suppress its detection and error display without being too obtrusive in other respects.
System: Asus ROG Maximus XI Code mobo, Intel i9-9900K CPU, Nvidia GTX1080 GPU, 32 GB DDR4-3600 RAM, Sumsung Pro 2x512GB NVMe & 3x1TB SSD, Multiboot
Post by smbulius » Fri Apr 09, 2021 2:01 pm
Same problem on my PC. I installed Linux Mint, Ubuntu, Debian. In all OS is same problem (kernel 4.x to 5.x versions). I didn't try the older version of kernels >4.x.
MB: Gigabyte x299 WU8 CPU: i9 10gen. BIOS: the latest version.
Please share experiences on how this problem can be solved!
Could this be the reason that the system is not working KVM (Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled). My Linux Mint show that VT-X is Disabled, but on BIOS is enabled. Windows 10 works great, but Linux Mint dont alow VTx.
Читайте также: