Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Core » Hardware » Bug in AMD Opteron kan hangend systeem veroorzaken

Bug in AMD Opteron kan hangend systeem veroorzaken

Door Martin Sturm, zaterdag 19 juni 2004 20:47
Bron: The Inquirer, views: 16.394

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.

AMD Opteron
Volgende 22:12 Brein stelt rechtszaak tegen Dvdstream uit
Vorige 20:00 IBM biedt MessageLabs' e-mailfilters aan
Advertentie

Categorieën

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 77 reacties zichtbaar770 Off-topic / Irrelevant: 70 reacties zichtbaar70+1 On-topic: 53 reacties zichtbaar53+2 Informatief: 20 reacties zichtbaar20+3 Spotlight: 3 reacties zichtbaar3
«  1  2  3  »

Door DukeBox, zaterdag 19 juni 2004 20:51

Score: 3
Biosupgrade -> microcode update (voor segment 403b)

Door Countess, zondag 20 juni 2004 00:25

Score: 1
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?

Door vincento, zondag 20 juni 2004 01:03

Score: 2
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.

Door justice strike, zondag 20 juni 2004 01:44

Score: 3
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.

Door Makkelijk, zondag 20 juni 2004 10:37

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

Door SCRAP, zondag 20 juni 2004 12:39

Score: 2
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.

Door Rogier Wolff2|IA, zondag 20 juni 2004 21:30

Score: 1
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?

Door Rogier Wolff2|IA, zondag 20 juni 2004 21:36

Score: 2
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

Door hdullink, maandag 21 juni 2004 10:59

Score: 1
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.

Door Thandor, zaterdag 19 juni 2004 20:51

Score: 2
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.

Door Laphroaig, zaterdag 19 juni 2004 20:59

Score: 2
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.

Door hdullink, zaterdag 19 juni 2004 23:01

Score: 3
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.

Door boer Krelis, zaterdag 19 juni 2004 21:00

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

Door hardwareaddict, zondag 20 juni 2004 18:09

Score: 1
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.

Door SizzLorr, zondag 20 juni 2004 22:55

Score: 2
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.

Door de_nille, zaterdag 19 juni 2004 20:52

Score: 0
spijtig
zijn nochtans zo goede beestjes

Door Thandor, zaterdag 19 juni 2004 21:26

Score: 2
Intel heeft ook bugs gehad in processoren. ;)

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

Door nuclear waste, zaterdag 19 juni 2004 21:30

Score: 0
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.

Door assembler, zaterdag 19 juni 2004 21:44

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

Door Thandor, zaterdag 19 juni 2004 21:50

Score: 1
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.

Door Chatslet, zaterdag 19 juni 2004 21:51

Score: 1
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/

Door hardwareaddict, zondag 20 juni 2004 18:11

Score: 1
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.

Door OMX2001, zaterdag 19 juni 2004 21:41

Score: 1
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.

Door Sleep0rz, zondag 20 juni 2004 22:00

Score: 0
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.

Door white modder, zaterdag 19 juni 2004 21:44

Score: 0
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

Door eamelink, zaterdag 19 juni 2004 22:02

Score: 2
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 8-)

Door hardwareaddict, zondag 20 juni 2004 18:18

Score: 0
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.

Door butje, zaterdag 19 juni 2004 21:04

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

Door Cyberblizzard, zaterdag 19 juni 2004 21:05

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

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

Door The Jester, zaterdag 19 juni 2004 21:39

Score: 2
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...)

Door blaatdwaabje, zondag 20 juni 2004 21:11

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

Door SizzLorr, zondag 20 juni 2004 23:07

Score: 1
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

Door Pietje Puk, maandag 21 juni 2004 20:38

Score: 1
Niet helemaal,

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

Door DynamicDuo, zaterdag 19 juni 2004 23:34

Score: 0
Zullen wij dan maar niet over jouw staat van dienst praten dan? 8-)

Ik wist niet eens dat er een kwalificatie "faalhaas" bestond binnen Tweakers.

Door The Source, zaterdag 19 juni 2004 21:46

Score: 0
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.

Door rbs, zondag 20 juni 2004 11:12

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

Door SizzLorr, maandag 21 juni 2004 00:05

Score: 1
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.

Door Thandor, zaterdag 19 juni 2004 21:52

Score: 2
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?

Door zeroxcool, zaterdag 19 juni 2004 23:45

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

Door Countess, zondag 20 juni 2004 00:18

Score: 1
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.

Door mr._Anderson, zondag 20 juni 2004 16:35

Score: 2
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...)

Door Timfonie, zaterdag 19 juni 2004 22:06

Score: 0
Psst, gauw even die d in een t veranderen (verplaatst) ...
Zodra dat gedaan is, mag je dit bericht wel omlaag modden.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 22:12 Brein stelt rechtszaak tegen Dvdstream uit
Vorige 20:00 IBM biedt MessageLabs' e-mailfilters aan
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011