Como poderia uma função OUTB assembly causa uma falha tripla?

Question

Em meus sistemas de classe nós estamos trabalhando em um pequeno OS passatempo, simples de programação. Pessoalmente, tenho vindo a trabalhar sobre um driver de disco rígido ATA. Eu descobri que uma única linha de código parece causar uma falha que, em seguida, reinicia imediatamente o sistema. O código em questão está no final da minha rotina de serviço de interrupção para as interrupções IDE. Desde que estava a utilizar os canais de IDE, eles são enviados através do PIC secundário (que é em cascata através do mestre). Originalmente o meu código só estava enviando o byte final de interrupção para o escravo, mas depois o meu professor me disse que eu deveria estar enviando-o para o PIC mestre também.

Então aqui está o meu problema, quando eu un-comentário da linha que envia o byte EOI ao mestre PIC, os sistemas de falhas triplos e então reinicia. Da mesma forma, se eu deixá-la comentou as estadias do sistema em execução.

_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 );

Sem ver o resto do sistema, é possível para alguém para explicar o que poderia estar acontecendo aqui?

NOTA: Assim como um tiro no escuro, eu substituiu a chamada _outb () com outra chamada _outb () que apenas a certeza de que as interrupções foram habilitar para o controlador IDE, no entanto, o gerado montagem teria sido quase idêntico . Isso não causar uma falha.

* _ outb () é um wrapper para a instrução x86 OUTB.

O que é tão especial sobre a minha função para enviar EOI ao mestre PIC que é um problema?

Eu percebo sem ver o código pode ser impossível de resposta, mas agradecimentos para olhar!

Answer 1

falhas triplos geralmente apontam para um estouro de pilha ou stack pointer estranho. Quando uma falha ou interrupção ocorre, o sistema imediatamente tenta empurrar mais algum lixo na pilha (antes de chamar o manipulador de falhas). Se a pilha é metralhado, isso fará com que outra falha, que, em seguida, tenta empurrar mais coisas na pilha, o que provoca uma outra falha. Neste ponto, o sistema dá-se em você e reinicializações.

Eu sei disso porque eu realmente tenho uma patente bobo (enquanto trabalhava na Dell cerca de 20 anos atrás) em uma maneira de fazer com que uma redefinição de CPU sem hardware externo (costumava ser feito através do controlador de teclado):

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

Uma instrução OUTB não pode causar uma falha por conta própria. Meu palpite é que você está re-permitindo uma interrupção, e a interrupção é acionado quando algo está errado com o seu stack.

Answer 2

Quando você reativar o PIC, você está fazendo isso com a interrupção jogo da bandeira da CPU, ou apagadas (isto é. Você está fazendo isso em algum momento depois de um opcode CLI, ou, algum tempo depois de um opcode STI)?

Assumindo que a bandeira de interrupção da CPU está habilitado, o seu ato de re-permitindo que o PIC permite que qualquer interrupções pendentes para chegar à CPU:., Que iria interromper seu código, expedição para um vector especificado pelo IDT, etc

Então, eu espero que não é o seu código de operação que está causando diretamente a falha:. Em vez disso, o que está em falha é o código que é executado como resultado de uma interrupção que acontece como resultado de sua re-permitindo que a PIC