Kegagalan dekompresi 'Oodle' akibat ketidakstabilan prosesor Intel
(radgametools.com)- Ketidakstabilan hardware pada prosesor Intel Core generasi ke-13 dan ke-14 dapat muncul sebagai kegagalan dekompresi Oodle Data dan crash pada game berbasis Unreal Engine
- Error yang umum adalah
DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle), dan masalahnya lebih terkait dengan pekerjaan multi-thread yang membebani CPU secara berat secara umum, bukan Oodle itu sendiri - Crash juga dapat muncul di Adobe Premiere, RealBench, CineBench, Prime95, Handbrake, Visual Studio, dan lainnya; meski penyebabnya CPU, masalah ini bisa terlihat seperti error GPU seperti
out of video memory - Intel mengonfirmasi penyebabnya adalah beberapa masalah yang bertumpuk sehingga sirkuit sinyal clock di dalam chip menua dengan cepat; komponen yang sudah mengalami degradasi fisik harus diganti
- Per 1 Oktober 2024, update BIOS yang menghindari kondisi operasi pemicu kerusakan mulai didistribusikan, sehingga harus dipasang sebelum gejala muncul
Ketidakstabilan CPU yang terungkap lewat crash game
- Masalah hardware pada prosesor Intel Core generasi ke-13 dan ke-14 seri 13xxx dan 14xxx dapat menyebabkan ketidakstabilan sistem secara umum
- Pada game berbasis Unreal Engine, kegagalan dekompresi Oodle Data dan crash dapat terjadi
- Error umum:
DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle)
- Error umum:
- Fenomena ini tidak terbatas pada Oodle saja
- Program yang sangat membebani prosesor di banyak thread juga dapat mengalami crash atau perilaku yang tidak dapat diprediksi
- Crash telah diamati di Adobe Premiere, RealBench, CineBench, Prime95, Handbrake, Visual Studio, dan lainnya
- Meski penyebabnya CPU, pesan yang muncul bisa terlihat seperti masalah GPU
- Contoh: error
out of video memoryyang keliru
- Contoh: error
Penyebab dan tindakan yang diperlukan
- Intel mengonfirmasi akar penyebabnya sebagai penuaan cepat pada sirkuit sinyal clock di dalam chip
- Kerusakan sirkuit terjadi karena beberapa masalah yang bertumpuk
- Kerusakan tersebut merupakan keausan fisik pada chip itu sendiri, dan tidak dapat dipulihkan setelah terjadi
- Komponen yang sudah mengalami degradasi perlu diganti
- Prosedur penggantian dirangkum dalam panduan terkait
- Per 1 Oktober 2024, update BIOS baru yang menghindari kondisi operasi penyebab kerusakan sirkuit mulai didistribusikan
- Untuk laptop atau PC desktop jadi, produsen sedang atau akan segera mendistribusikan update BIOS yang mencakup workaround tersebut
- Untuk PC rakitan sendiri, periksa image BIOS terbaru di situs web produsen motherboard
- Update BIOS harus dipasang sebelum gejala muncul
- Setelah crash mulai terjadi, sudah terlambat untuk menyelesaikannya lewat software
1 komentar
Komentar Hacker News
Ini mengingatkanku pada kejadian saat awal mengadopsi AMD Threadripper 3970X: https://forum.level1techs.com/t/amd-threadripper-3970x-under...
Diskusi HN: https://news.ycombinator.com/item?id=22382946
Pada akhirnya, selama beberapa bulan aku menyelidiki masalah ini bersama AMD, dan walaupun AMD memberi kompensasi yang cukup besar atas repotnya bolak-balik motherboard dan CPU, sejak itu aku terus memakainya dengan image BIOS kustom yang diberikan AMD. Pada akhirnya, sepertinya ini adalah masalah dari pihak Gigabyte
Aku menerima 13900K yang cacat, dan setidaknya dalam kasusku, aku bisa memastikan masalahnya muncul bahkan pada pengaturan PL1/PL2 default
Aku menjalankan reinforcement learning di sistem itu dan sistemnya terus crash, jadi butuh waktu cukup lama untuk mencari penyebabnya, lalu masalahnya hilang setelah CPU diganti dengan 13700KF yang kupakai di PC lain
Saat aku meminta RMA ke Intel, mereka bilang motherboard MSI yang kupakai tidak mendukung Linux, dan setelah kukirim repositori GitHub resmi Intel yang berisi microcode untuk mengaktifkan dukungan itu, petugas yang menanganiku langsung diganti. Pada saat itu terlihat jelas bahwa Intel berusaha sebisa mungkin menghindari RMA, dan untungnya aku tinggal di Eropa jadi bisa memproses RMA lewat lembaga perlindungan konsumen setempat
Sementara itu aku melihat promo bundel 7950X dan motherboard di toko online lalu membelinya, dan motherboard lama beserta 13900K hasil RMA kujual bekas. Aku sebelumnya memakai Intel karena Intel mensponsori beberapa proyek data science, tapi aku tidak berniat membeli Intel lagi
Untuk mengurangi masalah keamanan, sepertinya kita harus mematikan hyper-threading, dan sekarang untuk mengurangi masalah korupsi memori, kita juga harus mematikan mode turbo
Kalau C-state juga dimatikan untuk menghindari serangan side-channel, lalu efficiency core dimatikan untuk menghindari masalah scheduler, pada titik tertentu kita seperti kembali ke set fitur 20 tahun lalu :P
Baru-baru ini aku merakit sistem baru dengan i9 149KF dan motherboard Asus Formula. Tujuannya untuk menjalankan Windows sebagai sistem VFIO dan juga main game
Proses membuatnya stabil benar-benar seperti mimpi buruk, dan tidak satu pun pengaturan default motherboard yang benar. Game crash, dan kompilasi kernel maupun Emacs juga gagal
Pada akhirnya aku harus membatasi turbo chip 6GHz itu ke 5.4GHz, dan mengaktifkan pengaturan yang membatasi daya maksimum serta suhu throttling ke 90°C
Sekarang tampaknya stabil, dan bisa mempertahankan 5.4GHz tanpa throttling sambil bermain di 4K 120fps. Tapi tetap terasa mengganjal bahwa angka yang diiklankan dan kubayar itu tidak bisa dijalankan pada pengaturan apa pun
Awalnya aku pikir itu tidak masuk akal, tapi menurut Intel, itu tampaknya normal untuk chip ini: “Prosesor mendukung hingga 100°C, dan suhu di bawah itu normal dan sesuai perkiraan”
https://community.intel.com/t5/Processors/i9-14900K-temperat...
Tetap saja ini terasa sangat aneh. Di satu sisi, kita tentu harus mendapatkan performa yang diiklankan dan sudah dibayar, tapi di sisi lain menjalankan CPU pada 90~100°C terasa gila. Rasanya Intel sedang cukup terdesak. Aku penasaran pakai konfigurasi pendingin seperti apa
Ini sama seperti dulu ISP menjual layanan dengan klaim “hingga X Mbps”. Chip ini juga bilang bisa turbo boost “hingga 6.00GHz”
Pada dasarnya ini overclocking otomatis, dan seperti yang kualami sendiri, kadang bahkan tidak bisa mencapai kecepatan itu secara stabil. Beberapa chip mungkin tidak akan pernah berjalan di “hingga 6.00GHz”, tapi itu tetap bukan bohong. Karena katanya “hingga”
Tapi aku juga belum pernah melihat beban CPU melewati 40%, dan belum menjalankan software benchmark. 5.4GHz pada 90°C sangat berbeda dari yang kulihat pada prosesorku, jadi aku penasaran kamu pakai pendingin apa. Bisa juga meski clock-nya lebih tinggi, aku memang belum mendorong CPU sekeras itu
Mengingatkan pada tulisan klasik Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35...
xor eax, eaxpun salah, mungkin itu bisa mengurangi permintaan dukungan yang sulit di-debugSituasi ini terasa familiar. Mengingatkan pada Pentium III 1.13GHz yang lama
https://www.tomshardware.com/reviews/intel-admits-problems-p...
Di Zstd juga rutin menemui masalah perangkat keras. Sering kali dekompresor menjadi komponen pertama yang berinteraksi dengan data yang masuk lewat jaringan
Seperti pada kasus ini, dekompresor sangat sensitif terhadap bit flip terlepas dari apakah checksum digunakan, sehingga sering kali mendeteksi masalah perangkat keras lebih dulu daripada proses lain yang berjalan di host yang sama
Zstd memutuskan hanya menyertakan checksum untuk data asli, dan itu cukup untuk menjamin integritas data. Namun, karena tidak bisa memeriksa apakah data terkompresi rusak, jadi lebih sulit untuk menyingkirkan kemungkinan bahwa sumber kerusakan ada pada dekompresor
Halaman ini tampaknya tidak tertaut dari halaman publik lain, jadi terlihat seperti halaman yang dibuat untuk menangani keluhan tak diinginkan dari pengguna yang mencoba menelusuri “oodle” di log error. Mirip dengan kasus SQLite pada 2006 [1]
[1] https://news.ycombinator.com/item?id=36302805
https://www.radgametools.com/granny.html
https://www.radgametools.com/iggy.htm
https://www.radgametools.com/milesperf.htm
Sama sekali tidak mengejutkan
Dulu saya membeli ASUS TUF board untuk 4790K karena saya hanya ingin sesuatu yang dasar dan tidak tertarik pada overclocking atau tuning. Tapi BIOS punya pendapat lain
Bahkan hanya untuk menghindari overclock saja, saya harus mengatur banyak sekali opsi secara manual, menetapkan timing RAM, dan memeriksa setiap entri di BIOS untuk memastikan tidak ada yang melakukan overclock dengan cara apa pun. Pengaturan “optimal” justru mengaktifkan perubahan agresif seperti penyesuaian pengali kecepatan bus
Pernah mengalami hal serupa di motherboard Asus. Auto-tuning membuat sistem jadi tidak stabil sampai compiler crash, dan agar bisa dipakai dengan benar BIOS harus diatur manual
Menurut saya masalahnya diperparah oleh cara SuperIO mengendalikan kipas. Karena crash itu terkait dengan lonjakan suhu hingga 100°C. Kenaikan kecepatan kipas terlalu lambat, dan penurunannya terlalu cepat
Di Linux, ini bisa diatur dari user space. Tetapi sebenarnya, yang harus mengendalikan fase kenaikan adalah indikator pendahulu seperti regulator tegangan, bukan indikator terlambat seperti suhu. Atau pengendali Linux p-state bisa memprediksi tingkat daya lalu menetapkan kecepatan kipas yang lebih tinggi
Kurva kipas bawaan tidak efektif dan terus berosilasi sehingga menjengkelkan. Suhu satu inti P terus melonjak sehingga kipas bereaksi secara kacau
Saya membaca bahwa memperpanjang waktu naik bisa membuat perilaku kipas lebih halus, tetapi melihat pengalaman di atas, itu juga bisa menyebabkan kegagalan prosesor