Nehalem behept met tlb-bug

Intel heeft in een update van de Core i7-specificaties een fout in de translation lookaside buffer gemeld. Een bug in de tlb van AMD-processors zorgde bij AMD voor ernstige problemen.

Volgens een document met errata voor de nieuwe processorfamilie van Intel, de in november uitgebrachte Core i7-cpu's, bevatten de processors een aantal onvolkomenheden. Een van de problemen die in de lijst worden beschreven, betreft de translation lookaside buffer. Fouten in de tlb kunnen in sommige gevallen voor vastlopende systemen of onjuiste gegevens zorgen. Intel kon het bestaan van de tlb-bug aan Tweakers.net bevestigen, maar kon nog niet vertellen welke gevolgen de fout zal hebben.

Middels een bios-update, die al onder bios-fabrikanten en systeembouwers is verspreid, zegt Intel de problemen met de tlb-bug het hoofd te kunnen bieden. Welke impact de update op de prestaties van de processors zal hebben, is echter nog niet bekend. De workaround die AMD toepaste om de tlb-bug in zijn processors te omzeilen, schakelde simpelweg de gehele tlb uit, wat resulteerde in een prestatievermindering. Pas na een nieuwe stepping, b3, was de bug in de AMD-processors echt opgelost. Niet bekend is of Intel de tlb-bug en de overige onvolkomenheden alsnog met een nieuwe stepping zal oplossen.

Reacties (82)

De workaround die AMD toepaste om de tlb-bug in zijn processors te omzeilen, schakelde simpelweg de gehele tlb uit.

Dat kan niet waar zijn. Zonder TLB kan een processor niet (fatsoenlijk) werken.

http://en.wikipedia.org/w...de_Buffer_.28TLB.29_Error

Phenom processors up to and including stepping "B2" and "BA" are affected by this bug. BIOS and software workarounds disable the TLB, and typically incur a performance penalty of at least 10%.

Hier kun je ook lezen dat 'ie optioneel is en er alleen is voor snelheidswinst:
http://nl.wikipedia.org/wiki/Translation_look-aside_buffer

[Reactie gewijzigd door JapyDooge op 1 december 2008 17:36]

Je hebt waarschijnlijk gelijk, de normale caches werken natuurlijk nog wel en die worden dan gebruikt voor translation caching.

Het was ook niet voor niets dat hij nauwelijks nog verkocht werd. Eigenlijk alleen aan specialistische klanten, die ze in supercomputers o.i.d. wilden zetten. Er was namelijk wel een workaround voor in de linux-kernel.

De TLB werd dan ook niet uitgeschakeld, het cachen van de TLB werd uitgeschakeld, wat een flinke latentie veroorzaakt bij het opnieuw vullen van een TLB-ingang, de gegevens moesten uit het trage hoofdgeheugen komen.

[Reactie gewijzigd door dmantione op 1 december 2008 19:58]

De TLB is een cache, namelijk die van je page table entries. Een TLB heeft niet echt nut als die in het gewone geheugen staat, want daar staat de page table al.

Page tables worden gebruikt voor virtueel geheugen. Voor elke virtuele page (4K, 2M of 4M op x86, maar typisch 4K) staat er een entry in een tabel met het fysieke geheugenadres van die page. Omdat de page table in het hoofdgeheugen staat, wat relatief traag is, heeft de CPU een on-die cache waarin de fysieke adressen voor de laatst geraadpleegde pages staan: de Translation Lookaside Buffer. Als je de TLB uitschakelt moet hij de pagetable raadplegen bij elke memory access. Nou gaat dat natuurlijk wel via de reguliere L2 cache, maar omdat die ook gebruikt wordt voor andere data en individuele entries niet bijgehouden worden (maar blokjes van 64 bytes), is het veel minder effectief dan het gebruik van een dedicated TLB en dus trager.

[Reactie gewijzigd door .oisyn op 2 december 2008 01:23]

Hmmm, als de BIOS fix op 14/11 werd uitgebracht heb ik geluk denk ik...

Gigabyte stelde voor hun GA-EX58-EXTREME mobo op 14/11 BIOS-revisie F3 beschikbaar, met als omschrijving:

Fix CPU compatibility issues

Ik heb dan, denk ik, deze fix al. Nergens wat van gemerkt verder, behalve dat de i7-965 een bloedjesnelle CPU is

Hmmm, als de BIOS fix op 14/11 werd uitgebracht heb ik geluk denk ik...

Gigabyte stelde voor hun GA-EX58-EXTREME mobo op 14/11 BIOS-revisie F3 beschikbaar, met als omschrijving:
[...]
Ik heb dan, denk ik, deze fix al. Nergens wat van gemerkt verder, behalve dat de i7-965 een bloedjesnelle CPU is

Ehh, nee... Wat je net citeert zijn de strings waarmee het moederbord de CPUs herkend, dat is toch echt wel even wat anders dan de TLB bug.

Er waren maar drie CPU's voor dit bord bij release, waarom zouden ze dan nog een BIOS releases om (nieuwe) CPU's te herkennen?

In ieder geval heb ik, tot nu toe, nergens last van. Systeem is zo stabiel als wat èn bloedjesnel

Het zal wel weer meevallen als deze bug vergelijkbaar is met die van AMD.
Daar was het ook dat de bug kon optreden maar hoeft niet. Toch zou je verwachten dat na het AMD debacle intel hier erg goed op had getest.
Maar ja alle processoren bevatten "bugjes" dus deze nieuwe I7 is geen uitzondering.
En dat de processoren ook alleen maar ingewikkelder worden helpt natuurlijk ook niet.

Nuja, als alle fabrikanten op alle fouten van andere fabrikanten moeten testen hadden we foutloze producten gehad. Dat gebeurd niet natuurlijk niet. Intel gaat ervan uit dat zijn testwijzen afdoende zijn, en dat blijkt nu niet het geval.

Een fabrikant test niet alles wat ooit bij een ander is misgegaan. Blijft het feit dat het een slordig foutje is, maar je opmerking raakt kant nog wal denk ik.

Volgens mij vatten veel mensen het hier te simpel op... Deze bug hoeft totaal niet op die van AMD te lijken, en hoeft in de praktijk geen enkele overeenkomst te hebben. De oorzaak ligt toevallig ook in het TLB gedeelte van de processor, maar dat is dan ook alles. Iedere processor heeft een handvol tot tientallen bugs en met een 'beperkt' aantal onderdelen, is het dus redelijk logisch dat er af en toe bugs in't zelfde deel vallen.
Het hoeft totaal niet zo te zijn dat deze bug vertraging oplevert, maar het kan ook wel véel erger zijn datn bij AMD. Ik hoor/zie hier nu veel alarmbellen rinkelen, terwijl er eigenlijk nog geen info is, als ik het zo lees. Ja, er is een bug, maar dat is eigenlijk altijd zo...

Processors worden onder hoge tijdsdruk gemaakt, en zijn 'oneindig' complex. Het is dus niets nieuws dat er foutjes achterblijven, en Intel 'kiest' er voor om tot een 'redelijk'lvl te testen, en dan een product te lanceren. Veel doom-denkers gaan uit van't ergste... maar dat hoeft dus totaal niet.

Het klopt dat een CPU altijd bugs bevat. Maar is het ook zo dat de fabrikant daar altijd meer naar buiten komt? Dat is nu dus wel het geval, en wanneer dat in de overige gevallen niet of nauwelijks gebeurd kan dat duiden op een serieuzer probleem.

Maar zoals je wel terecht aan geeft, er is geen verdere info. Dus dat zijn allemaal speculaties.

Intel komt tot nu toe bij elke processor met zijn fouten naar buiten. Het enige waar je intel van kan beschuldigen is dat ze de pentium FDIV bug minder erg hebben doen voorkomen dan die was. Er zijn tot nu toe voor elke processor steeds rond de honderd specification updates. Juist dat intel hier zo duidelijk over is maakt dat ze als een betrouwbare leverancier gezien worden door veel bedrijven die kritische systemen leveren. (niets ten nadele van AMD maar daar heb ik me nog nooit in hoeven verdiepen)
De core 2 had ookal een flink aantal TLB bugs waarvan er een lijkt op de huidige bug. Daar hebben we ook nooit echt structureel last van gehad toch? Zoals al zo vaak gezegd is: elke processor heeft fouten maar de meeste fouten zullen niet of nauwlijks effect hebben op het gebruik. Er zijn tot nu toe in x86 land volgens mij maar twee echt groote problemen rond processor bugs geweest de FDIV bug van intel en de TLB bug van AMD. Ik denk dus ook dat veel mensen hier veel te veel waarde aan dit artikel geven.

[Reactie gewijzigd door jmzeeman op 1 december 2008 21:30]

Volgens mij lees jij dit bericht met een roze Intel bril op de neus.
Want heb jij ooit ergens op dit internet een bericht gevonden van iemand die ook echt met de TLB bug van AMD heeft mee mogen maken?
Ik heb lang lopen zoeken maar er is voglens mij niemand die het tegen is gekomen. Juist doordat ze nogaltijd tegen de naam moeten opboksen dat ze minder zijn hebben ze zulke drastische maatregelen genomen. Voor het geval van.
Bij Intel is het sneller, ach dit is toch nog maar de consumenten versie. Als er een bug gevonden wordt dan ruilen wij die processor wel om voor een ander en klaar.

Nou, een paar maanden nadat de Conroe (de eerste C2D) uitkwam is er een lijst door Intel gepubliceerd met bugs in hun cpu's en hun impact zoals Intel ze zag. Een vergelijkbare lijst bestond voor AMD's toenmalig vergelijkbare cpu's.

Toch kan deze TBL bug waardoor het systeem vast kan lopen ze behoorlijk wat centen gaan kosten als ze het niet snel oplossen. Denk daarbij aan de server markt, een systeem dat vast loopt verkoopt daar niet. Amd heeft virtualization en hun TBL bug al gerepareerd. virtualization zorgt ervoor dat men geen problemen ondervind mocht er iets mis gaan of als men een server wil vervangen. http://www.youtube.com/watch?v=86ocQO-8-Xg&translated=1

Intel daarin tegen heeft een nieuwe generatie server cpu's nodig om de concurrentie aan te gaan met de shanghai, Aan de andere kant was de TBL bug wel verantwoordelijk voor de slechte reputatie van de barcelona. Daarom ben ik benieuwd of deze bug invloed heeft of hun launch datum van de server versie van coreI7.
Ik verwacht dat intel dit probleem eerst oplost voor dat ze een server editie van de coreI7 op de markt zetten.

En intel heeft niet al jaren virtualisatie?


Daarnaast is het maar de vraag of de server versie ook last heeft van deze bug. En in hoeverre het echt een bug is. Misschien is het wel volledig op te lossen via het bios zonder performance impact.

Scheelt dat de server-versie gebaseerd is op de Nehalem. Serverprocessors mogen dan wel uit het midden van de bakplaat komen, de bug is er wel

Hoeft niet perse... Als ik me de AMD TLB bug goed herinner was het daar een timing issue; ergens in het TLB deel van de processor bestond een pad dat net iets te lang was (of, om precies te zijn, net kort genoeg, maar met te weinig marge). Resultaat: het signaal komt niet snel genoeg (niet voor de volgende clock cycle) aan, waardoor dingen fout gaan.
Bij processoren die "goed gelukt" waren trad de bug niet op, bij processoren die net iets minder goed gelukt waren (waar je die ontbrekende marge juist nodig had) kon de bug wel optreden. In dat geval zou je bij chips uit het midden van de wafer dus wel degelijk verwachten dat een lager percentage van de chips de bug heeft, misschien wel geen van alle...

Dit is zowel een desktop als een server processor.

Nuja, als alle fabrikanten op alle fouten van andere fabrikanten moeten testen hadden we foutloze producten gehad

Door te testen kun je aantonen dat er fouten in je product zitten, je kan nooit aantonen dat het foutvrij is. Er kan zicht altijd wel een situatie voordoen waar jij je niet op voorzien hebt en dat dusdanig resulteert in het niet correct werken van je product.

Oftewel het word tijd voor de nieuwe generatie waar Intel al lang over praat.
Namelijk een cpu die on the fly kan worden geoptimaliseerd voor bepaalde taken door een soort embedded software te draaien.

En eigenlijk zal alle software als source code moeten worden verkocht, en elke processer met een compiler, zodat je dit soort fouten in de compiler kan omzeilen, en niet grote hardware stukken hoeft uit te schakelen voor een bugje.

Ben benieuwd hiernaar.. kan me er zo 123 niets over herinneren van Intel.

Maar zoiets hebben we al gehad, helaas niet gehaald: Transmeta.
Een VLIW processor die via Code Morphing Software x86 code kon verwerken.

Maar vergeet niet dat elke processor een bepaalde stuk hardware moet hebben, en ik betwijfel of handig is om de TLB in software te gaan zetten.

Oftewel zelf programmeerbare FPGA's. Daar zijn druk wat onderzoeken mee bezig, voor machines die daar echt baat bij hebben (zoals in de ruimtevaart). Voor consumenten is het niet interessant. FPGA's zijn duurder in grote volumes dan ASIC's en presteren ook een stuk slechter. Een Virtex-5 (toch wel een van de betere FPGA's) heeft bijvoorbeeld "maar" een 550MHz clock, wat natuurlijk niets is tegenover de GHz'en van Intel.

En een hoop fouten kunnen ze al verhelpen door via de microcode instructies om te schrijven naar andere instructies die de bug omzeilen.

Namelijk een cpu die on the fly kan worden geoptimaliseerd voor bepaalde taken door een soort embedded software te draaien.

Dat is al ooit geprobeerd, er waren processoren waar je de microcode vanuit software kon aanpassen. Da's nooit echt een succes geworden.

Het zou mooi zijn als het meeleveren van een compiler dit soort problemen op kan lossen, maar ik vrees dat een compiler in dit geval (zonder de microcode aan te passen) weinig anders kan doen dan dat stuk hardware niet gebruiken, wat niet wezenlijk verschilt van dat blok hardware helemaal uitschakelen.

Tuurlijk, in sommige gevallen zou zo'n compiler kunnen helpen (bijvoorbeeld in de tijd van de FDIV bug in de eerste Pentium), maar ik denk dat het huidige systeem (laat het over aan OS / BIOS) het handigst werkt; dan zijn er weinig stukken code die zich hier zorgen over hoeven te maken, normale programma code kan gewoon vrolijk doen waar het zin in heeft omdat het probleem toch wel opgelost wordt.

Voor zover ik weet gebruikt Intel al jaren microcode in hun processoren hoor. Dat is ook de manier waarop dit "probleem" (wat overigens een storm in een glas water is) nu opgelost is.

Sorry, zo bedoelde ik het niet.

Alle moderne CPUs maken gebruik van microcode. Sommige meer dan andere, maar allemaal gebruiken ze het. Wat ik bedoelde is dat er een tijd terug processoren waren waar de applicatie-programmeur, terwijl de chip draaide, nieuwe / andere microcode in kon laden. Dát is nooit een succes geworden.

En daarmee komen we bij je volgende punt, dat Intel microcode-updates kan gebruiken om sommige bugs te fixen. Ja, dat klopt, maar in dat geval gaat het om een (in verhouding) erg kleine aanpassing; het overgrote deel van de voorgeprogrammeerde microcode blijft ongewijzigd. Een ander verschil is dat (voor zover ik gehoord heb) Intel CPUs nogal hun best doen om te controleren of die patch wel door Intel is goedgekeurd; gewone programmeurs kunnen dit mechanisme niet gebruiken.

volgens computerbase.de kan het probleem alleen optreden wanneer software zelf schrijfbewerkingen in TLB annuleert en komt het probleem ook voor bij de Core 2 Duo :

http://www.computerbase.d...b-bug_intel_core_i7_oder/

Toch zou je verwachten dat na het AMD debacle intel hier erg goed op had getest.

Het zou zomaar eens kunnen dat Intel dit al lang wist, maar dat ze besloten hebben er voorlopig niets aan te doen omdat dat te veel tijd / geld zou kosten.

Het zou zomaar eens kunnen dat als je het artikel goed leest, je er achter komt dat er al lang een bios fix is.

Voor de mensen die AMD afgeurineerd hebben met de tlb-bug (B2 stepping).

Zelfs de grootste processor fabrikant kan dit probleem hebben zelfs als bekend is dat dit een fout is die ze het beste kunnen vermijden (omdat veel mensen het als een blunder zagen bij hun grootste x86 concurrent, AMD).

Moto, zo slecht is AMD nog niet. Hebben ze nu dubbel en dwars bewezen als alle Shanghai nieuws klopt. (En de Barcelona, zeker de B3 een heel goede processor, zeker prijs prestatie verhouding).

Je hebt gelijk, maar pas op...
Het was ook een grote blunder van AMD, groter als die van Intel namelijk om volgende reden.
AMD moest toen echt een teken geven van wij kunnen Intel wel aan en wij kunnen zeker ook zo'n goeie processor maken als zij... De prestaties waren niet echt goed genoeg om Intel bij te benen en dan steekt er nog een bug in waardoor veel consumenten wantrouwen kregen in de Phenom.
Intel heeft nu nog steeds de luxe om te kunnen zeggen: "Sorry er zit een bug in onze Core i7, we weten dat en een nieuwe stepping zal er snel aankomen. Maar kijk eens hier wij hebben voor u nog een Core 2 Quad die nog steeds veel beter presteert dan de quadcores van onze concurrentie, misschien moet u even overwegen om deze te nemen..."

Ik weet het niet voor wie deze bug financieel het meeste weegt. AMD bestaat uiteindelijk nog steeds en doen het steeds beter.

Het is duidelijk dat het overschakelen naar een hele nieuwe architectuur met native quad core voor zowel AMD <-> Intel een zeer zware beproeving is.

IMO geeft dit aan dat AMD technologisch niet onderdoet voor Intel.

AMD stond onder grote druk om Barcelona te releasen.
Intel stond dat niet voor de Core i7, ze konden rustig de tijd nemen om het goed te doen.

Slordig van beiden, maar vooral van Intel. Iets te laid-back wellicht?

Dat is wat ik bedoel ja... ;-)

Elke processor heeft tientallen bugs, dus wat is het grote probleem hier? Er is niet bekend om wat voor probleem het gaat, dus voor hetzelfde geld is dit iets dat met gemak in code opgelost kan worden (en daar lijkt het wel op, aangezien er een bios fix is) Het probleem van AMD was dat de TLB bug, of beter gezegd, de oplossing voor de TLB bug flink performance kostte. En die bug was natuurlijk ook gewoon een foutje (zoals bij alle bugs), niet een blunder. Het kwam alleen erg slecht uit voor AMD op dat moment.

Dat blijkt nergens uit. De AMD fix was ook een bios-update, en die schakelde de hele TLB uit met perfomanceverlies tot gevolg.

Je kan dus nog niets zeggen over een eventuele performance hit die een fix met zich mee zal brengen.

Het probleem van AMD met de TLB bug was een reden voor de server markt om de Phenom bij de introductie min of meer links te laten liggen en te wachten op de B3 stepping .
Ik vraag me af wat dit voor Intel betekend op de server markt vooral aangezien AMD een nieuwe architectuur in 2009 de markt op gooit .

de bios fix die dit probleem moet oplossen is voor 14-11-08 uitgegeven en dus voordat de i7 op de markt kwam, alle reviews zijn naar alle waarschijnlijkheid ook hiermee gedaan

Gelukkig voor Intel is het geen server processor want server leveranciers houden niet van processoren met dit soort bugs.

De Nehalem is ook een server processor.

Zie: http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)

Dan moet je je eigen link wel goed lezen. Nehalem is een desktopprocessor, maar Westmere, die gebaseerd is op Nehalem en die in 2009 moet uitkomen, is de servervariant daarvan.

?

Codename Market
Nehalem-EX (Beckton) MP server
Westmere DP server/desktop
Nehalem-EP (Gainestown) DP server
Bloomfield Desktop
Lynnfield Desktop
Clarksfield Mobile
Havendale Desktop
Auburndale Mobile


Volgens mij zijn het zelfs alleen de Server processors die Nehalem in de naam dragen?

Dat klopt, maar technisch gezien is Nehalem dan ook nog niet gelanceerd. Het is Bloomfield die nu gelanceerd is, en Nehalem (server) chips komen pas voorjaar 2009 op de markt.

De server varianten worden ook tegelijkertijd met de desktop varianten geleverd.

Omdat server systemen stabiel moeten zijn worden ze aan veel meer testen onderworpen dan Desktop systemen, dat is de reden waarom je server systemen met de Nehalem pas later zult zien.

En daarbij een desktop variant wordt veel vaker en eerder verkocht in bulk dan een server processor. Puur omdat de markt bij de consumenten hier veel kleiner voor is.

De Westmere is de 32nm shrink van de Nehalem.

Dat is pech voor Intel. Zo zie je maar dat zelfs de grootste chip bakker foutjes kan maken. Voor AMD is dit ongetwijfeld goed nieuws. Ik hoop voor AMD dat hun verkopen erdoor zullen stijgen. Das weer goed voor de concurrentie en innovatie.

Ik vraag me af of Intel nu dezelfde afbranding gaat krijgen als AMD gehad heeft. Alles is natuurlijk afhankelijk van de impact die een work-around heeft. Wat ik me ook afvraag is of Intel al server processoren aan het bakken is en/of die deze bug ook hebben.

Als dat zo is, dan zullen ze hem wel 'omdopen' tot desktop processor. Als het al een bug is die performance penalty heeft. Zoals eerder gezegd is, er is weinig bekend over wat deze bug echt is. Intel zal echt niet zijn goede naam op server gebied te grabbel gooien.

Zo zie je maar dat zelfs de grootste chip bakker foutjes kan maken.

Iedereen maakt fouten. Elke processorarchitectuur heeft tientallen tot honderden "bugs", en het zou prima kunnen zijn dat dit een miniscule bug is die geen grote gevolgen voor wie dan ook zal hebben. Dat het een probleem rond de TLB betreft zegt helemaal niets.

Is dus maar goed geweest, dat ik nog wat gewacht heb.
Laat eerst maar eens de kinderziektes eruit gehaald zijn, en even wachten op een nieuwe stepping

de bios fix die dit probleem moet oplossen is voor 14-11-08 uitgegeven en dus voordat de i7 op de markt kwam, alle reviews zijn naar alle waarschijnlijkheid ook hiermee gedaan

De benchmarks die tot nu toe zijn uitgevoerd, waren dus allemaal met de tlb bug.
dus waarom die commotie, de prestaties, zijn dus nog steeds uitstekend, wellicht zitten in de meest recente biossen al een oplossing ingebakken.

Ben trouwens erg te spreken over mijn I7 920, presteerd beter dan mijn voorgaande Q9550, en merk niets van een tlb bug.

Ben trouwens erg te spreken over mijn I7 920, presteerd beter dan mijn voorgaande Q9550, en merk niets van een tlb bug.

Op zich is het alleen maar logisch dat je het niet merkt, want je weet niet waarvoor een dergelijke functie op een CPU voor gebruikt word. Pas als je dat weet, word het meetbaar.

Ik ben zelf overigens benieuwd hoe Intel het gaat oplossen in een nieuwe stepping.
Moet ik die TLB-functionaliteit namelijk zien als software of is het electronica?

TLBs zijn hardware bij uitstek. Ze worden gebruikt op het meest kritieke pad, geheugen access. Vanwege dat belang mag je dus verwachten dat er behoorlijk veel handwerk in het ontwerp zit. Ter vergelijking, RAM en cache is typisch (geautomatiseerd) copy-paste werk. Maak 1 but, vervolgens 1 regel en uiteindelijk 1 array.

Idem met BA en B1/2 Barcelona's hier, 2344-8347. Ook commotie om niets. Kleine lettertjes met AMD dat het over CPU's met hogere clock ging, werd door de commotie alles gecancelled.

Met het bericht moest ik stiekum een beetje lachen dus. Echter als het in de media te ver opgeblazen wordt, vergaat het Intel mss ook net zo goed als met AMD toen.

Benchmarks tot op heden zijn kennelijk met CPU's gebeurt met deze bug. Reviewers hebben met Intel en toen ook met AMD niets vreemds kunnen ontdekken. Het maakt mijn interesse er niet minder op, ik kijk nog steeds uit naar een betaalbare Nehalem. Nadruk op betaalbaar.

Persoonlijk ben ik 2x een TLB gerelateerde fout tegen gekomen, en dat was in de voorloper van de Barcelona (harde reset na geheugen intensieve opdracht, fout met synchroniseren cache tussen cores). Zo ook heeft de voorloper van de Nehalem enkele TLB bugs.

Het is aan de ene kant niet eerlijk om een CPU af te schieten die een 9 verdient. Maar aan de andere kant als die ene punt die je mist een veel eerder vaker voorkomende fout is.....