AMD Ryzen 7000 masaüstü CPU'larda ECC RAM desteği doğrulandı

 (sunshowers.io)
2 puan yazan GN⁺ 2023-10-10 | 1 yorum | WhatsApp'ta paylaş
  • AM5 çıkışı sırasında teknik özellik tablolarından kaybolan ECC RAM desteği, Ryzen 7000 “Raphael” ve ASRock anakart kombinasyonunda çalıştığını gösteren örneklerle yeniden doğrulandı
  • Testler Ryzen 7950X, ASRock B650E PG Riptide, UEFI 1.28, AGESA 1.0.0.7b ve iki adet v-color 32GB ECC UDIMM ile yapıldı; DDR5 link training sonrasında Linux başarıyla açıldı
  • dmidecode içindeki 72 bit bellek genişliği ve Multi-bit ECC göstergeleri yararlı ipuçları sunsa da, bunlar UEFI'nin SMBIOS bilgisinden geldiği için tek başına ECC'nin etkin olduğunu kanıtlamıyor
  • AMD UMC doğrudan SMN üzerinden sorgulandığında UmcCapHi içindeki bit 30 değeri ECC etkinlik durumunu gösteriyor; Linux ryzen_smu üzerinde de iki bellek kanalında bu bitin ayarlı olduğu doğrulandı
  • Gerçek hata enjeksiyonu yapılmadı, ancak Linux çekirdeğinin EDAC günlükleri UMC'nin ECC etkin bitini doğruladıktan sonra üretildiği için ECC'nin çalıştığına dair güçlü bir kanıt sağlıyor

Ryzen masaüstünde ECC desteğindeki değişim

  • AMD Ryzen masaüstü CPU'lar geçmişten beri resmî ECC RAM desteği ile öne çıkıyordu
    • Ryzen 1000~5000 serilerinin çoğu, uygun bir anakartla eşleştirildiğinde daha pahalı workstation sınıfı CPU'lara gerek kalmadan ECC RAM kullanabiliyordu
    • ASRock B550 Steel Legend teknik özellik sayfası, CPU nesline göre ECC RAM uyumluluğunu ayrıntılı gösteren bir örnek
  • Ryzen 7000 “Raphael” ve Socket AM5 çıkışıyla birlikte ECC desteğine dair ifadeler ortadan kayboldu
    • Pahalı bir AM5 anakart olan ASRock X670E Taichi teknik özellik sayfasında da yazının yazıldığı an itibarıyla ECC desteğine dair bir ifade yok
    • Ryzen 7950X yükseltmesinden sonra performanstan memnun kalınsa da, satın alma sırasında ECC'nin olmaması büyük bir eksiklik gibi kaldı

ASRock forumunda başlayan AM5 ECC testi

  • ASRock forum başlığında ApplesOfEpicness adlı bir kullanıcı, bir AMD mühendisiyle birlikte AMD AGESA firmware üzerinde ECC RAM'i çalıştırma deneyimini paylaştı
    • Güncellenmiş UEFI'ye sahip ASRock anakartta veri pini ile toprak pinini kısa devre ederek hatanın işletim sistemine kadar raporlandığını doğruladığını söyledi
  • Sonraki testte ASRock B650E PG Riptide ve iki adet v-color 32GB ECC UDIMM kullanıldı
    • Anakart UEFI sürümü 1.28'e, AGESA ise 1.0.0.7b'ye güncellendi
    • RAM değişiminden sonra uzun bir DDR5 link training sürecinin ardından sistem açıldı
  • Bu sistemde 64GB RAM için link training neredeyse 3 dakika sürdü
    • Ryzen 7000 masaüstünde bu işlem RAM değişimi veya zamanlama değişikliğinden sonra yalnızca bir kez gerekiyor ve UEFI sonucu önbelleğe alarak sonraki açılışlarda yeniden kullanıyor

Linux'ta görünen ECC göstergeleri ve sınırları

  • Linux üzerinde sudo dmidecode -t memory, ECC ile ilgili değerleri gösteriyor
    • Error Correction Type: Multi-bit ECC
    • Total Width: 72 bits
    • Data Width: 64 bits
  • Toplam genişliğin 72 bit olması dikkat çekici bir işaret
    • ECC olmayan RAM'de bu değer 64 bit olarak görünüyor
    • 64 bit ECC RAM, parity verisi için ek 8 bit taşıyor
  • Linux çekirdeğindeki EDAC mekanizmasının da etkin olduğu görüldü
    • EDAC MC: Ver: 3.0.0
    • EDAC MC0: Giving out device to module amd64_edac
    • EDAC amd64: F19h_M60h detected

Neden yalnızca dmidecode yeterli değil

  • dmidecode, bilgisayarın DMI veya SMBIOS tablolarını insan tarafından okunabilir biçimde gösteren bir araç
    • Bu tablolar donanım bileşenleri, seri numaraları ve BIOS revizyonları gibi bilgileri içeriyor
    • Donanımı doğrudan taramaya gerek bırakmasa da, gösterilen bilgiler güvenilir olmayabilir
  • SMBIOS, BIOS'un ürettiği yönetim bilgisini okumak için veri yapıları ve erişim yöntemlerini tanımlıyor
    • Böylece işletim sisteminin aygıtları doğrudan taraması gerekmiyor
  • ECC ile ilgili dmidecode bilgisi işlemciden değil, UEFI'den geliyor
    • Bellek hızı gibi bazı bilgiler bellek denetleyicisinden gelebilir
    • Ancak ECC bilgisi UEFI kaynaklı olduğundan, belleğin ECC desteklediğini gösterebilir ama ECC'nin gerçekten etkin olduğunu garanti etmez
  • ECC'nin etkin olup olmadığına nihai olarak sistemin bellek denetleyicisi karar verir

AMD UMC'yi doğrudan sorgulama yöntemi

  • AMD işlemciler, System Management Network yani SMN adlı bir veri yolunu dışa açıyor
    • Bu veri yolu, AMD Unified Memory Controller yani UMC'yi sorgulamak ve yapılandırmak için kullanılabiliyor
  • illumos'un AMD UMC belgeleri üzerinden UmcCapHi register'ı sorgulanarak ECC'nin etkin olup olmadığı görülebiliyor
    • İlgili bilgi, açık AMD Processor Programming Reference'ın bir parçası değil; bunun izi açık kaynak Linux ve illumos çekirdek kaynaklarında sürülebiliyor
  • SMN'e doğrudan erişim riskli
    • Özellikle yazma komutları bilgisayara ciddi zarar verebilir
    • SMN üzerinde yazma işlemi yapılmamalı
  • illumos tarafında Ryzen 7000 işlemcisinin iki bellek kanalı ayrı ayrı sorgulanıyor
    • Kanal 0 adresi: 0x50df4
    • Kanal 1 adresi: 0x150df4
    • Her iki kanalda da dönen değer 0x40000030
  • Buradaki kritik nokta bit 30
    • Bu bit ayarlıysa, bellek denetleyicisinde ECC etkin demektir

Linux'ta ryzen_smu ile SMN sorgulama

  • Linux'ta da ryzen_smu sürücüsü üzerinden SMN veri yoluna erişilebiliyor
    • Bu sistemde kurulum için bir patch gerekiyordu
  • Sürücü /sys/kernel/ryzen_smu_drv/smn dosyasını sunuyor
    • Sorgu için 4 baytlık adresin little-endian biçiminde yazılması, 4 baytlık sonucun da little-endian biçiminde okunması gerekiyor
  • Bir Python betiğiyle iki kanal sorgulandığında sonuçlar şöyle oldu
    • 0x00050df4: 0x40000000
    • 0x00150df4: 0x40000000
  • Dönen değerde ilk nibble'daki 4, bit 30'un ayarlı olduğunu gösteriyor; yani bellek denetleyicisi ECC'nin etkin olduğunu bildiriyor
  • Windows'ta da SMUDebugTool benzeri araçlarla benzer sorgular mümkün olabilir, ancak bu aracın çalışması garanti edilmiyor

Gerçek hata enjeksiyonu ve EDAC güvenilirliği

  • ECC'nin çalıştığını en kesin biçimde doğrulamanın yolu gerçek hata enjeksiyonu yapmak
    • ApplesOfEpicness, anakart üzerindeki veri pini ile toprak pinini kısa devre etti
    • Başka bir yöntem de RAM overclock'u kararsızlık noktasına kadar yükseltmek olabilir
  • Bu testte fiziksel pin kısa devresi veya tekrar tekrar RAM overclock denemesi yapılmadı
    • DDR5 link training'in her seferinde birkaç dakika sürmesi de overclock testlerini zahmetli hale getiriyor
    • Şu ana kadar doğal olarak oluşan bir hata da gözlemlenmedi
  • Linux çekirdeğindeki EDAC mesaj yolunun, AMD UMC'nin ECC etkin bitine bağlı olduğu görülüyor
    • Giving out device to module günlüğü edac_mc_add_mc_with_groups içinden geliyor
    • Bu fonksiyon init_one_instance yolu üzerinden çağrılıyor
    • init_one_instance, yalnızca pvt->ops->ecc_enabled doğruysa çağrılıyor
    • Ryzen 7000 yani Zen 4, 0x19 familyasına ait ve bu durumda umc_ops içindeki umc_ecc_enabled kullanılıyor
  • umc_ecc_enabled, umc_cap_hi içindeki UMC_ECC_ENABLED bitini kontrol ediyor
    • UMC_ECC_ENABLED, bit 30
    • AMD işlemcilerde EDAC MC0: Giving out device to module amd64_edac mesajı, UMC'nin ECC'nin etkin olduğunu bildirdiğine dair güvenilir bir gösterge

Sonuç

  • Ryzen 7000 masaüstü CPU'larda da en azından ASRock anakart kombinasyonlarında ECC RAM'i nispeten kolay biçimde çalıştırmak mümkün görünüyor
  • dmidecode içindeki SMBIOS tabanlı bilgi tek başına yeterli değil; ancak UMC'nin bit 30 değeri ve Linux EDAC yolu birlikte değerlendirildiğinde ECC'nin etkin olduğu daha doğrudan doğrulanabiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-10
Hacker News yorumları

  • İşlemci yükseltmem gerekiyor ve ECC RAM yapılandırmasıyla oldukça ilgileniyorum.
    /r/AMD’de AMD işlemcilerin ya da anakartların gerçekten ECC’yi destekleyip desteklemediği konusunda iki kişinin tartıştığı bir gönderi gördüm ama kimin haklı olduğunu bilmiyorum: https://www.reddit.com/r/Amd/comments/lzxqod/list_of_am4_mot...
    Bu yazıyla AMD+ASRock kombinasyonunun gerçekten ECC RAM olduğu kesinleşiyor mu, merak ediyorum.

    • Anakart satın alırken teknik özelliklerde ECC desteğinin açıkça belirtilip belirtilmediğini kontrol etmek gerekir.
      Genelde “Memory” bölümünde “ECC & Non-ECC, Unbuffered Memory” gibi bir ifadeyle yazılır.
      “On-die ECC” ifadesine dikkat edilmeli; bu, Non-ECC bellekte de bulunan bir özellik olduğundan burada bahsedilen ECC ile ilgisi yoktur.
      ECC DDR5 UDIMM satın almak gerekir; AM5 anakartlarla uyumlu olmayan ECC DDR5 RDIMM’i yanlışlıkla almamak gerekir.
      ECC DDR5 UDIMM 80 bit veya 72 bit genişliğinde olabilir; Non-ECC DDR5 UDIMM’in 64 bitlik genişliği olmadığı sürece sorun yoktur.
      Eskiden kontrol ettiğimde ECC destekli AM5 kartı en çok ASUS’ta vardı ve GPU yuvası dışındaki PCIe genişletilebilirliği iyi olduğu için PRIME X670E-PRO WIFI’yi en çok beğenmiştim.
    • ECC’de “destek” birkaç seviyede olabilir.
      0, hiç desteklemeyip ECC RAM takıldığında sistemin açılmaması düzeyi; 1, takılabilse de ECC işlevinin kullanılmaması düzeyi; 2, devre mevcut olsa da anakart üreticisinin hata algılama/düzeltmeyi doğrulamadığı düzey; 3 ise ECC işlevinin bulunduğu ve üreticinin bunu doğruladığı düzeydir.
      Supermicro gibi sunucu sınıfı bir kartta 3. seviye beklenebilir.
      AMD işlemcilerde “ECC supported” göründüğünde bunun hangi seviye olduğunu bilmek zordur; ancak Intel’de CPU/yonga seti ECC’yi destekliyor deniyorsa bunun gerçekten desteklendiği varsayılabilir.
    • ASRock’u bilmiyorum ama ASUS X570 kartlarda ECC’nin kesin olarak çalıştığını biliyorum.
      Bilerek arızalı bir ECC DIMM kullanarak kısa süre içinde düzeltilebilir ve düzeltilemeyen hatalar oluşturabildim.
      Diğer bileşenlerin hepsi hazırken ASRock’un kablolamayı yapmamış olma ihtimali düşük görünüyor; çekirdek ECC olduğunu söylüyorsa doğrudur diye bakarım.
      Değilse kartı arızalı diye iade edip başka bir üretici kullanabilirsiniz.
    • X570 ve B550 ASRock kartlarda ECC kullanıyorum; ASRock uzun süredir unbuffered ECC’ye izin veriyor.
      Yalnız mini-ITX/mATX X670E kartının olmaması üzücü. Onlar sadece ASUS’ta var.
    • ASRock X570 PG 4S + Ryzen 5 2600 + Kingston 32GB 2666 ECC kombinasyonunu kullanıyorum ve bu kartın CPU/bellek destek listesinde de bu yapılandırmada ECC’nin çalıştığı belirtiliyor.
      dmidecode 72 bit yerine 128 bit veri genişliği bildiriyor, ancak tek bit değil çok bitli düzeltmeyi de raporluyor.
      Intel kartlardaki UDIMM’lerde, örneğin Supermicro+Xeon’da 72 bite alışkındım; fakat bu bilgi gerçek donanım desteğinden çok bellek denetleyicisinin ve anakartın raporlama biçiminden etkileniyor gibi görünüyor.
      Yine de EDAC çalışıyor, doğru sürücü kaydediliyor ve EDAC/RAS’ten düzeltilebilir hataların gerçekten düzeltildiğine dair ara sıra uyarı alıyorum; bence bu kadarı konuyu kapatmaya yeter.

  • Konudan biraz sapıyor ama eski AM4 platformunda ve Zen3 APU çekirdeklerinde de çalışan ECC desteği bu şekilde görünüyor; benim sistemimde kesinlikle mevcut.
    ASRock B550M-ITX/ac ve AMD Ryzen 5 PRO 5650G kombinasyonunu kullanıyorum; daha önce Ryzen 5 3600 ve harici GPU kullanırken de aynı şekilde çalışıyordu.
    Güncel GNU/Linux’ta ECC etkinliğini algılayıp kaydetmek için rasdaemon hizmetini etkinleştirmek gerekir.
    Bu hizmet MCE’leri ve diğer donanım ilişkili hataları yorumlayıp veritabanına kaydeder; yukarıda sorgulanan çıktı da bunun sonucudur.

    • Bu hata sıklığıyla, ECC’siz bir bilgisayarın ürettiği bilgilere güvenmek zor gelebilir.
      Ancak tekrar düşününce sıklık epey yüksek; bellek modülü bozulmuş da olabilir. Özellikle her seferinde aynı modül ve aynı adres olması bunu düşündürüyor.
    • APU’lar, PRO SKU dışında ECC desteği kapsamından açıkça hariç tutulmuş durumda.
      https://www.asus.com/global/support/FAQ/1045186/
    • Gigabyte B550I sistemime ECC RAM taktım; dmidecode 72 bit genişlik gösteriyor ve dmesg | grep -i EDAC da ECC’nin açık olduğuna benzer pek çok bilgi gösteriyor.
      Ancak ilgili komut çıktısı boş ve yalnızca “No Memory errors”, “No PCIe AER errors”, “No Extlog errors”, “No MCE errors” çıkıyor.
      Hataların kaydedilmesi için bir şeyi etkinleştirmem mi gerekiyor, yoksa dmidecode ve dmesg beni yanıltıyor mu, merak ediyorum.
    • Hangi bellek modülünü kullandığınızı merak ediyorum.

  • İyi bir yazı. Ben de Threadripper anakartımda ECC RAM kullanıyorum
    Blekko operasyon ekibinin Intel anakartlarda fark ettiği şeylerden biri, düzeltilebilir hataları gerçekten raporlaması için anakarta bunu açıkça söylemek gerektiğiydi
    Varsayılan davranış, kurtarılamayan bir hata varsa machine check üretmek, diğerlerini ise sessizce geçmekti
    Yaklaşık 1600 adet 192GB sistemde düzeltilebilir hataları kabaca haftada 1 kez gördüğümüzü hatırlıyorum
    6 yıl boyunca hiç kurtarılamayan hata hatırlamıyorum; bu da oldukça iyiydi

    • Siz daha şanslıymışsınız. Bizim sistemlerimiz ayrıca istemeden de düzeltilebilir hataları raporluyordu
      Benzer ölçekte ekipmanımız ve ortalama olarak benzer RAM kapasitemiz vardı; kurtarılamayan hatalar da ara sıra oluyordu. Muhtemelen yılda bir iki kez kadar, bu yüzden bir politika oluşmuştu
      Tek seferlik mi diye izlerdik; kısa süre içinde tekrar arızalanmazsa sorun yok sayardık, kısa süre içinde tekrar arızalanırsa RAM’i değiştirirdik
      Daha iyi sunucu anakartları, hangi RAM modülünün değiştirilmesi gerektiğini LED ile bile gösterir
      Düzeltilebilir hatalarda sayı epey yükselmeden değiştirme yapmazdık; günde bir iki hata veren sistemler bile uzun süre sorunsuz çalıştı
      Buna karşılık uzun süre 0’da gidip birkaç gün az sayıda hata verdikten sonra büyük sayılara sıçrayan sistemler de vardı
      Bir sistem saatte binlerce hataya kadar çıkmıştı; machine check exception işleme maliyeti yüzünden sistem kullanılamaz hale gelmişti, ama raporlama periyodu 1 saat olduğu için bir sonraki rapora kadar sebebi bilmiyorduk

  • Şu anda Ryzen 3700X ve ASUS TUF Gaming X570 anakart kullanıyorum; daha fazla tek çekirdek performansına ve NVMe/disk hızına ihtiyacım var
    Çift GPU, 2 adet M.2 NVMe ve 6 adet SATA’yı zaten kullanıyorum
    Yıl sonu yükseltmesini düşünüyorum; PCIe hatları yüzünden Threadripper’ı da kısa süre düşündüm ama Zen4 Threadripper henüz yok ve fiyatı da muhtemelen çok yüksek olur
    Seçeneklerim Ryzen 5900X’e geçip geri kalanını korumak ya da daha fazla para harcayıp AM5 Ryzen ve yeni anakarta geçmek
    Intel’e de baktım ama PCIe hatlarının 20’de bittiğini görünce eleme tarafına kaydım
    10Gb adaptör ekleyip döner disklerin bir kısmını dışarı taşımak istediğim için daha fazla PCIe hattına ihtiyacım var
    3700X’in çok çekirdek performansı yeterli; yeni anakart alırsam hız için en az 2 NVMe mirror ve 6’dan fazla SATA portu istiyorum

    • İki NVMe’yi mirror olarak kullanmayı denedim ama maksimum performansı almak için dikkat edilmesi gereken çok nokta var
      AMD tarafını bilmiyorum ama Intel anakartlarda genelde yalnızca bir M.2 yuvası doğrudan CPU’ya bağlı oluyor, diğer üçü yonga seti üzerinden geçiyor; bu da 10Gb Ethernet kartıyla darboğazı paylaşmaları anlamına geliyor
      Sonuçta PCIe 5.0 destekli bir anakart ve yeterince büyük tek bir SSD almak çok daha hızlı oldu; hem toplam IOPS hem de aktarım hızı önceki RAID 0 diziliminden yüksekti
    • Hangi iş yükünde NVMe hızı darboğaz oluyor merak ediyorum
    • 5900X kullanıyorum; keşke bekleyip 5800X3D alsaydım diye hissediyorum
    • Daha fazlası gerekiyorsa fiyatı yaklaşık 4/3 iken çekirdek sayısı iki kat olan 5950X’e geçmek ya da Factorio UPS için 3D önbellekli CPU düşünmek daha iyi
      5900X o kadar büyük bir yükseltme değil

  • Referans örnek olarak Hetzner, birkaç aydır ECC RAM takılı Ryzen 7000 CPU sunucular sunuyor
    https://www.hetzner.com/dedicated-rootserver/matrix-ax
    AX52, ECC RAM’i isteğe bağlı yükseltme olarak sunuyor; AX102’de ise ECC varsayılan olarak geliyor
    Gerçekte çalışmayan ECC sunacaklarını sanmıyorum

    • Bildiğim kadarıyla Hetzner kendi anakartlarını yapıyor ya da yaptırıyor
      Bu yüzden baştan sona ECC desteğini kesin biçimde garanti edebilirler

  • Keşke yasa koyucular aklını başına alıp ECC’yi zorunlu kılsa
    Hesaplamaların çoğunun kırılgan Non-ECC sistemlerde yapılması tedirgin edici
    Yapay piyasa bölümlendirmenin çok berbat bir biçimi

    • Milletvekillerinin Zuck gibi insanları çağırıp telefonda nasıl işlem yapılacağını sordukları oturumları görmemiş olmalısınız
      Böyle insanların ECC hakkında yasa çıkarmasını nasıl bekleyebiliriz
    • Non-ECC sistemlerin kırılgan olduğunu söylemek zor; zamanın %99,9999’unda tamamen düzgün çalışan bir şeye kırılgan demek kolay değil
    • Non-ECC makinelerin tamamen kırılgan olduğu söyleniyor sık sık; hesaplara bakınca bit flip’lerin sürekli olması gerekiyormuş gibi görünüyor
      Ama benim Intel sistemim 64GB Non-ECC RAM ile her gün yarım gün çalışıyor, geceleri hazırda bekletmeye geçiyor; 3D CAD, Photoshop, eklenti dolu VS Code ve WSL2 Docker container’ları çalıştırmama rağmen neredeyse hiç hata görmüyorum
      Çökme ya da mavi ekran da yok
      Bit flip hatasından tam olarak ne beklemem gerektiğini merak ediyorum. 64GB RAM’in neredeyse tamamını kullandığım bir durumda tek bitlik dönüşler bu kadar sık oluyorsa, bir şekilde kendini belli etmesi gerekirmiş gibi geliyor

  • Fiziksel olarak pinleri kısa devre ettirecek cesaretim yok; DDR5 link training’i için her seferinde dakikalarca bekleyerek RAM’i yavaş yavaş overclock edecek sabrım da yok.
    Bu yüzden bellek denetleyicisinin ECC’nin açık olduğunu raporlamasıyla yetiniyorum.
    Onun yerine RAM’e saç kurutma makinesinin sıcak havasını üflemek nasıl olur? Eskiden hata oluşturmak için böyle bir teknik kullanıldığını görmüştüm.

    • Yakın mesafeden propan barbekü çakmağı kullanmak işe yarar. Böyle şeyler akıl almaz düzeyde elektromanyetik girişim üretir.
      https://hackaday.com/2022/01/29/blast-chips-with-this-bbq-li...
      https://hackaday.com/tag/emfi/
    • Daha gerçekçi olarak, çalışan bir sistemde bellek overclock ayarlarının bir kısmı gerçek zamanlı ayarlanabiliyor ve link training de gerekmiyor.
      Gerçek kullanım için önerilmez ama bellek sınırlarını bulmak veya hata oluşturmak için kullanılabilir.
    • Sistemde ECC RAM olup olmadığını Rowhammer testi ile doğrulamak mümkün mü?
      Benim overclock edilmemiş I7-4770K sistemimde hatalar ortaya çıkıyor, ancak eski Supermicro X10 nesli kartta Rowhammer testi süresiz çalışsa da hata algılanmıyor gibi görünüyor.
      Yine de modern sistemler Rowhammer saldırılarına açık olmayacak şekilde tasarlandıysa bu yöntem işe yaramayabilir.
      Raspberry Pi 4B ve CM4’ün RAM’inin ECC RAM kullandığı biliniyor, fakat burada sözü edilen ECC’den farklı.
      Bu, on-die ECC ve amacı çip verimini artırmak; ECC hataları donanım üzerinden raporlanmadan düzeltiliyor.
      Düzeltilemeyen ECC hataları muhtemelen doğrudan yanlış veri olarak okunur.
      Modern RAM modüllerinin de on-die ECC’li çipler kullanıp kullanmadığını merak ediyorum.
    • Telefonu DIMM’in yakınına getirip hata tetiklemek mümkün olmaz mı? Denemesi kolay gibi görünüyor.
    • 10 yıl sürekli çalışacak yüksek hızlı I/O PCBA’da BGA’yı yeniden eritip lehimleme olasılığı yaratmak, diyotla korunan bir pin çiftini kısa devre etmekten daha riskli görünüyor.
      Link training BIOS’tan kapatılabildiği için sınırdaki bant genişliği ayarları hızla bulunabilir.
      Sonuçlar çok tekrarlanabilir olmayabilir ama bunun önemi yok.

  • Bazı, belki de tüm ASUS AM5 anakartlarda resmi ECC desteği var.
    Az önce kontrol ettiğim modelde hem kart kılavuzunda hem de BIOS kılavuzunda yazıyor.
    İlgili BIOS ayarlarından birinin varsayılanı Auto, fakat sezginin aksine bu durumda devre dışı kalıyor; dolayısıyla değiştirmek gerekiyor.
    Bu işlemciler için ECC raporlaması Linux 6.5’e girdi, bu nedenle Debian Stable kullanıcılarının Backports’a gelmesini beklemesi veya standart yolun dışına çıkması gerekiyor.
    https://www.phoronix.com/news/AMD-EDAC-Ryzen-7000-Series

    • BIOS’taki Auto ayarlarından gerçekten nefret ediyorum.
      Gerçekte uygulanan değeri görebilsek yine iyi, ama onda dokuzunda net olmuyor.

  • Eski AGESA sürümlerinde, yonga setinin ECC RAM’i doğru tanıyıp kullanmasını engelleyen bir hata olduğuna dair söylenti var.
    Söz konusu yonga setinin bunu desteklemesi gerektiği hâlde böyle olduğu söyleniyor.
    Düşünülen anakartın en az AGESA 1.0.0.5 patch C içeren bir firmware güncellemesi olup olmadığı kontrol edilmeli.
    https://www.reddit.com/r/truenas/comments/10lqofy/
    AGESA, AMD sistem firmware’inin bir parçasıdır ve temel sistem bileşenlerini başlatır: https://en.wikipedia.org/wiki/AGESA

    • ASRock forum başlığına bakınca doğru gibi görünüyor.
      ECC RAM takmadan önce AGESA 1.0.0.7b’ye güncellemiştim.

  • Ryzen 7000 serisinin ECC desteğini resmi olarak belirtmediğini bilmiyordum.

    • Bu yazıyı paylaştıktan sonra resmi olarak ECC destekleyen AM5 anakartlar olduğunu öğrendim.
      Örneğin ASRock Rack serisi destekliyor: https://www.asrockrack.com/general/productdetail.asp?Model=1...
      Bu ASUS anakart da ECC desteği sunduğunu iddia ediyor: https://www.asus.com/us/motherboards-components/motherboards...
      İkisi de ben ilk AM5 anakartımı aldığım sırada çıkmamıştı. Çıkıştan hemen sonraydı ve performans rakamları çok iyi olduğu için erkenden atlamıştım.
    • Yazarın içeriği yanlış yorumlanmış.
      Şu anda satılan tüm Ryzen 7000 serisi CPU’larda resmi ECC desteği var, ancak anakart desteği de gerekiyor.
      Bu tür koşullu ECC desteği aslında Athlon 64’e kadar uzanan AMD tüketici CPU’larında hep vardı, fakat Ryzen 7000 serisinde AMD pazarlama materyallerinde açıkça belirtildiğini ilk kez görüyor gibiyim.
      Yazarın söylediği, ASRock anakart belgelerinden ECC desteği ifadesinin kaldırıldığıydı.
      ASRock önceki Ryzen anakartlarında ECC desteğini belirttiği için bu dikkat çeken bir değişiklikti.
      Ryzen 5 7600 teknik özellik sayfası örneği: https://www.amd.com/en/product/12756#:~:text=ECC%20Support,R...)
    • Bu yıldan önce epey belirsizdi ve açıkça belirtilmiyordu.
      Üstelik tüm DDR5’in kullandığı on-chip ECC ile de karıştırılıyor.
      DDR5, normal çalışma sırasında oluşacak hataları düzeltmek için on-chip ECC’ye ihtiyaç duyar, ancak bu, bellek veriyolu üzerinden CPU’ya aktarılan verileri de koruyan ECC değildir.