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

Door , , 50 reacties
Submitter: gbh

Maandag zijn documenten opgedoken waarin errata voor de Nehalem-Core i7's staan opgesomd. Een van de genoemde bugs is de translation lookaside buffer-bug, maar volgens Intel heeft deze geen invloed op de Core i7-cpu's.

Intel Core i7-logoHet tlb-erratum dat in het pdf-bestand wordt genoemd, betreft de mogelijkheid dat systemen door het onjuist wissen van tlb-gegevens kunnen crashen of onjuiste resultaten kunnen opleveren. In het document wordt het advies aan programmeurs gegeven om hier rekening mee te houden bij het schrijven van algoritmes om de translation lookaside buffer te legen. Ook zou het bedrijf met een bios-update een oplossing voor het probleem bieden.

In een reactie op het nieuws rond de tlb-bug liet Intel echter weten dat de betreffende passage simpelweg verwijst naar een document uit april 2007. Toen werd bekend dat processors uit de Core 2 Duo-serie een probleem hadden dat met een bios-update kon worden opgelost. Intel ontkent dan ook dat de tlb van de Core i7 een ernstige fout bevat: de errata voor de tlb-bug van de Core i7-cpu's zouden slechts kleine fouten in de vertaling van adressen en foutmeldingen behandelen, en geen invloed hebben op de prestaties van de nieuwe processorfamilie. Bovendien zouden de ontwerpfouten al voor de lancering van de Core i7 met bios-updates zijn opgelost.

Moderatie-faq Wijzig weergave

Reacties (50)

Toch gaat intel onder deze berichten niet lijden. Simpelweg omdat er geen concurrerend alternatief is.

Met de tijd dat de AMD Phenoms geintroduceerd werden was dit niet de snelste processor. een Q6600 van intel was nog steeds stap(pen) sneller!

Combineer het feit dat AMD's TLB bug aan het licht kwam tesamen met mindere prestaties als de intel processoren en je hebt een minder lopende processor. Aangezien Intel's core i7 verreweg het snelste van alle processoren is zullen high-end gebruikers toch voor deze processoren kiezen. Overigens zou de TLB bug bij AMD er voor kunnen zorgen dat een systeem 1 maal in de 2 weken vast zou kunnen slaan, bij 24/7 gebruik en 100% load.

Wat een ophef! Er worden toch ook nog steeds TFT's verkocht met dode pixels, die voor een normale gebruiker vaak niet eens zichtbaar zijn. Ook worden nieuwe auto's nog met voor de normale bestuurders met spuitfouten geleverd.

Kortom: Een storm in een glas water; misschien ten voordele van AMD voor de consument die zich bang laat maken, Niet voor de consument die de situatie logisch bekijkt en voor de beste prestaties gaat.
Flashback? In ieder geval zonder reden.

Bugs in processoren (Zowel van Intel, AMD als andere fabrikanten) zijn doodnormaal. Iedere processor heeft er heel wat van. Daarom is er voor PC processoren ook een systeem om updates te verspreiden die worden geupload naar de processor. Dit gebeurt via de BIOS.

Een gemiddelde Intel processor zal tientallen erata's krijgen. (Melding van de bug en wat er tegen te doen) Simpelweg omdat Intel vrijwel altijd open kaart speelt. Dingen geheim houden hebben ze al in 1994 afgeleerd met de Pentium FDIV bug. Dit in tegenstelling tot AMD, welke stukken minder openheid geeft.

Waar het hier om gaat is een van deze kleine bugjes die al tijden in de processoren zitten. Zo klein dat Intel niet eens de tijd heeft genomen hem te pletten tussen de Core2Duo serie en de Core I7 serie. Dat zou de kostprijs en de introductiedatum namelijk niet ten goede gekomen zijn, wat weer slecht is voor de klanten.

Waarom er nu opeens zoveel aandacht aan gegeven wordt heeft wel met AMD te maken. AMD heeft een blunder begaan met hun (flink grote) TLB bug. Nu komt het woord TLB voor in een document en alle alarmbellen gaan rinkelen op de diverse nieuwssites. Een storm in een glas water, veroorzaakt door iemand die de documenten niet / half heeft gelezen, dan wel niet in staat is om ze te lezen. En zeker niet in staat is ze op waarde te schatten.

Gevolg hiervan is dat Intel zich nu moet gaan verdedigen. Een leuke bijkomstigheid voor de nieuwssites is dat als een bedrijf zich moet verdedigen, dit vrijwel nooit goed staat. Zo kun je er dus nog 2 á 3 artikelen uit halen.

Concluderend: Dit is een bug zoals zo velen. Al lang opgelost in de microcode die al in ieder moederbord voor dit platform aanwezig was nog voordat die borden verkocht werden. Die update wordt dus direct geupload naar de processor. De consument zal het dus niet eens merken, behalve de heisa die er nu rond gemaakt wordt.

[Reactie gewijzigd door Nijn op 2 december 2008 16:52]

Uploaden naar de processor? Veranderd de silicon dan? Bios updates die ervoor zorgen dat bepaalde delen niet meer aangesproken worden met dito prestatieverlies dus

En btw Dit is een nieuwssite, als lezer van een nieuwssite wil ik zoveel mogelijk nieuws horen, als ze dit verzwijgen kunnen ze beter enkel nog marketing van Intel weergeven...

[Reactie gewijzigd door Nille.NET op 2 december 2008 17:01]

Tot op zekere hoogte is het mogelijk om de functies van een CPU te beinvloeden door het laden van vernieuwde microcode. Of dit opgaat voor het TLB weet is niet, maar zie ook Wikipedia:
Microcode bevindt zich, in tegenstelling tot alle andere soorten programmacode (inclusief machinetaal), niet in het hoofdgeheugen, maar in een speciaal geheugen op de processor zelf. Dit geheugen, de control store, hoeft niet noodzakelijk read-only te zijn: soms wordt microcode tijdens het opstarten van de computer vanuit een andere locatie in de control-store geladen. Dit maakt het mogelijk om bugs te repareren of om nieuwe instructies aan de instructieset van de CPU toe te voegen.
Ik weet verder niet of Nijn gelijk heeft hoor, heck, ik weet niet eens of Intel dit wel heeft ingebouwd in de huidige CPU's. Wat ik me wel afvraag: je kan microcode laden naar de CPU, maar hoe weet je dat dit "een bug is zoals zovelen" die "allang opgelost is door de mobo's". Verklaar je nader, zou ik zeggen, het kan namelijk heel goed dat Intel gewoon bang is dat de verkoop (lees: vooral veel OEMs) nu enorm af zal nemen, omdat er iets mis is met hun CPU.
Bugs in processoren (Zowel van Intel, AMD als andere fabrikanten) zijn doodnormaal. Iedere processor heeft er heel wat van. Daarom is er voor PC processoren ook een systeem om updates te verspreiden die worden geupload naar de processor. Dit gebeurt via de BIOS.
Lang niet altijd. AMD moest hun ontwerp een heel klein beetje aanpassen om die TLB bug uit de Phenoms te helpen (resultaat: nieuwe stepping), dat zat dus hardwarematig.
Waarom er nu opeens zoveel aandacht aan gegeven wordt heeft wel met AMD te maken. AMD heeft een blunder begaan met hun (flink grote) TLB bug. Nu komt het woord TLB voor in een document en alle alarmbellen gaan rinkelen op de diverse nieuwssites. Een storm in een glas water, veroorzaakt door iemand die de documenten niet / half heeft gelezen, dan wel niet in staat is om ze te lezen. En zeker niet in staat is ze op waarde te schatten.
Iets mis met de TLB leidde tot instabiele systemen en crashes. Als jij dat "een storm in een glas water" vind, mag je dat eens tegen die bedrijven gaan vertellen die bijvoorbeeld clusters bouwen op AMD CPU's, of kantoren die fijn een hele lading AMD-powered PC's in huis hebben gehaald.

Verder vind ik het nogal dubieus om de kennis van diverse tech-sites op deze manier aan de kaak te stellen. Als je dat vind prima, maar doe ze dan niet af als "iemand die de documenten niet / half heeft gelezen, dan wel niet in staat is om ze te lezen. En zeker niet in staat is ze op waarde te schatten.". Je mag namelijk best aannemen dat ze dat wél hebben gelezen, op waarde hebben geschat en het begrepen hebben. Bovendien heeft Intel het aan Tweakers zelf bevestigd:
Intel kon het bestaan van de tlb-bug aan Tweakers.net bevestigen
Iets aannemen wat de fabrikant zélf over het product zegt, in positieve zin, is grotendeels niet, als dan wel in zijn geheel, objectief.

[Reactie gewijzigd door Bitage op 2 december 2008 17:37]

@Bitage

Ook de AMD bug is opgelost met microcode. Zeker niet tot tevredenheid, want de oplossing was een deel van de processor uit te schakelen.

Verder:
Als je mijn post leest dan zul je zien dat ik dit verhaal over Intel een storm in een glas water vind, niet de bug van AMD. Ik zeg daar zelf toch duidelijk over "Waarom er nu opeens zoveel aandacht aan gegeven wordt heeft wel met AMD te maken. AMD heeft een blunder begaan met hun (flink grote) TLB bug."

Wat betreft jouw stelling over het niet aan de kaak mogen stellen van informatie van tech sites... Ook tech sites nemen nieuws klakkeloos over. Ook tech sites moeten geld verdienen en smullen van dit soort nieuws. Als je een beetje rond gaat kijken op het Internet (of hier op Tweakers) en je een beetje inleest in de materie weet je dat deze bug niet eens in de buurt komt van wat AMD heeft geflikt. Deze bug zit niet eens in hetzelfde melkwegstelsel om het zo maar even te zeggen. Er is dan ook flink veel kritiek op de gast die dit als eerste aan de kaak heeft gesteld.

Verder lees je in mijn post niet dat ik het bestaan van deze bug ontken. Hij bestaat, dat heeft Intel ook bevestigd. Wat ik wel zeg is dat hij al opgelost is in de microcode. Dat is geen uitspraak van mij, dat is gewoon na te gaan.

Ik hoop dat je m'n post nog even iets beter wilt doorlezen en je een beetje wilt inlezen in de materie.

[Reactie gewijzigd door Nijn op 2 december 2008 17:46]

Ook de AMD bug is opgelost met microcode. Zeker niet tot tevredenheid, want de oplossing was een deel van de processor uit te schakelen.
Inderdaad, en Intel beweert nu dat het helemaal opgelost zou zijn door een microcode fix. Vandaar dat ik vraag om wat verheldering: in hoeverre verschillen de bugs dan met elkaar. Ik ben gewoon nieuwsgierig. ;)
Verder:
Als je mijn post leest dan zul je zien dat ik dit verhaal over Intel een storm in een glas water vind, niet de bug van AMD. Ik zeg daar zelf toch duidelijk over "Waarom er nu opeens zoveel aandacht aan gegeven wordt heeft wel met AMD te maken. AMD heeft een blunder begaan met hun (flink grote) TLB bug."
Ik neem AMD dan ook als voorbeeld. Nu aan het licht is gekomen dat ook Intel's i7 lijdt aan de TLB bug (nu dan wel of niet opgelost), zet ik AMD's blunder nogmaals in het spotlicht. Het is namelijk als clusterbouwer of kantoor inrichter/ICT'er funest om instabiele systemen te bouwen of te plaatsen. Ik wilde dus met dat citaat benadrukken dat het niet helemaal terecht is om het maar een storm in een glas water te noemen, aangezien het weldegelijk consequenties kan hebben, AMD als voorbeeld nemende, daar zij Intel voor gingen met het TLB-gebeuren.
Wat betreft jouw stelling over het niet aan de kaak mogen stellen van informatie van tech sites...
Van mij mag je het prima aan de kaak stellen hoor, maar subtieler/genuanceerder zou fijn zijn.

Verder kan het best zijn dat mijn verhaal wat warrig is, dat heb ik wel vaker als ik een lap tekst in een klein kadertje aan het typen ben (overzicht kwijt) :X Excuus daarvoor.

[Reactie gewijzigd door Bitage op 2 december 2008 17:55]

Genuanceerder is onzinnig omdat ik enkel herhaal wat er al dagen op de diverse fora geroepen wordt. (Vanzelfsprekend gecombineerd met mijn eigen kennis).

De TLB is een onderdeel van moderne processoren. De "Translation look-aside buffer". Dit onderdeel bevat (meestal / hopelijk) het gedeelte van de page-table die het meeste gebruikt wordt. De page table vertaald van virtuele adressen naar fysieke adressen. Zonder al te veel in details te treden, de ene TLB bug is de andere nog niet.

De TLB is nog een behoorlijk ingewikkeld stukje electronica (zoals alles dat in een processor zit). Het doet onder andere aan kansberekeningen.

Er is zeker niet zoiets als 'de TLB bug'. Er zijn talloze plaatsen in de TLB waar iets mis zou kunnen zitten. Bovendien is de implementatie van Intel heel anders dan die van AMD. De bug waar Intel last van heeft is dan ook een heel andere met hele andere gevolgen. AMD moest door hun bug (door naar mijn stellige overtuiging slecht testen) besluiten de gehele TLB uit te schakelen.

Bij Intel is dat echter heel anders. De TLB kan gewoon blijven werken. Hij heeft alleen een 'firmware update' nodig.

De Intel TLB bug, om hem zo maar even te noemen, heeft uitdrukkelijk geen consequenties voor kantoor inrichters, ICT'ers en waarschijnlijk ook niet voor cluster bouwers. Want nog voordat de moederborden voor de I7 processoren op de markt kwamen is al een microcode update in de bios gestopt. Met andere woorden: Op het moment dat de eerste I7 processor ingeschakeld werd buiten Intel kreeg hij al direct de bugfix van de BIOS. Kort gezegd kan niemand er dus last van gehad hebben. Daar zijn dan ook totaal geen berichten over.

Overigens is er niets dat deze bug onderscheid van de tientallen / honderden andere bugs die zo'n processor hebben. Nogmaals, dat is normaal. Werkt al zo sinds jaar en dag. Sterker nog, er zijn weinig recente processoren die geen microcode update nodig hadden om stabiel te werken. Als consument merk je hier echter nooit iets van.

Zoals mad_max234 hierboven zegt: De C2D had bij introductie meer dan 100 bekende bugs. Toch zweren hele volksstammen bij die dingen. (Al is dat volgend jaar natuurlijk weer anders)

[Reactie gewijzigd door Nijn op 2 december 2008 19:33]

AMD heeft de optie gegeven om de TLB uit te schakelen, omdat in het slechtste geval het kon leiden tot een crash van de PC. De mogelijkheid tot een dergelijke crash was dusdanig klein, dat het voor de consumenten-pc helemaal niet nodig was om een patch te schrijven. Op server gebied was de kans om er last van te krijgen ook praktisch gelijk aan nul (aangezien praktisch geen server consequent op 100% full load virtualisaties draait), maar omdat je op server-gebied gewoon geen enkele kans wilt lopen op een crash, hebben ze de bug geplet met een inderdaad performance-verliezende patch.

Die hele AMD TLB-bug was juist een grote storm in een glas water.

[Reactie gewijzigd door dahakon op 3 december 2008 11:14]

Ik snap ook niet goed waarom je zo negatief bent over AMD.
Ik heb nog nooit een bericht gelezen van iemand die de bug in het echt heeft gezien. Dus is het volgens mij net als bij Intel: de bug is niet zo erg, want de kans dat je hem tegen komt is uiterst gering.
Uploaden naar de processor? Veranderd de silicon dan? Bios updates die ervoor zorgen dat bepaalde delen niet meer aangesproken worden met dito prestatieverlies dus
1) Intel gebruikt microcode-aanpassingen om dit soort problemen te verhelpen.
2) De bios fix is al lang uit, waarschijnlijk zijn alle reviews die je tot nu toe hebt gelezen ook gebeurd met deze fix toegepast.
En btw Dit is een nieuwssite, als lezer van een nieuwssite wil ik zoveel mogelijk nieuws horen, als ze dit verzwijgen kunnen ze beter enkel nog marketing van Intel weergeven...
Dit is geen nieuws, dit is van een mug een olifant maken, omdat degene die het hele verhaal begonnen is (volgens mij was het Fudo) niet genoeg verstand had van wat hij rapporteerde. Hij zag "TLB" en "bug" in een zin en zag meteen potentieel voor een verhaal (dat er niet is)

[Reactie gewijzigd door Snoitkever op 2 december 2008 17:09]

De tijd dat iedere instructie volledig door transistoren die hier specifiek voor gebakken waren is al tijden voorbij. Deze processoren zijn intern meer RISC dan CISC processoren. (Zoek maar is op, interessant leesvoer) Ze kunnen veel instructies niet direct uitvoeren. De microcode maakt die vertaalslag. Maakt dus van 1 weinig gebruikte instructie waar geen specifieke hardware voor is meegebakken 3/5/8/10/20 instructies waar wel hardware voor is. Voor de veel gebruikte (RISC) instructies is dus meer ruimte on-die. Hierdoor kunnen ze sneller en meer van die veel voorkomende instructies verwerken en maak je netto winst.

Een microcode update zorgt er dus veelal voor dat die vertaling net ietsjes anders gaat of dat er net andere onderdelen gebruikt worden voor een bepaalde instructie. Als het al nodig is om hiervoor meer (RISC) instructies te gebruiken, dan nog zul je het niet merken in je Benchmarks vanwegen de enorme snelheden en (doordat er zo veel instructies zijn, verspreiding) lage mate van gebruik. Van hele segmenten uitschakelen zoals bij AMD nodig was gebeurt maar heel zelden.

Nogmaals, een gemiddelde processor bevat tientallen bugs die doorgaans met microcode worden opgelost. (Of niet eens worden opgelost omdat ze in de praktijk nooit zullen voorkomen en bovendien geen echte schade veroorzaken. Dan wordt er wel duidelijk melding van gemaakt vanuit Intel). Het oplossen van deze bugs merk je niet tot vrijwel niet in je prestaties.

De TLB bug van AMD is hierin een extreme uitschieter en gelijk de reden waardoor er zoveel herrie gemaakt wordt. Maar als we dat bij iedere bug zouden doen, dan wordt die lijst van artikelen hier op Tweakers.net een heel eind langer.

[Reactie gewijzigd door Nijn op 2 december 2008 17:36]

Ik meen me te herinneren dat intel wel tot inzekere mate wat micro code kon aanpassen op zijn cpu's.
Bugs in processoren (Zowel van Intel, AMD als andere fabrikanten) zijn doodnormaal. Iedere processor heeft er heel wat van. Daarom is er voor PC processoren ook een systeem om updates te verspreiden die worden geupload naar de processor. Dit gebeurt via de BIOS.
Niet exclusief via de BIOS. Je OS kan dit eveneens doen (Windows, *nix) en sommige Windows-updates zijn eigenlijk microcode-updates. Punt met het BIOS is dat buiten tweakers de meeste mensen het nooit updaten en dat bepaalde fabrikanten uitermate lui zijn als het gaat om het uitbrengen van BIOS-updates.
Dat idee had ik ook bij het lezen:

Bug komt bovenwater (beide nu meegemaakt)
Vervolgens wordt het ontkent (doet Intel nu ook)

Next step: toch toegeven of een echte crash.

Als ik dit zo lees kan het toch best wel een bug zijn die in de orde van grote ligt als de TLB bug bij AMD. Dat laatste zou niet mooi zijn voor Intel, maar het lijkt er wel meer op. Een kleine bug geef je zo toe (ze proberen hem hier naar mijn mening klein te praten), een grotere bug als die bij AMD en misschien dus ook intel, probeer je echt te verbergen. AMD probeerde dit en faalde, ik zie bij Intel hetzelfde gebeuren eerlijk gezegd.

Edit: Vind het toch vreemd. Waarom laat je een passage in zo'n document staan waar groot "november 2008" en "Core i7" op staat?! Dit is volgens mij wel de meest slechte smoes, zeker omdat hardware.info schrijft in het bericht dat de bug door Intel is bevestigd. Dus de ene keer bevestigd Intel het, de andere keer wordt het ontkend? Duidelijke gang van zaken... NOT!

Daarnaast ontkennen ze hier niet dat er geen probleem is, ze zeggen alleen dat het geen groot probleem is en al is opgelost. Echter vraag ik me dan af waarom programmeurs hier rekening mee zouden moeten houden, de bug is toch al gefixed, toch, intel?!

PFDje, pagina 27

[Reactie gewijzigd door GENETX op 2 december 2008 16:56]

Ja kan ze behoorlijk geld gaan kosten ja. niemand wil immers een cpu met een bug en al helemaal niet op de server markt . Ze kunnen nu 2 dingen doen ontkennen of toegeven een tijdelijke tbl patch maken net zoals amd dat heeft gedaan. Ik heb een vermoeden dat ze het voorlopig houden op ontkennen , omdat een +20% preformance penalty de reputatie van coreI7 compleet zou ruďneren.

[Reactie gewijzigd door Mietex op 2 december 2008 17:22]

Iedereen heeft een processor met bugs en iedereen voor wie die informatie belangrijk is weet dat. Die mensen weten dat iedere processor tientallen bugs heeft en dat deze gewoon opgelost worden met microcode, vaak zonder verlies van enige prestaties of minieme verschillen die in benchmarks niet eens opduiken.
C2D had meer dan 100 bekende bug tijdens de introductie waarvan er nog steeds een aantal niet zijn verholpen, elke cpu heeft bugs, dat is altijd al zo geweest en zal waarschijnlijk ook niet anders worden in de toekomst.

Bug betekend inderdaad niet gelijk dat een cpu niet werkt of niet gemaakt kan worden, zins intel de microcode kan overschrijven bij elke startup hoeft er ook niet gelijk een nieuwe stepping gemaakt te worden.
Hoe ontstaan deze bugs? Zijn het fouten in het ontwerp of heeft het met het productieproces te maken? En lees ik hier goed dat het de BIOS formware is die deze bugs handled? Sorry voor mijn vele vragen, maar dit is nieuw terrein voor me (komt niet meer zo vaak voor, maar je blijft leren :)).
Dit soort bugs ontstaan inderdaad doorgaans door fouten in het ontwerp. Een moderne processor heeft al gauw honderden miljoenen transistoren, en mensen maken nu eenmaal fouten. Waar programma's met duizenden regels code gegarandeerd bugs bevatten is dat bij processors met miljoenen transistoren ook het geval. Het zou echter ook goed een fout in het productieprocess kunnen zijn, dat er bij het ontwerp niet goed rekening is gehouden met bepaalde eigenschappen van het procedee, waardoor iets niet werkt (hoewel dit ook als ontwerpfout gezien kan worden)
En lees ik hier goed dat het de BIOS formware is die deze bugs handled?
Jup, via een BIOS fix wordt de zogenaamde "microcode" van de processor geupdate. Dit kan overigens ook via je normale OS (windows updates zijn soms ook gewoon microcode updates), maar het BIOS is ook een geschikte plek om dit te doen. De aanpassingen in de microcode zorgen er voor dat de CPU op het juiste moment net iets andere operaties uitvoert waardoor de bugs omzeild worden.
Waar kan je ergens vandaan halen welke bugs er bijvoorbeeld in de B3 phenom's zitten?
http://www.amd.com/us-en/...s_and_tech_docs/41322.pdf

Vrijwel elke fabrikant publiceert naast een normale datasheet een errata sheet (of IC Anomaly list zoals Analog Devices het mooi noemt).

[Reactie gewijzigd door Sphere- op 2 december 2008 19:25]

Tja dat programmeurs er ineens rekening mee moeten gaan houden dat Core i7 gaar is vind ik wel wat lam. Intel maakt de fouten en de programmeur moet er maar rekening mee houden. Het is voornamelijk gaar aangezien Intel zelf verwacht dat het aantal Core i7 gebruikers voorlopig nog niet erg groot gaat worden...
Eigenlijk wil ik mij niet in dit soort non-nieuws/onzin mengen maar dit schreeuwt om antwoord.

Dit geldt alleen voor besturingssysteem programmeurs: Microsoft, Linux ontwikkelaars, Apple, etc en bij virtualisatie oplossingen zoals VMWare, Hyper-V en Xen en zo. Elke andere normale programmeur zal het niet in zijn hoofd halen om TLB entries te gaan invalideren als eerste omdat hij geen rechten heeft in een fatsoenlijk besturingssysteem (OS/Virtualisatie opelossing draait alles in ring 0 en je programma's in ring 3) en ten tweede omdat dit alleen iets is voor een besturingssysteem om dat te veranderen en niet voor je eigen huis tuin en keuken programma, zelfs niet voor server software.

Nog iets, dit betreft een specificatie update. In de vorige specificatie was er iets onduidelijk en met deze update vertelt Intel hoe je het had moeten doen. Als je toen de de informatie verkeerd/anders hebt geinterpreteerd dan kun je nu in dit probleem lopen. Big deal zeker omdat er een BIOS fix is zodat niemand iets hoeft te doen die ook nog geen performance kost.

Nou ja, ik houd het er maar op dat mensen geen idee hebben waarvoor een TLB nu eigenlijk is en wat het moet doen en wat nu precies fout is in de TLB. Er zijn leuke artikelen te vinden op het web dus zoek maar eens goed en informeer jezelf voor je overhaaste conclusies trekt.

Disclaimer: Dit is mijn persoonlijke mening en niet die van mijn werkgever.
Programmeurs moeten helemaal niets. Heb je het gelinkte artikel wel gelezen?
The "AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS" document is a SPEC CLARIFICATION, and is simply a pointer to a previous document written in April 2007.
SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs. There are errata on the Intel® Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch.
Oftewel, er was een probleem in eerdere C2D processoren, daarvoor is een extra document geschreven om te voorkomen dat het probleem zomaar voorkomt, en het is vervolgens in BIOS fixes opgelost.

Daarnaast zijn er een aantal (ongerelateerde) kleine Ci7 problemen, en die zijn opgelost met een andere BIOS update.

EDIT: taalfouten

[Reactie gewijzigd door Snoitkever op 2 december 2008 19:29]

Lijkt het nou zo of zit je Intel keihard te verdedigen. Feit is wel dat er een bug zit in een onderdeel waarin eerder al, al dan niet door een andere fabrikant, ook een bug zat. Het probleem is helemaal niet opgelost. De bug zit nog steeds in de CPU. Hij wordt omzeild door middel van een BIOS-update. Ik vind het geen oplossing, jij misschien wel, maar dan hebben we daarover een meningsverschil.

Daarnaast zal ik ook neit meteen Intel op zijn of haar woord geloven aangezien die ook alleen maar wil verkopen en als de kans klein genoeg geacht wordt dat de bug niet of nauwelijks in real-life optreedt, wordt het gewoon eerst op deze manier afgedaan totdat er een nieuwe stepping is.
Lijkt het nou zo of zit je Intel keihard te verdedigen.
Jup, klopt. Mag dat tegenwoordig niet meer? ;)
Feit is wel dat er een bug zit in een onderdeel waarin eerder al, al dan niet door een andere fabrikant, ook een bug zat.
Nee hoor, er zat alleen een bug in een eerdere C2D processor. Er zitten in Nehalem een aantal hele kleine foutjes in het TLB, maar die hebben te maken met error-reportage en zijn in de BIOS gefixd. Als je daar al problemen mee hebt kun je beter nooit meer wat voor chip dan ook kopen, want elke chip heeft fouten, zeker als ze zo complex zijn als een moderne CPU.
De bug zit nog steeds in de CPU. Hij wordt omzeild door middel van een BIOS-update. Ik vind het geen oplossing, jij misschien wel, maar dan hebben we daarover een meningsverschil.
De bug zit wellicht nog steeds in de C2D processor, maar is al lang gefixd met een BIOS update. In veel gevallen kan dit via microcode, en hoewel dit iets performance kost zie ik dit als een fatsoenlijke oplossing. Daarnaast heeft Intel dus een document geschreven hoe deze fout ook voorkomen kan worden, zodat OS programmeurs (mocht de fix niet zijn toegepast) alsnog niet de fout laten optreden. Ik denk dat dit voldoende is, en het beste is dat een bedrijf als Intel kan doen, maar dat is inderdaad een andere discussie. Ik wil er nog wel over zeggen dat als je een processor wilt zonder fouten je lang kan wachten.
Daarnaast zal ik ook neit meteen Intel op zijn of haar woord geloven aangezien die ook alleen maar wil verkopen en als de kans klein genoeg geacht wordt dat de bug niet of nauwelijks in real-life optreedt, wordt het gewoon eerst op deze manier afgedaan totdat er een nieuwe stepping is.
Nogmaals, de bug komt voor bij C2D chips, dus dit is een probleem uit het verleden. Als Fudo in zijn sensatiezucht niet zo'n enorm verhaal hiervan had gemaakt had niemand er ooit iets van geweten, behalve misschien wat OS programmeurs die dagelijks met dit soort bugs te maken hebben.

Dat AMD problemen had met het TLB heeft hier overigens niets mee te maken. Als er in Linux een bug in de TCP laag van de netwerkstack zit die grote problemen veroorzaakt, en in Windows zit ook een bug in de TCP laag van de netwerkstack, gaat iedereen dan ook opeens roepen dat dit hetzelfde probleem is en dat er enorme gevolgen zullen zijn voor Windows? Antwoord is nee, omdat de meeste mensen hier wel weten dat softwarebugs niets met elkaar te maken hebben. Mensen hier lezen echter TLB en denken dat er dus per se relaties moeten zijn tussen de bug van AMD en Intel.

EDIT: Als je Intel niet geloofd kun je ook gewoon zelf de documenten lezen. Dit hele gedoe is ontstaan door iemand die de documenten verkeerd had gelezen en dacht met problemen te maken te hebben die er niet zijn. Als je het zelf leest zul je zien dat Nehalem alleen kleine TLB foutjes heeft en dat de specificatie waar naar verwezen wordt al ouder is (april 2007).

[Reactie gewijzigd door Snoitkever op 3 december 2008 10:49]

Jup, klopt. Mag dat tegenwoordig niet meer? ;)
Je zou advocaat moeten worden ;)
De bug zit wellicht nog steeds in de C2D processor, maar is al lang gefixd met een BIOS update.
Dus is het niet gefixed in de CPU zelf, wat ik dus aangaf. Ondanks dat er meerdere steppings zijn.
In veel gevallen kan dit via microcode, en hoewel dit iets performance kost zie ik dit als een fatsoenlijke oplossing.
Een work-around dus want een fysieke bug los je niet op door een microcode-update te doen.
Daarnaast heeft Intel dus een document geschreven hoe deze fout ook voorkomen kan worden, zodat OS programmeurs (mocht de fix niet zijn toegepast) alsnog niet de fout laten optreden.
Juist om dat soort gevallen te voorkomen zou Intel het probleem al lang in de CPU zelf opgelost moeten hebben.
Ik denk dat dit voldoende is, en het beste is dat een bedrijf als Intel kan doen, maar dat is inderdaad een andere discussie. Ik wil er nog wel over zeggen dat als je een processor wilt zonder fouten je lang kan wachten.
Een work-around vind ik een tijdelijke oplossing, zeker geen definitieve. In een nieuwe stepping zouden dergelijke onvolkomenheden uit het vorige ontwerp/stepping, gewoon voor een groot gedeelte opgelost moeten zijn. Om je analogie met software even aan te houden. Zie het als een Service Pack. Elke stepping is geen compleet nieuw ontwerp.

Wat betreft je laatstse zin heb je natuurlijk wel gelijk. Zolang mensen fouten maken, bestaan er geen perfecte chips.
Dat AMD problemen had met het TLB heeft hier overigens niets mee te maken. Als er in Linux een bug in de TCP laag van de netwerkstack zit die grote problemen veroorzaakt, en in Windows zit ook een bug in de TCP laag van de netwerkstack, gaat iedereen dan ook opeens roepen dat dit hetzelfde probleem is en dat er enorme gevolgen zullen zijn voor Windows? Antwoord is nee, omdat de meeste mensen hier wel weten dat softwarebugs niets met elkaar te maken hebben. Mensen hier lezen echter TLB en denken dat er dus per se relaties moeten zijn tussen de bug van AMD en Intel.
Eens :)
EDIT: Als je Intel niet geloofd kun je ook gewoon zelf de documenten lezen. Dit hele gedoe is ontstaan door iemand die de documenten verkeerd had gelezen en dacht met problemen te maken te hebben die er niet zijn. Als je het zelf leest zul je zien dat Nehalem alleen kleine TLB foutjes heeft en dat de specificatie waar naar verwezen wordt al ouder is (april 2007).
Intel niet geloven is een groot woord. Feit is natuurlijk wel dat Intel zo veel mogelijk chips wil verkopen. Als die chips een probleem vertonen wat zich misschien in 0,0009% van de gevallen voordoet in de vorm van een systeemcrash, zal Intel het niet nalaten dit stil te houden aangezien het wel te nadele van hun verkoopcijfers zou kunnen zijn.

[Reactie gewijzigd door LollieStick op 3 december 2008 12:36]

Dus is het niet gefixed in de CPU zelf, wat ik dus aangaf. Ondanks dat er meerdere steppings zijn.
Misschien, missschien niet. Ik durf het niet te zeggen. Het is ook zo niet na te zoeken. Als het echt kritisch was of de fix zou veel performance kosten dan denk ik dat Intel het wel gefixd zou hebben, maar tenzij je het specifiek bij Intel gaat navragen is er geen manier om daar achter te komen.
Een work-around dus want een fysieke bug los je niet op door een microcode-update te doen.
...
Een work-around vind ik een tijdelijke oplossing, zeker geen definitieve. In een nieuwe stepping zouden dergelijke onvolkomenheden uit het vorige ontwerp/stepping, gewoon voor een groot gedeelte opgelost moeten zijn. Om je analogie met software even aan te houden. Zie het als een Service Pack. Elke stepping is geen compleet nieuw ontwerp.
Oke, mee eens, een BIOS/microcode update is niet hetzelfde als een nieuwe stepping zonder de bug. Ik vind echter persoonlijk dat dit in gevallen als deze meer dan voldoende is. Als jij dat niet vind kan ik me daar ook iets bij voorstellen, maar ik heb geen zin om daarover met je in discussie te gaan ;)
Intel niet geloven is een groot woord. Feit is natuurlijk wel dat Intel zo veel mogelijk chips wil verkopen. Als die chips een probleem vertonen wat zich misschien in 0,0009% van de gevallen voordoet in de vorm van een systeemcrash, zal Intel het niet nalaten dit stil te houden aangezien het wel te nadele van hun verkoopcijfers zou kunnen zijn.
Daar heb je wel een punt natuurlijk. Alleen lijkt er in dit geval gewoon niet eens sprake van een probleem, alleen van onkundige "journalisten" als Fudo :P Zeker omdat de documenten zelf gewoon bevestigen wat Intel zegt, dus dan geloof ik Intel eerder.
Dus, als ik het goed begrijp, zijn er documenten waarin het ene staat, maar Intel beweert iets anders en zegt dat het niet van toepassing is op de i7's? Waarom hebben ze het dan in de documenten gezet die over de i7's gaan? Of zijn die documenten niet van Intel zelf afkomstig?

[Reactie gewijzigd door DJDarkByte op 2 december 2008 16:42]

het is wel van toepassing op de i7, maar het probleem was al bekend en is al opgelost voordat de eerste bios uitgebracht werd. Niemand heeft er last van dus.

Althans, dat beweert Intel :)
Nee, er zijn documenten waarin iets staat, waarvan mensen die er geen verstand van hebben denken dat het het ene zegt, terwijl Intel het andere zegt, wat door het beter lezen van die documenten dan ook ondersteund wordt. Oftewel, nieuwssites maken een storm in een glas water omdat ze het woord "TLB" en "bug" in 1 zin zien staan en er zelf geen verstand van hebben. Dit wordt dan nog wat versterkt door reacties van bezoekers die er nog minder verstand van hebben en conclusies trekken die nergens op slaan, zoals gisteren in het eerste nieuwsbericht al meteen te merken valt.

Concluderend: nothing to see here folks, move along

[Reactie gewijzigd door Snoitkever op 2 december 2008 17:01]

De documenten zijn in April 2007 gemaakt. Het kan best zijn dat er destijds een bug was maar in een later stadium is gefixed
Zwart maken van de i7en een typisch staaltje van gestuurde communicatie zoals dat in de VS zeer gebruikelijk is? Een zgn. neutraal iemand vertelt een verhaal op basis van documenten waardoor van alles in rep en roer komt (door zo'n strategie zijn volkomen ten onrechte medicijnen bijvoorbeeld uit de handel genomen, omdat MSD en Pfeifer beide elkaar op die manier een voet dwars proberen te zetten) Je vertelt dus een indianenverhaal en dat gaat dan lekker zijn eigen leven lijden. Blijft nog wel even de vraag hoe het zat met de opmerking hier op tw.net 1-12-08: "Intel kon het bestaan van de tlb-bug aan Tweakers.net bevestigen, maar kon nog niet vertellen welke gevolgen de fout zal hebben". Fout geďnterpreteerd? slecht gehoord? Niet goed overgebracht? Of is het huidige bericht toch onjuist en wordt de fout verbloemd? Kortom de tijd zal nu moeten leren wat er echt aan de hand is. Voorlopig lijken benchmarks uit te wijzen dat een i7 toch een echt hebbedingetje is. :9
http://www.hardware.info/nl-NL/news/#uGfZ

Even scrollen naar "Intel Core i7 heeft TLB bug" en;

*Intel heeft bevestigd dat hun nieuwste 45nm quadcore - beter bekend als de Core i7 - een TLB bug heeft. De bug wordt uitgebreid beschreven in een PDF document op de website van Intel. Op pagina 37 van dat document wordt de Translation Lookaside Buffer genoemd, waarbij er in specifieke gevallen onvoorspelbaar gedrag kan optreden zoals een vastlopend besturingssysteem of verlies van data.

[Reactie gewijzigd door KoffieNT op 2 december 2008 16:47]

Het Intel document vertelt duidelijk dat het probleem opgelost kan worden in de BIOS en dat we dit reeds aan het doorcommuniceren zijn naar onze partners en dat dus ook voor reeds verscheepte componenten een oplossing voorhanden is. Vergelijkingen met andere situaties – zoals in het artikel vermeld - zijn dan ook niet van toepassing.
Aldus Intel op de zelfde site..
Intel heeft bevestigd dat hun nieuwste 45nm quadcore - beter bekend als de Core i7 - een TLB bug heeft.
Als je het document leest zie je dat er meerdere problemen rond de TLB zijn. Boeien, dat gebeurt bij elke processor. Intel heeft al aangegeven dat dit normale problemen zijn die al lang verholpen zijn. Alle benchmarks en tests die je tot nu toe hebt gelezen maken wss ook al gebruik van de fix, dus er is zelfs geen groot performanceverlies te verwachten.
Ik weet niet of ik je verkeerd begrepen heb, maar ik geef hier mijn mening niet ofzo he :P, ik geef simpelweg reactie op de titel waarin staat dat Intel dit ontkent, en dat ik gister op hardware.info las dat intel juist dit bevestigd, maargoed :D.

Zou wel vet zijn als AMD hier nu flink in actie tegen gaat komen en dat Intel misschien hun prijzen zelfs moet/gaat verlagen. (ze zijn al redelijk vind ik, de instapmodellen iig, maar toch, Nederland hier he? :))

[Reactie gewijzigd door KoffieNT op 2 december 2008 18:31]

In de titel staat:

Intel ontkent ernstige TLB-bug in Core i7

Ze ontkennen inderdaad dat het een erstige bug is, maar bekennen dat er 1 of zelfs meerdere bugs in het TLB zitten.

Ik zie de fout dus niet en ik denk dat niemand hier echt iets van gaat merken, behalve nieuwsberichten dan ;)
Intel kon het bestaan van de tlb-bug aan Tweakers.net bevestigen, maar kon nog niet vertellen welke gevolgen de fout zal hebben.
link: http://tweakers.net/nieuw...m-behept-met-tlb-bug.html

Oké..? We gaan dus eerst zeggen dat er een bug is en dan steenhard ontkennen?
Nee, "we" gaan ontkennen dat de bug belangrijk is. En dat is ie ook niet, want het is al lang gefixd.
Het lijkt alsof iedereen denkt naar aanleiding van dit artikel dat Intel het voor de volle 100% ontkent. Echter is dit niet zo.
Ook zou het bedrijf met een bios-update een oplossing voor het probleem bieden.
Ze ontkennen dat het hier om een ernstige bug gaat. Er zitten wel wat foutjes in, maar als eindgebruiker zullen we die dus niet merken (volgens intel). Ook ontkennen ze dat dit tot prestatie verlies kan leiden (door eventueel (bios) update):
De errata voor de tlb-bug van de Core i7-cpu's zouden slechts kleine fouten in de vertaling van adressen en foutmeldingen behandelen, en geen invloed hebben op de prestaties van de nieuwe processorfamilie.
Met andere woorden, het enige wat je kunt doen is wachten en te tijd zal het duidelijk maken. Er zullen vast wel benchmarks verschijnen met dezelfde systemen mét en zonder (bios) update.

Nu bewerk ik mijn bericht nog even, om dit te citeren:
Bovendien zouden de ontwerpfouten al voor de lancering van de Core i7 met bios-updates zijn opgelost.
Met andere woorden, dit was dus al blijkbaar langer bekend. Je kan geen verschil meten omdat waarschijnlijk alle X58 (en andere aankomende) moederborden in het bezit zijn van een bios die zich om de tlb-bug heen werkt. Hardware website's kunnen op die manier het prestatie verlies niet meten, mocht deze aanwezig zijn.

[Reactie gewijzigd door Red-Front op 2 december 2008 17:06]

Intel kon het bestaan van de tlb-bug aan Tweakers.net bevestigen, maar kon nog niet vertellen welke gevolgen de fout zal hebben.
Bron: nieuws: Nehalem behept met tlb-bug

Waar sloeg dit dan op?
Misschien een woordvoerder die zo niet genoeg over de zaak wist?
Ach in het eerder aangehaalde PDFje staat vrij duidelijk een foutcode die in exact dat zelfde document verwijst naar de Core i7, dus voorlichter is ietwat abuis denk ik ;)
Maar goed een fix is bekend, dus we mogen aannemen dat het geen probleem meer is ;)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True