Открываю баг по ветке vulkan-amdgpu, хотя сам не до конца уверен что есть связь, так как проблема весьма специфична. Опишу ситуацию сначала издалека и по железу. Видеокарта у меня внешняя и работает в связке с мини-пк,имеющий разъем TB4/USB4. Такая связка довольно экзотична, на *nix тем более. для eGPU Прменяется плата TH3P4G3 на ней RX 7700 XT --> Кабель tb4 длиной 0.5м --> PRO DP10 13M Проблема заключалась/заключается(?) в следующем. eGPU с видеокартами от амд требует дополнительной настройки для работы, через параметры ядра для того, чтобы драйвер(?) правильно распознавал скорость слота TB4. По нему создается,как я понимаю, аппаратная виртуализация шины PCI-E (в efi этот параметр называется PCI-E over TB4 tunneling или как-то так). Но есть нюанс в пропускной способности TB4 - она четверть от полной для TB3 и дожна быть по идее в половину полноценного PCI-E и кроме того, ядро линукс или какой-то его компонент неверно распознает это соединение и сбрасывает скорость до обычного усб. Чтобы этого не происходило есть man от арча https://wiki.archlinux.org/title/External_GPU там довольно подробно рассказывается о проблеме для amdgpu, где говорится что нужно в модпроб создавать конфиг с параметром: options amdgpu pcie_gen_cap=0x40000 дабы захардкодить этот параметр ядра. Это работало на убунту с ядром 6.5 что-ли. Потом пошли обновления и этот метод по всей видимости отвалился, скорость падает, что достаточно легко понять даже по внешнему шуму дросселей (при высокой нагрузке их слышно) или программно по FPS или потребляемым ваттам (должна быть более 100 ватт при активной нагрузке, но сейчас это 20-35 ватт). Эта проблема коснулась разных дистрибутивов https://forum.endeavouros.com/t/amd-rx580-egpu-pcie-link-speed/56818 и скорее всего, касается либо самого ядра, либо компонента ядра amdgpu, либо mesa. Я готов провести тест, но не совсем уверен в ту ли ветку пишу, так как поймать конкретный компонент мне не под силу. ,что и приводит в некоторое
замешательство
Перевел на корректный компонент. Assignee пока оставлю на себя. Из того, что вижу в коде ядра 6.10: параметры на месте drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c ... 481 * DOC: pcie_gen_cap (uint) 482 * Override PCIE gen speed capabilities. See the CAIL flags in drivers/gpu/drm/amd/include/amd_pcie.h. 483 * The default is 0 (automatic for each asic). 484 */ 485 MODULE_PARM_DESC(pcie_gen_cap, "PCIE Gen Caps (0: autodetect (default))"); 486 module_param_named(pcie_gen_cap, amdgpu_pcie_gen_cap, uint, 0444); 487 488 /** 489 * DOC: pcie_lane_cap (uint) 490 * Override PCIE lanes capabilities. See the CAIL flags in drivers/gpu/drm/amd/include/amd_pcie.h. 491 * The default is 0 (automatic for each asic). 492 */ 493 MODULE_PARM_DESC(pcie_lane_cap, "PCIE Lane Caps (0: autodetect (default))"); 494 module_param_named(pcie_lane_cap, amdgpu_pcie_lane_cap, uint, 0444); и defines из заголовочного файла: /* Following flags shows PCIe link speed supported in driver which are decided by chipset and ASIC */ #define CAIL_PCIE_LINK_SPEED_SUPPORT_GEN1 0x00010000 #define CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2 0x00020000 #define CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3 0x00040000 #define CAIL_PCIE_LINK_SPEED_SUPPORT_GEN4 0x00080000 #define CAIL_PCIE_LINK_SPEED_SUPPORT_GEN5 0x00100000 #define CAIL_PCIE_LINK_SPEED_SUPPORT_MASK 0xFFFF0000 #define CAIL_PCIE_LINK_SPEED_SUPPORT_SHIFT 16 /* Following flags shows PCIe link speed supported by ASIC H/W.*/ #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_GEN1 0x00000001 #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_GEN2 0x00000002 #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_GEN3 0x00000004 #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_GEN4 0x00000008 #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_GEN5 0x00000010 #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_MASK 0x0000FFFF #define CAIL_ASIC_PCIE_LINK_SPEED_SUPPORT_SHIFT 0 ... /* Following flags shows PCIe lane width switch supported in driver which are decided by chipset and ASIC */ #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X1 0x00010000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X2 0x00020000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X4 0x00040000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X8 0x00080000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X12 0x00100000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X16 0x00200000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_X32 0x00400000 #define CAIL_PCIE_LINK_WIDTH_SUPPORT_SHIFT 16 я думаю в вашем случае нужно создать файл с содержимым options amdgpu pcie_gen_cap=0x40000 в /etc/modprobe.d/amd-egpu-pcie-speed.conf потом запустить от рута команду make-initrd, перегрузиться и проверить снова. Как быстро проверить - приложить сюда файл journalctl, который можно создать след. командой (от рута) # journalctl -b > journalctl 2>&1 (после этого полученный файл прикрепить сюда вложением)
Created attachment 16669 [details] вывод stdout > Journalctl
что сделано: # echo "options amdgpu pcie_gen_cap=0x40000" > /etc/modprobe.d/amd-egpu-pcie-speed.conf # make-initrd #reboot # journalctl -b > journalctl 2>&1
забыл активировать еGPU после перезагрузки. выхлоп journalctl -b > journalctl 2>&1 повторю еще раз при работе еGPU
Created attachment 16670 [details] вывод
если нужно готов сделать холодный старт с заранее активированной картой до загрузки системы: я вижу не всегда срабатывает хотплаг: не всегда подхватывается напр. LACT - пока не запустится синхронно с пк. Так что дайте знать
(In reply to Павел from comment #7) > если нужно готов сделать холодный старт с заранее активированной картой до > загрузки системы: я вижу не всегда срабатывает хотплаг: не всегда > подхватывается напр. LACT - пока не запустится синхронно с пк. Так что дайте > знать я сейчас выложил новую версию ядра lks-wks с доп. патчами от amd, сможете проверить с ней? от рута выполнить: # apt-get update # update-kernel -t lks-wks # перегрузиться с подключенной egpu снять journalctl в файл и приложить сюда. Я пока анализирую логи и уже попозже скажу что можно ещё проверить.
Обновил. Я бы протестировал сначала в каком-нибудь бенчмарке, желательно кросс-платформенном, дабы избегать прослойки трансляции в вулкан, как это делает протон, а после этого уже и в нем. сравнить результаты еще и с win. только я не очень знаком с такими в экосистеме *nix или пока ограничимся логами?
(Ответ для Павел на комментарий #9) > Обновил. > Я бы протестировал сначала в каком-нибудь бенчмарке, желательно > кросс-платформенном, дабы избегать прослойки трансляции в вулкан, как это > делает протон, а после этого уже и в нем. сравнить результаты еще и с win. > только я не очень знаком с такими в экосистеме *nix или пока ограничимся > логами? Так есть же Superposition, он кроссплатформенный. Насчет логов - я не вижу во вложениях логов с ядром 6.10.0-alt1.6.
Created attachment 16683 [details] Journalctl :6.10.6-6.10-alt1
добавил. Но вот еще небольшая проблема :нужно переключаться между дискреткой и встройкой. Superposition пошел по встройке. Видимо, пока не совсем все хорошо с этим функционалом. Есть https://github.com/hertg/egpu-switcher я не знаю, как поведет себя на этом ядре, но я думаю, что поставлю.
что то пошло не так с golang, не собрался # make build -s .... go: downloading github.com/russross/blackfriday/v2 v2.1.0 # runtime/cgo /usr/bin/x86_64-alt-linux-gcc: No such file or directory make: *** [Makefile:25: build] Error 1
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #10) > (Ответ для Павел на комментарий #9) > > Обновил. > > Я бы протестировал сначала в каком-нибудь бенчмарке, желательно > > кросс-платформенном, дабы избегать прослойки трансляции в вулкан, как это > > делает протон, а после этого уже и в нем. сравнить результаты еще и с win. > > только я не очень знаком с такими в экосистеме *nix или пока ограничимся > > логами? > > Так есть же Superposition, он кроссплатформенный. Насчет логов - я не вижу > во вложениях логов с ядром 6.10.0-alt1.6. в вложении логи загрузки с ядром kernel-image-6.10. Я просил проверить с ядром kernel-image-lks-wks. Насчет скорости подключения: ❯ fgrep 'PCIe bandwidth' journalctl fgrep: warning: fgrep is obsolescent; using grep -F авг 23 03:06:50 MiG kernel: pci 0000:03:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) авг 23 03:06:50 MiG kernel: pci 0000:05:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link) авг 23 03:06:50 MiG kernel: pci 0000:07:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link) авг 23 03:06:50 MiG kernel: pci 0000:19:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) т.е. скорость подключения PCIe x4 но полоса ограничена до 2.5 GT/s. Ограничение может быть аппаратным (например, как USB4 подключен к шине), так и ограничено где-то в BIOS.
Странно. Обновил ядро по инcтрукции. uname-r 6.10.6.-6.10-alt1; Файл во вложении вроде с времени после обновлений. Я понимаю ход вашей мысли. Почему же тогда при перекрестной проверке на win видеокарта работает на свои 150-200ватт?? Почему и раньше она работала хоть и на убунту, но примерно так же как на win?? Но у меня тестовое последнее ядро. И ситуация может быть уже совсем другой. Могу тогда выслоать через sos. Хотя вроде все правильно сделал.
(In reply to Павел from comment #12) > добавил. Но вот еще небольшая проблема :нужно переключаться между дискреткой > и встройкой. Superposition пошел по встройке. Видимо, пока не совсем все > хорошо с этим функционалом. > Есть > https://github.com/hertg/egpu-switcher > я не знаю, как поведет себя на этом ядре, но я думаю, что поставлю. я собрал пакет в сизиф, собирать ничего не нужно.
(In reply to Павел from comment #15) > Странно. Обновил ядро по инcтрукции. > uname-r > 6.10.6.-6.10-alt1; > Файл во вложении вроде с времени после обновлений. > Я понимаю ход вашей мысли. Почему же тогда при перекрестной проверке на win > видеокарта работает на свои 150-200ватт?? Почему и раньше она работала хоть > и на убунту, но примерно так же как на win?? Но у меня тестовое последнее > ядро. И ситуация может быть уже совсем другой. Могу тогда выслоать через > sos. Хотя вроде все правильно сделал. вот поэтому лучше запустить superposition и измерить потребление ещё раз (тот же nvtop должен его показать).
Да.Хотя я предполагаю, и только предположение что скорость tb4 вероятно еще и переопределяется в рантайме в зависимости от нагрузки...
Ой.. так скрипт eGPU для иксорг. Как я понимаю тут еще и нужно слезать с Wayland...
я собрал пакет в сизиф, собирать ничего не нужно https://packages.altlinux.org/ru/search/?q=egpu что-то я ничего не смог найти...
нашел https://packages.altlinux.org/ru/sisyphus/binary/egpu-switcher/x86_64/3111314328978607676
root@MiG ~]# egpu-switcher enable [info] no eGPU has been configured yet Found 2 possible GPU(s)... 1: Intel Corporation Raptor Lake-P [Iris Xe Graphics] (i915) 2: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] (amdgpu) Which one is your external GPU? [1-2]: 2 [ok] Your selection was saved to the config file [info] created egpu bootup service to autorun 'egpu-switcher switch' [ok] setup successful [root@MiG ~]#
Ожидание инструкций запуска x11. Иначе скрипт eGPU_switcher несовместим с wayland
(In reply to Павел from comment #23) > Ожидание инструкций запуска x11. Иначе скрипт eGPU_switcher несовместим с > wayland если у вас гном, то просто на этапе логина выбрать GNOME Xorg. Про другие dm не знаю.
(In reply to Павел from comment #22) > root@MiG ~]# egpu-switcher enable > [info] no eGPU has been configured yet > > Found 2 possible GPU(s)... > > 1: Intel Corporation Raptor Lake-P [Iris Xe Graphics] (i915) > 2: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 > XT] (amdgpu) > > Which one is your external GPU? [1-2]: 2 > > [ok] Your selection was saved to the config file > [info] created egpu bootup service to autorun 'egpu-switcher switch' > [ok] setup successful > [root@MiG ~]# кстати, убедитесь, что у вас установлена версия -alt2: $ rpm -q egpu-switcher в версии -alt1 может не работать автозапуск сервиса egpu
почему-то в регулярке alt-regular-gnome я не увидел привычной шестереночки в правом нижнем углу, где можно выбрать себе графический стэк. А я думаю, что нужно мне запускать не на сессию а именно на этапе загрузки, а то я сильно подозреваю что на логине скрипт уже проверил что тут wayland и не активен
не работает и другой способ, через /etc/gdm3/daemon.conf». где раскомментить «WaylandEnable=false». такого пути как gdm3 нет в alt-regular-gnome
(In reply to Павел from comment #26) > почему-то в регулярке alt-regular-gnome я не увидел привычной шестереночки в > правом нижнем углу, где можно выбрать себе графический стэк. А я думаю, что > нужно мне запускать не на сессию а именно на этапе загрузки, а то я сильно > подозреваю что на логине скрипт уже проверил что тут wayland и не активен нет, скрипт просто модифицирует xorg.conf, он сессию не проверяет (точнее, там есть проверка что есть display-manager, но она ничего не делает).
(In reply to Павел from comment #26) > почему-то в регулярке alt-regular-gnome я не увидел привычной шестереночки в > правом нижнем углу, где можно выбрать себе графический стэк. А я думаю, что > нужно мне запускать не на сессию а именно на этапе загрузки, а то я сильно > подозреваю что на логине скрипт уже проверил что тут wayland и не активен Антон, ты можешь это подтвердить (пропажу возможности переключения типа сессии)?
(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #29) > (In reply to Павел from comment #26) > > почему-то в регулярке alt-regular-gnome я не увидел привычной шестереночки в > > правом нижнем углу, где можно выбрать себе графический стэк. А я думаю, что > > нужно мне запускать не на сессию а именно на этапе загрузки, а то я сильно > > подозреваю что на логине скрипт уже проверил что тут wayland и не активен > > Антон, ты можешь это подтвердить (пропажу возможности переключения типа > сессии)? Обычно, это происходит, когда gdm запущен на xorg. Узнать, запущены иксы или wayland, можно командой: echo $XDG_SESSION_TYPE
Приношу извинения, не разобрался. Колесико появляется, но когда активно поле ввода.
Superposition упрямо не хочет работать с eGPU на альт. На вин я уже давно прогнал тесты на внешке, там вопросов нет. nvtop говорит о нулевой активности внешки. Но вот я запустил одну из легких в плане нагрузки протоновких игр, как трафик пошел через внешку. В gnome на убунту если вызывать меню программ и левой кнопкой щелкнуть на иконку, то появлялся контекст 'запустить, используя дискретную видеокарту'
Вообще ситуация немножечко странная. nvtop и/или LACT видят внешку как то через раз. Лечится перезагрузкой с заранее включенной док-станцией.
Не выдержал, запустил Superposition через протон. Разница с win где-то в 4 раза. Сейчас приложу скриншоты.
Created attachment 16696 [details] superposition на win
Created attachment 16697 [details] superposition на alt, через портпротон
сеcсия X11
(In reply to Павел from comment #32) > Superposition упрямо не хочет работать с eGPU на альт. На вин я уже давно > прогнал тесты на внешке, там вопросов нет. nvtop говорит о нулевой > активности внешки. Но вот я запустил одну из легких в плане нагрузки > протоновких игр, как трафик пошел через внешку. В gnome на убунту если > вызывать меню программ и левой кнопкой щелкнуть на иконку, то появлялся > контекст 'запустить, используя дискретную видеокарту' для этого вам нужен switcheroo-control https://packages.altlinux.org/en/sisyphus/binary/switcheroo-control/x86_64/2942543700018845925, по крайней мере, так пишут интернеты
(In reply to Павел from comment #33) > Вообще ситуация немножечко странная. nvtop и/или LACT видят внешку как то > через раз. > Лечится перезагрузкой с заранее включенной док-станцией. я советую вам сначала разобраться с одной проблемой, а потом уже решать другие. nvtop и LACT это разные пакеты, которые собирают разные люди, поэтому ошибки нужно регистрировать на каждую программу в отдельности.
И тут пока провал. # rpm -q switcheroo-control switcheroo-control-2.6-alt1.x86_64 Контекстного меню нет, обнаружение EGPU системой есть.
(In reply to Павел from comment #40) > И тут пока провал. > # rpm -q switcheroo-control > switcheroo-control-2.6-alt1.x86_64 > Контекстного меню нет, обнаружение EGPU системой есть. как вы это проверяли, сессию перезапускали? Есть ли какие либо сообщения в логах?
после установки сразу ушел в перезагрузку. программа работает, похоже, замедляя загрузку системы. Она поддерживает небольшой блок команд и вот как они выполнились: Usage: switcherooctl COMMAND [ARGS…] Commands: help Print help version Print version list List the known GPUs launch Launch a command on a specific GPU Use “switcherooctl help COMMAND” to get detailed help. [root@MiG ~]# ну а когда подаю list: [root@MiG ~]# switcherooctl list [root@MiG ~]# описание смотрел здесь https://man.archlinux.org/man/switcherooctl.1.en
В системе заметил "дребезг" отрисовки: подчистка пикселей с существенной задержкой. Похоже это появилось после установки этого пакета.
можно ли/стоит ли отключить заставку при загрузке?
системы
(In reply to Павел from comment #42) > после установки сразу ушел в перезагрузку. > программа работает, похоже, замедляя загрузку системы. > Она поддерживает небольшой блок команд и вот как они выполнились: > Usage: > switcherooctl COMMAND [ARGS…] > > Commands: > help Print help > version Print version > list List the known GPUs > launch Launch a command on a specific GPU > > Use “switcherooctl help COMMAND” to get detailed help. > [root@MiG ~]# > > ну а когда подаю list: > [root@MiG ~]# switcherooctl list > [root@MiG ~]# > > описание смотрел здесь > https://man.archlinux.org/man/switcherooctl.1.en Если программа не работает, создайте отдельный баг на нее, не нужно все скидывать в кучу в одном обсуждении. Пока я ничего не вижу по нашей проблеме: - до сих пор нет данных по скоростям и TDP в linux/windows во время запуска теста в одинаковых условиях. Запуск чего-то через portproton ни о чем не говорит, там слишком много уровней трансляции из одного 3D API в другой. До тех пор, пока вы не сможете собрать эти данные обсуждать тут нечего.
Хорошо, либо добьюсь работы утилит, либо поробую найти игры с нативной поддержкой и линкус и виндовс.
Уважаемые коллеги, пока не иссяк энтузиазм удалось все же запустить Superposition нативно и провести тест по методу, так сказать, доказательной медицины. У меня две новости. Хорошая новость в том, что производительность серьезно возросла. А плохая в том, что не настолько, чтобы полностью догнать win. О разнице судите сами. Параллельно велся захват участка экрана на ntop/cpu-z, сильно на производительность это не повлияло, я запускал и без записи. Удалось запустить через команду egpu-switcher switch -- override info] looking for eGPU... [info] the egpu is connected [warn] No eGPU attached display detected with open source drivers. (Of 5 eGPU outputs detected) Internal mode and setting DRI_PRIME variable are recommended for this configuration. [debug] -> Overridden: setting eGPU mode [info] egpu has been added to X.Org config [ok] switch completed Теперь поток перенаправляется, но ТОЛЬКО после перезагрузки. результаты прилагаю во вложения. Тест проводился на одном и том же мониторе, то есть трафик возвращался обратно в обоих случаях: от PC с видеокарте и обратно. Если же вывести через внешний слот hdmi/dp то теоретически, скорость должна еще больше возрасти.
Created attachment 16699 [details] superposition на alt, нативно
Created attachment 16700 [details] superposition на alt, нативно2
ссылка на видеозахват работы nvtop и cpu-z в режиме измерения https://disk.yandex.ru/d/vHM-ecpmV_QdiQ
(In reply to Павел from comment #48) > Уважаемые коллеги, пока не иссяк энтузиазм удалось все же запустить > Superposition нативно и провести > тест по методу, так сказать, доказательной медицины. > У меня две новости. > Хорошая новость в том, что производительность серьезно возросла. > А плохая в том, что не настолько, чтобы полностью догнать win. > О разнице судите сами. > Параллельно велся захват участка экрана на ntop/cpu-z, сильно на > производительность это не повлияло, я запускал и без записи. > Удалось запустить через команду > > egpu-switcher switch -- override > info] looking for eGPU... > [info] the egpu is connected > [warn] No eGPU attached display detected with open source drivers. (Of 5 > eGPU outputs detected) Internal mode and setting DRI_PRIME variable are > recommended for this configuration. > > [debug] -> Overridden: setting eGPU mode > [info] egpu has been added to X.Org config > [ok] switch completed > > Теперь поток перенаправляется, но ТОЛЬКО после перезагрузки. > результаты прилагаю во вложения. > Тест проводился на одном и том же мониторе, то есть трафик возвращался > обратно в обоих случаях: от PC с видеокарте и обратно. Если же вывести через > внешний слот hdmi/dp то теоретически, скорость должна еще больше возрасти. ok, уже что-то. Что можно (и нужно еще проверить): - в тестах под windows не видна скорость PCIe, можете это проверить? - непонятен режим работы GPU (профиль работы), что показывает LACT/corectrl? - можете таки замерить все под ядром lks-wks? # apt-get install apt-repo-wks-kernel # apt-get update # update-kernel -t lks-wks (перегрузиться и выбрать ядро lks-wks)
1. загрузился с ядром lks-wks 2. снял работу superposition на nvtop 3. отчет бенчмарка с ядром lks-wks прилагаю. 4. профиль работы amdgpu взятый с LACT прилагаю. Должен быть дефолтный заводской. От себя добавлю еще раз. Есть два основных режима "двунаправленный" поток по tb4 (I): monitor <--- PC <---> tb4 <---> eGPU "однонаправленный" поток tb4 (II): PC ---> tb4 ---> eGPU ---> monitor у меня пока "двунаправленный" (I) 5. под win диспетчер устройств --> системные устройства при подключении подключаются виртуальные порты PCI-E устройства Epgpu: upstream & downstream они все определены я так понимаю, что третьего поколения. во вложении. https://disk.yandex.ru/d/AV-tb8Q46Q7d9Q вроде пока все.
отчет GPU-Z добавил. Тоже трактует PCI-E как 4 полосы поколения 3.
(In reply to Павел from comment #54) > отчет GPU-Z добавил. Тоже трактует PCI-E как 4 полосы поколения 3. вот это я и пытаюсь узнать. У вас все ещё старое ядро lks-wks версия должна быть 6.10.0-alt1.6, а не 6.10.0-alt0.6, это принципиально, т.к. в новом релизе драйвер amd существенно отличается в лучшую (или худшую) сторону от ванильного 6.10. Поэтому установите именно ядро 6.10.0-alt1.6, и снимите все показания снова: - journalctl -b - показания LACT/corectrl - цифры superposition
Так я выполнил эти команды. # apt-get install apt-repo-wks-kernel # apt-get update # update-kernel -t lks-wks В загрузочном меню GRUB вижу разные ядра. никакого такого *alt1.6. нет есть просто ядро lks-wks под которым сейчас загрузился. uname -r возвращает [pavel@MiG ~]$ uname -r 6.10.0-lks-wks-alt0.6
root@MiG ~]# update-grub Generating grub configuration file ... Found theme: /boot/grub/themes/sisyphus/theme.txt Found linux image: /boot/vmlinuz Found initrd image: /boot/initrd.img Found linux image: /boot/vmlinuz-un-def Found initrd image: /boot/initrd-un-def.img Found linux image: /boot/vmlinuz-std-def Found initrd image: /boot/initrd-std-def.img Found linux image: /boot/vmlinuz-lks-wks Found initrd image: /boot/initrd-lks-wks.img Found linux image: /boot/vmlinuz-6.10.6-6.10-alt1 Found initrd image: /boot/initrd-6.10.6-6.10-alt1.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt0.6 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt0.6.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt0.5 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt0.5.img Found linux image: /boot/vmlinuz-6.10 Found initrd image: /boot/initrd-6.10.img Found linux image: /boot/vmlinuz-6.6.40-un-def-alt1 Found initrd image: /boot/initrd-6.6.40-un-def-alt1.img Found linux image: /boot/vmlinuz-6.1.99-std-def-alt1 Found initrd image: /boot/initrd-6.1.99-std-def-alt1.img
попробовал еще раз. получилось отчеты подготовлю
Система с ядром 6.10.0-lks-wks-alt1.6 и с включенной eGPU не поднялась вообще. C выключенной загрузился.
с 5 раза получилось загрузить систему с егпу, но похоже, она просто как заглушка. не обнаруживается утилитами, да и egpu-switcher вылетает с ошибкой. тесты пока провести нельзя. я прилагаю пока jornalctl cо шквалом ошибок amdgpu
Created attachment 16705 [details] 6.10.0-lks-wks-alt1.6
(In reply to Павел from comment #61) > Created attachment 16705 [details] > 6.10.0-lks-wks-alt1.6 Интересно, а в вот этом случае карта была физически включена? авг 25 19:39:19 MiG kernel: [drm] amdgpu kernel modesetting enabled. авг 25 19:39:19 MiG kernel: amdgpu: Virtual CRAT table created for CPU авг 25 19:39:19 MiG kernel: amdgpu: Topology: Add CPU node авг 25 19:39:19 MiG kernel: amdgpu 0000:07:00.0: Unable to change power state from D3cold to D0, device inaccessible тут видно, что устройство не реагирует на сигнал включения. Можете тогда сделать следующее: В /etc/modprobe.d/amdgpu.conf (или где у вас уже добавлены опции для pcie) добавить # enable DRM extra debugging messages options drm debug=0x19f потом: # make-initrd перегрузиться и journalctl -b опять (желательно сразу, т.к. в логах будет очень много сообщений).
Интересно, а в вот этом случае карта была физически включена? При подключении (физически кабелем, когда пк тоже работает или запускается) на док станции загорается зеленый светодиод, значит готова к работе. Наверное какой то базовый совсем низкоуровневый TX-RX есть, если ее пытаются включить. Поробую еще раз поднять систему на ядре 1.6 но это получилось каким-то чудом, поэтому сразу вытянул оттуда логи.
При рестарте пк, работа егпу не возобновляетя, за этим надо следить. У меня так, что конечно не очень удобно, особенно если хотплаг нестабилен и не может нормально обеспечить перенаправление нити исполнения на графическое ядро егпу.Но конкретно в этот момент она была включена.
(In reply to Павел from comment #63) > Интересно, а в вот этом случае карта была физически включена? > > При подключении (физически кабелем, когда пк тоже работает или запускается) > на док станции загорается зеленый светодиод, значит готова к работе. > Наверное какой то базовый совсем низкоуровневый TX-RX есть, если ее пытаются > включить. Поробую еще раз поднять систему на ядре 1.6 но это получилось > каким-то чудом, поэтому сразу вытянул оттуда логи. если не получится с alt1.6, сделайте аналогично с alt.0.6, мне главное понять как там происходит инициализация железа и где искать отличия.
что сделано: 1. дописан параметр в модпроб # echo "options drm debug=0x19f" >> /etc/modprobe.d/amd-egpu-pcie-speed.conf 2. пересобрана система инициализации # make-initrd 3. Сняты логи с двух ядер: рабочего *0.6 и сбоящего *1.6 для дифференциального изучения
Created attachment 16721 [details] *1.6
Created attachment 16722 [details] *0,6
это странное событие Unable to change power state from D3hot to D0, device inaccessible есть в обоих логах...
... или это разные адреса и устройства???
https://bbs.archlinux.org/viewtopic.php?id=297421 Очень схожая ситуация с amdgpu(egpu) на арче
(In reply to Павел from comment #71) > ... или это разные адреса и устройства??? это разные устройства. Я тут нашёл как включить debug сообщения от drm: при загрузке ядра добавьте параметр drm.debug=0x1ff это включит все сообщения от подсистемы drm. Потом соберите логи от ядер 0.6 и 1.6 приложите сюда.
раз через точку-оператор, значит в grub ?? дописано в /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT=' resume=/dev/disk/by-uuid/5ab05302-75c1-4862-b442-f5e749e2b893 panic=30 quiet loglevel=3 splash' drm.debug=0x1ff root@MiG ~]# update-grub /etc/sysconfig/grub2: строка 41: drm.debug=0x1ff: команда не найдена
(In reply to Павел from comment #74) > раз через точку-оператор, значит в grub ?? > дописано в /etc/default/grub > > GRUB_CMDLINE_LINUX_DEFAULT=' > resume=/dev/disk/by-uuid/5ab05302-75c1-4862-b442-f5e749e2b893 panic=30 quiet > loglevel=3 splash' drm.debug=0x1ff > > root@MiG ~]# update-grub > /etc/sysconfig/grub2: строка 41: drm.debug=0x1ff: команда не найдена GRUB_CMDLINE_LINUX_DEFAULT=' resume=/dev/disk/by-uuid/5ab05302-75c1-4862-b442-f5e749e2b893 panic=30 quiet loglevel=3 splash drm.debug=0x1ff' Видите разницу?
если делаете через grub, не забудьте выполнить команду update-grub перед перезагрузкой.
Видите разницу? Семен Семеныч... Спасибо. Кхм. лог файла аж 110мБ
https://disk.yandex.ru/d/AV-tb8Q46Q7d9Q
(Ответ для Павел на комментарий #78) > https://disk.yandex.ru/d/AV-tb8Q46Q7d9Q я выложил новую сборку ядра lks-wks (6.10.0-alt2.7), можете проверить с ней? # удалить drm.debug из конфигурации grub # apt-get update # update-kernel -t lks-wks (убедиться, что установилась версия 6.10.0-alt2.7) перегрузиться, снять логи и приложить сюда.
при работающем егпу симптомы те же, что и на *1.6 нет обнаружения root@MiG ~]# egpu-switcher config [error] unable to read pci information from sysfs: got error while scanning device '0000:04:01.0': the pci 'config' file has an invalid format panic: unable to read pci information from sysfs goroutine 1 [running]: github.com/hertg/egpu-switcher/internal/pci.ReadGPUs() /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/internal/pci/pci.go:98 +0x1a5 github.com/hertg/egpu-switcher/cmd.init.func2(0xc0000e2800?, {0x7c652d?, 0x4?, 0x7c6531?}) /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/cmd/config.go:26 +0x2f github.com/spf13/cobra.(*Command).execute(0xadffc0, {0xb4b040, 0x0, 0x0}) /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/vendor/github.com/spf13/cobra/command.go:872 +0x6b4 github.com/spf13/cobra.(*Command).ExecuteC(0xadfac0) /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/vendor/github.com/spf13/cobra/command.go:990 +0x38d github.com/spf13/cobra.(*Command).Execute(...) /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/vendor/github.com/spf13/cobra/command.go:918 github.com/hertg/egpu-switcher/cmd.Execute() /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/cmd/root.go:79 +0x1a main.main() /usr/src/RPM/BUILD/egpu-switcher-0.19.0/.gopath/src/github.com/hertg/egpu-switcher/main.go:8 +0xf [root@MiG ~]# uname -r 6.10.0-lks-wks-alt2.7 [root@MiG ~]#
понятно, будем искать дальше. Приложите тогда вывод journalctl -b с этого ядра.
так это с учетом активности drm param или нет???
(In reply to Павел from comment #82) > так это с учетом активности drm param или нет??? нет, drm.debug тут уже не нужен. Достаточно просто сохранить вывод journalctl при обычной загрузке.
Created attachment 16762 [details] alt 2.7
авг 30 22:21:52 MiG kernel: amdgpu: Virtual CRAT table created for CPU авг 30 22:21:52 MiG kernel: amdgpu: Topology: Add CPU node авг 30 22:21:52 MiG kernel: amdgpu 0000:07:00.0: Unable to change power state from D3cold to D0, device inaccessible кажется, как и прежде, не удается разбудить карту.
А можете еще приложить вывод команды dmidecode (полученный файл dmidecode.log)? # dmidecode > dmidecode.log 2>&1 у меня тут есть идея как включить видеокарту при загрузке.
я собрал экспериментальную версию ядра, которая должна включить egpu. https://lakostis.unsafe.ru/RPMS/ALTLinux/testing/kernel-image-lks-wks-6.10.0-alt2.7.x86_64.rpm - скачайте этот пакет, потом выполните от рута: # apt-get install --reinstall ./kernel-image-lks-wks-6.10.0-alt2.7.x86_64.rpm потом перегрузиться и проверить результат (dmidecode все еще нужен)
установил. Дабы избежать досадных недоразумений вопрос- как оно должно представиться модифицированное ядро? Что должно вернуть uname-r? и что выбрать из списка: lks-wks?
[root@MiG ~]# update-grub Generating grub configuration file ... Found theme: /boot/grub/themes/sisyphus/theme.txt Found linux image: /boot/vmlinuz Found initrd image: /boot/initrd.img Found linux image: /boot/vmlinuz-un-def Found initrd image: /boot/initrd-un-def.img Found linux image: /boot/vmlinuz-std-def Found initrd image: /boot/initrd-std-def.img Found linux image: /boot/vmlinuz-lks-wks Found initrd image: /boot/initrd-lks-wks.img Found linux image: /boot/vmlinuz-6.10.6-6.10-alt1 Found initrd image: /boot/initrd-6.10.6-6.10-alt1.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt2.7 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt2.7.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt1.6 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt1.6.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt0.6 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt0.6.img Found linux image: /boot/vmlinuz-6.10.0-lks-wks-alt0.5 Found initrd image: /boot/initrd-6.10.0-lks-wks-alt0.5.img Found linux image: /boot/vmlinuz-6.10 Found initrd image: /boot/initrd-6.10.img Found linux image: /boot/vmlinuz-6.6.40-un-def-alt1 Found initrd image: /boot/initrd-6.6.40-un-def-alt1.img Found linux image: /boot/vmlinuz-6.1.99-std-def-alt1 Found initrd image: /boot/initrd-6.1.99-std-def-alt1.img Found Windows Boot Manager on /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi Adding boot menu entry for UEFI Firmware Settings ... Found memtest image: /boot/memtest-7.00.bin Found memtest image: /boot/memtest-7.00.efi done [root@MiG ~]#
Просто если ошибка одинаково вопроизводится на ядре нужно точно понимать на каком именно.
(In reply to Павел from comment #90) > Просто если ошибка одинаково вопроизводится на ядре нужно точно понимать на > каком именно. ядро нужно выбрать alt2.7
Пока все так же и после правок к сожалению
Created attachment 16766 [details] 2.7+
Created attachment 16767 [details] 2,7++
сможете подтвердить на всякий случай, что все сделано мной верно?
(In reply to Павел from comment #95) > сможете подтвердить на всякий случай, что все сделано мной верно? ядро загрузилось правильное, но вот исправление правильно не сработало. Все еще жду от вас вывод dmidecode. Попробуйте еще след. метод: Добавьте в опции загрузки параметр pcie_port_pm=off (по аналогии как делали с drm.debug), и проверьте с ядром -alt2.7
этот отчет Создано вложение 16766 [details] не актуален?
(In reply to Павел from comment #97) > этот отчет > Создано вложение 16766 [details] > не актуален? актуален, если вариант с pcie_port_pm=off сработает
параметр pcie_port_pm=off ( записал как есть) добавил в конфиг и обновил загрузчик. при активности док-станции егпу: система не поднялась за заставку: пошли обновления и не зашли за 42% новая загрузка ни к чему не привела не поднялась за заставку dmidecode на ядре *2.7 пока нельзя
Created attachment 16768 [details] 2,7+++
загрузил систему через очень длительный этап загрузки (около 10 мин)
обнаружения нет.
(In reply to Павел from comment #102) > обнаружения нет. жду journalctl
Сейчас могу сказать, что система на ядре *2.7 поднимается с eGPU, но как-то непредсказуемо (карта может запуститься, а может вести себя так как ранее). Как только случился такой запуск снял Journalctl и тест Superposition. Результаты во вложениях.
Created attachment 16771 [details] 2.7 успешный запуск eGPU
Created attachment 16772 [details] 2.7 + Superposition
Created attachment 16773 [details] dmidecode 2.7+
(In reply to Павел from comment #106) > Created attachment 16772 [details] > 2.7 + Superposition сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: [1002:747e] type 00 class 0x030000 PCIe Legacy Endpoint сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 0 [mem 0x00000000-0x0fffffff 64bit pref] сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 2 [mem 0x00000000-0x001fffff 64bit pref] сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 4 [io 0x0000-0x00ff] сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 5 [mem 0x00000000-0x000fffff] сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: ROM [mem 0x00000000-0x0001ffff pref] сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: PME# supported from D1 D2 D3hot D3cold сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link) сен 02 20:54:10 MiG kernel: pci 0000:07:00.1: [1002:ab30] type 00 class 0x040300 PCIe Legacy Endpoint В общем тут у нас проблема осталась - низкая скорость pcie подключения. А параметр в /etc/modprobe.d/ для скорости pcie у вас остался? Попробуйте его закомментировать совсем (или удалить вообще этот файл с параметром).
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #108) > (In reply to Павел from comment #106) > > Created attachment 16772 [details] > > 2.7 + Superposition > > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: [1002:747e] type 00 class > 0x030000 PCIe Legacy Endpoint > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 0 [mem > 0x00000000-0x0fffffff 64bit pref] > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 2 [mem > 0x00000000-0x001fffff 64bit pref] > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 4 [io 0x0000-0x00ff] > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: BAR 5 [mem > 0x00000000-0x000fffff] > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: ROM [mem 0x00000000-0x0001ffff > pref] > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: PME# supported from D1 D2 > D3hot D3cold > сен 02 20:54:10 MiG kernel: pci 0000:07:00.0: 8.000 Gb/s available PCIe > bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of > 252.048 Gb/s with 16.0 GT/s PCIe x16 link) > сен 02 20:54:10 MiG kernel: pci 0000:07:00.1: [1002:ab30] type 00 class > 0x040300 PCIe Legacy Endpoint > > В общем тут у нас проблема осталась - низкая скорость pcie подключения. > > А параметр в /etc/modprobe.d/ для скорости pcie у вас остался? Попробуйте > его закомментировать совсем (или удалить вообще этот файл с параметром). после удаления файла или комментирования параметра не забудьте выполнить make-initrd -k 6.10.0-lks-wks-alt2.7 перед перезагрузкой.
М-да. Архитектура железа не должна подвести и подозрения такого рода нужно было отсеять в первую очередь. Полная поддержка TB4 заявлена производителем (msi не должен был как то на нем сэкономить) исключить деградацию кабеля и т.п. Как я понимаю, ожидаем крупных патчей вендора (amd/amdgpu)? Если он вообще собирается на них реагировать, так как таких аппаратных решений маловато.
может быть еще какой то микрокод для контроллера TB4 должен быть передан на уровне ОС или пакта bolt? я чувствую что скатываюсь в гадание.
(In reply to Павел from comment #111) > может быть еще какой то микрокод для контроллера TB4 должен быть передан на > уровне ОС или пакта bolt? я чувствую что скатываюсь в гадание. я пока смотрю текущие баги по этой ситуации и потом отпишусь, что можно будет сделать.
(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #112) > (In reply to Павел from comment #111) > > может быть еще какой то микрокод для контроллера TB4 должен быть передан на > > уровне ОС или пакта bolt? я чувствую что скатываюсь в гадание. > > я пока смотрю текущие баги по этой ситуации и потом отпишусь, что можно > будет сделать. Пока новостей особых нет, проблема с производительностью известна довольно давно - https://gitlab.freedesktop.org/drm/amd/-/issues/2885 но решения пока нет, все упирается в прошивку TB от intel или драйвер в ядре. Собственно, в ядре баг открыт - https://bugzilla.kernel.org/show_bug.cgi?id=218525 Поэтому можете пока поставить ядро 6.11 из Сизифа и сравнить результат.
Похоже все говорит о том, что проблема пустила корни очень глубоко на низкий уровень микрокода и рассогласования режимов работы контроллеров на плате egpu и контоллера TB4 от intel (фукнкционала PCI-E over tb4 tunneling и текущей иплеметации технологии amd X-connect на Linux. Спасибо. Будет немного больше времени проверю на ядре 6.11. Спасибо за участие.
ядро 6.10 EOL, поэтому баг закрываю. Прошу проверить с ядром 6.12 и открыть баг там.
https://bugzilla.altlinux.org/52066
