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

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.

Intel Core 2 Duo-bug 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.

Door René Wichers

Eindredacteur

27-06-2007 • 15:57

114 Linkedin Google+

Submitter: RdamRobin

Bron: Microsoft

Reacties (114)

Wijzig sortering
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.
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.
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)
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...
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 juni 2007 16:28]

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 juni 2007 16:55]

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?
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.
Klinkt als een moederbord probleem, niet als een CPU probleem. Het contact naar de CPU zal wel beschadigd zijn.
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.
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.
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.
Memory leaks zijn vrij simpel op te sporen. Daar hebben we tenslotte profilers voor :)
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 juni 2007 16:40]

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.
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.
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.
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.
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...
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.
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 juni 2007 16:27]

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True