ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
Здравствуйте! Это мой первый топик на данном форуме, поэтому за оформление прошу строго не наказывать. В общем проблема в том, что мне нужно пофиксить ACPI-таблицы из-за присутствия в них багов. Так как опыта в этом нет, прошу помочь гуру из этого форума. BIOS обновлён до последней версии. Не нашёл как прикрепить файлы к топику, поэтому выложил все ACPI-таблицы https://spac1.me/files/index/XopmoH/7926880/ . Вот некоторая информация о системе и ACPI:
Буду очень благодарен за помощь! 🙂
Это мой первый топик на данном форуме, поэтому за оформление прошу строго не наказывать
Да у тебя ещё «по-божески» оформлено. Читать и не ломать глаза можно.
нужно пофиксить ACPI-таблицы из-за присутствия в них багов
Как баги проявляются? Чем мешают? Пробовал вместо Linux указывать «Windows 20..» (точно не скажу, какой именно год указывать — подобрать возможно) — проблемы не решает?
призываем SakuraKun
Багов нет. Вопрос в чем? Если в:
ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
То это просто информация, что acpi имеет разную логику, если ему сообщают, что это «Linux» или что-то другое. То есть биос/acpi умышленно работает по разному для разных операционных систем. Но линукс это игнорирует и будет прикидываться расово верной операционной системой (в простонародье — windows). А логику биос/acpi должен исправлять (может исправить) только производитель.
Не очень интересно копаться в кривой проприетарщине, поэтому предлагаю ТС универсальное решение: сменить комп на поддерживаемый опенсорсным BIOS-ом coreboot ( https://coreboot.org/status/board-status.html ) и прошить его туда — по крайней мере с ACPI у коребута всё в порядке. Ну или обратиться на форум https://www.bios-mods.com/ , там с бОльшей вероятностью помогут.
логику биос/acpi должен исправлять (может исправить) только производитель
Должен — но зачастую не хочет / не может, т.к. после этой модели он выпустил ещё 100500 а индусов клепать биосы ограниченное количество и на всё не хватает. Вот и приходится людям самостоятельно в hexeditor ручками править.
биос/acpi умышленно работает по разному для разных операционных систем
Мельком посмотрел твой dsdt. Как пример, отдается разная таблица яркости экрана. По мне, это обыкновенная диверсия.
Источник
ACPI Bug
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 ноутом невозможно будет пользоваться
Не только ноутом, любой железкой.
» — Доктор у меня болит голова…
— Ампутировать батенька. Немедленно ампутировать её полность. «
чем мешает/что не работает?
добавь в параметры ядра при загрузке acpi_osi=»Windows» (возможно «Windows 2016» или «Windows 2018» или как-там сейчас принято — гугл в помощь)
P.S. Acer просто не приветствует установку других (linux based) OC на свои устройства. Возможно это требует от них «ненужных затрат».
Тут дело такое, хочу пробросить видеокарту на ноутбуке (!с одной видеокартой поддерживающей AMD-Vi IOMMU) в гостивую windows. Перед тем, как приступить к этому, пытаюсь все ошибки исправить.
Вроде бы пишут, что начиная с 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-кода инструментов. Его пишут практичеси методом копи-пасты и инклудов копи-пасты. Там даже лауреат премии Тьюринга не сможет написать коректный код. Потому и занимаются этим неблагодарным делом «особокомпетентные граждане». А там куда кривая эволиции приведет, или докопипастят до более-менее рабочего состояния, или сгинет в конкурентной борбе багов и жучков.
На archlinux.org написанно, что подобная проблема возникает из-за ядра версии 4.19.
После чего, поставил arch с ядром 5.2.7
Значит говно такая спецификация, если она существует в воображаемом мирке, а не описывает реальное железо.
Значит говно такая спецификация, если она существует в воображаемом мирке, а не описывает реальное железо.
anonymous да тебе никто не запрещает жить в том же воображаемом мирке. А реальность такова — вендоры зачастую кладут на специфкации и для корректной работы ядра на конкретно взятой железяке (комбинации железяк) зачастую требуется локальная доработка напильником.
Реальность такова, что есть только реальное железо, а твоя спецификация это даже не бумажка, которой подтереться. Место таких спецификаций обычно занимают описывающие реальное железо, нужно понимать у майкрософта есть своя, используемая вендорами железа. Но необучаемые всё продолжали выдумывать оправдания и наступать на те же грабли.
У тебя есть конкретные предложения? Пиши в lklm. А вот так же заниматься демагогией может кто угодно.
В lkml уже всё порешали, копируя поведение венды, например поддерживая вендовый wmi. Остаётся разобраться с лоровскими демагогами.
Остаётся разобраться с лоровскими демагогами.
Лоровские демагоги вообще зачастую без понятия о предмете разговора. Так что ну ты понял…
Если узнаете, что делать с ошибкой, дайте знать.
Источник
Gentoo «ACPI: BIOS _OSI(Linux) query ignored»
Доброго времени суток
Имеется ноут Asus k52jv. Поставил Gentoo и Win7 (подпиливал grub). Грузится нормально, все работает (вроде как :)).
При загрузке, сразу после выбора ОСи в Грубе, Гента мельком показывает какое-то сообщение, которое сразу исчезает — никак не успеваю прочитать, что там такое (что-то связанное с файловой системой, вроде).
Посему полез смотреть dmesg, вот чего насмотрел: http://paste.pocoo.org/show/488356/
1) [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored — щито это такое и как с ним бороться (и нужно бороться ли?)
2) ну, коль речь зашла о проблемах — что делать с jme 0000:04:00.5: eth0: UDP Checksum error ? Интернет используется кабельный, от роутера. DHCP добавлен в автостарт.
И по первому, и по второму вопросу гугл толком ничего не подсказал, посему решил объеденить оба вопроса тут.
>BIOS _OSI(Linux) query ignored — щито это такое
What is OSI and how is it used
OSI is an ACPI method provided by the operating system that can be invoked by ACPI BIOS code. It is used by BIOS developers to detect which operating system is running. The method that should be used (cmp. ACPI spec[1], chapter 5.7.2 and 5.7.3) is OS, but for various reasons, OSI is used to identify recent operating systems. The intent of the OSI function is to identify features provided by the OS. For example some BIOSes check for Vista which supports and demands the latest ACPI backlight functions (compare ACPI spec Appendix B). Vendors sometimes update BIOS to use OSI to work around specific oper- ating system problems. This is very dangerous and should always be avoided. Here is an example of how a vendor wrongly fixed his ACPI BIOS implemen- tation trying to work around a Linux bug. It then broke when newer kernels were fixed after the bug got identified: http://bugzilla.kernel.org/show bug.cgi?id=7787
У dmesg как не страннно есть
Usage: dmesg [options]
Supported log levels (priorities): emerg — system is unusable alert — action must be taken immediately crit — critical conditions err — error conditions warn — warning conditions notice — normal but significant condition info — informational debug — debug-level messages
Так вот обращай внимание с какого _уровня_ идут сообщения в dmesg
Хм.. мануал пишет:
Set the level at which logging of messages is done to the console. For example, -n 1 prevents all messages, except panic messages, from appearing on the console.
Тоесть мне теперь нужно выставлять # dmesg -n 4 ребутится, и смотреть, с какого уровня ошибки? ладно 🙂
Источник