Hoofdcategorieën

Bug in Intel Core 2 Duo aan het licht gebracht

Door René Wichers, woensdag 27 juni 2007 15:57
Bron: Microsoft, submitter: RdamRobin, views: 49.475

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.

Volgende 16:09
Vorige 15:43

Reacties

«  1  2  3  4  5  »

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


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.

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)

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?? _/-\o_

Ik zou gaan solliciteren bij HP als ik jou was!

Of iets aan de echte oorzaak doen?

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 :)

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

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.

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.

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



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

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.

"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 Q-t op woensdag 27 juni 2007 16:26]


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.

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 woensdag 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.

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

Hoe kan je nou een bug testen? :?

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.

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. )

edit oops, foutje. sorry.

[Reactie gewijzigd door iceheart op donderdag 28 juni 2007 01:11]


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

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...


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.

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....

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


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 :)

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


idd staat ook in het gelinkte KB artikel
A microcode reliability update is available that improves the reliability of systems that use Intel processors.

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

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

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).

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

het was meer van 1 + 1 = 2.000000000001 hoor

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.

@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 ;)

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.

Hoe lang is dit al bekend en is er een relatie met de prijsdalingen van laatst?

nieuws: 'Intel verlaagt prijzen al in juli'

[Reactie gewijzigd door videodok op woensdag 27 juni 2007 16:06]


Die relatie is er niet, als de cpu echt zo slecht zou zijn zou er een recall gedaan worden en geen prijsverlaging, dan kun je beter je prijzen later verlagen zodat mensen pas later op je product overstappen. Hierdoor is de kans groter dat ze op een mobo geprikt worden dat al een correcte bios heeft ;)

Als daar een relatie zou zijn dan zou ik dit niet via nieuwsbericht lezen maar dat mijn pc wel eens vastloopt (wat dan bijna nooit gebeurd)

Bugs in processors, doet me denken aan de befaamde Reken-bug van de Pentium.

Hoe lang hebben ze gedaan om deze bug op te merken?
Te snel willen introduceren, dan krijg je deze bagger/bugs

Hoogmoed komt ten val Intel! 8)

Vertel eens over die rekenbug?

Laten we nu niet de Nederlandse taal gaan verkrachten he ;)

Hoogmoed komt voor den val :P

Is kijken hoeveel overbodig ik krijg .... give me the candy

*16:31
Hap hap hap ... ... sorry te veel meel op.

[Reactie gewijzigd door vinnux op woensdag 27 juni 2007 16:32]


Ook jij gaat de fout in...

"Is kijken hoeveel overbodig ik krijg" moet zijn:
"Eens kijken hoeveel overbodig (stemmen) ik krijg"

Ik zou stemmen er in zetten, is duidelijker, maar het openingswoord is je grootste fout.

Hoogmoed komt voor DE val... Als je wilt corrigeren, doe het dan tenminste wel goed.

Moet je deze link even aanklikken staat het kort uitgelegd.
http://nl.wikipedia.org/wiki/Pentium

of deze iets uitgebreider maar dan in het Engels
http://en.wikipedia.org/wiki/Pentium_FDIV_bug

En weer wordt er door Intel in eerste instantie niets aan gedaan.

Te laat, moet sneller zoeken en typen

[Reactie gewijzigd door T.C op woensdag 27 juni 2007 16:25]


Er word nagenoeg tegenwoordig veel minder uitgebreid getest dan vroeger, men zoekt steeds meer naar een gulden middenweg, testduur tov. economisch belang.

Het is jammer dat alles loopt zoals het nu loopt, en daar bedoel ik mee dat er eerst Longhorn was, toen Vista, toen het besluit van om Vista van scratch weer op nieuw op te bouwen, de gepaard gaande indtroductie van de dual core cpu's en het snelle verschijnen van Nvidia's DX10 kaarten, waarvan steeds veel mensen nog problemen hebben/gehad omtrend de drivers.

Tel daarbij op de zogenaamde Vista ready progamma's of oudere software waarvoor een Vista ready patch/update verscheen heeft ook menigeen de mogelijke hoofdbrekens gegeven.

Ben zelf nu ook met Vista bezig en merk nog steeds dat diverse software niet lekker loopt, waaronder NIS2007 en nog steeds geen software update voor een HP laser printer, die er imho allang had moeten zijn. Misschien alles bij elkaar toch een beetje overhaast door de bedrijven :O

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.

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.


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 furby-killer op woensdag 27 juni 2007 16:27]


@ 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)
«  1  2  3  4  5  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:09
Vorige 15:43
VNU Media logo Hosted by True

© 1998 - 2009 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van: