Prefetch bug in Sun UltraSparc III processor

News.com meldt dat Sun een bug heeft ontdekt in de hardware prefetch pipeline van de UltraSparc III processor. Volgens Sun kan de bug resulteren in mogelijke data corruptie bij het uitvoeren van floating-point instructies met een ingeschakelde prefetching pipeline. Het probleem doet zich voor bij een beperkt aantal van de tot nu toe verkochte Sun Blade 1000 workstations. Sun heeft inmiddels een patch uitgebracht waarmee het probleem wordt verholpen door het uitschakelen van de hardware prefetching functionaliteit. Dit heeft als bijkomstig gevolg een performance-daling van 15% in de SPECfp2000 benchmark. De na 13 maart geleverde Blade 1000 systemen zijn reeds voorzien van de patch. De bug heeft geen betrekking op de nieuwe Sun Fire servers die vorige maand werden gelanceerd:

The problem affects only initial models of the Sun Blade 1000 workstation, one of the first computers based on the critical new design from the Palo Alto, Calif.-based company, spokeswoman Kasey Holman said.

Though Sun is distributing a program that fixes the problem, the patch disables a feature of the chip and thus cuts computer performance under some circumstances, Holman said.

[...] "I don't think it looks good for them, obviously, but I don't think this is going to have too much bearing on new product sales" because Sun appears to have the problem in hand, said ARS Market Intelligence analyst Steve Greenberg.

Reacties (30)

[Ralph Smeets]

Zoals jullie in m'n profile kunnen zien, werk ik in de microelectronica wereld. Om precies te zijn bij STMicroelectronics. Ik ben werkzaam binnen de verificatie. Dat wil zeggen, ons team probeert bugs in het design te vinden door het schrijven van testen en het runnen van simulaties.

Een van mijn specialiteiten is code-coverage. Elke chip wordt namelijk beschreven in een of ander taaltje (VHDL of Verilog meestal) en daarna gesimuleerd. Code Coverage wordt gebruikt om te kijken of alles wat beschreven is, ook getest is. Heb je dus voor alle lijnen code 'n test, dan weet je dat je alles test. Echter, het probleem is dat je niet weet of je onderdeel a voor onderdeel b test of visa versa!

Het simuleren van 'n CPU gaat op 'n snelheid van ongeveer 10Hz. Dus om 1 milioen instructies te runnen (wat normaal gesproken bij 'n 1 Ghz proc in 0.1 sec is gebeurt), heb je 100 000 sec. op 'n software simulator nodig (28 uur).

Als 'n proc 100 instructies heeft en twee 32 bits status velden, dan zijn er 100*100*2^32*2^32 = 184E21 verschillende states mogelijk. Dit komt overeen met ongeveer evenveel instructies. Bij 10Hz heb je dus ongeveer 584E12 jaar nodig om de proc 100% uit te testen......

Het is dus onmogelijk om 'n processor voor 100% onder alle mogelijke omstandigheden uit te testen!

[Wouter Tinus]

Waarom is het simuleren zo traag? Voor zoiets belangrijks kan men toch wel een supercomputer(cluster) neerzetten? Code-coverage is misschien een goede methode om individuele processors te testen op productiefouten, maar werkt het ook wel zo handig voor het valideren van een ontwerp? Ik neem aan dat een groot aantal zaken ook via wiskundige methoden aan te tonen zijn.

[Verwijderd]

testability is inderdaad een heel moeilijk issue binnen de hedendaagse microëlektronica. Gelukkig zijn er wel verschillende handige routines ontworpen om het testen van standaard µ-processoren te vereenvoudigen. Het probleem met VHDL en Verilog simulaties blijft echter dat op transistor niveau de simulaties dikwijls tot onoplosbare algoritmen leiden. Dit zorgt voor niet uit te voeren simulaties.

[Initial G]

Zullen wel wat kopjes gaan rollen bij Sun, wat een stomme fout!

[Verwijderd]

Lijkt me niet zo'n stomme fout, net als met software (ik noem zeker geen namen) komen er ook in hardware bugs voor, en soms zien ze gewoon niet zitten na uitgebreide testen terwijl ze na het uitbrengen van de processor opeens op een fout gewezen worden of er zelf alsnog achterkomen. Op dat moment vind ik het niet meer dan logisch dat dat netjes gemeld wordt en er een oplossing wordt aangeboden zoals dat nu het geval is.

Ze hoeven trouwens soms niet eens zo'n rigoreuze patch toe te passen, nu wordt er een compleet onderdeal van die processor eruit gehaald, soms volstaat een kleine aanpassing van de kernel van een os, dit verschilt natuurlijk van fout tot fout

[Verwijderd]

Dat is zo, maar bij software kunnen ze met bugfixes een onderdeel vernieuwen van een programma en bij deze processor slopen ze het hele onderdeel eruit waardoor je minder performance hebt!

[gridfox]

Een gemiddelde Sun Blade 1000 kost zo'n Hfl. 60.000,-. De Blade 100 is het 'simple desktop dingetje'. Overigens is de Blade 1000 een midi-tower model en wordt niet als server ingezet, maar eerder als zwaar ontwikkel/grafish werkstation.

Ik betwijfel of grote organisaties als ABN direct op nieuwe machines gaan draaien. Deze zullen eerst uitvoerig getest worden. Waarschijnlijk zijn dit ook de omstandigheden waarbinnen de bug naar voren is gekomen.

[P5ycho]

Bij de eerstvolgende stepping wordt zoiets meteen gefixt hoor... jah, ik zou liever de boel iets trager hebben dan last hebben van datacorruptie... wat jij?

[Verwijderd]

Ik zou mijn geld terug willen! Die SUN systemen zijn volgens mij best wel heel erg prijzig en voor dat geld wil ik een goed systeem.

<font color=#786562>* [fth]melkpap denkt dat Sun nog wel wat claims zal gaan krijgen</font><div class=r>[Reaktie gewijzigd door [fth]melkpap]</div><!-- end -->

[RvdH]

Die Sun Blade is "maar" $999 als ik me niet vergis, en vergeleken met een dergelijk x86 systeem is dat niets duurder, misschien zelfs wel goedkoper.

Neemt natuurlijk niet weg dat het erg minder is, als je zo'n ding hebt staan met de bug.

* 786562 RickJansen

[bille]

Hallo! je koopt een proc. van 2000piek+ en dan zit er een fout in die ze minder dan 1 maand daarna eruit halen. Sorry hoor, maar dat is toch wel ernstig fout!

Stel je voor: ABN koopt een paar honderd van die procs. voor hun nieuwste bankingservers. Als die dingen uitvallen kost het ze minstens 100.000 piek per seconde!!! aan overschrijvingswinst e.d. (EN DAT IS GEEN GRAP, als het netwerk van ABN plat ligt langer dan zijn ze binnen 24 uur "out-of-business")

Die krengen draaien net 2 weken en de heleboel gaat down. Je koopt toch niet voor niks een SUN ?? Een foutje in software is wel wat anders dan een foutje in hardware, zeker als het om een dergelijk grote fout gaat. Als de nieuwste drivers van NVidia een foutje bevatten is het de volgende dag opgelost en de dag daarna heeft iedereen de nieuwste drivers. Zo werkt dat in hardware land niet. Zeker niet voor grote bedrijven die niet 100 maar 10.000 van die CPU's kopen.

[demonite]

maar een sun blade 1000 is maar een simpel workstation dingetje...

geen dikke server waar ABNamro hun spullen op laten draaien...

[KeX]

Uitvallen is natuurlijk wel een paar stappen verder. Prefetching pipelining is is slechts een mechanisme dat snelheidswinst boekt door het voorspellen van de informatie die de chip nodig heeft zodat te verwerken gegevens in een 'wachtrij' gezet kunnen worden. Dit heeft betrekking tot mathematische handelingen die in het geval van de ultrasparc III bij floating point operaties fouten op kunnen leveren. Dit zal slechts in heel weinig gevallen voorkomen. Geen enkele van de klanten heeft tot nu toe fouten ontdekt (itt destijds met de floating point bug in de PI 60). De Ultrasparc III zal wat betreft de genoemde ABN servers geen problemen opleveren daar voor server werkzaamheden dit soort complexe berekeningen nauwelijks plaats hoeven te vinden.

The computing jobs typically handled by servers don't involve as much mathematical calculation, so server performance won't be affected as much.

En na de patch zal dus de performance verslechteren. Aangezien geen van de customers zelf iets gemerkt heeft en Sun bij eigen testen de bug ontedekt heeft verwacht ik niet dat het een grote bug betreft. Sun weigert ook de betrokken bedrijven te noemen alhoewel ze exact weten wie welke niet 100% funtionerende proc heeft. Ze zullen dit heel discreet en correct afhandelen want ze hebben een goede naam te verliezen. Als er dergelijke risico's zijn (banken met dergelijke bedragen per seconde verlies) dan zullen ze wel wat anders handelen.
* 786562 klerkx

[arnob]

Zo niet..geld terug of een vervangend exemplaar dat wel goed is

pff, makkelijk gezegd.
Ik heb een Intel PII-266 (eerste stepping) in een dual proc systeem maar de proc kan niet dual proc werken, oeps foutje
Er staat geen disclaimer op een CPU maar hij hoort er volgens mij wel bij.
grtz

[SvMp]

maar een sun blade 1000 is maar een simpel workstation dingetje...

geen dikke server waar ABNamro hun spullen op laten draaien...

Hoe simpel het ding ook mag zijn, als je hardware koopt heb je recht op 100% correct werkende hardware.

Zo niet..geld terug of een vervangend exemplaar dat wel goed is.

Of het nou gaat om een server van 15000 piek of een geluidskaartje van 30 gulden, het dient gewoon te werken.

[roelio]

die disclaimer staat er niet bij maar vast wel op de website van Sun/Intel/AMD/whoever. En bij een boxxxed processor misschien in het bijgeleverde boekje/papiertje

[Wilfred]

Nou ik wil liever de goed presterende CPU waar ik voor heb betaald..
Ik koop een paar schoenen en dan gaat ineens de fabrikant zeggen sorry foutje ik moet je zolen eraf halen.... nee ik denk dat ik dan nieuwe schoenen krijg!! Dus inleveren en een nieuwe krijgen!!

[Verwijderd]

Daar is zo`n bank toch tegen verzekerd?
En ze zullen daar toch wel een backup systeem naast hebben staan om verder te draaien!

[P5ycho]

Kijk maar naar de eerste Pentium release (de 60/66Mhz), toen hadden ze ook een flinke fout gemaakt. Die dingen gebeuren nou eenmaal met zo'n megacomplex geval.

[Bezulba]

fout in software is imho zelfde als fout in hardware.. tmag allebij niet maar gebeurt toch en je kan er als klant nixs tegen doen... dus dat ambamro verhaal slaat nergens op.. al vinden ze een bug in het os dat abn gebruikt patchen ze het en gaan ze gewoon weer verder.. dat zal hier ook wel gebeuren

[Verwijderd]

Fouten in software zijn veel eenvoudiger op te lossen dan fouten in hardware. Daarnaast moet bij hardware bijna altijd ingeleverd worden, zoals hier 15% performance.
Met software schrijf je gewoon een paar stukken code opnieuw. Bij hardware kan dat niet, daar is patchen de enige oplossing.

[Verwijderd]

Vraag ik me even af of ze dit soort fouten ook kunnen verhelpen of omzeilen in de microcode. En zo niet vraag ik me af of het zinnig is om toch zoveel mogelijk in de processor zelf herconfigureerbaar te maken. Wellicht dat een processor dit zelf zou kunnen beslissen om te doen. Maar volgens mij kom je dan al meer in de sfeer waar Transmeta al geruime tijd mee bezig is.

Bedenk wel even dat het testen van een CPU meer dan de helft van de ontwikkel/produktie tijd kost. Want ga jij maar eens bedenken welke tests je moet uitvoeren als één van de 16 miljoen transistoren het toevallig niet doet. (zal wel geen 16 miljoen zijn maar wel veul)
Geen kattepis dus. En niemand kan 100% functionaliteit garanderen omdat je dan 3000 jaar (ofzo) bezig bent om dat te bewijzen. (word alleen maar erger met 64 bitters ipv 32)

[Bleh!]

Ter informatie: de UltraSparc is al een 64 bit processor.
Al denk ik niet dat dat veel uit zou moeten maken.
Over die tests het lijkt me dat ze gewoon alle instructies uitvoeren en dan misschien in verschillende volgordes.

[Verwijderd]

Zit nu geregeld met Sun werkstations te werken. Had kunnen weten dat ze 64 bitters waren.

Maar reken maar eens na alle instructies. Gelukkig is het een Risc dus valt het nog wel mee. Maar ga jij maar eens alle vermenigvuldigingen van twee 64 bits getallen testen. 2^64/10Mips*16cycles/60sec/60min/24uur/365dg=~100.000jaar!!! (aangenomen dat hij 10Mips aan kan en een FPU instructie als deze 16 cycles kost)
En alsjeblieft niet op m'n rekenfouten gaan zitten katten. Als het binnen een factor 1000.000 zit blijft het nog steeds veels te lang. Gelukkig kun je dit mbv slim nadenken sterk verkorten alleen blijken die tests dan niet foutvrij te zijn.

[Verwijderd]

Het gaat hier om een prefetch bug. Dit is hoogstwaarschijnlijk in silicium gebakken (een prefetch is het al ophalen van intructies die mogelijk als volgende aan de beurt zijn; branchprediction komt hier ook om de hoek kijken omdat als er een jump wordt gedaan men andere instructies moet ophalen).
Het lijkt mij geen micro-code oplossing omdat een aanpassing in de micro-code niet zou lijden tot 15% performance drop. Die prefetch hebben ze gewoon uitgezet. Het is wachten op een nieuwe stepping waarin ze het probleem hebben opgelost.

[Verwijderd]

Dit gaat Sun hoe dan ook veel geld kosten. Ze moeten zelf actie ondernemen en de klanten benaderen. Je kunt niet verwachten dat alle klanten op de hoogte zijn van de fout en dus patch. Laat staan dat je de verantwoordlijkheid van het patchen bij de klant kan neerleggen.

Daar het toch al geld kost om de machines met de problemen te lokaliseren en de problemen te verhelpen kunnen ze beter een hele nieuwe CPU installeren bij de klanten die een CPU met de fout.

Klanten een goed gevoel, slechte publiciteit omgedraaid naar reclame. En een bedrijf die een beetje professioneel is doet dit dan ook..

Dus: Tijdelijk patchen en daarna één voor één de machines langs om een nieuwe CPU erin te stoppen..

[Verwijderd]

Ah... Nou ik zal je zeggen, een bug in de software kan voor een bedrijf net zo fataal zijn als een bug in de hardware.

Klanten een goed gevoel, slechte publiciteit omgedraaid naar reclame. En een bedrijf die een beetje professioneel is doet dit dan ook..

Wanneer was de laatste keer dan dat Microsoft zijn klanten op de hoogte bracht van een bug?
Ons bedrijf gebruikt al een 3 jaar Windows NT en ze hebben nog nooit gewaarschuwd voor een bug in hun software. Niet door bellen, noch door een mailtje. We hebben er altijd zelf nog achter moeten komen via bugtraq of de Microsoft site zelf...

[roelio]

Waarom hebben de Blade1000 workstations wel deze fout en hebben de Fire-servers geen last van deze bug? zit hier soms een nieuwe stepping van deze USparcIII in ??

[Verwijderd]

Zou me niks verbasen als Sun net zŽon inruilaktie begint als Intel destijds....ze hebben een reputatie hoog te houden, en het kost ze ook niet verschrikkelijk veel, het bakken van procjes is niet zo duur, maar het ontwikkelen (lees constante kosten) wel...

[Verwijderd]

leuk processortje