RTX 5080’deki Çökmelerden Claude Suçlandı, Ama Gerçek Suçlu Çok Daha Sürpriz Çıktı.

Üç ay kadar süredir PC’me yerleşmiş, üstelik üstesinden gelemeydiğim sinir bozucu bir çökme alışkanlığı vardı. Oyunlar çöküyordu ama tutarlı bir şekilde değil ve ben de tekrarlayamadığım bir biçimde. Hem boşta hem de yük altında birkaç mavi ekran görüyordum ve Linux üzerinde hiç tam çökme yaşamadığım için bunları Windows hatalarına yüklüyordum. Sıklık açısından bakınca da rahatsız edici sayılmayacak kadar azdı, ta ki birkaç hafta öncesine kadar.

Oyun oturumuna 10 dakikadan fazla dayanamadım ve artık bunun köküne inmem gerektiğini biliyordum. Tüm kanıtlarımı Claude‘a sundum—oyun çökme kayıtları, Windows kayıtları ve bulabildiğim diğer her şey—ve o da sahip olduğum ikinci el RTX 5080’nin VRAM’ini sorunun kaynağı olarak kararlı bir biçimde teşhis etti. RMA sürecinin yarısındaydım ki, bulduğu şeye daha yakından bakmaya karar verdim ve gerçek neden, yıllardır değiştirmemiş olduğum sistem belleği yapılandırması çıktı.

Claude, sıkıcı kısmı çok iyi halletti

Artık loglar arasında kendim asla araştırma yapmayacağım

Claude’a hakkını vermekte yarar var, çünkü sorunu eleme yeteneği inanılmaz derecede yardımcı oldu. Escape From Tarkov oyununda çökme yaşıyordum ve bu oyun tek bir oturum için neredeyse her alt sistem için detaylı çökme kayıtları yazıyor. Claude’a tüm klasörü verdim ve bir dakikadan kısa sürede içindeki işe yarayan şeyi buldu.

“DXGI_ERROR_DEVICE_REMOVED” adlı bir hata buldu; bu, Windows’un GPU‘nun yanıt vermeyi bıraktığını ve sürücünün onu sıfırlamak zorunda kaldığını söylüyor. En iyi ihtimalle bu oyun çökmesine, en kötü ihtimalle sistem çökmesine yol açabilir. Oradan bana Windows’un olay geçmişine inebileceğim PowerShell komutlarını gösterdi. Bu da Tarkov’un ilk hatasından bir saniye önce loglanan bir NVIDIA sürücü sıfırlaması, aynı anda yazılmış bir kernel izleme (watchdog) dökümü, bozuk bir “shader program başlığı” konusunda şikayet eden bir dizi grafik istisnası ve Ağustos ayına giden üç sıfırlama daha ortaya çıkardı.

Bu tarihlerin hepsi, daha önce yaşadığım çökmelerle birebir örtüşüyordu ve en azından bu noktada tüm işaretler suçu GPU’ya yüklüyordu.

Tek bir bitlik çevirme tüm tanının kapısını açtı

Kırmızı bir biber: Dikkat dağıtıcı

Sıradaki adım bir GPU bellek testiydi. Claude, bana video belleği desenlerle dolduran ve bu desenlerin doğru şekilde okunup okunmadığını kontrol eden, ücretsiz bir araç olan memtest_vulkan’ı gösterdi. İlk çalıştırmanın yaklaşık 45. saniyesinde tek bir bitlik çevirmeyi yakaladı ve bu, ardından gelen tüm olay dizisinin tetikleyicisi oldu.

Claude ardından bana, bu çevrilmiş bitin bir VRAM kusurunun kanıtı olduğunu ve bir RMA sürecine MSI üzerinden başlamam gerektiğini söyledi. Son aylardır sorunsuz çalışan bir kartın aniden neden çalışmamaya başladığını sorunca, hatanın kartın 16GB belleğinin yaklaşık 13GB’lık kısmında bulunduğunu, bu yüzden yakın zamanda çıkan bir oyun güncellemesinin Tarkov’u, zayıf noktaya denk gelecek kadar yükseğe taşımış olabileceğini iddia etti. Bu bana pek mantıklı gelmedi; tam olarak arabelleği dolduran diğer oyunlar güvenilir biçimde çökmüyordu, bu yüzden test sonuçlarına kendim daha yakından bakmaya karar verdim ve bu da bizi tamamen yeni bir dert yumağına götürdü.

Claude’un atladığı, asıl suçu işaret eden sayı

Hız: Büyük bir tehlike çanığı

Kullanımda olduğum VRAM testi, çalışırken veri aktarım hızını raporluyordu ve benim çöken çalıştırmalarım saniyede 200 ile 300GB arasında bir hızla veri taşıyordu. RTX 5080’in belleği saniyede 960GB için tasarlanmış, bu da zaten bazı şüpheler uyandırıyordu. Kartın VRAM’ini gerçekten zorlayan bir test bunun civarında bir sonuca ulaşmalıydı ve sonunda bir tanesi ulaştı: Stok ayarlarının üzerinde bellek overloklu, temiz bir çalıştırma yaklaşık 850GB/s’ye ulaştı ve üç saat boyunca sorunsuz geçti.

Bu net sonuç, bana göre RMA önerisinin büyük bir kırmızı bayrağıydı. Claude, testler arasındaki bu büyük farkı yakaladı, ancak bunu saat durumlarına atfetti ve ayrıca HWiNFO ile birlikte yarışma ekran görüntüsünü doğru şekilde incelemedi; bu görüntüde, düşük hızlarda başarısız olan testlerle PCIe bus’un önemli ölçüde yük altında olduğu görülüyordu. Ya PCIe bus ya da sistemin RAM’inin son derece şüpheli olduğu konusunda açık bir işaret olmalıydı.

Video belleği dolduğunda, Windows veriyi isteği reddetmek yerine sistemin RAM’ine yavaşça aktarır. İlk testi başlattığımda, VRAM’inimden birkaç gigabaytlık uygulamalar vardı, dolayısıyla memtest’in arabelleğinin bir kısmı sistem belleğine yerleşti ve sorun büyük ihtimalle oradaydı. Bir gece süren bir VRAM testi çalıştırdım ve bu test hiçbir hata verdiğinde, sıradaki adımda nereye bakacağımı tam olarak biliyordum.

RAM’im birincil şüpheliydi

Daha fazla DDR5 kararsızlığı

Bilgisayarımda Ryzen 7 7800X3D ve dört adet 16GB’lık DDR5-6000 modül çalışıyor; bu çılgınca bir şey gibi görünmüyor, ancak AMD yalnızca Ryzen 7000 işlemcileri iki modülde en fazla 5200 için derecelendiriyor ve dört yeminin de dolduğunda bu hızı 3600MT/s’ye düşürüyor. Hızı 6000’e çıkarmak saçma görünmüyordu, çünkü AMD bu değeri Zen 4 çipleri için “en uygun nokta” olarak adlandırıyordu; ancak iki modülde 5200MT/s’den 6000MT/s’ye çıkmak, 3600MT/s’den 6000MT/s’ye çıkmaya kıyasla tamamen farklı bir talepti.

Bu, bilgisayarımda 2024’te bir araya getirdiğimden beri kullandığım bellek konfigürasyonuydu, ancak kanıtlar bunun neden olduğuna işaret ediyordu, bu yüzden bir gece süren bir bellek testi çalıştırdım.

Ve işte oradaydı: MemTest86+, beş saatlik temiz denemeden sonra 22 hata bildirdi ve her şeyin ardındaki suçlu buuydu.

Her çubuyu tek tek test edecek vaktim olmadı, birinin arızalı olup olmadığını görmek için tüm kombinasyonları denemedim; ancak en olası açıklama, o hızda dört DIMM’in CPU bellek denetleyicimden çok fazla şey beklemesiydi. Hızı düşürüp performansı kurban etmek yerine iki çubuyu çıkardım ve Tarkov o günden beri kararlı.

Sorun gidermek için AI kullanmak kötü bir fikir değil, ama yine de küçük detayları kaçırabiliyor

İlk kademe sorun gidermede yine bir AI modeline başvuruyorum çünkü ilgili hataları bulmak için üst üste birikmiş logları okumak için en hızlı yol bu. Ancak test kısmında kendi bilgi birikimime ve içgüdülerime güveniyorum. Böyle hatalarda neden karmaşık ve çok yüzlü olabilir ve tek bir kanıta dayanarak aslında hiçbir zaman kesin emin olamazsınız. Bir AI’nın RMA gibi radikal bir önlemle sonuçlandırdığı bir tanıyla harekete geçmeden önce, diğer bileşenleri elemek için bir test yapmak her zaman iyi bir fikirdir ve ben bunu neredeyse pahalı ödeyerek öğrendim.