Intel fikst bug die Skylake-chip laat vastlopen bij berekening priemgetallen

Intel geeft toe dat er een bug zit in zijn Skylake-processors die ervoor kan zorgen dat de processor vastloopt. Het bedrijf wil een bios-update uitbrengen die het probleem verhelpt. Het probleem komt alleen voor bij het berekenen van bepaalde priemgetallen.

Intel heeft in een reactie op zijn forum bekendgemaakt dat ze op de hoogte zijn van de bug en dat er al een oplossing klaar ligt. Het bedrijf is bezig om deze oplossing uit te leveren aan de makers van moederborden. Deze kunnen dan via een bios-update de oplossing naar alle gebruikers van Skylake-processoren brengen. Vooralsnog raadt Intel gebruikers aan om contact op te nemen met de leveranciers van de moederborden als een systeem getroffen is door de bug.

De bug is ontdekt door gebruikers van Prime95, een programma ontwikkeld door de Mersenne Research-groep. Het programma wordt gebruikt om nieuwe mersennepriemgetallen te vinden. Mersennepriemgetallen worden gebruikt voor onder andere random number generators en in cryptografie. De bug komt voor als Prime95 wordt gebruikt om het nummer 14942209 te testen. Onder de druk loopt het computersysteem vanzelf vast. Het is mogelijk dat de bug ook in andere situaties kan voorkomen, maar alleen de Prime95-methode wist het herhaaldelijk te tonen. Met de bios-update moet het probleem worden verholpen.

Reacties (100)

Gaat het hier nu om een fout in de hardware zelf? Of om een fout in de software (BIOS)?

Maw, de fix gaat de hardwarematige fout softwarematig opvangen? Of....?

Het staat inderdaad niet duidelijk in de tekst, maar er zit een bug in de Skylake-architectuur. Zie ook de bronvermeldingen (https://communities.intel...%2Fv3%2Fcontents%2F524553), daarin staat namelijk letterlijk het volgende: "Since this bug is reproducible and has been confirmed on motherboards of many different suppliers and with RAM modules of different suppliers the bug seems to be tied to the processor architecture".

De moederbord fabrikanten dienen een oplossing aan te dragen. Verander je vervolgens van moederbord, dan kan je systeem weer vastlopen.

In de onderstaande link staat ook nog interessant leesvoer.
http://mersenneforum.org/showthread.php?t=20714

[Reactie gewijzigd door Beunhaas91 op 11 januari 2016 10:55]

Het zal verholpen worden met een micro-code update. Dit is een stukje code dat door de BIOS in de processor geladen word bij booten. Je zou het een beetje kunnen zien als een stukje firmware van je processor.

Als je niet terugdeinst van het idee je eigen BIOS-mod uit te voeren, en je moederbord heeft een UEFI BIOS, dan kan je met deze handige guide ook zelf een microcode update installeren. Zelf onlangs gedaan voor mijn ASUS Sabertooth Z77 (een ouder model), werkte eenvoudig en perfect. Om te flashen moest ik wel de noodflashprocedure gebruiken (speciale USB-poort), maar dat werkte goed.

Een microcode update hoeft niet zo moeilijk, dit kan ook gewoon door het OS worden uitgevoerd. In ieder geval kan dat met Linux.

Ik draai zelf Windows 10. Microsoft heeft niet al te lang geleden wel een update uitgebracht die een wat nieuwere microcode bevat, maar je kan het in Windows niet met de hand aanpassen voor zover ik weet. Nu mijn BIOS een nieuwere versie ingebouwd heeft wordt deze door Windows gewoon gebruikt.

Over NT gebaseerde Windows zou ik het ook niet durven te zeggen. Ik weet wel dat er in de 9x tijd een mogelijkheid was via een DOS driver de microcode in te laden voordat Windows 9x opstartte.

Wat heb je aangepast op je Asus Sabertooth Z77? En waarom heb je dat gedaan?

Ik heb de nieuwste MEI firmware erop gezet (dat hoefde niet via de BIOS, maar kan ook geen kwaad) en de nieuwste microcode. Voor overclocken schijnt een oudere versie aangeraden te zijn, maar ik ben meer geïnteresseerd in de errata (hoe zeldzaam ze ook mogen zijn). Of ik het verschil zal merken, dat is natuurlijk wel de vraag.

[Reactie gewijzigd door Mitsuko op 12 januari 2016 01:56]

Het zal verholpen worden met een micro-code update. Dit is een stukje code dat door de BIOS in de processor geladen word bij booten. Je zou het een beetje kunnen zien als een stukje firmware van je processor.

Je kan microcode updates ook laden vanuit het OS, bijvoorbeeld in Linux. Zo ben je niet afhankelijk van een update voor je BIOS.

Het is alles behalve een "firmware" van je processor. Als de BIOS dan zegt voer uit y bij opdracht x, dan heeft dat niets met de processor te maken.

Sterker nog, de bug zit dus nog steeds in de processor.

[Reactie gewijzigd door Beunhaas91 op 11 januari 2016 11:03]

Je begrijpt me verkeerd. De BIOS laad een stukje microcode (alle biossen hebben die aan boord, afkomstig van Intel , afgestemd op specifieke processoren) in de processor.

Deze microcode (niet de BIOS) kun je zien als een soort firmware van je processor.

https://wiki.debian.org/Microcode

[Reactie gewijzigd door gjmi op 11 januari 2016 11:06]

Wordt deze microcode bij elke boot opnieuw geladen (dwz, begint de CPU "clean") of is dit een firmwareupdate waarbij gekeken wordt of de huidige versie al in de CPU zit? Waarna er geen flash zal plaatsvinden?

_{Typo's gefikst}

[Reactie gewijzigd door ThaStealth op 11 januari 2016 13:38]

Elke boot opnieuw toegepast

Micro codes worden altijd elke keer opnieuw geladen, intel cpu's hebben alleen vluchtige(volatile) geheugen in de chip. En dat is maar goed ook mocht er verkeerde code geladen worden is je dure cpu niet ineens stuk, reboot en kan weer nieuwe kans wagen.

Dat is quatsch. De BIOS stuurt de processor niet aan, hij zal hem hoogstens een reset signaal geven. De processor laadt de instructies zelf uit het geheugen en voert deze uit.

Niet alles in de CPU is echter hardwired in hardware, ook in de processor zelf zijn dingen uitgevoerd in software. Deze microcode kan worden geüpdatet, en zal door het BIOS tijdens het booten worden ingeladen.

Dus eigenlijk gewoon een excuus om de micro-code te veranderen, zodat overklokken niet meer mogelijk is

Deze 'bug' zal inderdaad ook worden gefixt denk ik.

In het kort: Cpu's hebben heel veel bugs, elke cpu tot nu toe had honderd plus bugs, meeste zullen niet eens aangepakt worden, die verstoren de werking niet of nauwelijks. Dat was vroeger een probleem, kon je de chip weggooien als de bug wel de werking ernstig verstoorde, tegenwoordig kunnen ze de chip met micro codes achteraf nog aanpassen op hardware niveau, zoals herschikken van hardware onderdelen, uitschakelen, etc.

[Reactie gewijzigd door mad_max234 op 11 januari 2016 19:30]

Nu doe je alsof microcode nieuw is, maar microcode wordt al een jaar of 30 tot 40 gebruikt.

Microcode is ook helemaal geen aanpassing op hardware-nivo. Het is letterlijk code, software. Herschikken en uitschakelen van hardwareonderdelen gebeurt met een laser en speciale fuses die doorgebrand worden.

Microcode wordt vooral gebruikt voor complexe instructies. Sinds de Pentium Pro is de interne instructie-set losgekoppeld van de historische x86 instructies, en worden de x86 instructies dus vertaald. Sommige van die x86 instructies starten nu een micro-code programmatje op.

Microcode kan ook gebruikt worden om zeldzame situaties op te lossen. Geheugen wordt in 4 kB blokken gemanaged, en meestal met meer dan 1 byte tegelijk gelezen. Wat nu als je 4 bytes leest, waarvan 2 bytes in RAM staan en 2 bytes op harddisk? Dat is extreem zeldzaam, dat los je niet in hardware op maar met microcode.

Ik heb gister toevallig een nieuwe Pentium G4400T, een Skylake dus, lopen testen met de mprime torture test. Heeft 14 uur gelopen zonder fouten. Geen idee of deze specifieke situatie daarin ook voorkomt maar ben hem in ieder geval niet tegen gekomen.

Het gaat niet om priemgetallen, maar om een specifieke samenloop van omstandigheden die voorkomt bij:

- Skylake
- Hyperthreading
- CpuSupportFMA3=0

Deze combinatie wordt getriggerd door het programma Prime95(dus niet jouw mprime) bij het bewuste priemgetal.

Deze combinatie wordt getriggerd door het programma Prime95(dus niet jouw mprime) bij het bewuste priemgetal.

Mprime ís Prime95. Prime95 is de Windows-versie, op Linux heet die mprime, maar de algoritmes zijn hetzelfde. Dat zal het verschil niet maken. Maar de door jou genoemde hyperthreading ontbreekt bijvoorbeeld op mijn processor, dat lijkt me een aannemelijkere verklaring.

Tja, dat zegt dus helemaal niets. Je test het op een andere manier.

Als je eens probeert wat in het artikel staat:
"Als Prime95 wordt gebruikt om het nummer 14942209 te testen dan loopt het computersysteem vanzelf vast. "

Ja, en de torture test houdt in het testen van priemgetallen. Bij een FFT met een lengte van 768K zou het fout moeten gaan. Die zou best voorbij kunnen komen in zo'n test. Maar wat .oisyn hier haanhaalt: .oisyn in 'nieuws: Intel fikst bug die Skylake-chip laat vastlopen bij berekening priemgetallen' suggereert dat het alleen om de 6th Gen Intel® Core™ family of product gaat, en ik heb een Skylake Pentium, die dus niet bij de Core family hoort. Mogelijk dat die sowieso buiten schot blijft.

Ja, maar komt excact dit getal voorbij? Je bent zelf niet zeker, zelfs nu heb je het over "zou moeten" en "mogelijk" dus als je één commando uitvoert, waarvan vast staat dat het de bug triggered, weet je het zeker.

Wow, Pentium 60 tijden herleven Goed dat ze het erkennen en dat het gewoon met een BIOS / EFI update te verhelpen is.

Je fixt het dan waarschijnlijk op DAT bord, niet voor de CPU. Als je die ooit meeneemt naar een ander bord moet deze ook wel geupdate zijn lijkt me?

Ja, de bios laad een microcode in de processor. Deze microcode word bij iedere boot in de processor geladen. Dus met een ander moederbord waarvan de bios niet deze fix heeft zal de bug weer optreden.

Als je die ooit meeneemt naar een ander bord moet deze ook wel geupdate zijn lijkt me?

Je suggereert dat het vooraf moet maar dat hoeft dus niet, zolang jij geen priemgetallen gaat uitrekenen heb je die update ook niet nodig.

Nonsens. Het feit dat Prime95 toevallig de bug triggert impliceert niet dat alléén Prime95 de bug triggert. Er is niets speciaals aan priemgetallen, het gaat gewoon om de specifieke omstandigheden die door de programmacode optreden. De bug is wellicht zeldzaam en daarom zul je over het algemeen prima de CPU kunnen gebruiken zonder de update, maar zeggen dat je goed zit zolang je geen priemgetallen uitrekent is gewoonweg onwaar.

[Reactie gewijzigd door .oisyn op 11 januari 2016 11:07]

Misschien heb ik mij niet helemaal juist verwoord, maar bedoel me meer dat het dus niet uit maakt dat je vooraf die update al hebt (zoals zijn opmerking imho suggereert).

De update kan je gewoon downloaden en draaien zeg maar

Dat is inderdaad waar, zonder de update lijkt de processor in ieder geval prima in staat de meeste hedendaagse software te draaien, inclusief de benodigde bios update zelf

Er is niets speciaals aan priemgetallen

Zeg dat maar niet tegen een getaltheoreticus!

Maar het artikel doet inderdaad wel overkomen of er iets magisch is aan priemgetallen die deze processor laten crashen. Heel vreemd omdat er natuurlijk een groot aantal algoritmes te bedenken is dat test of iets een priemgetal is en de meeste daarvan zullen niet crashen.

Dat is niet helemaal waar. Dit scenario triggered de bug, maar dat wil niet zeggen dat het niet ook anders getriggered kan worden.

Klopt.

Ik denk dat de gemiddelde consument hier in ieder geval niet veel last van zal hebben.

Dat klopt, inderdaad. Het komt alleen voor tijdens het uitvoeren van vrij specifieke opdrachten, zoals de berekening van deze priemgetallen met Prime95. Zie ook de bronvermelding (https://communities.intel...%2Fv3%2Fcontents%2F524553): This issue only occurs under certain complex workload conditions, like those that may be encountered when running applications like Prime95. In those cases, the processor may hang or cause unpredictable system behavior.

Dat bedoel ik inderdaad. Lijkt me sterk dat tijdens een potje gamen of druk je brief typen in Word plots deze of een vergelijkbare instructie voorbij komt zeilen, hoewel het nooit uitgesloten is uiteraard...

Het gaat niet om een specifiek instructie, maar om een complexe samenloop van omstandigheden. Het is niet gezegd dat die in een game bijvoorbeeld nooit voor kunnen komen.

Bij dat potje gamen lijkt het me wel waarschijnlijker dan in word.

Waarschijnlijk dat bij een volgende stepping, deze bug eruit wordt gehaald.

20 jaar geleden is dit ook al gebeurd ,
bij een pentium processor

http://www.techradar.com/...t-shook-the-world-1270773

was het eerste waar ik aan moest denken als ik het bericht las
het 2 de waar ik aan moest denken was :wordt ik nu echt zo oud dat dit alweer 20 jaar geleden is

EDIT: dit is misschien een viering :we maken nog is een cpu met een bug dat is nu al 20 jaar sinds we dat nog gedaan hebben

[Reactie gewijzigd door laserdesign op 11 januari 2016 19:35]

Als ze die ooit weten te vinden.

Als ze al een fix klaar hebben, denk je dan niet dat ze 'm al gevonden hebben?

Het probleem komt alleen voor bij het berekenen van bepaalde priemgetallen.

Natuurlijk klopt dit niet. Er zit kennelijk een bug in de cpu architectuur van Skylake. Die bug komt aan het licht als met Prime95 het priemgetal 14942209 wordt uitgerekend. En hij zal op nog een heleboel manieren aan het licht kunnen komen, het is niet dat Prime95 als enige in de wereld een bepaalde assembly instructie gebruikt. Alleen is het met Prime95 voor het eerst gelukt om deze bug betrouwbaar te kunnen reproduceren.

Natuurlijk klopt dit niet.

Je vergeet even dat er eigenlijk niemand in assembly werkt (x86-64) op een paar 'vakidioten' na. Daarnaast maakt Intel een van de meest gebruikte compilers. Het zou dus heel goed kunnen zijn dat die compiler deze bug 100% zeker nooit zal produceren. Een processor is geen 'simpel rekenmachientje', het is een keten. Waarbij een compiler bijvoorbeeld ook al zaken 'goed' zet voor een branch predictor en rekening houdt met de specifieke implementatie en/of microcode in de CPU. Daarmee kan Prime95 dus inderdaad echt het enige programma ooit zijn die hier last van heeft.

Volgens de mensen van Prime95 treedt het probleem op bij:
- Skylake en
- hyperthreading en
- het gebruik van bepaalde instructies uit de FMA3 instructieset. Die overigens al een tijdje bestaat.

Het zou natuurlijk kunnen dat de Intel compiler die FMA3 instructies op een andere manier gebruikt dan in de handgeschreven code van Prime95. En dat de net zo populaire GCC compiler het ook op de Intel manier doet. En dat alle andere handgeschreven assembly (wordt meer gedaan dan je denkt, niet alleen door 'vakidioten') het toevallig ook op de 'correcte' manier doet. Dus in dat geval heb je gelijk, dan is Prime95 inderdaad het enige programma dat hier last van heeft.

Maar zelfs dan is het op zijn zachtst gezegd misleidend om in het artikel te zeggen dat het probleem 'alleen voorkomt bij het berekenen van bepaalde priemgetallen'. Intel processors hebben geen weet van priemgetallen, het is een bepaalde FMA3 instructie die in een bepaalde context een bug vertoont.

Natuurlijk geeft ze dit ook mooi de kans om de OC mogelijkheden van non-K processors weer de nek om te draaien.

Schoot bij mij ook meteen door het hoofd

Een update als deze, die toch wel vrij handig is voor eindgebruikers, kan natuurlijk fijn gebruikt worden om wat ander ongewenst gedrag de nek om te draaien.

Ach ja, het was een unsupported feature, en het zou niet de eerste keer zijn dat Intel zo'n loophole dicht gooit, iedereen die hierdoor getroffen wordt had het kunnen zien aankomen

Ik ben bij Haswell blijven steken, wie zou dit kunnen testen voor zijn/haar mede-Tweakers?

Vreemde fout als het slechts heel specifiek voorkomt.

Doet me denken aan de problemen bij floating-point berekeningen bij de introductie van de nieuwe Pentium. Die leverden verkeerde waarden op. Link

Wat ik mij afvraag, heeft deze fix geen negatieve performance effect?

Ik ga een beetje paranoïde spelen, maar ik vind het wel heel toevallig dat er nu een zeer zeldzame bug ontdekt word waardoor de microcode van de CPU in de BIOS geupdate moet worden.

Net nu moederbord fabrikanten overklokken met de normale chipset en non-K CPU's mogelijk hebben gemaakt, waar deze update zeer waarschijnlijk "toevallig" ook iets voor ingebouwd heeft zodat dat niet meer mogelijk is. Maar ja, zonder update kan je computer crashen, dus toch maar doen?

Het kan natuurlijk puur toeval zijn, maar ergens denk ik van niet. Ik ben benieuwd waar de fabrikanten mee komen!