Notas sobre la plataforma: estación de trabajo Sun Ultra 450 y servidor Ultra Enterprise 450

Recuperación automática del sistema

La recuperación automática del sistema o ASR (acrónimo de Automatic System Recovery) permite al sistema Ultra 450 reanudar el funcionamiento después de experimentar determinados fallos de hardware. Las funciones Power-on self-test (POST) y OpenBoot diagnostics (OBDiag) pueden detectar automáticamente los componentes de hardware que han fallado, y una función de configuración automática diseñada en el firmware de OBP permite al sistema desconfigurar dichos componentes y restaurar el funcionamiento del sistema. En tanto el sistema sea capaz de funcionar sin el componente desactivado, las funciones de ASR harán que el sistema rearranque automáticamente sin la intervención del operador. Este "arranque degradado" permite al sistema seguir funcionando mientras se efectúa una llamada al servicio técnico para sustituir la pieza defectuosa.

Si se detecta el fallo de un componente durante la secuencia de encendido, éste se desconfigura y, si el sistema es capaz de funcionar sin él, la secuencia de arranque continúa. En un sistema en ejecución, determinados tipos de fallos (como el de un procesador) pueden provocar la restauración automática del sistema. Si esto ocurre, las funciones de ASR permiten el rearranque inmediato, siempre que el sistema pueda funcionar sin el componente que ha fallado. Esto impide que una pieza de hardware mantenga todo el sistema inactivo o vuelva a provocar su detención.

Desconfiguración básica mediante la propiedad de estado

Para poder efectuar el arranque degradado, la OBP utiliza la norma IEEE 1275 Client Interface (a través del árbol de dispositivos) para "marcar" los dispositivos como fallido o desactivado mediante la creación de una propiedad de "estado" adecuada en el nodo correspondiente del árbol de dispositivos. Por convención, UNIX no activará ningún controlador para cualquier subsistema marcado de esta manera.

Así, siempre que el componente defectuoso esté inactivo en términos de electricidad (es decir, no pueda causar errores aleatorios de bus, ruido, etc.), el sistema podrá rearrancar automáticamente y reanudar el funcionamiento mientras acude el servicio técnico para sustituir la pieza.

Desconfiguración avanzada

En dos casos especiales de desconfiguración de un subsistema (CPU y memoria), la OBP hace algo más que crear una propiedad de "estado" en el árbol de dispositivos. Inmediatamente después de la restauración del sistema, la OBP debe inicializar y configurar (o ignorar) estas funciones para que el resto del sistema pueda funcionar correctamente. Estas acciones se emprenden en función del estado de dos variables de configuración NVRAM, post-status y asr-status, que contienen la información suministrada por la función POST o especificada manualmente por el usuario (consulte "Valores de ASR definidos por el usuario").

Desconfiguración de la CPU

Si el valor de POST indica que una CPU ha fallado, o si un usuario decide deshabilitarla, la OBP activa su bit Master Disable que, básicamente, desactiva la CPU como dispositivo UPA hasta la siguiente vez que se enciende el sistema.

Desconfiguración de la memoria

La detección y aislamiento de los problemas de memoria del sistema es una de las labores de diagnóstico más complejas. El problema se complica aún más por los distintos modos de intercalado de memoria que puede emplear el sistema, así como por la posibilidad de utilizar módulos DIMM de memoria dispares dentro del mismo banco.

Una vez que se ha detectado el fallo en un componente de memoria, el firmware desconfigura el banco de memoria asociado al error. Según esta norma, la configuración degradada puede provocar también el uso de un factor de intercalado inferior, una utilización inferior al 100 por cien en los bancos restantes, o ambas cosas, según el factor de intercalado.

Valores de ASR definidos por el usuario

Aunque, en la mayoría de los casos, los valores predeterminados configuran o desconfiguran adecuadamente los sistemas Ultra 450, resulta útil proporcionar a los usuarios avanzados la posibilidad de establecer manualmente valores que anulen los valores predeterminados. Por la naturaleza de la desconfiguración básica frente a la desconfiguración avanzada, es preciso proporcionar dos mecanismos de anulación distintos pero relacionados.

Valores de usuario para la desconfiguración básica

Para cualquier subsistema representado por un determinado nodo del árbol de dispositivos, los usuarios pueden desactivar esa función mediante la variable NVRAM asr-disable-list, que es simplemente un lista de rutas del árbol de dispositivos separadas por espacios.

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

La OBP del Ultra 450 utilizará esta información para crear la propiedad de estado disabled en todos los nodos incluidos en la variable asr-disable-list.

Valores de usuario para la desconfiguración avanzada

Para anular los valores de subsistemas que precisan desconfiguración avanzada (CPU y memoria), se utilizan los comandos de OBP asr-enable y asr-disable a fin de activar o desactivar cada subsistema de forma selectiva.

Nota -

Existen duplicaciones en los valores de usuario para la desconfiguración por básica y avanzada. Siempre que sea posible, es preferible utilizar los comandos asr-enable y asr-disable de la desconfiguración avanzada.

Para poder llevar el control de los estados establecidos por los valores definidos manualmente, se ha incorporado un nuevo comando de usuario, .asr, que permite ver el resumen de valores en uso.

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

Opciones de arranque automático

OpenBoot proporciona la variable binaria controlada por NVRAM y denominada auto-boot? que determina si OBP arrancará automáticamente el sistema operativo después de cada restauración. El valor predeterminado para las plataformas SUN es true.

Si un sistema detecta un fallo durante el diagnóstico de encendido, no se tiene en cuenta la variable auto-boot? y el sistema no arranca a menos que el usuario lo haga manualmente. Obviamente, este comportamiento no es el adecuado para un caso de arranque degradado, por lo que la OBP del sistema Ultra 450 proporciona una segunda variable binaria controlada por NVRAM que se denomina auto-boot-on-error?. Esta conmutación controla si el sistema intentará efectuar un arranque degradado cuando se detecte el fallo de un subsistema. Tanto auto-boot? como auto-boot-on-error? deben tener el valor true para poder habilitar el arranque degradado.

ok setenv auto-boot-on-error? true

Nota -

El valor predeterminado de auto-boot-on-error? es false. Por este motivo, el sistema no intentará realizar un arranque degradado a menos que el usuario lo cambie por true. Igualmente, el sistema no tratará de efectuar un arranque degradado como respuesta a un error grave sin solución, aunque dicho arranque esté habilitado. Un ejemplo de error grave es cuando todas las CPU del sistema están desactivadas por un fallo detectado por POST o como resultado de los valores definidos manualmente por el usuario.

Casos de restauración del sistema

El protocolo estándar de restauración del sistema no tiene en cuenta el diagnóstico del firmware a menos que la variable NVRAM diag-switch? esté definida como true. El valor predeterminado de esta variable es false.

Para poder utilizar la ASR en los sistemas Ultra 450, conviene poder ejecutar el diagnóstico del firmware (POST/OBDiag) en algunos o todos los casos de restauración. En lugar de cambiar simplemente el valor predeterminado de diag-switch? por true, que conlleva otros efectos (consultar el OpenBoot 3.x Command Reference Manual), la OBP del Ultra 450 proporciona una nueva variable NVRAM denominada diag-trigger, que permite determinar qué casos de restauración, si los hay, activarán automáticamente las funciones POST/OBDiag. La variable diag-trigger y sus distintos valores se explican en la tabla siguiente.

Nota -

diag-trigger no tiene ningún efecto a menos que diag-switch? esté definida como true.

Tabla 2-5 Variables de configuración para power-reset, error-reset, y soft-reset


Valor	Función
`power-reset` (predeterminado)	Ejecuta el diagnóstico sólo en restauraciones de encendido.
`error-reset`	Ejecuta el diagnóstico sólo en restauraciones por encendido, errores graves de hardware y advertencias de error.
`soft-reset`	Ejecuta el diagnóstico en todas las restauraciones (excepto las de XIR), incluidas aquéllas provocadas por los comandos `init` `6` o `reboot` de UNIX.
`none`	Deshabilita la activación automática del diagnóstico por cualquier evento de restauración. Con todo, los usuarios pueden ejecutar el diagnóstico manualmente pulsando simultáneamente las teclas Stop y d al encender el sistema, o poniendo el botón del panel frontal en la posición de Diagnostics al encender el sistema.

En el ejemplo siguiente, la variable diag-trigger se utiliza para activar las funciones de diagnóstico POST y OpenBoot en todas las restauraciones excepto las de XIR.

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