Plattformsinformation: Sun Ultra 450 Workstation och Ultra Enterprise 450 Server

Automatisk systemåterhämtning

Funktionen automatisk systemåterhämtning (ASR) gör att du kan fortsätta efter det att vissa maskinvarufel har upptäckts. Självtestet vid-påslag (POST) och OpenBoot-diagnostik (OBDiag) kan automatiskt upptäcka trasiga maskinvarukomponenter, och med en auto-konfigureringsfunktion i den inbyggda OBP-programvaran kan sådana trasiga komponenter avkonfigureras och systemet köra som vanligt. Så länge som systemet kan fungera utan den trasiga komponenten, låter ASR-funktionerna systemet starta om automatiskt utan att operatören måste gripa in. Med en sådan "nedminskad start" kan systemet fortsätta fungera medan ett serviceanrop görs om att den trasiga porten måste ersättas.

Om en trasig komponent upptäcks under starten avkonfigureras komponenten, och om systemet kan fortsätta fungera utan den, fortsätter starten. Medan systemet körs kan vissa typer av fel (som processorfel) initiera en automatisk omstart. Om detta inträffar låter ASR-funktionerna systemet starta om omedelbart, förutsatt att systemet kan fungera utan den trasiga komponenten. Detta ser till att en enstaka trasig maskinvarukomponent inte kan hindra hela systemet från att fungera.

"Mjuk" avkonfigurering via statusegenskap

För att stödja funktionen med nedminskad start använder OBP klientgränssnittet 1275 (via enhetsträdet) för att "markera" att vissa enheter antingen är trasiga eller deaktiverade genom att skapa en passande "status-"egenskap i motsvarande enhetsträdnod Enligt reglerna kommer UNIX inte att aktivera en drivrutin för något delsystem som är markerat på detta sätt.

Därför, så länge som den felaktiga komponenten inte stör elektriskt (inte skapar slumpmässiga bussfel eller signalbrus etc.), kan systemet startas om automatiskt och fortsätta fungera medan ett serviceanrop görs.

"Hård" avkonfigurering

I två specialfall av avkonfigurering av delsystem (CPU:er och minne) gör OBP mer än bara skapa en passande "status"-egenskap i enhetsträdet. Alldeles efter omstarten måste OBP initieras och på ett funktionellt sätt konfigurera (eller hoppa över) dessa funktioner för att resten av systemet skall fungera korrekt. Dessa åtgärder utförs beroende på status hos två NVRAM-konfigurationsvariabler, post-status och asr-statussom innehåller den ändringsinformation som antingen kommer från POST eller via en manuell användarändring (se "Explicit angivelse av ASR-inställningar").

CPU-avkonfigurering

Om någon CPU markeras vara felaktig under POST, eller om användaren väljer att deaktivera en CPU, kommer OBP att sätta huvuddeaktiverad-biten för den skadade processorn.

Minnesavkonfigurering

Att upptäcka och isolera minnesproblem är en av de svårare diagnostikuppgifterna. Den kompliceras ytterligare av möjligheten att installera DIMM:ar med olika kapacitet inom en och samma minnesbank.

(Varje minnesbank måste innehålla fyra DIMM:ar med samma kapacitet.). Detta handlingssätt innebär även att den nedminskade konfigurationen kan sänka mellanrumsfaktorn eller göra så att mindre än 100% av de kvarvarande bankarna används, eller bådadera beroende på mellanrumsfaktorn.

Explicit angivelse av ASR-inställningar

Även om standardinställningarna konfigurerar eller avkonfigurerar Ultra 450 korrekt i de flesta fall, är det användbart för avancerade användare att själva ange inställningarna explicit. P.g.a. naturen hos "mjuk" och "hård" avkonfigurering är det nödvändigt att ha två likartade men ändå olika mekanismer för att ange inställningarna explicit.

Ange egna inställningar för "mjuk" avkonfigurering

För alla delsystem som har en bestämd enhetsträdnod kan användaren deaktivera genom NVRAM-variabeln asr-disable-list, som helt enkelt är en lista med enhetsträdssökvägar, skilda av mellanslag.

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

Ultra 450:s OBP använder denna information för att skapa deaktiverade status-egenskaper för varje nod som finns i variabeln asr-disable-list.

Ange egna inställningar för "hård" avkonfigurering

För att ange egna inställningar för de delsystem som kräver "hård" avkonfigurering (CPU och minne) finns OBP-kommandona asr-enable och asr-disable Med dem väljer man vilka delsystem som skall aktiveras eller deaktiveras.

Obs!

Det finns dubbletter mellan explicita inställningar för mjuk och hård avkonfigurering. Om möjligt skall du använda kommandona för hård avkonfigurering, asr-enable och asr-disable.

För att hålla reda på status för alla manuella egna inställningar finns ett nytt användarkommando, .asr, för att visa en lista med de aktuella inställningarna

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

Auto-startinställningar

OpenBoot innehåller en NVRAM-styrd inställning vid namn auto-boot?, som styr om OBP skall starta operativsystemet automatiskt efter varje omstart. Standardinställningen för Sun-plattformar är true.

Om ett system inte klarar diagnosstegen när det slås på, ignoreras auto-boot? och systemet kan endast startas manuellt av användaren. Detta beteende är ju uppenbart oacceptabelt vid en nedminskad start och därför innehåller Ultra 450:s OBP en andra NVRAMstyrd inställning, auto-boot-on-error?. Denna inställning styr om systemet skall försöka sig på en nedminskad start, när ett delsystemfel upptäcks. Både auto-boot? och auto-boot-on-error? måste vara true för att en nedminskad start skall genomföras.

ok setenv auto-boot-on-error? true

Obs!

Standardinställningen för auto-boot-on-error? är false. Därför kommer inte systemet att försöka utföra en nedminskad start, om du inte ändrar inställningen till true. Dessutom kommer systemet inte att utföra en nedminskad start om det föreligger ett fel som det inte går att fortsätta efter, även om nedminskad start är aktiverad. Ett exempel på ett fel, som det inte går att fortsätta efter, är när alla systemets CPU:er har deaktiverats, antingen genom felaktig POST eller till följd av en manuell användarinställning.

Omstartscenarier

Standardprotokollet för systemomstart hoppar över diagnostiken i den inbyggda programvaran helt och hållet, om inte NVRAM-variabeln diag-switch? är true. Standardinställningen för variabeln är false.

För att ASR i Ultra 450 skall stödjas är det önskvärt att köra diagnostiken i den inbyggda programvaran (POST/OBDiag) vid några eller alla omstarter. I stället för att helt enkelt ändra standardinställningen för diag-switch? till true, vilket skulle ge vissa biverkningar, (se OpenBoot 3.x Command Reference Manual), har Ultra 450:s OBP en ny NVRAM-variabel, diag-trigger. Med den kan du välja om några omstarter skall starta POST/OBDiag automatiskt och i så fall vilka. Variabeln diag-trigger och dess olika inställningar beskrivs i följande tabell.

Obs!

diag-trigger har ingen effekt om inte diag-switch? är true.

Tabell 2-5 Inställningar för variablerna power-reset, error-reset och soft-reset


Inställning	Funktion
`power-reset` (standard)	Kör diagnostik endast när systemet startas genom att det slås på med -strömbrytaren.
`error-reset`	Kör diagnostik bara vid -påslagsomstarter, allvarliga maskinvarufel och vakthundsomstarthändelser.
`soft-reset`	Kör diagnostik vid alla omstarter (utom XIR), inklusive omstarter initierade av UNIX-kommandona `init` `6` och `reboot`
`none`	Deaktiverar automatisk exekvering av diagnostik vid alla omstarter. Användare kan fortfarande köra diagnostik manuellt genom att hålla ner tangenterna Stop och d medan systemet slås på, eller genom att vrida tangentswitchen på frontpanelen till läge Diagnostik, när systemet slås på.

I följande exempel används diag-trigger för att POST och OpenBoot-diagnostik skall köras vid alla omstarter utom XIR-omstarter.

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