LINUX.ORG.RU

VLC вешает amdgpu

 ,


1

3

Аппаратное ускорение декодирования отключено, потому что работало коряво.

Плеер стоит на паузе и свёрнут.

В произвольный момент времени в лог начинает сраться бесконечное

Aug  7 00:03:44 RERE-turk kernel: [76742.076355] amdgpu 0000:05:00.0: amdgpu: [mmhub0] no-retry page fault (src_id:0 ring:40 vmid:7 pasid:32784, for process vlc pid 1852235 thread vlc:cs0 pid 1852470)
Aug  7 00:03:44 RERE-turk kernel: [76742.076370] amdgpu 0000:05:00.0: amdgpu:   in page starting at address 0x0000800101a10000 from IH client 0x12 (VMC)
Aug  7 00:03:44 RERE-turk kernel: [76742.076378] amdgpu 0000:05:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00740051
Aug  7 00:03:44 RERE-turk kernel: [76742.076381] amdgpu 0000:05:00.0: amdgpu: 	 Faulty UTCL2 client ID: MP1 (0x0)
Aug  7 00:03:44 RERE-turk kernel: [76742.076384] amdgpu 0000:05:00.0: amdgpu: 	 MORE_FAULTS: 0x1
Aug  7 00:03:44 RERE-turk kernel: [76742.076386] amdgpu 0000:05:00.0: amdgpu: 	 WALKER_ERROR: 0x0
Aug  7 00:03:44 RERE-turk kernel: [76742.076388] amdgpu 0000:05:00.0: amdgpu: 	 PERMISSION_FAULTS: 0x5
Aug  7 00:03:44 RERE-turk kernel: [76742.076390] amdgpu 0000:05:00.0: amdgpu: 	 MAPPING_ERROR: 0x0
Aug  7 00:03:44 RERE-turk kernel: [76742.076392] amdgpu 0000:05:00.0: amdgpu: 	 RW: 0x1

Через несколько минут ради пущего веселья сабж пытается починить то, что не сломано, и ломает графику напрочь:

Aug  7 00:03:54 RERE-turk kernel: [76752.173003] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=428330, emitted seq=428331
Aug  7 00:03:54 RERE-turk kernel: [76752.173156] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process vlc pid 1852235 thread vlc:cs0 pid 1852470
Aug  7 00:03:54 RERE-turk kernel: [76752.173275] amdgpu 0000:05:00.0: amdgpu: GPU reset begin!
Aug  7 00:03:54 RERE-turk kernel: [76752.405438] [drm] free PSP TMR buffer
Aug  7 00:03:54 RERE-turk kernel: [76752.431452] CPU: 14 PID: 1837166 Comm: kworker/u32:0 Tainted: P           OE     5.19.0-50-generic #50-Ubuntu
Aug  7 00:03:54 RERE-turk kernel: [76752.431459] Hardware name: LENOVO 82L5/LNVNB161216, BIOS GSCN33WW 07/04/2022
Aug  7 00:03:54 RERE-turk kernel: [76752.431462] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]
Aug  7 00:03:54 RERE-turk kernel: [76752.431476] Call Trace:
Aug  7 00:03:54 RERE-turk kernel: [76752.431479]  <TASK>
Aug  7 00:03:54 RERE-turk kernel: [76752.431482]  show_stack+0x52/0x69
Aug  7 00:03:54 RERE-turk kernel: [76752.431491]  dump_stack_lvl+0x49/0x6d
Aug  7 00:03:54 RERE-turk kernel: [76752.431498]  dump_stack+0x10/0x18
Aug  7 00:03:54 RERE-turk kernel: [76752.431504]  amdgpu_do_asic_reset+0x2b/0x441 [amdgpu]
Aug  7 00:03:54 RERE-turk kernel: [76752.431912]  amdgpu_device_gpu_recover_imp.cold+0x4f6/0x805 [amdgpu]
Aug  7 00:03:54 RERE-turk kernel: [76752.432283]  amdgpu_job_timedout+0x15e/0x190 [amdgpu]
Aug  7 00:03:54 RERE-turk kernel: [76752.432650]  ? finish_task_switch.isra.0+0x84/0x290
Aug  7 00:03:54 RERE-turk kernel: [76752.432657]  drm_sched_job_timedout+0x6a/0x120 [gpu_sched]
Aug  7 00:03:54 RERE-turk kernel: [76752.432664]  process_one_work+0x21c/0x400
Aug  7 00:03:54 RERE-turk kernel: [76752.432669]  worker_thread+0x50/0x3f0
Aug  7 00:03:54 RERE-turk kernel: [76752.432673]  ? rescuer_thread+0x3a0/0x3a0
Aug  7 00:03:54 RERE-turk kernel: [76752.432675]  kthread+0xeb/0x120
Aug  7 00:03:54 RERE-turk kernel: [76752.432680]  ? kthread_complete_and_exit+0x20/0x20
Aug  7 00:03:54 RERE-turk kernel: [76752.432684]  ret_from_fork+0x1f/0x30
Aug  7 00:03:54 RERE-turk kernel: [76752.432692]  </TASK>
Aug  7 00:03:54 RERE-turk kernel: [76752.432707] amdgpu 0000:05:00.0: amdgpu: MODE2 reset
Aug  7 00:03:54 RERE-turk kernel: [76752.432792] amdgpu 0000:05:00.0: amdgpu: GPU reset succeeded, trying to resume
Aug  7 00:03:54 RERE-turk kernel: [76752.433013] [drm] PCIE GART of 1024M enabled.
Aug  7 00:03:54 RERE-turk kernel: [76752.433019] [drm] PTB located at 0x000000F400FA0000
Aug  7 00:03:54 RERE-turk kernel: [76752.433036] [drm] VRAM is lost due to GPU reset!
Aug  7 00:03:54 RERE-turk kernel: [76752.433039] [drm] PSP is resuming...
Aug  7 00:03:54 RERE-turk kernel: [76752.452919] [drm] reserve 0x400000 from 0xf47fb00000 for PSP TMR
Aug  7 00:03:55 RERE-turk kernel: [76752.712977] amdgpu 0000:05:00.0: amdgpu: RAS: optional ras ta ucode is not available
Aug  7 00:03:55 RERE-turk kernel: [76752.723675] amdgpu 0000:05:00.0: amdgpu: RAP: optional rap ta ucode is not available
Aug  7 00:03:55 RERE-turk kernel: [76752.723681] amdgpu 0000:05:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
Aug  7 00:03:55 RERE-turk kernel: [76752.723686] amdgpu 0000:05:00.0: amdgpu: SMU is resuming...
Aug  7 00:03:55 RERE-turk kernel: [76752.724205] amdgpu 0000:05:00.0: amdgpu: SMU is resumed successfully!
Aug  7 00:03:55 RERE-turk kernel: [76752.724753] [drm] DMUB hardware initialized: version=0x0101001F
Aug  7 00:03:55 RERE-turk kernel: [76753.118193] [drm] kiq ring mec 2 pipe 1 q 0
Aug  7 00:03:55 RERE-turk kernel: [76753.344452] amdgpu 0000:05:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring sdma0 test failed (-110)
Aug  7 00:03:55 RERE-turk kernel: [76753.344813] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <sdma_v4_0> failed -110
Aug  7 00:03:55 RERE-turk kernel: [76753.345136] amdgpu 0000:05:00.0: amdgpu: GPU reset(1) failed
Aug  7 00:03:55 RERE-turk kernel: [76753.345202] amdgpu 0000:05:00.0: amdgpu: GPU reset end with ret = -110
Aug  7 00:03:55 RERE-turk kernel: [76753.345210] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* GPU Recovery Failed: -110

В интернетах нашёл только советы вида «обнови ядро». Сейчас стоит 6.2.0-26-generic, более нового в репе нет.

Если в светлом будущем будут существовать компьютеры, я буду пользоваться чем угодно, кроме продукции AMD. Сколько же, блин, можно.


Ответ на: комментарий от ox55ff

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

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

Была ж лет 5 назад новость, что, у кажется, BSDшников выходят огромные счета за свет при тестировании на древних мейнфреймах. Так что, видимо, так и делают.

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

Ну удачи тебе замокать

Это нужно делать тем, кто пишет драйвера. Сразу, а не потом когда нибудь. Тогда всё это не будет казаться огромной непосильной задачей. А если 30 лет забивать, то накопленный технический долг будет колоссальным. Что мы и видим.

когда спека производителя не отражает реальное поведение

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

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

Ага, я понял. Значит, нам нужны будут стенды, на которых мы будем крутить все многообразие десктопного ПО, чтобы проверить, как vlc/mpv/mplayer/cinelerra/opera/qbittorrent/geany/whatever (не)роняют драйвера/ведро под kwin/mutter/sway на xorg/wayland, работая через alsa/oss/pulseaudio/pipewire. Или их все тоже замокать? Точно, будем тестировать моки через моки, сразу будет идеальный код получаться, без багов.

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

замёржить в мастер

Вот вам наглядное сравнение проприетарщины и швятого опенсорса

мастер

💁🏻‍♀️

Сколько лет сижу на блобе nvidia под линуксом и никогда не ловил поломку драйвера

ЕМНИП блоб перманентно сломан, это его состояние по умолчанию. Размер GTT memory у них не регулируется параметром ядра, совместимость с новыми ядрами периодически запаздывает, поддержку пожилых видеокарт (т.е. не безнадежно устаревших, а просто пожилых) выкидывают в legacy ветки у коих с новыми ядрами совсем беда, переменная окружения DRI_PRIME игнорируется, нет ни gbm, ни vk_ext_drm_modifier, ни vk_ext_external_memory_dma_buf, ни vaapi элементарного..

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

поддержку пожилых видеокарт

Нахер не нужно.

DRI_PRIME

Ноутбукопробелмы

нет ни gbm

Шпициалиста сразу видно. 14 October 2021 NVIDIA 495 Linux Beta Driver Released With GBM Support

После этого дальше читать смысла нет.

ox55ff ★★★★★
()

Это еще большой фарт, если проблема в этом копролите - vlc, меняешь его на mpv и живешь дальше счастливо. А у меня dpms откючен, иначе большие шансы видео вновь не поднять, вплоть до зависания ядра. И вон, вчера выяснил, что при запущенном клиенте телеграма тоже ловлю зависания, но на них хоть reisub работает.
В общем, боль и страдания, ушел собирать 6,5-rc5 вместо 6.3, mesa стоит 23.1.5.

sehellion ★★★★★
()

я починить то, что не сломано,

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

*ERROR* resume of IP block <sdma_v4_0> failed -110

MODULE_FIRMWARE("amdgpu/vega10_sdma.bin");
MODULE_FIRMWARE("amdgpu/vega10_sdma1.bin");
MODULE_FIRMWARE("amdgpu/vega12_sdma.bin");
MODULE_FIRMWARE("amdgpu/vega12_sdma1.bin");
MODULE_FIRMWARE("amdgpu/vega20_sdma.bin");
MODULE_FIRMWARE("amdgpu/vega20_sdma1.bin");
MODULE_FIRMWARE("amdgpu/raven_sdma.bin");
MODULE_FIRMWARE("amdgpu/picasso_sdma.bin");
MODULE_FIRMWARE("amdgpu/raven2_sdma.bin");
MODULE_FIRMWARE("amdgpu/arcturus_sdma.bin");
MODULE_FIRMWARE("amdgpu/renoir_sdma.bin");
MODULE_FIRMWARE("amdgpu/green_sardine_sdma.bin");
MODULE_FIRMWARE("amdgpu/aldebaran_sdma.bin");


Вам с этим на помойку, работать стабильно это поколение не будет никогда, оно мертворождёное. Живое у amd сейчас rdna2+ или 8 поколение (RX4XX-RX5XX), всё что между - провальные эксперименты, зачем-то выкинутые на потребитьельский рынок (ака вантузятники что угодно сожрут)
Под виндой 9 поколение работает относительно стабильно засчёт собираемой драйвером телеметрии - если gpu ловит VM фаулты, отслеживается что делал драйвер и отсылается на сервера, в обнове драйвера находят условия под которым ставить зажержку, вставляется задержка и таким образом краш обходится
Некоторые конечно заявляют, что у них renoir не падает, но либо это очень удачный чип, либо им просто повезло и оно пока что не падало, либо сваливали ошибки на что-то иное, а у тебя скорее всего что-то типа raven и это сразу ГРОБ ГРОБ КЛАДБИЩЕ ВОРОН, само название намекает

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

Это тоже 9.3, значит те же проблемы, что и у renoir. Не будет падать если очень повезёт.
основная проблема у них - если что-то пойдёт не так, придётся снимать питание с gpu и cpu
Для сравнения, rdna2, который в стимдеке просто резетится и продолжает работать

mittorn ★★★★★
()

Мне удавадось пару раз успешно резетнуть raven, который в 2400G после зависания. Для этого пришлось немного хакнуть ядро, убрав там вызов suspend для gpu и увести систему в suspend в процессе резета. При этом питание с gpu снимается и после пробуждения встройка прошла тесты. Но это на голом фреймбуффере было

mittorn ★★★★★
()
14 сентября 2023 г.
Ответ на: комментарий от Dimez

Это не dmesg, это компиляция нескольких kern.log. Возможно, с разрывами, я не уверен, почему пауза между записями в разных файлах составляет 2 секунды. https://hastebin.com/share/toyovajipa.yaml
Dmesg текущей сессии погиб под гнётом генерируемого auditd мусора, а перезагружаться сейчас вообще не хочется, слишком много запущено

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