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

Capitolo 2 Parametri di configurazione del sistema

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 Ultra 450:

Le variabili di configurazione della NVRAM descritte in questo capitolo sono:

I comandi OBP descritti in questo capitolo sono:

Controllo UPA

I sistemi Ultra 450, 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.Sebbene la maggior parte dei sistemi Ultra dispongano di sole tre o quattro porte UPA attive, i sistemi Ultra 450 forniscono sino a nove porte suddivise tra i seguenti sottosistemi:

Tabella 2-1 Porte attive

Tipo di dispositivo 

Slot UPA 

Implementazione fisica 

CPU 

0-3 

Quattro slot plug-in 

Bridge UPA-PCI 

4,6,1f 

Saldato sulla scheda madre 

Frame buffer grafico UPA 

1d, 1e  

Due slot plug-in 

L'ordine di controllo degli ID di queste 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 4, 1d

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.

Controllo PCI

Dei sei bus PCI del sistema Ultra 450, 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 i controller standard SCSI e Ethernet. 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 2-2 Valori in pci0-probe-list

Numero del dispositivo PCI 

Funzione 

0

Bridge del bus UPA-PCI (non controllato) 

1

 Interfaccia EBus/Ethernet (sempre controllata, mai inclusa nell'elenco dei dispositivi da controllare)

2

Controller SCSI integrato per dispositivi removibili e porte SCSI esterne 

3

Controller SCSI integrato per i 4 slot UltraSCSI del pannello posteriore 

4

Slot PCI 10 del pannello posteriore 


Nota -

I valori di questa lista si riferiscono al numero dei dispositivi PCI e non alla numerazione degli slot del pannello posteriore (1-10).


Nell'esempio seguente, la variabile pci0-probe-list definisce l'ordine di controllo 3-4, ed esclude dal controllo il controller SCSI integrato per dispositivi removibili e la porta SCSI esterna.


ok setenv pci0-probe-list 3,4

L'ordine di controllo degli altri cinque bus PCI (slot PCI da 1 a 9) non può essere modificato dall'utente. Questi slot vengono sempre controllati nel seguente ordine: 5-3-2-1-4-9-8-7-6. È però disponibile un'altra variabile della NVRAM, pci-slot-skip-list, che permette di escludere qualsiasi slot PCI dalla procedura di controllo. Nell'esempio seguente, la variabile pci-slot-skip-list è configurata in modo da escludere gli slot 3 e 8 del pannello posteriore dal controllo PCI.


ok setenv pci-slot-skip-list 3,8


Nota -

I valori usati in pci-slot-skip-list fanno riferimento alla numerazione 1-10 del pannello posteriore. Gli slot PCI inclusi in questa lista vengono esclusi dal controllo anche se la variabile pci0-probe-list, include il dispositivo numero 4 (slot 10 del pannello posteriore).


Interleaving della memoria

Nei sistemi Ultra 450, l'interleaving della memoria è controllato dalla variabile della NVRAM memory-interleave. La tabella seguente mostra le possibili impostazioni di questa variabile e i relativi effetti sulla configurazione della memoria. Per una trattazione più approfondita dell'interleaving e della configurazione della memoria, vedere la sezione "Informazioni sulla memoria" nel manuale dell'utente del sistema Ultra 450.

Tabella 2-3 Impostazioni della variabile memory-interleave

Impostazione 

Effetto sulla configurazione della memoria 

auto (valore predefinito)

Abilita l'interleaving a quattro vie se tutti i quattro banchi di memoria contengono DIMM della stessa capacità. Abilita l'interleaving a due vie se vengono usati solo i banchi A e B ed entrambi i banchi contengono DIMM della stessa capacità. Diversamente, l'interleaving è disabilitato. 

max-size

Ha lo stesso effetto dell'impostazione auto per i sistemi Ultra 450.

max-interleave

Abilita il massimo livello di interleaving possibile per una data configurazione di memoria, ma una parte della memoria rimane inutilizzata se i DIMM installati hanno capacità differenti. All'interno di ogni DIMM, viene usata una quantità di memoria pari alla capacità dei DIMM più piccoli installati. 

1

Disabilita l'interleaving; utilizza tutta la capacità di memoria disponibile. 

2

Forza l'interleaving a due vie tra i banchi A e B. Una parte della memoria rimane inutilizzata se i DIMM installati hanno capacità differenti. I DIMM di capacità inferiore devono essere installati nel banco B. I banchi C e D, se occupati, rimangono inutilizzati. 

4

Forza l'interleaving a quattro vie tra tutti i banchi. Una parte della memoria rimane inutilizzata se i DIMM installati hanno capacità differenti. I DIMM di capacità inferiore devono essere installati nel banco D. 

L'esempio seguente mostra come configurare il sistema per ottenere il massimo interleaving della memoria.


ok setenv memory-interleave max-interleave

Monitoraggio e controllo ambientale

Le funzioni di monitoraggio e controllo ambientale dei server 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 la sezione "Informazioni sulle caratteristiche di affidabilità, disponibilità e riparabilità" del Manuale dell'utente del sistema Ultra 450.

Tabella 2-4 Impostazioni della variabile env-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 disabled


Nota -

Questa variabile della NVRAM non ha effetti sulle capacità di monitoraggio e controllo ambientale del sistema mentre il sistema operativo è in funzione.


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