LINUX.ORG.RU

Системные прерывания в Linux и как включить MSI режим для прерываний?

 , ,


1

4

Прошу помощи, если вдруг кто сталкивался или кто знает.

Объясняю то, почему мне вдруг потребовалось это узнать.

Дистрибутив - Garuda LXQt Обновления стоят, баги с pipewire исправлены.

Установлено на ноут Acer Aspire E5-575G(i3 6100U) Проблема в следующем: У меня на ноуте, почему-то, неправильно распределяются тайминги прерываний(или хз как это ещё назвать). Из-за чего процессор в ПРОСТОЕ грузится на 20%(если быть точнее - грузится в 100% один из потоков, всегда разный причём). Ведь прерывания одного из устройств выполняются программно. Я крайне долгое время думал почему так, ибо такая проблема присутствовала что на Windows, что на Linux(BSD уж не проверял, извиняйте)

В Windows - фиксилось это при помощи программки MSI Mode Utility с сайта guru3d, путём того, что на «Контроллер Аудио Microsoft» я ставил режим прерываний MSI. В Linux же - я без единого понятия как перевести устройство в режим MSI и как точно определить какое устройство является источником проблемы…



Последнее исправление: FaRa (всего исправлений: 1)

Смотреть прерывания — в файле /proc/interrupts. Включить msi можно либо передав параметр модулю (если это предусмотрено), либо через параметры загрузки ядра, если модуль статически вкомпилён. Например для моей звуковой карты msi включается параметром enable_msi для модуля snd_hda_intel. Узнать какие параметры у модуля можно командой modinfo имя_модуля. Вангую что если тебе в винде включение msi для звуковухи помогало то и тут оно поможет. По умолчанию msi отключено для некоторых звуковых встроек, так как они с ним пердят. Попробуй включить.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

А как передать параметр модулю…?

Имя моей звуковухи - примерно как и у вас.

Приношу извинения за свои затупки, но в Linux для меня с таким копаться в новинку… Но крайне хочется наладить систему, чтобы всё было норм.

FaRa
() автор топика
Ответ на: комментарий от FaRa

Я не знаю как это делается в твоём дистрибутиве. В моём это делается через создание в каталоге /etc/modprobe.d конфига snd_hda_intel.conf c содержимым

options snd_hda_intel enable_msi=1

Сработает после перезагрузки.

PS. А, Garuda это Arch же. Да, я всё верно написал, https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture/Troublesho... подтверждает. На то что раздел про микрофон внимания не обращай, важно что там msi включают. Использование в имени конфига и модуля «_» или "-" разницы не имеет, работает и так, и так, просто я к «_» привык, а тот кто статью писал к "-".

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от FaRa

Не факт что это вообще прерывания виноваты. Ты так думаешь, но это далеко не факт. И вообще они уже давно не выполняются настолько «программно» как в старых книжках про x86 написано. Выложи содержимое /proc/interrupts, только языком разметки сообщений воспользуйся, а то пост в кашу нечитаемую превратится. Или на pastebin запости, а тут ссылку выложи.

БИОС обновлён до самой свежей версии? Если нет - обнови. Используется UEFI или Legacy Boot Mode? У некоторых Асеров были проблемы с прерываниями в Legacy режиме.

Ещё выложи выхлоп команды dmesg на pastebin и ссылку сюда, это лог загрузки ядра, хотелось бы его тоже увидеть.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 3)
Ответ на: комментарий от Jameson

Такая проблема с прерываниями у меня и в Legacy, и в UEFI режиме, так что от этого не зависит.

BIOS - обновлён до последней версии. Ещё у меня есть TPM, я читал, что из-за него могут быть проблемы… Раньше на экран вылазило что типа Disabling IRQ16. Я его отключил - перестало.

А так-то - система стоит на HDD в Legacy режиме на MBR На SSD в GPT - стоит Windows.

proc/interrupts - https://pastebin.com/4xjieaHs sudo dmesg - https://pastebin.com/bX95KPpY

FaRa
() автор топика
Ответ на: комментарий от FaRa

Ну вот с 16 прерыванием по прежнему проблемы, судя по

16:          0          0   14541756          0  IR-IO-APIC   16-fasteoi   idma64.0, i2c_designware.0, i801_smbus

Судя по ядерной багзилле у тебя шторм на 16 прерывании из за тачпада. Это баг, https://bugzilla.kernel.org/show_bug.cgi?id=215533, пишут что в свежих ядрах исправлен, но видимо для тебя — нет. Баг связан с кривым БИОС. По хорошему надо в ядрёную багзиллу жаловаться. Если единственное что тебя смущало при включённом TPM — ругань на отключенное 16 прерывание — включи TPM снова, видимо ядро не зря 16 прерывание выключало.

Ещё можно попробовать отключить прерывания для i801_smbus, создай /etc/modprobe.d/i2c-i801.conf и в нём скажи

options i2c-i801 disable_features=0x10

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

https://forum.garudalinux.org/t/high-single-core-cpu-usage-due-to-large-inter...

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

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 3)
Ответ на: комментарий от Jameson

Ваше предложение не сработало... Процессор всё так же грузится на 20% в простое...

TPM включил Конфиг прописал

В WIndows, кстати, аудио контроллер был как-раз таки на 16-ом прерывании. После перевода в MSI - становится на -8 вроде(лень смотреть, да и роли не играет)

Однако система стала работать как-то шустрее. Ввод пароля на экране входа больше не имеет импут-лаг при вводе первого символа, а в ютубе теперь возможно смотреть 1080p60(до этого 720p60 шло с кряхтением)

Но это ведь не полноценное решение проблемы... Вы сказали, что проблема может быть в тачпаде, верно? Может мне попробовать его перевести в MSI режим...? Или вовсе отключить его в Linux, я им не особо-то и пользуюсь в нём, да и в Windows редко.

FaRa
() автор топика
Ответ на: комментарий от Jameson

Что забавно, кстати…

Вы говорите, что баг был исправлен в новых ядрах, ОДНАКО! В моём случае - этот баг ПРИШЁЛ с новым ядром!

Собственно потому я и пересел на винду, а сейчас решил попробовать вернуться и выбрал Garuda.

Помню ставил Chakra, где было ядро 4.7 или 4.17(честно, не помню, но что-то связанное с цифрой 7) - там нагрузка на процессор в простое была 0%, как и должно быть. Однако софт на такое древнее ядро не ставился: ни AUR, ни обновления pacman… Ни-ча-го!

Чакра - на данный момент мёртвый, но он был основан на арче, как уже можно было понять.

FaRa
() автор топика
Ответ на: комментарий от FaRa

Ну... Этот баг многослойный и связан с кривыми БИОС. Он всплыл как регрессия в 5.16 ЕМНИП, вызвавший регрессию патч откатили, но корень проблем пофикшен не был. Тем у кого он всё равно всплывает несмотря на откат рекомендуют завести новый баг в ядрёной багзилле, так как формально откат пофиксил неправильное поведение у тех кто баг зарепортил. Так что те кому не помогло должны продолжать писать в Спортлото. Вообще жалоб на шторм тачпада в асерах в инете много и судя по всему это проблема асеровских БИОС.

Jameson ★★★★★
()
Ответ на: комментарий от FaRa

TPM включил Конфиг прописал

Вот ты зря делаешь ВСЁ и СРАЗУ. Например если ядро при включённом TPM вырубило штормящее 16 прерывание - можно и не отключать его в конфиге для i2c-i801, так как прерывания наверняка по другому распределились. И вообще, i801 тут ни при чём, так как корень проблем в тачпаде. Просто поскольку это всё на одном прерывании висит и управлять прерываниями тачпада я не знаю как — я сделал предположение что можно «поиграть» с прерываниями i801, так как для него modinfo показывает наличие некоей feature 0х10, которая судя по комментарию связана с прерываниями.

На будущее, не стучи по всем кнопкам сразу одновременно, в том числе головой, попробуй что то ОДНО, посмотри на результат, потом ДРУГОЕ, и только потом СОЧЕТАНИЯ одного и другого. Иначе ты получишь хаос и бардак.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

И так. Проблему до конца я не решил, но смог снизить нагрузку на процессор на целых 7%. Отзывчивость системы стала гораздо лучше.

Чтобы добавить модуль(ну я добавил драйвер, если ничего не попутал) в чёрный список - надо создать параметр в etc/default/grub
Который выглядит следующим образом: GRUB_CMDLINE_LINUX_DEFAULT=«initcall_blacklist=dw_i2c_init_driver»

После чего выполнил

sudo update-grub

И перезагрузил систему

FaRa
() автор топика