Bug in AMD Opteron kan hangend systeem veroorzaken

Op de site van The Inquirer is te lezen dat een bug die is gevonden in de AMD Opteron-processor ervoor kan zorgen dat een er mee uitgerust systeem vastloopt. De site baseert zich op een rapport dat te vinden is op 3DChips, waar ook gedetailleerd wordt uitgelegd wanneer de bug optreedt. De bug treedt op na het aanroepen van de instructie REP MOVS, waarmee meerdere bytes kunnen worden verplaatst. Als gevolg van de bug kan het voorkomen dat na het aanroepen van deze instructie de instructies die daarop volgen worden overgeslagen. Een van de gevolgen kan zijn dat het desbetreffende computersysteem vastloopt of dat er onjuiste resultaten worden geproduceerd. AMD werkt aan een fix in de vorm van een BIOS-update die het probleem zal oplossen. Bezitters van een getroffen processor worden derhalve ook aangeraden contact op te nemen met AMD.

Reacties (77)

[DukeBox]

Biosupgrade -> microcode update (voor segment 403b)

[Countess]

betekend dit dan ook dat de fout eigenlijk puur software-matig was? dus dat de fout in de "bios" van de optron zat, of zijn er echt fouten gemaakt in de hardware?

[Verwijderd]

microcode is de software van deze processor. Dus de software van de hardware. In de microcode worden bij de meeste moderne processoren veel bugs of onhandigheden later opgelost. Na de grote recall van Intel met hun Pentium-I bug hebben alle processoren nu deze optie.

Een fout in de hardware kan dus via software opgelost worden binnen in de processor zelf.

[justice strike]

microcode bestaat al sinds de ibm 360 series en is absoluut niet nieuw voor x86 processoren. ik betwijfel dat er voor de pentium 1 geen microcode gebruikt werdt.

[Makkelijk]

@justice
dat niet, maar het updaten ervan door gebruikers/winkels zelf was er in ieder geval niet..

[SCRAP]

Iedere Cisc CPU werkt met microcode en is de interne verwerking om tot een bepaalde instructie te komen. Risc cpu's werken niet met microcode omdat risc cpu's deze 'tijdrovende' verwerkingen in hardware hebben ingebakken. De instructies zijn hierbij dus direct aanspreekbaar, in tegenstelling tot Cisc cpu's.

Microcode heeft dus niet direct iets te maken met deze bug. Ook is het niks nieuws. Zoals een ander al zei, microcode wordt al sinds de jaren 50/60 gebruikt in cpu's. De Risc cpu's die het dus niet gebruiken ontstonden in de jaren 70.

[Verwijderd]

De uitvinding "risc" dateert van 1981 of 1982.

In de jaren 50, 60, en 70 dacht men voornamelijk dat door computers ingewikkelder te maken, je ze steeds meer in 1 instructie kon laten doen waardoor ze sneller zouden worden.

Begin jaren tachtig kwamen een aantal mensen op de gedachte om de kloksnelheid te trachten te verhogen, door de hoeveelheid die binnend ie klokpuls moest gebeuren te verlagen. De lol is dat je dan bijvoorbeeld 90% van de instructies versnelt en dat dit niet opweegt tegen de 10% die nu meerdere instructies nodig heeft.

Een risc processor kan wel degelijk microcode bevatten. Zo kan ik me bijvoorbeeld voorstellen dat een risc processor voor het afhandelen van een pagefault microcode heeft. Maar niet voor veel gebruikte dingen. Daar probeert zo'n ding snel mee te zijn. l

[Verwijderd]

Ehmm. Het updaten van Microcode is voor het eerst ingevoerd op de PDP 11/60 in 1975 of 1976.

Of het echt de eerste computer met field-upgradable microcode was weet ik niet, maar het artikel dat uit de krant geknipt en op de machine geplakt was claimde van wel......

Je gelooft soms niet hoe oud sommige uitvindingen zijn, nietwaar?

[hdullink]

Risc cpu's werken niet met microcode ...

Klopt, RISC cpu's werken met millicode. Dit zijn kleine veel gebruikte routines die in het gewone RAM staan. Deze routines worden gebruikt voor CISC achtige operaties, zoals vermenigvuldigen en delen.
Dit klinkt errug langzaam, maar in de tijd dat RISC werd ontworpen waren geheugens veel sneller dan CPU's. Meerdere eenvoudigere instructies waren dus sneller dan een enkele complexe instructie.

[Thandor]

Hoe willen ze dan zo'n bug oplossen via het BIOS?
De FDIV bug in de P60 kon toch ook niet via het bios verholpen worden?

AMD heeft wel mazzel dat het via het BIOS veholpen kan worden --> als al die Opteron CPU's vervangen moesten worden op kosten van AMD....dan zou het erg veel geld gaan kosten.

[Verwijderd]

Ze bedoelen de 'bios' van de opteron zelf, beter bekend als microcode. De P60 had nog geen microcode, al heeft iedereen daarvan geleerd, zodat het nu wel opgelost kan worden zonder alle procs te moeten vervangen.

[hdullink]

Alle x86 (en voorgangers, eigenlijk alle CISC processoren) hebben microcode. Deze code zit in een soort van ROM. Bij nieuwere is deze voor een deel aan te passen. Er wordt voor deze foute instructie(s) een alternatief stuk microcode aangeboden. Dit moet elke keer als de CPU wordt opgestart gedaan worden. Daarom wordt de BIOS van de PC aangepast om elke keer als de PC wordt opgestart een stukje alternatieve microcode te 'uploaden' in de CPU.

[Verwijderd]

Hoe willen ze dan zo'n bug oplossen via het BIOS?

Bijna alle moderne processors hebben tegenwoordig zgn "field upgradeable microcode" optie. Dit houd in dat je "BIOS" van de processor zelf kan upgraden net zoals je de BIOS van je moederbord upgrade.

Upgrade van microcode zijn meeste fabrikanten voorzichtig mee, als je teveel geheimen weg geeft dan kunnen mensen er wel eens misbruik van maken (virus/worm die processor verkloot). Meestal wordt de microcode van de processor geupdate via de BIOS van je moederbord, er komt een nieuwe BIOS voor je moederbord en als die ziet dat je een oude microcode hebt dan update hij die meteen.

De FDIV bug in de P60 kon toch ook niet via het bios verholpen worden?

Nee, dit vanwege 2 reden:
1. De P60 had geen upgradeable microcode.
2. Het was een hardware fout die niet of moeilijk via de microcode te corrigeren valt.

De fout zat in een datatabel die in de hardware was ingebakken (Lookup table voor de SRT deling algorhytme). De microcode fungeert als een soort van tolk tussen de gebruiker software en processor in, het vertaalt alleen de input, output en zorgt ervoor dat de processor steeds aan de gang blijft.

Om te checken of de output van de processor wel goed is via de microcode is een zeer intensieve operatie waardoor de processor zelf heelerg traag wordt. Dus al hadden ze het via de microcode opgelost dan zou je van (bij wijze van) P60 naar 386DX40 gaan, iets waar veel mensen niet blij mee zullen zijn.

De fout in de Opteron is echt microcode specifiek, waardoor een update mogelijk is.

[hardwareaddict]

De bug zit niet in de processor zelf, maar is er alleen voor supertrage verouderde instructies die de microcode (bios) aanroepen om te executen.

Dus alleen zwaar verouderde libs kunnen dat ueberhaupt doen. Vanaf 486 wordt dit eigenlijk niet meer gebruikt (zo min mogelijk that is).

Neemt niet weg dat het erg slordig is zo'n bug te hebben.

Het is dus een compatibiliteitsbug als je het zo wil zien.

[boer Krelis]

Die P60 bug was toch de reden om een updatebaarbare microcode te iplementeren?

[Thandor]

Als de Opteron dit heeft, dan moet de Athlon 64 FX het toch ook hebben (het zijn immers dezelfde procs)

Heeft de Athlon 64 hier ook "last" van?

[zeroxcool]

De Athlon 64 heeft weer een héél andere core...

[mr._Anderson]

Beide zijn op de hammer cores, en precies hetzelfde onwerp gebasseerd.

De athlon64 kan omgaan met 'normaal' geheugen wat waarschijnlijk aan een andere mem controller ligt,
en de athlon64-FX-940 is enkel en alleen een omgebouwde Opteron voor op de desktop.

De laatste 939 cpu's hebben nog wat meer optimalisaties maar de core's lijken nogal veel op elkaar
(die optimalisaties zullen de opteron's natuurlijk ook niet gemist blijven...)

[Countess]

nowja heel anders.
de "rand apperatuur " van de core (geheugen controler, L2cache, meerdere HT links) is iets ander maar de core zelf toch vrijwel het zelfde voor zover ik weet.

[hetisik]

Zoals 1 opmerking liet zien (door zo lekker dom de hoek uit te komen) kan ik best wel inzien dat veel van die zogenaamde IT specialisten die computer hardware voor de bedrijven aanschaffen nu toch heel wat minder vrolijk tegen hun amd opteron aankijken. (ook al is het probleem makkelijk verholpen).

Ik vind het zonde van zo'n mooie proccesor waar AMD nog meer mee hard aan de weg aan het timmeren was. De fout heeft nu netzoveel waarde als lucht, maar toch, menig zal het aangrijpen als 'argument' om de opteron niet te accepteren.

[hetisik]

Ik wou eigenlijk zeggen dat dit best wel eens zou kunnen en zal zorgen voor een mindere stijging in de verkopen van de amd opteron en de daar van afgeleide series. (kort samen gevat)

[Verwijderd]

@ Novardi:

Als een bedrijf zo eerlijk is om toe te geven en tegelijkertijd bezig zijn met oplossing voor het problemen, en ze nemen de kosten voor hen zelf, dan zeg ik dat het een Perfecte bedrijf is, en dat ik uitmerate te vreden ben met hun service!

Vergeet niet mensen, 60% van de grote bedrijven en ondernemers vinden Service, Alle belangrijkste en dan pas misschien de prijs etc..

Ik zie dus absoluut geen reden dat verkoopcijfers gaan dalen, aangezien men binnen no-time met een oplossing komt

[Verwijderd]

In dit argument mis ik de gevolgen van die PI bug. Toen was het ook duidelijk en tóch koos men niet voor AMD..
Waarom nu wèl AMD laten vallen? Politiek? Angst? Of zal het wel loslopen en gewoon verholpen worden?

[EaS]

Zozo.... gaan we dan straks ook de tegenhangers (Intel errata)/aanvullers (AMD errata) van dit bericht krijgen? Want voor iedereen die een beetje bekend is met de tech docs is dit bericht natuurlijk een lachertje. Ik zal alvast wat bugs in de trent van dit bericht posten:

Bug in Intel Xeon processor kan hangend systeem veroorzaken:

Processor may hang due to speculative page walks to nonexistent system memory

Processor may hang under certain frequencies and 12.5% STPCLK# duty cycle

System may hang if a fatal cache error causes bus write line transaction to occur to the same cache line address as an outstanding bus read line or bus read-invalidate line

Volgens goede tweakers traditie verwacht ik deze "nieuwsfeiten" binnenkort ook op de frontpage terug.

[Verwijderd]

deze bug in de opteron en de lijst met bekende errata van intel zijn onvergelijkbaar. waarom?

de intel errata zijn allemaal hardware gerelateerde bugs die door chipset bouwers of anderszins door hardware opgelost worden middels workarounds. deze hele lijst van intel errata is geneutraliseerd door workarounds in hardware/bios updates en tot voor kort kon precies hetzelfde aangevoerd worden voor de opteron errata lijst.

dan is er ineens het opteron REP MOVS probleem.

de opteron REP MOVS bug is puur een probleem in de k8 core. het probleem kan alleen door een microcode update van amd opgelost worden. deze microcode patch van amd is niet beschikbaar.

amd heeft sinds 2 dagen dit k8 core probleem toegevoegd aan haar erratalijst. het is een nieuw probleem en alle in het veld staande amd64 implementaties kampen met het probleem.

op dit moment kan dus bestaande x86 software op een k8 core resulteren in system-hangs of, eigenlijk veel erger, onbetrouwbare resultaten. dit is onacceptabel voor een server processor.

daarom denk ik dat het tweakers artikel wel zeker nieuwswaarde heeft en dat het 'maar intel heeft ook een lijst van errata' argument van eas geen hout snijdt.

edit:
@rbs
elke bestaande microprocessor op aarde heeft erratalists. de opteron heeft erratalists en ook de intel p4 heeft erratalists.

echter, dit REP MOVS probleem is zeer recentelijk toegevoegd aan de erratalist van amd. dat maakt het een nieuwsfeit voor tweakers. daarnaast heeft de REP MOVS bug impact op gebruikers van amd64 processoren en is er geen oplossing/workaround van amd beschikbaar.

deze feiten maken de REP MOVS bug uniek en niet vergelijkbaar met erratalists waarvan de errata geen impact hebben op gebruikers.

de situatie lijkt een beetje op de intel pentium FDIV bug van een aantal jaren geleden.

[_JGC_]

Je kunt wel zeggen dat er geen microcode update beschikbaar is, maar ik durf zowat te wedden dat de komende paar dagen veel moederbord fabrikanten met een BIOS upgrade komen met een AMD64 microcode update.
Microcode upgrades zijn niet bedoeld om door gebruikers gedownload te worden, wij krijgen toch ook niet een reference BIOS van Award omdat er een bug in alle oude award BIOSjes zitten?

Wat betreft deze bug die zo erg is: alle Intel Pentium CPUs hebben de F0 0F bug (Cyrix 6x86 had em ook), bij Cyrix kon er gewoon mbv BIOS een register omgeflipt worden en bestond de bug niet meer, bij Intel moest de bug in software opgelost worden. Ik krijg elke keer als ik mn linux machine opstart deze melding:
Intel Pentium with F0 0F bug - workaround enabled.
WORKAROUND heet dat... die zit dus ook in windows 9x/NT en is in het geval van win9x gewoon uischakelbaar zelfs. De bug houdt in dat je door het geven van de opcode F0 0F de hele CPU op kunt hangen. Hoogstwaarschijnlijk zal het OS deze instructie gewoon afvangen en negeren

[EaS]

echter, dit REP MOVS probleem is zeer recentelijk toegevoegd aan de erratalist van amd. dat maakt het een nieuwsfeit voor tweakers. daarnaast heeft de REP MOVS bug impact op gebruikers van amd64 processoren en is er geen oplossing/workaround van amd beschikbaar.

Aangezien jij dit een nieuwsfeit vind, zijn volgens jou redenatie bijna alle 'specification updates' die er op de website van Intel te vinden zijn goed voor nieuwsfeiten. Want immers:
Er zijn zeer recentelijk errata toegevoegd aan de spec.updates. van de verschillende Intel CPU's. Dat maakt het een nieuwsfeit voor tweakers.
Daarnaast hebben meerdere errata impact op gebruikers van Intel processoren en is er geen oplossing/workaround van Intel beschikbaar.
Ga namelijk maar eens zoeken hoevaak er Workaround: None at this time in die documenten staat.
De Pentium 4 debuteerde met 40 bugs, en HP heeft zelfs systemen uit de handel moeten vanwege Pentium 4 bugs.
Heeft iemand hier ooit last van gehad? Is de P4 geen succes geworden?

[Verwijderd]

Hebben we bierbuik weer hoor, altijd Intel verdedigen.

[Verwijderd]

Hoeveel zijn er wel niet die altijd AMD verdedigen.

[Verwijderd]

Interessant verhaal, maar het is nog steeds niet duidelijk waarom deze laatste bug niet vergelijkbaar is met de bestaande errata lijst.

Je zegt zelf dat Intel CPU bugs worden opgelost in de hardware of BIOS en dat is precies wat AMD doet toch?

[RetepV]

Het is goed dat je zo vaak het woordje 'KAN' gebruikt, Bierbuik. Want vooralsnog is er geen paniek, dus blijkbaar is de kans van een hanger heel erg laag.

Maar goed, wat leren we hiervan? Dat we ook de Intel bugs moeten posten als nieuwsfeit.

Het enige probleem daaraan is dat er ook bij Intel nogal wat bugs gevonden worden.

Misschien is het beter om daar een aparte site voor neer te zetten.

In de tussentijd kun je best proberen respect te vergaren, maar je komt respectabeler voor als je je waardeoordelen achterwege laat en iets objectiefs schrijft.

[Verwijderd]

was er vroeger in de PII niet ook al een "foutje"? en had er toen niemand OOIT iets van gemerkt ..

[The Jester]

Bijna alle Pentia hadden bugs.
De P1 had moeite met afronden (probleem in de 'schattingstabellen'). Die kon men slechts oplossen na een nieuwe stepping.

FF zeuren: ook sommige posters hebben een klein firmware foutje: verplaatsd schrijft men in goed Nederlands met een T (Kofschip & zo...)

[Verwijderd]

FF zeuren: Het meervoud van Pentium is niet Pentia maar Pentiums.

[Verwijderd]

Dat kon je wel merken, in Excel bvb. bekwam je bij een bepaalde bewerking verkeerde resultaten.

http://www.x86.org/secrets/dan0411.htm

[Verwijderd]

Even een leuke fact, nu je toch over de PII FIST bug begint. De software in de Ariane 5 raket had een zelfde soort bug waardoor hij 1 minute na opstijgen explodeerde.

http://www.siam.org/siamnews/general/ariane.htm

[Verwijderd]

Niet helemaal,

De Ariane 5 storte neer omdat ze code voor de Ariane 4 gebruikte. En blijkbaar zijn raketten niet backwards compatible.

[The Source]

Niets spannends, er zitten zoveel fouten in CPU's. AMD heeft tenminste nog het fatsoen om de publiekelijk op hun website te zetten, zie: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_doc s/25759.pdf

Ga er maar van uit dat er bij Intel evenveel, zo niet meer (meer transistors, meer kans op fouten) in zitten. Echter is 90% daarvan de moeite van het oplossen niet waard.

[Verwijderd]

Eh, de moeite van het oplossen niet waard? Dat klinkt dan meer alsof de hele functie niet in de CPU had moeten zitten.

[Verwijderd]

Eh, de moeite van het oplossen niet waard? Dat klinkt dan meer alsof de hele functie niet in de CPU had moeten zitten.

Je zal versteld staan hoe groot de bug databases van sommige bedrijven zijn. Zoals bij Oce, waar ze kopieraparaten maken. Hebben ze daar een bug database? Ja kijk maar, laden vol met bugreports allemaal gekwalificeerd met een lage prioriteit.

Mercedes, BMW, Audi, VW, Opel, Philips, B&R, etc. etc. etc. allemaal zelfde melodie, databases vol met bugs allemaal lage prioriteit.

Als er een bug is, is het ten eerste een afweging tussen kosten/baten. Vaak baat het niet om een bug te fixen omdat het zo insignificant is en als mensen ervan weten dan kunnen ze er makkelijk omheen. Deze bug is zo insignificant en zo extreem dat ik het voor mogelijk acht dat AMD het gewoon zo laat.

Misschien dat ze besluiten om het te fixen omdat het zo breed in de media staat (dus voor hun imago) maar dat zal hoogstwaarschijnlijk ook de enige reden zijn.

[Thandor]

Intel heeft ook bugs gehad in processoren.

http://www.x86.org/secrets/intelsecrets.htm

[nuclear waste]

Wat een flame, het is wel intel die de 64-bit techonologie laat ontwikkelen door AMD om dan zelf te kopieren en veel duurder op de markt te brenegn.

[assembler]

Oh ja?
Waarom bestaat de Itanium dan al veel langer dan de opteron? De itanium is anders ook 64 bits hoor.

[Thandor]

Is Itanium compatible met 32Bits ?...nope, het moet worden ge-emuleerd, en dat is veel trager.
Maar wat maakt het allemaal uit : De een wil AMD en de ander wil Intel. Ieder wat wils toch?

Tha Lord --> dit was reactie op assembler.

[Chatslet]

We hebben het hier ook niet over de Itanium maar over een x86-64 cpu die zowel 32bits als 64 bits kan. Intel heeft dit gekopieerd en gaat daar nu zelfs cpu's mee maken. Dat is wat hier bedoeld word/

[hardwareaddict]

Ja de itanium is x86 compatible. Het execute x86 code alleen zo supertraag dat niemand echt interesse had in die x86 compatibiliteit. Voor enige cpu intensieve code is een itanium1 en itanium2 op 800Mhz ongeveer even snel in IA32 als een 100Mhz PII.

Dit was natuurlijk gebouwd omdat intel natuurlijk grote plannen had met itanium. Later bleek het zo'n dure cpu te zijn dat deze zelfs nu nog te duur is in de highend om massaal toe te passen.

Dus al die grootse x86 plannen zijn snel vergeten van de itanium. Echter hij *kan* het wel. Ondergetekende is uw getuige.

[Yoshi]

B-merk?????????????????????????
AMD is al evenlang bezig met tegen Intel op te knokken, ze moeten vechten voor elke percent winst, al jaren, en een van de redenen zal wel zijn dat er personen als jij zijn, die dan een computerzaak ofzo hebben

het is amd die dit keer beter is, zijn waren het eerst met een excellente code, en hoor wie gaat dit kopieren, idd Intel,

het is iets dat ik haat, kunnen mensen niet normaal meer doen ofzo

[eamelink]

Natuurlijk is het een flame, maar het lokt wel interessante reacties uit

Jij doet nu weer alsof AMD zielig is. Dat is de andere kant van het verhaal.

Intel en AMD zijn gewoon allebei normale bedrijven, met beide prima spul.

Het overduidelijke "Intel stinkt, AMD roeleert maar wordt onderdrukt door de Intel monopolipositie" mag nu ook weleens over zijn.

Intel voert gewoon een beter marketingbeleid Ik zie vaak zat intel reclames langskomen overal, van AMD minder. Nou, dan is je naamsbekendheid ook minder, en word je al snel genoemd als 'B-merk'.

Om daar nou de winkeliers de schuld van te geven is flauw. Nooit van pull-marketing gehoord? Intel maakt reclame voor de consument, de consument vraagt naar Intels, de winkelier verkoopt intels.

Overigens heb ik wel een AMD, maar ik ben dan ook een tweaker, geen consument

[Verwijderd]

Intel en AMD hebben beiden een lijst van bekende bugs in hun CPU's. Sinds de P90 FDIV blamage van Intel is er nu de mogelijkheid om microcode achteraf te updaten, zodat men niet weer een hele bak CPU's moet vervangen.
Soms komen er bugs omhoog die nogal ernstig zijn, dat gebeurd overal. Maar gezien de track record van AMD tot nu toe, moet ik zeggen dat ze voor een B-merk toch hele goede CPU's maken.

[Verwijderd]

Ach man, dit is weer zo'n type wat niet snapt waar hij over praat..

een via C3, dat is een b-merk, maar AMD? Nee, dat is geen B-merk, kwalitatief is Intel dan net zo hard B-merk, minder naamsbekendheid heeft er niets mee temaken, de kwaliteit van de spullen wel. En ik moet zeggen dat ik een Athlon64 toch iets beter van kwaliteit vind dan een pentium4 en/of Xeon.

Simpelweg omdat de xeon en p4tjes van tegenwoordig veel te warm worden en per clock eigenlijk veel te traag zijn. Het te warm worden en afbrokkelen van de core, daaraan is een B-merk te zien, AMD is sinds de Athlon64/opteron op geen enkele manier nog als B-merk te omschrijven, dat was vroeger anders, ja, die best oude processortjes van AMD wilde weleens te warm worden maar die plaats neemt Intel nu lekker in.

Intel is voor mij een B-merk als ik naar de desktop processortjes kijk, Athlon64 een A-merk en de athlonXP de budget variant van AMD. op servergebied is AMD onomstotelijk beter maar jammergenoeg is Intel bekender.

Twijfels? Bedenk dan het volgende.
Waarom worden die pentium 4 dingen van tegenwoordig bijna 60% warmer dan een Athlon64?

Waarom kopieert Intel de x86-64bit extensies van AMD?

Waarom gaat intel sinds AMD's cool&quiet zo goed werkt proberen speedstep in de desktop processors te stoppen?

Waarom is nu de snelste Athlon64/FX zodanig veel sneller dan de snelste pentium4?

Waarom raden mensen met VEEL ervaring met beiden processors AMD aan?
- hierbij bedoel ik een onpartijdig persoon, geen intel freak of zo'n figuur wat alles denkt te weten zonder werkelijk te werken met dit soort systemen.

[hardwareaddict]

De bug is nogal klein hoor. We praten over code die rond het jaar 1986 geschreven moet zijn of daarvoor die dit soort onhandige assembly code gebruikt.

Zelfs assembly boeken uit begin jaren 90 kennen deze opcodes nauwelijks overigens. Executen via de bios is supertraag namelijk.

Enige wat nodig is, is een kleine update van de bios.

Dit waar intel dus hele volkeren misleid heeft met de itanium bijvoorbeeld. Al die 900Mhz en 1Ghz cpu's die zo lang de testsets domineerden zijn teruggehaald naar de fabriek.

Idemdito 933Mhz Xeons.

Over het algemeen is het echter zo dat de hoeveelheden bugs in de hardware erg meevallen.

Deze bug is eigenlijk niet noemenswaardig.

[Verwijderd]

slordig foutje. maar gelukkig komt het niet zo veel voor dat de DF op 1 staat, REP MOVSx instructies worden bijna altijd met een DF = 0 gebruikt.

[Verwijderd]

Kan allemaal best. Maar enerzijds is er het probleem dat een willekeurige student een programma schrijft wat de bug triggert en je vakgroep-server platgooit in het weekend. Anderzijds kan iemand bewust proberen om je systeem plat te gooien. Over een week is er een "crashAMD" progje van 300 bytes wat je machine plat gooit. Hoe vaak gaat je publieke server plat voordat je doorhebt dat er een student zit te zieken?

[hetisik]

Nou, omdat veel bedrijven dat dan doen voor de zogenaamde IT profesionals, zijn het de bedrijven die de inkopen voor hun doen en dus ondaks dat 'het' 'argument'niet meer geld toch minder AMD opteron zullen kopen. (al zal het verschil niet al te groot zijn inderdaad)