Thema: Verwirrt durch Interrupts

[bluecode]

Du musst die Adresse von "exception" zur Laufzeit deines Kernels eintragen, d.h. du definierst zuerstmal die GDT ohne das label exception zu verwenden (habs den Deskriptor jetzt nicht auf korrektheit überprüft!):

Code: [Auswählen]

idt_start:
dw 0
dw 0x10
dw 0x8E00
dw 0
Dann vervollständigst du die IDT bevor du sie lädst:

Code: [Auswählen]

mov eax, exception
mov [idt_start], ax
shr eax, 16
mov [idt_start+6], ax

Und genau das hab ich in meinem vorletzten Post bereits vorgeschlagen

[kotzkroete]

Aachso....hm...na ok...dann versuch ich das mal. Danke.

Also ich hab das jetzt so gemacht:

Code: [Auswählen]

idt_start:
dw 0x0000
dw 0x10
dw 0x8E00
dw 0x00
idt_end:

idt_pointer:
dw idt_end - idt_start - 1
dd idt_start


set_idt:
mov eax, exception
mov [idt_start], ax
shr eax, 16
mov [idt_start+6], ax

lidt [idt_pointer]
sti
ret

Und so funktioniert es nicht. Und das liegt am sti. Da verreckt er immer. Wenn ich das sti auskommentiere, gehts, aber das ist ja nicht der Sinn. Denn ich brauche ja interrupts. Die PICs sind auch alle gesetzt. Oder brauche ich noch mehr ISRs?

Edit: Und die Adresse wird auch korrekt kopiert.
Edit: Anscheinend wird die Adresse doch nicht richtig eingetragen. Aber selbst, WENN ich sie manuell richtig eintrage, geht es nicht.

[MNemo]

Oder brauche ich noch mehr ISRs?

Du brauchst auf jeden Fall ein ISR für den Timer(IRQ0), wenn du den nicht ausschaltest.

Und du kannst natürlich auch alle Interrupts(auch exceptions, und so) per asm( INT ) aufrufen um sie zutesten.(ob mit oder ohne 'sti' ist da egal)

[nooooooooos]

Du muss für alle Exeptions und HW-Ints eine ISR haben...wobei du auch überall die Gleiche himachen kannst...Am besten eine ohne Inhalt nur mit einem iret....

Probier mal noch nach dem progarmmieren der PICs, alle Harware-INTs zu deaktivieren. Etwa so:

   mov al, 11111110b                      ;IRQ-0 demaskieren, alle andern maskieren
   out 0x21, al

[kotzkroete]

Dann werd ich erstmal 32+16 interrupts machen....hoffentlich gehts dann :/
Edit: Also manuelles Aufrufen per int funktioniert auch nicht :/
Seltsam :/
Edit: Ich fuerchte, der Eintrag ist falsch. ich habe den Einfach aus einem Tutorial kopiert und die Adresse angepasst, aber das scheint ja falsch zu sein.

Edit: Kann man nicht einfach die BIOS IDT inklusive ISRs irgendwo herbekommen und dann nur auf den PMode zuschneiden?

[Thoth]

Soweit ich weiß verwendet das RM BIOS keine IDT, denn im Realmode gibt es lediglich eine sogenannte Interrupt Vector Table (IVT) am Anfang des Speichers (also Adresse 0), die für jeden Interrupt, angefangen mit dem ersten linear zwei Bytes Segment und zwei Bytes Offset der ISR speichert und bei einem Interrupt guckt die CPU dann halt in der IVT nach.

[bluecode]

Die BIOS ISR enthalten 16bit Code realmode code, das ist nicht unbedingt so wünschenswert im 32bit protected mode.

[nooooooooos]

Und den umzuschreiben macht keinen Sinn und dafür reicht auch dein Leben nicht aus...(Vorrausgesetzt du hast noch ein kleines bisschen Real-Life...)

...Wobei schöne Treiber im PM zu schreiben um ein "richtiges" Betriebsystem mit GUI und aufwendiger API zu machen würde warscheinlich auch zu lange dauern...

Tja darum ist das OS-Dev auch nicht einfach ein kleines Projekt von einem Jahr...Es sei denn man ist mit FAT 16 und einer UI mit 20 Befehlen zufrieden...


Gruss
Nooooooos

[kotzkroete]

Hi, ich bins nochmal...nach einige Zeit hat mich das OS development wieder gepackt, aber ich haenge immernoch an dieser scheiss IDT. Ich glaube aber, dass ich jetzt weiss, wo der Fehler ist, undzar:
Folgendermassen sieht meine IDT aus, ich habe zu Testzwecken alle Eintraege ausgfuellt:

Code: [Auswählen]

idt_start:
%rep 256
dw 0x02ec
dw 0x08  ; <---hier
dw 0x8E00
dw 0x10
%endrep
idt_end:

idt_pointer:
dw idt_end - idt_start - 1
dd idt_start
lidt [idt_pointer]

Die Addresse meiner universal isr ist bei 0x1002ec, die hab ich manuell eingetragen.
An der markierten Stelle soll der "code selector" stehen, hab ich gelesen.
So sieht meine GDT aus:

Code: [Auswählen]

GDTR:

GDTsize DW GDT_END-GDT-1

GDTbase DD GDT



GDT:

NULL_SEL        EQU $-GDT     ; null descriptor is required (64bit per entry)

      DD 0x0

      DD 0x0

CODESEL     EQU $-GDT       ; 4GB Flat Code at 0x0 with max 0xFFFFF limit

      DW     0xFFFF           ; Limit(2):0xFFFF

      DW     0x0              ; Base(3)

      DB     0x0              ; Base(2)

      DB     0x9A             ; Type: present,ring0,code,exec/read/accessed (10011000)

      DB     0xCF             ; Limit(1):0xF | Flags:4Kb inc,32bit (11001111)

      DB     0x0              ; Base(1)

DATASEL     EQU $-GDT       ; 4GB Flat Data at 0x0 with max 0xFFFFF limit

      DW     0xFFFF           ; Limit(2):0xFFFF

      DW     0x0              ; Base(3)

      DB     0x0              ; Base(2)

      DB     0x92             ; Type: present,ring0,data/stack,read/write (10010010)

      DB     0xCF             ; Limit(1):0xF | Flags:4Kb inc,32bit (11001111)

      DB     0x0              ; Base(1)

GDT_END:
Was soll jetzt der code selector sein?
CODESEL?
Den habe ich naemlich eingetragen, ist in dem Falle 8, weil zwar dwords dazwischen sind, aber es geht immer noch nicht.
Ich kann keine interrupts aufrufen. Hoffentlich ist nicht alles so schwierig wie die IDT :/

[bluecode]

Was soll jetzt der code selector sein? CODESEL?

Jo genau das sollte es sein...

Was passiert denn überhaupt (Triple fault?)? Was sagt das bochs log (am besten mal bevor dein kernel ausgeführt word strg+c drücken und das debugging für das CPU device überall auf "report" stellen... Wie testest du deine IDT (IF = 0/1?)?

[Ich hab den Rest vom Thread nicht gelesen.]

[nooooooooos]

Hast du vor dem sti alle Handware Interrupts maskiert?
Zeig bitte mal noch den sti und den PIC Code...

Gruss
Noooooooooos

[kotzkroete]

@noooooos:
Also die Hardware interrupts habe ich DEmaskiert, so wie du es mir in einem anderen Post gesagt hast (zu Testzwecken).
Hiermit remappe ich die PICs:

Code: [Auswählen]

PIC1 equ 0x20
PIC2 equ 0xA0
PIC1_DATA equ PIC1 + 1
PIC2_DATA equ PIC2 + 1

ICW1 equ 0x11
ICW4 equ 0x01


remap_pics: ; eax = offset1 ebx = offset2
push eax

in eax, PIC1_DATA
mov [a1], al

in eax, PIC2_DATA
mov [a2], al

mov eax, ICW1
out PIC1, eax
out PIC1, eax

pop eax
out PIC1_DATA, eax
mov eax, ebx
out PIC2_DATA, eax

mov al, 4
out PIC1_DATA, al
mov al, 2
out PIC2_DATA, al

mov eax, ICW4
out PIC1_DATA, eax
out PIC2_DATA, eax

mov eax, [a1]
out PIC1_DATA, eax
mov eax, [a2]
out PIC2_DATA, eax
ret


a1 db 0
a2 db 0

Und mir

Code: [Auswählen]

mov eax, 0x20
mov ebx, 0x28
call remap_pics
rufe ich die Funktion auf.

Aber egal wie ich es mache, es funktioniert nicht. Kein int funktioniert und qemu friert einfach ein. Ich kann es nicht mal mehr beenden.

[kevin]

Durch Einfrieren signalisiert qemu typischerweise einen Triple Fault.

Du kannst mal probieren qemu mit -d int zu starten, dann bekommst du eine riesige Logfile, wo drinsteht, welche Exception es genau ist und wo sie aufgetreten ist. bochs reagiert in solchen Situationen manchmal souveräner, aber leider auch längst nicht immer.

[nooooooooos]

Wird warschienlich beim sti passieren...Jedenfalls war das bei mir so
Nur dumm dass ich eigentlich nicht weiss warum das passiert ist...$

Hast du direkt nach dem sti eine Endlosschleife? Wenn ja mach soeine auch mal in den Interrupt-Handler...sonst gibt das logisch einen TripleFault...

Könntest du eventuell mal irgendwo deinen ganzen Code hochladen? (nopaste)

Gruss
Nooooooooooos

[kevin]

Wird warschienlich beim sti passieren...Jedenfalls war das bei mir so
Nur dumm dass ich eigentlich nicht weiss warum das passiert ist...$

Daß sich eine kaputte IDT erst nach einem sti bemerkbar macht, ist eigentlich logisch, oder?

Hast du direkt nach dem sti eine Endlosschleife? Wenn ja mach soeine auch mal in den Interrupt-Handler...sonst gibt das logisch einen TripleFault...

Hä? Wieso soll eine Endlosschleife nach dem sti einen Triple Fault verursachen? Das ist doch völlig legitim, da eine Endlosschleife hinzusetzen?

[nooooooooos]

Mit ersterem meinte ich das es nichts bringt zu schauen bei welcher Adresse der Fault auftritt da dies eben logisch ist.

Die Endlosschleife verursacht eben kein Triple Fault aber keine eben eventuell schon...

Gruss
Nooooooooooooos