Proses Melacak dan Memperbaiki Hang Saat Suspend-Resume Linux pada GPU AMD

 (nyanpasu64.gitlab.io)
1 poin oleh GN⁺ 2025-02-18 | 1 komentar | Bagikan ke WhatsApp
  • Pada desktop Linux berbasis AMD RX 570, jika sistem masuk suspend saat penggunaan RAM tinggi, setelah resume sering muncul layar hitam atau input tidak merespons, sehingga pelacakan harus melampaui sekadar masalah tampilan hingga alur power management kernel
  • Akar masalahnya ada pada alur amdgpu yang sebelum suspend S3 harus mencadangkan VRAM ke RAM sistem, tetapi saat RAM kosong tidak cukup, tidak dapat memanfaatkan swap disk dengan benar dan runtuh karena OOM
  • Patch pertama yang memajukan VRAM eviction dari dpm_suspend() ke dpm_prepare() mengurangi race dengan pemutusan daya SSD, tetapi karena pm_restrict_gfp_mask() sudah menonaktifkan swap, kekurangan memori kontigu masih bisa terjadi
  • Setelah itu, ketika diubah agar amdgpu_device_evict_resources() dipanggil pada saat PM_SUSPEND_PREPARE melalui register_pm_notifier(), VRAM dapat dicadangkan selagi swap dan disk masih aktif, sehingga di lingkungan pengujian suspend berhasil bahkan saat penggunaan RAM dan VRAM tinggi
  • Perubahan ini digabungkan ke tree amdgpu, tetapi dibatalkan pada 2025-06 karena kemungkinan deadlock; pada jalur suspend yang tidak membekukan proses pengguna terlebih dahulu, aplikasi 3D dapat menarik kembali VRAM ke GPU dan menghambat eviction

Kegagalan suspend berulang dan diagnosis awal yang keliru

  • Desktop tersebut dikonfigurasi dual-boot Windows dan Linux, dan saat mencoba suspend di Linux ketika penggunaan RAM tinggi, sistem sering bermasalah
    • Setelah resume, hanya terlihat layar hitam dan kursor yang bergerak, atau tidak ada output layar dan hanya merespons magic SysRq atau hard reset
    • Pada beberapa kasus, jam di layar kunci KDE diperbarui secara real time, tetapi sistem hang saat login atau berinteraksi
  • Lingkungan pengujian adalah Gigabyte B550M DS3H, GPU AMD RX 570, SSD NVMe Kingston A2000 1TB, Arch Linux, systemd-boot, dan Linux 6.4
  • Saat memeriksa log boot sebelumnya dengan journalctl --system -b -1, pada beberapa percobaan suspend muncul kesalahan OOM pada kode kernel di bawah amdgpu_device_suspend
  • Banyak kasus kegagalan berakhir pada log berikut, dan tidak ada catatan bahwa sistem yang rusak berhasil bangun kembali
    • systemd-sleep: Entering sleep state 'suspend'...
    • kernel: PM: suspend entry (deep)
  • Awalnya mode hemat daya NVMe APST dicurigai, sehingga dicoba nvme_core.default_ps_max_latency_us=0, iommu=soft, upgrade firmware SSD, dan penggantian SSD boot 2TB, tetapi masalah tidak terselesaikan

Alat debugging yang mempersempit lokasi kegagalan

  • Karena perilaku systemd yang mencoba beberapa mode suspend secara berurutan dapat menimbulkan noise log dan memperburuk status kernel, SuspendState=mem ditambahkan ke /etc/systemd/sleep.conf
    • Debugging menjadi lebih sederhana, tetapi akar masalah tetap ada
  • Lokasi kegagalan suspend dilacak dengan echo 1 > /sys/power/pm_trace
    • pm_trace menyimpan status progres suspend-resume ke waktu sistem
    • Berkat efek samping berupa dinonaktifkannya suspend asinkron, terlihat juga pola bahwa setelah kegagalan suspend amdgpu sistem dapat pulih, alih-alih hang total
  • Parameter kernel systemd.debug_shell ditambahkan agar root shell dapat dibuka di Ctrl-Alt-F9 tanpa login KDE atau TTY
  • Untuk mengantisipasi USB controller dan keyboard rusak, digunakan keyboard PS/2, lalu kemudian konsol serial dikonfigurasi
    • Parameter kernel: no_console_suspend console=tty0 console=ttyS0,115200 loglevel=8
    • Log ditangkap terus-menerus dari laptop dengan sudo minicom --device /dev/ttyUSB0 --baudrate 115200
    • Konsol serial memungkinkan eksekusi perintah dan pengumpulan log bahkan setelah tampilan dan jaringan rusak, tetapi memiliki keterbatasan pada kecepatan transfer serta penanganan warna dan ukuran layar

Hubungan antara amdgpu VRAM eviction dan OOM

  • Log crash umumnya terjadi pada jalur eviction buffer TTM milik amdgpu
    • amdgpu_device_evict_resources()
    • amdgpu_ttm_evict_resources()
  • Dari laporan bug terkait, “evict” dipastikan berkaitan dengan tindakan menyalin VRAM ke RAM sistem, atau memindahkan RAM sistem ke swap
  • Ketika desktop masuk suspend S3, daya GPU PCIe terputus dan data chip VRAM hilang
    • Driver GPU harus menyalin VRAM yang sedang digunakan ke RAM sistem sebelum suspend
    • Setelah resume, data yang disimpan di RAM harus dipulihkan kembali
  • Pada driver Linux amdgpu, ketika tidak ada cukup RAM kosong untuk menampung seluruh VRAM yang sedang digunakan, terdapat masalah yang membuatnya crash karena kehabisan memori alih-alih memindahkan RAM sistem ke swap berbasis disk
  • Jika Linux mengalami OOM saat suspend, sistem mencoba membatalkan suspend dan memulai ulang perangkat, tetapi karena suspend sudah terlanjur sebagian berjalan, beberapa driver bisa rusak atau OOM dapat terjadi lagi saat suspend/resume
    • Risikonya lebih besar jika suspend asinkron aktif
    • Suspend itu sendiri juga bisa berhasil, tetapi OOM terjadi saat proses memulai perangkat pada resume

Upaya perbaikan pertama: memajukan waktu pencadangan VRAM

  • Mario Limonciello menyarankan untuk mengaktifkan /sys/power/pm_print_times dan /sys/power/pm_debug_messages, lalu memeriksa log suspend
  • Log menunjukkan bahwa driver NVMe dan amdgpu masuk secara paralel ke pci_pm_suspend saat suspend
  • Pada awalnya dicari cara untuk mendahulukan suspend GPU daripada suspend SSD, dan mekanisme device suspend ordering Linux juga diperiksa
    • Mekanisme ini terlihat lebih dekat untuk sinkronisasi periferal yang terkait erat daripada untuk mensuspend semua GPU sebelum semua disk sistem
  • Mario mengusulkan cara melakukan eviction VRAM pada tahap prepare Linux suspend, lalu menulis patch kernel yang memindahkan VRAM eviction dari dpm_suspend() ke dpm_prepare()
  • Alur sebelum dan sesudah perubahan adalah sebagai berikut
    • Sebelumnya: pencadangan VRAM dijalankan pada dpm_suspend(), sehingga dapat tumpang-tindih dengan alur SSD dimatikan
    • Sesudahnya: pencadangan VRAM dicoba terlebih dahulu di dpm_prepare(), dan jika gagal, suspend dihentikan sebelum perangkat lain disuspend
  • Perubahan ini lebih baik daripada sebelumnya, tetapi karena pm_restrict_gfp_mask() menonaktifkan swap sebelum dpm_prepare(), suspend masih gagal saat penggunaan RAM tinggi
    • amdgpu_ttm_evict_resources() bisa gagal karena kekurangan memori kontigu
    • Bahkan jika seluruh VRAM dapat dimasukkan ke RAM, OOM saat sleep atau wake masih bisa terjadi jika ruang tersisa tidak cukup untuk menangani alokasi driver berikutnya

Crash amdgpu lain yang ditemukan dengan Ghidra

  • Saat pengujian muncul kesalahan BUG: unable to handle page fault for address: fffffffffffffffc, yang tampak seperti dereference pointer yang hampir null
  • Log crash menunjuk ke lokasi dm_resume+0x200, tetapi tidak memberikan nomor baris kode sumber
  • Setelah menyimpan dan mengekstrak modul kernel amdgpu.ko, modul tersebut didekompilasi dengan Ghidra untuk memetakan lokasi crash di dalam dm_resume ke baris source kernel
  • Masalah terjadi pada makro for_each_new_crtc_in_state(dm->cached_state, crtc, new_crtc_state, i)
    • dm->cached_state bukan pointer valid, melainkan fffffffffffffff4
    • Setelah itu, saat membaca field [RSI + 0x8], terjadi page fault pada alamat fffffffffffffffc
  • Penyebabnya ada pada alur dm_suspend() yang langsung menyimpan nilai balik drm_atomic_helper_suspend() ke pointer
    • drm_atomic_helper_suspend() dapat mengembalikan pointer valid atau ERR_PTR(err)
    • Karena OOM, -ENOMEM (-12) dikembalikan, dan kode suspend amdgpu tampaknya mendereference nilai itu seolah-olah pointer
  • Mario memperbaiki masalah ini dengan menambahkan kode untuk memeriksa nilai balik kegagalan dan menghentikan suspend

Arah yang ditinggalkan: mengizinkan swap saat prepare()

  • Alasan suspend terus gagal saat penggunaan RAM tinggi adalah amdgpu mencadangkan VRAM di dpm_prepare(), tetapi pada saat itu pm_restrict_gfp_mask() sudah menonaktifkan swap disk
  • Salah satu percobaan adalah struktur yang mengizinkan swap di dpm_prepare(), lalu menonaktifkan swap tepat sebelum dpm_suspend() mematikan disk
  • Untuk itu dilakukan eksperimen memindahkan pemanggilan pm_restrict_gfp_mask() dari enter_state() ke bagian yang lebih dalam di dalam dpm_suspend_start()
  • Hambatan praktisnya besar
    • pm_restrict_gfp_mask() dideklarasikan di kernel/power/power.h dan dipanggil dari kernel/power/suspend.c
    • Lokasi yang ingin memanggilnya adalah drivers/base/power/main.c, dan file ini umumnya tidak menyertakan header kernel/power/
    • Sebagai hack sementara ditambahkan #include <../kernel/power/power.h>, tetapi struktur seperti ini perlu meyakinkan upstream
  • Pada hybrid suspend juga ada masalah correctness
    • Hybrid suspend menyimpan image sistem, memanggil pm_restrict_gfp_mask(), lalu memanggil suspend_devices_and_enter() dalam kondisi swap nonaktif
    • Jika fungsi yang sama dipanggil lagi, peringatan muncul dan pm_restore_gfp_mask() mungkin tidak dapat mengaktifkan swap kembali
  • Dalam pengujian, frekuensi kegagalan atau crash berkurang tetapi tidak terselesaikan sepenuhnya, dan karena perubahan ini rapuh serta menyentuh core power management, tidak dicoba untuk upstream

Workaround userspace: amdgpu-sleep

  • Pada 2024-10, setelah menutup SuperTuxKart lalu suspend, layar hitam muncul saat resume
    • Menurut log, percobaan suspend pertama mengalami OOM di dpm_prepare(), dan percobaan berikutnya berujung pada crash alokasi memori bw_calcs() milik amdgpu saat resume
  • Pendekatan pencadangan VRAM userspace milik NVIDIA dijadikan referensi
    • NVIDIA melakukan pencadangan dan pemulihan VRAM dengan menulis ke /proc/driver/nvidia/suspend dari layanan yang dijalankan sebelum dan sesudah systemd memanggil kernel suspend
  • Berdasarkan itu, dibuat paket amdgpu-sleep untuk Arch Linux
    • Sebelum suspend, paket membaca /sys/kernel/debug/dri/1/amdgpu_evict_vram
    • Endpoint debug ini memerintahkan amdgpu untuk menyimpan seluruh VRAM ke RAM sistem
    • systemd menunggu sampai GPU VRAM eviction selesai, lalu memulai kernel suspend
  • Saat mensuspend desktop, VRAM cepat disalin ke memori dan, bila perlu, RAM didorong ke swap sehingga berhasil
  • Ketika beberapa aplikasi 3D sedang berjalan, aplikasi-aplikasi itu terus merender frame dan membawa VRAM kembali ke GPU, sehingga terjadi livelock tarik-menarik dengan amdgpu_evict_vram
    • Kondisi ini berlanjut lebih dari 70 detik sebelum amdgpu_evict_vram menyerah
    • Setelah itu systemd memulai kernel suspend dan membekukan userspace, sehingga pada tahap kernel VRAM eviction berhasil
  • Skrip ini terus digunakan karena frekuensi livelock tidak lebih rendah daripada frekuensi crash tingkat kernel saat skrip dimatikan

Patch final: power management notifier

  • Pada 2024-11, Mario meminta pengujian patch yang mengizinkan eviction selagi swap masih aktif
  • Patch tersebut menggunakan struktur yang memanggil register_pm_notifier(), dengan memanfaatkan API power management notifier Linux
  • Callback menerima pesan PM_HIBERNATION_PREPARE dan PM_SUSPEND_PREPARE, lalu memanggil amdgpu_device_evict_resources()
  • PM_SUSPEND_PREPARE diterbitkan di enter_state() → suspend_prepare() melalui pm_notifier_call_chain_robust(PM_SUSPEND_PREPARE, PM_POST_SUSPEND)
    • PM_SUSPEND_PREPARE dikirim ke driver yang memiliki callback notifier
    • Jika terjadi kegagalan, PM_POST_SUSPEND dikirim ke driver yang sudah disiapkan dan suspend dihentikan
  • Jika VRAM dievict di lokasi ini, waktunya adalah sebelum pm_restrict_gfp_mask() menonaktifkan swap dan saat disk juga belum dibekukan
  • Alur yang sudah diperbaiki adalah sebagai berikut
    • suspend_prepare()
    • PM_SUSPEND_PREPARE
    • amdgpu_device_pm_notifier() → amdgpu_device_evict_resources()
    • pm_restrict_gfp_mask()
    • dpm_prepare()
    • dpm_suspend()
  • Setelah membangun dan menguji kernel kustom yang berisi driver amdgpu yang sudah diperbaiki, tidak ada error meski suspend dilakukan berkali-kali saat penggunaan RAM dan VRAM tinggi
  • Namun, karena amdgpu mencadangkan VRAM sebelum PipeWire atau kernel membisukan speaker, muncul gejala audio berulang selama beberapa detik
  • Setelah beberapa kali code review, perubahan ini digabungkan ke tree amdgpu, dan setelah lebih dari setahun upaya, bug tersebut memasuki tahap penyelesaian

Pembaruan 2025-06 dan revert

  • Awalnya perubahan ini diperkirakan akan masuk ke stable Linux kernel 6.14, tetapi kemudian di-revert karena kemungkinan deadlock
  • Masalah baru yang diperkenalkan terjadi ketika systemd memanggil system suspend tanpa terlebih dahulu membekukan semua proses userspace
    • Kernel mencoba mengevict VRAM ke RAM sistem sebelum membekukan prosesnya sendiri
    • Pada saat yang sama, jika program 3D membawa VRAM kembali ke GPU, proses suspend eviction dapat deadlock
  • Ini mirip dengan livelock yang dialami pada workaround userspace amdgpu_evict_vram
  • Maintainer Linux PM mengusulkan untuk memindahkan pemanggilan pm_restrict_gfp_mask() ke dalam suspend_devices_and_enter()
    • Ini berkaitan dengan arah sebelumnya yang bereksperimen mengizinkan swap saat prepare()
  • Tidak ada rencana untuk mengimplementasikan dan mengirimkannya sendiri
    • Karena GPU AMD sudah dipindahkan ke komputer lama dengan CPU yang lebih lambat dan memori 8GB, dan tidak ingin menjalankan build kernel di lingkungan itu
  • Komputer utama sudah di-upgrade ke Intel Arc B570, tetapi masalah jenis yang sama terjadi bahkan dengan VRAM 10GB
    • Masalah tersebut dilaporkan ke drm/xe kernel bug tracker

Bacaan terkait

1 komentar

 
GN⁺ 2025-02-18
Komentar Hacker News

  • Asumsi bahwa saat desktop masuk ke sleep S3, daya ke GPU PCIe terputus belum tentu benar
    Memang S3 mematikan semua daya kecuali RAM, tetapi misalnya motherboard Gigabyte Aorus terkenal bermasalah karena bug sleep pada SSD NVMe yang membuat sistem gagal tidur atau bangun dengan benar
    Biasanya ini bisa diakali dengan aturan udev yang memblokir wakeup pada semua port PCIe: ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
    Bisa juga dipersempit hanya ke port PCIe yang bermasalah, misalnya ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc", dan penyebabnya bisa dicari lewat /proc/acpi/wakeup, /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID, udevadm info --attribute-walk /dev/whatever
    Selain udev, /proc/acpi/wakeup juga bisa ditoggle dari layanan systemd atau skrip otomatisasi, tetapi itu kurang andal, dan masalah sleep Linux seperti ini benar-benar sangat menjengkelkan

    • Di motherboard saya, saya harus menambahkan ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled" ke /etc/udev/rules.d/ untuk mencegah wakeup spontan
      Saya juga tidak tahu kenapa receiver Logitech Bolt langsung membangunkan beberapa komputer Linux sementara di Windows tidak, dan tidak jelas apakah untuk menangkap USB perlu alat seperti logic analyzer atau Glasgow
      Sebagai solusi sementara, saya menambahkan aturan ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled" untuk memblokirnya
    • Saya rasa sudah beberapa kWh terbuang karena masalah ini di motherboard Aorus, jadi saya berharap ada solusi, tetapi dalam kasus saya ini tidak berhasil
    • Saya juga mengalami masalah sleep di X570 Aorus Master, dan terselesaikan dengan menjalankan echo GPP0 >> /proc/acpi/wakeup dari unit systemd saat boot
      Namun sleep pertama setelah boot selalu langsung bangun lagi, dan setelah menerapkan aturan udev di atas, tampaknya masalah itu juga teratasi
    • Orang jadi berharap ada cara mendeteksi apakah hardware benar-benar berhasil tidur, atau setidaknya aman untuk membangunkan kembali hardware yang sebenarnya tidak sempat tidur
      Sepertinya seharusnya memungkinkan untuk mengirim perintah sleep ke perangkat PCIe, lalu menidurkan bus itu sendiri, dan saat bangun, menghidupkan kembali bus terlebih dahulu sebelum membangunkan perangkat
    • Saya sempat lama bergelut dengan masalah ini, tetapi cara ini juga tidak berhasil, dan catatan saya ada di https://bbs.archlinux.org/viewtopic.php?id=302440
      Dalam kasus saya, sumber wakeup tampaknya berasal dari .../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6, tetapi saya tidak terlalu paham arti jalur itu

  • Sebagai penulis memreserver, salah satu workaround user-space yang disebutkan, saya pernah men-debug masalah ini beberapa tahun lalu
    Komentar publik yang cepat ditemukan ada di https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17..., dan saya juga ingat pernah ada diskusi di mailing list
    Intinya, Linux saat itu tidak punya hook suspend bertahap yang bisa dijalankan secara andal sebelum disk dan sebagian subsistem memori membeku, dan sekarang tampaknya itu sudah dimungkinkan
    Sayangnya Gitlab Freedesktop tampaknya tidak terindeks dengan baik, jadi pengetahuan ini seperti terkubur

  • Benar-benar pekerjaan yang luar biasa
    Jika Anda pernah bertanya-tanya kenapa transisi suspend di Linux sulit dibuat bekerja dengan benar dan juga sulit di-debug, tulisan ini sendiri sudah menunjukkan betapa banyak titik yang bisa rusak
    Bahkan sekarang di ThinkPad P1G4, jika kipas tidak dimatikan manual sebelum suspend, kipas tidak mati otomatis, dan belakangan ini setelah resume dari suspend muncul noise di headphone Bluetooth sehingga saya juga harus mematikan suspend node PipeWire: https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...

    • Mengejutkan bahwa meskipun sudah tahun 2025, sleep/suspend di laptop Linux masih belum benar-benar beres
      Saya pertama kali mengalami masalah seperti ini mungkin sekitar 15 tahun lalu
    • Suspend benar-benar soal untung-untungan, dan bug seperti yang muncul di tulisan itu juga sangat sulit di-debug
      Di antara solusi sementara yang disarankan untuk berbagai masalah, ada yang menyuruh mematikan mode hemat daya, tetapi tujuan memakai suspend biasanya untuk memperpanjang daya tahan baterai, jadi pendekatan seperti ini kurang realistis karena bisa sangat mengurangi waktu pakai nyata
      Meski begitu, bukan berarti membuat suspend S0ix berfungsi itu mustahil
      Saya memasang Arch Linux di perangkat genggam berbasis AMD 7840U dan AMD 8840U, yaitu GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3, OneXPlayer X1 Ryzen, dan tampaknya kecil kemungkinan perusahaan-perusahaan ini merancang atau mengujinya dengan dukungan Linux dalam pikiran
      Namun, hanya dengan sedikit menyetel sumber wake palsu di /proc/acpi/wakeup dan /sys/devices/*/*/*/power/wakeup, saya bisa mendapatkan dukungan S0ix yang hampir sempurna pada semuanya kecuali OneXPlayer X1 Ryzen terbaru
      Dukungan kernel Linux bawaan juga sangat bagus: layar sentuh, input pena, Wi-Fi, dan Bluetooth berjalan baik, dan satu-satunya kekurangan yang saya lihat adalah dukungan pembaca sidik jari
      Pabrikan kecil seperti ini cenderung tidak melakukan kustomisasi komponen yang ekstrem atau integrasi yang terlalu rapat, dan itu memang terlihat dari perangkat mereka yang beberapa mm lebih tebal
      Jadi mereka mungkin membuat pilihan komponen yang lebih konservatif, dan hasilnya dukungan Linux justru lumayan bagus secara tak terduga
    • Agar pengguna akhir bisa memakai suspend dengan mudah dan andal, solusinya adalah membeli perangkat keras dengan kompatibilitas yang sudah terbukti
      Dari pengalaman saya, ThinkPad bisnis sudah sangat stabil sejak lama, dan pengguna Windows dengan model yang sama justru tampaknya lebih sering mengalami masalah suspend

  • Secara pribadi saya sangat berterima kasih
    Laptop utama saya adalah ThinkPad berbasis Ryzen yang menjalankan Linux, dan saya sering memakai suspend dan hibernasi; saya sudah mengalami masalah ini sesekali
    Saya menantikan Linux 6.14

  • Alasan dm->cached_state menyimpan -12 alih-alih pointer kemungkinan besar karena saat suspend dm_suspend() langsung mengisikan dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev))
    drm_atomic_helper_suspend() yang dipanggil bisa mengembalikan pointer valid atau ERR_PTR(err) yang mengenkode error sebagai pointer negatif, tetapi pemanggil tidak memeriksa error dan langsung menyimpannya sebagai pointer lalu mendereferensikannya saat resume
    Ini menambah satu alasan lagi kenapa kernel perlu Rust, karena jika penanganan tipe Result dipaksakan, kejadian seperti ini akan lebih sulit terjadi

    • Bahkan dengan preprocessor C, kita bisa membuat algebraic sum type: https://github.com/Hirrolot/datatype99
      Tetapi default itu penting, dan sejarah kernel yang sudah lama menunda modernisasi praktik penulisan kode membuat perbaikan di sisi C menjadi kurang menguntungkan
      Ironisnya, resistensi yang sama juga membuat para pengembang Rust frustrasi, karena bahkan merapikan tiap subsistem atau mendokumentasikan cara kerjanya saja sering tidak diterima dengan baik
      Hal seperti https://github.com/llvm/llvm-project/issues/74205 mungkin bisa membantu jika sampai ke kernel, tetapi tetap saja sepertinya mereka akan terus memilih pendekatan meng-overload pointer secara manual daripada mengamankan keselamatan lewat tipe

  • Saya memakai dual boot Linux/Windows di laptop Framework AMD dengan modul ekspansi GPU, jadi pekerjaan ini sepertinya akan membantu
    Saya ingin mendukung langsung atau berdonasi ke badan amal pilihan Anda; kontak saya ada di profil

  • Saya dulu mengira penamaan, invalidasi cache, dan bug off-by-one adalah dua masalah terbesar dalam ilmu komputer, tetapi setelah tahu soal masalah sleep/wake, ini terlihat seperti NP-lengkap

    • Saya menganggap sleep/wake sebagai subset dari invalidasi cache
      Jika semua periferal tidak memiliki state, mungkin ini tidak akan jadi masalah
    • Hanya begitu di Linux; di Windows O(n²), di macOS O(log n)

  • Di Linux, manajemen memori dan khususnya situasi OOM masih merupakan mimpi buruk yang menyakitkan dan sulit dipercaya
    Bukan berarti masalah seperti ini selalu dialami, tetapi jelas pernah gagal saat mencoba men-debug masalah serupa, dan pada akhirnya ketika OOM terjadi biasanya orang hanya menambah RAM
    Itu boros dan mahal, tetapi menangani situasi OOM secara elegan tampaknya akan tetap menjadi masalah yang sulit diselesaikan Linux
    Pekerjaan kali ini sangat bagus, dan akan menjadi patokan saat men-debug masalah serupa di masa depan
    Fitur debug-shell di systemd juga menarik, dan saya tidak tahu sebelumnya bahwa fitur seperti itu ada
    Hanya saja, sepertinya board X670E Steel Legend saya tidak punya serial header, jadi saya penasaran bagaimana port serial bawaan bekerja akhir-akhir ini
    Apakah terhubung ke lane PCIe chipset
    Saat menggali kernel Linux, rekaman presentasi subsistem kernel dari acara seperti FOSDEM atau Linux Plumbers Conference sangat membantu; misalnya, video subsistem memori TTM yang dipakai sebagian besar driver DRM GPU desktop ada di sini: https://www.youtube.com/watch?v=MG7_tUNKSt0

    • Di Windows, port serial motherboard saya ditampilkan terhubung ke Pci Bus → PCI standard ISA bridge
      Hidup DOS
      Videonya tentang TTM akan saya tonton kalau ada waktu
    • Mengurung OOM dengan cgroups cukup berhasil
      Saya tidak begitu tahu apakah ada pendekatan penanganan OOM modern yang lebih baik daripada yang dilakukan Linux, dan kalau ada bacaan yang layak soal itu saya ingin tahu
    • Betul, bahkan kalau mau dibilang baik pun ini tetap mengerikan
      Linux tidak mampu menangani situasi OOM dengan semestinya
      Saya tahu kita bisa memasang pagar pengaman dengan cgroups, memasang earlyoom, menambah swap, atau memakai zram
      Tapi pada akhirnya itu semua cuma hack kotor yang kadang bisa menyelamatkan sekali-sekali, dan tidak memperbaiki cara situasi seperti ini ditangani
      Saya harap ini tidak terus diajukan sebagai solusi
      Saya pernah melihat kernel gagal mengalokasikan memori di dm_crypt sehingga volume LUKS me-remount dirinya sebagai read-only; tolong, bunuh saja satu proses user-space
      Keadaan saat ini sama sekali tidak bisa diterima, dan saya lelah dengan pembelaannya
    • Penasaran apakah Anda sudah mencoba zswap/zram
      Dengan zstd, 8GB RAM bisa dipakai seperti 20GB 'RAM' tanpa banyak masalah, dan 16GB seperti 40GB
      Lebih nekat lagi, memori bahkan bisa diovercommit lebih dari 100%, dan Android juga melakukan ini, jadi pendekatan ini cukup stabil

  • Kabar baik
    Driver grafis Linux dari AMD secara umum bekerja dengan baik, tetapi masalah ini adalah pengecualian yang saya alami beberapa kali

    • Keberuntungan saya sedikit lebih buruk
      Masalah yang belakangan saya alami adalah setelah bangun dari suspend, driver terus menulis WARNING: CPU: 12 PID: 11871 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100 generic_reg_update_ex+0x1d2/0x290 [amdgpu] lalu "[drm] scheduler comp_1.0.n is not ready, skipping" ke log
      https://gitlab.freedesktop.org/drm/amd/-/issues/3911
    • Pengalaman saya juga secara umum bagus, tetapi masalah serupa muncul jika Thunderbolt yang terhubung ke monitor dicabut saat perangkat sedang tidur
      Hanya saja ini laptop, jadi susunan drivernya sangat berbeda dan juga tidak ada GPU PCIe

  • Menyimpan modul kernel amdgpu.ko, mengekstraknya, mendekompilasinya dengan Ghidra, lalu memetakan lokasi crash di dm_resume ke baris yang sesuai di source kernel adalah bagian yang selalu paling saya sukai dalam debugging