AMD GPU पर Linux सस्पेंड-रिज्यूम हैंग को ट्रैक कर ठीक करने की प्रक्रिया

 (nyanpasu64.gitlab.io)
1 पॉइंट द्वारा GN⁺ 2025-02-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AMD RX 570 आधारित Linux डेस्कटॉप पर RAM उपयोग अधिक होने की स्थिति में सस्पेंड करने पर रिज्यूम के बाद बार-बार काली स्क्रीन या इनपुट न चलने की स्थिति आती थी, इसलिए यह सिर्फ स्क्रीन की समस्या नहीं थी; kernel power management flow तक ट्रैक करना पड़ा
  • मुख्य कारण यह था कि S3 सस्पेंड से पहले VRAM को system RAM में बैकअप करने वाले amdgpu को खाली RAM कम होने पर disk swap का सही इस्तेमाल नहीं हो पा रहा था और वह OOM से ढह जाता था
  • VRAM eviction को dpm_suspend() से dpm_prepare() में पहले ले जाने वाले पहले patch ने SSD power-off के साथ race को घटाया, लेकिन pm_restrict_gfp_mask() पहले ही swap को disable कर देता था, इसलिए contiguous memory की कमी बनी रह सकती थी
  • बाद में register_pm_notifier() के जरिए PM_SUSPEND_PREPARE समय पर amdgpu_device_evict_resources() call करने पर, swap और disk सक्रिय रहते हुए VRAM का backup हो सका, इसलिए test environment में अधिक RAM·VRAM उपयोग के बावजूद suspend सफल रहा
  • यह change amdgpu tree में merge हुआ, लेकिन deadlock की संभावना के कारण 2025-06 में revert कर दिया गया; ऐसे suspend path में जहां user process पहले freeze नहीं होते, 3D apps VRAM को फिर से GPU में खींचकर eviction रोक सकते हैं

बार-बार suspend failure और शुरुआती गलत diagnosis

  • डेस्कटॉप Windows और Linux dual-boot configuration में था, और Linux में RAM usage अधिक होने पर suspend करने की कोशिश में system अक्सर टूट जाता था
    • Resume के बाद केवल काली screen और चलता हुआ cursor दिखता, या display output के बिना सिर्फ magic SysRq या hard reset पर response मिलता
    • कुछ मामलों में KDE lock screen clock real-time में update होती थी, लेकिन login या interaction पर hang हो जाता था
  • Test environment था Gigabyte B550M DS3H, AMD RX 570 GPU, Kingston A2000 1TB NVMe SSD, Arch Linux, systemd-boot, Linux 6.4
  • journalctl --system -b -1 से पिछले boot logs देखने पर, कुछ suspend attempts में amdgpu_device_suspend के नीचे kernel code की OOM errors दिखीं
  • कई failure cases नीचे दिए logs पर समाप्त हुए, और टूटे हुए system के फिर जागने का कोई record नहीं बचा
    • systemd-sleep: Entering sleep state 'suspend'...
    • kernel: PM: suspend entry (deep)
  • शुरुआत में NVMe APST sleep mode पर शक कर nvme_core.default_ps_max_latency_us=0, iommu=soft, SSD firmware upgrade, और 2TB boot SSD replacement आजमाए गए, लेकिन समस्या हल नहीं हुई

Failure location को narrow करने वाले debugging tools

  • systemd द्वारा कई suspend modes लगातार try करने का behavior log noise और kernel state deterioration पैदा कर सकता था, इसलिए /etc/systemd/sleep.conf में SuspendState=mem जोड़ा गया
    • Debugging आसान हुई, लेकिन root cause जस का तस रहा
  • echo 1 > /sys/power/pm_trace से suspend failure location track किया गया
    • pm_trace suspend-resume progress state को system time में store करता है
    • asynchronous suspend disable होने के side effect की वजह से, amdgpu suspend failure के बाद पूरे system hang के बजाय recovery का pattern भी दिखा
  • systemd.debug_shell kernel parameter जोड़कर KDE या TTY login के बिना भी Ctrl-Alt-F9 पर root shell खोलना संभव किया गया
  • USB controller और keyboard टूटने की स्थिति के लिए PS/2 keyboard इस्तेमाल किया गया, और बाद में serial console configure किया गया
    • Kernel parameters: no_console_suspend console=tty0 console=ttyS0,115200 loglevel=8
    • Laptop से sudo minicom --device /dev/ttyUSB0 --baudrate 115200 के जरिए logs लगातार capture किए गए
    • Serial console ने display और network टूटने के बाद भी command execution और log collection संभव बनाया, लेकिन transfer speed और color·screen size handling में सीमाएं थीं

amdgpu VRAM eviction और OOM का संबंध

  • Crash logs आम तौर पर amdgpu के TTM buffer eviction path में आते थे
    • amdgpu_device_evict_resources()
    • amdgpu_ttm_evict_resources()
  • संबंधित bug reports से पता चला कि “evict” VRAM को system RAM में copy करने, या system RAM को swap में ले जाने की प्रक्रिया से जुड़ा है
  • जब desktop S3 suspend में जाता है, PCIe GPU power कट जाती है और VRAM chips का data गायब हो जाता है
    • GPU driver को suspend से पहले इस्तेमाल में मौजूद VRAM को system RAM में copy करना होता है
    • Resume के बाद RAM में stored data को फिर restore करना होता है
  • Linux amdgpu driver में इस्तेमाल हो रही पूरी VRAM रखने जितनी free RAM न होने पर system RAM को disk-based swap में ले जाने के बजाय memory shortage से crash होने की समस्या थी
  • Linux suspend के दौरान OOM मिलने पर suspend cancel कर devices को फिर start करने की कोशिश करता है, लेकिन पहले से रुके suspend के कारण कुछ drivers टूट सकते हैं या suspend/resume के दौरान फिर OOM हो सकता है
    • asynchronous suspend on होने पर risk और बढ़ता है
    • suspend खुद सफल हो सकता है, लेकिन resume के दौरान device start process में OOM आ सकता है

पहला समाधान प्रयास: VRAM backup timing को पहले करना

  • Mario Limonciello ने /sys/power/pm_print_times और /sys/power/pm_debug_messages enable कर suspend logs देखने का सुझाव दिया
  • Logs में दिखा कि NVMe और amdgpu drivers suspend के दौरान pci_pm_suspend में parallel entry कर रहे थे
  • शुरुआत में GPU suspend को SSD suspend से पहले करने का तरीका ढूंढा गया, और Linux का device suspend ordering mechanism भी देखा गया
    • यह mechanism सभी GPUs को सभी system disks से पहले suspend कराने के बजाय closely connected peripherals को synchronize करने के लिए ज्यादा उपयुक्त लगा
  • Mario ने Linux suspend के prepare phase में VRAM evict करने का तरीका सुझाया, और VRAM eviction को dpm_suspend() से dpm_prepare() में ले जाने वाला kernel patch लिखा
  • बदलाव से पहले और बाद का flow यह था
    • पुराना: dpm_suspend() के समय VRAM backup चलता था, जो SSD बंद होने के flow से overlap कर सकता था
    • बदला हुआ: dpm_prepare() में VRAM backup पहले try होता, और fail होने पर दूसरे devices के suspend से पहले suspend रोक दिया जाता
  • यह बदलाव पहले से बेहतर था, लेकिन pm_restrict_gfp_mask() का dpm_prepare() से पहले swap disable कर देना high RAM usage में अब भी failure का कारण बना
    • amdgpu_ttm_evict_resources() contiguous memory shortage से fail हो सकता था
    • VRAM को पूरी तरह RAM में डाल देने पर भी बाद की driver allocations संभालने के लिए enough free space न हो तो sleep या wake के दौरान OOM हो सकता था

Ghidra से मिला अलग amdgpu crash

  • Testing के दौरान BUG: unable to handle page fault for address: fffffffffffffffc error आई, जो लगभग null जैसी pointer dereference लगी
  • Crash log ने dm_resume+0x200 location दिखाया, लेकिन source code की line number नहीं दी
  • amdgpu.ko kernel module को save·extract करने के बाद Ghidra से decompile कर dm_resume के अंदर crash location को kernel source line से map किया गया
  • for_each_new_crtc_in_state(dm->cached_state, crtc, new_crtc_state, i) macro में समस्या हुई
    • dm->cached_state valid pointer नहीं था, बल्कि fffffffffffffff4 था
    • इसके बाद [RSI + 0x8] field पढ़ते समय fffffffffffffffc address पर page fault हुआ
  • कारण dm_suspend() में drm_atomic_helper_suspend() return value को सीधे pointer में store करने वाले flow में था
    • drm_atomic_helper_suspend() valid pointer या ERR_PTR(err) return कर सकता है
    • OOM से -ENOMEM (-12) return हुआ, और अनुमान था कि amdgpu suspend code ने इसे pointer की तरह dereference किया
  • Mario ने failure return value check करने और suspend रोकने वाला code जोड़कर यह समस्या ठीक की

छोड़ी गई दिशा: prepare() के दौरान swap allow करना

  • High RAM usage में suspend failure जारी रहने का कारण था कि amdgpu dpm_prepare() में VRAM backup करता है, लेकिन इस समय तक pm_restrict_gfp_mask() disk swap को पहले ही disable कर चुका होता है
  • एक प्रयास यह था कि dpm_prepare() में swap allow किया जाए, और dpm_suspend() disk बंद करने से ठीक पहले swap disable करे
  • इसके लिए pm_restrict_gfp_mask() call को enter_state() से और गहरे dpm_suspend_start() के अंदर ले जाने का experiment किया गया
  • Practical constraints काफी बड़े थे
    • pm_restrict_gfp_mask() kernel/power/power.h में declared है और kernel/power/suspend.c से call होता है
    • जहां call करने की कोशिश थी वह drivers/base/power/main.c था, और यह file आम तौर पर kernel/power/ headers include नहीं करती
    • Temporary hack के तौर पर #include <../kernel/power/power.h> जोड़ा गया, लेकिन upstream के लिए convincing structure चाहिए था
  • Hybrid suspend में भी correctness issue था
    • Hybrid suspend system image save करता है और pm_restrict_gfp_mask() call करने के बाद swap disabled state में suspend_devices_and_enter() call करता है
    • वही function दोबारा call करने पर warning आती है और pm_restore_gfp_mask() swap फिर से enable नहीं कर पाता
  • Tests में failure या crash frequency घटी, लेकिन पूरी तरह हल नहीं हुआ, और core power management छूने वाला brittle change होने के कारण upstream attempt नहीं किया गया

User space workaround: amdgpu-sleep

  • 2024-10 में SuperTuxKart बंद करने के बाद suspend किया और resume पर black screen आई
    • Logs के अनुसार पहले suspend attempt में dpm_prepare() पर OOM आया, और अगले attempt में resume के दौरान amdgpu के bw_calcs() memory allocation crash तक बात पहुंची
  • NVIDIA के user space VRAM backup method को reference बनाया गया
    • NVIDIA systemd द्वारा kernel suspend call करने से पहले/बाद चलने वाली service से /proc/driver/nvidia/suspend में write कर VRAM backup·restore करता है
  • इसके आधार पर Arch Linux के लिए amdgpu-sleep package बनाया गया
    • Suspend से पहले /sys/kernel/debug/dri/1/amdgpu_evict_vram पढ़ा जाता है
    • यह debug endpoint amdgpu को सारी VRAM system RAM में save करने का निर्देश देता है
    • systemd GPU VRAM eviction पूरा होने तक wait करता है, फिर kernel suspend शुरू करता है
  • Desktop पर suspend करते समय यह जल्दी से VRAM को memory में copy करता है और जरूरत पड़ने पर RAM को swap में धकेलते हुए सफल हो जाता है
  • कई 3D apps चल रहे हों तो apps लगातार frames render करते हुए VRAM को फिर GPU में लाती हैं, जिससे amdgpu_evict_vram के साथ tug-of-war livelock होता है
    • यह state 70 seconds से ज्यादा जारी रहने के बाद amdgpu_evict_vram हार मान लेता है
    • इसके बाद systemd kernel suspend शुरू कर userspace को freeze करता है, तो kernel phase में VRAM eviction सफल हो जाता है
  • यह script जारी रखी गई, क्योंकि script बंद होने पर kernel-level crash की frequency livelock बनने की frequency से कम नहीं थी

अंतिम patch: power management notifier

  • 2024-11 में Mario ने ऐसा patch test करने को कहा जो swap अभी active रहते हुए eviction allow करे
  • Patch register_pm_notifier() call करने की structure में था, और Linux की power management notifier API इस्तेमाल करता था
  • Callback PM_HIBERNATION_PREPARE और PM_SUSPEND_PREPARE messages लेकर amdgpu_device_evict_resources() call करता था
  • PM_SUSPEND_PREPARE enter_state() → suspend_prepare() में pm_notifier_call_chain_robust(PM_SUSPEND_PREPARE, PM_POST_SUSPEND) के जरिए publish होता है
    • notifier callback वाले drivers को PM_SUSPEND_PREPARE deliver होता है
    • Failure होने पर already prepared drivers को PM_POST_SUSPEND deliver होता है और suspend रोक दिया जाता है
  • इस location पर VRAM evict करने से यह pm_restrict_gfp_mask() के swap disable करने से पहले होता है, और disk भी अभी freeze नहीं हुई होती
  • Fixed flow यह है
    • suspend_prepare()
    • PM_SUSPEND_PREPARE
    • amdgpu_device_pm_notifier() → amdgpu_device_evict_resources()
    • pm_restrict_gfp_mask()
    • dpm_prepare()
    • dpm_suspend()
  • Fixed amdgpu driver वाला custom kernel build कर test करने पर, high RAM·VRAM usage में कई बार suspend करने के बावजूद कोई error नहीं आई
  • हालांकि amdgpu के PipeWire या kernel द्वारा speaker mute करने से पहले VRAM backup करने के कारण कुछ seconds तक audio repeat playback की घटना दिखी
  • कुछ rounds की code review के बाद यह change amdgpu tree में merge हुआ, और 1 साल से ज्यादा कोशिशों के बाद उस bug को solve करने की stage तक पहुंचा

2025-06 update और revert

  • शुरुआत में उम्मीद थी कि change stable Linux kernel 6.14 में शामिल होगा, लेकिन बाद में possible deadlock के कारण revert कर दिया गया
  • नया introduce हुआ issue तब होता है जब systemd सभी user space processes को पहले freeze किए बिना system suspend call करता है
    • Kernel अपने-आप processes freeze करने से पहले VRAM को system RAM में evict करने की कोशिश करता है
    • उसी समय अगर 3D program VRAM को फिर GPU में लाता है, तो suspend eviction process deadlock हो सकता है
  • यह user space amdgpu_evict_vram workaround में अनुभव किए गए livelock जैसा है
  • Linux PM maintainer ने pm_restrict_gfp_mask() call को suspend_devices_and_enter() के अंदर ले जाने का प्रस्ताव दिया
    • यह पहले experiment की गई prepare() के दौरान swap allow करने वाली दिशा से जुड़ा है
  • इसे खुद implement·submit करने की योजना नहीं है
    • AMD GPU को धीमे CPU और 8GB memory वाले पुराने computer में move कर दिया गया है, और उस environment में kernel build चलाना नहीं चाहते
  • Main computer को Intel Arc B570 पर upgrade किया गया, लेकिन 10GB VRAM पर भी उसी type की problem आती है
    • यह issue drm/xe kernel bug tracker में report किया गया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-18
Hacker News टिप्पणियां

  • यह धारणा पक्की नहीं है कि desktop के S3 sleep में जाते ही PCIe GPU की power कट जाती है
    S3 में RAM को छोड़कर बाकी सबकी power कटनी चाहिए, लेकिन उदाहरण के लिए Gigabyte Aorus motherboards NVMe SSD sleep bug के लिए बदनाम हैं, जिसकी वजह से system ठीक से sleep या wake नहीं हो पाता
    आम तौर पर सभी PCIe ports की wake-up capability रोकने वाले udev rule से workaround हो जाता है: ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
    और सीमित दायरे में सिर्फ problem वाले PCIe port को ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc" की तरह specify किया जा सकता है, और /proc/acpi/wakeup, /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID, udevadm info --attribute-walk /dev/whatever से root cause ढूंढा जा सकता है
    udev के बजाय systemd service या automation script में /proc/acpi/wakeup toggle भी किया जा सकता है, लेकिन यह कम भरोसेमंद है, और Linux की ऐसी sleep समस्याएं वाकई बेहद परेशान करने वाली हैं

    • मेरे motherboard पर अपने-आप wake-up रोकने के लिए /etc/udev/rules.d/ में ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled" डालना पड़ा
      Logitech Bolt receiver भी कई Linux computers को तुरंत जगा देता है, जबकि Windows में ऐसा क्यों नहीं होता यह समझ नहीं आता; और USB capture करने के लिए logic analyzer या Glasgow जैसी device चाहिए या नहीं, यह भी साफ नहीं है
      फिलहाल इसे रोकने के लिए ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled" rule जोड़ दिया है
    • Aorus motherboard पर इस problem की वजह से शायद कई kWh बिजली बर्बाद कर चुका हूं, इसलिए समाधान की उम्मीद थी, लेकिन मेरे मामले में इसका असर नहीं हुआ
    • X570 Aorus Master पर भी sleep की problem झेल रहा था, और boot के समय systemd unit से echo GPP0 >> /proc/acpi/wakeup चलाने पर यह ठीक हो गया
      हालांकि boot के बाद पहला sleep हमेशा तुरंत wake हो जाता था, लेकिन ऊपर वाला udev rule लगाने के बाद लगता है वह problem भी सुलझ गई
    • उम्मीद होती है कि यह detect किया जा सके कि hardware सच में sleep में गया या नहीं, या जो hardware sleep में नहीं गया था उसे फिर से wake करने पर कोई problem न हो
      ऐसा संभव होना चाहिए कि PCIe device को sleep command भेजने के बाद bus खुद sleep में जाए, और wake करते समय पहले bus को वापस चालू किया जाए, फिर device को जगाया जाए
    • इस problem से कुछ समय तक परेशान रहा, लेकिन यह तरीका भी काम नहीं आया; मैंने जो notes लिखे हैं वे https://bbs.archlinux.org/viewtopic.php?id=302440 पर हैं
      मेरे मामले में wake-up source .../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6 से आता लगता है, लेकिन यह path क्या दर्शाता है, यह ठीक से समझ नहीं आता

  • बताए गए user-space workarounds में से एक memreserver के author के रूप में, मैंने कुछ साल पहले इस issue को debug किया था
    जल्दी मिलने वाली public comment https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17... है, और याद है कि mailing list पर भी discussion हुई थी
    मुख्य बात यह थी कि Linux में ऐसा staged suspend hook नहीं था जो disk और memory subsystems के कुछ हिस्सों के freeze होने से पहले reliably चल सके, और अब लगता है कि यह संभव है
    अफसोस है कि Freedesktop Gitlab शायद अच्छी तरह index नहीं होता, इसलिए लगता है यह जानकारी दब गई

  • वाकई शानदार काम
    अगर आप सोच रहे थे कि Linux में sleep transition को ठीक से चलाना और debug करना इतना कठिन क्यों है, तो यह लेख अकेला ही अच्छी तरह दिखा देता है कि कितनी जगह चीजें टूट सकती हैं
    आज भी ThinkPad P1G4 पर sleep से पहले अगर मैं fan को खुद बंद न करूं, तो वह अपने-आप बंद नहीं होता, और हाल ही में sleep से resume के बाद Bluetooth headphones में noise आने लगा, इसलिए PipeWire की node sleep भी बंद करनी पड़ी: https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...

    • 2025 में भी Linux laptops पर sleep/suspend का अब भी ठीक से काम न करना हैरान करने वाला है
      मैंने पहली बार शायद करीब 15 साल पहले ऐसी समस्या झेली थी
    • sleep सचमुच किस्मत का खेल है, और लेख में बताए गए जैसे errors को debug करना भी बेहद मुश्किल है
      कई समस्याओं के लिए सुझाए गए workarounds में power saving modes बंद करना शामिल है, लेकिन sleep इस्तेमाल करने का मकसद आम तौर पर battery life बढ़ाना होता है, इसलिए ऐसा तरीका practical usage time को काफी घटा सकता है और बहुत वास्तविक नहीं लगता
      फिर भी S0ix sleep को चलाना असंभव नहीं है
      मैंने AMD 7840U और AMD 8840U आधारित handheld devices—यानी GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3, OneXPlayer X1 Ryzen—पर Arch Linux install किया, और लगता नहीं कि इन कंपनियों ने Linux support को ध्यान में रखकर design या test किया होगा
      फिर भी /proc/acpi/wakeup और /sys/devices/*/*/*/power/wakeup में कुछ fake wakeup sources को थोड़ा adjust करने भर से, नए OneXPlayer X1 Ryzen को छोड़कर, लगभग perfect S0ix support मिल गया
      default Linux kernel support भी शानदार है: touchscreen, pen input, Wi‑Fi, Bluetooth सब ठीक चलते हैं, और जो एकमात्र कमी दिखी वह fingerprint reader support है
      ऐसे छोटे manufacturers में parts की extreme customization या tight integration कम होती है, और असल में devices के कुछ mm मोटे होने में यह दिखता भी है
      इसलिए वे शायद ज्यादा conservative parts चुनते हैं, और नतीजतन Linux support हैरानीजनक रूप से अच्छा हो सकता है
    • end users के लिए sleep को आसानी से और अच्छे से इस्तेमाल करने का जवाब है validated compatible hardware खरीदना
      मेरे अनुभव में business ThinkPad पर यह काफी पहले से बहुत stable रहा है, और ऐसा लगता है कि उसी model के Windows users उल्टे sleep issues ज्यादा बार झेलते हैं

  • व्यक्तिगत रूप से बहुत आभारी हूं
    मेरा main laptop Ryzen-based ThinkPad है जिस पर Linux चलता है, और मैं sleep व hibernate अक्सर इस्तेमाल करता हूं; यह समस्या बीच-बीच में आती रही है
    Linux 6.14 का इंतजार है

  • dm->cached_state ने pointer की जगह -12 क्यों store किया, इसकी वजह शायद यह है कि suspend के दौरान dm_suspend() ने dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev)) को सीधे assign कर दिया
    call किया गया drm_atomic_helper_suspend() valid pointer या error को encode करने वाला negative pointer ERR_PTR(err) लौटा सकता है, लेकिन caller ने error check किए बिना उसे सीधे pointer में डाल दिया और resume के समय dereference कर दिया
    kernel में Rust लाने की एक और वजह बढ़ गई; अगर Result type handling अनिवार्य हो, तो ऐसी चीजें होना मुश्किल होगा

    • C preprocessor से भी algebraic sum types बनाए जा सकते हैं: https://github.com/Hirrolot/datatype99
      लेकिन defaults मायने रखते हैं, और kernel ने coding practices को modernize करने में लंबे समय से देरी की है, जिसका C-side improvements पर नकारात्मक असर पड़ता है
      विडंबना यह है कि इसी resistance से Rust developers भी frustrate होते हैं, क्योंकि हर subsystem को साफ करना या उसके व्यवहार को document करना तक आसानी से स्वीकार नहीं किया जाता
      https://github.com/llvm/llvm-project/issues/74205 जैसी चीज kernel तक पहुंच जाए तो मदद मिल सकती है, लेकिन फिर भी लगता है कि type safety हासिल करने के बजाय pointers को manually overload करने का तरीका ही चुना जाता रहेगा

  • GPU expansion module वाले Framework AMD laptop पर Linux/Windows dual boot इस्तेमाल कर रहा हूं, इसलिए लगता है कि यह काम मददगार होगा
    सीधे sponsor करना या अपनी पसंद की charity को donate करना चाहूंगा; contact details profile में हैं

  • मुझे लगता था कि naming, cache invalidation, और off-by-one errors computer science की सबसे बड़ी दो समस्याएं हैं, लेकिन sleep/wake issue जानने के बाद यह तो NP-complete लगता है

    • मेरे हिसाब से sleep/wake cache invalidation का subset है
      अगर सभी peripherals के पास state न होती, तो शायद यह समस्या ही न होती
    • यह सिर्फ Linux में है; Windows में यह O(n²) है, और macOS में O(log n)

  • Linux में memory management, खासकर OOM की स्थितियां, अब भी अविश्वसनीय रूप से दर्दनाक nightmare हैं
    ऐसा नहीं है कि ये समस्या हमेशा झेलनी पड़ती है, लेकिन मिलती-जुलती समस्याओं को debug करने की कोशिश करके असफल होने का अनुभव जरूर रहा है, और आखिर में OOM होने पर आम तौर पर और RAM लगा दी जाती है
    यह बेकार खर्च है और महंगा भी, लेकिन OOM स्थितियों को graceful तरीके से handle करना आगे भी Linux के लिए हल करना मुश्किल समस्या लगती है
    यह काम शानदार है, और आगे इसी तरह की समस्याओं को debug करते समय benchmark बनेगा
    systemd का debug-shell feature भी अच्छा लगा; पता ही नहीं था कि ऐसा feature है
    हालांकि मेरे X670E Steel Legend board में serial header नहीं लगता, तो जिज्ञासा है कि आजकल onboard serial port कैसे काम करते हैं
    क्या वे chipset PCIe lanes से जुड़े होते हैं
    Linux kernel में गहराई से उतरते समय FOSDEM या Linux Plumbers Conference जैसी जगहों के kernel subsystem talks की recordings बहुत मददगार होती हैं; उदाहरण के लिए ज्यादातर desktop GPU DRM drivers जिस TTM memory subsystem का इस्तेमाल करते हैं, उसका video यह है: https://www.youtube.com/watch?v=MG7_tUNKSt0

    • Windows में मेरे motherboard का serial port Pci Bus → PCI standard ISA bridge से जुड़ा हुआ दिखता है
      DOS ज़िंदाबाद
      TTM video समय मिलने पर देखूंगा
    • OOM को cgroups में सीमित करना काफी अच्छी तरह काम किया
      Linux जो करता है उससे बेहतर कोई आधुनिक OOM handling तरीका है या नहीं, यह ठीक से नहीं पता; अगर इस बारे में पढ़ने लायक कोई सामग्री हो तो जानना चाहूंगा
    • सही है, नरम शब्दों में कहें तो भी यह भयानक है
      Linux OOM situation को ठीक से handle नहीं कर पाता
      पता है कि cgroups से guardrails लगाए जा सकते हैं, earlyoom install किया जा सकता है, swap बढ़ाया जा सकता है या zram इस्तेमाल किया जा सकता है
      लेकिन आखिरकार ये सब बस गंदे hacks हैं जो कभी-कभार बचा सकते हैं, और ऐसी situations जिस तरह handle होती हैं उसे ठीक नहीं करते
      कृपया इन्हें solution की तरह पेश न करें
      मैंने देखा है कि kernel dm_crypt में memory allocate नहीं कर पाया और LUKS volume खुद ही read-only mount हो गया; कृपया बस किसी एक user-space process को kill कर दें
      मौजूदा स्थिति बिल्कुल स्वीकार्य नहीं है और excuses सुन-सुनकर थक गया हूं
    • क्या आपने zswap/zram आज़माया है, यह जानना चाहूंगा
      zstd इस्तेमाल करने पर 8GB RAM को बिना खास दिक्कत 20GB ‘RAM’ की तरह, और 16GB को 40GB की तरह इस्तेमाल किया जा सकता है
      और अधिक aggressive तरीके से memory को 100% से ज्यादा overcommit भी किया जा सकता है, और Android भी ऐसा करता है, इसलिए यह काफी stable तरीका है

  • अच्छी खबर है
    AMD का Linux graphics driver कुल मिलाकर अच्छी तरह काम करता रहा है, लेकिन यह समस्या वह exception थी जिसे मैंने कई बार झेला

    • मेरी किस्मत थोड़ी कम अच्छी रही
      हाल में जो समस्या आ रही है वह यह है कि sleep से wake होने के बाद driver WARNING: CPU: 12 PID: 11871 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100 generic_reg_update_ex+0x1d2/0x290 [amdgpu] के बाद "[drm] scheduler comp_1.0.n is not ready, skipping" को logs में लगातार डालता रहता है
      https://gitlab.freedesktop.org/drm/amd/-/issues/3911
    • मेरा भी overall experience अच्छा है, लेकिन device के sleep में होने पर monitor से जुड़े Thunderbolt को unplug करने पर ऐसी ही समस्या होती है
      हालांकि laptop होने की वजह से driver configuration काफी अलग है और PCIe GPU भी नहीं है

  • amdgpu.ko kernel module को save करके निकाला, Ghidra से decompile किया, और फिर dm_resume की crash location को kernel source की संबंधित line से map किया—debugging में यह हिस्सा हमेशा मेरा पसंदीदा moment होता है