¿Cómo podía una función OUTB montaje causar una falla triple?

Question

En mi clase de programación de sistemas que estamos trabajando en un pequeño sistema operativo, simple pasatiempo. Personalmente he estado trabajando en un controlador de disco duro ATA. He descubierto que una sola línea de código parece causar una falla que luego se reinicia inmediatamente el sistema. El código en cuestión se encuentra al final de mi rutina de servicio de interrupción de las interrupciones IDE. Desde que estaba usando los canales IDE, son enviados a través del esclavo PIC (que se conecta en cascada a través del maestro). Originalmente mi código sólo se envía el byte de fin de interrupción para el esclavo, pero entonces mi profesor me dijo que yo debería estar enviando al PIC maestro también.

Así que aquí es mi problema, cuando me des-comentar la línea que envía el byte EOI al PIC maestro, los sistemas de fallas triples y luego se reinicia. Del mismo modo, si lo dejo comentó el sistema permanece en funcionamiento.

_outb( PIC_MASTER_CMD_PORT, PIC_EOI );  // this causes (or at least sets off) a triple fault reboot
_outb( PIC_SLAVE_CMD_PORT, PIC_EOI );

Sin ver el resto del sistema, es posible que alguien le explique lo que podría estar sucediendo aquí?

NOTA: Al igual que un disparo en la oscuridad, que sustituyó a la _outb () llamada con otra llamada _outb () que simplemente se aseguró de que las interrupciones se permiten para el controlador IDE, sin embargo, el ensamblado generado habría sido casi idéntica . Esto no causa un fallo.

* _ outb () es un contenedor para la instrucción x86 OUTB.

¿Qué hay de especial en mi función para enviar EOI al PIC maestro que es un problema?

Me doy cuenta sin ver el código de esto puede ser imposible de responder, pero gracias por mirar!

Answer 1

faltas triples por lo general apuntan a un desbordamiento de pila o el puntero de pila impar. Cuando se produce un fallo o una interrupción, el sistema intenta inmediatamente para empujar algunos más basura en la pila (antes de invocar el controlador de fallo). Si se riega la pila, esto hará que otro fallo, que luego trata de empujar más cosas en la pila, lo que hace que otra falla. En este punto, el sistema da por vencido en ti y se reinicia.

Lo sé porque en realidad tengo una patente tonta (mientras se trabaja en Dell hace unos 20 años) en una manera de hacer que un reinicio de la CPU sin necesidad de hardware externo (se hacía a través del controlador de teclado):

   MOV ESP,1
   PUSH EAX    ; triple fault and reset!

Una instrucción OUTB no puede causar un fallo en sí mismo. Mi conjetura es que están volviendo a habilitar una interrupción, y la interrupción se desencadena mientras que algo está mal con su pila.

Answer 2

Cuando se vuelva a habilitar el PIC, lo haces con el conjunto de la bandera de interrupción de la CPU, o se despeja (es decir. Qué haces en algún momento después de un código de operación CLI, o, en algún momento después un código de operación STI)?

Si se asume que la bandera de interrupción de la CPU está activada, el acto de volver a habilitar el PIC permite a cualquier interrupciones pendientes para llegar a la CPU:. Que interrumpir su código, el envío de un vector especificado por el IDT, etc.

Así que espero que no es su código de operación que está causando directamente la culpa:. Más bien, lo que se critica es el código que se ejecuta como resultado de una interrupción que ocurre como resultado de su volver a habilitar el PIC