Eerste Pentium D 900-chips geplaagd door Speedstep-bug

De net uitgebrachte Pentium D 900 heeft last van beestjes, bericht TechReport. De gebruikte Presler-core, die zoals verwacht nog niet is uitgerust met een volledige Speedstep-implementatie, blijkt niet goed overweg te kunnen met Enhanced Halt State- en EIST-instructies. Hoewel de desbetreffende functionaliteit pas vanaf een volgende stepping, die in het tweede kwartaal van dit jaar moet verschijnen, toegevoegd zou worden, kunnen de chips deze instructies wel te verwerken krijgen als een moederbord probeert om de kloksnelheid van de processor tijdelijk omlaag te schroeven. Uit een pdf'je op de site van Intel blijkt nu dat de processors vast kunnen lopen als ze deze instructies voor hun kiezen krijgen.

Hoewel de Presler beter uitontwikkeld zou moeten zijn dan voorganger Smithfield, wat naar verluidt een haastig inelkaar gezet werkstukje was, loopt Intel opnieuw tegenslag op in de race met de dualcores van AMD. Volgens TechReport zou een bios-update echter genoeg moeten zijn om computers tegen de nieuwe bug te beveiligen, en hebben de problemen niet de potentie om uit te groeien tot de marketingramp die de Intel in 1994 trof, toen de oorspronkelijke Pentium rekenfouten bleek te maken.

Reacties (56)

[Verwijderd]

Nooit ergens van de eerste exemplaren aanschaffen blijkt maar weer eens te gelden. Geduld is een stabiele zaak!

[Thandor]

Nee, de fabrikant had het uitvoering moeten testen alvorens het product op de markt te brengen

[TD-er]

Dat testen doen ze dus kennelijk ook wel, alleen zijn ze vergeten die test-instructies weer uit te zetten in deze stepping

[McChouffe]

Waarom steekt Intel instructies in een CPU die officieel niet horen te werken?

[Verwijderd]

Omdat deze instructies het mogelijk maken deze 3,6ghz nog enigzins koel te houden.
En omdat de consument graag een Pentium & een hoge kloksnelheid wil, dit staat namelijk voor goed, snel en betrouwbaar Wat in de pentium3-tijd ook waarheid was.

[The Merovingian]

Nou vergis je je toch, het was niet de fout van Cool & Quiet zelf maar van de driver die de kloksnelheid opschroeven moest.
Dit programma gebruikt de processor zelf (natuurlijk) om de snelheid te verhogen, maar als de processor 100% gebruikt wordt is die bezet en kun je hem niet op tijd op een hogere snelheid zetten.
Vanwege de multitasking laat Windows de driver namelijk gewoon even wachten, terwijl die driver juist tijd vrij had kunnen maken. Heeft alles met threads en prioriteiten te maken.

[Verwijderd]

Punt is dat ze er niet inzitten maar sommige biosen per ongeluk denken dat ze wel aanwezig zijn.

[Verwijderd]

Ja en dat komt omdat intel de mobomakers heeft aangestuurd om deze instructies door de mobo's te laten ondersteunen.

[catfish]

... omdat volgende generaties het wel gaan kunnen

ze zouden beter een soort register in dechips beginnen bakken waar de ondersteunde instructies in staan, zo kan elk mobo met een universele bios bepalen wat kan en wat niet kan

een bug zou ik het niet noemen, eerder een onhandig iets

[DeArmeStudent]

Misschien omdat ze de uitdrukking: "steek die instructies maar ergens waar de zon nooit schijnt!" een beetje erg serieus genomen hebben?

[cyberjunk]

Dan ben je er volgens mij toch beter af met een AMD Athlon 64 processor, ze mogen dan wel iets langzamer zijn maar ze zijn wel betrouwbaar

Edit: ik bedoelde dat AMD procesoren een langzamere klok snelheid hebben vergleken met intel processoren

[Verwijderd]

Langzamer?

Het is toch niet omdat de CPU clock minder snel is, dat hierdoor de hele computer trager is.
Ik denk dat er genoeg benchmarks op internet beschikbaar zijn die net het tegenovergestelde bewijzen.

Over het topic...Het lijkt me dat er een communicatieprobleempje is geweest tussen Intel en de moederbordfabrikanten.

Johan

[dtech]

waar haal je vandaan dat ze langzamer zijn? dat hangt van het model af, qua prijs krijg je over het algemeen zelf nog iets meer prestatie bij AMD als bij Intel

[Verwijderd]

allemaal afhankelijk van de apps die je gebruikt... over het algemeen(!) is AMD sneller in gaming, maar Intel sneller wat betreft aanmaken van files, converten (ligt erg dicht bij elkaar though), en dat soort dingen... de CPU die je kiest is dus afhankelijk van wat je met je rig doet...
tot hier mijn offtopic mening...

[Andros]

En ze zijn zelfs nog sneller ook...

[Darkprince1234]

En goedkoper;)

[gyjo]

En koeler

[sniek]

Langzamer? Qua kloksnelheid wel ja, maar wanneer je de prestaties vergelijkt ontlopen ze elkaar nauwelijks.

Zelf draai ik zowel Intel als AMD systemen. Ik moet toch eerlijk zeggen dat ik over de AMD meer tevreden ben en die dan ook als Game rig gebruik.

[Reinstein]

Dus met een bios update is het te verhelpen, maar als je nou een programma schrijft die die instrunctie uitvoert, dan gaat het dus als nog mis. of begrijp ik het nou verkeerd

[BasHouse]

Dat begrijp je verkeerd. Die BIOS-update zal er voor gaan zorgen dat die instructie -door welk programma dan ook aangeroepen- niet meer uitgevoerd zal worden.

[_JGC_]

Tegenwoordig wordt er met microcode updates gewerkt. Een bugje als dit in de CPU oplossen is niets anders dan een microcode update beschikbaar stellen die de moederbordfabrikant in de BIOS integreert.
Op het moment dat de PC gestart wordt, wordt er een microcode update gedaan op de CPU waardoor de gewraakte instructie gewoon genegeerd wordt. Het zit dus niet specifiek in de BIOS, maar gewoon in de CPU. Als het echt in de BIOS gezeten had, was het gewoon te omzeilen geweest, 99% van de dingen die windows en linux doen gaan gewoon buiten de BIOS om.

[daft_dutch]

microcode hoeft niet in de bios worden geplaast.
deze kan je ook on the fly in je cpu laaden. met een programatje. mijn P4 spingt tijdens het booten van linux van versie 9 naar 12.
Ik heb geen idee wat de aanpassingen zijn maar ach.

[TheCapK]

Kortom: die functie is hoe dan ook niet te gebruiken op deze (ook weer te haastig uitgebrachte) Pentium Dual Core!

Wat was de nieuwe slogan ook al weer?
Intel Leap ahead? Eerder stepping down!
Way to go Intel!

[dutchguy]

Beetje jammer. Ik snap wel dat ze graag nieuwe processoren willen uitbrengen maar toch vind ik dit wel slordig van Intel.

[ocdaan]

Tsja, je kan het ook van de andere kant bekijken, als Intel aangeeft dat die functionaliteit nog niet aanwezig is (of nog niet officieel iig) en de mobo makers dit niet goed in de bios verwerken, dwz dat het bios toch probeerd te steppen kan Intel er ook weinig aan doen. Maar idd had Intel dit moeten opvangen.

[Evil_Ed]

Maar als je als moederbord / biosbakker alles moet gaan disablen wat (nog) niet ondersteund word krijg je wel een hels karwei.
Is alsof je bij het inloggen op een computer een wachtwoord invult en de machine gaat kijken of het wachtwoord voorkomt in een lijst met niet goede wachtwoorden ipv vergelijken met het juiste wachtwoord.
aangezien je een triljard foute wachtwoorden kunt bedenken kan het effe duren voordat ie zou zeggen dat het niet het juiste wachtwoord is.

Dus als een familie processoren een instructie reeks aan boord heeft moet het niet zo zijn dat omdat de productie niet lekker is dat er voor elk type afwijke zaken geregeld moeten worden.
Als deze CPU dit niet (fatsoenlijk) ondersteund dan hoort de CPU dergelijke instructies te blokken.

just my 2cts

/edit : typo gewijzogd

[Wouter Tinus]

Maar als je als moederbord / biosbakker alles moet gaan disablen wat (nog) niet ondersteund word krijg je wel een hels karwei.

Het controleren van de ondersteuning voor EIST is een kwestie van één bitje uitlezen, iets wat sowieso moet gebeuren omdat ook in de 90nm Pentium D-serie niet alle chips deze techniek aan boord hebben. Dat sommige BIOS-programmeurs blijkbaar geen of de verkeerde controle uitvoeren is gewoon slecht, en daar wordt nu dus zowel de consument als Intel (vanwege de negatieve aandacht) de dupe van.

Als deze CPU dit niet (fatsoenlijk) ondersteund dan hoort de CPU dergelijke instructies te blokken.

Dat kun je als hardwarebouwer niet maken: de software gaat er namelijk wél vanuit dat zijn opdrachten worden uitgevoerd, en je kunt dus hele programma's in de soep laten lopen door instructies botweg te 'blokken'. Een CPU moet in het geval van een illegale instructie gewoon een exception genereren, en dat dat vaak tot een crash leidt is dan jammer, maar beter dan corrupte data of berekeningen.

[Verwijderd]

Zoals je zelf aan aangeeft is het een beetje een kip en het ei verhaal. Sommige moederborden sturen niet ondersteunde opdrachten naar de chip met als gevolg dat de chip crasht.
Volgens mij is het onmogelijk voor intel om alle potentiele fouten van biosfabrikanten op te vangen. Je kan de "schuld" dus net zo goed bij de moederbordfabrikanten leggen. Maar uiteindelijk is het gewoon een kwestie van een nieuw bios om je systeem werkend te krijgen. Niets bijzonders.

[.oisyn]

Nee, de chip voldoet gewoon niet aan de specificatie. Het is natuurlijk van de zotte dat een CPU crasht als je 'm een verkeerde instructie geeft die hij niet snapt, dan is het voor een applicatie wel heel makkelijk om het hele systeem omlaag te halen. Nee, in plaats daarvan hoort er gewoon een illegal instruction exception op te treden wat het OS weer af kan vangen, terwijl de CPU in perfect gedefinieerde staat verder kan werken. Hij zou te nimmer moeten crashen.

[HaterFrame]

Ik snap idd dat Intel niet achter wil raken maar dat betekend natuurlijk niet dat men met half werk op de proppen moet komen. Ze lopen gewoon achter, laat ze dan wat langer wachten en dan een goed stabiel product op de markt brengen dat zich kan meten aan de concurent. Dat doen ze al een hele tijd niet meer

[Verwijderd]

Ik zal mezelf even quoten:
* 786562 inn87
* 786562 inn87
* 786562 inn87
.

Ik vindt het dan ook erg achterlijk dat dit gewoon zomaar kan... Een processor met een bug breng je toch niet uit? Brand dit ding overigens niet gewoon door zonder deze mooie functie?

[Verwijderd]

Hoewl het vragen om een flamewar is toch maar reageren.

1) Een Intel verbruikt meer dan een AMD. Maar de extra stroomkosten zijn niet zo hoog dat je daar echt wakker van moet liggen. Een 60Watt gloeilamp is erger voor je stroomrekening. Daarnaast verbruikt deze processor minder dan oudere intel Pentium 4 modellen. Intel wordt dus gewoon steeds efficienter qua stroomverbruik (maar blijft slechter dan AMD)

2) Als dat ding onder een bepaalde temp blijft kan die sneller lopen. Wordt de temparatuur te hoog klokt de chip zich terug om te zorgen dat de chip het overleeft. Of je continue 3.6 GHz haalt is dus sterk afhankelijk van de koeling. Maar als je koeling niet in orde is blaas je in ieder geval je CPU niet op. Dus kies maar: Een oververhitte CPU die iets sneller draait of een CPU die zichzelf (en jou investering) beschermd maar zich terug moet klokken doordat jou systeem niet goed genoeg gekoeld wordt.

3) Als je betaald voor een 3.6 én voor een goede koeling zorgt heb je dus geen probleem.

4) Het is geen bug in de processor. Op zijn hoogst kun je stellen dat Intel de bugs in de biosen had moeten voorzien en een wat nettere foutafhandeling had moeten verzorgen. Maar misschien kan dat helemaal niet bij alle moederborden.

5) Nee, hij brand niet door. De chip ondersteund geen EIST, wel andere speedstep functionaliteit.

[Ruuddie]

Het is trouwens doodgewoon dat er bugs in processors zitten, dat loopt tegenwoordig bijna standaard in de tientallen (ja, ook bij AMD).

Niets is bugvrij, dat weten we inmiddels wel. Maar een bug waarvan je hele pc crasht vind ik dan weer een beetje te veel van het goede.

Wel grappig om te zien dit: Als er een klein bugje wordt gevonden in Windows ligt iedereen te zeiken, maar nu wordt er een flinke bug in een processor gevonden, en dan is het van 'ja, ze moeten gehaast werken, en niets is bugvrij, en anders zou het weer maanden geduurd hebben'.

[Wouter Tinus]

Een processor met een bug breng je toch niet uit?

Een relatief onbelangrijke bug in EIST is voor Intel geen reden om een nieuwe processor vier tot vijf maanden uit te stellen (want zo lang duurt het om een nieuwe versie de deur uit te krijgen), en al helemaal niet als er voor miljarden dollars aan 65nm-apparatuur is gekocht die zo snel en veel mogelijk gebruikt moet worden om de investering terug te verdienen.

Het is trouwens doodgewoon dat er bugs in processors zitten, dat loopt tegenwoordig bijna standaard in de tientallen (ja, ook bij AMD).

[Noel]

@ P Puk:

1) Niet zozeer het verbruik, maar de extra warmte en het daarbij verhoogde geluidsniveau + extra investeringen in koeling, zijn eerder de problemen voor veel mensen/systeembouwers.

2) Als je 3.6GHz koopt moet je die gewoon 24/7 ter beschikking hebben. Terugklokken is alleen voor extreme situaties (lees: koelblok/fan vergeten/kapot).

3) Je betaalt bij Intel voor een 3.6GHz mét boxed koeler. Als je dan nog problemen hebt, is er duidelijk iets mis met die combinatie. Extra betalen, tja, niet iedereen wilt nog eens 50€ bijleggen voor casefans/fancontrollers/etc...

4) Meer testen. Betere communicatie met fabrikanten.

[Knobby]

hoe ging die uitdrukking ookal weer? "Nobody got fired for buying Intel"

[empheron]

Bij mij komt het er, ondanks zeurende gebruikers die denken er iets vanaf te weten, niet meer in.

Bovendien heb ik, door dalende TCO en energierekening, ook het management achter me staan. Gewoon Semprons dozen aanschaffen voor Office werkplekken.

Moet er overigens niet aan denken dat ik op een x-aantal werkplekken BIOS updates moet gaan draaien omdat Intel er een zooitje van maakt.

[memphis]

Een beetje bedrijf loopt met hard- en software altijd achter op de nieuwste technologiën dus hoef je niet bang te zijn dat je een erg buggy werkomgeving krijgt vanwege dingen die eigenlijk nog in Beta stadium staan.

[jp]

Bij een bedrijf zijn dat soort dingen het probleem van de leverancier (HP ofzo), of wou je op je werk zelf je machine in elkaar knutselen? ben je qua tijd meer aan kwijt dan de paar tientjes die je verdient op aanschaf.....

[alt-92]

Maar je kan wel bij dezelfde leverancier een keuze maken voor machines met een lager energieverbruik door een non-Intel processor te kiezen.

[Verwijderd]

Intel heeft in ieder geval een lesje van -$475 miljoen geleerd met die bug van 1994 dus ze zullen deze bug snel hechten. Die bug van 1994 was trouwens niet noemenswaardig want het werd berekend dat een gemiddeld spreadsheet gebruiker de bug 1 keer in 27000 jaar zou kunnen treffen. Maar ja, het verhaal liep uit de hand toen intel niet bereid was om zo'n bug te willen hechten en intel moest uiteindelijk alle verkochte computers voorzien van een nieuwe bugloos CPU.

Ik vraag me af hoe vaak deze bug voor zou kunnen komen voor een gemiddeld computer gebruiker?

[Verwijderd]

Een gemiddelde gebruiker ja. Iemand die de functie op een bepaalde wijze aanriep had 100% kans op afwijkingen. Doorrekenen met die uitkomsten deed de rekenfout exploderen.

Het gevolg was dat je geen enkele serieuze floating point berekening meer kon vertrouwen, tenzij je het met de hand, of een andere computer, ging zitten narekenen. Maar daar had je nou net die pentium pc voor. Die CPU was dus 100% ondeugelijk voor wiskundigen aangezien elke uitkomst onbetrouwbaar was. Je zou maar net de krachten die op een brug staan aan het berekenen zijn en de bug tegenkomen ....

[TheCapK]

Ze moeten er gewoon voor zorgen dat hun CPU's doen wat ze moeten doen zonder fouten!
Dat is dus weer het voordeel van de AMD productietechniek: Zodra zo'n fout wordt geconstateerd wijzigen ze gewoon iets in de productie waardoor zoiets niet kan gebeuren! En dat terwijl de productie bezig is!

[Verwijderd]

En als je een cpu maakt zal je em eerst moeten testen ipv dat ie al word geproduceert. Heb je duizenden mislukte cpu's, waste of money.

Maar ze gaan steeds hoger en hoger en hoger, terwijl de snelheid niks uitmaakt.
En een AMD64 3000+ ownt al een Pentium 4 670 (of een ander cijfer) 3,8 GHz
AMD64 is veel goedkoper etc. just call something.

Daar moet intel toch ook wel wat aan schroeven, en die bug die ze hebben gemaakt is zielig

[Dexter]

Wanneer probeert een moederbord om tijdelijk de kloksnelheid omlaag te zetten? Zijn dat van die opties (energiebesparend etc.) die je met bepaalde software/utiltities aanstuurt? Of gaat het moederbord daarin zijn eigen gang?

[DaTuX]

kep een 950 cpu hiero maar wat een traag ding
ik denk dat ze dual core race niet gaan winnen op deze manier (hoeft van mij ook niet )

(mening is vastgesteld met een nieuw intel mobo de D945Pvs en 2x 512 kingston modules )

[Dexter]

Hoezo traag ding? Vergeleken met AMD X2? Of waarmee dan wel?

[Left]

Maar wat moet een processor dan wel doen als hij een instructie moet uitvoeren die hij niet kent? Op zijn minst moet hij een exceptie genereren en dat vindt je OS ook niet leuk.
Ik vind dit een beetje een sensatie verhaal.