Bug in Intel Core 2 Duo aan het licht gebracht

Een aantal Core 2 Duo-cpu's heeft 'betrouwbaarheidsproblemen'. Zowel computerleveranciers als Microsoft hebben reparatiesoftware uitgebracht, die vastlopers moet voorkomen.

De update van Microsoft spreekt alleen van 'Intel processors', maar The Inquirer achterhaalde dat het probleem aanwezig is in Core 2 Duo E4000/E6000-, Core 2 Quad Q6600- en Core 2 Extreme QX6700/QX6800-processors. Ook laptops met een Core 2 Duo T5000 of een T7000 en Xeons met het typenummer 3000, 3200, 5100 of 5300 zouden de gewraakte fout bevatten. Diverse fabrikanten hebben al bios-updates online gezet, waarbij benadrukt wordt dat de patches absoluut noodzakelijk zijn om een goede werking van de machines te kunnen garanderen. Het probleem is volgens de documentatie van HP dat de bewuste cpu's op een onjuiste manier met gegevens in de cache omgaan, waardoor de verkeerde data kan worden gebruikt met, in het ergste geval, instabiliteit of crashes tot gevolg.

Dat Microsoft een patch heeft uitgebracht, heeft tot veel speculatie geleid: zo zouden Macs geen update nodig hebben, omdat de gewraakte functionaliteit niet door OS X wordt gebruikt. Volgens HP is een kernel panic onder Linux echter niet uit te sluiten, waarmee in elk geval duidelijk is dat een bios-patch veruit de voorkeur heeft boven een pleister op het besturingssysteem. Intel heeft het bestaan van het manco erkend, maar zou geen terugroepactie overwegen. Het bedrijf hoopt er uiteraard op dat de problemen van beperkte omvang zullen blijken: eerdere bugs die wel tot een product recall leidden, bezorgden het bedrijf veel pr-schade. De chipbakker zal in elk geval hoop hebben geput uit de tests van HP: ondanks grondig onderzoek slaagden de onderzoekers van dat bedrijf er niet in om de problemen in alledaagse praktijksituaties te reproduceren.

Reacties (114)

[Nijn]

Helaas erg weinig info, maar het lijkt een zeer beperkte bug te zijn.

Even wat info: Een processor kan "gepatched" worden met een stukje eentjes en nulletjes genaamd een microcode. Dit gebeurt door de BIOS/OS. Om een processor te patchen moet de BIOS/OS geupdate worden. Vervolgens laad de BIOS/OS de nieuwe microcode in de processor.

Helaas is dit geen geweldige oplossing. De microcode bepaalt hoe bepaalde bewerkingen worden uitgevoerd. Deze code zorgt er dus voor dat de processor bewerkingen zo snel mogelijk uitvoert. Microcode kan echter niets aan de processor zelf veranderen, alleen data naar andere onderdelen sturen. Dat zal in dit geval dus ook gebeuren, een bepaald gedeelte van de processor zal uitgeschakeld worden en de bewerkingen zullen door een ander deel opgelost worden. Deze oplossing kost per definitie wat "rekenkracht", maar dan zit je waarschijnlijk ver in de promielen.

[liledevil]

Ik weet niet precies wat voor fout het precies is, maar het klinkt bijna alsof het tijd is om de oude pentium grappen weer uit de kast te halen

OT: Het lijkt mij dat een BIOS update idd een betere remedie is dan een OS patch. Vind een OS patch voor een dergelijke bug een vreemde benadering, zeker wanneer slechts 1 OS word meegenomen.

[Verwijderd]

Ik kan me voorstellen dat bedrijven niet bepaald te wachten zitten op een bios update voor hun hele park. Dat gaat je systeembeheerder aardig (lees HEEL VEEL) tijd kosten en zoiezo is het een 'gevaarlijke' operatie (al is het tegenwoordig zo goed als veilig)

[To_Tall]

ASUS borden, PC's van DELL HP enz kunnen vanuit windows Patchen.

Dus met een Scriptje pushen naar de machine's en dan gelijk laten lopen met WSUS en niemand zal er wat van merken...

[Verwijderd]

Ik kan me voorstellen dat bedrijven niet bepaald te wachten zitten op een bios update voor hun hele park. Dat gaat je systeembeheerder aardig (lees HEEL VEEL) tijd kosten en zoiezo is het een 'gevaarlijke' operatie (al is het tegenwoordig zo goed als veilig)

Server-based computing met een ilo kaartje.

[Firefox]

System Manager van HP kun je 1 server als repository inrichten en alle servers daarnaar laten wijzen.

Deze 'clients' sturen een catalog van wat ze zelf hebben, de repository checkt vanaf dat moment op gezette intervallen of er nog nieuwe versies beschikbaar zijn, en je krijgt dat uitgekauwd met groene vinkjes, gele uitroeptekentjes en oranje warnings terug wanneer een driver up2date, verouderd is, en of de nieuwe update als kritisch wordt aangemerkt.

de Open Manage Server Update tool van Dell heeft ook zo'n oplossing met een repository CD die dat allemaal bij elkaar zoekt en installeert, en evenzo met IBM Director. (Da's helemaal automagisch en gescheduled.)

Kost een avondje onderhouds window, maar ach, als je er toch bezig bent met de windows updates....

[the_stickie]

Zowel het OS als de BIOS kunnen microcode naar de cpu sturen.
Die microcode maakt het mogelijk de cpu te "updaten".
Vermoedleijk bestaat de oplossing in beide gevallen dus uit dezelfde microcode die op verschillende manieren (door BIOS of OS (via ACPI, dus eig ook via bios) op de cpu geladen wordt/vervangen wordt/omzeild wordt.
http://en.wikipedia.org/wiki/Microcode

[Reactie gewijzigd door the_stickie op 27 juli 2024 04:14]

[Glimi]

De link die je geeft gaat puur om de interne vertaling van (CISC) opcodes naar veel kleinere instructies. Dit is hoe veel de moderne processor werkt, het opbreken van instructies naar kleinere delen om deze parallel uit te kunnen voeren in de pipeline in plaats van serieel als het een ondeelbare instructie blijft.

Ik zou met de door jou geleverde wikipedia link niet kunnen voorstellen hoe je de CPU kan 'updaten', eigenlijk zelfs al wat je er mee bedoeld?

--edit ik lees niet goed. Je bedoelt feitenlijk de code welke een instructie ontleed in verschillende microinstructions. Nooit over nagedacht dat deze gepatcht zou kunnen worden

Is er trouwens iemand die meer tech details heeft, of een bron over dit issue?

[Reactie gewijzigd door Glimi op 27 juli 2024 04:14]

[TD-er]

Klopt, dat heb ik al eens gezien met een dual-pentium-pro bordje.
Oude BIOS-versie en dmesg van Linux gaf aan dat er een bepaalde bug in de CPU gedetecteerd was. Nieuwe BIOS erop en die bug was weg

[Ge Someone]

idd staat ook in het gelinkte KB artikel

A microcode reliability update is available that improves the reliability of systems that use Intel processors.

[humbug]

Ra ra waarom Intel dit updaten van de microcode mogelijk heeft gemaakt ......

[Verwijderd]

Ja na de grote FDIV blunder ben je natuurlijk wel wat voorzichtiger.

[J.J.J. Bokma]

processoren zijn complex. De meeste draaien software (vaak op diverse nivos), en in software kunnen (net als in hardware) bugs optreden. Veel processoren hebben 1 of meer bugs. Sommige van die bugs treden op bij een bepaalde instructievolgorde, en kunnen dus vermeden worden. Sommige bugs kunnen extern gepatched worden. En als de software in de processor aangepast kan worden, is een patch mogelijk.

Bugs in processoren is dus geen "pentium" grap, of Intel specifiek (ook de ARM2, om maar iets te noemen, had een bug waar je omheen moest werken).

[mashell]

Beetje vreemd gedoe, en wel erg weinig detail info. Wat moet die patch doen? Zorgen dat instructies en data niet meer in een bepaalde volgorde in de cache komen te staan? En wat kan die BIOS patch daaraan doen?

[PWM]

Dat verklaard wat.

Ik heb heel veel problemen met mijn T7400. Blauwe schermen, op zowel Vista als XP, die melden dat er een probleem met de proccessor is komen heel vaak voor.

Proc is al 2 keer gewisseld, zonder resultaat.

Dit is mijn foutmeling:

"A Clock interrupt was not received on a secondary processor within the Time Interval"

[Reactie gewijzigd door PWM op 27 juli 2024 04:14]

[Jiriki]

De chipbakker zal in elk geval hoop hebben geput uit de tests van HP: ondanks grondig onderzoek slaagden de onderzoekers van dat bedrijf er niet in om de problemen in real life-situaties te reproduceren.

Ik vraag me af of je probleem dan wel hiermee te maken heeft. Als ze er gericht op testen, kunnen ze het niet reproduceren.

[Verwijderd]

ik had in het begin ook veel problemen met met m'n dual core.
Constant vastlopers en blauwe schermen.
Maar nu loopt hij al ruim 8 maanden perfect! (wel afkloppen op een eiken houten tafel)

[humbug]

Klinkt als een moederbord probleem, niet als een CPU probleem. Het contact naar de CPU zal wel beschadigd zijn.

[Verwijderd]

Lijkt mij denk ik een probleem met je HPET timer. Volgens mij krijgt je 2e core geen HPET timer interrupt. Kan zijn dat een bios update het probleem fixt en anders moet je denk ik je moederbord vervangen.

[atomik]

Dus iets dat een heel team van experts niet voor elkaar weet te krijgen, namelijk het reproduceren in een real life scenario, lukt jou niet één, niet twee, maar meerdere malen??

Ik zou gaan solliciteren bij HP als ik jou was!

Of iets aan de echte oorzaak doen?

[martdj]

Jullie vergeten hier wat het begrip reproduceerbaarheid betekent.
Dat ze het niet kunnen reproduceren betekent dat ze niet een vaste serie acties kunnen bedenken waarbij de fout zich elke keer voordoet. Het is dus best mogelijk dat een fout zich met enige regelmaat voordoet zonder dat deze te reproduceren is.

[Beretta1979]

Inderdaad heb af en toe ook problemen met mijn software bij klanten , crashes die zich dagelijks voordoen en die we hier bij testing met de beste wil van de wereld niet kunnen reproduceren. (zoals gezegd een vast scenario van stappen uitvoeren waarbij de fout altijd optreed). In feite als je een bug kan reproduceren heb je hem als half opgelost.
Typisch voorbeeld hiervan zijn memory leaks in software. De oorzaak ligt vast maar de crashes kunnen vrij random zijn. Ik kan mij voorstellen dat dit hetzelfde is bij een cache van CPU.

[humbug]

Memory leaks zijn vrij simpel op te sporen. Daar hebben we tenslotte profilers voor

[Verwijderd]

Als ik jou was zou ik eens een ander moederbord proberen. "A secondary processor" wijst erop dat het niet je central processing unit is die het probleem vormt maar een secundaire processor. Ik zou eerder denken aan een geheugencontroller, schijfcontroller of een onboard geluidskaart ofzo.

[MeNTaL_TO]

Waarom zou de melding niet op 1 van de 2 cores op de cpu kunnen slaan?
Zeker gezien de bug het verkeerd gebruik van de cache betreft.

[videodok]

't lijkt me stug, maar probeer eens zo'n patch zou ik zeggen

[Miglow]

Die Windows spellingscontrole is dus ook niet zo goed. Ik heb vroeger op school geleerd dat het enkelvoud is. Geen spellingscontrole voor nodig

[Verwijderd]

"ondanks grondig onderzoek slaagden de onderzoekers van dat bedrijf er niet in om de problemen in real life-situaties te reproduceren."

Als dat met veel moeite en expertise nog niet lukt, waar praten we dan in hemelsnaam over?

@thekip:

Ik begrijp wat je bedoelt hoor, maar als je het nooit 100% kunt testen, hoe kun je dan een goed werkende patch schrijven? Vreemd m.i...

@DutchStoner:

Ik bedoel: als je de BUG niet 100% kan testen hoe kun je dan een goed werkende patch schrijven. Ik snap oo kwel, dat je niet alle software 100% kunt testen.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 04:14]

[Rataplan]

De crux zit 'm in 'real life'. Vooropgezette labtests laten de fout duidelijk zien, maar in de praktijk hoor je 'm volgens dit onderzoek zelden of nooit tegen te komen.

Heb de bewuste tekst even iets scherper geformuleerd.

[Reactie gewijzigd door Rataplan op 27 juli 2024 04:14]

[TD-er]

Ik vraag me af of deze patch mogelijk ook een gevolg heeft voor de performance. Grote kans dat ze met deze patch de benadering van het cache-geheugen aangepast hebben en dat zou dus mischien een snelheidsverschil kunnen opleveren.
Mischien leuk om eens te testen.

[Verwijderd]

Een hardwarefout in iets als de cache kun je niet zomaar triggeren. Het zal in specifieke gevallen voorkomen, maar je hebt zoveel omgevingsvariabelen dat je nooit echt iets 100% kunt testen.

[DutchStoner]

Als men wel 100% tests kan uitvoeren zouden er geen patches nodig zijn...

[Verwijderd]

Hoe kan je nou een bug testen?

[J.J.J. Bokma]

Een bug in software is gewoon een reeks instructies met een fout. Waarom zou je dat niet kunnen testen? Stel een ingave wordt met 3 vermenigvuldigd, maar dat had 3.1 moeten zijn. Dat kan je perfect testen. Je voert 10 in, en je krijgt 30.


Het is ook goed gebruik om voor (!) of tenminste tijdens het ontwikkelen van software diverse test routines te schrijven, en regelmatig die tests te draaien en de resultaten na te lopen. In voorgenoemde voorbeeld zou je dus een test kunnen schrijven die 10 invoert, en controleerd dat er 31 uit komt.

Ditto voor hardware.

[Fiander]

Ik herinder me een bug die ook niet door een team van experts gevonden kon worden.
was als ik me goed herinder iets als 1 / 2 waar de eerste pentiums 1,7 van maakten of zo. ( echte berekening had andere getallen, maar was wel zoiets simpels. )

[iceheart]

edit oops, foutje. sorry.

[Reactie gewijzigd door iceheart op 27 juli 2024 04:14]

[Verwijderd]

De bug waar in het artikel over gesproken wordt is de zgn. FDIV bug, dit had inderdaad bij delingen fouten.

[RobIII]

@PWM:

ondanks grondig onderzoek slaagden de onderzoekers van dat bedrijf er niet in om de problemen in real life-situaties te reproduceren.

Lijkt me stug dat jij er dan toevallig last van hebt

[PWM]

Met reproduceren hebben ze het over een "reproduceerbaar scenario". Een actie die altijd de fout tot gevolg heeft.

Dat hebben ze niet, en ik ook niet. De fout is namelijk compleet willekeurig.

[Verwijderd]

Hoe is deze bug dan vastgesteld / gepatched als hij niet te reproduceren valt? Lijkt me dat er maar wat gegokt wordt van "hmm dit ZOU het kunnen zijn". Als je het niet kan reproduceren weet je het niet, en het is ook al erg vaag dat dat niet mogelijk is.

[J.J.J. Bokma]

reproduceerbaar in real life situaties. Is boven aan al tig keer uitgelegd, zou fijn zijn als mensen de reakties ook eens lezen voor spontaan hetzelde in te tikken wat al 10x opgemerkt is.

[Joghert]

T gaat trouwens om de E4000 en E6000 Sequence, zie de Intel errata over de core2bugs
http://download.intel.com...sor/specupdt/31327914.pdf

Dit houd dus effectief in dat bijna alle Conroe proccesoren beinvloed zijn.


Van een informatieve slashdotpost

[Reactie gewijzigd door Joghert op 27 juli 2024 04:14]

[pinockio]

En Slashdot verwijst weer naar dit artikel uit januari 2006 (sic) van Geek.com:

http://www.geek.com/updat...god-theyre-full-of-flaws/

Deze bugs zijn dus al 1 1/2 jaar bekend... Bovendien bevat elke processor bugs. Toch wel vreemd dat er nu pas aandacht voor is. Mogelijk komt dat doordat nu duidelijk is geworden dat (één van) deze bugs tot een crash kan leiden...

[dangerpaki]

deja vu --> 1+1=3
herinnert iemand zich die nog???

maar zal niet zo'n heel serieus probleem zijn aangezien de meeste mensen hier niet zo'n last van hebben en er nooit echt een discussie is geweest omdat de intels overmatig zouden vastlopen.

toch mooi dat ze daar een bios patch voor uitbrengen

[stappel_]

het was meer van 1 + 1 = 2.000000000001 hoor

[humbug]

Tsja, maar als je iets weet van numerieke wiskunde weet je dat dit tot gevolg kan hebben dat uiteindelijk uit je berekening geen 0 maar 734.321.434 komt. Niet leuk als je optiekoersen aan het voorspellen bent....

Vandaar dat Intel al die CPUs moest terughalen. Het was aan het antwoord niet te zien of je CPU goed of fout gerekend had.

[Sissors]

99.99% kans dat dat niks met deze fout te maken heeft.

Denk dat je eerder naar andere oorzaken zou moeten zoeken

[Reactie gewijzigd door Sissors op 27 juli 2024 04:14]

[roy-t]

@ Pimpy en Furby-killer

kijk je services is na, spyware, hijackthislogje etc. etc. dit heeft 99.999999% waarschijjnlijk niks met je cpu te maken

(ps. een p3 doet dat ook niet 2 a 3minuten stallen, de p3 hier naast me (niet deze) loopt heerlijk soepel met win2k)