round_down(value, SZ_128K)

ค่าดังกล่าวไม่ได้เป็นจุดเริ่มต้นของหน่วยความจำ แต่เป็น “ขีดจำกัด” ที่บอกว่าพื้นที่ VRAM ที่จัดสรรได้สิ้นสุดลงตรงไหน การปัดค่าขึ้นจึงอาจทำให้พื้นที่เล็ก ๆ ระหว่างขอบเขตจริงกับค่าที่ถูกปัดขึ้น ถูกมองว่าเป็น VRAM ว่าง ทั้งที่พื้นที่นั้นเป็นของ CCS และถูกสงวนไว้ให้ฮาร์ดแวร์

การปัดค่าลงทำให้ตัวจัดสรร VRAM อยู่ในฝั่งที่ปลอดภัย โดยไม่ล้ำเข้าไปในพื้นที่ CCS

ทำไมความผิดพลาดเล็กน้อยจึงทำให้ภาพพังและระบบวนลูป

เมื่อระบบมองว่าพื้นที่ CCS เป็น VRAM ที่นำไปใช้งานได้ การจัดสรรหน่วยความจำทั่วไปก็อาจเขียนทับข้อมูลเมทาดาทาที่ GPU ต้องใช้ ผลกระทบลุกลามไปถึงข้อมูลที่เกี่ยวข้องกับตารางหน้าหน่วยความจำ หรือ page table จนเกิดหน่วยความจำเสียหาย ภาพบนหน้าจอผิดเพี้ยน และ GDM ซึ่งเป็น display manager ของระบบ Linux รีสตาร์ตซ้ำไม่รู้จบบนการ์ด Battlemage G21

ดังนั้น ปัญหานี้ไม่ใช่แค่การคำนวณเลขผิด แต่เป็นความเข้าใจความหมายของค่าที่ไม่ตรงกัน โค้ดจัดการค่าดังกล่าวราวกับเป็น “จุดเริ่มต้น” ที่ควรจัดแนวด้วยการปัดขึ้น ทั้งที่ในความเป็นจริงมันคือ “ขอบเขตสิ้นสุด” ซึ่งควรปัดลง นี่คือเหตุผลที่แพตช์สุดท้ายสั้นมาก แต่การค้นหากลับยุ่งยากอย่างยิ่ง

แพตช์ 24 รุ่น กับการบูต 18 ครั้งเพื่อจำกัดวงปัญหา

Torvalds เรียกกระบวนการนี้ว่าเป็น “เซสชันดีบักจากขุมนรก” เขาและ AI assistant เพิ่มและปรับเครื่องมือวัดเฉพาะจุด ไล่ตามเส้นทางการคำนวณหน่วยความจำของไดรเวอร์ และเปรียบเทียบตำแหน่ง CCS ที่ฮาร์ดแวร์รายงานกับขอบเขตที่ตัวจัดสรร VRAM ได้รับ

การสืบสวนต้องผ่านแพตช์ดีบัก 24 รุ่นและการรีบูตเพื่อทดสอบ 18 รอบ กว่าจะพบว่าทิศทางการจัดแนวค่าผิดพลาด

การบูตซ้ำมีความสำคัญ เพราะปัญหาไม่ได้ปรากฏแค่เป็นบรรทัดโค้ดที่ดูน่าสงสัย แต่อาการเกิดขึ้นจริงในระดับฮาร์ดแวร์และระบบแสดงผล การทดลองแต่ละรอบช่วยแยกให้เห็นว่าอาการดังกล่าวเกี่ยวข้องกับการจัดสรรหน่วยความจำ ไม่ใช่สาเหตุอื่นของความผิดพลาดด้านกราฟิก

AI ช่วยเร่งงาน แต่ไม่ได้เป็นคนคุมการดีบัก

Torvalds ใช้ AI ในฐานะคู่หูสำหรับการดีบักแบบโต้ตอบ เครื่องมือช่วยเสนอวิธีเพิ่ม instrumentation ไล่เส้นทางการทำงานของไดรเวอร์ และช่วยวิเคราะห์ผลจากการทดลองแต่ละรอบ ทำให้การทดสอบสมมติฐานใช้แรงและเวลาน้อยลง

แต่ AI ไม่ได้เป็นผู้เชี่ยวชาญที่เชื่อถือได้เสมอไป Torvalds ระบุว่า AI เคยสรุปหลายครั้งว่าปัญหานี้เป็นไปไม่ได้หรือแก้ไม่ได้ และเสนอให้หยุดแล้วเขียนรายงานแทน

สิ่งที่ทำให้การสืบสวนเดินหน้าต่อคือ Torvalds เป็นผู้เลือกการทดลองครั้งถัดไป รู้ว่าแนวตีความใดไม่ถูกต้อง และเข้าใจความหมายของ offset ในโมเดลการจัดสรรหน่วยความจำของไดรเวอร์

บทบาทจึงแบ่งกันอย่างชัดเจน: AI ช่วยสร้างทางเลือกและจัดการงานเชิงกลไก ส่วนผู้เชี่ยวชาญเป็นผู้ให้บริบท ออกแบบการทดสอบที่พิสูจน์หักล้างได้ ตรวจสอบผล และตัดสินใจขั้นสุดท้าย

แพตช์ถูกส่งเข้าเคอร์เนลแล้ว แต่เวอร์ชัน backport ยังไม่ชัดเจน

Torvalds เป็นผู้เขียนและ commit แพตช์แก้ไขไดรเวอร์ Intel Xe เข้า upstream Linux kernel โดยรายงานที่มีอยู่ระบุว่าเคอร์เนล stable สายที่ยังได้รับการดูแลและได้รับผลกระทบ คาดว่าจะได้รับการแก้ไขผ่านกระบวนการ backport ตามปกติ

อย่างไรก็ตาม แหล่งข้อมูลที่มีอยู่ยังไม่ยืนยันอย่างน่าเชื่อถือว่า stable version ใดบ้างจะรวมแพตช์นี้ หรือจะออกเมื่อใด จึงยังไม่ควรระบุหมายเลขเวอร์ชันเฉพาะ ผู้ใช้ฮาร์ดแวร์ที่ได้รับผลกระทบควรรอตรวจสอบประกาศจากผู้ดูแลดิสทริบิวชัน Linux หรือผู้ดูแลเคอร์เนลว่าบิลด์ใดมีแพตช์ดังกล่าวแล้ว

บทเรียนเรื่อง AI กับการพัฒนาเคอร์เนล

กรณีนี้ไม่ใช่การรับรองว่าโค้ดเคอร์เนลที่สร้างโดย AI นั้นดีเสมอไป แต่เป็นตัวอย่างของการใช้ AI ในขอบเขตที่รัดกุมกว่า นั่นคือ ผู้เชี่ยวชาญใช้ AI เพื่อเร่งวงจรดีบักที่ซับซ้อน ขณะเดียวกันยังรับผิดชอบสมมติฐาน การออกแบบการทดสอบ การตรวจโค้ด และแพตช์สุดท้ายด้วยตัวเอง

แนวทางนี้แตกต่างอย่างมากจากการสร้างแพตช์หรือรายงานช่องโหว่ด้วย AI แล้วส่งให้ผู้ดูแลโครงการทันทีโดยไม่ทดสอบหรือไม่เข้าใจระบบ นักพัฒนาเคอร์เนลบางรายบอกว่าต้องรับมือกับ “คลื่นถาโถม” ของแพตช์ที่ผลิตโดย AI ขณะที่ผู้ดูแลระบบ staging และ networking ก็รายงานถึงความหงุดหงิดจากแพตช์คุณภาพต่ำหรือแพตช์ที่ผู้ส่งไม่สามารถอธิบายได้

ตัวเลขที่มักถูกอ้างว่าจำนวนการส่งผลงานเพิ่มขึ้นถึง 2,700% ควรรับฟังอย่างระมัดระวัง เพราะข้อมูลที่มีไม่ได้ระบุวิธีวัด ช่วงเวลา หรือหมวดหมู่ที่ตัวเลขนี้ครอบคลุมอย่างชัดเจน ข้อสรุปที่มีหลักฐานรองรับมากกว่าคือ AI ทำให้การสร้างโค้ดและรายงานทำได้ง่ายขึ้น แต่ภาระตรวจสอบและคัดกรองยังตกอยู่กับผู้ดูแลโครงการที่เป็นมนุษย์

Torvalds เองก็เคยกล่าวว่า Linux ไม่ได้ต่อต้านเครื่องมือ AI โดยสิ้นเชิง โดยเฉพาะการใช้ AI ช่วยตรวจสอบโค้ด เซสชันดีบัก Intel Xe แสดงให้เห็นเส้นแบ่งในทางปฏิบัติได้ดี: AI มีประโยชน์เมื่ออยู่ในกระบวนการวิศวกรรมที่มีวินัย แต่ไม่สามารถทดแทนความรู้เฉพาะด้าน การทดสอบที่ทำซ้ำได้ หรือมนุษย์ที่รับผิดชอบผลงานได้

แพตช์สุดท้ายมีเพียงหนึ่งบรรทัด แต่ความสำเร็จที่แท้จริงคือการรู้ว่าต้องแก้บรรทัดไหน และไม่ยอมเลิกค้นหา แม้ AI จะบอกว่าคำตอบนั้นไม่มีทางหาเจอก็ตาม

round_down(value, SZ_128K)

ค่าดังกล่าวไม่ได้เป็นจุดเริ่มต้นของหน่วยความจำ แต่เป็น “ขีดจำกัด” ที่บอกว่าพื้นที่ VRAM ที่จัดสรรได้สิ้นสุดลงตรงไหน การปัดค่าขึ้นจึงอาจทำให้พื้นที่เล็ก ๆ ระหว่างขอบเขตจริงกับค่าที่ถูกปัดขึ้น ถูกมองว่าเป็น VRAM ว่าง ทั้งที่พื้นที่นั้นเป็นของ CCS และถูกสงวนไว้ให้ฮาร์ดแวร์

การปัดค่าลงทำให้ตัวจัดสรร VRAM อยู่ในฝั่งที่ปลอดภัย โดยไม่ล้ำเข้าไปในพื้นที่ CCS

ทำไมความผิดพลาดเล็กน้อยจึงทำให้ภาพพังและระบบวนลูป

เมื่อระบบมองว่าพื้นที่ CCS เป็น VRAM ที่นำไปใช้งานได้ การจัดสรรหน่วยความจำทั่วไปก็อาจเขียนทับข้อมูลเมทาดาทาที่ GPU ต้องใช้ ผลกระทบลุกลามไปถึงข้อมูลที่เกี่ยวข้องกับตารางหน้าหน่วยความจำ หรือ page table จนเกิดหน่วยความจำเสียหาย ภาพบนหน้าจอผิดเพี้ยน และ GDM ซึ่งเป็น display manager ของระบบ Linux รีสตาร์ตซ้ำไม่รู้จบบนการ์ด Battlemage G21

ดังนั้น ปัญหานี้ไม่ใช่แค่การคำนวณเลขผิด แต่เป็นความเข้าใจความหมายของค่าที่ไม่ตรงกัน โค้ดจัดการค่าดังกล่าวราวกับเป็น “จุดเริ่มต้น” ที่ควรจัดแนวด้วยการปัดขึ้น ทั้งที่ในความเป็นจริงมันคือ “ขอบเขตสิ้นสุด” ซึ่งควรปัดลง นี่คือเหตุผลที่แพตช์สุดท้ายสั้นมาก แต่การค้นหากลับยุ่งยากอย่างยิ่ง

แพตช์ 24 รุ่น กับการบูต 18 ครั้งเพื่อจำกัดวงปัญหา

Torvalds เรียกกระบวนการนี้ว่าเป็น “เซสชันดีบักจากขุมนรก” เขาและ AI assistant เพิ่มและปรับเครื่องมือวัดเฉพาะจุด ไล่ตามเส้นทางการคำนวณหน่วยความจำของไดรเวอร์ และเปรียบเทียบตำแหน่ง CCS ที่ฮาร์ดแวร์รายงานกับขอบเขตที่ตัวจัดสรร VRAM ได้รับ

การสืบสวนต้องผ่านแพตช์ดีบัก 24 รุ่นและการรีบูตเพื่อทดสอบ 18 รอบ กว่าจะพบว่าทิศทางการจัดแนวค่าผิดพลาด

การบูตซ้ำมีความสำคัญ เพราะปัญหาไม่ได้ปรากฏแค่เป็นบรรทัดโค้ดที่ดูน่าสงสัย แต่อาการเกิดขึ้นจริงในระดับฮาร์ดแวร์และระบบแสดงผล การทดลองแต่ละรอบช่วยแยกให้เห็นว่าอาการดังกล่าวเกี่ยวข้องกับการจัดสรรหน่วยความจำ ไม่ใช่สาเหตุอื่นของความผิดพลาดด้านกราฟิก

AI ช่วยเร่งงาน แต่ไม่ได้เป็นคนคุมการดีบัก

Torvalds ใช้ AI ในฐานะคู่หูสำหรับการดีบักแบบโต้ตอบ เครื่องมือช่วยเสนอวิธีเพิ่ม instrumentation ไล่เส้นทางการทำงานของไดรเวอร์ และช่วยวิเคราะห์ผลจากการทดลองแต่ละรอบ ทำให้การทดสอบสมมติฐานใช้แรงและเวลาน้อยลง

แต่ AI ไม่ได้เป็นผู้เชี่ยวชาญที่เชื่อถือได้เสมอไป Torvalds ระบุว่า AI เคยสรุปหลายครั้งว่าปัญหานี้เป็นไปไม่ได้หรือแก้ไม่ได้ และเสนอให้หยุดแล้วเขียนรายงานแทน

สิ่งที่ทำให้การสืบสวนเดินหน้าต่อคือ Torvalds เป็นผู้เลือกการทดลองครั้งถัดไป รู้ว่าแนวตีความใดไม่ถูกต้อง และเข้าใจความหมายของ offset ในโมเดลการจัดสรรหน่วยความจำของไดรเวอร์

บทบาทจึงแบ่งกันอย่างชัดเจน: AI ช่วยสร้างทางเลือกและจัดการงานเชิงกลไก ส่วนผู้เชี่ยวชาญเป็นผู้ให้บริบท ออกแบบการทดสอบที่พิสูจน์หักล้างได้ ตรวจสอบผล และตัดสินใจขั้นสุดท้าย

แพตช์ถูกส่งเข้าเคอร์เนลแล้ว แต่เวอร์ชัน backport ยังไม่ชัดเจน

Torvalds เป็นผู้เขียนและ commit แพตช์แก้ไขไดรเวอร์ Intel Xe เข้า upstream Linux kernel โดยรายงานที่มีอยู่ระบุว่าเคอร์เนล stable สายที่ยังได้รับการดูแลและได้รับผลกระทบ คาดว่าจะได้รับการแก้ไขผ่านกระบวนการ backport ตามปกติ

อย่างไรก็ตาม แหล่งข้อมูลที่มีอยู่ยังไม่ยืนยันอย่างน่าเชื่อถือว่า stable version ใดบ้างจะรวมแพตช์นี้ หรือจะออกเมื่อใด จึงยังไม่ควรระบุหมายเลขเวอร์ชันเฉพาะ ผู้ใช้ฮาร์ดแวร์ที่ได้รับผลกระทบควรรอตรวจสอบประกาศจากผู้ดูแลดิสทริบิวชัน Linux หรือผู้ดูแลเคอร์เนลว่าบิลด์ใดมีแพตช์ดังกล่าวแล้ว

บทเรียนเรื่อง AI กับการพัฒนาเคอร์เนล

กรณีนี้ไม่ใช่การรับรองว่าโค้ดเคอร์เนลที่สร้างโดย AI นั้นดีเสมอไป แต่เป็นตัวอย่างของการใช้ AI ในขอบเขตที่รัดกุมกว่า นั่นคือ ผู้เชี่ยวชาญใช้ AI เพื่อเร่งวงจรดีบักที่ซับซ้อน ขณะเดียวกันยังรับผิดชอบสมมติฐาน การออกแบบการทดสอบ การตรวจโค้ด และแพตช์สุดท้ายด้วยตัวเอง

แนวทางนี้แตกต่างอย่างมากจากการสร้างแพตช์หรือรายงานช่องโหว่ด้วย AI แล้วส่งให้ผู้ดูแลโครงการทันทีโดยไม่ทดสอบหรือไม่เข้าใจระบบ นักพัฒนาเคอร์เนลบางรายบอกว่าต้องรับมือกับ “คลื่นถาโถม” ของแพตช์ที่ผลิตโดย AI ขณะที่ผู้ดูแลระบบ staging และ networking ก็รายงานถึงความหงุดหงิดจากแพตช์คุณภาพต่ำหรือแพตช์ที่ผู้ส่งไม่สามารถอธิบายได้

ตัวเลขที่มักถูกอ้างว่าจำนวนการส่งผลงานเพิ่มขึ้นถึง 2,700% ควรรับฟังอย่างระมัดระวัง เพราะข้อมูลที่มีไม่ได้ระบุวิธีวัด ช่วงเวลา หรือหมวดหมู่ที่ตัวเลขนี้ครอบคลุมอย่างชัดเจน ข้อสรุปที่มีหลักฐานรองรับมากกว่าคือ AI ทำให้การสร้างโค้ดและรายงานทำได้ง่ายขึ้น แต่ภาระตรวจสอบและคัดกรองยังตกอยู่กับผู้ดูแลโครงการที่เป็นมนุษย์

Torvalds เองก็เคยกล่าวว่า Linux ไม่ได้ต่อต้านเครื่องมือ AI โดยสิ้นเชิง โดยเฉพาะการใช้ AI ช่วยตรวจสอบโค้ด เซสชันดีบัก Intel Xe แสดงให้เห็นเส้นแบ่งในทางปฏิบัติได้ดี: AI มีประโยชน์เมื่ออยู่ในกระบวนการวิศวกรรมที่มีวินัย แต่ไม่สามารถทดแทนความรู้เฉพาะด้าน การทดสอบที่ทำซ้ำได้ หรือมนุษย์ที่รับผิดชอบผลงานได้

แพตช์สุดท้ายมีเพียงหนึ่งบรรทัด แต่ความสำเร็จที่แท้จริงคือการรู้ว่าต้องแก้บรรทัดไหน และไม่ยอมเลิกค้นหา แม้ AI จะบอกว่าคำตอบนั้นไม่มีทางหาเจอก็ตาม