SISTEMAS OPERATIVO SESION 2

PROCESOS

1. GENERALIDADES
1.1. Programa, proceso y tarea
a) Programa
Conjunto de instrucciones para una computadora. Un programa no hace nada a menos que sus instrucciones sean ejecutadas por el procesador.
b) Proceso
Es un programa en ejecución.
c) Tarea
Una tarea se refiere al proceso que está corriendo en memoria.

1.2. Sistema Operativo
“Un sistema operativo es el encargado de brindar al usuario una forma amigable y sencilla de operar, interpretar, codificar y emitir las órdenes al procesador central, para que éste, realice las tareas necesarias y específicas para completar una orden”

a) CLASIFICACIÓN
a. Por su Estructura
· Monolítico: están constituidos fundamentalmente por un solo programa compuesto de un conjunto de rutinas entrelazadas de tal forma que cada una puede llamar a cualquier otra. Estos sistemas tienen un núcleo grande y complejo, que engloba todos los servicios del sistema.


· Por Capas o Jerárquico: está dividido en pequeñas partes, de tal forma que cada una de ellas es perfectamente definida y con una interfaz clara con el resto de elementos.


· Cliente Servidor: El núcleo tiene como misión establecer la comunicación entre los clientes y los servidores. Cuando un proceso de usuario, llamado proceso cliente, necesita un servicio del S.O lo que hace es enviar un mensaje al proceso servidor correspondiente el cual realiza el trabajo y devuelve la respuesta.


· Maquina Virtual: El objetivo de los sistemas operativos de máquina virtual es el de integrar distintos sistemas operativos dando la sensación de ser varias máquinas diferentes. Estos sistemas operativos separan dos conceptos que suelen estar unidos en el resto de sistemas: la multiprogramación y la máquina extendida.


b. Por Cantidad de Tareas
· Monotarea: Sólo puede ejecutar una tarea o proceso (aparte de los procesos del propio S.O.) en un momento dado. Una vez que empieza a ejecutar un proceso, continuará haciéndolo hasta su finalización o interrupción.

· Multitarea: Permite que varias tareas (procesos) se ejecuten al tiempo. Cada tarea se ejecuta de manera independiente y utilizando los mismos recursos.

c. Por Cantidad de Usuarios
· Monousuario: Solamente permite ejecutar los programas de un usuario al mismo tiempo. Esto a causa de las limitaciones creadas por el hardware, los programas o el tipo de aplicación que se esté ejecutando.

· Multiusuario: administran y permiten que varios usuarios utilicen al tiempo, recursos de hardware y de software. Permite que varios usuarios ejecuten simultáneamente sus programas. Utilizan métodos de protección de datos, de manera que un programa no pueda usar o cambiar los datos de otro usuario.

d. Por la Forma de Administrar Recursos
· Centralizado: Si permite utilizar los recursos de un solo computador.

· Distribuido: Permite utilizar los recursos (memoria, CPU, disco, periféricos...) de más de un computador al mismo tiempo. Integran recursos, en una sola máquina virtual, que el usuario accesa en forma transparente. El usuario no necesita saber la ubicación de los recursos, sino que los conoce por nombre y simplemente los usa como si todos ellos fuesen locales a su lugar de trabajo habitual.
b) INTERFACES
Las interfaces sirven para comunicar el sistema operativo con el usuario y sus programas. Esta comunicación se realiza por medio de instrucciones que el SO proporciona o llamadas al sistema. Las interfaces se usan de dos formas:
· Línea de comandos:
Es un lenguaje de comandos especial, los comandos deben ser memorizados, son programables, otorgándoles flexibilidad.


· Interfaz gráfica.
Tipo de visualización que permite al usuario elegir comandos, iniciar programas, ver listas de archivos, etc. usando representaciones visuales (íconos) y menús. Se activan a través del mouse o teclado.

c) KERNEL
Es el corazón o núcleo del sistema. Esta porción del sistema operativo es la que trabaja de forma más cerrada e independiente del usuario. Se encarga de realizar las funciones de más bajo nivel con respecto al hardware del equipo, permitiendo la no-dependencia del hardware del resto de las partes del sistema operativo.
· Gestiona los recursos físicos, así como las aplicaciones de los usuarios.
· Sirve de interfaz entre los servicios de usuario del S.O. y el propio hardware.
· Reside permanentemente en memoria.
· Maneja los procesos asignando recursos, planificando la multitarea y manejando solicitudes de servicio del hardware.
· Maneja unidades supervisando la transmisión de datos entre los periféricos y las aplicaciones.
El kernel contiene un manejador para las unidades físicas de cada ordenador. Estos manejadores son propios de cada máquina y de cada dispositivo periférico.

d) SHELL
El shell es realmente la única parte del sistema que ve el usuario. Actúa como intérprete permitiendo la comunicación con el sistema.
Cuando un usuario introduce un comando, el shell, que es un programa que está en constante ejecución, lo analiza y llama a ejecución al programa que realiza la función especificada por el comando.
El shell es configurable, es decir, cada usuario puede tener su propio programa shell o “entorno”. Las actividades que normalmente realiza el shell pueden ser:
· Editar programas
· Inicializar soportes
· Comparar, copiar, mostrar e imprimir archivos
· Traducir e interpretar instrucciones
· Gestionar gráficos
· Depurar y encadenar grupos de comandos
Además de las características ya apuntadas hasta este momento cabe destacar otras características no menos importantes:
· Eficacia: es la primera característica que debe cumplir un Sistema Operativo; esto supone una ejecución de sus funciones de forma rápida y utilizando pocos recursos del ordenador.
· Fiabilidad: el sistema operativo debe ser robusto o como ya he dicho con anterioridad, debe ser tolerante a fallos.
· Fácil mantenimiento: debe estar escrito en un lenguaje de programación fácil de mantener y modificar. Esto le da una buena portabilidad.
· Portabilidad: un sistema operativo es portable cuando se puede transportar de un ordenador a otro físicamente distinto. Es una característica muy apreciada y que da origen a los deseados sistemas abiertos.

De manera esquemática, un sistema operativo se compone de:
1. Núcleo (Kernel): responsable de la gestión de memoria, de disco y de procesos.
2. Servicios (API: Aplication Program Interface): mediante estos servicios las aplicaciones pueden realizar peticiones al sistema operativo para acceder a los recursos hardware del sistema.
3. Shell (Intérprete de comandos): es el proceso encargado de traducir los comandos que los usuarios introducen, a instrucciones que el sistema operativo entiende.


a) ¿QUÉ ES UN PROCESO?
Un proceso es un programa en ejecución. Un proceso simple tiene un hilo de ejecución, por el momento dejemos esta última definición como un concepto, luego se verá en más detalle el concepto de hilo. Una vez definido que es un proceso nos podríamos preguntar cuál es la diferencia entre un programa y un proceso, y básicamente la diferencia es que un proceso es una actividad de cierto tipo que contiene un programa, entradas salidas y estados.

Los procesos pueden ser cooperantes o independientes, en el primer caso se entiende que los procesos interactúan entre sí y pertenecen a una misma aplicación. En el caso de procesos independientes en general se debe a que no interactúan y un proceso no requiere información de otros o bien porque son procesos que pertenecen a distintos usuarios.

En la bibliografía los términos job, task y proceso suelen tomarse como sinónimos (dependiendo el autor del texto), pero significan cosas distintas. Un job o trabajo está generalmente asociado a procesamiento en batch y agrupa todas las tareas necesarias para ejecutar ese procesamiento. Un task o tarea es una actividad en particular. En general un job en se compone de varios tasks.

Un proceso se caracteriza por poseer:
· Contador de programa (PC)
· Estado
· Stack
· Sección de datos
· PCB

2. ESTADOS
El principal trabajo del procesador es ejecutar las instrucciones de máquina que se encuentran en memoria principal. Estas instrucciones se encuentran en forma de programas. Para que un programa pueda ser ejecutado, el sistema operativo crea un nuevo proceso, y el procesador ejecuta una tras otra las instrucciones del mismo.

Los procesos en el estado listo son los que pueden pasar a estado de ejecución si el planificador los selecciona. Los procesos en el estado ejecución son los que se están ejecutando en el procesador en ese momento dado. Los procesos que se encuentran en estado bloqueado están esperando la respuesta de algún otro proceso para poder continuar con su ejecución. Por ejemplo operación de E/S.

El concepto central de cualquier Sistema Operativo es el de proceso: una abstracción de un programa en ejecución también llamada tarea.

2.1. Modelo de cinco estados:
En la realidad, los procesos utilizan datos para operar con ellos, y puede suceder que no se encuentren listos, o que se deba esperar algún suceso antes de continuar, como una operación de Entrada/Salida. Es por esto que se necesita un estado donde los procesos permanezcan bloqueados esperando hasta que puedan proseguir. Se divide entonces al estado No ejecución en dos estados: Listo y Bloqueado. Se agregan además un estado Nuevo y otro Terminado.

Los cinco estados de este diagrama son los siguientes:
· Ejecución: el proceso está actualmente en ejecución.
· Listo: el proceso está listo para ser ejecutado, sólo está esperando que el planificador así lo disponga.
· Bloqueado: el proceso no puede ejecutar hasta que no se produzca cierto suceso, como una operación de Entrada/Salida.
· Nuevo: El proceso recién fue creado y todavía no fue admitido por el sistema operativo. En general los procesos que se encuentran en este estado todavía no fueron cargados en la memoria principal.
· Terminado: El proceso fue expulsado del grupo de procesos ejecutables, ya sea porque terminó o por algún fallo, como un error de protección, aritmético, etc.

Los nuevos estados Nuevo y Terminado son útiles para la gestión de procesos. En este modelo los estados Bloqueado y Listo tienen ambos una cola de espera. Cuando un nuevo proceso es admitido por el sistema operativo, se sitúa en la cola de listos. A falta de un esquema de prioridades ésta puede ser una cola FIFO. Los procesos suspendidos son mantenidos en una cola de bloqueados. Cuando se da un suceso se pasan a la cola de listos los procesos que esperaban por ese suceso.

2.2. Transiciones de estado de los procesos:
A continuación se dan ejemplos de eventos que pueden provocar transiciones de estado en un proceso en este modelo de tres estados. La mayoría de estos eventos se discutirán con profundidad a lo largo del curso:

· De ejecución á Bloqueado: al iniciar una operación de E/S, al realizar una operación WAIT sobre un semáforo a cero (en el tema de procesos concurrentes se estudiarán los semáforos).
· De ejecución á Listo: por ejemplo, en un sistema de tiempo compartido, cuando el proceso que ocupa la CPU lleva demasiado tiempo ejecutándose continuamente (agota su cuanto) el sistema operativo decide que otro proceso ocupe la CPU, pasando el proceso que ocupaba la CPU a estado listo.
· De Listo á en ejecución: cuando lo requiere el planificador de la CPU (veremos el planificador de la CPU en el tema de planificación de procesos).
· De Bloqueado á Listo: se dispone del recurso por el que se había bloqueado el proceso. Por ejemplo, termina la operación de E/S, o se produce una operación SIGNAL sobre el semáforo en que se bloqueó el proceso, no habiendo otros procesos bloqueados en el semáforo.

Obsérvese que de las cuatro transiciones de estado posibles, la única iniciada por el proceso de usuario es el bloqueo, las otras tres son iniciadas por entidades externas al proceso.


2.3. Bloque de Control de los Procesos (PCB)
Es una estructura de datos que contiene información asociada a cada proceso. La Tabla General del sistema contiene una lista de todos los procesos, con la PID (process identification) y un puntero a la correspondiente PCB.

En lo que tiene que ver con el control de todos los procesos que se efectúan en nuestro sistema, tenemos que tener claro los estados del proceso (aceptado, listo, en ejecución, bloqueado). Un Program counter, los Registros del CPU, información para la planificación del CPU, información para la Administración de Memoria, información para la Contabilidad y la Información del Estado de la E/S. Pero para administrar estos procesos correctamente necesitamos de una administración o planificación correcta, teniendo:

· Planificador de Trabajos (alto nivel): Se ocupa de elegir los trabajos de una cola de trabajos que llegan y los coloca en la cola de procesos (se basa en los conceptos de: primero en entrar, primero en servirse y en el de prioridad).
· Planificador de procesos (bajo nivel): Se ocupa de asignar el CPU para ejecutar los procesos de los trabajos de la cola de LISTOS.
· Planificador de nivel medio: Se ocupa de retirar trabajos activos de la memoria para reducir el grado de multiprogramación



Cada proceso se representa en el sistema operativo con un bloque de control del proceso (PCB, process control block), también llamado bloque de control de tarea. Este bloque contiene muchos elementos de información asociados a un proceso específico, incluidos los siguientes:
· Estado del proceso: El estado puede ser: nuevo, listo, en ejecución, en espera, detenido, etc.
· Contador de programa: el contador indica la dirección de la siguiente instrucción que se ejecutara para este proceso.
· Registros de CPU: El número y tipo de los registros varía dependiendo de la arquitectura del computador. Los registros incluyen acumuladores, registros índices, punteros de pila y registros de propósito general, así como cualesquier información de códigos de condición que haya. Junto con el contador de programa, esta información de estado se debe guardar cuando ocurre una interrupción, para que el proceso pueda continuar correctamente después.
· Información de planificación de CPU: Esta información incluye una prioridad del proceso, punteros a colas de planificación y cualesquier otros parámetros de planificación que haya.
· Información de gestión de memoria: Esta información puede incluir datos tales como el valor de los registros de base y límite, las tablas de páginas o las tablas de segmentos, dependiendo del sistema de memoria empleado por el sistema operativo (Cap. 8).
· Información contable: Esta información incluye la cantidad de tiempo de CPU y tiempo real consumida, límites de tiempo, números de cuenta, números de trabajo o proceso, y demás.

2.4. PLANIFICACIÓN DE PROCESOS
Existen dos planificadores que se encargan respectivamente de pasar trabajos o procesos a la memoria principal y a la CPU. El más importante es el Planificador de la CPU que se encarga de decidir qué procesos de los que están preparados pasarán a ejecución cuando la CPU se libere de algún otro proceso (cuando este pase a estar en espera). Esta planificación puede ser apropiativa o no apropiativa, siendo la primera aquella en la que unos procesos tienen prioridad sobre otros y cuando acaban de estar en espera y pasan a preparado hacen que el S.O. les dé paso a la CPU que abandona el proceso que tenía en ejecución, lo pone en preparado y pasa a ejecutar el que tiene prioridad. Con el otro sistema la CPU ejecuta un proceso hasta que lo termina o por alguna razón éste pasa a estar en espera. Existen varios criterios por los cuales la CPU es capaz de cambiar de proceso en ejecución:
· Utilización de la CPU: el S.O. pretende que la CPU este el menor tiempo posible inactiva.
· Productividad.
· Tiempo de retorno: el proceso en ejecución tarda mucho en acabar una acción, pudiendo encontrarse en un bucle muy largo.
· Tiempo de espera: se pretende que los procesos no estén demasiado tiempo en espera.
· Tiempo de respuesta.

a) COLAS DE LA PLANIFICACIÓN DE PROCESOS
Entre estas podemos tener:
· Cola de trabajos – conjunto de todos los procesos en el sistema.
· Cola de procesos listos – conjunto de todos los procesos residentes en la memoria-principal, listos y en espera para ejecutarse.
· Cola de dispositivos –conjunto de todos los procesos en espera de un dispositivo de E/S.
· Migración de los Procesos entre las distintas colas.

Conforme el trabajo se mueve a través del sistema, su avance se anota en el PCB.


b) PLANIFICADORES
Un proceso migra de una cola de planificación a otra durante toda su existencia. Para fines de planificación, el sistema operativo debe seleccionar procesos de estas colas de alguna manera. El planificador apropiado se encarga de este proceso de selección. En un sistema por lotes, es común que haya más procesos presentados de los que se pueden ejecutar inmediatamente. Estos procesos se colocan en spool en un dispositivo de almacenamiento masivo (por lo regular un disco), y ahí esperan hasta que pueden ejecutarse. El planificador a largo plazo (o planificador de trabajos) escoge procesos de esta reserva y los carga en la memoria para que se ejecuten. El planificador a corto plazo (o planificador de CPU) escoge entre los procesos que están listos para ejecutarse, y asigna la CPU a uno de ellos.

La distinción primaria entre estos dos planificadores es la frecuencia con que se ejecutan. El planificador a corto plazo debe seleccionar un proceso nuevo para la CPU de forma relativamente frecuente. Un proceso podría ejecutarse durante unos cuantos milisegundos antes de esperar una solicitud de E/S. En muchos casos, el planificador a corto plazo se ejecuta por lo menos una vez cada 100 milisegundos. Dada la brevedad del lapso entre ejecuciones, el planificador a corto plazo debe ser muy rápido. Si se requieren 10 milisegundos para tomar la decisión de ejecutar un proceso durante 100 milisegundos, se estará gastando (desperdiciando) el 10/(100 + 10) = 9% del tiempo de CPU simplemente para planificar el trabajo. El planificador a largo plazo, en cambio, se ejecuta con una frecuencia mucho menor. Podrían pasar minutos entre la creación de procesos nuevos en el sistema. El planificador a largo plazo controla el grado de multiprogramación (el numero de procesos que están en la memoria). Si el grado de multiprogramación es estable, la frecuencia promedio de creación de procesos debe ser igual? a. la frecuencia promedio de salida de procesos del sistema. Así, podría ser que solo sea necesario invocar el planificador a largo plazo cuando un proceso sale del sistema. Como el intervalo entre ejecuciones es más largo, el planificador a largo plazo puede darse el lujo de tardar más en decidir cual proceso escogerá para ejecutarlo.

Entre los planificadores podemos tener:
· Planificador de largo plazo (o planificador de trabajos) selecciona cual proceso deberá ser traído a la cola de procesos listos.
· Planificador de corto plazo (o planificador del CPU).- selecciona cual proceso deberá ser ejecutado enseguida y colocarlo en el CPU.

El planificador de corto plazo es invocado muy frecuentemente: (en milisegundos) ⇒ (deberá de ser rápido).
El planificador de largo plazo es invocado muy infrecuentemente: (en segundos, o minutos) ⇒ (deberá de ser lento). El planificador de largo plazo controla el grado de multiprogramación (el número de procesos en la memoria).
Planificador de mediano plazo (en sistemas de tiempo compartido).- realiza intercambio (swapping), para liberar a la memoria principal y reducir el grado de multiprogramación y también para mejorar la mezcla de procesos.


Los procesos pueden ser descritos como:
· Procesos limitados por E/S.- pasan más tiempo realizando E/S que computaciones, y va muchas veces al CPU, es de carrera corta.
· Procesos limitados por CPU.- pasan más tiempo realizando computaciones; y va muy pocas veces al CPU, es de carrera larga.
El sistema para un mejor rendimiento tiene una buena mezcla de ambos procesos

Es importante que el planificador a largo plazo haga una selección cuidadosa. En general, los procesos pueden describirse como limitados por E / S o limitados por CPU. Un proceso limitado por E/S es uno que dedica la mayor parte de su tiempo a operaciones de E/S, y menos a realizar cálculos. Un proceso limitado por CPU, en cambio, genera solicitudes de E/S con poca frecuencia, y dedica más de su tiempo a realizar cálculos que un proceso limitado por E/S. Es importante que el planificador a largo plazo escoja una buena mezcla de procesos limitados por E / S y limitados por CPU. Si todos los procesos están limitados por E/S, la cola de procesos listos casi siempre estará vacía, y el planificador a corto plazo casi no tendrá que hacer. Si todos los procesos están limitados por CPU, la cola de espera de E / S casi siempre estará vacía, los dispositivos estarán ociosos, y una vez más el sistema estará des balanceado. El sistema con el mejor rendimiento tiene una combinación de procesos limitados por E/S y limitados por CPU.

En algunos sistemas, el planificador a largo plazo podría estar ausente o ser mínimo. Por ejemplo, es común que los sistemas de tiempo compartido no tengan planificador a largo plazo y se limiten a colocar todos los procesos nuevos en la memoria para el planificador a corto plazo. La estabilidad de estos sistemas depende de una limitación física (como el numero de terminales disponibles) o bien de la naturaleza autoajustable de los usuarios humanos. Si el desempeño baja a niveles inaceptables, algunos usuarios simplemente se darán por vencidos y harán alguna otra cosa. Algunos sistemas operativos, como los de tiempo compartido, podrían introducir un nivel adicional, intermedio, de planificación. La idea clave en que se basan los planificadores a mediano plazo es que a veces puede ser provechoso sacar procesos de la memoria (y de la contención activa por la CPU) a fin de reducir el grado de multiprogramación. En algún momento posterior, el proceso se reintroducirá en la memoria y podrá continuar su ejecución donde se quedo. Este esquema se denomina intercambio (swapping). El planificador a mediano plazo intercambia el proceso a disco y luego lo intercambia a la memoria. Esto puede ser necesario para mejorar la mezcla de procesos o cuando un cambio en las necesidades de memoria ha distribuido la memoria disponible entre demasiados procesos, y es preciso liberar algo de memoria.

c) Conmutación de contexto
El cambio de la CPU a otro proceso requiere guardar el estado del proceso anterior y cargar el estado guardado del nuevo proceso. Esta tarea se denomina conmutación de contexto (context switch). El tiempo de conmutación de contexto es exclusivamente gasto extra (overhead), porque el sistema no realiza trabajo útil durante la conmutación. La rapidez de conmutación varia de una maquina a otra, dependiendo de la velocidad de la memoria, el número de registros que hay que copiar y la existencia de instrucciones especiales (como una sola instrucción para cargar y almacenar todos los registros). Por lo regular, el tiempo de conmutación varia entre 1 y 1000 microsegundos. Los tiempos de conmutación de contexto dependen en buena medida del apoyo del hardware.

Por ejemplo, algunos procesadores (como el DECSYSTEM-20) cuentan con varios conjuntos de registros. Una conmutación de contexto simplemente implica cambiar el puntero al conjunto de registros actual. Desde luego, si hay más procesos activos que conjuntos de registros, el sistema tendrá que recurrir a copiar los datos de registros en la memoria, igual que antes. Además, cuanto más complejo es el sistema operativo, mas trabajo hay que efectuar durante una conmutación de contexto. Las técnicas de gestión de memoria avanzadas podrían requerir la conmutación de datos adicionales con cada contexto. Por ejemplo, se hace necesario preservar el espacio de direcciones del proceso actual antes de preparar el espacio para la siguiente tarea. La manera como se preserva el espacio de direcciones, y la cantidad de trabajo que implica, dependen del método de gestión de memoria del sistema operativo. La conmutación de contexto se ha convertido en un cuello de botella tan importante para el desempeño que se están empleando estructuras nuevas (hilos) para evitarla hasta donde sea posible.

3. Operaciones con Procesos
3.1. Creación de procesos
Un proceso puede crear varios procesos nuevos, a través de una llamada al sistema de "crear proceso", durante el curso de su ejecución. El proceso creador se denomina proceso padre, y los nuevos procesos son los hijos de ese proceso. Cada uno de estos procesos nuevos puede a su vez crear otros procesos, formando un árbol de procesos.
En general, un proceso necesita ciertos recursos (tiempo de CPU, memoria, archivos, dispositivos de E/S) para efectuar su tarea. Cuando un proceso crea un subproceso, este tal vez pueda obtener sus recursos directamente del sistema operativo, pero podría estar restringido a un subconjunto de los recursos del proceso padre. El padre quizá tenga que dividir sus recursos entre sus hijos, o tal vez varios de sus hijos puedan compartir algunos recursos (como memoria o archivos). La restricción de un proceso hijo a un subconjunto de los recursos del padre impide que cualquier proceso sobrecargue el sistema creando demasiados subprocesos. Además de los diversos recursos físicos y lógicos que un proceso obtiene cuando se crea, el proceso padre podría pasar a su hijo datos de iniciación (entradas). Por ejemplo, consideremos un proceso cuya función es exhibir la situación de un archivo, digamos Al, en la pantalla de una terminal. En el momento de crearse recibirá, como entradas de su proceso padre, el nombre del archivo Al, y se ejecutara utilizando ese dato para obtener la información deseada. El proceso también podría recibir el nombre del dispositivo de salida. Algunos sistemas operativos pasan recursos a los procesos hijos. En un sistema semejante, el proceso nuevo podría obtener dos archivos abiertos, Al y el dispositivo de terminal, y tal vez solo tendría que transferir el dato entre los dos. Cuando u n proceso crea u n proceso nuevo, hay dos posibilidades en términos de ejecución:

• El padre sigue ejecutándose de forma concurrente con sus hijos.
• El padre espera hasta que algunos de sus hijos, o todos, han terminado.

También hay dos posibilidades en términos del espacio de direcciones del nuevo proceso:
• El proceso hijo es un duplicado del proceso padre.
• Se carga un programa en el proceso hijo.

Para ilustrar estas diferentes implementaciones, consideremos el sistema operativo UNIX. En UNIX, cada proceso se identifica con su identificador de proceso, que es un entero único. Se crea un proceso nuevo con la llamada al sistema fork (bifurcar). El nuevo proceso consiste en una copia del espacio de direcciones del proceso original. Este mecanismo permite al proceso padre comunicarse fácilmente con su proceso hijo. Ambos procesos (el padre y el hijo) continúan su ejecución con la instrucción que sigue al fork con una diferencia: el código de retorno que el proceso nuevo (hijo) recibe del fork es cero, pero al padre se devuelve el identificador de proceso (distinto de cero) del hijo.

Por lo regular, uno de los dos procesos utiliza la llamada al sistema execve después del fork para reemplazar su espacio de memoria con un programa nuevo. La llamada execve carga un archivo binario en la memoria (destruyendo la imagen de memoria del programa que contenía la llamada execve) e inicia su ejecución. De esta forma, los dos procesos pueden comunicarse, y luego cada uno sigue su propio camino. El padre puede crear más hijos o, si no tiene nada más que hacer mientras el hijo se ejecuta, puede emitir una llamada al sistema wait (esperar) para sacarse a sí mismo de la cola de procesos listos hasta que el hijo termine.
El sistema operativo DEC VMS, en contraste, crea un proceso nuevo, carga un programa especificado en ese proceso, e inicia su ejecución. El sistema operativo Microsoft Windows NT maneja ambos modelos: el espacio de direcciones del padre podría duplicarse, o el padre podría especificar el nombre de un programa que el sistema operativo cargara en el espacio de direcciones del nuevo proceso.

3.2. Terminación de procesos
Un proceso acaba cuando termina de ejecutar su ultimo enunciado y le pide al sistema operativo que lo elimine utilizando la llamada al sistema salir (exit). En ese momento, el proceso podría devolver datos (salidas) a su proceso padre (por medio de la llamada al sistema esperar). El sistema operativo liberará todos los recursos del proceso, incluidos memoria física y virtual, archivos abiertos v buffersdeE/S.
Hay otras circunstancias en las que ocurre la terminación. Un proceso puede causar la terminación de otro con una llamada al sistema apropiada (por ejemplo, abortar). Normalmente, solo el padre del proceso que se terminara puede emitir tal llamada. De otro modo, los usuarios podrían matar arbitrariamente los trabajos de otros usuarios. Es evidente que el padre necesita conocer la identidad de sus hijos. Por ello, cuando un proceso crea un proceso nuevo, el sistema operativo le pasa la identidad del proceso recién creado.
Un padre podría terminar la ejecución de uno de sus hijos por diversas razones, como:

• El hijo se ha excedido en la utilización de algunos de los recursos que se le asignaron.
• La tarea que se asigno al hijo ya no es necesaria.
• El padre va a salir, y el sistema operativo no permite que un hijo continúe si su padre termina.

Para determinar el primer caso, el padre debe contar con un mecanismo para inspeccionar el estado de sus hijos.
Muchos sistemas, incluido VMS, no permiten que un hijo exista si su padre ya termino. En tales sistemas, si un proceso termina (sea normal o anormalmente), todos sus hijos tienen que terminar. Este fenómeno se denomina terminación en cascada y por lo regular es el sistema operativo quien lo inicia.
Para ilustrar la ejecución y terminación de procesos, consideremos otra vez el sistema
UNIX. En UNIX, un proceso puede terminar emitiendo la llamada al sistema éxito, y su proceso padre puede esperar ese suceso empleando la llamada al sistema wait. Esta última llamada devuelve el identificador de proceso de un hijo que ha terminado, para que su padre pueda saber cuál de sus posiblemente múltiples hijos termino. Por otro lado, si el padre termina, el sistema operativo hace que todos los hijos terminen. Si no hay un padre, UNIX no sabe a quién informar de las actividades de un hijo.


4. Comunicación entre procesos
Los procesos cooperativos pueden comunicarse en un entorno de memoria compartida. El esquema requiere que estos procesos compartan una reserva de buffers común, y que el programador de la aplicación escriba explícitamente el código para implementar el buffet. Otra forma de lograr el mismo efecto es que el sistema operativo proporcione los medios para que procesos cooperativos se comuniquen unos con otros a través de un mecanismo de comunicación entre procesos (IPC, interprocess communication).

La IPC ofrece un mecanismo que permite a los procesos comunicarse y sincronizar sus acciones. La mejor forma de proveer la comunicación entre procesos es mediante un sistema de mensajes. Hay muchas formas diferentes de definir los sistemas de mensajes. Estos sistemas también tienen otras ventajas.
Cabe señalar que los esquemas de comunicación por memoria compartida y por transferencia de mensajes no son mutuamente exclusivos, y podrían utilizarse simultáneamente dentro de un mismo sistema operativo o incluso dentro de un mismo proceso.

4.1. Estructura Básica
La función de un sistema de mensajes es permitir a los procesos comunicarse entre si sin tener que recurrir a variables compartidas. Un recurso de IPC ofrece por lo menos dos operaciones enviar (mensaje) (send) y recibir (mensaje) (receive). Los mensajes que un proceso envía pueden ser de tamaño fijo o variable. Si solo es posible enviar mensajes de tamaño fijo, la implementación física es sencilla. Sin embargo, esta restriccion dificulta la tarea de programación. Por otro lado, los mensajes de tamaño variable requieren una implementación física más compleja, aunque simplifican la tarea de programación.

Si los procesos P y Q quieren comunicarse, deberán enviarse mensajes; para ello, debe existir un enlace de comunicación entre ellos. Este enlace se puede implementar de diversas maneras. Aquí no nos interesa la implementación física del enlace (que podría ser memoria compartida, un bus de hardware o una red), sino los problemas de su implementación lógica, como sus propiedades lógicas. Las siguientes son algunas preguntas básicas que deben contestarse para la implementación:

• ¿Cómo se establecen los enlaces?
• ¿Un enlace puede estar asociado a mas de dos procesos?
• ¿Cuantos enlaces puede haber entre cada par de procesos?
• ¿Qué capacidad tiene un enlace? Es decir, el enlace tiene espacio de buffer. De ser así, ¿cuánto?
• ¿Qué tamaño tienen los mensajes? ¿El enlace puede dar cabida a mensajes de tamaño variable o solo de tamaño fijo?
• ¿El enlace es unidireccional o bidireccional? Es decir, si existe un enlace entre P y
Q, ¿los mensajes pueden fluir solo en una dirección (digamos, solo de P a Q) o en ambas direcciones?

La definición de unidireccional se debe plantear con más cuidado, ya que un enlace podría estar asociado a más de dos procesos. Así, decimos que un enlace es unidireccional solo si cada proceso conectado al enlace puede enviar o recibir, pero no ambas cosas, y cada enlace tiene por lo menos un proceso receptor conectado a él. Además, hay varios métodos para implementar lógicamente un enlace y las operaciones de enviar/recibir:
• Comunicación directa o indirecta
• Comunicación simétrica o asimétrica
• Uso de buffers automático o explicito
• Envió por copia o envió por referencia
• Mensajes de tamaño fijo o variable
4.2. Asignación de nombres
Los procesos que desean comunicarse deben tener una forma de referirse unos a otros. Se puede usar comunicación directa o comunicación indirecta, como veremos en las dos sub-secciones siguientes.
a) Comunicación directa
En la disciplina de comunicación directa, cada proceso que desea comunicarse debe nombrar explícitamente el destinatario o el remitente de la comunicación. En este esquema, se definen las primitivas enviar y recibir como sigue:

Enviar (P, mensaje). Enviar un mensaje al proceso P.
Recibir (Q, mensaje). Recibir un mensaje del proceso Q.

Un enlace de comunicación en este esquema tiene las propiedades siguientes:

• Se establece automáticamente un enlace entre cada par de procesos que desean comunicarse. Los procesos solo necesitan conocer la identidad del otro para comunicarse.
• Un enlace se asocia a exactamente dos procesos.
• Entre cada par de procesos solo existe un enlace.
• El enlace puede ser unidireccional, pero suele ser bidireccional.

Como ilustración, presentaremos una solución al problema de productores y consumidores. Para que los procesos productores y consumidores puedan ejecutarse de forma concurrente, permitimos al productor producir un elemento mientras el consumidor está consumiendo otro elemento. Cuando el productor termina de generar un elemento, envía ese elemento al consumidor. El consumidor obtiene dicho elemento por medio de la operación recibir. Si un elemento todavía no se ha producido, el proceso consumidor debe esperar hasta que se produce. El proceso productor se define así:

repeat
…
producir un elemento en sigp
…
enviar (consumidor, sigp);
until false;

El proceso consumidor se define así:

repeat
recibir (productor, sigc);
…
consumir el elemento que está en sigc
…
until false;

Este esquema exhibe una simetría de direccionamiento; es decir, los procesos tanto emisor como receptor necesitan nombrar al otro para comunicarse. Una variante de este esquema utiliza asimetría de direccionamiento. Solo el emisor nombra al destinatario; el destinatario no está obligado a nombrar al emisor. En este esquema, las primitivas enviar y recibir se definen como sigue:

· enviar (P, mensaje): Enviar un mensaje al proceso P.
· recibir (id, mensaje): Recibir un mensaje de cualquier proceso; se asigna a la variable id el nombre del proceso con el que hubo comunicación.
La desventaja de ambos esquemas (simétrico y asimétrico) es la limitada modularidad de las definiciones de proceso que se obtienen. Para cambiar el nombre de un proceso podría ser necesario examinar todas las demás definiciones de procesos. Hay que hallar todas las referencias al nombre antiguo a fin de poder cambiarlas al nuevo. Esta situación no es deseable desde el punto de vista de la compilación separada.

b) Comunicación indirecta
Con la comunicación indirecta, los mensajes se envían a, y se reciben de, buzones (también llamados puertos). Un buzón puede considerarse en abstracto como un objeto en el que los procesos pueden colocar mensajes y del cual se pueden sacar mensajes. Cada buzón tiene una identificación única. En este esquema, un proceso se puede comunicar con otro a través de varios buzones distintos. Dos procesos pueden comunicarse solo si comparten un buzón. Las primitivas enviar y recibir se definen como sigue:

· enviar(A, mensaje): Enviar un mensaje al buzón A.
· recibir(A, mensaje): Recibir un mensaje del buzón A.

En este esquema, un enlace de comunicación tiene las propiedades siguientes:

· Se establece un enlace entre un par de procesos solo si tienen un buzón compartido.
· Un enlace puede estar asociado a más de dos procesos.
· Entre cada par de procesos en comunicación puede haber varios enlaces distintos, cada uno de los cuales corresponderá a un buzón.
· Los enlaces pueden ser unidireccionales o bidireccionales.

Supongamos ahora que los procesos P1, P2 y P3 comparten el buzón A. El proceso P1 envía un mensaje a A, y P2 y P3 ejecutan cada uno un recibir de A. ¿Cuál proceso recibirá el mensaje que P1 envió? Esta cuestión puede resolverse de varias maneras:

· No permitir que un enlace este asociado a mas de dos procesos.
· No permitir que más de un proceso ejecute una operación recibir a la vez.
· Permitir al sistema escoger arbitrariamente cual proceso recibirá el mensaje (es decir, P2 o P3, pero no ambos, recibirá el mensaje). El sistema podría identificar el receptor al emisor.

Un buzón puede ser propiedad de un proceso o del sistema. En el primer caso (es decir, si el buzón está unido a, o definido como parte de, el proceso), distinguimos entre el propietario (que solo puede recibir mensajes a través de este buzón) y el usuario del buzón (que solo puede enviar mensajes al buzón). Puesto que cada buzón tiene un propietario único, no puede haber confusión respecto a quien debe recibir un mensaje enviado a este buzón. Cuando un proceso que posee un buzón termina, el buzón desaparece. Cualquier proceso que envié subsecuentemente un mensaje a ese buzón deberá ser notificado de que el buzón ya no existe (por medio de manejo de excepciones).
Hay varias formas de designar el dueño y los usuarios de un buzón dado. Una posibilidad es permitir que un proceso declare variables de tipo buzón. El proceso que declara un buzón es el dueño de ese buzón. Cualquier otro proceso que conozca el nombre de dicho buzón podrá usarlo. Por otro lado, un buzón propiedad del sistema operativo tiene existencia propia; es independiente y no está unido a ningún proceso específico. El sistema operativo establece un mecanismo que permite a un proceso:

· Crear un buzón nuevo
· Enviar y recibir mensajes a través del buzón
· Destruir un buzón
El proceso que crea un buzón nuevo es, por omisión, su dueño. Inicialmente, el dueño es el único proceso que puede recibir mensajes a través de este buzón. Sin embargo, la propiedad y el privilegio de recibir se pueden transferir a otros procesos por medio de llamadas al sistema apropiadas. Desde luego, esta posibilidad podría dar lugar a la existencia de múltiples receptores para cada buzón. Los procesos también podrían compartir un buzón a través del recurso de creación de procesos. Por ejemplo, si el proceso P crea el buzón A, y luego crea un nuevo proceso Q, P y Q podrían compartir el buzón A. Puesto que todos los procesos con derecho de acceso a un buzón podrían terminar en algún momento, podría suceder que después de cierto tiempo un buzón ya no esté accesible a ningún proceso. En este caso, el sistema operativo deberá recuperar el espacio utilizado para el buzón.
Esta tarea podría requerir alguna forma de recolección de basura en la que ocurre una operación independiente para buscar y liberar memoria que ya no se está usando.

4.3. Uso de buffers
Un enlace tiene cierta capacidad que determina el numero de mensajes que pueden residir en el temporalmente. Esta propiedad puede visualizarse como una cola de mensajes unida al enlace. Básicamente, hay tres formas de implementar una cola semejante.

· Capacidad cero: La cola tiene como longitud máxima 0; el enlace no puede tener mensajes esperando en el. En este caso el emisor deberá esperar hasta que el destinatario reciba el mensaje. Los dos procesos deben sincronizarse para que pueda haber una transferencia de mensaje. Esta sincronización se denomina encuentro (rendezvous).

· Capacidad limitada: La cola tiene una longitud finita n; es decir, cuando más n mensajes pueden residir en ella. Si la cola no está llena cuando se envía un mensaje nuevo, este se coloca en la cola (se copia el mensaje o bien se mantiene un puntero a él) y el emisor puede continuar su ejecución sin esperar. Sin embargo, el enlace tiene una capacidad finita; si está lleno, el emisor deberá esperar hasta que haya espacio libre en la cola.

· Capacidad ilimitada: La cola tiene una longitud potencialmente infinita; en ella puede esperar cualquier cantidad de mensajes. El emisor nunca espera.

El caso de capacidad cero recibe también el nombre de sistema de mensajes sin buffers; los otros casos ofrecen almacenamiento automático en buffers.
Cabe señalar que, en los casos de capacidad cero, un proceso no sabe si su mensaje llego o no a su destino después de llevar a cabo la operación enviar. Si esta información es crucial para el cálculo, el emisor deberá comunicarse explícitamente con el receptor para averiguar si este último recibió el mensaje. Por ejemplo, supongamos que el proceso P envía un mensaje al proceso Q y solo puede continuar su ejecución después de haberse recibido el mensaje. El proceso P ejecuta la secuencia

enviar (Q, mensaje);
recibir (Q, mensaje);

El proceso Q ejecuta

enviar (P, mensaje);
recibir (P, "confirmación");

Se dice que tales procesos se comunican asincrónicamente.

Hay casos especiales que no encajan directamente en ninguna de las categorías que hemos descrito:
· El proceso que envía un mensaje nunca espera. Sin embargo, si el receptor no ha recibido el mensaje antes de que el proceso emisor envié otro mensaje, el primero se perderá. La ventaja de este esquema es que no es necesario copiar más de una vez los mensajes grandes. La desventaja principal es que la tarea de programación se vuelve más difícil. Los procesos necesitan sincronizarse explícitamente para asegurar que no se pierdan los mensajes y también que el emisor y el receptor no manipulen el buffer de mensajes simultáneamente.

· El proceso que envía un mensaje espera hasta recibir una respuesta. Este esquema se adopto en el sistema operativo Thoth, en el que los mensajes tienen un tamaño fijo (ocho palabras). Un proceso P que envía un mensaje se bloquea hasta que el proceso receptor ha recibido el mensaje y ha devuelto una respuesta de ocho palabras empleando la primitiva reply (P, mensaje). El mensaje de respuesta se escribe sobre el buffer del mensaje original. La única diferencia entre las primitivas send y reply es que un send hace que el proceso emisor se bloquee, mientras que reply permite que tanto el proceso emisor como el receptor continúen de inmediato su ejecución.
Este método de comunicación sincrónico puede expandirse fácilmente para tener un sistema de llamada a procedimientos remotos (RPC, remote procedure cali) con todas las de la ley. Los sistemas RPC se basan en la percepción de que una llamada a una subrutina o procedimiento en un sistema monoprocesador actúa exactamente como un sistema de mensajes en el que el emisor se bloquea hasta que recibe una respuesta.
El mensaje es entonces como una llamada a una subrutina, y el mensaje de retorno contiene el valor de la subrutina calculada. El siguiente paso lógico es que procesos concurrentes puedan invocarse mutuamente como subrutinas empleando RPC. De hecho, se pueden usar RPC entre procesos que se ejecutan en computadores distintos, con lo cual varios computadores pueden colaborar para beneficio mutuo.

4.4. Condiciones de excepción
Los sistemas de mensajes son útiles sobre todo en los entornos distribuidos, donde los procesos podrían residir en diferentes sitios (maquinas). En un entorno así, la probabilidad de que ocurra un error durante la comunicación (y el procesamiento) es mucho mayor que en un entorno de una sola maquina. En este último caso, los mensajes por lo regular se implementan en memoria compartida. Si ocurre una falla, todo el sistema falla. En un entorno distribuido, en cambio, los mensajes se transfieren por líneas de comunicación, y el fallo de un sitio (o enlace) no causa necesariamente el fallo de todo el sistema.

Cuando ocurre un fallo en un sistema, sea centralizado o distribuido, el sistema debe intentar recuperarse del error (manejar la condición excepcional). Comentaremos brevemente algunas condiciones excepcionales que un sistema debe manejar en el contexto de un esquema de mensajes.

a) El proceso termina
El emisor o el receptor podrían terminar antes de que se procese un mensaje. Esta situación deja mensajes que nunca se recibirán o procesos esperando mensajes que nunca se enviaran. Aquí consideraremos dos casos:

1. Un proceso receptor P podría esperar un mensaje de un proceso Q que ya termino.
Si no se toman medidas, P se bloqueara eternamente. En este caso, el sistema podría terminar P, o bien notificar a P que Q termino.
2. El proceso P podría enviar un mensaje a un proceso Q que ya termino.
Con el esquema de colocación automática en buffers, no hay problema; P simplemente continuara su ejecución. Si P necesita saber que Q proceso su mensaje, deberá programar explícitamente una confirmación. Si no se usan buffers, P se bloquearía eternamente. Como en el caso 1, el sistema podría terminar P o bien avisarle que Q ya termino.

b) Mensajes perdidos
Un mensaje del proceso P al proceso Q podría perderse en la red de comunicación, a causa de un fallo de hardware o de la línea de comunicaciones. Hay tres métodos básicos para enfrentar este suceso:

1. El sistema operativo tiene la obligación de detectar este suceso y retransmitir el mensaje.
2. El proceso emisor tiene la obligación de detectar este suceso y retransmitir el mensaje, si desea hacerlo.
3. El sistema operativo tiene la obligación de detectar este suceso; luego avisa al proceso emisor que el mensaje se perdió. El proceso emisor decide que quiere hacer.

No siempre es necesario detectar los mensajes perdidos. De hecho, algunos protocolos de red especifican que los mensajes no son confiables, mientras que otros garantizan la confiabilidad. El usuario debe especificar (esto es, notificar al sistema, o bien programar este requisito el mismo) que debe realizarse tal detección.

¿Cómo detectamos la pérdida de un mensaje? El método de detección más común es emplear tiempos límite o plazos. Cuando se envía un mensaje, siempre se devuelve un mensaje de respuesta para confirmar la recepción del mensaje. El sistema operativo o un proceso pueden entonces especificar un intervalo de tiempo durante el cual esperara la llegada del mensaje de acuse de recibo. Si se vence este plazo antes de que llegue la confirmación, el sistema operativo (o el proceso) podrá suponer que el mensaje se perdió y volverá a enviarlo. Sin embargo, es posible que no se haya perdido el mensaje, y solo haya tardado un poco más de lo esperado en viajar por la red. En este caso, podríamos tener múltiples copias del mismo mensaje viajando por la red. Debe haber un mecanismo para distinguir entre los diferentes tipos de mensajes.

c) Mensajes alterados
El mensaje podría llegar a su destino, pero sufrir alteraciones en el camino (por ejemplo, a causa de ruido en el canal de comunicación). Este caso es similar al de un mensaje perdido. Por lo regular, el sistema operativo retransmitirá el mensaje original. Es común el uso de códigos de verificación de errores (como las sumas de verificación, paridad y CRC) para detectar este tipo de errores.

5. Resumen
Un proceso es un programa en ejecución. Mientras un proceso se ejecuta, cambia de estado. El estado de u n proceso lo define su actividad actual. Un proceso puede estar en uno de los siguientes estados: nuevo, listo, en ejecución, en espera o terminado. Cada proceso se representa en el sistema operativo con su propio bloque de control de proceso (PCB).
Si un proceso no se está ejecutando, se coloca en alguna cola de espera. Hay dos clases principales de colas en un sistema operativo: colas de solicitud de E/S y la cola de procesos listos. Esta última contiene todos los procesos que están listos para ejecutarse y están esperando la CPU. Cada proceso se representa con un PCB, y los PCB se pueden enlazar para formar una cola de procesos listos. La planificación a largo plazo (de trabajos) es la selección de los procesos a los que se les permitirá competir por la CPU.
Normalmente, la planificación a largo plazo depende en gran medida de las consideraciones de asignación de recursos, sobre todo la gestión de memoria. La planificación a corto plazo (de CPU) es la selección de un proceso de la cola de procesos listos. Los procesos del sistema se pueden ejecutar de forma concurrente. Hay varias razones para permitir la ejecución concurrente: compartir información, aceleración de los cálculos, modularidad y comodidad. La ejecución concurrente requiere un mecanismo para crear y eliminar procesos. Los procesos que se ejecutan en el sistema operativo pueden ser independientes o cooperativos. Los procesos cooperativos deben poder comunicarse entre si. En general, hay dos esquemas de comunicación complementarios: memoria compartida y sistemas de mensajes. El método de memoria compartida requiere que los procesos en comunicación compartan ciertas variables. Se espera que los procesos intercambien información empleando dichas variables. En un sistema de memoria compartida, la obligación de proveer la comunicación corresponde a los programadores de aplicaciones; el sistema operativo solo tiene que proporcionar la memoria compartida. El método de sistema de mensajes permite a los procesos intercambiar mensajes. En este caso la obligación de proveer la comunicación corresponde al sistema operativo. Estos dos esquemas no son mutuamente exclusivos, y podrían utilizarse simultáneamente en un mismo sistema operativo.
Los procesos cooperativos que comparten directamente un espacio de direcciones lógico se pueden implementar como procesos ligeros o hilos. Un hilo es una unidad básica de utilización de la CPU, y comparte con otros hilos pares su sección de código, sección de datos y recursos del sistema operativo, que colectivamente reciben el nombre de tarea. Una tarea no hace nada si no contiene hilos, y un hilo debe estar en una y solo una tarea. El alto grado de compartimiento hace que la conmutación de la CPU entre hilos pares, y la creación de hilos, tengan un costo bajo en comparación con la conmutación de contexto entre procesos pesados.

“PROCESO DE ARRANQUE DE UN COMPUTADOR PERSONAL HASTA LA CARGA DEL SISTEMA OPERATIVO”

“PROCESO DE ARRANQUE DE UN COMPUTADOR PERSONAL HASTA LA CARGA DEL SISTEMA OPERATIVO”

1. Cuando conecta su PC, una señal eléctrica sigue permanentemente un camino programado por la CPU para borrar la información interna de los registros de los chips. La señal inicia un registro de la CPU llamado contador de programa con un número específico. En el caso de los AT y ordenadores posteriores, el número es F000. El número en el contador de programa dice a la CPU la dirección de la siguiente instrucción que necesita ser procesada. En este caso, la dirección es el comienzo de un programa de arranque almacenado permanentemente en la dirección F000 en un conjunto de chips de memoria de sólo lectura (ROM) que contiene el sistema de entrada/salida básico de los PC (BIOS).
2. La CPU utiliza la dirección para encontrarla e invocar al programa de arranque de la ROM-BIOS, que invoca a su vez una serie de comprobaciones del sistema, conocidas como autocomprobación o POST. La CPU se chequea a sí misma primero y al programa de POST, leyendo el código en diversas ubicaciones y chequeando registros permanentes idénticos.
3. La CPU envía señales por el bus del sistema (circuitos que conectan todos los componentes entre sí) para asegurar que todos están funcionando.
4. En los viejos PC que contienen un núcleo del lenguaje de programación BASIC en ROM, esa sección de código es chequeada mientras la CPU también comprueba los relojes del sistema, que son los responsables de asegurar que todas las operaciones de los PC funcionan de forma sincronizada y ordenadamente.
5. EL proceso POST comprueba la memoria contenida en el adaptador de vídeo y las señales de vídeo que controlan la visualización. Entonces hace del código de los adaptadores BIOS una parte de los sistemas globales de la BIOS y de la memoria de configuración. En este punto verá aparecer algo en el monitor de su PC.

6. El POST ejecuta una serie de pruebas para garantizar que los chips de RAM están funcionando adecuadamente. La CPU escribe información en cada chip, entonces la lee y compara lo que lee con la información enviada en primer lugar. Un contador considera la cantidad de memoria que ha sido chequeada y la muestra en el monitor durante la prueba.

7. La CPU chequea para asegurarse de que el teclado esté adecuadamente conectado y se preocupa de ver si han sido pulsadas algunas teclas.
8. El POST envía señales por trayectorias específicas a través del bus a cualquier unidad de disco y espera respuesta para determinar qué unidades de disco están disponibles

9. En un AT o PC posteriores, los resultados de la prueba de POST son comparados con un registro específico en un chip CMOS, que es un registro oficial de qué componentes están instalados. La CMOS es un tipo de chip de memoria que retiene información mientras el ordenador está apagado y recibe electricidad de una batería. Cualquier cambio en la configuración básica del sistema debe estar registrado en la información establecida en la CMOS de todos los PC que influyen esa función. (Solamente el PC original y el PC XT no utilizan la CMOS).
10. En sistemas que contienen componentes que incluyen su propio BIOS, como algunas tarjetas controladoras de disco, ese código es reconocido e incorporado como parte de los sistemas poseedores de BIOS y memoria. La PC está ahora lista para realizar el siguiente paso en el proceso de arranque: la carga de un sistema operativo desde disco.
11. Cuando la CPU (Unidad Central de Procesamiento) ha terminado su control sobre cada uno de sus componentes, sean controladores o periféricos, pasa a cargar el sistema operativo. El S.O. cumple una tarea muy importante: facilitar al usuario el control de la computadora.
Cada sistema operativo se puede dividir en cuatro áreas, las cuales tienen una función muy especifica:
· procesamientos de comandos;
· supervisión de entradas y salidas:
· manejo y control de archivos;
· programas de utilidad.
Durante este proceso se verifica cual es el primer dispositivo de arranque, y si este es un disco duro Básico, le pasará el control al MBR (master boot record o registro maestro de arranque). El MBR está contenido en el primer sector físico del disco duro y es como una especie de índice que contiene toda nuestra tabla de particiones. Este índice es creado cuando particionamos el disco duro y contiene un pequeño código ejecutable que damos en llamar Master Boot Code es decir Código Maestro de Arranque. El MBR es el encargado de llevar a cabo las siguientes operaciones.
· Busca en la tabla de particiones cual es la primera partición activa para transferirle el control
· Revisa cual es el sector de inicio de la partición que este configurada como activa
· Carga un copia del sector de inicio desde la partición activa en memoria y finalmente transfiere el control al código ejecutable del sector de inicio
Si durante este proceso no se pueden completar alguna de estas operaciones, nuestra máquina desplegará alguno de estos mensajes:
Invalid partition table.
Error loading operating system.
Missing operating system.

El sector Maestro de Arranque y el sector de inicio
Una vez terminado el trabajo del MBR este, como hemos visto, transfiere al control al Sector de Arranque o Boot Sector, de nuestra partición activa en sistemas Windows, la primera partición activa es básica puesto que suele contener los archivos básicos de arranque de Windows y suele coincidir con la letra “C”. En terminología informática esta partición también es llamada volumen de sistema, que puede coincidir con el volumen de inicio, si la primera partición activa, es decir nuestro volumen de sistema, también alberga al sistema operativo, aunque es cada vez más habitual que el volumen de sistema y de inicio no coincidan.
En cualquier caso, nuestro sector de arranque asume las siguientes operaciones:

Las instrucciones de inicialización para CPU basada en x86
La identificación original del fabricante de nuestro PC, en el caso de que nuestro sistema sea OEM.
La BIOS Parameter Block, BPB
la BIOS Parameter Block, Extendida.
El código ejecutable que inicia nuestro sistema operativo.


Así pues, el siguiente paso, una vez leídas las instrucciones de inicialización para CPU basadas en x86, sería cargar la BPB. La BPB contiene la estructura básica del volumen y las controladoras de disco utilizan este sector para leer y configurar los parámetros básicos de los volúmenes contenidos en nuestro disco. También es un proceso básico puesto que es el encargado de transferirle el control al código ejecutable, que es en sí, el que va a iniciar nuestro sistema operativo. Unos parámetros incorrectos en la BPB impedirán por tanto la carga del Sistema Operativo y explican porque no podemos iniciar cualquier Windows si lo cambiamos de máquina, ya que la BPB se basa en parámetros físicos más que en parámetros lógicos.
El archivo NTLDR
Ahora empiezan a intervenir los archivos propios del sistema operativo. En todos los sistemas con núcleo NT (por ejemplo WinXP o Windows 2000) el cargador se llama ntldr (de “nt loader”), y se encuentra en la partición activa o volumen de sistema (habitualmente C). El archivo ntldr es el encargado de leer el sistema de archivos tanto de una partición NTFS como de una FAT. Lo primero que hace el ntldr es cargar un serie de controladores básicos de dispositivos que van embebidos en este archivo, justo a continuación lee la información contenida en el archivo boot.ini que se encuentra oculto en el directorio raíz de nuestro volumen de sistema es decir en C, y que referencia que tipo de Sistema Operativo tiene que cargar. Supongamos que tenemos un arranque dual de XP y Windows 98. Si en el menú de arranque elegimos en este momento Windows 98, el ntldr pasará el control al bootsect.dos.
Si elegimos XP o un Sistema Operativo basado en núcleo NT se le pasa el control al ntdetect.com que es el encargado de la detección del hardware instalado.
Nuestro archivo ntdetect.com¸ se encarga de cargar la información contenida en nuestro perfil de hardware y las tablas de la ACPI, y las envia para su inclusión a nuestro archivo de arranque ntldr, para ser agregadas en la clave del registro.
HKEY_LOCAL_MACHINE\HARDWARE
El Kernel utiliza datos internos que provee el propio ntldr para crear la clave mencionada, cuya información será renovada en cada arranque de nuestra máquina, en base al hardware que se detecte durante cada inicio de nuestra máquina
De vuelta al ntldr, este pasará el control al archivo ntoskrnl.exe, es decir, el núcleo del sistema operativo (el nombre del archivo proviene de “nt operating system kernel”), y al archivo HAL (hardware abstraction layer o capa de abstracción del hardware), y leerá la información contenida el fichero “system” que tenemos ubicado en la carpeta \windows\system32\config,
Son el HAL y el kernel los encargados de poner en funcionamiento el software, mediante una serie de componentes llamada Windows executive. Estos componentes están almacenados en los “conjuntos de control” del registro (control sets). Concretamente los podemos encontrar referenciados en la clave del registro.
HKEY_LOCAL_MACHINE\SYSTEM
Esta clave es utilizada para múltiples propósitos entre ellos determinar qué drivers deben ser cargados durante cada arranque de nuestro sistema, en base al hardware cargado.
Carga de Drivers y servicios
Ahora prestemos atención a los drivers y a los servicios. Están contenidos, respectivamente, en las siguientes carpetas a las que puede accederse directamente desde Inicio > Ejecutar y escribir los siguientes:
Drivers -> %systemroot%\System32\Drivers
Servicios -> %systemroot%\System
Puesto que los drivers también son servicios, en este momento el núcleo lee la información de la clave
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Se arrancará primero los servicios que tengan el valor Start puesto a ‘0’ (los drivers de arranque) y luego los que tengan dicho valor puesto a ‘1’.
Ahora llega el proceso en el que interviene el Administrador de sesión (Session Manager, smss.exe). Éste crea variables de entorno, cambia a modo gráfico, y además de otras cosas, se encarga de arrancar el Administrador del logon (Logon Manager, winlogon.exe). El administrador de sesión lee tres claves:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager
en la que, por ejemplo, podría haber una referencia al “autochk.exe” (una versión del chkdsk), por si se necesita cargarse,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\Subsystem
con los distintos subsistemas,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
y acudiría a los servicios cuyo valor Start esté en “Auto-load”.
Si antes del logon quisiéramos que se nos cargarse alguna aplicación (no configurada como servicio, sino digamos que de forma “normal”) tendremos que colocarlas en alguna de estas dos claves del registro:
[1]HKEY_LOCAL_MACHINE\Sofware\Microsoft\Windows\CurrentVersion\RunServicesOnce
[2] HKEY_LOCAL_MACHINE\Sofware\Microsoft\Windows\CurrentVersion\RunServices
Estas dos claves se cargan de forma asíncrona. Por tanto, su contenido puede cargarse al mismo tiempo y no necesariamente en el orden especificado en las claves. Es más, aunque se cargan en el orden propuesto (primer [1]y luego [2]), se cargan también de forma asíncrona con el propio proceso de logon en sí, por lo que podría ser que continuasen cargándose después de introducir el nombre de usuario y contraseña.
Precisamente, como ya se ha indicado, la utilidad de estas dos claves es coloar aplicaciones en ellas para que se carguen antes del logon.
INICIANDO WINDOWS
En este momento, es winlogon.exe quien toma el control. Inicia el Administrador de control de servicios (Service control manager) el Local security authority (lsass.exe) y la Autentificación e Identificación Gráfica (Graphical Identification and Authentification, GINA) y pide al usuario (si así está configurado) un nombre y una contraseña. De la autentificación de ese usuario y contraseña se encarga el protocolo Kerberos V5 o bien NTLM. (Como comentario totalmente aparte, Kerberos es el nombre inglés del perro de dos cabezas Cancerbero que era encargado de custodiar las puertas del infierno en la mitología). Para más información sobre el protocolo Kerberos,
NTLM proviene de NT Lan Manager, y se usa sobre todo en grupos de trabajo, Windows 95 y Windows 98. Es en está fase cuando ciertas claves del registro son adaptadas si el arranque ha tenido éxito, entre ellas las claves Control sets que anteriormente mencionabamos, haciendo una nueva copia de la misma. Las políticas de grupo locales que tengamos aplicadas también toman efecto en este punto y comienzan a cargarse ciertas claves que inicializan determinados programas y servicios no cargados con anterioridad
Después de la autentificación
Tras introducir el usuario y la contraseña, se cargan las claves:
[3] HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\Setup
[4] HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
Esta clave [4] se carga de forma síncrona aunque su contenido no tiene por qué cargarse en el orden especificado. Esto también significa que esta que esta clave no se carga completamente no se cargan las siguientes. Igualmente, esta clave [4] no se carga hasta que no se han cargado las anteriores claves [1], [2] y [3].
A continuación se carga la clave
[5] HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx.
A partir de aquí, y hasta el item [12] el orden de carga vuelve a ser asíncrono y, digámoslo así, todo se carga el mismo tiempo (más o menos) pudiéndose solapar unas cosas con otras. A continuación se carga lo siguiente:
[6] Sección Load del Win.iniy luego
[7] Sección Run del Win.ini
A continuación la clave
[8] HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
que contiene los programas instalados en la máquina y la clave

[9] HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
que contiene los programas instalados específicamente en el usuario logueado. También se carga la clave
[10] HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Hasta ahora digamos que lo que se ha cargado ha sido el núcleo de Windows y el contenido del registro. Ahora se acude a las carpetas del menú inicio. Primero, las de todos los usuarios
[11] Documents and Settings\All Users\Menú Inicio\Programas\Inicio
y luego los del usuario logueado
[12] Documents and Settings\[usuario]\Menú Inicio\Programas\Inicio
donde [usuario] es el nombre de la cuenta en la que se ha iniciado sesión. A continuación se carga la clave
[13] HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
y finalmente las tareas programas que se tengan.
Vuelvemos a repetir que hasta [12] el proceso de carga se hace de forma asíncrona, por lo que podrían solaparse unas claves con otras y unos archivos con otros. Los elementos de los menú de inicio se cargan de forma alfanumérica. Por ejemplo, “a01.exe”, “a10.exe” y “b2p.exe” se cargan en ese orden. Si nos interesa alterar el orden de carga, tendríamos que renombrar los archivos.
Otras claves utilizadas durante la inicialización de Windows
Todas las que hemos relatado en el apartado anterior suelen ser las utilizadas comúnmente para inicializar programas, antes o después de la fase de autentificación, pero quizás sea conveniente anotar alguna ubicación más en el registro que tiene el mismo propósito: iniciar nuestros programas.
Una de las ubicaciones más esotéricas y menos conocidas para iniciar programas es la clave Load, ubicada en la rama
HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Windows\load.
En esta clave y en esta rama, podríamos especificar programas que se iniciarían sólo en la sesión de usuario que esté actualmente loguado. La clave análoga que afectaría a todos los usuarios de la máquina es denominada userinit, que podremos encontrar en la rama
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Userinit
Esta última clave, a diferencia de la clave Load, que anteriormente comentábamos, se encuentra presente en todos los sistemas y suele contener un único valor que apunta al ejecutable o proceso userinit.exe, que está encargado de inicializar los parámetros de inicialización de la Shell de Windows. Esta clave acepta valores separados por coma (CSV) por lo que es posible agregar más valores al ya comentado en esta clave.
Finalmente también podemos ejecutar diferentes procesos en la clave Explorer\Run
que podremos encontrar en las ramas,
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run.
Detección de dispositivos Plug and Play,
La detección de este tipo de dispositivos que son detectados e instalados casi sin que el usuario interactue para nada con el sistema, son cargados asincrónicamente durante la fase de autentificación. Esta fase de detección se basa fundamentalmente, en el firmware de cada dispositivo hardware conectado y en las características internas que el S.O. posee para la detección de nuevos tipos de dispositivos. Windows XP está optimizado para la detección de dispositivos que cumplan con la normativa ACPI.

La CPU una vez cargado el SO en la zona de la memoria destinada a tal fin, cede el control de la computadora al usuario. En este punto, se le ofrece al usuario varias posibilidades de elección para continuar con el manejo de la computadora:
· emplear los programas de utilidad que posee el sistema operativo;
· programar;
· cargar un programa aplicativo que se encuentra generalmente en dispositivo de almacenamiento secundario;
· conectarse a la red y utilizar algunos de sus recursos o servicios.


ARRANQUE Y FALLAS
Que ocurre desde que le damos al botón de Power hasta que aparece nuestro sistema operativo cargando??Cuando encendemos el ordenador, nuestra placa base hace una especie de escaneo a todo el sistema para comprobar si todo está en regla y continuar cargando.
Lo iremos marcando por pasos:


1. POWER, llega el voltaje a placa base
2. Seguidamente alimenta a los dispositivos de almacenamiento
3. El microprocesador, resetea todos los contadores y registros para partir de 0.
4. Busca una dirección de BIOS para testear la máquina, y también busca el test (Comprobación de dispositivos conectados)
5. POST ( Power On Self Test ) : Son un conjunto de rutinas y programas que chequean el hardware. Aquí es donde se producen los pitidos que indican el estado del ordenador
6. La BIOS envía al micro señales y asigna canales DMA y IRQ
7. Inicializa la BIOS de la VGA
8. Testeo y cuenta de memoria
9. Habilita Teclado Led"s y genera entradas
10. Busca el sector de arranque
11. Carga el boot managery cede el control al sistema operativo.
Siempre que lo encendamos el modo que tiene la placa base de transmitir el estado del sistema es por medio de pitidos. Aquí tenemos algunos:
Ningún pitido: No hay suministro eléctrico (veamos que el cable está sin enchufar, el cable en sí falla, o la caja de suministro eléctrico está deteriorada, la cuestión es que no llega corriente) o también puede ser que el Speaker, lo que emite los pitidos, falle (lo podréis comprobar si a continuación funciona correctamente).
Tono continuo: Error en el suministro eléctrico (llega mal la corriente, o la caja de suministro esta fastidiada, no hay más que cambiarla).
Tonos cortos constantes: La placa madre está defectuosa, es decir, está rota, es de lo peor que nos puede ocurrir.
Un tono largo: Error de memoria RAM, lo normal es que esté mal puesta o que esté fastidiada.
Un tono largo y otro corto: Error el la placa base o en ROM Basic. Esto suele ocurrir mucho en placas base viejas, la gente las suele tirar.
Un tono largo y dos cortos: Error en la tarjeta gráfica. Puede que el puerto falle, por lo que no habría más que cambiarla de puerto, pero también puede ser que la tarjeta gráfica sea defectuosa.
Dos tonos largos y uno corto: Error en la sincronización de las imágenes. Seguramente problema de la gráfica.
Dos tonos cortos: Error de la paridad de la memoria. Esto ocurre sobretodo en ordenadores viejos que llevaban la memoria de dos módulos en dos módulos. Esto significaría que uno de los módulos falla, o que no disponemos de un número par de módulos de memoria.Tres tonos cortos: Esto nos indica que hay un error en los primeros 64Kb de la memoria RAM.
Cuatro tonos cortos: Error en el temporizador o contador.
Cinco tonos cortos: Esto nos indica que el procesador o la tarjeta gráfica se encuentran bloqueados. Suele ocurrir con el sobrecalentamiento.
Seis tonos cortos: Error en el teclado. Si ocurre esto yo probaría con otro teclado. Si aun así no funciona se trata del puerto receptor del teclado.
Siete tonos cortos: Modo virtual de procesador AT activo.
Ocho tonos cortos: Error en la escritura de la video RAM.
Nueve tonos cortos: Error en la cuenta de la BIOS RAM.

Muchas veces nos suenan muchos de estos pitidos por cosas que no entendemos pero luego sigue funcionando con normalidad. En ese caso sería problema del detector de errores o de esa especie de escaneo que nos hace al encender el ordenador.

Tonos de la BIOS AMI
Pitidos fáciles de identificar, su interfaz gráfico ha sido mejorado y los parámetros son más parecidos a los de AWARD.
Ningún pitido. Esto significa varias cosas. Primeramente nos aseguramos de que el speaker esté bien conectado, luego revisamos el cable de alimentación. En caso de estar todo bien y la configuración de swichers y jumpers también l sea cambiaremos la placa por defectuosa. Ese fallo se debe en la mayoría de las veces por fallos de corriente.
Un pitido. Este pitido indica que todo esta correcto. En caso de no dar imagen revisaremos la tarjeta grafica y la memoria RAM.
Dos pitidos. Es un problema de memoria en tarjeta de video o en la RAM. Si vemos imagen nos aparecerá un mensaje de error. Si es así cambiaremos la memoria RAM de posición en los zócalos que ocupa ya que existe un problema de paridad, o en los primeros 64Kbytes de memoria. Si el problema persiste cambiaremos la placa.
Tres pitidos. Lo mismo que cuando suenan dos pitidos.
Cuatro pitidos. Lo mismo que ocurre con dos y tres pitidos. En este caso además puede ser un error en el reloj del sistema
Cinco pitidos. La placa base no ha detectado memoria RAM, o no es compatible procedemos a cambiarla de posición o a cambiarla por otra. En muchos casos la marca de la RAM influye mucho.
Seis pitidos. La controladora de teclado estropeada, hay que cambiar de placa.
Siete pitidos. No se ha podido detectar el procesador o no funciona. Lo cambiamos o revisamos la configuración.
Ocho pitidos. No se ha detectado tarjeta de video o no funciona. Cambiamos de slot la tarjeta o revisamos al memoria de video.
Nueve pitidos. El código de la BIOS está corrupto, procedemos a flasearla si podemos, o a reemplazar el chip.
Diez pitidos. La BIOS no puede leer / escribir los datos almacenados en la CMOS. Intentamos borrar estos datos puenteando el jumper Clean CMOS o quitando la pila, e intentamos salvar los valores de nuevo en la CMOS. Si el problema persiste tendremos que cambiar la placa ya que este chip viene siempre soldado.
Once pitidos. La memoria caché del sistema (640Kbytes en la placa) esta dañada o no pude acceder a ella . Podemos reactivar la caché mediante la combinación Control + Alt + Shift + I
Tonos de la BIOS AWARD
Si poseemos esta BIOS ya nos vale agudizar el oído. En la mayoría de los pitidos se les acompaña un mensaje de error.
Tono ininterrumpido. Fallo en el suministro eléctrico. Revisamos las conexiones y la fuente de alimentación.
Tonos cortos constantes. Sobrecarga eléctrica, chips defectuosos, placa mal.
1 largo. Si aparece esto en la pantalla RAM Refresh Failure, significa que los diferentes componentes encargados del refresco de la memoria RAM fallan o no están presentes. Cambiar de banco la memoria y comprobar los jumpers de buses.
1 largo y 1 corto. El código de la BIOS esta corrupto o defectuoso, probaremos a flasear o reemplazamos el chip de la BIOS sino podemos cambiamos de placa.
1 largo y dos cortos. No da señal de imagen, se trata de que nuestra tarjeta de vídeo esta estropeada, probaremos a pincharla en otro slot o probaremos otra tarjeta gráfica.
1 largo y 2 cortos. Si aparece por pantalla este mensaje: No video card found, este error solo es aplicable a placas base con tarjetas de vídeo integradas. Fallo en la tarjeta gráfica, probaremos a desabilitarla y pincharemos una nueva en cualquier slot libre o cambiaremos la placa madre.
1 largo y 3 cortos. Si aparece este mensaje por pantalla No monitor connected Idem que el anterior.
1 largo y varios cortos. Mensaje de error. Video related failure. Lo mismo que antes. Cada fabricante implanta un código de error según el tipo de tarjeta de video y los parámetros de cada BIOS
2 largos y 1 corto. Fallo en la sincronización de las imágenes. Cargaremos por defecto los valores de la BIOS e intentaremos reiniciar. Si persiste nuestra tarjeta gráfica o placa madre están estropeadas.
2 cortos. Vemos en la pantalla este error: Parity Error. Se trata de un error en la configuración de la BIOS al no soportar la paridad de memoria, la deshabilitamos en al BIOS.
3 cortos. Vemos en la pantalla este error. Base 64 Kb Memory Failure, significa que la BIOS al intentar leer los primeros 64Kbytes de memoria RAM dieron error. Cambiamos la RAM instalada por otra.
4 cortos. Mensaje de error; Timer not operational. El reloj de la propia placa base esta estropeado, no hay mas solución que cambiar la placa. No confundir con CMOS cheksum error una cosa es la pila y otra el contador o reloj de la placa base.
5 cortos. Mensaje por pantalla Processor Error significa que la CPU ha generado un error porque el procesador o la memoria de vídeo están bloqueados.
6 cortos. Mensaje de error: 8042 - Gate A20 Failure, muy mítico este error. El controlador o procesador del teclado (8042) puede estar en mal estado. La BIOS no puede conmutar en modo protegido. Este error se suele dar cuando se conecta/desconecta el teclado con el ordenador encendido.
7 cortos. Mensaje de error: Processor Exception / Interrupt Error Descripción. La CPU ha generado una interrupción excepcional o el modo virtual del procesador está activo. Procesador a punto de morirse.
8 cortos. Mensaje de error: Display Memory Read / Write error. La tarjeta de video esta estropeada, procedemos a cambiarla.
9 cortos. Mensaje de error: ROM Checksum Error; el valor del checksum (conteo de la memoria) de la RAM no coincide con el valor guardado en la BIOS. Reseteamos los valores de la CMOS y volvemos a a configurar y si persiste tendremos la RAM o la BIOS stropeadas.
10 cortos. Si vemos por pantalla esto; CMOS Shutdown Register / Read/Write Error: el registro de la CMOS RAM falla a la hora de la desconexión. En otras palabras que no puede escribir en la CMOS cuando salimos de configurar la BIOS.
11cortos. Mensaje de error: Cache Error / External Cache Bad la memoria caché (L1o L2) del procesador están fallando. También se aplica a la cache de la placa.
1 pitido largo + 8 pitidos cortos. Error en la verificación de tarjeta de video, esta está defectuosa, procedemos a cambiarla
1 pitido largo + 3 pitidos cortos. Fallo en la comprobación de la RAM (Reemplazar la memoria) posiblemente porque los ciclos de reloj de esa memoria no se corresponden con los de la placa o no son compatibles ( memoria de marca o no ).

Tonos de la BIOS Phoenix

La duración de los pitidos se mide de uno a cuatro. Esta BIOS es propiedad desde hace dos años de AWARD y estaba muy presente en equipos portátiles.1-2-2-3: error del código de verificación de la ROM. En otras palabras BIOS corrupta
1-3-1-1: fallo en el testeo del refresco de la memoria DRAM. Revisamos que la memoria RAM este bien instalada y su configuración de BUS sea correcta.1-3-1-3: error en el test de del controlador del teclado. Procedemos a conectarlo bien, si persiste cambiaremos la placa ya que la controladora de teclado esta mal.1-3-4-1: error en una dirección de memoria. Evidentemente el testeo de la RAM ha fallado tendremos que reemplazarla o revisaremos si estaba bien instalada.1-3-4-3: error en una dirección del área de memoria baja. Idem2-1-2-3: error en la ROM del sistema .La BIOS esta corrupta o no se ha podido acceder a ella( leer / escribir).Tratamos de flasearla, o de sustituir el chip de la BIOS por otro idéntico.2-2-3-1: problemas con interrupciones de sistema. Entramos en la BIOS la procedemos a configurar correctamente.Errores en pantalla
Otras veces no oímos ningún pitido y si nos parece en la pantalla alguno de estos errores. Estos errores no dependen del tipo de BIOS. Y son comunes a todos ellos.*BIOS ROM checksun error – system halted: el código de control de la BIOS es incorrecto, lo que indica que puede estar corrupta. En caso de reiniciar y repetir el mensaje, tendremos que reemplazar al BIOS.*CMOS battery faled: la pila de la placa base que alimenta la memoria CMOS ha dejado de suministrar corriente. Es necesario cambiar la pila inmediatamente.*CMOS checksum error – Defaults loaded: el código de control de la CMOS no es correcto, por lo que se procede a cargar los parámetros de la BIOS por defecto. Este error se produce por que la información almacenada en la CMOS es incorrecta, lo que puede indicar que la pila está empezando a fallar.*Display switch is set incorrectly: el tipo de pantalla especificada en la BIOS es incorrecta. Esto puede ocurrir si hemos seleccionado la existencia de un adaptador monocromo cuando tenemos uno en color, o al contrario. Bastará con poner bien este parámetro para solucionar el problema*Floppy disk(s) Fail ( code 40/38/48 dependiendo de la antigüedad de la bios): Disquetera mal conectada, verificamos todos los cables de conexión.*Hard disk install failure: la BIOS no es capaz de inicializar o encontrar el disco duro de manera correcta. Debemos estar seguros de que todos de que todos los discos se encuentren bien conectados y correctamente configurados.*Keyboard error or no keyboard present: no es posible inicializar el teclado. Puede ser debido a que no se encuentre conectado, este estropeado e incluso porque mantenemos pulsada alguna tecla durante el proceso de arranque.*Keyboard error is locked out – Unlock the key: este mensaje solo aparece en muy pocas BIOS, cuando alguna tecla ha quedado presionada.*Memory Test Fail: el chequeo de memoria RAM ha fallado debido probablemente, a errores en los módulos de memoria. En caso de que nos aparezca este mensaje, hemos de tener mucha precaución con el equipo, se puede volver inestable y tener perdidas de datos. Solución, comprobar que banco de memoria esta mal, y ustituirlo inmediatamente.*Override enabled – Defaults loaded: si el sistema no puede iniciarse con los valores almacenados en la CMOS, la BIOS puede optar por sustituir estos por otros genéricos diseñados para que todo funcione de manera estable, aunque sin obtener las mayores prestaciones.*Primary master hard diskfail: el proceso de arranque ha detectado un fallo al iniciar el disco colocado como maestro en el controlador IDE primario. Para solucionar comprobaremos las conexiones del disco y la configuración de la BIOS.