R
ruyven_macaran
Gast
erratum 298 - für die, dies interessiert...
hab gerade zufällig ne seite gefunden, die so etwas wie einen offiziellen text von amd zum tlb-bug zu enthalten scheint.
da es über das ding ja ne ganze menge spekulationen gibt und amd die öffentlich zugänglichen fehlerlisten seit september nicht mehr aktualisiert hat (kunden brauchen wohl keine infos
)....:
“The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."
soweit ich das interpretiere, werden fehler also dann ausgelöst, wenn
-ein programm auf den tlb zugreift, dabei veränderungen in seinem adressraum vornimmt und
-diese veränderungen noch nicht wieder in die caches zurückgeschrieben worden sind
-bevor ein programm mit anderem adressraum auf genau die gleichen zeilen des tlb zugreifen will
-woraufhin die veränderungen von einem programm fälschlicherweise in den daten vom anderen programm vorgenommen werden
-dass darauf gegebenenfalls mit problemen reagiert.
d.h. der bug wird gefördert durch möglichst viele programme mit unabhängigen adressraum, die zeitgleich möglichst viele speichertransfers auf der cpu durchführen. also insbesondere
-virtualisierung
-intensives multitasking (aber afaik nicht mutlithreading, multicore optimierte spiele sind also für sich erstmal nicht betroffen)
-speicherlastige anwendungen
je nachdem, wie das "small window of time" zu interpretieren ist (absolut/relativ zum cpu-takt), könnte auch noch ein erhöhter cpu-takt dazu beitragen.
überhaupt keine rolle dürfte die laufzeit spielen - der bug kann eine sekunde oder 1 jahr nach start aller anwendungen, deren kombination in letztlich verursacht, auftreten.
nach 2 wochen ist die chance, dass er schon aufgetreten ist, natürlich größer, als nach 2 stunden.
oder anders: der bug sollte in all den szenarien auftreten, für die ein quadcore mit imc prädestiniert ist, in denen, für die die k10 architektur laut ursprünglicher werbung besonders geeignet sein soll - vielleicht auch bei den taktfrequenzen, die uns mal versprochen wurden.
aber eher nicht in für spieler oder benchmarker typischen situationen.
hoffe mal, dass dämpft die ewige "nie" "nur bei hoher belastung" "nach 2 wochen" "so oft, dass das ding in die tonne gehört",... spekulationen bezüglich des auftretens - auch wenn die quelllage hier wieder ungewiss ist.
p.s.:
triple- und selbst dual-core ableger sollten demnach auch betroffen sein, auch wenn die wahrscheinlichkeit da geringer ist.
single-cores/phenoms mit 3 deaktivierten kernen dürften dagegen relativ sicher sein. (vielleicht für ocer interessant. wenn der takt wirklich eine rolle spielen sollte, könnte es sein, dass sich eine cpu mit 2/3/4 aktiven kernen nichtmal so hoch takten lässt, wie der langsamste der beteiligten kerne alleine)
hab gerade zufällig ne seite gefunden, die so etwas wie einen offiziellen text von amd zum tlb-bug zu enthalten scheint.
da es über das ding ja ne ganze menge spekulationen gibt und amd die öffentlich zugänglichen fehlerlisten seit september nicht mehr aktualisiert hat (kunden brauchen wohl keine infos
)....:“The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."
soweit ich das interpretiere, werden fehler also dann ausgelöst, wenn
-ein programm auf den tlb zugreift, dabei veränderungen in seinem adressraum vornimmt und
-diese veränderungen noch nicht wieder in die caches zurückgeschrieben worden sind
-bevor ein programm mit anderem adressraum auf genau die gleichen zeilen des tlb zugreifen will
-woraufhin die veränderungen von einem programm fälschlicherweise in den daten vom anderen programm vorgenommen werden
-dass darauf gegebenenfalls mit problemen reagiert.
d.h. der bug wird gefördert durch möglichst viele programme mit unabhängigen adressraum, die zeitgleich möglichst viele speichertransfers auf der cpu durchführen. also insbesondere
-virtualisierung
-intensives multitasking (aber afaik nicht mutlithreading, multicore optimierte spiele sind also für sich erstmal nicht betroffen)
-speicherlastige anwendungen
je nachdem, wie das "small window of time" zu interpretieren ist (absolut/relativ zum cpu-takt), könnte auch noch ein erhöhter cpu-takt dazu beitragen.
überhaupt keine rolle dürfte die laufzeit spielen - der bug kann eine sekunde oder 1 jahr nach start aller anwendungen, deren kombination in letztlich verursacht, auftreten.
nach 2 wochen ist die chance, dass er schon aufgetreten ist, natürlich größer, als nach 2 stunden.
oder anders: der bug sollte in all den szenarien auftreten, für die ein quadcore mit imc prädestiniert ist, in denen, für die die k10 architektur laut ursprünglicher werbung besonders geeignet sein soll - vielleicht auch bei den taktfrequenzen, die uns mal versprochen wurden.
aber eher nicht in für spieler oder benchmarker typischen situationen.
hoffe mal, dass dämpft die ewige "nie" "nur bei hoher belastung" "nach 2 wochen" "so oft, dass das ding in die tonne gehört",... spekulationen bezüglich des auftretens - auch wenn die quelllage hier wieder ungewiss ist.
p.s.:
triple- und selbst dual-core ableger sollten demnach auch betroffen sein, auch wenn die wahrscheinlichkeit da geringer ist.
single-cores/phenoms mit 3 deaktivierten kernen dürften dagegen relativ sicher sein. (vielleicht für ocer interessant. wenn der takt wirklich eine rolle spielen sollte, könnte es sein, dass sich eine cpu mit 2/3/4 aktiven kernen nichtmal so hoch takten lässt, wie der langsamste der beteiligten kerne alleine)
