Processori AMD EPYC Rome: si bloccano dopo 1044 giorni. Perché non è così grave

Processori AMD EPYC Rome: si bloccano dopo 1044 giorni. Perché non è così grave

Pubblicando un aggiornamento della sua Revision Guide riferita ai processori EPYC RomeAMD ha rivelato che essi si bloccano puntualmente dopo 1044 giorni di attività. Trascorso questo periodo di tempo, la macchina basata su EPYC Rome si blocca e richiede un riavvio fisico (o via IPMI, Intelligent Platform Management Interface). Questo avviene perché i vari core cessano di funzionare e nessun interrupt può essere loro trasferito. Un interrupt è un segnale asincrono generato da un dispositivo o da un evento esterno che richiede l’attenzione immediata del processore o del sistema: in questo modo è possibile sospendere temporaneamente l’esecuzione del programma corrente e passare ad eseguire una routine di gestione dell’interrupt specifica per l’evento verificatosi.

Perché i processori AMD EPYC Rome si bloccano dopo esattamente 1044 giorni di funzionamento

Il problema deriva dal fatto che il core non riesce a uscire dallo stato di sospensione CC6. Nel contesto dei processori AMD, CC6 (Core C6 state) si riferisce a uno stato di basso consumo energetico progettato per ridurre l’assorbimento quando il processore non richiede una potenza di calcolo significativa. Quando il core di un processore AMD entra in CC6, viene disattivato e posto in uno stato di basso consumo energetico. Il core interrompe temporaneamente l’esecuzione di istruzioni e calcoli.

Per evitare che il sistema basato su EPYC Rome (ad esempio gli EPYC 7002) si blocchi, basta ricordarsi di riavviare la macchina almeno una volta prima di 1044 giorni. D’altra parte 1044 giorni sono praticamente 3 anni. Difficile che, anche in ambito data center, figuriamoci in altri ambienti professionali, qualche amministratore si sogni di non effettuare il reboot del server per così tanto tempo. Anche la semplice installazione degli aggiornamenti e delle patch di sistema, sia su Linux che su Windows, spesso porta l’amministratore di sistema a riavviare la macchina.

I tecnici della società guidata da Lisa Su indicano che non risolveranno il problema in questione. Per scongiurare i rischi di un blocco della macchina basata su EPYC Rome, consigliano un riavvio prima dei 3 anni oppure l’eventuale disattivazione di CC6.

AMD ha presentato i processori EPYC Rome ad agosto 2019. Sono la seconda generazione degli EPYC basati sull’architettura Zen 2. Destinati al settore server, offrono prestazioni elevate, con un aumento significativo di core e thread rispetto alla generazione precedente. Per la società di Sunnyvale, gli EPYC Rome hanno rappresentato un importante passo avanti nella competizione con Intel nel segmento business e data center.

Cosa sono gli “errata” nel caso dei microprocessori

Quello confermato da AMD e che “spegne” il funzionamento degli EPYC Rome dopo 1044 giorni di funzionamento è un errata. Così sono chiamati in gergo gli errori e le anomalie che si verificano nella progettazione o nell’implementazione di un processore. Questi errori possono causare comportamenti anomali o imprevisti quando viene eseguito del codice su un microprocessore specifico. I produttori sono soliti controllare e registrare gli errata fornendo documenti pubblici sulle problematiche rilevate.

Gli sviluppatori di software e i system integrator possono utilizzare queste informazioni per evitare o mitigare gli effetti degli errata durante lo sviluppo e il testing dei loro prodotti. I produttori di microprocessori possono anche rilasciare aggiornamenti del microcodice o del firmware per correggere o mitigare gli errori più gravi (non è questo il caso).

Con miliardi di transistor in gioco, è inevitabile che ci siano problemi: non è raro che un chip abbia mille o più errata/bug via via corretti a vari livelli. La presenza di errata è una caratteristica comune dei microprocessori moderni, così complessi e sofisticati. Non tutti hanno però un impatto significativo sul normale funzionamento del processore.

Tant’è vero che AMD non risolverà il problema in questione. Forse la questione è troppo costosa da risolvere a livello di silicio, una patch del microcodice/firmware comporta un eccessivo deficit prestazionale oppure, più semplicemente, non ci sono abbastanza clienti interessati.

Ti consigliamo anche

Link copiato negli appunti