Autor Thema: physische Speicherverwaltung - Excpetion 5  (Gelesen 10985 mal)

Savatage

  • Beiträge: 28
    • Profil anzeigen
Gespeichert
« am: 16. August 2016, 10:19 »
Hallo OS-Dev Team :)

Ich kämpfe im Moment mit dem Tutorial Teil 7.  Dabei habe ich mich weitestgehend an Tyndur orientiert. Ich habe die physische Speicherverwaltung umgesetzt, aber noch 2 statische Tasks (im Usermode) in ein Array geschrieben (noch keine Liste). Die Task wechseln sich ganz klassisch über den Interrupt ab.

Ohne Speicherverwaltung klappt alles prima. Mit Speicherverwaltung wird nur noch ein Task ausgeführt und irgendwann tritt eine Exception 5 auf. Das sieht für mich erstmal nach einem Problem mit den Interrupts aus, an denen ich für die Speicherverwaltung ja aber nichts geändert habe. Von dem her bin ich sehr unsicher wo ich überhaupt anfangen muss mit der Fehlersuche, bzw. wo das Problem liegen könnte.
Wenn einer eine Idee hat wo der Fehler sein kann, poste ich auch gern etwas Code. So macht das aber noch nicht viel Sinn.   

Was ist eigentlich die Exception 5? Und tritt das Problem bei anderen auch auf?
Ich muss auch zugeben, dass ich mit dem Debuggen etwas überfordert bin und nicht so richtig weiß wo ich ansetzten sollte.

Ich freue mich auf eure Antworten
Sava

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 16. August 2016, 11:17 »
Erstmal zu deiner Frage, was Exception 5 ist: Das könntest du ganz leicht selber herausfinden. Wie alles fürs OS-Dev wesentliche steht das im Intel-Manual Volume 3, und zwar logischerweise im Kapitel über Interrupts und Exceptions. Dort findest du dann: "Interrupt 5—BOUND Range Exceeded Exception (#BR)". Ich gehe nicht davon aus, dass dein Code absichtlich BOUND benutzt, von daher ist entweder deine Ausgabe falsch (nimm qemu -d int zum prüfen, wenn du das nicht schon hast) oder du führst etwas aus, was du nicht ausführen willst.

Ich weiß nicht genau, was du mit der Speicherverwaltung schon machst, aber der normale Ansatz wäre, alle Aufrufe in die Speicherverwaltung nach und nach auszukommentieren, um zu sehen, welcher das Problem erzeugt, und dann mit vielen kprintfs zu versuchen, herauszufinden, wo der Kernel etwas anderes macht als du denkst.

Eine Option könnte sein, dass der PMM eigentlich belegte Adressen herausgibt, so dass du z.B. deinen Kernelcode überschreibst, wenn du den Speicher benutzt. Wenn du dir alle Adressen ausgeben lässt, die er für Allokationen benutzt, solltest du sowas recht schnell sehen. Das gilt natürlich nur, wenn die erste Allokation das Problem auslöst. Wenn schon die Initialisierung reicht, damit Dinge kaputtgehen, könnte vielleicht der Code, der versucht, die Bitmap zu platzieren, schuld sein. Auch da einfach wieder Adressen ausgeben lassen und schauen, ob das das ist, was du erwartest.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Savatage

  • Beiträge: 28
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 19. August 2016, 09:26 »
Vielen Dank für die Hinweise. Du hast genau das Problem getroffen und mir sehr geholfen.

Effektiv war es nur ein Tippfehler. In der Initialisierung der PMM habe ich beim Durchlaufen der Adressen while (addr > addr_end) statt while(addr < addr_end) geschrieben. Super dämlich, aber beim debuggen lernt man mindestens genau soviel wie beim eigentlichen programmieren :)

Das Intel Manual ist gespeichert und wird ab jetzt zu Rate gezogen bevor ich eine neue Frage an die Community stelle.

Noch einmal besten Dank und bis zur nächsten Frage.

 

Einloggen