วิธีแก้ปัญหา sleep-awake ของ Linux ที่เกิดบน AMD GPU

• การเกิดปัญหา: บนเดสก์ท็อปที่ทำ dual boot ระหว่าง Windows และ Linux พบว่าเมื่อใช้งาน RAM ปริมาณมากบน Linux แล้วเข้าสู่โหมดสลีป ระบบจะล่ม เมื่อลองปลุกระบบกลับขึ้นมาจะพบหน้าจอดำหรือระบบไม่ตอบสนอง ปัญหานี้เกิดจากบั๊กด้านการจัดการพลังงาน/หน่วยความจำของไดรเวอร์ amdgpu

• การวิเคราะห์ปัญหา: ระบบที่ใช้เมนบอร์ด Gigabyte B550M DS3H และ GPU AMD RX 570 กำลังรัน Arch Linux หลังระบบล่ม ได้ตรวจสอบล็อกผ่าน journalctl และพบว่าเกิดข้อผิดพลาดหน่วยความจำไม่พอ (OOM) ใน amdgpu_device_suspend ไดรเวอร์ NVMe ไม่สามารถเริ่มต้นใหม่ได้สำเร็จตอนระบบกลับมาทำงาน ทำให้ระบบค้างและไม่สามารถบันทึกล็อกได้

• ความพยายามในการแก้ปัญหา: มีการปรับตั้งค่า systemd เพื่อทดลองโหมดสลีปหลายแบบ และปิดการสลีปแบบ asynchronous เพื่อทำให้ปัญหาง่ายต่อการวิเคราะห์ขึ้น แต่ก็ยังไม่สามารถแก้ต้นตอของปัญหาได้ พบว่าระบบล่มระหว่างขั้นตอนนำ TTM buffer ของ amdgpu ออก

• สาเหตุของปัญหา: เมื่อระบบเข้าสู่โหมดสลีป S3 ไฟเลี้ยงของ PCIe GPU จะถูกตัด ทำให้ข้อมูลใน VRAM สูญหาย เพื่อป้องกันสิ่งนี้ ไดรเวอร์ GPU ต้องสำรอง VRAM ไปยัง RAM ของระบบ แต่ไดรเวอร์ amdgpu บน Linux จะล่มด้วยอาการหน่วยความจำไม่พอหากมี RAM ไม่เพียงพอ

• แนวทางแก้ไข: Mario Limonciello ได้เขียนเคอร์เนลแพตช์เพื่อให้สำรอง VRAM ไปยังสตอเรจบนดิสก์ก่อนที่ดิสก์เบสสตอเรจจะหยุดทำงาน แพตช์นี้เปลี่ยนให้การสำรอง VRAM เกิดขึ้นในขั้น dpm_prepare() แทน dpm_suspend() เพื่อให้สามารถยกเลิกการเข้าสลีปได้หากหน่วยความจำไม่พอ

• การแก้ปัญหาเพิ่มเติม: ผู้ใช้ได้เขียนสคริปต์ให้สำรอง VRAM จาก user space โดยย้าย VRAM ไปยัง RAM ของระบบก่อนเข้าสู่โหมดสลีป อย่างไรก็ตาม เมื่อมีแอป 3D หลายตัวกำลังทำงานอยู่ VRAM อาจถูกย้ายกลับไปที่ GPU ต่อเนื่องและทำให้ระบบล่มได้

• การแก้ไขขั้นสุดท้าย: มีการเปลี่ยนไปใช้ power management notifier API เพื่อสำรอง VRAM ในขั้น PM_SUSPEND_PREPARE ส่งผลให้สามารถย้าย VRAM ไปยัง RAM ของระบบได้ก่อนที่ swap จะถูกปิดใช้งาน จึงแก้ปัญหานี้ได้

• สรุป: ปัญหานี้ถูกแก้ไขได้จากความพยายามของหลายคนและการลองผิดลองถูกหลายแบบ และมีกำหนดจะถูกรวมเข้าใน Linux kernel 6.14

[GN⁺]

ความคิดเห็นจาก Hacker News

• มีข้อสงสัยเกี่ยวกับสมมติฐานที่ว่าเมื่อเดสก์ท็อปเข้าสู่โหมดสลีป S3 ระบบจะตัดไฟของ GPU แบบ PCIe

  • โดยหลักแล้ว S3 ควรตัดไฟทุกอย่างยกเว้น RAM แต่เมนบอร์ด Gigabyte Aorus มีปัญหาบั๊กสลีปของ NVMe SSD ที่ทำให้สลีปหรือปลุกกลับขึ้นมาได้ไม่ถูกต้อง
  • เพื่อแก้ปัญหานี้ จำเป็นต้องเพิ่มกฎ udev
  • ยังมีวิธีป้องกันการปลุกจากพอร์ต PCIe บางพอร์ตได้ด้วย
  • มีวิธีค้นหาอุปกรณ์ปลุกผ่าน PCIe ที่เป็นปัญหา
  • สามารถใช้คำสั่ง udevadm เพื่อดึงข้อมูลอุปกรณ์ได้
  • อาจใช้เชลล์สคริปต์เพื่อแก้ปัญหาได้เช่นกัน

• ผู้เขียน memreserver แชร์ประสบการณ์การดีบักเพื่อแก้ปัญหาสลีปบน Linux

  • ชี้ให้เห็นปัญหาที่ Linux ไม่สามารถรัน interrupt hook ที่เชื่อถือได้ก่อนที่ดิสก์และซับซิสเต็มหน่วยความจำจะถูกแช่แข็ง
  • หาข้อมูลที่เกี่ยวข้องบน Freedesktop Gitlab ได้ยาก

• อธิบายว่าทำไมการทำฟีเจอร์สลีปบน Linux จึงยาก และทำไมการดีบักจึงลำบาก

  • กำลังเจอปัญหาพัดลมบน ThinkPad P1G4 ไม่ยอมหยุดเอง
  • พบปัญหาเสียงแตกบนหูฟังบลูทูธหลังปลุกจากสลีป

• ผู้ใช้ ThinkPad ที่ใช้ Ryzen รายหนึ่งบอกว่ากำลังเจอปัญหาสลีปบน Linux และกำลังรอเวอร์ชัน 6.14

• มีความเห็นว่าตนเพิ่งตระหนักว่า ปัญหา "สลีป/ปลุก" เป็นปัญหาแบบ NP-complete

• มีความเห็นว่านี่น่าจะช่วยผู้ใช้ Framework AMD laptop ที่ใช้ GPU expansion และทำ dual boot Linux/Windows ได้

  • บอกว่าอยากบริจาค

• ผู้ใช้ที่กำลังเจอปัญหาหลังสลีปแล้ว PC แทบค้างบน AMD GPU กำลังพยายามแก้ปัญหาอยู่

  • ปัญหาเริ่มเกิดหลังเปลี่ยนจาก RX 5700 XT เป็น RX 7900 XTX
  • หวังว่าเวอร์ชัน 6.14 จะช่วยแก้ปัญหาได้

• มีความเห็นว่าเจอปัญหาสลีปมาตลอดตั้งแต่ใช้ Linux

  • ต่อให้ใช้ฮาร์ดแวร์ Intel, AMD, ATI หรือ NVIDIA ก็ยังมีหลายครั้งที่สลีปหรือไฮเบอร์เนตทำงานได้ไม่ถูกต้อง

• มีการแชร์ประสบการณ์การดีบักปัญหาสลีปบนฮาร์ดแวร์ IoT

  • บน Linux การไฮเบอร์เนตทั้งระบบเชื่อถือได้มากกว่าสลีป
  • ถ้า SSD เร็วพอ ก็ควรใช้การไฮเบอร์เนตทั้งระบบ

• อธิบายว่าการจัดการหน่วยความจำและเงื่อนไข OOM ยังคงเป็นปัญหาที่ยากบน Linux

  • การเพิ่ม RAM เพื่อแก้ปัญหา OOM เป็นวิธีที่ไม่มีประสิทธิภาพ
  • มีความเห็นว่าฟีเจอร์ debug shell ของ systemd มีประโยชน์
  • มีการบรรยายออนไลน์ที่เป็นประโยชน์เกี่ยวกับซับซิสเต็มต่าง ๆ ของเคอร์เนล Linux