Dotaz: ProLiant BL460c Gen8: mce: [Hardware Error]:

[BigWrigley]

Dobry den.

Mame HP enslosure a v nem nejake BL460c Gen8. OS RHEL 7.3. Jeden z nich zacal generovat chyby

May 02 21:34:38 ctx-aaa-be2 kernel: mce: [Hardware Error]: Machine check events logged
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: HANDLING MCE MEMORY ERROR
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: CPU 26: Machine Check Event: 0 Bank 9: 8c000044000800c1
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: TSC 0 
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: ADDR c13111000 
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: MISC 90000040004088c 
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: PROCESSOR 0:206d7 TIME 1493753678 SOCKET 1 APIC 25
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: TSC 0 
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: ADDR c13111000 
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: MISC 90000040004088c 
May 02 21:34:38 ctx-aaa-be2 kernel: EDAC sbridge MC1: PROCESSOR 0:206d7 TIME 1493753678 SOCKET 1 APIC 25
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: Hardware event. This is not a software error.
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCE 0
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: CPU 26 BANK 9
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MISC 90000040004088c ADDR c13111000
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: TIME 1493753678 Tue May  2 21:34:38 2017
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCG status:
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCi status:
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: Corrected error
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCi_MISC register valid
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCi_ADDR register valid
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCA: MEMORY CONTROLLER MS_CHANNEL1_ERR
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: Transaction: Memory scrubbing error
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MemCtrl: Corrected patrol scrub error
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: 
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: STATUS 8c000044000800c1 MCGSTATUS 0
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: MCGCAP 1000814 APICID 25 SOCKETID 1
May 02 21:34:38 ctx-aaa-be2 mcelog[1143]: CPUID Vendor Intel Family 6 Model 45
May 02 21:34:39 ctx-aaa-be2 kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0xc13111 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c1 socket:1 ha:0 

Chodi to nekolikrat denne, ruzne CPU, ruzny BANK, ale zda se, ze stejny kanal radice (MEMORY CONTROLLER MS_CHANNEL1_ERR). Myslim si, ze je to HW problem, ale cely den bezici diagnostika pameti/cpu nic nenasla. Myslim, ze problem je nekde v CPU nebo na desce, ale diky ECC se chyby neprojevi do OS tak, ze by server spadl. HP se nechce toto moc uznat jak HW problem.

Chyby ve vypis nize s casem narustaji.

[root@ctx-aaa-be2 ~]# grep "[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count
/sys/devices/system/edac/mc/mc0/csrow0/ch0_ce_count:0
/sys/devices/system/edac/mc/mc0/csrow0/ch1_ce_count:0
/sys/devices/system/edac/mc/mc0/csrow0/ch2_ce_count:0
/sys/devices/system/edac/mc/mc1/csrow0/ch0_ce_count:0
/sys/devices/system/edac/mc/mc1/csrow0/ch1_ce_count:65
/sys/devices/system/edac/mc/mc1/csrow0/ch2_ce_count:30

Otazky zni: 1. mam se tim dal zabyvat a tlacit do vymeny HW? (zatim to nicemu nevadi) 2. existuje nejaka diagnostika, ktera by ukazala, co je kde spatne? Zatim me napadlo pouze prohodit CPU mezi sebou, ev. prehazet nejak pameti.

Diky za tipy.

A.

Odpovědi

[R]

Vadna RAM.

[Trubicoid2]

Taky bych myslel vadnej jeden modul RAM. Zkus postupně po jednom vytahovat moduly, dokud chyba nezmizí.

Jednou jsem to měl tak. EDAC hlásil chyby, ale memtest je nenašel. Asi je to tím, že ECC chybu opraví a memtest to nepozná, kdežto EDAC to hlásí jak CE - correctable error.

[Peter Golis]

Vzdialenú konzolu nikto nekonfiguroval? Na nej je vidno zdravie železa nielen pre enclosure, ale aj pre servre v nej zapustené.

[BigWrigley]

Konzoli (onboard administrator) samozrejme pouzivame. Ale tam je vse ciste, ani iLO vlastniho serveru nic neregistruje.

[pc2005]

Hodnota CPU je jen číslo CPU který to selhání objevilo.

Znamená hodnota "ADDR" adresu používanou kernelem? Pokud by byla stejná tak to bude určitě problém jednoho DRAM modulu. (BTW 36bitů ... kolik má ten server RAM o_O)

HP se nechce toto moc uznat jak HW problem.

Jak dlouho bude ten server v záruce? Pokud už dlouho ne, tak bych to řešil co nejdřív, ono se to zlepšovat nebude. Ale časem budou aspoň naskakovat chyby v memtestu (nebo v tom co jsi na tom serveru pouštěl, umí to EDAC? Pokud ne, tak by to tu chybu asi potichu přešlo...).

Ještě je možný že je problém se DRAM slotem (to by se ale po vyndání a zandání DRAM modulů nejspíš zase rozběhlo), řadičem a nebo někde na plošňáku, ale ty poslední dva by byly rozhodně HW chyba a HP kecá. Taky může být problém se zdrojem (mě se špatným zdrojem blikaly pixely v ASCII konzoli jejíž framebuffer byl v system RAM), ale zase do serveru od HP nemůžou dát nějakej levnej eurocase za 400 Kč z výprodeje

[joke] Alternativou je dát ten server dál od vašeho reaktoru [/joke]

[BigWrigley]

Server uz neni v zaruce, ale je pod kontraktem, takze exisuje narok na opravu. Je v nem 48GB RAM, EDAC umi, prave proto to nepada, ale jen reportuje skrz HP utility chyby. Zdroj to nebude, je to bladecenter, kde tech zdroju je sest a skoro cele je obsazene.

[joke] Alternativou je dát ten server dál od vašeho reaktoru [/joke]

Dobrej for

[pc2005]

Je v nem 48GB RAM, EDAC umi, prave proto to nepada, ale jen reportuje skrz HP utility chyby.

Já myslel jestli ty utility pro testování RAM umí logovat hlášení z EDAC (klasickej memtest co se bootuje z diskety to IMO neumí). Pokud má na to HP vlastní memtest (nedivil bych se, on tu klasickou PC platformu často dost ohejbá) a pokud jeho memtest EDAC umí, tak ty chyby z něj by měly být dostatečné pro uznání hw chyby (ale asi záleží na podmínkách té smlouvy o podpoře). Pokud ten jejich memtest EDAC umí a žádný chyby nejsou hlášeny, tak je to divné. Pokud by HP memtest EDAC hlášení neuměl, tak logicky žádné chyby nebudou (ECC je potichu opraví ... zatím).

[BigWrigley]

HP ma primo v Biosu/UEFI utilitu, ktera se da bootnout a pak se da vybrat ruzna diagnostika. U pameti jsou ruzne typy testu (march a pod.), ale ani jeden z nich nic nezaznamenal. Takze, presne jak pisete, ECC imho chyby opravi a utilita hlaseni EDAC nijak nebere v potaz (nikde nic neni videt), coz je u testu pameti docela fail.

[Peter Golis]

Fail by to bolo keby chybovosť prerástla hranicu určujúcu zlyhanie, alebo keby boli tie chyby neopraviteľné. Ani disk sa nevymieňa ako vadný ak má len zopár retry, Kebyže áno tak by predsa všetci výrobcovia stiahli z trhu všetky USB disky.

[dustin]

O opravených chybách tohoto typu je potřeba vědět, protože obvykle značí blížící se reálnou poruchu DIMMu. Takže by bylo opravdu užitečné takové warningy v testu paměti vypisovat.

[BigWrigley]

Take si myslim, ze potlacovat, resp. nezobrazovat tyto chyby je neni dobre. Podminky nasledne reklamace mohou byt ruzne, tj. ze si vyrobce muze zasmluvnit, ze do urcite cetnosti to neni duvod k vymene, ale vedet by se o nich melo. Nota bene v momente, kdy je sw nastroje tehoz vyrobce v OS reportuji.

[pc2005]

Akorát že DRAM buňka není by design považována za degradující závislosti na počtu přístupů ani mechanické zařízení. Si představ že místo DRAM buňky by to byl dynamický tranzistor v procesoru.

[Peter Golis]

Vravel som o opakovaní prenosu, nie o poškodení zapísaných údajov. Si predstav akú majú spoľahlivosť USB2 disky pri vyššej záťaži kvôli latencii na ...

[pc2005]

U DRAM čipu se nedá, na rozdíl od flash a HDD, zablokovat chybové sektory (kromě výroby). Pokud budu už od začátku počítat s chybným bitem, tak jsem si nemusel kupovat stroj s ECC, protože to ECC často opravuje jen jednu chybu. u nonECC pamětí je samozřejmě nutnost mít všechny bity funkční (porucha jednoho bitu v celém modulu je dost na reklamaci).

[Peter Golis]

Vravel som o opakovaní prenosu, nie o poškodení zapísaných údajov. Je smutné že si takú drobnosť nepochopil.

PS: Ak ECC skoriguje chybu, a nepresiahne to chybovosť uznávanú ako medzník na reklamáciu, tak ECC funguje podľa očakávaní. Aj napriek tvojmu názoru. ECC predsa znamená error correcting code.

[Trubicoid2]

Ne, pleteš se. CE i UE je důvod k reklamaci RAM. Oprava ECC se neděje v paměti samotné, ale v řadiči paměti, který teď je na CPU. Korekce jsou různé druhy, můžeš si v bisu zapnout třeba chipkill, nebo ne. Zapnout scrub a různě rychlej, nebo ne. Pak je podle tebe paměť v pořádku se scrubem, nebo bez? A s chipkillem, nebo bez?

Pokud paměť dělá jedno CE za rok, tak je to normální, třeba kosmický záření. Pokud jich je několik za den, případně několik za týden, tak reklamace.

[Peter Golis]

Podľa tvojej logiky by mali utratiť na veľkej pardubickej každého koňa čo zakopol. Nielen tých, čo si zlomili nohu.

[Trubicoid2]

O koních moc nevím, o pamětech víc. Prostě paměť má buď 8 bitů anebo 9 bitů, kde se ten poslední použije na ECC. Pokud paměť vrací jiné hodnoty, než tam jsou zapsány, má se reklamovat. Tvoje dojmy, že časté CE jsou v pohodě, protože s chybami ECC počítá a opravuje, jsou zavádějící. Pokud z důvodu vadného modulu často nastává opravitelná chyba v jednom bitu, pak může častěji nastat i neopravitelná chyba ve dvou bitech a pak co? Kernel panic? Super

Závěr: reklamovat. Jak jsem říkal, jeden ECC modul jsem takhle reklamovat a výrobce Kingston nedělal problém.

[pc2005]

1 bit navíc ti neudělá ECC, maximálně jen detekci jedné chyby (ne její lokaci).

[Trubicoid2]

Ano, skutečná implementace je jiná, ale hustota je 9bit/byte pro ECC nebo 8bit/byte bez ECC

[pc2005]

Ono to není lineární (1 bit parity pro každejch 8 bitů dat) ale spíš logaritmická (?) závislost. Lepší je popis pomocí n=2^m-1, kde n=počet všech bitů (data+parita) a m=počet paritních bitů. Třeba pro 247 databitů ti stačí v hammingově kódu jen 8 paritních bitů.

[Trubicoid2]

Já měl za to, že to je lineární 9:8 prostě a pak je to otázka implementace v řadiči, tedy ne na modulu DRAM. Ale asi by byla blbost ty bity nepoužít, když už tam jsou

[pc2005]

lineární 9:8

Nn když máš 8 bitů dat a 1 bit parity, tak si schválně zkus, že při změně jednoho bitu nedokážeš z té parity vydedukovat kterej to byl (což potřebuješ pro 1 bit opravu).

[Trubicoid2]

To se tu zase sešli experti, nebo se jen nechápeme? :) Hele, ještě jednou: já říkám bitů v ECC modulu je oproti neECC modulu stejné velikosti víc v poměru 9:8. To prostě tak je a roste to lineárně.

Ve skutečnosti řadič nepouští do ECC paměti 8bit data + 1bit paritu, ale právě třeba ten tvůj hamming kód, nebo taky jiný. Takže koukni na konec odstavce ve svém odkazu o SECDED, kde píší, že třeba tvůj Hamming kód (127,120) + jedna parita navíc má právě přesně požadovanou hustotu 9:8.

[pc2005]

Ale to že to pro 64bit RAM vyjde je jen náhoda. Ta hustota je jen velmi hrubý odhad. Limita poměru končí v 1:1 a třeba hamming pro 1 bit jsou dva paritní pro jeden datový (3/1).

Nemůžeš brát hamming algoritmus podle implementace v RAM modulech. V hammingovi je použitej ten 120bitovej a protože počítače obvykle používaj sběrnici o šířce 2^n, tak se použije jen část (64) z těch 120 bitů. Kdybys z těch 120 bitů vzal 96 bitů (64+32), tak by ti pro opravu stále stačilo těch 7+1 paritních bitů ale ten poměr bys rozbil.

[Trubicoid2]

Tak teď jsem se ztratil, netvrdíš tady, že velký ECC moduly mají skoro stejně bitů jako neECC, tedy že ten poměr se blíží 1:1? Že ne? A taky se nebavíme obecně o hamming kódech, ale právě o ECC pamětech, že?

Protože naposledy říkám, že všechny ECC moduly jsou z výroby o 9:8 větší než neECC a nezáleží na jejich velikosti. Tak je to prostě vyrobeno.

Navíc na modulu vůbec žádný kódy neběží, modul jen čte nebo zapisuje kódovaný data. Ty kódy běží v řadiči a mohou být různý. To, že se používá zkrácený optimální (127,120) na (72,64) tedy vůbec není náhoda, ale je to dáno tím, jak ty paměti ve skutečnosti vypadají, tedy 9:8 a taky tím, že dřív ten řadič nebyl na CPU a byl to zvlášť šváb, který ECC implementoval. Viz třeba tento.

[R]

Presne tak, rozdiel medzi ECC a non-ECC DIMM je len v tom, ze namiesto 8 pamatovych cipov je ich tam 9 (pripadne nasobky tychto cisel). Na niektorych non-ECC DIMM (hlavne starsich - SDRAM, DDR) aj vidiet prazdne miesto na ten 9. cip. Stacilo by ho tam prispajkovat, pripadne pridat par pasivnych suciastok okolo (ak nejake chybaju) a prepisat EEPROM.

[pc2005]

Tak teď jsem se ztratil, netvrdíš tady, že velký ECC moduly mají skoro stejně bitů jako neECC, tedy že ten poměr se blíží 1:1?

Ano přesně to tvrdím. 64 bitová RAM má 72 bitů pokud je ECC (+8 ECC slovo), 128 bitová RAM by měla 137 bitů pokud by byla ECC (+9 ECC slovo). Pokud budou jednou ECC HBM v počítačích, tak ty by klidně mohli mít třeba 4096 bitové slovo. Hypotetická RAM se slovem dlouhým 1 milion bitů by v ECC provedení měla 1 milion a 20 bitů délku.

Jejich poměr by byl víc a víc blízký 1:1.

A taky se nebavíme obecně o hamming kódech, ale právě o ECC pamětech, že?

V tom případě musíš zahrnout ECC třeba pomocí TMR (Triple modular redundancy), kde by pro 64 bitovou RAM bylo dalších 64+64 bitů pro opravu.

Ono jde o to kolik těch bitů chceš opravovat. Pokud jeden bit z 64, nebo tisíc bitů z miliónu, nebo všechny v daném slově ... tak se to pak projeví na délce parity.

Viz třeba tento.

Když se koukneš na stránku 3, tabulku 1, tak jaký poměr datových a celkových bitů je pro poslední dva řádky?

[Trubicoid2]

Tak teoreticky ten poměr jde k 1:1, to je ale prakticky na prt, protože jsem ještě neviděl standartní DDR modul s šířkou větší než 64 bit.

A taky nevím proč šířce říkáš velikost? Prostě prakticky DDR3 ECC 8GB má s paritou 9GB, tedy 9:8 a nezávisí to na velikosti (neeee šířce). Tedy 16GB ECC bude mít s paritou 18GB.

Nebo bys chtěl třeba kvůli jednomu bytu číst několik okolních adres, aby to bylo pomalejší, hlavně že ušetříš paritní bity, který tam stejně jsou z výroby?

A kód ať si tam běží, jakej chce. Třeba by se to dalo kombinovat i s šifrováním. Existoval i projekt softwarové ECC nad běžnou pamětí. Jedinej problém byl, že to bylo ukrutně pomalé. Ale tam bys mohl dát kód nad 1Mb klidně. To pak bude náhodné čtení z paměti ještě pomalejší.

[pc2005]

protože jsem ještě neviděl standartní DDR modul s šířkou větší než 64 bit

Rambus DRAM mělo 16bitů. Jedna vývojová deska od TI měla tuším jen 32bitů a jak jsi linkoval alteru, tak zrovna u FPGA je jedno kolik máš bitů pro data i pro ECC. Hlavně ECC není zrovna standardní aplikace. Pokud bysme se bavili o speciálních a historických strojích tak tam byly datová slova o šířce jiné než 2^n. Stejně tak můžeš mít ECC pro framy v FPGA. Tam je to odhadem tak tisíce bitů vůči 32 bitům (záleží na architektuře) a samozřejmě nejrůznější DSP budou mít taky speciální šířku slova.

A taky nevím proč šířce říkáš velikost?

To jsem psal kde? o_O ... O velikosti jsi psal jenom ty.

Jinak ano pro 64bit modul s tím 8bit ECC bude celková kapacita RAM modulu podle toho poměru 9:8, ale moc užitečná hodnota to není :-/.

Nebo bys chtěl třeba kvůli jednomu bytu číst několik okolních adres, aby to bylo pomalejší, hlavně že ušetříš paritní bity, který tam stejně jsou z výroby?

Jestli to bylo k tomu TMR, tak tam budou tři sady RAM modulů (v zásadě takovej RAID). Celková kapacita RAM modulů pak bude trojnásobná.

[trubicoid2]

To jsem psal kde? o_O ... O velikosti jsi psal jenom ty.

no, já psal od začátku, že je poměr 9:8 a nezávisí na velikosti, k čemuž tys napsal, že pro velké velikosti to půjde k 1:1 a až pak jsem pochopil, že mluvíš o šířce a nee velikosti

tak hlavně že jsme se pochopili :)

[pc2005]

[pc2005]

A co když ten kůň bude zakopávat o každou překážku?

ECC je od ochrany proti jednorázovými single event upsety, kdy do DRAM buňky narazí energetická částice a přehodí jí stav. Protože to je server tak se požaduje, aby ty data byly opraveny bez výpadku. A protože to je single event upset, tak se čip konstruuje obvykle jen pro opravu jedné chyby a detekci dvou chyb. Pokud je v paměti jedna buňka permanentně zničená, tak zbývá jen ta detekce jedné další chyby (každá porucha v tom slově pak znamená poškození dat, což je na 24/7 serveru nemilé).

Pokud bys bral DRAM čip jako médium se šumem, tak bys musel mít mnohem delší opravný kód. Pro 64bit plain-text slovo bys potřebovat mnohem delší codeword slovo. Třeba takovej golayúv kód (24 bitů) má dvojnásobnou délku plaintextu (12 bitů) a umí opravit jen 3 bity.

[Peter Golis]

Ak bude ten kôň zakopávať o každú prekážku, tak bude vyzerať ako ty pri maturite. Podľa tvojej logiky by si mal vrátiť ten papier.

[pc2005]

?

[pc2005]

Vravel som o opakovaní prenosu, nie o poškodení zapísaných údajov.

Pak nechápu proč taháš retry do diskuze o poškození zapsaných údajů.

Ak ECC skoriguje chybu, a nepresiahne to chybovosť uznávanú ako medzník na reklamáciu, tak ECC funguje podľa očakávaní.

Ne, pokud má v běžném provozu ECC paměť periodický výskyt chyby na stejném místě, tak je to zmetek z výroby, kde měli tu řádku DRAM buněk vyměnit za funkční spare.

[Peter Golis]

Vytiahol som to ako ukážku kde korekcia dodá bezchybný výsledok bez strát. Tak je to v prípade ECC, alebo zopakovaní prenosu údajov po USB zbernici.

PS: Ak je to nepodarok z výroby, tak máte možnosť splniť dôkazné konanie a pretlačiť to napríklad cez ČOI. Ale, to dôkazné konanie už asi bolo určite negatívne keďže v diskusii spomínané nepriestrelné argumenty v neprospech ECC sú založené na súkromných dohadoch vyplývajúcich z nepochopenia použitej technológie.

[Trubicoid2]

Tak to ECC všichni chápou, až na tebe :) Asi sis přečet něco o samoopravných kódech pro HDD/SDD a teď děláš chytrýho? V případě pamětí se ale netolerují vadné bity a hotové.

[pc2005]

Až na to že retry u USB znamená akorát poškození dočasné pracovní kopie dat (v cache, v bufferu apod.), ale to co má OP tématu je pravděpodobně permanentní fyzické poškození. U USB bude nejspíš příští přenos OK (protože původní záznam bude v pořádku). Pokud bys u tom RAM modulu dělal retry, tak se zacyklíš, protože ať tam zapíšeš co zapíšeš, tak budeš mít pořád chybu (ten poškozenej bit je efektivně černá díra - a z té informaci ven nedostaneš ). A jistě sám uznáš, že RAM modul při jehož používání se zacykliš v retry, je dost k ničemu.

Ak je to nepodarok z výroby

Však jsem tazateli psal, že ho HP nejspíš jen blokuje na takovém tom klasickém first line support firewallu .

[Peter Golis]

Pokud bys u tom RAM modulu dělal retry, tak se zacyklíš, protože ať tam zapíšeš co zapíšeš, tak budeš mít pořád chybu (ten poškozenej bit je efektivně černá díra - a z té informaci ven nedostaneš ). A jistě sám uznáš, že RAM modul při jehož používání se zacykliš v retry, je dost k ničemu.

To máš potom dosť skreslené informácie o tom, ako funguje ECC.

[pc2005]

Retry se na RAM modulu samozřejmě nedělá, takže pak nechápu proč retry taháš do diskuze.

[Peter Golis]

Retry, ako som už spomínal, je jeden zo spôsobov korekcie. Som rád že si sa priznal že nechápeš význam slova korekcia.

[Trubicoid2]

Jedině ecc před testem v biosu vypnout, otázka je, jestli to jde.

Správná paměť má mít nula CE i UE. Já ten svůj vadný dimm vyreklamoval, Kingston myslím. Novej v pohodě. Ještě zajímavý, že začal dělat chyby až zahřátej, za studena nebo s otevřeným krytem v pohodě. Teplota při chybách byla v toleranci, takže výměna. Jen to ztěžuje najití vadného modulu.

[dustin]

Memory scrubbing error - zatím mi vždycky pomohlo vyměnit vadný DIMM. Pokud je to v záruce, výrobce to musí uznat, nedal bych se odpálkovat. Je to jasný HW problém. Jinak bych si jej vyměnil sám.

Někdy mají chybu ve firmwaru (např. dell v jednom serveru) a jsou to plané poplachy. Ale i to dell řešil, než po šesté výměně desky uznali, že to hardwarem nebude. Bohužel servisní technici netušili, co to edac/mce vůbec je, všichni pořád tlačili standardní memory testy, které samozřejmě proběhnou OK. Ale tam to hlásilo tisíce chyb edacu okamžitě po spuštění, ne jako tady. Nezbylo nic jiného, než ten edac modul v jádře vypnout a jede bez hlídání mce - nic moc.

S hledáním konkrétního dimmu - zkus mcelog, má docela pěkný výstup.

[BigWrigley]

Ad zaruka - server je v support kontraktu, takze je to jen otazka to "vykomunikovat". FW je aktualni, to je oblibeny postup, jak nejprve stiznost odpalkovat :)

Ad mcelog - koukam, ze to funguje zase jinak a neloguje do samostatneho souboru, ale jde zavolat jako klient - smarter every day

[root@ctx-aaa-be2 ~]# mcelog --client 
Memory errors
SOCKET 1 CHANNEL any DIMM any
corrected memory errors:
        35 total
        0 in 24h
uncorrected memory errors:
        0 total
        0 in 24h

SOCKET 1 CHANNEL 1 DIMM any
corrected memory errors:
        35 total
        0 in 24h
uncorrected memory errors:
        0 total
        0 in 24h
Per page corrected memory statistics:
bb310e000: total 12 seen "12 in 24h" offline triggered

bb310f000: total 2 seen "2 in 24h" online

bb3111000: total 10 seen "2 in 24h" online

bb3112000: total 5 seen "2 in 24h" online

c13111000: total 2 seen "1 in 24h" online

c13112000: total 2 seen "1 in 24h" online

Tak a ted jak z toho poznat, ktery DIMM to je?

hpasmcli> show dimm
DIMM Configuration
------------------
Processor #:                     1
Module #:                     1
Present:                      Yes
Form Factor:                  9h
Memory Type:                  DDR3(18h)
Size:                         8192 MB
Speed:                        1600 MHz
Supports Lock Step:           No
Configured for Lock Step:     No
Status:                       Ok

Processor #:                     1
Module #:                     3
Present:                      Yes
Form Factor:                  9h
Memory Type:                  DDR3(18h)
Size:                         8192 MB
Speed:                        1600 MHz
Supports Lock Step:           No
Configured for Lock Step:     No
Status:                       Ok

Processor #:                     1
Module #:                     8
Present:                      Yes
Form Factor:                  9h
Memory Type:                  DDR3(18h)
Size:                         8192 MB
Speed:                        1600 MHz
Supports Lock Step:           No
Configured for Lock Step:     No
Status:                       Ok

Processor #:                     2
Module #:                     1
Present:                      Yes
Form Factor:                  9h
Memory Type:                  DDR3(18h)
Size:                         8192 MB
Speed:                        1600 MHz
Supports Lock Step:           No
Configured for Lock Step:     No
Status:                       Ok

Processor #:                     2
Module #:                     3
Present:                      Yes
Form Factor:                  9h
Memory Type:                  DDR3(18h)
Size:                         8192 MB
Speed:                        1600 MHz
Supports Lock Step:           No
Configured for Lock Step:     No
Status:                       Ok

Processor #:                     2
Module #:                     8
Present:                      Yes
Form Factor:                  9h
Memory Type:                  DDR3(18h)
Size:                         8192 MB
Speed:                        1600 MHz
Supports Lock Step:           No
Configured for Lock Step:     No
Status:                       Ok

hpasmcli> 

Kazdopadne dekuji za nakopnuti. A.

[dustin]

Mně mcelog reportuje přímo detaily:

MCE 19
CPU 4 BANK 5
MISC 204208f886 ADDR 9ef754fc0 
TIME 1493880142 Thu May  4 08:42:22 2017
MCG status:
MCi status:
Error overflow
Corrected error
MCi_MISC register valid
MCi_ADDR register valid
MCA: MEMORY CONTROLLER RD_CHANNEL1_ERR
Transaction: Memory read error
STATUS cc02110000010091 MCGSTATUS 0
MCGCAP 1000c14 APICID 8 SOCKETID 0 
CPUID Vendor Intel Family 6 Model 45
Hardware event. This is not a software error.

[dustin]

Konkrétní dimm se poznává blbě, zkus zagooglovat pro ten typ serveru. Dimmů máš jenom pár, já jich tam měl v jednom 32 a ve druhém 64 .

[BigWrigley]

Příloha:

• dimm_location.png (35738 bytů)

Myslim, ze to mam. Existuje utilita edac-util (balik edac-utils):

[root@ctx-aaa-be2 ~]# edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc0: csrow0: 0 Uncorrected Errors
mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#0_DIMM#0: 0 Corrected Errors
mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#1_DIMM#0: 0 Corrected Errors
mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#2_DIMM#0: 0 Corrected Errors
mc1: 0 Uncorrected Errors with no DIMM info
mc1: 0 Corrected Errors with no DIMM info
mc1: csrow0: 0 Uncorrected Errors
mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#0_DIMM#0: 0 Corrected Errors
mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#1_DIMM#0: 68 Corrected Errors
mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#2_DIMM#0: 30 Corrected Errors
[root@ctx-aaa-be2 ~]#

A podle navodu k blade jsou to sloty 3B a 8C u CPU1. Jdu s tim na HP. Dam vedet, jak to dopadlo. Diky vsem.

A.

[BigWrigley]

Tak mam odpoved. Uplne mi to radost neudelalo:

These messages does not indicate a hardware failure, To ensure efficient Firmware First handling of memory failures, HPE recommends disabling EDAC. HPE also recommends disabling the correctable error detection functionality of the Linux kernel's Machine Check Event (MCE) handling. This is accomplished by setting the boot parameter "mce=ignore_ce". This boot parameter also disables logging of such events via mcelog. Details are in article http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5379860&docLocale=en_US&docId=emr_na-c04183538

1. Update BIOS to Version: 2015.06.01(1 Oct 2015) http://h20564.www2.hpe.com/hpsc/swd/public/detail?sp4ts.oid=5196168&swItemId=MTX_7de076891ced47ae8a1b6dd90f&swEnvOid=4176#tab2

2. Launch insight diagnostics, from insight diagnostics, Select quick test for memory and test all DIMMs, check for any DIMM failure.

3. Save advanced offline survey and check for any DIMM errors in SPD data as per step 4 e,f,g in link below http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=316593&docId=emr_na-c01965669&docLocale=en_US

4. Capture a new AHS log.

Prijde mi ujete, ze kvuli dvema obyc. 8GB DIMM palim tolik casu...

[dustin]

Pokud nekecají, tak to tedy nepoužívá pro reportování EDAC (proto doporučují jeho vypnutí), ale nějaké proprietární API, ze kterého to čte např. ILO - viz ten jejich popis http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c02878598 - mrkni na ty obrazovky ILO na str. 6. Zajímalo by mě, zda ve Tvém ILO ty chyby taky budou. Pokud ano, není co řešit...

[BigWrigley]

No prave ze iLO nereportuje vubec nic. Pokud to tedy chapu spravne, tak reportovani eventu EDACem je z pohledu HP zbytecne citlive a pokud ta jejich technologie konkretni DIMM neoznaci za vadny, resp. iLO nezareportuje chyby, neni duvod k vymene. Jina situace by asi byla na bezne desce s podporou ECC/EDAC, bez "HP Advanced Memory Error Detection Technology".

HP Advanced Memory Error Detection Technology Because of higher memory error frequency, some server administrators are unnecessarily shutting down servers to replace DIMMs that experience correctable errors. The best way to prevent unnecessary DIMM replacements is to filter out superfluous errors and identify critical errors that can lead to a shutdown. That‟s the goal of HP Advanced Memory Error Detection Technology.

A.

[R]

Klasicke bullshity od HP. Aby usetrili na zakaznikovi za vymenu vadnej RAM (ktora sa aj tak o mesiac vyserie uplne), tak vymyslaju "enterprise riesenia" - vlastne diagnosticke nastroje na skryvanie chyb...

[BigWrigley]

Bohuzel, take z toho nemam radost. Ale presto mi HP zelezo prijde jako velmi spolehlive a pokud platite, tak i support je vcelku obstojny.

[dustin]

No, přijde mi to tak. Když v ILO nic nemáš, tak asi HP nic nevymění.

Jenom nevím, jak číst data z ILO přímo přes OS, ale asi to nějak půjde.

[BigWrigley]

Existuji utility, ktere HP pro RHEL (ale i Debian) poskytuje:

root@ctx-aaa-be2 ~]# hpasmcli -s show

Invalid Arguments
         SHOW ASR
         SHOW BOOT
         SHOW DIMM [ SPD ]
         SHOW F1
         SHOW FANS
         SHOW HT
         SHOW IML
         SHOW IPL
         SHOW NAME
         SHOW PORTMAP
         SHOW POWERMETER
         SHOW POWERSUPPLY
         SHOW PXE
         SHOW SERIAL [ BIOS | EMBEDDED | VIRTUAL ]
         SHOW SERVER
         SHOW TEMP
         SHOW TPM
         SHOW UID
         SHOW WOL

[root@ctx-aaa-be2 ~]# 

[root@ctx-aaa-be2 ~]# hpasmcli -s show\ iml

Event: 15 Added: 04/18/2017 09:59                                                                                                                                                                                                                                               
INFO: System Revision - Firmware flashed (iLO 4 2.50).                                                                                                                                                                                                                          
                                                                                                                                                                                                                                                                                
Event: 16 Added: 04/18/2017 09:37                                                                                                                                                                                                                                               
INFO: System Revision - Firmware flashed (ProLiant System BIOS - I31 06/01/2015).                                                                                                                                                                                               

Event: 17 Added: 04/21/2017 09:17
INFO: Maintenance Note - Maintenance note: Intelligent Provisioning was loaded..

Event: 18 Added: 04/21/2017 09:21
INFO: Maintenance Note - Maintenance note: Intelligent Provisioning was loaded..

A.

[dustin]

Díky, mrknu na to.

[frr]

Se zájmem jsem si početl, děkuji za odkaz. Takže vadný DIMM, pokud má ECC, vlastně není vadný ve smyslu reklamovatelný, dokud se nezačne projevovat nestabilita OS (nebo minimálně opravy chyb nezačnou zpomalovat běh OS). V tu chvíli byste měl v dmesg už vodopád hlášek od EDACu o opravách chyb.

"To je v pohodě, dyk to běží, neee? Kam bychme přišli, kdybychme vyměňovali každej kusově vadnej DIMM !"

Z vyššího nadhledu je to asi otázka definice, co už je vadná paměť, ve zmíněné smlouvě o supportu.

To jsou věci po dvou deci. Měl jsem pocit, že EDAC je tu od toho, aby se vadné paměti pokud možno plánovitě vyměnily dřív, než způsobí neplánovaný výpadek = škodu. To je tím, že prodávám malý hardware, kde vadnou paměť je potřeba vyměnit TEČKA.

[pc2005]

Aha takže jde o to že se musíš spolehnout na jejich priprietární testy. Tak pokud svojí práci vykonaj ... ale nic moc teda :-/.

[frr]

Tu skutečnou práci s opravami chyb každopádně odvátí EDAC v hardwaru daného procesoru (v paměťovém řadiči). Rozdíl je v tom, že se na výstup EDAC nekoukáte nekompromisním vanilkovým ovladačem v linuxovém kernelu, ale skrz ILO, které z toho EDACu tahá data buď na hostitelské straně (v SMI/SMM?) nebo teoreticky možná "out of band" skrz AMT. Vtip je v tom, že HP firmware se snaží posoudit, "jak moc je ta chyba vážná" = četnost výskytu a kolik bitů v řádce, možná nějaká statistika rozprostření chyb v adresním prostoru, a na základě jakési heuristiky se rozhodne, zda chybu nahlásit, nebo admina chlácholit (resp. ponechat v nevědomosti).

Já bych si možná nechal radši podrobné informace z vanilkového ovladače. Abych si mohl udělat vlastní úsudek, nakolik je to vážné. Ochota či neochota HP s tím něco dělat je oddělený problém.

[dustin]

+1

[frr]

Uvedl jste jako příklad z dmesg jediný výskyt chyby. V tom ústřižku výpisu jsou pro mě nejzajímavější tyto řádky:

EDAC sbridge MC1: PROCESSOR 0:206d7 TIME 1493753678 SOCKET 1 APIC 25
MCE 0
CPU 26 BANK 9
MISC 90000040004088c ADDR c13111000

Podle mého identifikují poměrně přesně procesor, řadič RAM, kanál RAM a DIMM - a adresa se taky hodí. Jenom z toho výpisu není jasné mapování na fyzické popisky na plošáku motherboardu / v dokumentaci. Asi by to šlo zmapovat metodou pokus/omyl, ale spíš jako východisko z nouze. Něco by se možná dalo vykoukat z výpisu "dmidecode". Takhle kdyby se to dalo spárovat až na sériová čísla DIMMů... ale to by byla velká klika. Tohle mapování na popisky výrobce boardu je podle mého jediná/hlavní výhoda přístupu skrz doporučené GUI/API HP ILO.

Obecně chyba v RAMce podle mého neznamená nutně chybu samotného DIMMu. Mohlo by to znamenat špatný kontakt v patici nebo někde jinde po cestě, případně třeba vadnoucí elyty ve VRM. RAMka má svůj vlastní VRM, na motherboardu s více procesory teoreticky může mít každý procesor svůj vlastní VRM pro RAMku (vymejšlím si). Klika je, že tu chybu hlásí řadič paměti, tzn. blok na hraně procesorového čipu = je vcelku jistota, že to není hlouběji v procesoru nebo někde dál v systémových sběrnicích. Na charakter vady by se možná dalo usuzovat podle rozložení chyb mezi adresy / DIMMy / kanály řadiče paměti. Pokud je to dokolečka pořád stejná adresa, je to asi jasné. Pokud správně koukám, není z toho logu vidět, které konkrétní bity byly špatně... Kdyby to byl problém v napájení pamětí (teplo nebo suché elyty), asi by těch chyb bylo mnohem víc a systém by to už neustál.

[dustin]

Problém je, že mu to píše pokaždé jiné CPU i bank. Měl jsem to tak stejně.

[frr]

Jo aha... jako že v dmesg / mcelogu se to střídá, ale edac-util to hlásí věcně a správně? A pomůže vyměnit konkrétní DIMM? halucinace...

[pc2005]

První řádek OMG. Píšu, že položka CPU je procesor, který zrovna na tu adresu přistoupil (leda že kecaj v dokumentaci kernelu).

[dustin]

To je samozřejmé. Leč původní dotaz a i moje zkušenost:

Chodi to nekolikrat denne, ruzne CPU, ruzny BANK, ale zda se, ze stejny kanal radice (MEMORY CONTROLLER MS_CHANNEL1_ERR).

Vidíš tam to "ruzny BANK"?

[frr]

Jestli správně koukám, tak "BANK" je tady Machine Check Exception bank, nikoli memory bank... takže to myslím sedí.

[frr]

Jo aha. Měl bych napřed číst než napíšu

Když na to navážu: v tom .Hčku co odkazujete se říká, že CPU je "procesor, který chybu detekoval". Tady bych měl možná rozlišit, že se nám tu míchají dvě věci: specificky EDAC = detekce/korekce chyb v paměťovém řadiči, a MCE, což je obecnější framework, který umí nahlásit třeba přehřívání nebo nějaké další obecné chyby - ale zaostřeno na konkrétní CPU jádro, které tou chybou bylo stiženo. MCE je orientován na CPU jádro, EDAC na paměť = řadič paměti, což je na čipu dost samostatný blok, připojený vedle jader na vnitřní cross-connect. Tzn. ve výpisu v řádce uvedené "MCE", pokud se mluví o patici (socket), jedná se patrně o patici s postiženým jádrem, nikoli o patici s postiženým memory kontrolérem. (Je to vidět v mce.c.) A pak mi není jasné, jestli MC1 je číslo jedna v rámci CPU patice, nebo v rámci systému (motherboardu). A už jsem línej to dohledávat. Nahlédl jsem do arch/x86/kernel/cpu/mcheck/* a drivers/edac/* a moudrej z toho teda nejsem. Jdu radši dělat něco užitečného

[dustin]

Hledal jsem různě na netu a tak nějak jsem nic pořádně nenašel, jak z těch hlášek určit, který DIMM vyměnit. Předpokládám, že ten ukázkový log v ILO ("Processor 1, Memory Module 9") už ukazuje na konkrétní DIMM. V tomto ohledu by ta "nadstavba" HP měla docela přínos.

[BigWrigley]

Tak pokud by to nekoho zajimalo, problemy zcela ustaly. Pocet chyb se dale se nezvysuje. A s pametni se nakonec nijak nemanipulovalo.

[R]

Skor, ci neskor sa to vrati, napriklad pri zmene teploty.