Intels Skylake- och Kaby Lake-processorer har Hyperthreading-relaterat fel

Frågan är inte enbart om hur ofta det händer utan också om hur mycket skada det kan ställa till med när det händer.
I fall där programmet uträttar något viktigt så kan man kanske leva med om programmet krashar - för då upptäcker man det och kan starta om. Men om programmet bara levererar inkorrekta beräkningar utan att man upptäcker det så kan det ställa till saker.

AMD Ryzen har förresten en liknande bugg och jag har ännu inte sett något uttalande från AMD om det. Ganska många användare med Linux-distributioner där alla program kompileras för att installeras har varit med om att kompilatorn krashat om och om igen. En kernel-utvecklare för en BSD-distribution har lyckats reproducera felet varje gång.
Men det är svårt att hitta bra information om det i olika forum därför att folk och fä skriker på varandra om hur oviktigt det skulle vara, eller att man skulle behöva skylla sig själv eftersom plattformen är ny, anklagelser om att de som har problem skulle ha överklockat och att det egentligen skulle ha varit orsakat av överklockning. Och sen alla dessa ovidkommande kommentarer från folk som postar reflexmässigt utan att ha förstått innebörden i det/de inlägg de kommenterar eller i förnekelse över sitt nya dyra inköp etc. etc ... Man blir galen.

Nu måste jag undra... har du gjort det testet för att framkalla felet som beskrivs då? Eller har du bara kört vanliga benchmark i 24h och därför antagit att det är "good2go"?

Du kan ha fel som rättas till med ECC långt innan du får fel i program eller fel i tester. Ofta ser man dessa genom att prestandan minskas när man är på gränsen, då ECC tar lite tid, vilket stör. Risken är större att du får större fel när du redan är inne på och norpar av detta skydd på tex L2 cachen.

Problemet som jag tror @anon159643 här försöker förklara är att när man utvecklar saker och speciellt testar kod... får inget bli fel pga defekt hårdvara. Om det gör det kan du spendera timmar och 100-tals kronor på att jaga fel som inte finns, eller kompilera defekta bibliotek som kan göra att andra sedan kraschar utan förklaring.

Så att det ens finns en risk för honom att få okontrollerade och oväntade fel förstår jag är ett problem. Detta fel kan ju påverka på helt okända sätt, vilket kan vara orsaken att du kraschade i ett spel för ett tag sedan, även om du trodde det var spelet...

Sen för dig som sitter och OCar och lite skiter i om du får ett udda fel, eller ECC måste kicka in nån gång, eller tom frå BSOD 1 gång på ett år, är en helt annan miljö. Det är inte hela världen om du får ett mindre problem, och du ofta tom märker inte ens dessa fel då programkod ofta har en hel del självkorrigering i sig. Man märker detta rätt fort på ett Alpha spel tex, som saknar dessa skydd, om man har instabil CPU. Svåra är att hitta CPU felen från programmerings buggarna.

Om det är något jag dock sett mycket väl så är det folk som tror deras setup "är 100% stabil"... när den bara är 99.9%... de har bara inte lyckats hitta den 0.1% som triggar då de kör samma tester om och om igen.

Ang artikeln så är det ett litet fel, men ändå ett som behöver uppdagas då det kan påverka känsliga saker. Normalt väntar många utvecklare på att en CPU eller en generation av modekort ska bli "pålitliga" innan de hoppar på den.

De rör tex inte Ryzen än, då det är för instabilt, men med B2 så kanske det kan ändras. Av samma anledning rörde de inte Skylake i början med sina minnesfel heller, utan höll sig till Haswell som var stabil och felen fixade. Ingen CPU är felfri, och det är viktigare att felen hittas, än att man tror att det inte finns några.

Att det krävs få instruktioner i en loop för att trigga problemet pekar på att en förutsättning är att instruktionerna kommer från mikro-op cachen alt. andra "front-end" optimeringar för korta loopar. Korta loopar är väldigt vanligt förekommande.

Att båda trådar är aktiva i en fysisk kärna är inte heller speciellt osannolikt om man jobbar med batch-jobb som t.ex. beräkningar, kompilering eller liknande.

Det som gör fallet väldigt osannolikt är sista kravet: programmet måste inom de 64 instruktionerna använda ett specifikt x86 register både genom EAX/RAX (32-bitar eller 64-bitar) och genom AL (de höga 8-bitarna av de lägsta 16-bitarna).

Som redan nämnts bör ingen kompilator eller assemblerhackare skapa sådan kod då det är en dålig idé ur prestandasynpunkt på alla Intel CPU modeller sedan PentiumPro och alla AMD modeller sedan ursprungliga Athlon. För det vetgirige, läs om "partial register access" här.

I OCaml fallet (OCaml är ett programspråk) verkan man tvingat gcc att genera sådan kod (antagligen helt omedvetet) genom att lägga restriktioner som normalt inte finns på kodgenereringen.

"There were extra constraints being placed on gcc by OCaml, which would explain why gcc apparently rarely generates this pattern."

Som nämns flera gånger så har alla moderna CPUer buggar. Tyvärr är x86 långa historia en kvarnsten här då dessa har fler gropar man kan kliva i och de tar därmed lägre tid att validera. Just den här buggen är inte ens tekniskt möjlig på t.ex. ARM, det är ett resultat av något som var en god idé på 80-talet när 8086 var aktuell men som ingen skulle stoppa in i en modern CPU-design.

Gissar att fixen i detta fall blir att man på något sätt identifierar fall register där ah/bh/ch/dh läses/skrives nära läsning/skrivning av eax/ebx/ecx/edx/rax/rbx/ecx/edx (problemet är alltså access av samma register, men olika delmängder av registret). Ser man ett sådant fall gör man nog helt sonika någon form av fördröjning mellan dessa instruktioner. D.v.s. slutresultatet är att sådan kod antagligen kommer köras långsammare, ett icke-problem då det redan är väldigt ineffektivt och därför bör undvikas på alla x86-modeller nyare än ~15 år.

Gissar att de flesta CPU-buggar löses på ett sätt som gör att sekvensen som triggar problemet kommer köras långsammare. Detta blir ett problem först om/när man hittar ett fel i fall som ofta inträffar i vanligt förekommande kod. Sådana fall är som tur är ovanliga, ett sådan fel visar sig normalt under testning och i värsta fall kort efter att produkten når marknaden.