Questo capitolo descrive le variabili di configurazione per la NVRAM e i comandi della OpenBoot PROM (OBP) disponibili per configurare i seguenti aspetti del comportamento del sistema Sun Enterprise 250:
Le variabili di configurazione della NVRAM descritte in questo capitolo sono:
upa-port-skip-list
pci0-probe-list
pci-slot-skip-list
env-monitor
asr-disable-list
auto-boot-on-error?
diag-trigger
I comandi OBP descritti in questo capitolo sono:
asr-enable
asr-disable
.asr
I server Sun Enterprise 250, come tutti i sistemi basati su processori UltraSPARC(TM), utilizzano il bus ad alta velocità UPA (Ultra Port Architecture), un bus di sistema a commutazione che supporta fino a 32 porte (o slot) di indirizzamento per dispositivi della scheda madre come CPU, bridge di I/O e frame buffer. Il server Enterprise 250 fornisce fino a tre porte attive per i seguenti sottosistemi.
Tabella 1-1 Porte bus di sistema UPA
Tipo di dispositivo |
Slot UPA |
Implementazione fisica |
---|---|---|
CPU |
0-1 |
Due slot plug-in |
Bridge UPA-PCI |
1f |
Saldato sulla scheda madre |
L'ordine di controllo degli ID di queste tre porte non è modificabile dall'utente; tuttavia, è possibile escludere dal controllo un certo numero di porte impostando la variabile upa-port-skip-list della NVRAM. Nell'esempio seguente, la variabile upa-port-skip-list viene usata per escludere CPU-1 dal controllo dei dispositivi UPA.
ok setenv upa-port-skip-list 1
Questo metodo permette di escludere un certo dispositivo dal controllo (e quindi dall'uso) del sistema senza rimuovere fisicamente la scheda plug-in. Può perciò essere utile per isolare una scheda difettosa in un sistema che presenti problemi occasionali.
Dei due bus PCI del server Enterprise 250, il Bus 0 (/pci@1f,4000 nella gerarchia dei dispositivi) ha la particolarità di essere l'unico bus PCI a contenere dispositivi della scheda madre (non plug-in) come il controller SCSI integrato. Per definizione, questi dispositivi non possono essere scollegati o intercambiati per modificare l'ordine del controllo. Per cambiare l'ordine di controllo di questi dispositivi, si può utilizzare la variabile della NVRAM pci0-probe-list. Questa variabile permette di impostare sia l'ordine di controllo che l'esclusione dei dispositivi sul bus PCI 0. I valori che è possibile utilizzare con pci0-probe-list sono specificati nella tabella seguente.
Tabella 1-2 Valori di Probe
Numero del dispositivo PCI |
Funzione |
---|---|
2 |
Slot PCI 2 (come da etichetta sul pannello posteriore del sistema) |
3 |
Controller SCSI integrato per dispositivi SCSI interni ed esterni |
4 |
Slot PCI 1 (come da etichetta sul pannello posteriore del sistema) |
5 |
Slot PCI 0 (come da etichetta sul pannello posteriore del sistema) |
I valori di questa lista si riferiscono al numero dei dispositivi PCI e non alla numerazione degli slot del pannello posteriore (0-3).
Nell'esempio seguente, la variabile pci0-probe-list definisce l'ordine di controllo 5-2-4 ed esclude dal controllo il controller SCSI integrato per dispositivi SCSI interni ed esterni.
ok setenv pci0-probe-list 5,2,4
Si noti che la variabile pci0-probe-list non ha effetto sul controllo dello slot PCI superiore (lo slot 3 nel pannello posteriore del sistema). È però disponibile un'altra variabile della NVRAM, pci-slot-skip-list, che permette di escludere qualsiasi slot PCI dal controllo PCI. Nell'esempio seguente, la variabile pci-slot-skip-list è configurata in modo da escludere gli slot 0 e 3 del pannello posteriore dal controllo PCI.
ok setenv pci-slot-skip-list 0,3
I valori usati in pci-slot-skip-list fanno riferimento alla numerazione 0-3 del pannello posteriore. Se il numero di uno slot PCI è incluso in questa lista, esso viene escluso dal controllo anche se appare nella variabile pci0-probe-list.
Le funzioni di monitoraggio e controllo ambientale dei server Enterprise 250 risiedono sia a livello del sistema operativo che a livello del firmware OBP. Questo assicura che siano operative anche quando il sistema è stato arrestato o non è in grado di eseguire il boot. Il modo in cui la OBP verifica e reagisce alle condizioni ambientali e di temperatura è controllato dalla variabile della NVRAM env-monitor. La tabella seguente mostra le possibili impostazioni di questa variabile e i relativi effetti sul comportamento della OBP. Per maggiori informazioni sulle capacità di monitoraggio ambientale del sistema, vedere "Informazioni sulle caratteristiche di affidabilità, disponibilità e riparabilità"nel Manuale dell'utente per Server Enterprise 250 Sun.
Tabella 1-3 Valori ed effetti della variabile Environmental Monitor
Impostazione |
Il monitor è attivo? |
Azione risultante |
---|---|---|
enabled (valore predefinito) |
Sì |
In risposta a una condizione di surriscaldamento critica, la OBP genera un avvertimento e arresta automaticamente il sistema dopo 30 secondi. |
advise |
Sì |
La OBP genera solo un avvertimento, senza arrestare il sistema. |
disabled |
No |
La OBP non esegue alcuna azione; il monitoraggio ambientale a livello della OBP è disabilitato. |
Nell'esempio seguente, la variabile env-monitor è configurata in modo da disabilitare il monitoraggio ambientale a livello della OBP.
ok setenv env-monitor disattivata
Questa variabile della NVRAM non ha effetti sulle capacità di monitoraggio e controllo ambientale del sistema mentre il sistema operativo è in funzione.
La funzione Automatic System Recovery (ASR) permette al server Enterprise 250 di riprendere il funzionamento automaticamente dopo determinati guasti o errori hardware. Il test di avvio POST e la diagnostica OpenBoot Diagnostics (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.
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.
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").
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.
L'identificazione e l'isolamento dei problemi di memoria sono tra le operazioni diagnostiche più difficili. Il problema è complicato ulteriormente dalla possibilità di installare DIMM di capacità differente nello stesso banco di memoria. (Ogni banco di memoria deve contenere quattro DIMM di uguale capacità.) In caso di guasto di un componente della memoria, il firmware deconfigura l'intero banco associato all'errore.
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.
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@1f,2000 /pci@1f,4000/scsi@3,1
La OBP Enterprise 250 userà queste informazioni per creare la proprietà di stato "disabled" per ogni nodo elencato nella variabile asr-disable-list.
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.
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.
È possibile generare una lista di parametri validi per asr-disable e asr-enable definendo entrambi i comandi senza parametri.
ok asr-disable ? Invalid subsystem name: Known 'enable/disable' subsystem components are: bank* bank3 bank2 bank1 bank0 dimm15 dimm14 dimm13 dimm12 dimm11 dimm10 dimm9 dimm8 dimm7 dimm6 dimm5 dimm4 dimm3 dimm2 dimm1 dimm0 cpu* cpu1 cpu0 ok
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 SC-MP: Enabled Psycho@1f: Enabled Cheerio: Enabled SCSI: Enabled Mem Bank0: Enabled Mem Bank1: Enabled Mem Bank2: Enabled Mem Bank3: Disabled PROM: Enabled NVRAM: Enabled TTY: Enabled SuperIO: Enabled PCI Slots: Enabled
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 Enterprise 250 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
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.
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?.
Per supportare la funzione ASR sui server Enterprise 250, è 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? in true, un'operazione che produce altri effetti collaterali (vedere il documento OpenBoot 3.x Command Reference Manual), la OBP Enterprise 250 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.
diag-trigger ha effetto solo se la variabile diag-switch? è impostata su true.
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