ปรากฏการณ์การแตกไฟล์บีบอัด 'Oodle' ล้มเหลวจากความไม่เสถียรของโปรเซสเซอร์ Intel

 (radgametools.com)
1 คะแนน โดย GN⁺ 2024-02-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความไม่เสถียรของฮาร์ดแวร์ใน โปรเซสเซอร์ Intel Core รุ่นที่ 13 และ 14 อาจแสดงออกมาเป็น การแตกไฟล์บีบอัด Oodle Data ล้มเหลว และเกมล่มในเกมที่ใช้ Unreal Engine
  • ข้อผิดพลาดที่พบบ่อยคือ DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle) และปัญหานี้เกี่ยวข้องกับงานแบบมัลติเธรดโดยรวมที่ใช้ CPU อย่างหนัก มากกว่าจะเป็นตัว Oodle เอง
  • อาจเกิดอาการล่มใน Adobe Premiere, RealBench, CineBench, Prime95, Handbrake, Visual Studio ฯลฯ ได้เช่นกัน และแม้สาเหตุจะมาจาก CPU ก็อาจ ดูเหมือนข้อผิดพลาดของ GPU เช่น out of video memory
  • Intel ยืนยันแล้วว่าสาเหตุเกิดจากหลายปัญหาซ้อนกันจนทำให้ วงจรสัญญาณนาฬิกาภายในชิปเสื่อมสภาพอย่างรวดเร็ว และชิ้นส่วนที่เสื่อมสภาพทางกายภาพไปแล้วจำเป็นต้องเปลี่ยนใหม่
  • ณ วันที่ 1 ตุลาคม 2024 อัปเดต BIOS ที่หลีกเลี่ยงเงื่อนไขการทำงานซึ่งก่อให้เกิดความเสียหายเริ่มถูกปล่อยออกมาแล้ว จึงควรติดตั้งก่อนที่จะมีอาการ

ความไม่เสถียรของ CPU ที่เผยให้เห็นผ่านเกมล่ม

  • ปัญหาฮาร์ดแวร์ของ โปรเซสเซอร์ Intel Core รุ่นที่ 13 และ 14 ซีรีส์ 13xxx และ 14xxx อาจนำไปสู่ความไม่เสถียรทั่วไปของระบบ
  • ในเกมที่ใช้ Unreal Engine อาจเกิดการแตกไฟล์บีบอัด Oodle Data ล้มเหลวและเกมล่ม
    • ข้อผิดพลาดที่พบบ่อย: DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle)
  • ปรากฏการณ์นี้ ไม่ได้จำกัดอยู่แค่ Oodle
    • โปรแกรมที่ใช้งานโปรเซสเซอร์อย่างหนักในหลายเธรดก็อาจล่มหรือมีพฤติกรรมที่คาดเดาไม่ได้
    • พบการล่มใน Adobe Premiere, RealBench, CineBench, Prime95, Handbrake, Visual Studio ฯลฯ เช่นกัน
  • แม้ CPU จะเป็นสาเหตุ แต่ข้อความที่แสดงอาจดูเหมือนปัญหา GPU
    • เช่น ข้อผิดพลาด out of video memory ที่ไม่ถูกต้อง

สาเหตุและสิ่งที่ต้องดำเนินการ

  • Intel ยืนยันสาเหตุรากว่าเป็น การเสื่อมสภาพอย่างรวดเร็วของวงจรสัญญาณนาฬิกาภายในชิป
    • ความเสียหายของวงจรเกิดขึ้นจากหลายปัญหาที่ซ้อนกัน
    • ความเสียหายเป็น การสึกหรอทางกายภาพ ของตัวชิปเอง และเมื่อเกิดขึ้นแล้วไม่สามารถย้อนกลับได้
  • ชิ้นส่วนที่เสื่อมสภาพไปแล้วจำเป็นต้องเปลี่ยนใหม่
  • ณ วันที่ 1 ตุลาคม 2024 อัปเดต BIOS ใหม่ที่หลีกเลี่ยงเงื่อนไขการทำงานซึ่งทำให้วงจรเสียหายเริ่มถูกปล่อยออกมาแล้ว
    • สำหรับแล็ปท็อปหรือเดสก์ท็อปพีซีสำเร็จรูป ผู้ผลิตกำลังปล่อยหรือมีกำหนดจะปล่อยอัปเดต BIOS ที่รวมวิธีเลี่ยงปัญหานี้
    • สำหรับพีซีที่ประกอบเอง ควรตรวจสอบอิมเมจ BIOS ที่อัปเดตแล้วจากเว็บไซต์ของผู้ผลิตเมนบอร์ด
  • ควรติดตั้งอัปเดต BIOS ก่อนที่จะมีอาการ
    • หากเริ่มเกิดการล่มแล้ว ก็สายเกินกว่าจะแก้ไขด้วยซอฟต์แวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-25
ความคิดเห็นใน Hacker News

  • นึกถึงเหตุการณ์ที่เคยเจอตอนรับ AMD Threadripper 3970X มาใช้ช่วงแรก: https://forum.level1techs.com/t/amd-threadripper-3970x-under...
    การถกเถียงบน HN: https://news.ycombinator.com/item?id=22382946
    สุดท้ายก็ใช้เวลาหลายเดือนตรวจสอบปัญหาร่วมกับ AMD และ AMD ก็ชดเชยให้พอสมควรสำหรับความยุ่งยากจากการส่งเมนบอร์ดกับ CPU ไปมา แต่หลังจากนั้นก็ยังใช้งานต่อด้วย อิมเมจ BIOS แบบคัสตอม ที่ AMD ให้มา สรุปสุดท้ายดูเหมือนว่าจะเป็น ปัญหาฝั่ง Gigabyte

    • ทำให้นึกถึง บั๊ก Intel Skylake ที่นักพัฒนาคอมไพเลอร์ OCaml เป็นคนค้นพบ: https://tech.ahrefs.com/skylake-bug-a-detective-story-ab1ad2...
    • ไม่เคยรู้มาก่อนเลยว่าผู้ผลิต CPU จะรับมือกับผู้ใช้ทั่วไปแบบนี้ได้ด้วย

  • ผมได้รับ 13900K ที่มีปัญหา และอย่างน้อยในกรณีของผมก็ยืนยันได้ว่าปัญหาเกิดขึ้นแม้ใช้ ค่า PL1/PL2 เริ่มต้น
    ผมใช้ระบบนั้นรัน reinforcement learning แล้วมันแครชตลอด เลยใช้เวลานานพอสมควรกว่าจะหาสาเหตุเจอ พอเปลี่ยน CPU เป็น 13700KF ที่ใช้อยู่ใน PC อีกเครื่อง ปัญหาก็หายไป
    ตอนขอ RMA กับ Intel ทางนั้นบอกว่าเมนบอร์ด MSI ที่ใช้อยู่ไม่รองรับ Linux แต่พอผมส่ง GitHub repository ทางการของ Intel ที่มีไมโครโค้ดสำหรับเปิดการรองรับให้ เจ้าหน้าที่ที่ดูแลเคสก็ถูกเปลี่ยนตัว ทันทีนั้นมันดูชัดเจนว่า Intel พยายามเลี่ยง RMA ให้มากที่สุด โชคดีที่ผมอยู่ยุโรป เลยดำเนินการ RMA ผ่านหน่วยงานคุ้มครองผู้บริโภคในพื้นที่ได้
    ระหว่างนั้นผมเห็นโปรโมชันขายชุด 7950X พร้อมเมนบอร์ดจากร้านออนไลน์ก็เลยซื้อมา และขายเมนบอร์ดเดิมกับ 13900K ที่ได้จาก RMA เป็นของมือสองไปแล้ว เดิมทีผมใช้ Intel เพราะ Intel เป็นสปอนเซอร์บางโปรเจ็กต์ด้าน data science แต่ผมคงไม่ซื้อ Intel อีกแล้ว

    • 7700K ก็ไม่เสถียรมาตลอดตั้งแต่ซื้อมา และแม้จะ อัปเดต BIOS นาน 16 เดือน ก็ยังไม่หาย อาจเป็นไปได้ว่าโปรเซสเซอร์รุ่นใหม่ๆ มีปัญหามากกว่าดีไซน์ที่เรียบง่ายกว่าในอดีต

  • ถ้าอยากลดปัญหาด้านความปลอดภัยก็คงต้องปิด Hyper-Threading และตอนนี้ถ้าอยากลดปัญหา memory corruption ก็คงต้องปิด Turbo mode ด้วย
    พอจะเลี่ยง side-channel attack ก็ต้องปิด C-states และถ้าจะเลี่ยงปัญหา scheduler ก็ต้องปิด efficiency core ไปด้วย ทำไปทำมาสักพักก็เหมือนย้อนกลับไปใช้ชุดฟีเจอร์เมื่อ 20 ปีก่อน :P

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

  • ไม่นานมานี้ผมประกอบระบบใหม่ด้วย i9 149KF และเมนบอร์ด Asus Formula จุดประสงค์คือจะใช้รัน Windows แบบ VFIO และเล่นเกมด้วย
    กระบวนการทำให้มันเสถียรนี่เหมือนฝันร้าย และค่าเริ่มต้นของเมนบอร์ดก็ไม่ถูกต้องเลยสักอย่าง เกมแครช และการคอมไพล์เคอร์เนลกับ Emacs ก็ล้มเหลว
    สุดท้ายผมต้องจำกัด turbo ของชิป 6GHz ลงมาเหลือ 5.4GHz และเปิดการตั้งค่าให้จำกัดกำลังไฟสูงสุดกับอุณหภูมิ throttling สูงสุดไว้ที่ 90°C
    ตอนนี้มันดูเสถียรแล้ว และเล่นเกม 4K ที่ 120fps ได้พร้อมคงความเร็ว 5.4GHz ต่อเนื่องโดยไม่ throttling แต่ก็ยังรู้สึกติดใจที่ไม่ว่าจะตั้งค่าแบบไหนก็ใช้งานไม่ได้ตามตัวเลขโฆษณาที่จ่ายเงินซื้อมา

    • ที่บอกว่าจำกัดอุณหภูมิ throttling ไว้ที่ 90°C หมายความว่าก่อนหน้านั้นมันเกิน 90°C งั้นหรือ?
      ตอนแรกผมก็คิดว่ามันฟังดูเหลือเชื่อ แต่ตามที่ Intel บอก นี่ถือว่าปกติสำหรับชิปตัวนี้: “โปรเซสเซอร์รองรับได้สูงสุด 100°C และอุณหภูมิที่ต่ำกว่านั้นถือว่าปกติและอยู่ในช่วงที่คาดไว้”
      https://community.intel.com/t5/Processors/i9-14900K-temperat...
      ถึงอย่างนั้นมันก็ยังแปลกมาก ด้านหนึ่งก็รู้สึกว่าควรได้ประสิทธิภาพตามที่โฆษณาและจ่ายเงินไป แต่อีกด้านหนึ่งการรัน CPU ที่ 90~100°C ก็ดูบ้าระห่ำมาก รู้สึกเหมือน Intel กำลังถูกกดดันอย่างหนัก อยากรู้ว่าใช้ชุดระบายความร้อนแบบไหน
    • ไม่ชอบ การตลาด Turbo Boost เลย
      มันเหมือนสมัยก่อนที่ ISP ชอบขายแพ็กเกจว่า “สูงสุด X Mbps” ชิปรุ่นนี้ก็พูดว่า Turbo Boost ได้ “สูงสุด 6.00GHz”
      ในทางปฏิบัติมันก็คือโอเวอร์คล็อกอัตโนมัติ และอย่างที่เจอมากับตัว บางครั้งมันก็วิ่งความเร็วนั้นอย่างเสถียรไม่ได้ด้วยซ้ำ ชิปบางตัวอาจไม่มีวันทำงานที่ “สูงสุด 6.00GHz” ได้เลย แต่ก็ไม่ถือว่าโกหก เพราะเขาบอกว่า “สูงสุด”
    • ผมเพิ่งประกอบระบบด้วยเมนบอร์ด ASUS TUF, ชุดระบายความร้อน NZXT Kraken 360 และ 14900KF ช่วงนี้ยังไม่เจอปัญหากับค่า BIOS เริ่มต้น ค่าเริ่มต้นอยู่ที่ 5.7GHz และอุณหภูมิก็ยังไม่เคยเห็นเกิน 70°C
      แต่ผมก็ยังไม่เคยเห็น CPU load เกิน 40% และก็ยังไม่ได้รันซอฟต์แวร์เบนช์มาร์กเหมือนกัน 5.4GHz ที่ 90°C ต่างจากที่ผมเห็นบนโปรเซสเซอร์ตัวเองมาก เลยอยากรู้ว่าใช้ชุดระบายความร้อนอะไร หรืออาจเป็นเพราะแม้ผมจะได้คล็อกสูงกว่า แต่ก็ไม่ได้กด CPU หนักขนาดนั้น
    • สงสัยว่าได้ถอดทำความสะอาดทั้งหมดแล้วติดตั้งคูลเลอร์ใหม่พร้อมทา thermal paste ใหม่หรือยัง ผมเคยเห็นอาการคล้ายกันตอนทาเพสต์ผิดแล้วมีฟองอากาศ ค่าอุณหภูมิที่แสดงแยกตามคอร์แตกต่างกันมากไหม?
    • ความต่างของความถี่สัญญาณนาฬิกาแค่ 10% แต่กลับเป็นเส้นแบ่งระหว่างเสถียรกับไม่เสถียร ฟังดูน่ากลัวเหมือนกัน ของเผื่อจริงๆ มันเหลืออยู่แค่ไหนกัน?

  • ทำให้นึกถึงบทความคลาสสิกของ Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35...

    • สงสัยว่าทำไมถึงไม่ใส่องค์ประกอบในตัววิเคราะห์ระบบล่มที่คอยบอกผู้ใช้ว่า CPU กำลังทำงานผิดปกติ ตัวอย่างเช่น ถ้าบอกได้ว่าแม้แต่คำสั่งพื้นฐานอย่าง xor eax, eax ยังให้ผลผิด ก็น่าจะช่วยลดคำขอซัพพอร์ตที่ดีบักได้ยาก

  • สถานการณ์นี้คุ้นมาก ทำให้นึกถึง Pentium III 1.13GHz สมัยก่อน
    https://www.tomshardware.com/reviews/intel-admits-problems-p...

    • นอกประเด็นหลักหน่อย แต่ก็น่าชื่นชมที่ Tom’s Hardware ยังเก็บโพสต์บนเว็บเมื่อ 24 ปีก่อนไว้ได้อย่างสมบูรณ์

  • ใน Zstd ก็เจอปัญหาฮาร์ดแวร์แบบนี้เป็นประจำ บ่อยครั้งตัวถอดบีบอัดจะเป็นองค์ประกอบแรกที่เริ่มโต้ตอบกับข้อมูลที่เข้ามาทางเครือข่าย
    เหมือนในกรณีนี้ ตัวถอดบีบอัดไวต่อ bit flip มากไม่ว่าจะใช้ checksum หรือไม่ก็ตาม จึงมักตรวจพบปัญหาฮาร์ดแวร์ได้ก่อนโปรเซสอื่น ๆ ที่รันอยู่บนโฮสต์เดียวกัน
    Zstd ตัดสินใจใส่ checksum เฉพาะของข้อมูลต้นฉบับ ซึ่งเพียงพอสำหรับรับประกันความถูกต้องสมบูรณ์ของข้อมูล แต่ก็ทำให้ตรวจไม่ได้ว่าข้อมูลที่ถูกบีบอัดเสียหายหรือไม่ จึงยิ่งยากที่จะตัดความเป็นไปได้ว่าต้นเหตุของความเสียหายนั้นมาจากตัวถอดบีบอัดเอง

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

  • หน้านี้ดูเหมือนไม่ได้ถูกลิงก์จากหน้า public อื่น ๆ เลย จึงดูเหมือนเป็นหน้าที่สร้างขึ้นมาเพื่อรับมือกับคำบ่นไม่พอใจที่ไม่ตั้งใจจากผู้ใช้ซึ่งพยายามตามรอยคำว่า “oodle” ใน error log คล้ายกับกรณี SQLite ในปี 2006 [1]
    [1] https://news.ycombinator.com/item?id=36302805

  • ไม่แปลกใจเลยสักนิด
    ตอนก่อนผมซื้อ ASUS TUF board สำหรับ 4790K ก็เพราะอยากได้อะไรพื้นฐาน ๆ และไม่ได้สนใจโอเวอร์คล็อกหรือปรับแต่ง แต่ BIOS คิดไม่เหมือนกัน
    แค่จะหลีกเลี่ยงการโอเวอร์คล็อกก็ต้องตั้งค่าด้วยตนเองมากมาย ต้องตั้งค่า timing ของ RAM และไล่ดูทุกหัวข้อใน BIOS ว่ามันไม่ได้โอเวอร์คล็อกไม่ทางใดก็ทางหนึ่ง การตั้งค่า “optimal” เปิดการเปลี่ยนแปลงเชิงรุกอย่างการปรับ bus speed multiplier ด้วย

    • อย่างที่คนอื่นบอก CPU ที่ “พื้นฐานพอแล้ว” ตัวนั้นจริง ๆ แล้วเป็นผลิตภัณฑ์ที่เจาะ ตลาดโอเวอร์คล็อก ตรง ๆ และเมนบอร์ดที่พูดถึงก็น่าจะใช่เช่นกัน มันไม่ใช่ชุดพื้นฐานเลย แต่เป็นระบบสำหรับการปรับแต่งขั้นสูง เพียงแค่เป็นระบบปรับแต่งที่มีอายุ 10 ปีแล้ว
    • มีไม่กี่คนหรอกที่ซื้อ K processor ทั้งที่ไม่สนใจโอเวอร์คล็อกหรือปรับแต่ง ดังนั้นก็ไม่น่าแปลกใจถ้า BIOS ของเมนบอร์ดเกมมิงจะตั้งค่าเริ่มต้น “optimal” บนสมมติฐานแบบนั้น ตลาดเกมมิงขับเคลื่อนด้วยเบนช์มาร์กอยู่แล้ว

  • เคยเจอเรื่องคล้ายกันบนเมนบอร์ด Asus การปรับจูนอัตโนมัติทำให้ระบบไม่เสถียรจนคอมไพเลอร์ล่ม และถ้าจะใช้งานให้ปกติก็ต้องตั้ง BIOS เองแบบแมนนวล
    ผมคิดว่าปัญหานี้ยิ่งแย่ลงเพราะวิธีที่ SuperIO ใช้ควบคุมพัดลม เนื่องจากอาการล่มเชื่อมโยงกับ อุณหภูมิพุ่งไปถึง 100°C ความเร็วในการเร่งพัดลมช้าเกินไป แต่ตอนลดกลับเร็วเกินไป
    บน Linux ผู้ใช้สามารถปรับสิ่งนี้จาก user space ได้ แต่ในทางปฏิบัติ สิ่งที่ควรใช้ควบคุมช่วงขาขึ้นไม่ควรเป็นตัวชี้วัดที่มีความหน่วงอย่างอุณหภูมิ แต่ควรเป็นตัวชี้นำล่วงหน้าอย่างตัวปรับแรงดันไฟฟ้า หรือไม่เช่นนั้นตัวควบคุม Linux p-state ก็ควรคาดการณ์ระดับพลังงานและตั้งความเร็วพัดลมให้สูงขึ้น

    • ตอนนี้กำลังเจอปัญหานี้อยู่พอดี ชุดที่ใช้คือ Asus ROG Z790, 14900K, Noctua NH-D15
      fan curve เริ่มต้นแทบไม่ช่วยอะไรเลย แถมยังแกว่งไปมาจนน่ารำคาญ อุณหภูมิของ P-core เดี่ยว ๆ เด้งขึ้นตลอดจนทำให้พัดลมตอบสนองแบบลุกลี้ลุกลน
      เคยอ่านมาว่าถ้าเพิ่มเวลาไต่ขึ้นจะทำให้การทำงานของพัดลมเนียนขึ้น แต่จากประสบการณ์ข้างต้นก็ดูเหมือนว่านั่นอาจทำให้โปรเซสเซอร์พังได้