Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Debian Project: zet hyperthreading bij Skylake- en Kaby Lake-chips uit

Door , 96 reacties, submitter: iTeV

Ontwikkelaars van Debian adviseren hyperthreading te deactiveren bij processors van Intels Skylake- en Kaby Lake-generatie. De eigenschap van de chips kan onder omstandigheden voor problemen zorgen. Het defect zou in combinatie met alle besturingssystemen kunnen optreden.

Gebruikers van systemen met Intel Kaby Lake- of Skylake-processors dienen onmiddellijk hyperthreading uit te schakelen in het bios of uefi, waarschuwt ontwikkelaar Henrique de Moraes Holschuh van Debian Project. Voor Debian 8 en Debian 9 is een microcode-update beschikbaar, maar deze is alleen voor Intel Skylake-processors. Intel heeft wel een microcode-update voor Kaby Lake gereed, maar die is alleen beschikbaar voor systeembouwers, waardoor gebruikers moeten wachten op een bios- of uefi-update.

Het defect van hyperthreading kan zorgen voor compiler- en applicatiecrashes, onverwacht gedrag van programma's en incorrecte output van software. Een ontwikkelaar van OCaml waarschuwde het Debian-team eind mei dat de OCaml-gemeenschap begin dit jaar ontdekt had dat de compiler het hyperthreadingdefect kon activeren. De eerste problemen dateren al van het tweede kwartaal van 2016. Niet bekend is welke software naast OCaml het defect kan triggeren.

Het OCaml-team lichtte Intel in, maar hoorde vervolgens niets van het chipbedrijf. Onlangs bleek Intel toch het probleem verholpen te hebben met microcode-updates, zonder dat de chipgigant OCaml daarover berichtte. Intel meldt in de KBL095-notificatie dat het probleem alleen onder 'complexe micro-architecturale condities' speelt. Het bedrijf spreekt van korte loops van minder dan 64 instructies die voor onverwacht systeemgedrag kunnen zorgen als beide logische cores op dezelfde fysieke processor actief zijn.

Olaf van Miltenburg

Nieuwscoördinator

26 juni 2017 08:20

96 reacties

Submitter: iTeV

Linkedin Google+

Reacties (96)

Wijzig sortering
Short loops which use ah/bh/ch/dh registers may cause unpredictable system behavior.
Het klinkt bijna alsof gebruik van een repeat instructie met een 8-bit register icm. Hyperthreading fout gaat. Vergis je niet, dergelijke repeats worden best veel gebruikt. Nasty...

Het is jammer dat Intel hier niet bepaald lekker over communiceert: als je CPU bepaalde dingen niet goed doet, is het ook gewoon een optie om de compiler hier rekening mee te laten houden. Dat is voor iedereen ultimo beter.

Overigens heb ik even de lijst doorgelopen en vond ik bug met ID KBL096 ook niet erg lekker klinken:

[quote]
CPUID TLB Associativity Information is Inaccurate
[/quote]

(Voor mensen die niet weten wat een TLB is, hier is de link)

[Reactie gewijzigd door atlaste op 26 juni 2017 10:11]

Overigens heb ik even de lijst doorgelopen en vond ik bug met ID KBL096 ook niet erg lekker klinken:

CPUID TLB Associativity Information is Inaccurate

(Voor mensen die niet weten wat een TLB is, hier is de link)
Nee dat lijkt mij absoluut geen (groot) probleem. Je TLB is een associatieve cache van geheugen translaties; als de CPUID instructie nou bijvoorbeeld de verkeerde informatie terug geeft dat de TLB 2-way associative is en werkelijk 4-way associative blijkt te zijn, dan is er nog geen man overboord. Dit zal je hooguit een performance hit kunnen opleveren mocht je zeer geavanceerde software gebruiken die zijn adres-layout afstemt op de associativiteit van de TLB (om daarmee de TLB maximaal te kunnen benutten). Je zou dan wat meer hardware tablewalks krijgen om je TLB te vullen, maar je moet wel hele exotische dingen doen wil je dat meer dan enkele procenten aan performance laten verliezen.
Hmm. Point taken, eens.
vond ik bug met ID KBL096 ook niet erg lekker klinken:
CPUID... hoeft dus geen probleem met de TLB zelf te zijn.

Volgens mij heeft elke moderne CPU een hele lijst met errata, is niks nieuws.
Is het ook gewoon een optie om de compiler hier rekening mee te laten houden. Dat is voor iedereen ultimo beter.
Want?
Mogelijk is het alternatief minder snel en waarom zouden mensen met andere CPUs die prijs moeten betalen?

[Reactie gewijzigd door Olaf van der Spek op 26 juni 2017 09:19]

Volgens mij heeft elke moderne CPU een hele lijst met errata, is niks nieuws.
Absoluut! Net zoals software is hardware ook eigenlijk nooit bug-vrij. Er wordt wel heel erg intensief getest, maar er zijn altijd kleine dingen of hele gekke extreme scenarios met gek gedrag die er doorheen kunnen glippen. Er zijn ook vaak dingen die tijdens het testen gevonden worden en dan als niet kritiek bestempeld worden, voornamelijk als ze hooguit een performance impact hebben en geen functionele problemen opleveren; als ze te laat gevonden worden en je kan er omheen werken of ze zijn niet kritiek, dan ga je niet weer een hele (kostbare) design spin doen. Er zijn ook altijd standaard een stel verborgen configuratie registers met zogeheten "chicken switches" voor allerlei features. Mocht er dan tijdens het testen iets niet goed blijken te werken, dan kan besloten worden om die feature standaard uit te zetten in het uiteindelijke product. David Kaplan van AMD heeft daar eens een goed praatje over gegeven waarvan ik kan bevestigen dat het een goed overzicht geeft van hoe het er aan toe gaat in deze industrie.

Overigens lijkt er hier wel iets ingewikkelders aan de hand te zijn wat wel functionele gevolgen heeft; aan de hand van de omschrijving lijkt het alsof er een bepaalde manier van corrruptie van waardes kan plaatsvinden in de registers onder omstandigheden (waarschijnlijk een bepaalde scheduling van uops) die alleen kunnen plaatsvinden als er twee threads in de core actief zijn. Zoals Intel aangeeft:
Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active.
Dus waarschijnlijk heeft het te maken met een register-aliasing probleem, omdat je in x86 bepaalde (sub) registers op andere manieren kan aanspreken. Dit soort eigenschappen maakt het vinden van dependencies tussen de registers in de processor's Rename stage enorm ingewikkeld, dus het verbaast mij niets dat er hier een foutje in is geslopen. Een microcode oplossing zou kunnen bestaan uit het toevoegen van een impliciete synchronisatie in een van de getroffen instructies, waardoor er gegarandeerd is dat alle oudere updates naar die registers al klaar zijn voordat deze instructie uitgevoerd wordt.
Wordt er de laatste tijd wel kriebelig van. Eerst het gesodemieter met Intel Avoton (kon mijn mooie firewall de kliko in :'( ), nu dit weer. Tsjongejongejonge.... (enz.)
De kliko in? Je kan onder Nederlandse garantie gewoon een nieuwe / gereviseerde versie zien te krijgen lijkt mij. Ik heb er inmiddels 2 buiten de garantie vervangen. Direct bij de fabrikant in 1 geval en bij de verkoper (alternate) in het andere geval.
Ik weet niet waar je op doelt, gezien een avoton cpu onboard zit. Wellicht dat je je moederbordje hebt kunnen vervangen. Die van mij zat in een kerio ng300 firewall. Begint bij het feit dat kerio totaal niet reageert op het verhaal, niet via email en niet via facebook. Je wordt dommig weggezet "dank voor de melding, we geven het door", en je kunt letterlijk in de str*nt zakken. Heb ik ze nog niet eens verteld dat ik mijn ng300 niet nieuw gekocht had (hoewel hij in nieuwstaat verkeerde). Echt een heel fijn bedrijf, dat kerio :'( .
Ja ik heb inderdaad in beide gevallen heel het bord (asrock rack) buiten de garantie vervangen gekregen. Hoefde er niet eens moeilijk over te doen, gewoon ticket aangemaakt en het werd geregeld. Neem aan dat Intel voor de schade bij ASRock opdraait.
Net zoals software is hardware ook eigenlijk nooit bug-vrij.
En eigenlijk is de hardware ook deels sowtware geworden. Microcode verzorgt het uitvoeren van de eigenlijke hardware microinstructies en vormt dus een softwarelaag tussen instuctieset en de eigenlijke hardware.
Dus waarschijnlijk heeft het te maken met een register-aliasing probleem, omdat je in x86 bepaalde (sub) registers op andere manieren kan aanspreken.
Dit gaat dan wel om x64 en niet x86... :)
[...]
Het is jammer dat Intel hier niet bepaald lekker over communiceert: als je CPU bepaalde dingen niet goed doet, is het ook gewoon een optie om de compiler hier rekening mee te laten houden. Dat is voor iedereen ultimo beter.
Dat is ook zo maar dat betekent dat iedereen zijn compilers moet aanpassen en software moet hercompileren, dat kost nou eenmaal tijd.

Hetzelfde zag je met de oude Pentiums die de beruchte FDIV bug hadden, uiteindelijk was dat wel opgelost in de compilers, maar daarvoor zijn er wel processoren zelfs teruggeroepen.
Dat is ook zo maar dat betekent dat iedereen zijn compilers moet aanpassen en software moet hercompileren, dat kost nou eenmaal tijd.
Sinds de FDIV bug is er wel een heleboel gebeurd in compiler land... compilers optimaliseren tegenwoordig normaliter op SSA form, die ze vervolgens omzetten in machine SSA en daarna via bepaalde tabellen converteren naar assembler. Het aantal assembler dialecten is ook sterk toegenomen, o.a. door CPU feature flags, die meegenomen worden in machine code generatie.

In LLVM weet ik inmiddels hoe je een dergelijk probleem oplost... (Ik ben een keer een Skylake bug tegengekomen in LLVM die de verkeerde instructies genereerde, waar ik dagen op heb zitten zoeken). Het valt wel mee hoe veel werk het is om dergelijke aanpassingen te maken in de codegen als je eenmaal weet waar de fout zit; dit is nog geen uurtje werk. De impact van dat alles is minimaal omdat bepaalde instructies dan simpelweg niet meer gegenereerd worden (irt. testen/uitrollen/etc is dat relevant).

De grootste tijd zit in hercompilatie van alle software...

Ik geef uiteraard meteen toe dat dit niet ideaal is; het is natuurlijk veel beter om de bug te fixen (in microcode). En hoe dan ook begint het met afstemming en communicatie, zodat je beiden weet waar je aan toe bent. Wellicht waren ze bij Debian al begonnen met een dergelijke workaround proberen - als Intel immers niet zegt dat ze er mee bezig zijn / het gefixt hebben, wil je als Debian toch gewoon proberen het euvel op te lossen voor je klanten.

[Reactie gewijzigd door atlaste op 26 juni 2017 10:01]

Het is wel gecompliceerder dan dat omdat zowel 8-bit en gebruik van het corresponderende 32(/64?)-bit register nodig, en nog eens hyperthreading.

Er gaat waarschijnlijk iets fout in de administratie van registers, een ah vs r/eax conflict wordt geregistereerd en de retiring maakt er een zootje van.

Mogelijk is de repeat alleen een factor om de kans te verhogen dat het voorkomt.

Merk ook op dat het met een OCaml compiler is opgemerkt, niet LLVM of GCC. Die gebruiken niet zoveel 8-bit registers.
Die update voor Debian werkt inderdaad goed: Ik heb twee Proxmox VE *) / Ceph nodes met een Core i3-6100T (model 94, stepping 3). Na het enablen van de non-free packages, het installeren van package intel-microcode, en rebooten, geeft het kernel log (dmesg) aan dat e.e.a. gefixed is:

[ 0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
[ 0.000000] Linux version 4.10.15-1-pve (root@stretchbuild) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP PVE 4.10.15-12 (Mon, 12 Jun 2017 11:18:07 +0200) ()
...
[ 0.093802] smpboot: CPU0: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz (family: 0x6, model: 0x5e, stepping: 0x3
...
[ 1.275300] microcode: sig=0x506e3, pf=0x2, revision=0xba
[ 1.282128] microcode: Microcode Update Driver: v2.2.

Die update 0xba, met signature 0x506e3 is de fix.

*) Edit: Proxmox VE is een Debian-gebaseerde distributie met extra packages die er out-of-the-box een multi-master virtualisatieomgeving met webinterface, Ceph, etc. van maken.

[Reactie gewijzigd door nhbergboer op 26 juni 2017 09:29]

Maar een grotere vraag, had je problemen met je systeem voordat dit gefixt was?
Dat is natuurlijk een goede vraag. Als ik eerlijk ben dan is het antwoord: "dat weet ik niet". Anders gezegd: geen enorme problemen met de stabiliteit (dat had ik wel gemerkt), maar of er niet hier en daar kleinere dingen fout zijn gegaan; dat weet ik niet.

Het is beter om de fix toch maar te installeren.
(sorry, verkeerd gezien).

[Reactie gewijzigd door jj71 op 26 juni 2017 13:01]

Ik heb twee Intel NUCs met een Core i5-6260U (dat is een Skylake processor). Ik zie dat Intel op 24 mei een BIOS update heeft uitgebracht voor dit model, maar helaas is het onduidelijk of ze daarmee dit probleem hebben opgelost, de release notes zijn erg summier en ik zie er geen verwijzing in staan naar dit probleem.

Ik gebruik één van die NUCs al meer dan een jaar elke dag om op te werken en heb nog niets gemerkt van onstabiliteit of rare crashes.

Is er een manier om te zien of de juiste microcode in je processor zit?

Edit: De post van Debian noemt het commando: iucode_tool -S
waarmee je een signature van je processor / microcode kunt opvragen (als je Debian draait natuurlijk; zo te merken werkt het ook op Ubuntu).

De mijne heeft signature 0x000406e3, wat blijkbaar inderdaad één van de modellen is waar de bug in zit... :/

[Reactie gewijzigd door jj71 op 26 juni 2017 08:44]

Aha, zojuist het volgende gevonden:

https://communities.intel.com/thread/115796

Er zijn dus nieuwe BIOS versies beschikbaar voor NUCs die het probleem oplossen.
Ik begrijp het verhaal niet helemaal maar het is toch erg dat je hyperthreading moet uitschakelen terwijl de CPU hiermee wel word gepromoot. En dit is voor normale consumenten ook van toepassing?
Ik ga ervan uit dat Intel dat niet met opzet heeft gedaan. Intel kan dit gewoon makkelijk oplossen door nieuwe microcode naar de hardwarefabrikanten te sturen. Die moeten op hun beurt weer hun bios updaten.
Maar mensen die nog nooit van een bios update hebben gehoord maar wel een Skylake hebben. Hoe lossen die groep mensen dat op? Die zitten dan lekker voor een tijdje met een half gebakken CPU zonder hyperthreading. :?
Ik denk dat als mensen niet weten hoe ze een bios update moeten uitvoeren, dat ze waarschijnlijk ook niet zullen weten hoe je hyperthreading uit kan zetten in de bios.
Als zij problemen ondervinden sturen ze waarschijnlijk de gehele computer terug naar de media markt omdat deze niet goed meer werkt. Waar media markt weer een dikke rekening voor teruggeeft alleen maar voor een bios update.
Waar media markt weer een dikke rekening voor teruggeeft alleen maar voor een bios update.
Altijd leuk, bedrijven bashen. Maar een computer in ontvangst nemen, transporteren naar een geschikte werkplek, uitpakken, aansluiten op de nodige randapparatuur, diagnose van het probleem, updaten van het moederbord, update valideren, afsluiten, ontkoppelen, inpakken, terugtransporteren, klant inlichten, tijdelijke opslag en uiteindelijk overhandigen aan de klant kost gewoon iets meer tijd en geld dan jij suggereert met "een bios update". Ik ga niet garanderen dat ik het in een halfuurtje geregeld zou hebben, en volgens mij is EUR 75/uur geen vreemd bedrag voor aan manuur in een (groot) bedrijf. De vraag is wat mij betreft dan ook niet: "is het bedrag te hoog" maar "zou dit onder garantie moeten vallen?".
Ja garantie, betreft een produktiefout.
Ik ben het met je eens dat het een productiefout (of ontwerpfout) is en de fabrikant het op moet lossen. Maar dat kan intel toch doen door een update beschikbaar te stellen? Is het toepassen van die update ook een taak van de leverancier? Zo ja, wat nou als iemand te incapabel is om Windows Update te draaien (toegeven: het kost meer moeite om updates niet te installeren, maar dat terzijde)? Is de leverancier dan verplicht iedere keer voor jou die handelingen uit te voeren als je met je computer bij de balie staat?
De leverancier mag op zijn beurt kosten verhalen bij Intel. Dat is aan de verkoper. Net zoals de verkoper zijn assortiment kan kiezen, wat opnieuw het grote belang van gezonde concurrentie onderstreept. Concurrentie maakt dat Intel gedwongen is dit netjes op te lossen.

Dus het is niet 'leuk bedrijven bashen' maar de verantwoordelijkheid genomen zien worden waar het hoort want dat is waarop het systeem van de vrije markt namelijk kan voortbestaan.
Het 'bedrijven bashen' stukje ging over de dikke rekening voor 'alleen een BIOS update'.
En zoals uitgelegd is het vaak meer dan alleen ff een bios update. Een klant komt niet aan zetten van; "ik heb dit en dit probleem en dat kan opgelost worden met een bios update, maar ik weet niet hoe dat moet of ik wil er de verantwoordelijkheid niet voor hebben." Een klant komt dan bij de mediamarkt van: "Hij doet het niet" of "Hij is traag" etc. En zoek het dan maar uit. Waarschijnlijk moet je 7/10 keer eerst alle "zooi" eraf moet gooien om het überhaupt werkbaar te maken.
Lees de context en vooral op wie ik reageerde:

Brandonvds:
Waar media markt weer een dikke rekening voor teruggeeft alleen maar voor een bios update.
84hannes:
Altijd leuk, bedrijven bashen. Maar een computer in ontvangst nemen, transporteren naar een geschikte werkplek, uitpakken, aansluiten
Vayra:
Dus het is niet 'leuk bedrijven bashen' maar de verantwoordelijkheid genomen zien worden
OddesE:
Het 'bedrijven bashen' stukje ging over de dikke rekening voor 'alleen een BIOS update'.
Hopelijk zie je nu dat we het met elkaar eens zijn. Bedrijven leveren een *extra* service als ze de BIOS update voor je installeren. Dus niet gek dat daar een rekening voor komt.
Je stelt wat mij betreft een erg interessant vraagstuk. Wanneer is de consument verantwoordelijk voor het installeren van een update en wanneer is het de leverancier die het dan kosteloos zou moeten repareren onder mom van productiefouten?
Ik ben het met je eens dat het een productiefout (of ontwerpfout) is en de fabrikant het op moet lossen. Maar dat kan intel toch doen door een update beschikbaar te stellen? Is het toepassen van die update ook een taak van de leverancier? Zo ja, wat nou als iemand te incapabel is om Windows Update te draaien (toegeven: het kost meer moeite om updates niet te installeren, maar dat terzijde)? Is de leverancier dan verplicht iedere keer voor jou die handelingen uit te voeren als je met je computer bij de balie staat?
Strict formeel is, in Nederland, de leverancier verantwoordelijk voor het product, niet de fabrikant. De leverancier moet een redelijke poging doen om de fout te herstellen of de klant op een andere manier tevreden te stellen, bv geld terug, maar die verantwoordelijkheid is niet oneindig.
Microsoft heeft een update-manager in Windows zitten waarmee iedere normale gebruiker van het product kan bijwerken. (Wie (onder normale omstandigheden) geen updates kan installeren zal ook niet gewoon met Windows kunnen werken.) Dat is redelijkerwijs voldoende om aan de garantieverplichtingen te voldoen.

Intel zou ook een software-update beschikbaar kunnen maken maar dat is minder mooi omdat ze geen ingebouwde updater hebben. Veel mensen zullen dus nooit weten dat die update er is. Een ander nadeel(tje) is dat Intel rekening moet houden met verschillende besturingssystemen. Dat is geen show-stopper maar het helpt ook niet.

Maar, het blijft de verantwoordelijkheid van de winkel. Die mag die patch van Intel aan de klanten geven en dan is het goed. Maar als die patch niet geschikt is voor hun computer of er gaat iets mis dan is de winkel weer verantwoordelijk. De winkeliers zullen er dus bij Intel op aandringen dat het goed wordt geregeld. (Althans, in theorie, of Intel zich in praktijk iets aantrekt van winkeliers durf ik niet te zeggen).

Als ik Intel was zou ik zorgen dat er een of andere patchkit voor winkeliers is om dit soort problemen op te lossen (USB-key er in, computer booten, even wachten, klaar) en de winkels financieel compenseren voor hun tijd. Dat kost wat, maar Intel moet z'n klanten tevreden houden nu AMD weer concurreert.

Veruit de meeste klanten zullen er geen gebruik van maken, die lossen het liever thuis op dan terug naar de winkel te gaan of hun computer per post te versturen. Voor die paar mensen die toch naar de winkel gaan met hun computer moet Intel dan maar betalen om hun reputatie goed te houden.
OK, dus als jouw auto een probleem heeft met de remmen dan vind je het wel prima als de fabrikant zegt dat je bij deze een onderdeel kunt bestellen dat het probleem oplost?

Nee, de fabrikant moet de afnemer actief benaderen.
Ik denk dat diezelfde groep hyperthreading ook niet uit kan schakelen en daarmee dus gebruik blijft maken van HT en de eventuele bugs die daaruit voortvloeien.

Wat mij nu niet helemaal duidelijk is, is of dit ook Windows gebruikers treft. De melding komt van Debian ontwikkelaars en OCaml maar dat is allemaal redelijk specifiek spul. Andersom, als ik de reproductie lees dan zou je verwachten dat ook Windows zo'n korte loop met zulke registers zou kunnen hebben. Ik heb zelf ook een processor uit die generatie maar ik heb echt geen stabiliteitsproblemen. Wellicht dat de reproductie onder Linux eenvoudiger is?

edit: Ah zelf al gevonden, het hangt af van de microcode die je hebt. Maar Windows 10 doet die microcode updates automatisch dus de kans is wellicht groter dat W10 machines al gepatched zijn.

[Reactie gewijzigd door Cloud op 26 juni 2017 09:03]

Maar Windows 10 doet die microcode updates automatisch dus de kans is wellicht groter dat W10 machines al gepatched zijn.
Debian (en andere distro's) updaten ook de microcode (wordt ook vermeld in de mail). Maar voor Kaby Lake heeft Intel de microcode update enkel nog maar vrijgegeven aan "system vendors". De kans is dus ook groot dat MS geen toegang heeft tot de microcode en dit dus ook niet beschikbaar kan maken aan W10 gebruikers. Deze "system vendors" kunnen dan wel de microcode via een BIOS update updaten, vandaar dat dit wordt vermeld.
Ik zou hier wel graag duidelijkheid over willen, vind het Tweakers artikel wat incompleet qua informatie. Eerste vraag is kan ik testen of ik het probleem überhaubt heb en zo ja hoe fix ik het. Via een Windows update of via een Bios update...
In de bron is een script te vinden (op de Debian mailing lijst) om te testen of je moet updaten.
Hier dus: https://lists.debian.org/debian-devel/2017/06/msg00309.html

[Reactie gewijzigd door latka op 26 juni 2017 19:30]

Het probleem is al een jaar geleden gemeld, maar bereikt nu pas de mainstream media. Het probleem doet zich voor onder heel specifieke omstandigheden. Storm in een glas water zou ik zeggen.
Duidelijk, probleem opgelost haha thanks! :)
Tsja als intel die microcode nou vrijgeeft, kan het gewoon met Windows update meekomen. Hoeft de eindgebruiker niks te doen. (Ik neem aan dat Windows het updaten van microcode ondersteunt)

En voor linux.... als die microcode wordt vrijgegeven komt die gewoon in de repo en komt ook met de updates mee. Dus... ergens snap ik het niet dat Intel deze alleen aan fabrikanten geeft.

Maar als die mensen nog nooit van een BIOS update hebben gehoord, denk je dat ze dan wel het BIOS kunnen vinden om hyperthreading uit te schakelen? Of ze überhaupt zouden weten dat dit zou moeten? Nee, ik denk dat ze dan opgescheept zitten met een computer die af en toe raar doet, met hyperthreading.
Ho. Stop.
Als iemand zo'n duivelse baat heeft bij hyperthreading, zullen die hierdoor moeten/gaan leren hoe zuks op te lossen. Het zijn zulke specifieke scenario's dat iemand de crash mogelijk eenmalig tegen komt wat de impact miniem maakt, of zo repetitief dat het goed te vinden is.

Er wordt pro-actief geadverteerd met hyperthreading; maar net-als bij andere contexten is dat niet hetgene wat geheel feilloze werking garandeert. Echter vind ik het hier vooral jammer om dan te horen dat intel niet pro-actief communiceert hierover...
Ik vermoed dat deze mensen dan waarschijnlijk ook gewoon Windows gebruiken i.p.v Debian. Meestal zijn linux-gebruikers wel beter technisch aangelegd op dat vlak...
Volgens mij kan het OS ook microcode toepassen.
Zie hier bijvoorbeeld
Bugs zijn er overal. In zowel software als hardware. In dit geval blijkbaar in de hyperthreading stack. Totdat het geupdate is is het advies om het niet te gebruiken. Ik snap niet wat hier erg aan is?Windows ben je onderhand elke twee weken aan het patchen om het werkbaar te houden, nu is het een keer iets van je CPU zelf.
Omdat windows updates automatisch gaan en bios updates niet, al zou de microcode wel met een update kunnen komen maar dan moet Intel die wel aanleveren.
Denk dat de crux is dat communicatie tov alle OS en voor vooral servers laat is.
Reden om volgende keer voor AMD servers te gaan. Als voor premium naam betaald maar niet die service krijgt.
Totdat er een fix komt. Tsja. Kan gebeuren, lijkt me. Slordig maar de techniek is dermate complex dat dit soort dingen vaker zullen voorkomen. En wees blij dat het met een kennelijke UEFI-update gefixed kan worden :)
Nee het probleem wordt gemeld en verder geen communicatie van iNtel. Enige verklaring kan zijn dat iNtel het probleem eerst moet valideren en reproduceren om te achterhalen dat er probleem is met de microcode met HT. Ondertussen dat ze met oplossing bezig zijn.

Draaien kritikal servers gewoon door met die HT Bug.
Staat deze standaard aan? En hoe zet ik deze uit?
Asus Prime Z270-P
I7-7700K
Als je niet weet hoe dat moet zou ik er niet eens aan beginnen en het gewoon zo laten zoals het is. Het probleem doet zich alleen onder heel specifieke omstandigheden voor die dus zeldzaam zijn.
Precies, dacht ik ook al. Kan een pc in elkaar knutselen, Windows erop gooien. Maar dat is het dan ook. Laat gewoon voor wat het is.
Het staat inderdaad standaard aan. Als je het toch uit wil zetten, kan je deze instructies volgen. Hoe de UEFI er precies uitziet verschilt per fabrikant, dus je moet mogelijk even zoeken.

(naar mijn mening alleen uitzetten als je onverklaarde applicatie- of systeemcrashes hebt).
Moet ik hier nou zelf nog iets aan doen als eigenaar van een skylake chip? Of is het al opgelost?
Heb je het bericht wel gelezen? Je moederbord fabrikant moet met een bios update het probleem gaan verhelpen. Het probleem is dus op het moment van schrijven nog niet opgelost.
het artikel zegt dat er wel een update beschikbaar is voor debian 8 en 9, maar alleen voor skylake. die voor kaby lake moet nog beschikbaar komen voor gebruikers. dan lijkt het toch dat je bij skylake niks hoeft te doen?

[Reactie gewijzigd door mjz2cool op 26 juni 2017 08:41]

Nee, er is een microcode update voor de cpu, die het probleem met debian 8 en 9 oplost. Dat is geen update voor debian zelf. De microcode update wordt via bios naar de cpu gepushed.
beetje verkeerd verwoord, maar ik bedoel inderdaad voor de cpu, maar zoals het in het artikel staat moet je hyperthreading bij skylake ook uitzetten, maar als de update er is dan kun je die toch beter flashen?
Ja, Intel heeft de gefixte microcode klaarliggen, maar het is nu dus wachten op de mobofabrikenten tot ze die microcode verwerken in hun bios. Tot die tijd zou je HT kunnen uitschakelen mocht je door dit probleem geteisterd worden.
mocht je door dit probleem geteisterd worden.
En als je er niet door geteisterd wordt? Dan zou ik denken laat maar aanstaan, vooral als je Windows hebt en gwn wat gamepjes speelt.

Of denk ik nu verkeerd?
Klopt, het probleem doet zich alleen voor onder zeer spesefieke omstandigheden die uiterst zeldzaam zijn. Storm in een glas water...
Debian weet dat dit kan voorkomen. Debian waarschuwt dus, en geeft daarbij een workaround.
Als jij het risico wilt lopen om tegen deze bug aan te lopen, ga je gang...

Is dit een storm in een glas water? Tja, dat ligt eraan hoe kritisch het juist functioneren van de computer is...
Of de situatie wel of niet vaak voorkomt zegt niets over de ernst van de problemen als het optreedt.
oke, dus zo'n update kun je pas flashen als er een bios update is. duidelijk.
maar dan wekt het artikel wel enige verwarring op, want er is een update voor debian 8 en 9 (als het om een update gaat voor de cpu, waarom is het dan specifiek voor debian?), alleen voor skylake, en er is een update voor kaby lake maar alleen nog voor oems. wat is dan het verschil? in beide gevallen moet de gebruiker wachten op de bios/uefi update waar die fix in zit.
Er zijn 2 manieren om de microcode aan te passen :
1) Permanent via bios/uefi update
2) Door het OS bij boot de patch te laten laden tijdens de boot. Dit moet bij elke boot opnieuw

[Reactie gewijzigd door hackerhater op 26 juni 2017 12:36]

ah op die manier, dan bedoelen ze met die update voor debian 8 en 9 die 2e manier? dan zou het betekenen dat je in dat geval niks hoeft te doen voor skylake
Ik las dat het met microcode was opgelost. Het was voor mij onduidelijk of ik dit zelf binnen moest halen.
Er moet een UEFI update beschikbaar komen met daarin de nieuwe Microcode update van Intel, als je die flashed is dit opgelost.

Overigens zitten er vaak zo maar honderden defecten in je chip, sommigen wat ernstiger dan anderen. Als ze bekend worden, worden ze echter vaak wel gefixed met microcode updates, als dat mogelijk is. Dus als deze patched is dan wil dat niet zeggen dat er geen bugs meer zijn.

[Reactie gewijzigd door -The_Mask- op 26 juni 2017 08:37]

Kan de microcode niet via het OS geupdate worden?
In het geval van een OS geinstalleerd op een UEFI (met secure boot): ja, dat kan. Sterker nog: sommige OEM's pushen via Windows Update. Indien je in MBR-modus zit kan dat, uiteraard, niet.
Waarom kan het in niet-UEFI mode uiteraard niet?
Omdat er niet alleen een lading OS-meuk tussen zit, er zit ook een zaak tussen die 'protected mode' heet. Als je een BIOS hebt, zal die doorgaans 'ontladen' worden zodra je door de POST heen bent in het voordeel van het OS. In het geval van een UEFI is dat niet zo, sterker nog: het is een van de krachten van UEFI dat firmware op die manier ook ontsloten kan worden. Een van de voorbeelden hiervan is GOP (Graphics Output Protocol), een manier om de GPU te ontsluiten direct via de firmware. Niet alleen om een hoop compatibiliteit/IRQ-meuk op te lossen, maar ook om zaken zoals rapid boot (op Windows) mogelijk te maken, waarbij de driver feitelijk een stuk firmware is IPV software.

Indien een UEFI in MBR-modus staat kan het al helemaal niet, voor de simpele reden dat nádat de UEFI gestart is, er ook een soort "virtual machine"-BIOS binnen de UEFI gestart wordt, met als doel om een gast-OS er niet meer van bewust te laten zijn dat er uberhaupt een UEFI is, zodat alleen-BIOS meuk kan starten. Zoals antieke DOS-software. Een analogie zou zijn om je videokaart driver van het host-OS te updaten vanuit een guest OS op een hypervisor.
Ah, MBR-mode op een UEFI systeem.

Of we echt zo blij moeten zijn met een hele hoop closed-source code in UEFI weet ik zo net nog niet maar dat is een hele andere discussie.
Top een biosflash dus, thanks.
Gebruikers van systemen met Intel Kaby Lake- of Skylake-processors dienen onmiddellijk hyperthreading uit te schakelen in het bios of uefi
Hyperthreading uit zetten totdat een BIOS update beschikbaar is die het probleem fixt.
Nou ja, zo'n groot probleem lijkt het niet te zijn, anders hadden we er al veel meer van gehoord. En alleen van 1 software pakket is het bekend dat deze het probleem triggered.
Debian is er dus tegen aan gelopen, dit soort fixen rollen ze niet zomaar uit.
Als je het hele artikel goed leest dan weet je dat het anders zit. een ontwikkelaar heeft het probleem al een jaar geleden aan Intel doorgegeven. En op een keer ook aan het debian team. Die zijn er dus niet zelf tegen aan gelopen. Het is voor zover bekend ook nog maar bij 1 software pakket opgetreden.

Desalniettemin is het wel een serieus issue dat meer software kan treffen, maar niet dramatisch anders was er wel eerder een patch gekomen.

Toch wel lastig, steeds vaker is er commentaar van mensen die niet goed lezen.

[Reactie gewijzigd door gjmi op 26 juni 2017 08:49]

Als je het hele artikel goed leest dan weet je dat het anders zit. een ontwikkelaar heeft het probleem al een jaar geleden aan Intel doorgegeven. En op een keer ook aan het debian team. Die zijn er dus niet zelf tegen aan gelopen. Het is voor zover bekend ook nog maar bij 1 software pakket opgetreden.

Desalniettemin is het wel een serieus issue dat meer software kan treffen, maar niet dramatisch anders was er wel eerder een patch gekomen.

Toch wel lastig, steeds vaker is er commentaar van mensen die niet goed lezen.
Heb het artikel zeker wel gelezen.
De eigenschap van de chips kan onder omstandigheden voor problemen zorgen. Het defect zou in combinatie met alle besturingssystemen kunnen optreden.
Uit het artikel blijkt dus dat dit in meerdere besturingssystemen kan voorkomen, daarnaast zijn ze verder gegaan en hebben ze het in Debian als fix uitgerold dat hyperthreading uitgezet wordt. Dus is deze bug zo erg dat ze liever de performance wat terug schroeven als dat ze een instabiel systeem leveren. Dit doen ze niet als alleen een software pakket van OCaml dit veroorzaakt.
Dan heb je het niet goed gelezen of begrepen.
Je zei dat debian er tegen aan is gelopen, dat is niet zo. Dat heb ik in mijn vorige post nog eens uitgelegd,maar staat ook in het artikel.

Debian heeft ook geen fix uitgebracht die hyperthreading uit zet. Ze zeggen dat je dat zelf moet doen in je BIOS/UEFI. Dat staat letterlijk in het begin van het artikel. Dus je hebt ergens iets verkeerd begrepen.

Er is een fix beschikbaar die voor Skylake het probleem oplost. Maar dat is een microcode update van Intel, die moet door moederbord fabrikanten in de BIOS/UEFI worden verwerkt, en dan moet je zelf nog de BIOS/UEFI updaten.

Dus debian heeft geen fix, alleen het advies om het zelf uit te zetten (totdat je een BIOS update hebt van je moederbord fabrikant met een microcode patch van Intel)

Edit: met debian 8 en 9 kun je ook de microcode patch van Intel laden.

[Reactie gewijzigd door gjmi op 26 juni 2017 09:37]

Het is de Linux kernel die tijdens boot de microcode kan updaten. Theoretisch kan iedere Linux distributie de patch toepassen.
Hou rekening dat Debian nogal vaak gebruikt word op Servers. Een plek waar je zeker niet wilt dat zo een bug eventjes een server doet crashen. Debian is gekend wegens hun stabiliteit ( en ook de reden dat ze volop gebruikt worden op servers ), m.a.w het is niet in hun voordeel om die bug te negeren.

Je kan zoiets negeren als het op een normale gebruiker. Maar op een server ...
Als het niet om productiekritische systemen gaat die 99,99999% uptime moeten garanderen zou ik er niet te veel tijd aan besteden.
Je zou hier maar als developer tegenaan gelopen zijn. Dat zullen wel vele uurtjes debuggen opgeleverd hebben want je legt de schuld eerst altijd bij je eigen code (tenzij het een known bug in je OS, framework etc is).
Ik leg de schuld altijd eerst bij degene waarvan ik de code heb gekopieerd op StackOverflow :)

maar idd, soms denk je bij debuggen dat je gek geworden bent terwijl het dus misschien zoiets is als dit. Ben alleen benieuwd wanneer je tegen dit probleem aanloopt.

[Reactie gewijzigd door cracking cloud op 26 juni 2017 08:36]

Ik hoop dat dat cynisch bedoeld was ;)

Ik heb zelf wel eens een bug in een compiler gehad, daar zoek je idd wel even naar.
Was nog op een 386sx, ging iets fout met 32 bit pointer offsets. Uiteindelijk te vinden door naar de gegenereerde machine code te kijken... dit gaat wel ff wat verder en kan je volgens mij idd echt gek van worden!
Ik denk dat je alleen de H/T hoeft uit te schakelen als je daadwerkelijk crashes hebt. Als je geen issues hebt zou ik het lekker aan laten staan. #My2cts
Jouw 2 cents is een gevaarlijk advies, want het ligt er een beetje aan waar de processor in zit. Is het je desktop game PC ja dan lekker aan laten staan. Is het je nasa mars rover communicatie server, ja dan zou ik het voor de zekerheid maar even uitzetten.

[Reactie gewijzigd door ro8in op 26 juni 2017 08:45]

Bij financiele tranacties is crash uiteraard niet gewenst maar dan worden mislukte transacties terug gedraaid. Maar als 111,22 + 2,5 = 114,94 dan ga je de mist in.
heb nog niets gemerkt hiervan, ga dan ook geen aanpassing uitvoeren om dit uit te schakelen. :+
weet jij hoe dit i.c.m. virtualisatie werkt? Worden dan de CPU's niet op een of andere manier anders aangesproken?
Het gaat dus om dit rijtje CPU's:
http://ark.intel.com/products/codename/37572/Skylake
en deze:
http://ark.intel.com/nl/products/codename/82879/Kaby-Lake
Da's een beste waslijst. Nog een wonder dat ik door het mijnenveld van moederborden/chips uit 2010 en 2012 er geen heb uitgekozen die nu legacy issues veroorzaken.
Nou, het lijkt me sterk dat het om die hele lijst gaat, eigenlijk, want die lijst staan ook processors op die überhaupt niet aan hyperthreading doen ;)

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*