Wie könnte eine OUTB-Funktion der Baugruppe einen dreifachen Fehler verursachen?

Question

In meiner Systemprogrammierklasse arbeiten wir an einem kleinen, einfachen Hobby-Betriebssystem. Persönlich habe ich an einem ATA-Festplattentreiber gearbeitet. Ich habe entdeckt, dass eine einzige Codezeile einen Fehler zu verursachen scheint, der das System sofort neu startet. Der fragliche Code befindet sich am Ende meiner Interrupt-Service-Routine für die IDE-Interrupts. Da ich die IDE-Kanäle verwende, werden sie über den Slave-PIC gesendet (der über den Master kaskadiert wird). Ursprünglich hat mein Code nur das Ende des Interrupt-Bytes an den Slave gesendet, aber dann sagte mir mein Professor, dass ich es auch an den Master-PIC schicken sollte.

SO ist hier mein Problem, wenn ich die Linie ent-Kommentar, die das EOI-Byte an den Master-PIC sendet, die Systeme dreifach Fehler und dann neu gestartet. Ebenso, wenn ich es kommentiert lasse, läuft das System weiter.

Ohne den Rest des Systems zu sehen, ist es für jemanden möglich zu erklären, was hier möglicherweise passieren könnte?

ANMERKUNG: Genau wie eine Aufnahme im Dunkeln, ersetzte ich den Aufruf _outb() durch einen anderen Aufruf _outb(), der nur dafür sorgte, dass die Interrupts für den IDE-Controller aktiviert waren identisch. Dies verursachte keinen Fehler.

* _outb() ist ein Wrapper für die Anweisung x86 OUTB.

Was ist so besonders an meiner Funktion, EOI an den Master PIC zu senden, der ein Problem ist?

Ich realisiere, ohne den Code zu sehen, dies kann unmöglich zu beantworten sein, aber danke fürs schauen!

Answer 1

Dreifache Fehler weisen normalerweise auf einen Stapelüberlauf oder einen ungeraden Stapelzeiger hin. Wenn eine Störung oder ein Interrupt auftritt, versucht das System sofort, mehr Müll auf den Stapel zu schieben (vor dem Aufruf des Fehlerbehandlers). Wenn der Stapel abgespritzt wird, wird dies einen weiteren Fehler verursachen, der dann versucht, mehr Material auf den Stapel zu schieben, was einen anderen Fehler verursacht. An diesem Punkt gibt das System auf Sie auf und startet neu.

Ich weiß das, weil ich eigentlich eine dumme Patent habe (während bei Dell arbeitet vor etwa 20 Jahren) auf einem Weg, um ein CPU-Reset ohne externe Hardware (verwendet, um durch die Tastatursteuerung zu tun) zu verursachen:

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

Eine OUTB-Anweisung kann keinen Fehler verursachen. Meine Vermutung ist, dass Sie einen Interrupt erneut aktivieren und der Interrupt ausgelöst wird, während etwas mit Ihrem Stack nicht stimmt.

Answer 2

Wenn Sie das PIC wieder aktivieren, machen Sie es mit dem Interrupt-Flag der CPU gesetzt oder gelöscht (dh machen Sie es irgendwann nach einem CLI Opcode, oder irgendwann nach einem STI Opcode)?

Unter der Annahme, dass die Interrupt-Flag der CPU aktiviert ist, Ihr Akt der Wiederfreigabe des PIC ermöglicht alle anstehenden Interrupts um die CPU zu erreichen: der Code unterbrechen würde, Versand in einem Vektor, der durch den IDT angegeben usw.

Also ich erwarte, dass es nicht Ihr Opcode ist, der direkt den Fehler verursacht: eher, was Fehler ist, ist Code, der als Ergebnis eines Interrupts ausgeführt wird, der als Ergebnis der Wiederaktivierung des PICs auftritt.