Note sulla piattaforma: Workstation Sun Ultra 450 e Server Ultra Enterprise 450

Automatic System Recovery

La funzione Automatic System Recovery (ASR) permette al sistema 450 di riprendere il funzionamento automaticamente dopo determinati guasti o errori hardware. I test di avvio (POST) e la diagnostica OpenBoot (OBDiag) possono rilevare automaticamente i componenti hardware difettosi, mentre la capacità di auto-configurazione integrata nel firmware della OBP permette al sistema di deconfigurare i componenti guasti e di ripristinare il funzionamento del server. Se il sistema è in grado di operare anche senza il componente guasto, la funzione ASR lo riavvia automaticamente, senza bisogno che intervenga l'operatore. Questo "boot degradato" permette al sistema di continuare a operare mentre viene generata una chiamata di assistenza per la sostituzione della parte guasta.

Se viene rilevato il malfunzionamento di un componente durante la sequenza di accensione, il componente viene deconfigurato e, se il sistema può funzionare anche senza quell'elemento, la procedura di boot continua. Nei sistemi in funzione, alcuni tipi di guasti (come un errore di un processore) possono causare un ripristino automatico del sistema. In questo caso, la funzionalità ASR permette al sistema di riavviarsi immediatamente, a condizione che possa operare senza il componente guasto. Questo impedisce che un problema a un componente hardware blocchi l'intero sistema o causi un ulteriore crash.

Deconfigurazione "transitoria" mediante le proprietà di stato

Per supportare il boot degradato, la OBP utilizza l'interfaccia client IEEE 1275 (attraverso la gerarchia dei dispositivi) per "contrassegnare" i dispositivi come failed (guasti) o disabled (disabilitati), creando cioè una proprietà di "stato" appropriata nel nodo corrispondente della gerarchia dei dispositivi. Per convenzione, UNIX non attiva nessun driver per i sottosistemi contrassegnati in questo modo.

Fino a quando il componente difettoso rimane elettricamente inattivo (cioè non può causare errori di bus o disturbi di segnale casuali, ecc.), il sistema può riavviarsi automaticamente e riprendere a funzionare mentre viene generata una chiamata di assistenza.

Deconfigurazione "attiva"

Quando la deconfigurazione riguarda i sottosistemi della CPU e della memoria, la OBP non si limita a creare una proprietà di "stato" appropriata nella gerarchia dei dispositivi, ma esegue una vera e propria azione. Subito dopo il ripristino, la OBP deve inizializzare e configurare (o escludere) funzionalmente queste funzioni per far sì che il resto del sistema possa operare correttamente. Queste azioni vengono eseguite in base allo stato di due variabili di configurazione della NVRAM, post-status e asr-status, che contengono informazioni prioritarie provenienti dal POST o da un'operazione manuale dell'utente (vedere "Priorità dell'utente sulla funzione ASR").

Deconfigurazione della CPU

Se una CPU non supera i test POST, o se l'utente sceglie di disabilitare una CPU, la OBP configura il bit Master Disable di quella CPU, sostanzialmente disattivandola come dispositivo UPA fino al successivo ciclo di accensione del sistema.

Deconfigurazione della memoria

L'identificazione e l'isolamento dei problemi di memoria sono tra le operazioni diagnostiche più difficili. Il problema è complicato ulteriormente dalle diverse modalità di interleaving della memoria del sistema, e dalla possibilità di installare DIMM di capacità differente nello stesso banco di memoria.

In caso di guasto di un componente della memoria, il firmware deconfigura l'intero banco associato all'errore. Questo significa che una configurazione degradata può comportare l'uso di un fattore di interleaving inferiore, un utilizzo inferiore al 100% dei banchi restanti o entrambe le soluzioni, a seconda del fattore di interleaving.

Priorità dell'utente sulla funzione ASR

Anche se, nella maggior parte dei casi, le impostazioni predefinite configurano e deconfigurano il server in modo corretto, è utile fornire agli utenti avanzati una capacità di intervento manuale. Data la diversità tra la deconfigurazione "transitoria" e quella "attiva", è necessario disporre di due meccanismi di intervento, correlati ma differenti.

Deconfigurazione "transitoria" manuale

Ogni sottosistema rappresentato da un nodo distinto nella gerarchia dei dispositivi può essere disabilitato dall'utente attraverso la variabile della NVRAM asr-disable-list, che è un semplice elenco di percorsi di dispositivi separati da spazi.

ok setenv asr-disable-list /pci/ebus/ecpp /pci@1f,4000/scsi@3

La OBP del sistema Ultra 450 userà queste informazioni per creare la proprietà di stato "disabled" per ogni nodo elencato nella variabile asr-disable-list.

Deconfigurazione "attiva" manuale

Per intervenire sui sottosistemi che richiedono una deconfigurazione "attiva" (CPU e memoria), si utilizzano i comandi della OBP asr-enable e asr-disable per abilitare o disabilitare selettivamente ogni sottosistema.

Nota -

Le deconfigurazioni manuali di tipo transitorio e attivo si possono sovrapporre. Se possibile, si dovrebbero usare i comandi della deconfigurazione "attiva", asr-enable e asr-disable.

Per controllare lo stato delle operazioni manuali, è disponibile un nuovo comando, .asr, che riassume le impostazioni correnti.

ok asr-disable cpu1 bank3
ok .asr
CPU0:	Enabled	
CPU1:	Disabled	
CPU2:	Enabled	
CPU3:	Enabled	
SC-Marvin:	Enabled	
Psycho@1f:	Enabled	
Psycho@4:	Enabled	
Psycho@6:	Enabled	
Cheerio:	Enabled	
SCSI:	Enabled	
Mem Bank0:	Enabled	
Mem Bank1:	Enabled	
Mem Bank2:	Enabled	
Mem Bank3:	Disabled	
PROM:	Enabled	
NVRAM:	Enabled	
TTY:	Enabled	
Audio:	Enabled	
SuperIO:	Enabled	
PCI Slots:	Enabled

Opzioni per il boot automatico

OpenBoot dispone di uno switch controllato dalla NVRAM, denominato auto-boot?, che indica se la OBP debba avviare automaticamente il sistema operativo dopo ogni ripristino. L'impostazione predefinita di questo switch per le piattaforme Sun è true.

Se il sistema non supera i test diagnostici di accensione, lo switch auto-boot? viene ignorato e il sistema può essere avviato solo con un comando manuale dell'utente. Questo comportamento non è accettabile per i casi di boot degradato, perciò la OBP del sistema Ultra 450 dispone di un secondo switch controllato dalla NVRAM denominato auto-boot-on-error?. Questo switch determina se il sistema debba cercare di eseguire un boot degradato in caso di malfunzionamento di un sottosistema. Per consentire l'esecuzione di un boot degradato, entrambi gli switch auto-boot? e auto-boot-on-error? devono essere configurati come true.

ok setenv auto-boot-on-error? true

Nota -

La configurazione predefinita per auto-boot-on-error? è false. Il sistema non cercherà di eseguire un boot degradato, a meno che questa impostazione non venga modificata in true. Inoltre, il sistema non cercherà di eseguire un boot degradato in risposta ad errori fatali non correggibili, anche se il boot degradato è abilitato. Un esempio di errore fatale non correggibile si ha quando entrambe le CPU del sistema sono state disabilitate, per mancato superamento del POST o in seguito a un intervento manuale dell'utente.

Scenari di ripristino

Il protocollo standard per il ripristino del sistema esclude completamente la diagnostica del firmware. Per abilitarla, è necessario cambiare da false a true la configurazione della variabile della NVRAM diag-switch?. Il valore predefinito per questa variabile è false.

Per supportare la funzione ASR sui server, è opportuno poter eseguire la diagnostica del firmware (POST/OBDiag) in tutti gli eventi di ripristino. Invece di cambiare semplicemente l'impostazione predefinita di diag-switch? su true, un'operazione che produce altri effetti collaterali (vedere il documento OpenBoot 3.x Command Reference Manual), la OBP del sistema Ultra 450 OBP dispone di una nuova variabile della NVRAM, denominata diag-trigger, che permette di scegliere quali eventi di ripristino debbano attivare automaticamente un ciclo di POST/OBDiag. La tabella seguente descrive la variabile diag-trigger e le sue possibili impostazioni.

Nota -

diag-trigger ha effetto solo se la variabile diag-switch? è impostata su true.

Tabella 2-5 Impostazioni di power-reset, error-reset e soft-reset


Impostazione	Funzione
`power-reset` (valore predefinito)	Esegue le funzioni diagnostiche solo nei cicli di accensione.
`error-reset`	Esegue le funzioni diagnostiche solo nei cicli di accensione, in caso di errori hardware fatali e in risposta ad eventi di ripristino watchdog.
`soft-reset`	Esegue le funzioni diagnostiche in tutti gli eventi di ripristino (ad eccezione di XIR), inclusi quelli provocati dai comandi UNIX `init` `6` o `reboot`
`none`	Disabilita l'attivazione automatica delle funzioni diagnostiche in caso di eventi di ripristino. L'utente può comunque attivare la diagnostica manualmente premendo i tasti Stop e d durante l'accensione del sistema, oppure spostando l'interruttore del pannello frontale in posizione Diagnostics all'accensione del sistema.

Nell'esempio seguente, la variabile diag-trigger è configurata per attivare le funzioni diagnostiche POST e OpenBoot in tutte le operazioni di ripristino ad eccezione degli eventi XIR.

ok setenv diag-switch? true
ok setenv diag-trigger soft-reset