Lowlevel
Lowlevel => OS-Design => Thema gestartet von: wissenshunger am 12. January 2014, 17:30
-
Hallo,
nachdem ich einige Treiber programmiert habe und mich aktuell mit dem Thema Paging rumschlage wirft mich der Kernel beim Betrieb auf echter Hardware wieder um einiges zurück.
Mein Kernel hat den Grundaufbau des Tutorial stark beibehalten, jedefalls wenn es um Sachen wie GTD, IVT, Task & Schudule geht.
Und hier liegt auch das Problem! Mein Kernel läuft wunderbar auf Qemu. Manschmal bleibt er beim PMM stehen aber liegt wohl am Qemu, denn bei neustart läuft er weiter. Auf ECHTER Hardware (getestet mit 3 underschiedlichen PC's) passiert folgendes:
- Bootloader wird geladen (GRUB4DOS)
- Grub läd den Kernel
- Kernel läuft
- Erster Task wird gestartet => CPU restet!
=> Vermutlich Triple Fault
Jetzt habe ich alle möglich "hlt" gesetzt, mit print Fehler ausgegeben,etc.
Am Anfang dachte ich, es hat etwas mit der IVT zutun und dem Hardware-Interrupt Timer. Dann vermutete ich den Fehler in den Software Interrupts, da ohne Task der Kernel weiterläuft und testweise mir bei jedem Timer-Interrupt "TIMER!" auf dem Bildschirm schreibt!
Also auszuschließen ist:
- Debug mit Exeption, da sofort CPU-Reset
- Fehler in der IVT
- Fehlerfunktion Software-Interrupts
- fehlerhafte Behandlung von Hardware-Interrupts
- Da bleibt nur noch der Schedule!
Und siehe da der Kernel läuft ohne Schedule (& ohne Task!) ganz normal. Da der orginal Schedule des Tutorial nicht viele Parameter verändern und auch alles korrekt zu sein scheit, liegt es vielleicht an der Datei int_stub.S die in ASM geschrieben ist.
Allerdings konnte ich dort kein Fehler feststellen und er bricht auch nicht ab. ERST wenn der Zustand wiederhergestellt wird, beim Befehl "iret" <<<=== Es funktioniert aber ohne Task (&Schedule)!
Meine letzte Vermutung ist, dass im Befehl init_gdt() irgendwas schief läuft & deswegen für Task irgendwas an Segmenten falsch gesetzt ist. Durch die GDT steig ich allerdings nicht wirklich durch. Und meine ist auch noch orginal getreu wie im Tutorial und läuft unter Qemu ja auch super, aber unter echter Hardware leider nicht!
Hat jemand eine Idee wie das Problem zu lösen oder zumindest Erklärbar wäre?
-
Manschmal bleibt er beim PMM stehen aber liegt wohl am Qemu, denn bei neustart läuft er weiter.
Das wäre mein erster Ansatzpunkt für das Problem. Ein Unterschied zwischen echter Maschine und Qemu sind Details des Speicherlayouts und die Belegung des Speichers durch Datenstrukturen (z.B. Multiboot-Header). Wenn die Speicherverwaltung in QEMU komische Sachen macht, dann könnte sie auf der echten Maschine noch mehr Probleme machen. Ich würde einmal versuchen herauszufinden, warum sie in QEMU nicht zuverlässig funktioniert, und überprüfen, ob sie auf der echten Maschine funktioniert.
-
Hmm... Auf echter Hardware läuft der Speicher. Wie gesagt, der CPU-RESET kommt erst sobald ein Task ausgeführt wird, egal ob Multiboot-Module oder "virtueller Task" im Kernel.
Qemu bleib manschmal bei dem Befehl pmm_init() stehen. Das ist der erste Befehl im Kernel, danach wird das Paging aktiviert. Aber das hat bis jetzt noch nie Probleme auf echter Hardware gemacht.
-
Leider konnte ich den Fehler noch nicht finden. Jemand ne Idee ?
-
Also Qemu bleibt auch bei pmm_init() stehen, wenn ich weit hintem im Code den Timer setze.
Vermutlich kommt Qemu nicht so schnell mit der Ausgabe hinterher, als wie es den Code verarbeitet. Somit könnte es doch etwas mit der Speicherverwaltung zu tun haben, dass er manschmal ohne am Timer zu fummeln stehen bleibt. Evtl. auch Ursache für CPU-Reset bei echter Hardware!
Mein pmm_init():
void pmm_init(struct multiboot_info* mb_info)
{ /* inititalisiert die Speicherverwaltung. Alle Speicherbereiche,
die beim Start des Systems frei sind, müssen als frei markiert werden, der Rest als belegt.
*/
struct multiboot_mmap* mmap = mb_info->mbs_mmap_addr;
struct multiboot_mmap* mmap_end = (void*)
((uintptr_t) mb_info->mbs_mmap_addr + mb_info->mbs_mmap_length);
/* Per Default ist erst einmal alles reserviert */
memset(bitmap, 0, sizeof(bitmap));
/*
* Nur, was die BIOS-Memory-Map als frei bezeichnet, wird wieder als frei
* markiert
*/
while (mmap < mmap_end) {
if (mmap->type == 1) {
/* Der Speicherbereich ist frei, entsprechend markieren */
uintptr_t addr = mmap->base;
uintptr_t end_addr = addr + mmap->length;
while (addr < end_addr) {
pmm_free((void*) addr);
addr += 0x1000;
}
}
mmap++;
}
/* Den Kernel wieder als belegt kennzeichnen */
uintptr_t addr = (uintptr_t) &kernel_start;
while (addr < (uintptr_t) &kernel_end) {
pmm_mark_used((void*) addr);
addr += 0x1000;
}
/*
* Die Multibootstruktur auch, genauso wie die Liste von Multibootmodulen.
* Wir gehen bei beiden davon aus, dass sie maximal 4k gross werden
*/
struct multiboot_module* modules = mb_info->mbs_mods_addr;
pmm_mark_used(mb_info);
pmm_mark_used(modules);
/* Und die Multibootmodule selber sind auch belegt */
int i;
for (i = 0; i < mb_info->mbs_mods_count; i++) {
addr = modules[i].mod_start;
while (addr < modules[i].mod_end) {
pmm_mark_used((void*) addr);
addr += 0x1000; //DEC: 4096 (4k)
}
}
}
Der Timer:
int counter = 1193182 / 100;// FREQUENZ
outb(0x43, 0x32);
outb(0x40, counter & 0xFF);
outb(0x40, counter >> 8);
Das zu noch kurz die Anmerkung, dass der eigentliche Fehler, wie im 1.Post beschieben vorher auftratt, bevor ich den Timer gesetzt habe. Ich habe nämlich zuvor die Standartfrequenz unverändern gelassen und einfach nur den IRQ0 bzw. 32 benutz! Das Problem, dass Qemu manschmal bei pmm_init(); (jedefalls laut Textausgabe!) stehen bleibt bestand dort aber auch.
Mit vmm_map_page() mappe ich in der Funktion vmm_init() die direkt nach pmm_init() aufgerufen wird die erst 8MB Speicher virtuell gleich physischer! Vielleicht liegt auch dort der Fehler.
Vielleicht hilft dieser Post etwas dem Problem auf das Bit zu kommen!
-
Manschmal bleibt er beim PMM stehen aber liegt wohl am Qemu, denn bei neustart läuft er weiter.
Das wäre mein erster Ansatzpunkt für das Problem. Ein Unterschied zwischen echter Maschine und Qemu sind Details des Speicherlayouts und die Belegung des Speichers durch Datenstrukturen (z.B. Multiboot-Header). Wenn die Speicherverwaltung in QEMU komische Sachen macht, dann könnte sie auf der echten Maschine noch mehr Probleme machen. Ich würde einmal versuchen herauszufinden, warum sie in QEMU nicht zuverlässig funktioniert, und überprüfen, ob sie auf der echten Maschine funktioniert.
Wie finde ich herrauß wieso Qemu manschmal bei pmm_init() stehen bleibt?
-
Schwer zu sagen. Vielleicht indem du den Code mit ordentlich Debug-Ausgaben spickst.
Was bei mir deinem Code auffällt, ist dass du nicht prüfst, dass die Speicherbereiche auf ganze Seiten ausgerichtet sind. Adressen und Größen, die in der Multiboot-Info stehen, sind nicht unbedingt Vielfache von 4096 und du musst die Werte selbst ausrichten. Das kann auch auf kernel_start/_end zutreffen, je nach dem wie dein Linkerskript aussieht. Außerdem kann es sein, dass mmap->base und mmap->length größer als 2^32 (4 GB) sind und dann nicht mehr in ein uintptr_t passen. Du solltest vorher prüfen, ob die Werte größer sind und ggf. nur den Bereich unter 2^32 berücksichtigen.
-
kernel_start & end Linker:
SECTIONS
{
. = 0x100000; //Kernel an 1MB laden
kernel_start = .;
.text : {
*(multiboot)
*(.text)
}
.data ALIGN(4096) : {
*(.data)
}
.rodata ALIGN(4096) : {
*(.rodata)
}
.bss ALIGN(4096) : {
*(.bss)
}
. = ALIGN(4096);
kernel_end = .;
-
Jo mit dem Linkerskript sollten kernel_start und kernel_end keine Probleme machen.
-
Außerdem habe ich jetzt mmap->base und mmap->length auf max. 4GB begrenzt.
-
Und die Probleme bestehen leider immer noch! Zum testen auf echter Hardware lade ich noch nicht mal ein Modul, sondern nur den Kernel selbst.
-
Also es muss doch ein Problem mit dem Paging vom Tutorial geben, dann wenn ich PG nicht aktiviere es nicht vom CPU-Reset kommt und es auch kein Anhalten von Qemu gibt!!!
Sobald PG aktiv ==>> CPU-RESET
-
Jetzt gibt er mir eine Exception 14 aus.
Page Fault:
eip=1058309
ERROR:00000101
-
Also es muss doch ein Problem mit dem Paging vom Tutorial geben, dann wenn ich PG nicht aktiviere es nicht vom CPU-Reset kommt und es auch kein Anhalten von Qemu gibt!!!
Diese Schlussfolgerung ist nicht korrekt. Es kann auch woanders noch ein Problem geben. Ein nicht seltenes Szenario sind Fehler in der Speicherverwaltung, bei dem Speicherbereiche, die nicht verwendbar sind, als frei markiert werden, oder Speicherbereiche doppelt vergeben werden. Beide können zur Folge haben, dass in den Page Tables fehlerhafte Werte stehen und Page Faults entstehen. Um das nochmal zu betonen: Dieses Problem ist nicht die einzige mögliche Ursache.
Page Fault:
eip=1058309
ERROR:00000101
Vorschlag: Lass dir Adressen als Hexadezimalzahl ausgeben. Der Wert von EIP ist dann 0x102605. Außerdem solltest du das Register CR2 (Adresse, auf die versucht wurde zuzugreifen) auslesen. Damit kannst du dann nämlich auch was anfangen. Wenn CR2 gleich EIP ist, weißt du, dass die Ausführung des Codes selbst den Page Fault verursacht hat. Wenn sie ungleich sind, ist der Befehl an der Adresse in EIP ein Speicherzugriff. In beiden Fällen kann es manchmal interessant sein welche Funktion an dieser Adresse ist. Wenn du deinen Kernel disassemblierst (objdump -d kernel), solltest du an der Adresse 102605 die dazugehörige Funktion finden.
Der Fehlercode 00000101 sagt dir außerdem, dass es ein Zugriff von User Space aus war (zur Dekodierung dieses Wertes siehe Intel Manuals Volume 3, 4.7 Page Fault Exceptions).
Folgende Theorie: Du hast den letzten Absatz in diesem Abschnitt des Tutorials nicht gelesen: http://www.lowlevel.eu/wiki/Teil_9_-_Paging#Page_Directory_und_Page_Tables
Mit diesem Code funktioniert unser Kernel jetzt wieder. Er bricht allerdings mit einer Exception 14 (einem Page Fault) ab: Das passiert, sobald er in einen Userspace-Task springen möchte. Bisher haben wir alle Pages nur für den Kernel gemappt. Man könnte jetzt natürlich hergehen und einfach das User-Flag setzen, dann funktionieren auch die Tasks wieder. Aber zukunftsfähig ist die Methode, einfach mal die ersten vier Megabytes zu mappen natürlich nicht.
-
(zur Dekodierung dieses Wertes siehe Intel Manuals Volume 3, 4.7 Page Fault Exceptions)
Oder hier: http://www.lowlevel.eu/wiki/Exception#Page_Fault (http://www.lowlevel.eu/wiki/Exception#Page_Fault)
-
ok, ich habe etwas am PG gebastelt und das hat die Exeption ausgelöst. Ich habe nun den standart vom Tutorial hergestellt. Die Exeption ist zwar weg, das Problem mit dem CPU-Reset bleibt.
Qemu läuft zwar jetzt wieder aber es kommt ca. zwischen jedem 10ten und 15ten Startversuch zum Anhalten (ohne Exeption!) bei pmm_init() bzw. vmm_init().
-
Vielleicht indem du den Code mit ordentlich Debug-Ausgaben spickst.
Diese habe ich auch Probiert und unter Qemu bleibt er bei diesem Codeabschnitt (pmm_init()) stehen:
while (mmap < mmap_end) {
if (mmap->type == 1) {
uintptr_t addr = mmap->base;
uintptr_t end_addr = addr + mmap->length;
while (addr < end_addr) {
pmm_free ((void*) addr);
addr += 0x1000;
}
}
mmap++;
}
Vielleicht kann man damit etwas anfang...
-
Und jetzt bitte genauer suchen. :-) Wenn du weißt, wo genau es hängt, dann kriegst du vermutlich auch raus, warum dort hängt.
Ich würde mal auf pmm_free() tippen.
-
void pmm_free(void* page)
{
uintptr_t index = (uintptr_t) page / 4096;
bitmap[index / 32] |= (1 << (index / 32));
}
Mehr steht da nicht drinnen.
-
Und doch steckt da ein Fehler drin. Du willst da (1 << (index % 32)) haben. Sonst landet in der Bitmap nicht allzuviel freier Speicher^^
-
ok, ist bearbeitet. Fehler bleibt.
-
Dann heißt es weitersuchen. Wenn der Kernel hängt, kannst du Qemu nach EIP fragen, um zu erfahren, wo genau er hängt. Da sollte sich eine Endlosschleife befinden, möglicherweise ausgeführt als Denkfehler.
Debug-Ausgaben sind sehr hilfreich. Je nachdem, wie aussagekräftig dein Exception-Handler ist, kannst es nützlich sein, den #NM-Handler zu missbrauchen. Einen NMI kann man in der Qemu-Konsole auslösen. Da Paging ebenfalls ein regelmäßig wiederkehrender unerschöpflicher Quell der Freude ist, solltest du deinem VMM-Code viel Aufmerksamkeit widmen und dessen Ergebnisse mit "info mem" und "info tlb" auf Korrektheit prüfen.
-
Dann heißt es weitersuchen. Wenn der Kernel hängt, kannst du Qemu nach EIP fragen, um zu erfahren, wo genau er hängt. Da sollte sich eine Endlosschleife befinden, möglicherweise ausgeführt als Denkfehler.
Debug-Ausgaben sind sehr hilfreich. Je nachdem, wie aussagekräftig dein Exception-Handler ist, kannst es nützlich sein, den #NM-Handler zu missbrauchen. Einen NMI kann man in der Qemu-Konsole auslösen. Da Paging ebenfalls ein regelmäßig wiederkehrender unerschöpflicher Quell der Freude ist, solltest du deinem VMM-Code viel Aufmerksamkeit widmen und dessen Ergebnisse mit "info mem" und "info tlb" auf Korrektheit prüfen.
Wie kann ich Qemu nach EIP fragen?
Debug-Ausgabe habe ich mit kprintf(); gemacht und dabei ist mir aufgefallen, dass er bei dem zuvor geposteten Codeabschnitt hängt. Exeption wird von Qemu nicht ausgelöst. Bei richtiger Hardware kommt es wohl zum Triple Fault und somit kann keine Exeption ausgelesen werden!
Um das Paging brauch ich mich im Moment auch nicht zu kümmern, da Paging noch nicht aktiv ist, wenn Qemu einfach so stehen bleibt ohne weitere Aktion. Wenn ich into mem oder tlb abrufe sagt mir Qemu nur, das PG noch nicht aktiv ist.
-
Wie kann ich Qemu nach EIP fragen?
"info registers".
Debug-Ausgabe habe ich mit kprintf(); gemacht und dabei ist mir aufgefallen, dass er bei dem zuvor geposteten Codeabschnitt hängt.
Und wo genau?
Exeption wird von Qemu nicht ausgelöst.
Mit "nmi" schon.
Bei richtiger Hardware kommt es wohl zum Triple Fault und somit kann keine Exeption ausgelesen werden!
Das ist schlecht. Wobei ich bezweifle, dass dir Debugging auf der realen Hardware weiterhelfen würde.
Um das Paging brauch ich mich im Moment auch nicht zu kümmern, da Paging noch nicht aktiv ist, wenn Qemu einfach so stehen bleibt ohne weitere Aktion.
Das war mir nicht klar, ist aber dennoch ein gut gemeinter Rat für später. :-)
-
Also laut Qemu
hat EIP=0000fff0
EDX=00000633
alles andere 0!
CR0=60000010 falls das weiter hilft.
Wie bringen mich diese Register weiter? Wie kann ich nach EIP suchen?
-
Die Adresse 0xfff0 sieht verdächtig nach des BIOS-Startadresse aus. Und CR0 verrät dir auch das du dich gerade nicht im Protected Mode befindest.
Sieht also so aus als hätte es auch unter QEMU einen Tripplefault gegeben, nur eben ohne Reboot.
Lass mal alle Interrupts mitloggen qemu -d int … und guck was da so für Exceptions auftreten.
-
SMM: enter
EAX=00000001 EBX=00000000 ECX=02000000 EDX=00000cfc
ESI=000f39fd EDI=0003802d EBP=0000000b ESP=00006ef0
EIP=000f409b EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 000fd3a8 00000037
IDT= 000fd3e6 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=000f39d0 CCD=00000001 CCO=LOGICB
EFER=0000000000000000
SMM: after RSM
EAX=00000001 EBX=00000000 ECX=02000000 EDX=00000cfc
ESI=000f39fd EDI=0003802d EBP=0000000b ESP=00006ef0
EIP=000f409b EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 000fd3a8 00000037
IDT= 000fd3e6 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=ffffff9c CCO=EFLAGS
EFER=0000000000000000
0: v=21 e=0000 i=0 cpl=0 IP=0008:001016c3 pc=001016c3 SP=0010:00109f3c EAX=000000ed
EAX=000000ed EBX=00000002 ECX=00000000 EDX=00000060
ESI=00000014 EDI=00000017 EBP=00109f54 ESP=00109f3c
EIP=001016c3 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00109f2c CCO=SUBL
EFER=0000000000000000
1: v=21 e=0000 i=0 cpl=0 IP=0008:0010170f pc=0010170f SP=0010:00109f5c EAX=00000000
EAX=00000000 EBX=00000002 ECX=00000000 EDX=00000060
ESI=00000014 EDI=00000017 EBP=00109f74 ESP=00109f5c
EIP=0010170f EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00109f4c CCO=SUBL
EFER=0000000000000000
2: v=21 e=0000 i=0 cpl=0 IP=0008:001016c3 pc=001016c3 SP=0010:00109f3c EAX=000000f3
EAX=000000f3 EBX=00000002 ECX=00000000 EDX=00000060
ESI=00000014 EDI=00000017 EBP=00109f54 ESP=00109f3c
EIP=001016c3 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00109f2c CCO=SUBL
EFER=0000000000000000
3: v=21 e=0000 i=0 cpl=0 IP=0008:0010172f pc=0010172f SP=0010:00109f5c EAX=00000000
EAX=00000000 EBX=00000002 ECX=00000000 EDX=00000060
ESI=00000014 EDI=00000017 EBP=00109f74 ESP=00109f5c
EIP=0010172f EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00109f4c CCO=SUBL
EFER=0000000000000000
4: v=21 e=0000 i=0 cpl=0 IP=0008:001016c3 pc=001016c3 SP=0010:00109f3c EAX=000000f4
EAX=000000f4 EBX=00000002 ECX=00000000 EDX=00000060
ESI=00000014 EDI=00000017 EBP=00109f54 ESP=00109f3c
EIP=001016c3 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00109f2c CCO=SUBL
EFER=0000000000000000
5: v=20 e=0000 i=0 cpl=0 IP=0008:00101c10 pc=00101c10 SP=0010:00109f40 EAX=00000000
EAX=00000000 EBX=00000002 ECX=0000055e EDX=000b84be
ESI=00000014 EDI=00000017 EBP=00109f54 ESP=00109f40
EIP=00101c10 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000085 CCD=fffff5c0 CCO=EFLAGS
EFER=0000000000000000
check_exception old: 0xffffffff new 0xe
6: v=0e e=0000 i=0 cpl=0 IP=0008:00102c17 pc=00102c17 SP=0010:f000ff53 CR2=f000ff53
EAX=f0000023 EBX=00000002 ECX=0000055e EDX=00000020
ESI=00000014 EDI=00000017 EBP=00109f54 ESP=f000ff53
EIP=00102c17 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=f000ff53 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000024 CCD=00109f00 CCO=ADDL
EFER=0000000000000000
check_exception old: 0xe new 0xe
7: v=08 e=0000 i=0 cpl=0 IP=0008:00102c17 pc=00102c17 SP=0010:f000ff53 EAX=f0000023
EAX=f0000023 EBX=00000002 ECX=0000055e EDX=00000020
ESI=00000014 EDI=00000017 EBP=00109f54 ESP=f000ff53
EIP=00102c17 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=f000ff4f CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000024 CCD=00109f00 CCO=ADDL
EFER=0000000000000000
check_exception old: 0x8 new 0xe
-
Wenn du dir das Log mal anschaust, fällt dir sicherlich auf, dass sich die Blöcke darin immer wiederholen. Ein Block beginnt mit eine oder zwei Zeilen, die ein paar Informationen über den Interrupt liefert, und dann mehrere Zeilen Registerdump. Die ersten beiden Interrupts (SMM: enter und SMM: after RSM) treten in qemu immer auf, und haben nichts mit deinem OS zu tun. Der darauf folgende Interrupt ist interessant. Der Dump fängt mit der Zeile "0: v=21 ..." an. Das heißt, dass Interrupt 21h (vermutlich IRQ 1 = Keyboard) ausgelöst wurde. Die drei darauffolgenden Interrupts kommen ebenfalls vom Keyboard Controller. Danach kommt ein Abschnitt, der mit "5: v=20 ..." anfängt, das heißt, dass ein Timer-Interrupt ausgelöst wird.
Die erste Frage, die du dir also stellen sollest: Warum treten Interrupts auf, bevor die Speicherverwaltung initialisiert ist, oder genauer warum aktivierst du Interrupts bevor die Speicherverwaltung initialisiert ist? Wenn du das nicht tust (und dir sicher bist, dass du das auch nicht ausversehen tust), wie konnte es dann kommen, dass du das Problem in pmm_init vermutet hast, wo doch das System offensichtlich danach weiterläuft?
Weiter mit dem Log:
check_exception old: 0xffffffff new 0xe
6: v=0e e=0000 i=0 cpl=0 IP=0008:00102c17 pc=00102c17 SP=0010:f000ff53 CR2=f000ff53
Das ist ein Page Fault. Die treten nur auf, wenn Paging aktiv ist. Wie kann das denn passieren, wo du doch oben gesagt hast, dass du kein Paging aktiviert hast?
Die Ursache für den Page Fault ist übrigens, dass ESP auf f000ff53 gesetzt wurde. Das ist ein Wert der in der IVT steht, welche sich an Adresse 0 befindet. Meine Vermutung ist, dass du Multitasking-Code hast, der einen NULL-Pointer derefenziert. Der Wert EIP=00102c17 kann dir bei der Suche helfen, indem du den Kernel disassemblierst (objdump -x kernel), und nach der Adresse 102c17 in der Ausgabe suchst. Dann solltest du herausfinden, in welcher Funktion sich dein Kernel befunden hat, als das aufgetreten ist.
-
Der darauf folgende Interrupt ist interessant. Der Dump fängt mit der Zeile "0: v=21 ..." an. Das heißt, dass Interrupt 21h (vermutlich IRQ 1 = Keyboard) ausgelöst wurde. Die drei darauffolgenden Interrupts kommen ebenfalls vom Keyboard Controller. Danach kommt ein Abschnitt, der mit "5: v=20 ..." anfängt, das heißt, dass ein Timer-Interrupt ausgelöst wird.
Wieso IRQ 0 und 1 an dieser Stelle ausgelöst werden verstehe ich allerdings auch nicht. Interessant ist, dass pmm_init() bei mehreren Tests durchgelaufen ist aber der Kernel trotzdem nach Beendigung stehen bleibt. An dieser Stelle ist aber noch kein Inerrupt aktiviert worden und Qemu sagt mir weiter, das PG nicht aktiv ist.
Die erste Frage, die du dir also stellen sollest: Warum treten Interrupts auf, bevor die Speicherverwaltung initialisiert ist, oder genauer warum aktivierst du Interrupts bevor die Speicherverwaltung initialisiert ist? Wenn du das nicht tust (und dir sicher bist, dass du das auch nicht ausversehen tust), wie konnte es dann kommen, dass du das Problem in pmm_init vermutet hast, wo doch das System offensichtlich danach weiterläuft?
Diese Frage habe ich mir gestellt und ehrlich gesagt weiß ich nicht wieso diese Fehler auftretten, wenn der Kernel gar nicht weiter läuft und Qemu einfach stehem bleibt.
check_exception old: 0xffffffff new 0xe
6: v=0e e=0000 i=0 cpl=0 IP=0008:00102c17 pc=00102c17 SP=0010:f000ff53 CR2=f000ff53
Das ist ein Page Fault. Die treten nur auf, wenn Paging aktiv ist. Wie kann das denn passieren, wo du doch oben gesagt hast, dass du kein Paging aktiviert hast?
[/quote]
Laut Qemu ist kein Paging aktiv!
Die Ursache für den Page Fault ist übrigens, dass ESP auf f000ff53 gesetzt wurde. Das ist ein Wert der in der IVT steht, welche sich an Adresse 0 befindet. Meine Vermutung ist, dass du Multitasking-Code hast, der einen NULL-Pointer derefenziert. Der Wert EIP=00102c17 kann dir bei der Suche helfen, indem du den Kernel disassemblierst (objdump -x kernel), und nach der Adresse 102c17 in der Ausgabe suchst. Dann solltest du herausfinden, in welcher Funktion sich dein Kernel befunden hat, als das aufgetreten ist.
Adresse 102c17 gibt es nicht, wenn ich alles richtig gemacht habe:
objdump -x kernel > kernel.txt
...danach in kernel.txt nach 102c17 gesucht => kein Treffer!
Aber hier mal am Rande die Frage: Wenn jemand das Tutorial ohne weiteres compiliert hat, hätte ihm doch den selbe Fehler auffallen müssen. Wieso funktioniert das bei mir nur nicht? Oder hat ihn bis her niemand auf echter Hardware probiert?!
Seltsam....
-
Aber hier mal am Rande die Frage: Wenn jemand das Tutorial ohne weiteres compiliert hat, hätte ihm doch den selbe Fehler auffallen müssen. Wieso funktioniert das bei mir nur nicht? Oder hat ihn bis her niemand auf echter Hardware probiert?!
Seltsam....
Das Tutorial liefert ja nicht den vollständigen Code, sondern es lässt viele Sachen offen, die der Leser implementieren muss. Da kann einiges schief gehen.
Wenn Interrupts auftreten, obwohl du glaubst, dass Interrupts deaktiviert sind, wenn Page Faults auftreten, obwohl du glaubst, dass Paging deaktiviert ist, und wenn du Code im disassemblierten Kernel nicht findest, dann läuft irgendwas grundlegendes falsch. Ohne Code kann ich dir da nicht weiterhelfen. Wenn du willst, kannst du das irgendwo hochladen (z.B. in ein GIT-Repository), dann werde ich mir das mal anschauen.
-
Laut Qemu ist kein Paging aktiv!
Laut log ist Paging schon vor dem ersten IRQ aktiv. (Siehe CR0)
Dass dir Qemu sagt es wäre nicht aktiv, liegt vermutlich daran, dass du das erst dann abfragst wenn Qemu wegen des Tripplefaults schon wieder rettetet wurde.
-
Laut Qemu ist kein Paging aktiv!
Laut log ist Paging schon vor dem ersten IRQ aktiv. (Siehe CR0)
Dass dir Qemu sagt es wäre nicht aktiv, liegt vermutlich daran, dass du das erst dann abfragst wenn Qemu wegen des Tripplefaults schon wieder rettetet wurde.
Das würde Sinn machen. Aber wie kann ich jetzt im info mem oder info tlb Daten auslesen, wenn Qemu schon reset hat? Kann ich den Rest irgendwie ausschalten?
-
qemu -no-reboot -no-shutdown ...
-
Hat geklappt!
info mem gibt folgendes aus:
00000000-00800000 00800000 urw
info tlb kann ich leider nicht komplett auslesen.
info registers:
EAX=f0000023 EBX=00000002 ECX=0010ee00 EDX=00000020
ESI=00000014 EDI=00000011 EBP=00109ff4 ESP=f000ff53
EIP=00102c17 EFL=00000002
...
GDT= 0012a060 0000002f
IDT= 0012a0a0 999997ff
CR0=80000011 CR2=f000ff4f CR3=00001000 CR4-DR0-DR3=00000000
DR6=ffff0ff0 DR7=00000400
...
Dazu Qemu INT-Log:
0: v=20 e=0000 i=0 cpl=0 IP=0008:00103b28 pc=00103b28 SP=0010:00109fa8 EAX=00000030
EAX=00000030 EBX=00000002 ECX=0010ee00 EDX=00082bf2
ESI=00000014 EDI=00000011 EBP=00109ff4 ESP=00109fa8
EIP=00103b28 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000034 CCD=00109f68 CCO=ADDL
EFER=0000000000000000
check_exception old: 0xffffffff new 0xe
1: v=0e e=0000 i=0 cpl=0 IP=0008:00102c17 pc=00102c17 SP=0010:f000ff53 CR2=f000ff53
EAX=f0000023 EBX=00000002 ECX=0010ee00 EDX=00000020
ESI=00000014 EDI=00000011 EBP=00109ff4 ESP=f000ff53
EIP=00102c17 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=f000ff53 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000024 CCD=00109f68 CCO=ADDL
EFER=0000000000000000
check_exception old: 0xe new 0xe
2: v=08 e=0000 i=0 cpl=0 IP=0008:00102c17 pc=00102c17 SP=0010:f000ff53 EAX=f0000023
EAX=f0000023 EBX=00000002 ECX=0010ee00 EDX=00000020
ESI=00000014 EDI=00000011 EBP=00109ff4 ESP=f000ff53
EIP=00102c17 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=f000ff4f CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000024 CCD=00109f68 CCO=ADDL
EFER=0000000000000000
check_exception old: 0x8 new 0xe
Das sind alles aktuelle Daten, die Qemu beim Stopp liefert.
-
Ich habe nochmal mit objdump -dS kernel >kernel.txt disasm. & da finde ich Adresse 102c17 in 00102bf8 <intr_common_handler>:
00102bf8 <intr_common_handler>:
102bf8: 55 push %ebp
102bf9: 57 push %edi
102bfa: 56 push %esi
102bfb: 52 push %edx
102bfc: 51 push %ecx
102bfd: 53 push %ebx
102bfe: 50 push %eax
102bff: 66 b8 10 00 mov $0x10,%ax
102c03: 8e d8 mov %eax,%ds
102c05: 8e c0 mov %eax,%es
102c07: 54 push %esp
102c08: e8 56 11 00 00 call 103d63 <handle_interrupt>
102c0d: 89 c4 mov %eax,%esp
102c0f: 66 b8 23 00 mov $0x23,%ax
102c13: 8e d8 mov %eax,%ds
102c15: 8e c0 mov %eax,%es
102c17: 58 pop %eax
102c18: 5b pop %ebx
102c19: 59 pop %ecx
102c1a: 5a pop %edx
102c1b: 5e pop %esi
102c1c: 5f pop %edi
102c1d: 5d pop %ebp
102c1e: 83 c4 08 add $0x8,%esp
102c21: cf iret
...
-
int_stub.S:
...
intr_common_handler:
// CPU-Zustand sichern
push %ebp
push %edi
push %esi
push %edx
push %ecx
push %ebx
push %eax
// Kernel-Datensegmente laden
mov $0x10, %ax
mov %ax, %ds
mov %ax, %es
// Handler aufrufen
// Der Rueckgabewert ist der Prozessorzustand des moeglicherweise
// gewechselten Tasks. Wir muessen also den Stack dorthin wechseln
// um die Register wiederherzustellen.
push %esp
call handle_interrupt
mov %eax, %esp
// User-Datensegmente laden
mov $0x23, %ax
mov %ax, %ds
mov %ax, %es
// CPU-Zustand wiederherstellen
pop %eax
pop %ebx
pop %ecx
pop %edx
pop %esi
pop %edi
pop %ebp
// Fehlercode und Interruptnummer vom Stack nehmen
add $8, %esp
iret
Also bedeutet das doch, dass es bei pop %eax zum Fault kommt. Was sagt mir das jetzt?
-
Dass der Stack kaputt ist. Da der Rückgabewert von handle_interrupt nach %esp geladen wird, heißt das, dass handle_interrupt einen ungültigen Wert zurückliefert.
-
Es muss also an der Funktion handle_interrupt liegen oder liegt es am Kernel Stack bzw. Am aktuellen Task Stack? Was heißt Stack kaputt?
-
Es muss also an der Funktion handle_interrupt liegen oder liegt es am Kernel Stack bzw. Am aktuellen Task Stack?
Ja handle_interrupt ist einer der Verdächtigen. Auch alles, das von handle_interrupt aufgerufen wird. Einer von denen sorgt dafür, dass der Kernel Stack falsch gesetzt wird indem das return-Statement in handle_interrupt etwas fehlerhaftes zurückgibt.
Was heißt Stack kaputt?
Im Allgemeinen heißt es, dass der Stack überschrieben wurde, es einen Stack Overflow gab oder der Stack Pointer einen fehlerhaften Wert hat.
In diesem Fall lässt sich aus dem "ESP=f000ff53" in den Logs von QEMU ablesen, dass der Stack Pointer einen fehlerhaften Wert hat. Es lässt sich sogar noch etwas mehr sagen, denn der Wert f000ff53 steht mehrfach in der IVT (die sich an Adresse 0 befindet). Das heißt die wahrscheinlichste Ursache ist eine Dereferenzierung eines NULL-Pointers und der fälschlich gelesene Wert wurde nach ESP geladen (über das return-Statement in handle_interrupt).
-
struct cpu_state* handle_interrupt(struct cpu_state* cpu)
{
struct cpu_state* new_cpu = cpu;
if (cpu->intr <= 0x1f) {
// ... Exeptions
while(1) {
// Prozessor anhalten
asm volatile("cli; hlt");
}
} else if (cpu->intr >= 0x20 && cpu->intr <= 0x2f) {
// ====> AB HIER HARDWARE INTERRUPTS <====
if (cpu->intr == 0x20) { //TIMER
// kprintf("!! TIMER !!\n");
// TIMER_ITR();
new_cpu = schedule(cpu);
// kprintf("!! SCHEDULE !!\n");
tss[1] = (uint32_t) (new_cpu + 1);
}
if (cpu->intr == 0x21) { //Keyboard
interruptevent = 3;
keypress = kbd_read();
}
if (cpu->intr == 0x24) { //SS0
interruptevent = 4;
}
if (cpu->intr == 0x26) { //FDC
interruptevent = 6;
FLOPPY_IRQ();
}
if (cpu->intr >= 0x28) {
// EOI an Slave-PIC
outb(0xa0, 0x20);
}
// EOI an Master-PIC
outb(0x20, 0x20); // PIC zurueksetzen
// =======================================
} else if (cpu->intr == SYSCALL_INTERRUPT) {
new_cpu = syscall(cpu);
} else {
kprintf("Unbekannter Interrupt\n");
while(1) {
// Prozessor anhalten
asm volatile("cli; hlt");
}
}
/*
if (cpu != current_task->cpu_state) {
asm volatile("mov %0, %%cr3" : : "r" (cpu->context));
} */
return new_cpu;
}
Da er bei echter Hardware immer nach dem Schedule abstürzt hier auch dieser Code:
struct cpu_state* schedule(struct cpu_state* cpu)
{
/*
* Wenn schon ein Task laeuft, Zustand sichern. Wenn nicht, springen wir
* gerade zum ersten Mal in einen Task. Diesen Prozessorzustand brauchen
* wir spaeter nicht wieder.
*/
if (current_task != NULL) {
current_task->cpu_state = cpu;
}
/*
* Naechsten Task auswaehlen. Wenn alle durch sind, geht es von vorne los
*/
if (current_task == NULL) {
current_task = first_task;
} else {
current_task = current_task->next;
if (current_task == NULL) {
current_task = first_task;
}
}
/* Prozessorzustand des neuen Tasks aktivieren */
cpu = current_task->cpu_state;
// ###############################################################################
return cpu;
}
Also ich kann kein Fehler sehen und das irgendwo NULL ausgegeben wird auch nicht.
Hier auch nochmal die intr.h:
#ifndef INTR_H
#define INTR_H
#include <stdint.h>
#include "multiboot.h"
struct cpu_state {
// Von Hand gesicherte Register
uint32_t eax;
uint32_t ebx;
uint32_t ecx;
uint32_t edx;
uint32_t esi;
uint32_t edi;
uint32_t ebp;
uint32_t intr;
uint32_t error;
// Von der CPU gesichert
uint32_t eip;
uint32_t cs;
uint32_t eflags;
uint32_t esp;
uint32_t ss;
};
void init_gdt(void);
void init_intr(void);
void init_multitasking(struct multiboot_info* mb_info);
struct cpu_state* handle_interrupt(struct cpu_state* cpu);
struct cpu_state* schedule(struct cpu_state* cpu);
#endif
-
Wann tritt der Fehler auf?
Nach dem ersten Timer interrupt. (Siehe Qemu Log)
Was gibt handle_interrupt in diesem Fall zurück?
new_cpu = schedule(cpu);
Was gibt schedule(cpu) zurück?
vermutlich: first_task->cpu_state;
Wie ist first_task initialisiert?
Vermutlich ist hier der NULL-Pointer, der dereferenziert wird.
Falls das doch noch nicht der Fall war, kannst du auch mal versuchen die erste Page nicht zu Mappen. Dein Kernel wird die nicht brauchen. Dann knallt's gleich wenn du einen NULL-Pointer dereferenzierst.
-
Nach Kontrolle von init_task und kleinen veränderungen tretten die letzten beiden Eceptions nach dem Timer IRQ bei folgenden Befehle im handle_interrupt auf:
push %ecx
Und
pop %ecx
Ich versteh einfach nicht wodran es liegt. Ich habe teilweise wieder orginal Code zum Tutorial wiederhergestellt und trotzem kommich vom Triple Fault nicht weg.
Langsam verzweifel ich.
-
Jetzt macht mein Kernel noch andere komische Sachen. -.-
Wie es scheint wird jetzt nach dem Timer IRQ eine #GP ausgelöst und danach eine #PF, dann gefolgt vom #DF [Qemu stopp]
1: v=20 e=0000 i=0 cpl=0 IP=0008:0010166f pc=0010166f SP=0010:00109f3c EAX=000000ed
EAX=000000ed EBX=00000002 ECX=00000000 EDX=00000060
ESI=00000014 EDI=00000020 EBP=00109f54 ESP=00109f3c
EIP=0010166f EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000010 CCD=00109f30 CCO=EFLAGS
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
2: v=0d e=0000 i=0 cpl=0 IP=0008:00102bcd pc=00102bcd SP=0010:00001024 EAX=00002027
EAX=00002027 EBX=00003007 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00001024
EIP=00102bcd EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000000 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00001024 CCO=ADDL
EFER=0000000000000000
check_exception old: 0xffffffff new 0xe
3: v=0e e=0002 i=0 cpl=0 IP=0008:00102ba8 pc=00102ba8 SP=0010:00001000 CR2=00000ffc
EAX=00002027 EBX=00003007 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00001000
EIP=00102ba8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000ffc CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00001024 CCO=ADDL
EFER=0000000000000000
check_exception old: 0xe new 0xe
4: v=08 e=0000 i=0 cpl=0 IP=0008:00102ba8 pc=00102ba8 SP=0010:00001000 EAX=00002027
EAX=00002027 EBX=00003007 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00001000
EIP=00102ba8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000ffc CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000008 CCD=00001024 CCO=ADDL
EFER=0000000000000000
check_exception old: 0x8 new 0xe
-
Also wenn die erste Page nicht mappe, spri. physisch = virtuell erst ab 4096KB, dann wird sofort eine #PF ausgelöst, log dazu:
0: v=0e e=0000 i=0 cpl=0 IP=0008:0010444a pc=0010444a SP=0010:00109f3c CR2=00000400
EAX=00000400 EBX=00000002 ECX=00000000 EDX=00000400
ESI=00000014 EDI=00000020 EBP=00109f50 ESP=00109f3c
EIP=0010444a EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00105180 00000080 0000e900 DPL=3 TSS32-avl
GDT= 0012a060 0000002f
IDT= 0012a0a0 000007ff
CR0=80000011 CR2=00000400 CR3=00001000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000400 CCD=00000400 CCO=ADDL
EFER=0000000000000000
Das blöde dazu, wenn ich objdump mit den Option -dS speicher und durchsuche, finde ich Adresse 10444a nicht.
-
Liest du für irgend etwas die BIOS Data Area (BDA) aus? Die liegt nämlich genau bei 0x400.
Hast du denn irgend etwas in der nähe von 0x10444a, bzw. was liegt denn so davor und dahinter ?
Wenn du es nur grob wissen willst oder code weit weg ist kannst du auch mit 'nm <kernel>' nur die labels ausgeben lassen.
-
Liest du für irgend etwas die BIOS Data Area (BDA) aus? Die liegt nämlich genau bei 0x400
Beim Starten lese ich die BDA aus um Daten zur seriellen Schnittstelle zu bekommen etc.
-
Mir kommt gerade eine Idee weil ich mich gefragt habe wieso Qemu doch manschmal weiter läuft.
Könnte der Fehler daran liegen, dass die Taskliste mit Null init. wird und wenn die Interrupts aktiviert werden der schedule dann null zurück gibt, dann noch kein Task in dieser Zeit aktiv ist bis das erste Mal Timer IRQ kommt? Interessanterweise ist nach änderung der Timerfrequenz an Problem mit Qemu schlimmer geworden! Das würde auch erklären wieso echte Hardware sofort resetet! Bei echter Hardware ist der Timer genUer oder er braucht länger den ersten Task zu init als der Timer und deswegen kommt es zu dieser geheimnisvollen Null, dass das ganze System zum absturz bringt.
-
Also wenn der Scheduler dann NULL zurückgibt, dann ist das wohl die Ursache füf deine Fehler. Du solltest im Scheduler überprüfen, ob es überhaupt einen Task gibt, zu dem man wechseln kann. Ansonsten wird einfach der Task nicht gewechselt.
-
Meine Vermutung hat sich bewahrheitet!
Das Problem war die ganze Zeit, dass bei echter Hardware der Timer Interrupt früher auslöste als überhaupt der erste Task angelegt werden konnte! Bei Qemu mit Standart-Timerfrequenz hat es manschmal doch geklappt.
Bei folgendem Codeausschnitt vom Schedule:
cpu = current_task->cpu_state;
return cpu;
}
...habe ich einfach "if (current_task != NULL)" eingebaut:
if (current_task != NULL)
cpu = current_task->cpu_state;
return cpu;
}
..und siehe da, dass PROBLEM ist behoben. Man man man was ein langer Weg für so wenig Code.
Wenn current_task = NULL ist wird der letzte CPU Stand einfach gelassen. Dieser Zustand kommt ja nur vor, wenn die Interrupts aktiviert werden und es noch wenige (m)sek. dauert bis der erste Task gestartet ist.
Bitte bitte ändert das mal jemand im Tutorial, damit dieser Fehler nicht bei irgendjemand sonst auftretten kann. Er ist überaus lästig!
Somit bedanke ich mich hiermit ganz herzlich bei jedem der sich hier mit den Kopf zerbrochen hat. Ich habe sehr viel über debugging gelernt und bin um einiges fitter in Sachen Register geworden. Vielen lieben Dank! Damit erkläre ich dieses Thema für erledigt und geschlossen! Danke!
-
Die Frage ist eher, warum der Scheduler so früh aufgerufen wird. Sollten eigentlich nicht Hardwareinterrupts deaktiviert sein, bis du alles fertig initialisiert hast?
-
Trotzdem ist es ein Fehler, denn nehmen wir mal an alle Task wurden beendet, dann gibt es immer einen Fault und das ist doch nicht schön.
-
Wenn alle Tasks beendet wurden, hast du sowieso ein größeres Problem, das deine Änderung auch nicht löst.
-
Wieso habe ich noch ein größeres Problem? Wie wäre es besser gelöst?
-
Wer startet neue Tasks, wenn kein Task läuft?
Deine Idle-Schleife wird das eher nicht tun.
-
Die Idleschleife wäre auch schon ein Task.
Das Problem entsteht beim Beenden des letzten Tasks: Was ist denn dann der nächste Zustand, in den der Kernel springen sollte? Dein Scheduler wird mit deiner Änderung den Task nicht mehr wechseln, also macht der Kernel im gerade beendeten und freigegebenen Task weiter. Was das genau bedeutet, kannst du dir selber überlegen.
-
Was ist, wenn ich einen Leerlauf Task erstelle der einfach nur eine Endlosschleife ist? Dieser Task nicht nicht beendbar.
-
Linux kennt eine Funktion panic(), die den Kernel tötet. Wenn keine Tasks vorhanden sind, dann solltest du deinen Kernel töten. Dein Leerlauf-Task schützt den Kernel dann vor dem out-of-tasks-panic. :-)
In die Endlosschleife solltest du wenigstens ein __asm__ volatile("hlt") reinmachen, damit dein Qemu nicht 100% CPU-Leistung vom Host saugt, wenn in deinem System nichts zu tun ist. Wenn das nur eine Endlosschleife sein soll, dann solltest du die auch nur dann aufrufen, wenn es sonst keine lauffähigen Tasks gibt.
-
Wie kann man den einen Kernel töten?
-
Wie kann man den einen Kernel töten?
Mit der Kreissäge? Aus deiner Perspektive befindet sich der Kernel in der Matrix.
-
Wie kann man den einen Kernel töten?
Svenska meint damit eine Endlosschleife:
In die Endlosschleife solltest du wenigstens ein __asm__ volatile("hlt") reinmachen, damit dein Qemu nicht 100% CPU-Leistung vom Host saugt, wenn in deinem System nichts zu tun ist. Wenn das nur eine Endlosschleife sein soll, dann solltest du die auch nur dann aufrufen, wenn es sonst keine lauffähigen Tasks gibt.
Optional ist es den Bildschirm blau einzufärben und kryptische Stackdumps und Fehlercodes sowie irgendwas von wegen "Wenden Sie sich an den Administrator" anzuzeigen.