TLB bug & PTT Toelichting gevraagd

[Reloader]

het stukje op de mainpage over de TLB bug boeit me enorm maar het word me al snel onduidelijk dus mijn vraag is of iemand het mischien wat kan verduidelijken

het gaat me voornamelijke om het volgende:

De PTT heeft echter meer functies dan alleen maar het vertalen van adressen; er wordt ook in bijgehouden wat de status is van hetgeen er op te vinden is. ^{Bevindt het zich op dit moment in het fysieke geheugen? Mag er naar geschreven worden? Gaat het om instructies of data? Is er iets aan gewijzigd sinds het is opgevraagd?} Vooral die laatste is belangrijk: als data uit het geheugen wordt gegooid zonder dat de wijzigingen eerst worden opgeslagen, kan dat tot vervelende resultaten leiden. Een crash is daar nog een van de minst erge van: software die zonder dat iemand het merkt de fout in gaat is een veel grotere kopzorg, in ieder geval voor bedrijfskritische systemen

de ptt dus
wat moet ik me erbij voorstellen ?

het is teneerste een bibliotheek. (gevuld met?)
en het is dus een inhoudsopgave van het geheugen. waarin ook nog eens bijgehouden word wat de status is van de inhoud?

bij het volgende stukje "de bug" word uitgelegd wat er gebeurt. maar ook dat is me niet echt duidelijk terwijl het toch echt interessant is.

kan iemand me een duwtje in de goede richting geven? eventueel een documentje wat L1 L2 en L3 cache verduidelijkt?

[Thandor]

Even een linkje naar het artikel: reviews: TLB-bug in quadcore AMD-chips: het hele verhaal

PTT staat voor 'page translation table'. De status kan o.a. 'Bevindt het zich op dit moment in het fysieke geheugen? Mag er naar geschreven worden? Gaat het om instructies of data? Is er iets aan gewijzigd sinds het is opgevraagd?' zijn en inderdaad, het is een soort inhoudsopgave waar bijgehouden wordt wat de status is van de inhoud.

Over het stukje van de bug:

Onder bepaalde omstandigheden kan het gebeuren dat de chip tijdens het wijzigen van de status van een brok data ineens gestoord wordt door andere opdrachten die in de wachtrij staan, die ten onrechte een hogere prioriteit krijgen. Hierdoor kan het zo zijn dat het L3-cache al wel op de hoogte is van de verandering, maar het L2-cache nog in het duister tast.

Dat wil zeggen dat Pietje (de chip), die bezig is met het schrijven van een boek, gestoord wordt omdat Jantje (de andere opdracht) er opeens tussendoor komt en de aandacht van Pietje vraagt. Pietje stopt met het schrijven van het boek en gaat verder met hetgeen waar Jantje mee aan kwam zetten. Pietje heeft echter wel voordat hij met het schrijven van zijn boek begon aangegeven dat hij met het schrijven begon (de status staat dan op schrijven) waardoor Henk, die bij de afdeling 'L2-cache' werkt denkt dat Pietje een boek aan het schrijven terwijl dat helemaal niet zo is.

L#-cache is een stukje geheugen op het de processor zelf. L1 cache zit dichter bij de processor dan L2 cache, L3 cache zit nog iets verder dan L2 cache. Het interne geheugen zit (relatief gezien) heel ver weg van de processor.

[Reloader]

Super .. duidelijke taal..alleen wat is dan het probleem dat de L2 cache de verkeerde status heeft?
dus henk denkt dat piet aan het boek schrijft.. maar dat is niet.. wat is het probleem?

(daar komt henk dan toch vanzelf wel achter )

wel lekkere duidelijke taal hehe

[Thandor]

Pietje schrijft het boek maar wordt ondertussen opgehouden door Jantje. Henk denkt dat Pietje het boek aan het schrijven is en wacht daar op of gaat verder met iets wat afhankelijk is van het schrijven van het boek (bijvoorbeeld het drukken van de boeken) dan dan loopt het systeem spaak. Immers worden verwachtingen niet waar gemaakt.

Anderzijds kan het natuurlijk ook zijn dat Pietje het boek geschreven heeft. De status op 'boek is klaar' zet maar in de tussentijd door Jantje gestoord wordt (en het boek dus niet klaar legt). Henk ziet aan de hand van de status dat het boek klaar is en vraagt het boek op, en dat boek ligt dan nog niet op tafel (=crash).

[Reloader]

duidelijk :D!

[Reloader]

ff kort door de bocht..

een vertaalslag word uitgevoerd door de chip. deze word onderbroken en verdwijnt of word corrupt vervolgens word de volgende stap dus een fout maakt waardoor hetsysteem crasht of vastloopt?

en de cache is een soort wachtrij voor deze vertaalslagen?

[GENETX]

Nee, Cache is een soort geheugen, net als je werkgeheugen. Ik weet neit wat voor rekenmachien je hebt, maar als je een iets geavanceerder model hebt dan heb je vaak de "Store functie". Hiermee sla je dus tijdelijk een tussenuitkomst op om er later mee verder te gaan.

Zo kan je ook software zien. Je slaat tijdelijk even iets op om straks de status er van weer terug te vragen.

[ Voor 117% gewijzigd door GENETX op 28-01-2008 14:30 ]

[Reloader]

achso dus die TLB en PTT regelen de Cache geheugens en niet het RAM geheugen.. zat ik daar al goed fout :#

[GENETX]

Dat zou ik even moeten nazoeken , maar in eerste instantie gaat het hier idd alleen om je cache.

Maar een van de grootste problemen is dus dat deze cache wordt gebruikt om vaak statussen vast te houden of bijvoorbeeld een tussenantwoord. Het vervelende van de TLB bug is dat het voor kan komen dat data uit het geheugen wordt verwijderd zonder het eerst op te slaan.

Rekenvoorbeeldje:

Computer doet 1+1 = 2
Antwoord (2) -> Geheugen
*TLB zet het antwoord in het geheugen*

*vorig antwoord wordt weer uit het geheugen gehaald*
*TLB zegt dat er niet is geweijzigd dus kjlopt de berekening nog*
Antwoord x 5 = 10
*TLB gooit het antwoord van 10 weg*
*TLB geeft aan dat er niet is gewijzigd en de 2 blijft dus staan*

*Antwoord wordt weer opgehaald*
*TLB geeft weer aan dat er neits is gewijzigd dus de berekening klopt nog*
Antwoord (dus nog steeds 2 ipv 10) / 2 = 1!

Daar ging dus iets mis. Het programma zou normaal een 10 moeten krijgen uit het geheugen van de vorige berekening. Verder is het programma vrij dom en gelooft de TLB op zn woord dat het antwoord nog steeds goed is. Toch gaat er wat mis omdat de TLB dus een foutje heeft gemaakt. Bedenk wat er gebeurt als er iets mis gaat met een CPU instructie... Daar koemn dus crashes van.

(Heb net mn post aangepast omdat ik dacht dat hij te lastig was )

[ Voor 77% gewijzigd door GENETX op 28-01-2008 14:46 ]

[Reloader]

ik ga vandaag weer verder prutsen! thx ..

[Reloader]

ff voor de goede orde.. de TLB en PTT zitten allebei in de processor. de TLB werkt ob basis van het cache geheugen en waar zet de PTT de inhoudsopgave van het geheugen weg?

en waarom staat de ene bereking in L3 cache en de andere in L1? is dat willekeurig?

[ Voor 20% gewijzigd door Reloader op 29-01-2008 14:48 ]

[GENETX]

Dat staat duidelijk in het artikel eigenlijk

Maar idd, ze zijn beide een onderdeel van de CPU. Een programma denkt dat hij het complete geheugen kan gebruiken, echter moet deze het delen met andere programma's Het programma weet dat niet. De TLB en PTT zorgen er voor dat dit in goede banen wordt geleid. Hiervoor wordt dus onthouden op welke plaats een bepaald deel zit. Zo hoeft een programma ook zelf geen geheugenlocatie te claimen.

De TLB en PTT zijn in het eerste opzicht gelijk: Beide geven ze aan waar iets staat. Echter kan de PTT veel meer info geven over een deel geheugen dan de TLB. De TLB daarintegen is wel een stuk sneller. De TLB houdt alleen de geheugenadressen vast waar iets staat. De PTT kan daarnaast ook nog andere dingen vasthouden zoals of het gaat om een instructie of data in dat geheugen. Of het is gewijzigd is of niet. Of een stuk geheugen read only is. En dergelijke.

Wanneer een programma alleen zijn data opvraagt kan dat gewoon met de TLB en werkt dus een stuk sneller. Wanneer het systeem geavanceerde gegevens wil opvragen dan kan hij in de PTT kijken.


Uitleg in een voorbeeld:
Stel, je gaat op vakantie. Je reserveerd een plek om je tent op neer te hameren (Geheugenlocatie). De camping (TLB en PTT) zal dan voor jou een geschikt plekje uitkiezen. je weet zelf niet welke andere gasten waar op de camping zullen komen. Dat hen jij (programma) ook neit nodig en wordt dus netjes voor je geregeld.

Wanneer jij dan op de camping komt zou men dus in de "TLB" kunnen kijken welk plekje voor jou is gereserveerd en je tent er op zetten. Wanneer men echter je rekening wil opstellen kan met uit de "PTT" opmaken hoe lang je er al staat, of je een tent of caravan hebt, hoeveel personen etc etc. Dat laatste heb jij niet nodig om je tent op te zetten, maar is wel heel handig voor de beheerders van de camping.

[Reloader]

ik hou wel van die jip en janneke stories .. super.

[mad_max234]

Jezus, is weer op jip en janneke niveau vandaag. (in ieder geval onder het tweakers niveau) Staat toch allemaal in het artikel en moet voor een beetje tweaker toch wel op te zoeken zijn wat het inhoud.

Het komt gewoon op neer dat data corrupt word in het cache geheugen omdat de status anders is, en hij dan niet meer weet wat hij moet doen, en zelf nadenken wat hij er dan mee zou moeten doen, doet hij jammer genoeg nog niet.

[ Voor 5% gewijzigd door mad_max234 op 29-01-2008 21:18 ]

[Reloader]

das wel heel kort door de bocht... gelukkig snap ik het nu ook na de duidelijke maar "onder niveau" van genetex en thandor

iets zo uit kunnen leggen is een goeie vaardigheid in een commercieel functie ..

nogmaals bedankt

[mad_max234]

Reloader schreef op dinsdag 29 januari 2008 @ 21:47:
das wel heel kort door de bocht... gelukkig snap ik het nu ook na de duidelijke maar "onder niveau" van genetex en thandor

iets zo uit kunnen leggen is een goeie vaardigheid in een commercieel functie ..

nogmaals bedankt

Alleen is dit een forum voor gevorderde pc gebruikers, en met google en het artikel ernaast was het jou ook wel gelukt denk ik zo.

offtopic/
Leuke roadtrip. en andere foto's alleen beetje veel van het zelfde voor al die bergen, maar verder leuke begin van een site.

[Reloader]

tis dan ook niet dat ik een kneus ben op pc gebied..ik denk niet dat je veel beginners hier zult vinden... alhoewel ik op gebied van processor architectuur wel een beginner ben (A)..

//oftopic.. die site staat al dik een jaar zo.. geen zin in en geen tijd voor.

[roy-t]

Ik heb zelf een AMD Phenom GP9600BE die ook last zou hebben van de TLB bug.

Mijn moederbord bios wist eerst niet van het bestaan van de bug af, resultaat:
Superstabiele PC, (je denkt misschien nu wtf? Maar het is waar)

Nu heb ik sinds een Bios Update van mijn Gigabte DS4 (AM2+ mobo) ook de optie om de TLB bugfix die het zooitje ongeveer 5~10% langzamer maakt aan te zetten. Standaard staat deze uit!

Of ik de optie nu aan of uit zet, ik merk het gewoon niet, niet in Crysis, niet tijdens softwaredevelopment. de TLB bug is lang zo rampzalig niet als iedereen maar roept. Misschien voor servers interessant. Maar voor een gemiddelde tweaker is er niks aan de hand.

ik ben nu al enkele weken zeer tevreden over mijn AM2+ CPU, TLB bug of niet, geweldige QuadCore voor slechts €200,- wat wil je nog meer?

[Salvatron]

Ik vind het een beetje een vaag artikel (dit artikel: reviews: TLB-bug in quadcore AMD-chips: het hele verhaal)

Er staat wel in te lezen dat er een bug is, maar nergens staat er te lezen hoe relevant het is. CPU's zullen wel zeer goed getest worden voordat ze op de markt worden gebracht, dus als de TLB-bug die tests heeft doorstaan, dan is de vraag wanneer die bug in de praktijk op zal treden, en of die überhaupt op zal treden.

[Verwijderd]

Bij desktop PC's zou het nauwelijks verschijnen. Bij Servers waar veel met virtualisatie gedaan wordt, schijnt het juist wel op te treden, en waar immers is een draaiend platform nou het meest cruciaale? Juist ja. De patch die er is vertraagt de boel jammergenoeg met 10%, maar als dat je zaak draaiende houden kan, waarom niet.

[GENETX]

Aan de andere kant, volgens mij was het The Source die zei dat er ergens een serverparkje met Barcelona's stond die in het begin waren uitgeleverd. Die waren nog geen problemen tegengekomen...

Maar verder, wat is er mis met deze jip en janneke verhaaltjes? Als tweaker/computerliefhebber ben je nog niet meteen CPU deskundige. Iederee weet hier wel wat welke melding in Windows betekend, maar niet wat er achter zit, hoe een CPU werkt. Ja, in grote lijnen weet je wel wat de hardware doet, maar niet exact hoe. Ik denk dat <10% hier weet op GoT hoe een CPU nou echt inelkaar steekt.

Verder vindt ik het geen probleem om mensen even iets duidelijk uti te leggen, ik weet nu zelf ook echt door het nog eens goed te bestuderen hoe het exact werkt. Beide dus wat opgestoken.

[Verwijderd]

roy-t schreef op dinsdag 29 januari 2008 @ 23:55:
Ik heb zelf een AMD Phenom GP9600BE die ook last zou hebben van de TLB bug.

Mijn moederbord bios wist eerst niet van het bestaan van de bug af, resultaat:
Superstabiele PC, (je denkt misschien nu wtf? Maar het is waar)

Nu heb ik sinds een Bios Update van mijn Gigabte DS4 (AM2+ mobo) ook de optie om de TLB bugfix die het zooitje ongeveer 5~10% langzamer maakt aan te zetten. Standaard staat deze uit!

Of ik de optie nu aan of uit zet, ik merk het gewoon niet, niet in Crysis, niet tijdens softwaredevelopment. de TLB bug is lang zo rampzalig niet als iedereen maar roept. Misschien voor servers interessant. Maar voor een gemiddelde tweaker is er niks aan de hand.

ik ben nu al enkele weken zeer tevreden over mijn AM2+ CPU, TLB bug of niet, geweldige QuadCore voor slechts €200,- wat wil je nog meer?

Het hele verhaal was dus ook dat AMD het niet bij zijn eigen testen is tegen gekomen en dat maakt het hele verhaal al erg zeldzaam. Feit is dat er een bug in zit die in zeer zeldzame omstandigheden op kan treden. Voor jou (en alle consumenten) boeit dat helemaal niets, jullie zullen het waarschijnlijk nooit merken. Voor een server echter is het wel van belang omdat je op een server met een dergelijke chip dus geen mission critical apps kunt draaien want je kunt niet 100% uitgaan van de correcte werking (1 fout per 10 jaar bijv. is dan ook teveel )

[mad_max234]

GENETX schreef op woensdag 30 januari 2008 @ 08:33:
Aan de andere kant, volgens mij was het The Source die zei dat er ergens een serverparkje met Barcelona's stond die in het begin waren uitgeleverd. Die waren nog geen problemen tegengekomen...

Maar verder, wat is er mis met deze jip en janneke verhaaltjes? Als tweaker/computerliefhebber ben je nog niet meteen CPU deskundige. Iederee weet hier wel wat welke melding in Windows betekend, maar niet wat er achter zit, hoe een CPU werkt. Ja, in grote lijnen weet je wel wat de hardware doet, maar niet exact hoe. Ik denk dat <10% hier weet op GoT hoe een CPU nou echt inelkaar steekt.

Verder vindt ik het geen probleem om mensen even iets duidelijk uti te leggen, ik weet nu zelf ook echt door het nog eens goed te bestuderen hoe het exact werkt. Beide dus wat opgestoken.

Is ook niks mis met goede duidelijke uitleg, het leest alleen beetje kinderachtig als het in jip en janneke taal word gedaan op een site waar je dat niet verwacht (eigenlijk tegenovergestelde verwacht), ik doe het ook welles bij leeks of mijn kleine neefjes.

Duidelijk uitleg hoeft toch niet in jip en janneke taal om duidelijk te zijn, ik vond het gewoon grappig om het hier zo te lezen. De vaardigheid in duidelijke uitleg ligt niet bij het jip en janneke taal gebruik. (want als je alleen maar zo iets duidelijk uit kan leggen, of alleen maar zo iets snapt, dan klopt er iets niet )

En maak je niet te druk, was maar een geintje zoals je kan zien aan de twee smilies die er tussen staan.

En je hoeft ook geen cpu deskundige te zijn, je moet wel google kunnen vinden en mee willen/kunnen werken. (dan kom je een heel eind zonder jip en janneke)

[ Voor 7% gewijzigd door mad_max234 op 30-01-2008 15:22 ]

[GENETX]

mad_max234 schreef op woensdag 30 januari 2008 @ 15:18:
[...]
Duidelijk uitleg hoeft toch niet in jip en janneke taal om duidelijk te zijn, ik vond het gewoon grappig om het hier zo te lezen. De vaardigheid in duidelijke uitleg ligt niet bij het jip en janneke taal gebruik.

Mja, de meeste tweakers zijn alsnog wel leken op dit gebied

[mad_max234]

GENETX schreef op woensdag 30 januari 2008 @ 15:19:
[...]


Mja, de meeste tweakers zijn alsnog wel leken op dit gebied

Wat houd je tegen om als leek iets te leren, dus veel inlezen en met google of andere zoek functie er achter te komen wat je niet weet, zo heeft bij iedereen het geleerd. Google, google en nog eens google en naar een tijdje weet je het

En het staat allemaal in het artikel wouter heeft niet voor niks zoveel tijd eraan besteed, en met hand van google en het artikel ernaast was een leek ook wel achter het antwoord gekomen. (er is meer dan zat over geschreven de laatste tijd, toch? )

[Salvatron]

Over google gesproken: ik heb even gegoogeld om te vinden of iemand al in de praktijk last heeft gehad van de bug. Maar nergens zie ik staan dat iemand er al last van heeft gehad, ook niet na honderden uren proberen, en ook niet in een bedrijf waar honderden phenom-systemen draaien. Ook reviewers schijnen geen melding te maken er last van te hebben. Als er iemand last van heeft dan mag ie het zeggen. Ik heb gewoon een Phenom 9500 gekocht hoor, ik denk niet dat ik er last van ga hebben.

[GENETX]

Phenom bug is idd overdreven. AMD heeft veel mazzel/pech gehad dat hij is gevonden.

Mazzel: Goede naam opgebouwd bij serverbouwers om een niet 100% goede CPU terug te halen\
Pech: Zo ongveer iedere tweakert zit te zeuren over niets.

[mad_max234]

Jack Walsh schreef op woensdag 30 januari 2008 @ 16:06:
Over google gesproken: ik heb even gegoogeld om te vinden of iemand al in de praktijk last heeft gehad van de bug. Maar nergens zie ik staan dat iemand er al last van heeft gehad, ook niet na honderden uren proberen, en ook niet in een bedrijf waar honderden phenom-systemen draaien. Ook reviewers schijnen geen melding te maken er last van te hebben. Als er iemand last van heeft dan mag ie het zeggen. Ik heb gewoon een Phenom 9500 gekocht hoor, ik denk niet dat ik er last van ga hebben.

Ik bedoelde meer op de vraag in je startpost dat je met hand van het artikel en google een heel eind was gekomen.

En je zal geen mensen vinden die kunnen zeggen dat hun crash (zal vast en zeker voorkomen) ook de schuld is van de bug, beetje moeilijk om dat aan te tonen. Dus je kan wel stoppen met het zoeken want niemand kan je dat zeggen namelijk, ook reviewers kunnen dat niet testen.

En ja de TL bug is niet zo erg, maar je hoor gewoon 100% werkend systemen te leveren als bedrijf, dus moest AMD wel een oplossing bedenken, en bugs komen bij alle cpu voor, de C2D had ook een hele lijst aan bugs tijdens de introductie.

[ Voor 10% gewijzigd door mad_max234 op 30-01-2008 16:49 ]

[Salvatron]

mad_max234 schreef op woensdag 30 januari 2008 @ 16:40:
Ik bedoelde meer op de vraag in je startpost dat je met hand van het artikel en google een heel eind was gekomen.

MIJN startpost? Ik heb hier geen startpost hoor . Maar ik heb aan de hand van het artikel gegoogeld, echter zie ik geen bewijzen dat het hier om een ernstige bug gaat.

En je zal geen mensen vinden die kunnen zeggen dat hun crash (zal vast en zeker voorkomen) ook de schuld is van de bug, beetje moeilijk om dat aan te tonen. Dus je kan wel stoppen met het zoeken want niemand kan je dat zeggen namelijk, ook reviewers kunnen dat niet testen.

Dat hangt er vanaf. Ten eerste: de bug schijnt je computer helemaal te laten bevriezen, dus als er geen bevriezing optreedt is er ook geen bug opgetreden. Ten tweede: alle crashes die er wel zijn, zouden een aantoonbaar andere oorzaak hebben dan de bug. Dus als er niet aan te tonen is dat de crash de schuld is van de bug, dan kan er nog gekeken worden of de crash een andere oorzaak heeft.

En ja de TL bug is niet zo erg, maar je hoor gewoon 100% werkend systemen te leveren als bedrijf, dus moest AMD wel een oplossing bedenken, en bugs komen bij alle cpu voor, de C2D had ook een hele lijst aan bugs tijdens de introductie.

Maar de phenom werkt misschien ook wel voor 100%, die bug komt in de praktijk misschien wel nooit voor. Aan de ene kant is de bug volgens AMD blijkbaar ernstig genoeg om er een patch voor uit te brengen, aan de andere kant zorgt AMD er ook voor dat die patch uit te schakelen is. Ik vind het zelf niet interessant of een CPU een bug heeft; pas als er precies bij wordt verteld wanneer die bug optreedt is het zinnig om iets over die bug te weten.

[GENETX]

Nope, de bug kan ook voor datacorruptie zorgen. In de meeste gevallen leidt dat idd onmiddelijk tot een crash. Echter is het niet ondenkelijk dat zoals ik op de vorige pagina al schetste een bepaalde waarde niet wordt vernieuwd. Zit je door te rekenen met de verkeerde waarde. Een nulletje meer of minder kan nogal wat gevolgen hebben....

[mad_max234]

Jack Walsh schreef op woensdag 30 januari 2008 @ 17:01:
[...]


MIJN startpost? Ik heb hier geen startpost hoor . Maar ik heb aan de hand van het artikel gegoogeld, echter zie ik geen bewijzen dat het hier om een ernstige bug gaat.

Oops , haalde je even door elkaar met de topic starter, maar geld natuurlijk ook in het algemeen.

Dat hangt er vanaf. Ten eerste: de bug schijnt je computer helemaal te laten bevriezen, dus als er geen bevriezing optreedt is er ook geen bug opgetreden. Ten tweede: alle crashes die er wel zijn, zouden een aantoonbaar andere oorzaak hebben dan de bug. Dus als er niet aan te tonen is dat de crash de schuld is van de bug, dan kan er nog gekeken worden of de crash een andere oorzaak heeft.

Oké hoe wil je dan een vast geslagen pc terug lijden naar de TLB bug? Is het zelfde verhaal als een crash, kan je niet terug lijden naar de TLB bug. je kan niet aantonen dat het door de cache komt. (misschien AMD wel in het lab, maar wij en reviewers niet)

Vast geslagen pc komt ook gewoon voor ook zonder TLB bug.

Maar de phenom werkt misschien ook wel voor 100%, die bug komt in de praktijk misschien wel nooit voor. Aan de ene kant is de bug volgens AMD blijkbaar ernstig genoeg om er een patch voor uit te brengen, aan de andere kant zorgt AMD er ook voor dat die patch uit te schakelen is. Ik vind het zelf niet interessant of een CPU een bug heeft; pas als er precies bij wordt verteld wanneer die bug optreedt is het zinnig om iets over die bug te weten.

Nee hij werk niet altijd 100% in sommige gevallen stop hij dus met werken. Dat is niet 100% goed werkende cpu, data kan zelfs corrupt worden van dat systeem doordat hij crashed, en dan zal je je backups weer terug moeten zetten. Een 100% goedwerkende cpu (Phenom met patch) heeft dit probleem niet.

[Salvatron]

mad_max234 schreef op woensdag 30 januari 2008 @ 18:21:
Oké hoe wil je dan een vast geslagen pc terug lijden naar de TL bug? Is het zelfde verhaal als een crash, kan je niet terug lijden naar de TL bug. je kan niet aantonen dat het door de cache komt. (misschien AMD wel in het lab, maar wij en reviewers niet)

Vast geslagen pc komt ook gewoon voor ook zonder TL bug.

Ik zie nergens dat mensen met een Phenom een vastgeslagen PC hebben.

Nee hij werk niet altijd 100% in sommige gevallen stop hij dus met werken. Dat is niet 100% goed werkende cpu, data kan zelfs corrupt worden van dat systeem doordat hij crashed, en dan zal je je backups weer terug moeten zetten. Een 100% goedwerkende cpu (Phenom met patch) heeft dit probleem niet.

Nee, want in de praktijk werkt dat ding altijd en slaat hij nooit vast.

[mad_max234]

Jack Walsh schreef op woensdag 30 januari 2008 @ 19:23:
[...]


Ik zie nergens dat mensen met een Phenom een vastgeslagen PC hebben.

Ik wel. (google eens en kijk op andere forums )

Nee, want in de praktijk werkt dat ding altijd en slaat hij nooit vast.

Ja vertel dat maar aan AMD Als hij het altijd zou doen, dus de bug nooit zou optreden zou AMD deze bug niet fixen net als alle andere bugs die in de Phenom zit en zou AMD hem lekker zo laten zitten.

Het komt niet vaak voor, maar dat wilt niet zeggen dat het nooit voorkomt. (Ik zegt overigens niet dat het een groot probleem voor thuis gebruikers)

[ Voor 3% gewijzigd door mad_max234 op 30-01-2008 19:37 ]

[Sebazzz]

mad_max234 schreef op woensdag 30 januari 2008 @ 19:36:
net als alle andere bugs die in de Phenom zitten

Welke andere? Zo ver ik weet is de TLB bug de enigste ernstige bug. Het feit dat de Phenom nogal warm is, is geen bug.

[mad_max234]

Sebazzz schreef op woensdag 30 januari 2008 @ 19:42:
[...]

Welke andere? Zo ver ik weet is de TLB bug de enigste ernstige bug. Het feit dat de Phenom nogal warm is, is geen bug.

Er zitten in alle cpu meerdere bugs, is altijd al geweest en zitten in alle cpu (Intel, Via, AMD, IBM hebben allemaal bugs in hun cpu zitten) en zal voorlopig nog niet tot het verleden behoren.

Zoals ik al zei in een eerdere post ook de c2d heeft meer dan 100 bug (weet even het exacte aantal niet), en die zitten er allemaal nog in, soms werken ze daar omheen door verschillende methodes zoals onder andere micro code updates. (TLB patch is ook een mirco code update)

En sommige bugs blijven gewoon zitten, deze hebben weinig effect en is niet nodig om te fixen.

En of de TLB bug ernstig is valt ook nog even te twisten, meeste gevallen is hij niet ernstig zijn en is de cpu gewoon bruikbaar. Voor de Phenom (desktop cpu) is hij eigenlijk niet ernstig, maar voor de Opteron is hij een doren in het oog van AMD.

[ Voor 31% gewijzigd door mad_max234 op 30-01-2008 21:51 ]