Hirdetés

Új hozzászólás Aktív témák

  • P.H.

    senior tag

    válasz dokar #4702 üzenetére

    Sokadszor újragondolva a dolgot, most úgy vélem, hogy nem kellene hájp-nak nevezni azt, ami itt történt, és az AMD 'csinálta'. Mindvégig szem előtt volt a hiba leírásában, mégsem kapott elég nagy hangsúlyt:

    "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."

    Bár magának a hibának sok gyakorlati jelentőséget a mai napig nem tulajdonítok (»nagyon« szerencsétlen helyzet kell ahhoz, hogy a hiba hatása kézzelfogható problémát okozzon), az Opteron-ok célterületén a Machine Check Architecture nem csak egy pipa az Everest-ben a CPUID-fülön, hanem nagyon komolyan vett dolog, a Machine Check Exception-ön túl is: "Machine check errors are either recoverable or irrecoverable. Recoverable errors are those that the processor can correct and, thus, do not raise the machine check exception (#MC). However, the error is still logged in the machine check MSRs and it is the responsibility of the system software to periodically poll the machine check MSRs to determine if recoverable errors have occurred. If a recoverable error has been logged in the machine check MSRs, a second recoverable error can overwrite it." (K8 BKDG)

    Úgy eladhatatlan egy server-processor, hogy (vélt vagy valós) L3-hibát jelez, le is álltak velük (pl. "Now the L2 and L3 cache have the same data, which shouldn't happen given AMD's exclusive cache hierarchy. If the line in L2 gets evicted once more, it'll be sent off to the L3 and there will be a conflict creating a L3 protocol error." [link])
    Azt pedig nehéz lett volna megmagyarázni, hogy az Opteron-ok hibája egyáltalán nem jelentkezik az Phenom-okban. Még akkor is, ha a desktop OS-ek nem figyelik és loggolják folyamatosan az MCA-státuszt, csak a kivételre 'ugranak'.

Új hozzászólás Aktív témák