AMD GPU’larda Linux uyku-uyanma sırasında oluşan kilitlenmenin izlenip düzeltilme süreci

 (nyanpasu64.gitlab.io)
1 puan yazan GN⁺ 2025-02-18 | 1 yorum | WhatsApp'ta paylaş
  • AMD RX 570 tabanlı bir Linux masaüstünde RAM kullanımının yüksek olduğu durumda uykuya geçildiğinde, uyanma sonrasında siyah ekran veya girişlerin çalışmaması tekrar tekrar yaşandı; bu yüzden sadece bir ekran sorununu değil, çekirdeğin güç yönetimi akışını da izlemek gerekti.
  • Temel neden, S3 uykusundan önce VRAM’i sistem RAM’ine yedeklemesi gereken amdgpu’nun, boş RAM’in yetersiz olduğu durumda disk swap’ını düzgün kullanamayıp OOM ile çökmesine yol açan akıştı.
  • VRAM eviction işlemini dpm_suspend() içinden dpm_prepare() aşamasına erkene alan ilk yama, SSD’nin güç kesilmesiyle yaşanan yarış durumunu azalttı; ancak pm_restrict_gfp_mask() zaten swap’ı devre dışı bıraktığı için bitişik bellek yetersizliği sorunu devam edebiliyordu.
  • Daha sonra register_pm_notifier() ile PM_SUSPEND_PREPARE anında amdgpu_device_evict_resources() çağrılacak şekilde değiştirildiğinde, swap ve disk hâlâ ayaktayken VRAM yedeklenebildi; test ortamında yüksek RAM ve VRAM kullanımında bile uyku başarılı oldu.
  • Bu değişiklik amdgpu ağacına birleştirildi, ancak deadlock olasılığı nedeniyle 2025-06’da geri alındı; kullanıcı süreçlerini önce freeze etmeyen uyku yolunda 3D uygulamalar VRAM’i yeniden GPU’ya çekerek eviction işlemini engelleyebiliyordu.

Tekrarlanan uyku hataları ve ilk yanlış teşhis

  • Masaüstü, Windows ve Linux çift önyüklemeli bir yapıdaydı; Linux’ta RAM kullanımı yüksekken uyku denenince sistem sık sık bozuluyordu.
    • Uyanma sonrası bazen sadece siyah ekran ve hareket eden imleç görülüyor, bazen de görüntü olmadan yalnızca magic SysRq veya sert reset tepki veriyordu.
    • Bazı durumlarda KDE kilit ekranındaki saat gerçek zamanlı güncelleniyor ama giriş veya etkileşim sırasında sistem kilitleniyordu.
  • Test ortamı Gigabyte B550M DS3H, AMD RX 570 GPU, Kingston A2000 1TB NVMe SSD, Arch Linux, systemd-boot ve Linux 6.4 idi.
  • journalctl --system -b -1 ile önceki açılış kayıtları incelendiğinde, bazı uyku denemelerinde amdgpu_device_suspend altındaki çekirdek kodunda OOM hatası görüldü.
  • Başarısız örneklerin çoğu şu kayıtlarla bitiyor, bozulmuş sistemin yeniden uyandığına dair kayıt kalmıyordu.
    • systemd-sleep: Entering sleep state 'suspend'...
    • kernel: PM: suspend entry (deep)
  • İlk başta NVMe APST uyku modu şüpheli görüldü; nvme_core.default_ps_max_latency_us=0, iommu=soft, SSD firmware güncellemesi ve 2TB önyükleme SSD’sinin değiştirilmesi denendi ama sorun çözülmedi.

Hata noktasını daraltan hata ayıklama araçları

  • systemd’nin birden fazla uyku modunu art arda denemesi, log gürültüsü ve çekirdek durumunun daha da bozulmasına yol açabildiği için /etc/systemd/sleep.conf içine SuspendState=mem eklendi.
    • Hata ayıklama basitleşti, ama temel neden ortadan kalkmadı.
  • echo 1 > /sys/power/pm_trace ile uyku hatasının nerede oluştuğu izlendi.
    • pm_trace, uyku-uyanma ilerleme durumunu sistem saatine kaydeder.
    • Asenkron uyku devre dışı kaldığı için, amdgpu suspend hatasından sonra tüm sistemin tamamen asılması yerine toparlandığı durumlar da gözlendi.
  • systemd.debug_shell çekirdek parametresi eklenerek KDE veya TTY oturumu açmadan da Ctrl-Alt-F9 üzerinde root shell açılması sağlandı.
  • USB denetleyicisi ve klavyenin bozulabileceği düşünülerek PS/2 klavye kullanıldı; sonrasında seri konsol kuruldu.
    • Çekirdek parametreleri: no_console_suspend console=tty0 console=ttyS0,115200 loglevel=8
    • Dizüstü bilgisayarda sudo minicom --device /dev/ttyUSB0 --baudrate 115200 ile loglar sürekli yakalandı.
    • Seri konsol, ekran ve ağ bozulduktan sonra bile komut çalıştırma ve log toplama olanağı verdi; ancak aktarım hızı ile renk/ekran boyutu işleme açısından kısıtları vardı.

amdgpu VRAM eviction ile OOM arasındaki bağ

  • Çökme logları çoğunlukla amdgpu’nun TTM buffer eviction yolunda oluşuyordu.
    • amdgpu_device_evict_resources()
    • amdgpu_ttm_evict_resources()
  • İlgili hata raporlarında “evict” işleminin, VRAM’in sistem RAM’ine kopyalanması veya sistem RAM’inin swap’a taşınmasıyla ilgili olduğu görüldü.
  • Masaüstü S3 uykusuna girdiğinde PCIe GPU’nun gücü kesiliyor ve VRAM çiplerindeki veri kayboluyor.
    • GPU sürücüsü, uykuya geçmeden önce kullanımda olan VRAM’i sistem RAM’ine kopyalamalıdır.
    • Uyanma sonrası da RAM’de saklanan veriyi geri yüklemelidir.
  • Linux amdgpu sürücüsünde, kullanımda olan tüm VRAM’i alacak kadar boş RAM olmadığında sistem RAM’ini disk tabanlı swap’a taşımak yerine bellek yetersizliğinden çökme sorunu vardı.
  • Linux suspend sırasında OOM ile karşılaşırsa uykuyu iptal edip aygıtları yeniden başlatmaya çalışır; ancak yarıda kalmış uyku nedeniyle bazı sürücüler bozulabilir veya suspend/resume sırasında yeniden OOM oluşabilir.
    • Asenkron uyku açıksa risk daha da artar.
    • Uykunun kendisi başarılı olsa bile, resume sırasında aygıt başlatma aşamasında OOM yaşanabilir.

İlk çözüm denemesi: VRAM yedekleme anını öne çekmek

  • Mario Limonciello, /sys/power/pm_print_times ve /sys/power/pm_debug_messages seçeneklerinin açılıp uyku loglarının incelenmesini önerdi.
  • Loglarda NVMe ve amdgpu sürücülerinin uyku sırasında pci_pm_suspend içine paralel olarak girdiği görüldü.
  • İlk olarak GPU suspend aşamasını SSD suspend’den önceye almanın yolu arandı ve Linux’un aygıt suspend sıralama mekanizması incelendi.
    • Bu mekanizma, tüm GPU’ları tüm sistem disklerinden önce suspend etmekten ziyade, birbirine sıkı bağlı çevre birimlerini senkronize etmeye daha uygun görünüyordu.
  • Mario, Linux suspend sürecinin prepare aşamasında VRAM eviction yapılmasını önerdi ve VRAM eviction’ı dpm_suspend() içinden dpm_prepare() aşamasına taşıyan bir çekirdek yaması hazırladı.
  • Değişiklik öncesi ve sonrası akış şöyleydi:
    • Eski durumda: VRAM yedeklemesi dpm_suspend() aşamasında yapılıyor, bu da SSD kapanışıyla çakışabiliyordu.
    • Yeni durumda: VRAM yedeklemesi dpm_prepare() içinde daha önce deneniyor, başarısız olursa diğer aygıtlar suspend edilmeden uyku iptal ediliyordu.
  • Bu değişiklik öncekinden iyiydi ama pm_restrict_gfp_mask() fonksiyonunun dpm_prepare() öncesinde swap’ı kapatması nedeniyle yüksek RAM kullanımında hâlâ başarısız oluyordu.
    • amdgpu_ttm_evict_resources() bitişik bellek yetersizliği nedeniyle başarısız olabiliyordu.
    • Tüm VRAM RAM’e sığsa bile, sonrasında sürücünün yapacağı tahsisler için yeterli alan kalmazsa uyku veya uyanma sırasında OOM oluşabiliyordu.

Ghidra ile bulunan ayrı bir amdgpu çökmesi

  • Testler sırasında BUG: unable to handle page fault for address: fffffffffffffffc hatası görüldü ve bu, neredeyse null olan bir işaretçinin çözülmesi gibi görünüyordu.
  • Çökme logu dm_resume+0x200 konumunu işaret ediyordu ama kaynak koddaki satır numarası verilmiyordu.
  • amdgpu.ko çekirdek modülü kaydedilip çıkarıldıktan sonra Ghidra ile decompile edilerek dm_resume içindeki çökme noktası çekirdek kaynak satırlarıyla eşleştirildi.
  • Sorun for_each_new_crtc_in_state(dm->cached_state, crtc, new_crtc_state, i) makrosunda ortaya çıktı.
    • dm->cached_state geçerli bir işaretçi değil, fffffffffffffff4 idi.
    • Sonrasında [RSI + 0x8] alanı okunurken fffffffffffffffc adresinde page fault oluşuyordu.
  • Nedeni, dm_suspend() içinde drm_atomic_helper_suspend() dönüş değerinin doğrudan işaretçiye yazılmasıydı.
    • drm_atomic_helper_suspend() geçerli bir işaretçi veya ERR_PTR(err) döndürebilir.
    • OOM nedeniyle -ENOMEM (-12) dönmüş ve amdgpu suspend kodu bunu işaretçi sanarak çözmeye çalışmış görünüyordu.
  • Mario, hata dönüş değerini kontrol edip suspend’i durduran kod ekleyerek bu sorunu düzeltti.

Vazgeçilen yön: prepare() sırasında swap’a izin vermek

  • Yüksek RAM kullanımında uyku hatasının sürmesinin nedeni, amdgpu’nun dpm_prepare() içinde VRAM yedeklemesi yapmasına rağmen bu noktada pm_restrict_gfp_mask() yüzünden disk swap’ının zaten kapatılmış olmasıydı.
  • Bir denemede dpm_prepare() sırasında swap’a izin verilmesi ve swap’ın ancak dpm_suspend() diskleri kapatmadan hemen önce devre dışı bırakılması hedeflendi.
  • Bunun için pm_restrict_gfp_mask() çağrısını enter_state() içinden daha derindeki dpm_suspend_start() içine taşıyan bir deney yapıldı.
  • Pratik kısıtlar büyüktü.
    • pm_restrict_gfp_mask() bildirimi kernel/power/power.h içinde ve çağrısı kernel/power/suspend.c içindeydi.
    • Taşınmak istenen konum drivers/base/power/main.c idi ve bu dosya normalde kernel/power/ başlıklarını içermez.
    • Geçici bir hack olarak #include <../kernel/power/power.h> eklendi, ancak bunun upstream’e kabul ettirilmesi zor bir yapıydı.
  • Hibrit uyku tarafında da doğruluk sorunları vardı.
    • Hibrit uyku, sistem imajını kaydederken pm_restrict_gfp_mask() çağırıyor ve swap devre dışıyken suspend_devices_and_enter() fonksiyonunu çağırıyor.
    • Aynı fonksiyon tekrar çağrılırsa uyarı oluşuyor ve pm_restore_gfp_mask() swap’ı yeniden açamayabiliyordu.
  • Testlerde hata veya çökme sıklığı azaldı ama tamamen çözülmedi; ayrıca çekirdek güç yönetiminin merkezine dokunan kırılgan bir değişiklik olduğu için upstream’e gönderilmedi.

Kullanıcı alanı geçici çözümü: amdgpu-sleep

  • 2024-10’da SuperTuxKart kapatıldıktan sonra uykuya geçilip uyanıldığında siyah ekran oluştu.
    • Loglara göre ilk uyku denemesi dpm_prepare() aşamasında OOM ile bitti, sonraki deneme ise resume sırasında amdgpu’nun bw_calcs() bellek tahsis çökmesine dönüştü.
  • NVIDIA’nın kullanıcı alanı VRAM yedekleme yaklaşımı incelendi.
    • NVIDIA, systemd’nin çekirdek suspend çağrısından önce ve sonra çalışan servislerde /proc/driver/nvidia/suspend dosyasına yazarak VRAM yedekleme ve geri yükleme yapıyor.
  • Bunun üzerine Arch Linux için amdgpu-sleep paketi oluşturuldu.
    • Uykudan önce /sys/kernel/debug/dri/1/amdgpu_evict_vram okunuyor.
    • Bu debug ucu, amdgpu’ya tüm VRAM’i sistem RAM’ine kaydetmesini söylüyor.
    • systemd, GPU VRAM eviction tamamlanana kadar bekliyor ve ardından çekirdek suspend sürecini başlatıyor.
  • Masaüstünde uykuya geçerken VRAM hızla belleğe kopyalanıyor, gerekirse RAM swap’a itiliyor ve işlem başarılı oluyordu.
  • Birden fazla 3D uygulama çalışırken uygulamalar sürekli kare üretip VRAM’i tekrar GPU’ya çekiyor, bu da amdgpu_evict_vram ile çekişmeli bir livelock yaratıyordu.
    • Bu durum 70 saniyeden fazla sürdükten sonra amdgpu_evict_vram vazgeçiyordu.
    • Sonrasında systemd çekirdek suspend sürecini başlatıyor ve userspace freeze edildiğinde çekirdek aşamasında VRAM eviction başarıyordu.
  • Bu betik, kapatıldığında çekirdek düzeyinde çökme yaşanma sıklığı, livelock oluşma sıklığından daha düşük olmadığı için kullanılmaya devam edildi.

Son yama: power management notifier

  • 2024-11’de Mario, swap hâlâ etkin durumdayken eviction yapılmasına izin veren bir yamanın test edilmesini istedi.
  • Yama register_pm_notifier() çağıran bir yapıdaydı ve Linux’un power management notifier API’sini kullanıyordu.
  • Geri çağırım, PM_HIBERNATION_PREPARE ve PM_SUSPEND_PREPARE mesajlarını alıp amdgpu_device_evict_resources() çağırıyordu.
  • PM_SUSPEND_PREPARE, enter_state() → suspend_prepare() içinde pm_notifier_call_chain_robust(PM_SUSPEND_PREPARE, PM_POST_SUSPEND) üzerinden yayınlanır.
    • Notifier geri çağırımı olan sürücülere PM_SUSPEND_PREPARE iletilir.
    • Hata olursa, önceden hazırlanmış sürücülere PM_POST_SUSPEND gönderilir ve uyku iptal edilir.
  • VRAM bu noktada evict edilirse, pm_restrict_gfp_mask() swap’ı kapatmadan önce işlem yapılmış olur ve diskler de henüz freeze edilmemiş durumdadır.
  • Düzeltilmiş akış şöyleydi:
    • suspend_prepare()
    • PM_SUSPEND_PREPARE
    • amdgpu_device_pm_notifier() → amdgpu_device_evict_resources()
    • pm_restrict_gfp_mask()
    • dpm_prepare()
    • dpm_suspend()
  • Düzeltilmiş amdgpu sürücüsünü içeren özel bir çekirdek derlenip test edildiğinde, yüksek RAM ve VRAM kullanımında defalarca uykuya geçilmesine rağmen hata oluşmadı.
  • Ancak amdgpu, PipeWire veya çekirdek hoparlörleri sessize almadan önce VRAM’i yedeklediği için birkaç saniye boyunca sesin tekrar etmesi gibi bir yan etki görüldü.
  • Birkaç kod incelemesinden sonra bu değişiklik amdgpu ağacına birleştirildi ve bir yılı aşkın uğraşın ardından ilgili hatayı çözüme götüren adım oldu.

2025-06 güncellemesi ve geri alma

  • Başta bu değişikliğin kararlı Linux çekirdeği 6.14’e girmesi bekleniyordu, ancak daha sonra olası deadlock nedeniyle geri alındı.
  • Yeni ortaya çıkan sorun, systemd’nin tüm kullanıcı alanı süreçlerini önce freeze etmeden sistem suspend çağrısı yapması halinde oluşuyordu.
    • Çekirdek, süreçleri kendi başına freeze etmeden önce VRAM’i sistem RAM’ine evict etmeye çalışıyordu.
    • Aynı anda 3D programlar VRAM’i yeniden GPU’ya çekerse suspend eviction süreci deadlock’a girebiliyordu.
  • Bu, kullanıcı alanındaki amdgpu_evict_vram geçici çözümünde görülen livelock’a benziyordu.
  • Linux PM bakımcısı, pm_restrict_gfp_mask() çağrısının suspend_devices_and_enter() içine taşınmasını önerdi.
    • Bu, daha önce denenmiş olan prepare() sırasında swap’a izin verme yönüyle örtüşüyor.
  • Bunu doğrudan uygulayıp göndermeyi planlamıyor.
    • Çünkü AMD GPU, daha yavaş CPU’ya ve 8GB belleğe sahip eski bir bilgisayara taşındı ve o ortamda çekirdek derlemek istemiyor.
  • Ana bilgisayar Intel Arc B570’e yükseltildi, ancak 10GB VRAM ile aynı türden sorun yine ortaya çıktı.
    • Bu sorun drm/xe çekirdek hata takip sistemine raporlandı.

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-18
Hacker News yorumları

  • Masaüstü S3 uyku moduna girdiğinde PCIe GPU’nun gücünün kesildiği varsayımı kesin değil
    S3’ün RAM dışında tüm gücü kesmesi doğru, ancak örneğin Gigabyte Aorus anakartlar, NVMe SSD uyku hatası yüzünden sistemin düzgün uyuyamaması veya uyanamamasıyla kötü şöhretli
    Genelde tüm PCIe portlarının uyandırmasını engelleyen bir udev kuralıyla etrafından dolaşılabiliyor: ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
    Daha dar kapsamlı olarak yalnızca sorunlu PCIe portu ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc" gibi belirtilebilir; nedeni bulmak için /proc/acpi/wakeup, /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID, udevadm info --attribute-walk /dev/whatever kullanılabilir
    udev yerine bir systemd servisi ya da otomasyon betiğinde /proc/acpi/wakeup anahtarlanabilir, ama bu daha az kararlı; bu Linux uyku sorunları gerçekten bıktırıcı

    • Benim anakartımda kendiliğinden uyanmayı engellemek için /etc/udev/rules.d/ içine ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled" eklemem gerekti
      Logitech Bolt alıcısının da birçok Linux bilgisayarı hemen uyandırıp Windows’ta neden böyle yapmadığını bilmiyorum; USB yakalama yapmak için mantık analizörü ya da Glasgow gibi bir ekipman gerekip gerekmediği de belirsiz
      Geçici olarak ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled" kuralını ekleyip engelledim
    • Aorus anakartta bu sorun yüzünden birkaç kWh harcamışım gibi geldiği için çözümü ummuştum, ama benim durumumda işe yaramadı
    • X570 Aorus Master’da da uyku sorunu yaşıyordum; açılışta bir systemd unit’inden echo GPP0 >> /proc/acpi/wakeup çalıştırınca çözüldü
      Ancak açılıştan sonraki ilk uyku her zaman hemen uyanıyordu; yukarıdaki udev kuralını uygulayınca o sorun da çözülmüş gibi görünüyor
    • Donanımın gerçekten uyuyup uyumadığını algılayabilmesini ya da uyumamış donanımı tekrar uyandırmanın sorun çıkarmayacağı şekilde tasarlanmış olmasını bekliyor insan
      PCIe aygıtına uyku komutu gönderdikten sonra veriyolunun kendisini uyutmak, uyandırırken de önce veriyolunu geri getirdikten sonra aygıtı uyandırmak gibi bir şey mümkün olmalı gibi
    • Bu sorunla bir süre uğraştım ama bu yöntem de işe yaramadı; derlediğim notlar https://bbs.archlinux.org/viewtopic.php?id=302440 adresinde
      Benim durumumda uyanma nedeni .../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6 yolundan geliyor gibi, ama bu yolun ne anlama geldiğini pek bilmiyorum

  • Bahsedilen kullanıcı alanı geçici çözümlerinden biri olan memreserver’ın yazarı olarak, bu sorunu birkaç yıl önce debug etmiştim
    Hızlıca bulunabilen herkese açık yorum https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17...; posta listesinde de bir tartışma olduğunu hatırlıyorum
    Asıl mesele, Linux’ta disk ve bellek alt sistemlerinin bazı kısımları donmadan önce güvenilir şekilde çalışan aşamalı suspend hook’larının olmamasıydı; artık mümkün gibi görünüyor
    Ne yazık ki Freedesktop Gitlab iyi indekslenmiyor gibi, bu yüzden bu bilgi gömülmüş görünüyor

  • Gerçekten harika bir çalışma
    Linux’ta uyku moduna geçişin neden düzgün çalıştırılmasının zor olduğunu ve hata ayıklamasının da neden güç olduğunu merak ettiyseniz, bu yazı tek başına bile bozulabilecek ne kadar çok nokta olduğunu iyi gösteriyor
    Ben hâlâ ThinkPad P1G4’te uyku moduna geçmeden önce fanı elle kapatmazsam otomatik kapanmıyor; yakın zamanda da uykudan döndükten sonra Bluetooth kulaklıklarda gürültü oluştuğu için PipeWire’ın düğüm uyku modunu da kapatmak zorunda kaldım: https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...

    • 2025 yılında bile Linux dizüstülerde sleep/suspend’in hâlâ doğru düzgün çalışmaması şaşırtıcı
      Bu tür bir sorunla ilk karşılaşmam muhtemelen 15 yıl kadar önceydi
    • Uyku modu gerçekten tamamen şansa kalmış durumda; yazıda anlatılan türden hataların hata ayıklaması da çok zor
      Çeşitli sorunlar için önerilen geçici çözümler arasında güç tasarrufu modlarını kapatmak da var; oysa uyku modunu kullanmanın amacı genelde pil süresini uzatmak olduğundan, bu yaklaşım gerçek kullanım süresini ciddi biçimde azaltabileceği için pek pratik değil
      Yine de S0ix uykusunu çalıştırmak imkânsız değil
      AMD 7840U ve AMD 8840U tabanlı taşınabilir cihazlara, yani GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3 ve OneXPlayer X1 Ryzen’e Arch Linux kurdum; bu şirketlerin Linux desteğini düşünerek tasarım veya test yapmış olma ihtimali düşük görünüyor
      Buna rağmen /proc/acpi/wakeup ve /sys/devices/*/*/*/power/wakeup içindeki sahte uyandırma kaynaklarında ufak ayarlar yapmakla, en yeni OneXPlayer X1 Ryzen hariç neredeyse kusursuz S0ix desteği elde ettim
      Temel Linux çekirdeği desteği de harika: dokunmatik ekran, kalem girişi, Wi‑Fi ve Bluetooth iyi çalışıyor; gördüğüm tek eksik parmak izi okuyucu desteği
      Bu küçük ölçekli üreticilerde parçaların aşırı özelleştirilmesi veya çok sıkı entegrasyonu daha az oluyor; bu da cihazların birkaç mm daha kalın olması şeklinde kendini gösteriyor
      Bu yüzden daha muhafazakâr parça seçimleri yapıyor olabilirler ve bunun sonucu olarak Linux desteği beklenmedik derecede iyi çıkıyor olabilir
    • Son kullanıcıların uyku modunu kolayca ve sorunsuz kullanabilmesi için cevap doğrulanmış uyumlu donanım satın almak
      Kendi deneyimime göre iş sınıfı ThinkPad’lerde bu çok uzun zamandır oldukça kararlıydı; hatta aynı modelin Windows kullanıcıları uyku sorunlarını daha sık yaşıyor gibi görünüyor

  • Şahsen gerçekten minnettarım
    Ana dizüstüm Linux çalıştıran Ryzen tabanlı bir ThinkPad ve uyku ile hazırda bekletmeyi sık kullanıyorum; bu sorunu aralıklı olarak yaşıyordum
    Linux 6.14’ü dört gözle bekliyorum

  • dm->cached_state’in bir işaretçi yerine -12 saklamasının nedeni büyük olasılıkla suspend sırasında dm_suspend()’in dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev)) değerini olduğu gibi ataması
    Çağrılan drm_atomic_helper_suspend() geçerli bir işaretçi ya da hatayı negatif işaretçi olarak kodlayan ERR_PTR(err) döndürebiliyor; çağıran taraf hatayı kontrol etmeden bunu doğrudan işaretçiye koymuş ve resume sırasında dereference etmiş
    Çekirdeğe Rust eklemek için bir neden daha; Result tipinin işlenmesi zorunlu olsa böyle bir şeyin gerçekleşmesi zorlaşırdı

    • C önişlemcisiyle de cebirsel toplam tipleri oluşturulabiliyor: https://github.com/Hirrolot/datatype99
      Ama varsayılanlar önemlidir ve çekirdeğin kodlama pratiklerini modernleştirmeyi uzun süredir ertelemiş olması, C tarafındaki iyileştirmelerin aleyhine işliyor
      İronik biçimde aynı direnç Rust geliştiricilerini de hayal kırıklığına uğratıyor; çünkü her alt sistemi toparlamak ya da çalışma biçimini belgelemek bile pek kabul görmüyor
      https://github.com/llvm/llvm-project/issues/74205 gibi bir şey çekirdeğe kadar inerse yardımcı olabilir; ama yine de tiplerle güvenliği sağlamaktansa işaretçileri elle overload etmeyi seçmeye devam edecekler gibi geliyor

  • GPU genişletme modülü takılı bir Framework AMD dizüstünde Linux/Windows çift önyükleme kullandığım için bu çalışma işime yarayacak gibi görünüyor
    Doğrudan sponsor olmak ya da tercih ettiğin bir hayır kurumuna bağış yapmak isterim; iletişim bilgileri profilimde var

  • İsimlendirme, önbellek geçersiz kılma ve off-by-one hatalarının bilgisayar biliminin en büyük iki sorunu olduğunu sanıyordum; sleep/wake sorununu görünce bunun NP-tam gibi olduğunu düşünüyorum

    • sleep/wake’i önbellek geçersiz kılmanın bir alt kümesi olarak görüyorum
      Tüm çevre birimleri durum tutmuyor olsaydı muhtemelen sorun olmazdı
    • Bu sadece Linux’ta böyle; Windows’ta O(n²), macOS’te O(log n)

  • Linux’ta bellek yönetimi ve özellikle OOM durumları hâlâ inanılmaz derecede acı verici bir kâbus
    Bu tür sorunları her zaman yaşamıyorum ama benzer bir sorunu debug etmeye çalışıp başarısız olduğum kesinlikle oldu; sonunda OOM olunca genelde daha fazla RAM takıyorsun
    İsraf ve pahalı, ama OOM durumlarını zarifçe ele almak Linux’un gelecekte de çözmekte zorlanacağı bir sorun gibi görünüyor
    Bu çalışma harika ve ileride benzer sorunları debug ederken bir referans noktası olacak
    systemd’nin debug-shell özelliğini görmek de sevindirici; böyle bir özellik olduğunu bilmiyordum
    Ancak benim X670E Steel Legend anakartımda seri header yok gibi; günümüzde yerleşik seri portların nasıl çalıştığını merak ediyorum
    Yonga setinin PCIe hatlarına mı bağlılar acaba
    Linux çekirdeğinin içine dalarken FOSDEM veya Linux Plumbers Conference gibi yerlerdeki çekirdek alt sistemi sunum kayıtları çok yardımcı oluyor; örneğin çoğu masaüstü GPU DRM sürücüsünün kullandığı TTM bellek alt sistemi videosu burada: https://www.youtube.com/watch?v=MG7_tUNKSt0

    • Windows’ta anakartımdaki seri portun Pci Bus → PCI standard ISA bridge’e bağlı olduğu görünüyor
      Yaşasın DOS
      TTM videosunu zaman bulunca izleyeceğim
    • OOM’u cgroups ile izole etmek oldukça iyi çalıştı
      Linux’un yaptığından daha iyi, modern bir OOM işleme yöntemi var mı pek bilmiyorum; bununla ilgili okunacak bir kaynak varsa öğrenmek isterim
    • Aynen, kibarca söylesek bile korkunç
      Linux OOM durumunu doğru düzgün ele alamıyor
      cgroups ile bariyerler koyabileceğini, earlyoom kurabileceğini, swap’i artırabileceğini veya zram kullanabileceğini biliyorum
      Ama sonuçta bunların hepsi ara sıra bir kez kurtarabilecek kirli hack’lerden ibaret; bu durumların ele alınma şeklini düzeltmiyorlar
      Bunların çözüm olarak sunulmamasını isterim
      Çekirdeğin dm_crypt içinde bellek ayıramadığı için bir LUKS biriminin kendini salt okunur olarak mount ettiğini gördüm; lütfen tek yapmanız gereken bir kullanıcı alanı sürecini öldürmek
      Mevcut durum kesinlikle kabul edilemez ve bahanelerden de yoruldum
    • zswap/zram denedin mi merak ediyorum
      zstd kullanınca 8GB RAM’i pek sorun yaşamadan 20GB “RAM” gibi, 16GB’ı da 40GB gibi kullanabiliyorsun
      Daha cesur davranıp belleği %100’ün üzerinde overcommit de edebilirsin; Android de bunu yaptığı için oldukça kararlı bir yöntem

  • İyi haber
    AMD’nin Linux grafik sürücüsü genel olarak iyi çalıştı ama bu sorun, birkaç kez yaşadığım bir istisnaydı

    • Benim şansım biraz daha kötüydü
      Son zamanlarda yaşadığım sorun, uyku modundan uyandıktan sonra sürücünün WARNING: CPU: 12 PID: 11871 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100 generic_reg_update_ex+0x1d2/0x290 [amdgpu] sonrasında sürekli "[drm] scheduler comp_1.0.n is not ready, skipping" satırını log’a basması
      https://gitlab.freedesktop.org/drm/amd/-/issues/3911
    • Benim deneyimim de genel olarak iyi, ama cihaz uykudayken monitörün bağlı olduğu Thunderbolt’u çıkarırsam benzer bir sorun oluyor
      Ancak bu bir dizüstü olduğu için sürücü yapılandırması epey farklı ve PCIe GPU da yok

  • amdgpu.ko çekirdek modülünü kaydedip çıkararak Ghidra ile decompile ettikten sonra dm_resume içindeki çökme konumunu çekirdek kaynağındaki ilgili satıra eşleştirdikleri kısım, debug süreçlerinde her zaman en sevdiğim sahne