I det här kapitlet beskriver vi de NVRAM-konfigurationsvariabler och OpenBoot PROM- (OBP-) kommandon som finns för konfigurering av följande Sun Enterprise 250-funktioner:
De NVRAM-konfigurationsvariabler som behandlas i kapitlet är:
upa-port-skip-list
pci0-probe-list
pci-slot-skip-list
env-monitor
asr-disable-list
auto-boot-on-error?
diag-trigger
De OBP-kommandon som behandlas är:
asr-enable
asr-disable
.asr
Sun Enterprise 250-servrar bygger, precis som alla andra UltraSPARC(TM)-baserade system, på den mycket snabba Ultra Port Architecture-bussen (UPA-bussen). Det är en växlad systembuss som kan ha upp till 32 port-ID-adresser (eller platser) för höghastighetsenheter på moderkort, som CPU:er, I/O-bryggor och bildskärmsminnen. Enterprise 250 innehåller upp till tre aktiva portar för följande delsystem.
Tabell 1-1 UPA-systembussportar
Typ av enhet |
UPA-plats |
Fysisk lösning |
---|---|---|
CPU |
0-1 |
Två insättningsplatser |
UPA-PCI-brygga |
1f |
Fastlödd på moderkort |
Användaren kan inte styra i vilken ordning de tre portarna avkänns; men han kan se till att vissa portar inte avkänns genom NVRAM-variabeln upa-port-skip-list. I följande exempel används variabeln upa-port-skip-list för att hindra att CPU-1 skall finnas med i UPA-avkänningslistan.
ok setenv upa-port-skip-list 1
Denna funktion gör det möjligt att hindra att en viss enhet avkänns (och därmed används) av systemet utan att man fysiskt tar ur kortet med enheten. Detta kan vara användbart när du vill isolera ett trasigt kort i ett system där sporadiska fel inträffar.
Av Enterprise 250:s två PCI-bussar är buss 0 (/pci@1f,4000 i enhetsträdet) unik på så sätt att den är den enda PCI-buss som innehåller moderkortsenheter (icke isatta enheter) som t.ex. den inbyggda SCSI-styrenheten. Per definition kan man inte ta ur dessa och låta dem byta plats för att därmed ändra i vilken ordning de avkänns. För att styra avkänningsordningen för dessa enheter finns NVRAM-variabeln pci0-probe-list. Denna variabel styr både i vilken ordning enheterna avkänns och vilka som hoppas över på PCI-buss 0. Värdena i pci0-probe-list definieras i tabellen nedan.
Tabell 1-2 Probe Values
PCI-enhetsnummer |
Funktion |
---|---|
2 |
PCI-plats 2 (enligt etiketten på systemets bakpanel) |
3 |
Inbyggd SCSI-styrenhet för interna och externa SCSI-enheter |
4 |
PCI-plats 1 (enligt etiketten på systemets bakpanel) |
5 |
PCI-plats 0 (enligt etiketten på systemets bakpanel) |
Värdena i den här listan är baserade på PCI-enhetsnumret och avser inte numreringen 0-3 av kortplatserna på baksidan.
I följande exempel används variabeln pci0-probe-list för att ange avkänningsordningen 5-2-4, vilket förhindrar att den inbyggda SCSI-styrenheten för interna och externa SCSI-enheter avkänns.
ok setenv pci0-probe-list 5,2,4
Tänk på att variabeln pci0-probe-list inte påverkar avkänningen av den övre PCI-kortplatsen (plats 3 på systemets bakpanel). Det finns dock en annan NVRAM-variabel, pci-slot-skip-list, som man kan använda för att förhindra avkänning av vilken kortplats som helst. I följande exempel används variabeln pci-slot-skip-list för att hindra avkänning av kortplatserna 0 och 3 på bakpanelen.
ok setenv pci-slot-skip-list 0,3
Värdena i pci-slot-skip-list motsvarar numreringen 0-3 på bakpanelen. Om ett PCI-kortplatsnummer finns med på denna lista, kommer det inte att avkännas även om det står med i variabeln pci0-probe-list.
Funktionerna för miljöövervakning och -styrning i Enterprise 250 ligger både på operativsystemnivå och i den inbyggda OBP-programvaran. Detta säkerställer att övervakningsfunktionerna fungerar även om systemet har stannat eller inte går att starta. Hur OBP övervakar och reagerar på överhettning i miljön styrs av NVRAM-variabeln env-monitor. Följande tabell visar de olika möjliga inställningarna för variabeln och vilken effekt de har på hur OBP agerar. Mer information om systemets miljöövervakningsfunktioner finns i "Funktioner för tillförlitlighet, tillgänglighet och för att underlätta service" i Sun Enterprise 250 Server Användarhandbok.
Tabell 1-3 Värden för miljöövervakning och effekter
Inställning |
Övervakning aktiv? |
Reaktion |
---|---|---|
enabled (standard) |
Ja |
Som svar på ett kritiskt överhettningstillstånd visar OBP en varning och stänger automatiskt av systemet efter 30 sekunder. |
advise |
Ja |
OBP visar endast en varning, utan att stänga av systemet. |
disabled |
Nej |
OBP gör ingenting; miljöövervakning på OBP-nivå är deaktiverad. |
I följande exempel används variabeln env-monitor för att deaktivera miljöövervakning på OBP-nivå.
ok setenv env-monitor disabled
Variabeln påverkar inte operativsystemets funktioner för miljöövervakning och -styrning.
Funktionen automatisk systemåterhämtning (ASR) gör att Enterprise 250 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.
För att stödja funktionen med nedminskad start använder OBP klientgränssnittet IEEE 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.
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-status, som innehåller den ändringsinformation som antingen kommer från POST eller via en manuell användarändring (se "Funktion för att explicit ange ASR-inställningar").
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.
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.) Om den inbyggda programvaran upptäcker en trasig minneskomponent kommer den att avkonfigurera hela den bank som komponenten sitter i.
Även om standardinställningarna konfigurerar eller avkonfigurerar servern korrekt i de flesta fall, kan det vara lämpligt att avancerade användare själva anger 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.
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@1f,2000 /pci@1f,4000/scsi@3,1
Enterprise 250 OBP använder denna information för att skapa deaktiverade status-egenskaper för varje nod som finns i variabeln asr-disable-list.
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.
Det finns överlappningar mellan mjuka och hårda egna inställningar. Det finns överlappningar mellan mjuka och hårda egna inställningar. Om det går skall du använda de "hårda" kommandona asr-enable och asr-disable.
Du kan få fram en lista med de giltiga parametrarna för asr-disable och asr-enable genom att starta endera kommandot utan parametrar.
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
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 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 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, så därför innehåller Enterprise 250:s OBP en andra NVRAM-styrd 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
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 absolut inte går att fortsätta efter, är när båda CPU:erna i systemet har deaktiverats, antingen genom felaktig POST eller till följd av att användaren gjort en manuell inställning.
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 på Enterprise 250 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 Enterprise 250: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
diag-trigger har ingen effekt om inte diag-switch? är true.
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 eller 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