Themen

1

Lowlevel-Coding / Seltsamer Pagefault

« am: 20. August 2013, 01:23 »

Hi,
ich habe momentan ein Problem bei dem ich nicht mehr weiter weiß. Vor ein paar Tagen hab ich mal wieder an meinem Kernel gebastelt und er ist nun so weit dass er einen simplen userspace-Prozess ausführen kann. Der userspace-Prozess ruft dabei einen simplen Syscall auf, der eine einfache Textzeile ausgibt. So sieht es aus, wenn es funktioniert:

Als ich dann anfing meinen simplen Prozess zu erweitern, fingen die Probleme an. Wenn der userspace-Prozess groß genug wird fällt der Kernel beim Sprung in den userspace auf die Nase, das scheint aufzutreten sobald der Prozess im RAM die Größe einer Page übersteigt. Das sieht dann folgendermaßen aus:

Um das Problem einzugrenzen hab ich dann meinen Testprozess vereinfacht, er sieht so aus:

Code: (asm) [Auswählen]

mov eax, 42
int 0x62
jmp $

xchg eax, eax
[...]Wie man sieht, keine Stackzugriffe und nur ein simpler Syscall, aufgeblasen wird das dann mit sehr vielen "xchg eax, eax"-Befehlen um das Programm groß genug zu bekommen um den Crash zu provozieren.
Natürlich hab ich mir dann das Logfile von qemu angesehen, ich hab es mal hier auf pastebin gepackt.
Was mich zunächst daran irritiert ist das cr2 die Adresse 0x00000000 angibt. Dort ist die obere Grenze des vom Kernel bereitgestellt usermode-Stacks, aber ein Zugriff auf den Stack findet ja gar nicht statt! Um ganz sicher zu sein hab ich mir zunächst per objdump die Anweisung an der von qemu angegebenen eip-Adresse angesehen, und dort steht ganz brav mein "mov eax, 42". Also, tatsächlich kein Stackzugriff, und beim instruction fetch scheints ja auch nicht zu krachen (sonst wäre ja cr2=eip), also was will die CPU an 0x00000000?
Ebenfalls seltsam ist, dass der error-code angibt, die Page sei nicht gemappt. Ich hab daher probiert per "info tlb" aus qemu mehr Infos herauszubekommen, und um das ganze vergleichen zu können hab ich das einmal mit einer funktionierenden Version des Programms (d.h. klein genug) und einmal mit der nicht funktionierenden Version getan:
1. Funktionierend
2. Nicht funktionierend
Ich hab die beiden Files dann mit einem diff-Tool (meld) verglichen, dabei fiel mir zunächst auf, dass in der nicht funktionierenden Version folgende Zeile fehlte: "00000000fffff000: 0000000000192000 ---DA--UW". D.h. der Stack ist nicht gemappt - wie bereits der Pagefault sagte. Auffällig ist auch das hier:
0000000040000000: 0000000000195000 ----A--UW
0000000040001000: 0000000000000000 -------UW
Die zweite Page des Programmes ist also nicht korrekt gemappt. Das sind zwar schon zwei Probleme, allerdings dürften beide nicht für den Pagefault verantwortlich sein. Es ist mir auch ein Rätsel, warum diese beiden Adressen nicht korrekt gemappt sind - die entsprechenden Code-Zeilen wurden definitiv ausgeführt.

Ich habe jetzt schon einige Stunden damit verbracht auf logs zu starren und an meinem Code herumzubasteln, aber die Ursache für den Pagefault und die zwei anderen Fehler konnte ich nicht finden, trotz zahlreicher eingefügter Print-Anweisungen. Daher poste ich mein Problem nun hier, in der Hoffnung dass jemand von euch eine Idee oder einen Tipp hat, damit ich dieses Problem endlich beheben kann. Der Code entspricht, abgesehen von ein paar zusätzlichen print-Anweisungen, der Version im Repository. Relevant für mein Problem dürften wohl vor allem elf.bas, modules.bas und vmm.bas sein.

Grüße,
TheThing


/edit: Ich hab mal eine ISO mit besagtem Problem hochgeladen: http://venom.improved-madness.de/frost.iso

2

tyndur / Kleine Ungenauigkeit in kernel2

« am: 31. March 2013, 17:00 »

Hi,
ich glaube einen kleinen "Fehler" in der SMP-Implementierung von kernel2 gefunden zu haben. Laut Spezifikation liegt der dritte Bereich, in dem der floating pointer liegen kann zwischen 0x0F0000 und 0x0FFFFF, kernel2 sucht an dieser Stelle allerdings bereits ab 0x0E0000 und sucht damit einen doppelt so großen Bereich ab. Habe ich da irgendetwas übersehen oder ist das tatsächlich ein Fehler in kernel2? Sollte es einer sein dürfte das ja eigentlich nicht weiter schlimm sein (der kernel betreibt dann halt nur mehr Aufwand als nötig), könnte allerdings Lernende etwas verwirren, so wie mich vorhin

3

OS-Design / Verwaltung von Threads

« am: 24. September 2012, 04:53 »

Hi,
so nach dem Abitur und vor dem Studium hat man ja doch relativ viel Zeit... Daher bin ich auch mal wieder über meinen Kernel bzw. mein OS gestolpert. Der einfachheit mal schnell ein Debian Wheezy in einer VM aufgesetzt, repository geklont und los ging der Spaß.
Dann erstmal jede Menge alte Debugging-Ausgaben entfernt, am Paging-Code geschraubt und mal wieder an der Überarbeitung des Multitaskings gebastelt. Dabei fiel mir folgendes auf: Ich habe zwar die Verwendung von Threads vorgesehen, allerdings ruft mein Scheduler die Threads stumpf nacheinander auf. Da Threads evtl. blockiert sein können, ist das nicht wirklich schön. Nachdem ich dann eine Weile rumprobiert hatte, kam ich zu dem Schluss, dass es ziemlich unpraktisch ist, wenn mein Scheduler versucht, eine Art Baumstruktur abzuarbeiten (Es gibt eine Linked-List mit Prozessen, jeder Prozess enhält eine Linked-List von Threads).
Daher stellt sich mir die Frage: Wie könnte man das besser lösen? Ich habe mir dazu bisher nur tyndur-Code angesehen. Der "alte" Kernel kann ja keine Threads, daher habe ich mir Kernel2 mal angesehen. Da komme ich allerdings nicht so ganz mit. Es werden ja scheinbar Listen genutzt, die der Scheduler stumpf durchlaufen kann. Allerdings gibt es da zwei Listen (threads_available und threads_scheduled). Wofür genau sind die zwei da, und wie werden sie benutzt?

Eine kleine Idee die ich gerade hatte (vielleicht macht Kernel2 das ähnlich?):
Ich nehme zwei Linked-Lists, in der einen hängen alle Threads, die zweite ist leer. Der Scheduler fängt dann an, aus der ersten Liste Threads zu nehmen. Ist der Thread lauffähig, wird er ausgeführt, wenn nicht, wandert er gleich in die zweite Liste. Ist ein Thread durchgelaufen, wandert er auch in die zweite Liste. Wenn die erste Liste leer ist, wird dann getauscht.
Allerdings stellt sich mir da noch eine Frage: Meine momentanen Verwaltungsstrukturen sind ja Baum-mäßig. Wenn ich jetzt Threads einfach in Listen lege, geht mir ja diese klare Zuordnung (Thread gehört zu Prozess) verloren. Wie soll ich dann die Prozesse effizient verwalten? Z.B. wenn ein Prozess gekillt werden muss.

Daher möchte ich hier mal wieder um Rat fragen. Welcher Ansatz ist da vernünftig? Was verwenden andere OS, um dieses Problem zu lösen?

Grüße,
TheThing

4

OS-Design / Ebenen der Speicherverwaltung

« am: 14. July 2011, 01:58 »

So, ich arbeite ja mometan wieder an meinem Microkernel, der ja diesmal etwas mehr können soll als nur einen test-task auszuführen
Momentan hängt es noch ein wenig bei der Speicherverwaltung. So wie ich das sehe kann man die ja eigentlich in drei Ebenen unterteilen:
1. PMM: Er kümmert sich einfach nur um das zuteilen und freigeben von 4KB-Blöcken. Das setze ich momentan mit einer Bitmap um.
2. Paging: Kümmert sich im Prinzip nur um das Mapping. Bei mir bekommen sämtliche paging-Funktionen die Adresse des page-directories übergeben. Falls da irgendwo Platz gebraucht wird, wird mit Hilfe des PMM Speicher geholt. Außerdem besitzt mein Code eine Funktion um virtuelle in physikalische Adressen umzurechnen und mappt den Kernel in jeden Adressraum.
3. VMM: Ja, gute Frage. Keine Ahnung. Rein theoretisch könnte man ja einfach auf PMM und paging zurückgreifen: Man holt per PMM einen 4KB-Block, mappt ihn an eine freie Stelle in den Adressraum und gibt dann die Stelle im Adressraum zurück. Wäre vermutlich am einfachsten umzusetzen, aber ehrlich gesagt halte ich es für schlecht, wenn ich für jede Task-Struktur einfach mal 4KB verschwende.

Wie siehts also aus? Sollte ich mir einen vernünftigen VMM basteln? Welche Methode würdet ihr da empfehlen bzw. verwendet ihr?

5

Lowlevel-Coding / Daten in den Speicher eines Prozesses kopieren

« am: 04. June 2011, 19:27 »

Hi,
ich habe da ein kleines Problem.
Bei meinem Kernel funktionieren bereits Multitasking und alles was "davor" kommt, und gestern hab ich auch endlich den Bug beheben können, der das Paging vermurkst hat. Ich habe also momentan Paging mit einem page-directory für den Kernel und bin gerade dabei den einzelnen Prozessen auch ein page-directory zu verpassen und gleich auch ELF-Dateien zu verwenden.
Mein Problem ist jetzt folgendes:
Ich kann bereits dynamisch Speicher mappen usw., aber wenn ich ELF-Dateien parse muss ich ja die einzelnen Speicherbereiche, die im Programm-Header angeben sind, in den Adressraum des Prozesses kopieren (einfach nur mappen ist ja im Grunde nicht richtig, da auch die Bereiche auch im Speicher evtl. größer sein müssen usw.). Ein einfaches memcpy ist hier ja ungeeignet, da die Daten ja nicht nur an eine andere Adresse, sondern in einen ganz anderen Kontext müssen.

Meine Frage daher: Wie kann ich das einigermaßen gut lösen? Für jedes zu kopierende Byte die Adresse umzurechnen ist ja von der Performance her schon mal ganz schlecht.

Vielleicht stehe ich auch einfach nur auf dem Schlauch

6

Offtopic / Makefile-Problem

« am: 03. May 2011, 22:35 »

Hi,
nach (sehr) langer Zeit habe ich mich mal wieder meinem Kernel gewidmet (Source angesehen, Würgereiz unterdrückt und neu angefangen). Dabei möchte ich jetzt auch ein Linkerscript und ein Makefile einsetzen.
Das mit dem Linkerscript klappt, aber das Makefile macht mir noch Problem.
Ich erkläre vielleicht zuerst einmal, wie ich das überhaupt haben will:
Im Ordner meines Kernels liegen zuerst einmal das Linkerscript (kernel.ld) und das Makefile. Dann gibt es da noch einen Unterordner (src) in dem der ganze Code liegt.
Wenn ich nun make starte, soll er alle *.bas-Files aus dem src-Ordner kompilieren und das Obj-File im Hauptordner ablegen (evtl. später auch in einem Unterordner obj oder so) und dann alle Obj-Files mit dem Linkerscript linken.
Auf Basis von Teil 4 der Tutorial-Reihe und jeder Menge googlen hab ich mir jetzt ein Makefile zusammengebastelt, dass mich aber mit einem Fehler abspeist:

make: *** Keine Regel vorhanden, um das Target »video.o«,
  benötigt von »frost.krn«, zu erstellen.  Schluss.

video.o wäre das Obj-File von video.bas, welches sich um die Ausgabe auf dem Bildschirm kümmert.
Jetzt folgt mein Makefile:

Code: [Auswählen]

SRCS = $(shell find src -name *.bas)
OBJS = $(addsuffix .o,$(basename $(notdir $(SRCS))))

CC = fbc
LD = ld

CFLAGS = -c
LDFLAGS = -melf_i386 -Tkernel.ld

frost.krn: $(OBJS)
$(LD) $(LDFLAGS) -o $@ $^

%.o: %.bas
$(CC) $(CFLAGS) -o $@ $^

clean:
rm $(OBJS)
rm frost.krn

.PHONY: clean

Wie ihr vermutlich schon erraten habt, habe ich keine Ahnung, wo mein Fehler liegt
Ich hoffe mal, dass ihr mir erklären könnnt, was ich falsch gemacht habe.

7

Offtopic / Win32 Build von qemu 0.14.0

« am: 14. March 2011, 20:36 »

Hi,
ich hab mir mal die Mühe gemacht und die aktuelle qemu-Version kompiliert. SDL ist mit drin.
Momentan liegen zwei Versionen auf meinem Server. Die Version mit "stdio_redirect" hat die SDL-Option drinnen, die alle Konsolenausgaben in eine "stdout.txt" umleitet.
Momentan ist nur die x86_64 Version auf meinem Server, das "Komplettpaket" kommt noch sobald ich in der Schule Gelegenheit habe es hochzuladen, hier ist leider mein Internet zu langsam.
Hier der Link: http://darkinsanity.netii.net/qemu/
Bei Bedarf darf auch gerne im QEMU-Artikel im Wiki unter "Aktueller Windows-Build" auf diese Version verlinkt werden.

so long, TheThing

8

Offtopic / GRUB 2 iso

« am: 06. October 2010, 18:30 »

Ich versuche gerade, GRUB 2 auf eine iso zu bekommen. Das ganze gestaltet sich schwieriger als ich gedacht hätte

Zuerst habe ich es folgendermaßen gemacht:
Zuerst eine GRUB-ISO erstellt:

Code: [Auswählen]

grub-mkrescue --output=GRUB2.iso /boot/grubDann hab ich die ISO mit meinem USB-Stick zum Windows-Rechner getragen und per UltraISO die grub.cfg und meinen Kernel draufkopiert.

Der Nachteil daran ist:
1. Ich habe keine Ahnung, wie ich später den Kernel und die grub.cfg per Shellscript draufkriegen soll
2. Auf der ISO liegen 185 Dateien im Hauptverzeichnis

Mein zweiter Ansatz war folgender:

Code: [Auswählen]

grub-mkimage -p /boot -o core.img biosdisk iso9660 multiboot sh
cat /usr/lib/grub/i386-pc/cdboot.img core.img > eltorito.imgDann hab ich mir ein Verzeichnis namens "root" gemacht und dort die eltorito.img reingelegt. Dann noch einen Unterordner "boot", und dort den Kernel + grub.cfg rein. Dann hab ich mir die iso erstellt:

Code: [Auswählen]

mkisofs -b eltorito.img -no-emul-boot -boot-info-table -o grub2.iso rootObwohl die grub.cfg und der Kernel auch wirklich auf der iso drauf sind, funktioniert das Menü nicht, wenn ich die iso mit qemu teste. Unter VirtualBox sehe ich sogar gar keine Ausgabe. In qemu kann ich dann aber den Kernel testen, wenn ich "multiboot /BOOT/FROST.KRN" gefolgt von "boot" eingebe.
Zuerst einmal wundert es mich, dass alle Datei- und Ordnernamen auf einmal groß geschrieben sind, und ich frage mich, warum das Menü nicht funktioniert.
Der Vorteil dieser Methode wäre, ich könnte das ganz einfach in ein Shellscript packen, wenn es denn mal geht

So, ich hoffe dann mal, dass ihr mir helfen könnt, und danke schon einmal für alle Antworten

9

OS-Design / Interprozesskommunikation (mit CDI) aufbauen

« am: 24. October 2009, 21:18 »

Hi,
nach langer Zeit hab ich mich mal wieder um meinen Kernel gekümmert. Dem fehlt jetzt noch ein wichtiger Bestandteil: Interprozesskommunikation. Ist ja wichtig für einen Mikrokernel 

Mein Problem ist, das ich noch keine Ahnung hab wie ich so etwas sinnvoll realisiere. Ich hab mich mal ein wenig umgesehen und bin dabei im Wiki über CDI gestolpert, da es unabhängig vom Betriebssystem ist, dachte ich, das ich das verwende.

Könnt ihr mir erklären, wie ich eine Interprozesskommunikation (speziell mit CDI) aufbaue bzw. wie sie funktioniert?

Und ganz nebenbei: Wie krieg ich das hin das meine Tasks im Usermode laufen?

Grüße, TheThing

10

Offtopic / GRUB 2

« am: 02. October 2009, 12:40 »

Hi,
hab ne kurze Frage: Wie krieg ich GRUB 2 auf ne floppy, und was muss ich beachten damit ich GRUB 2 anstatt GRUB nutzen kann?

mfg

11

OS-Design / FreeBasic: Software Multitasking

« am: 14. May 2009, 18:27 »

@ehenkes: Hab deine Tuts gelesen. Baust du das mit dem Multitasking auch ein?

Weil, naja, also irgendwie verstehe ich das alles noch nicht.
Ich habe auch das Tutorial von James Molloy gelesen, aber ich habe da noch ein paar Fragen:
Wie funktioniert das genau, das er den richtigen Wert in eip hat?
Warum verlässt er die Routine mit "jmp *%%ecx" ? Müsste das nicht den Stack zerstören? Warum springt er nicht mir IRET zurück?
Wo sichert er die ganzen Register?
Warum überprüft er, ob in eip 0x12345 steht?

Bei meinem Kernel gibt es da auch noch ein Problem. Der Kernel läuft nach dem laden der Register des zweiten Tasks nicht mehr weiter. Falls jemand sich das mal anschauen will: http://rapidshare.com/files/232940400/FROST_V0.2.0a_unstable.zip
Sorry wenn ich dämliche Fehler gemacht habe, das ist mein erster Versuch. Ich hab noch kein TSS drin, da ich das ganze momentan sowieso nur innerhalb des Kernels teste.

Ehrlich gesagt hab ich so meine Probleme damit, fertigen Code zu verstehen. Und, naja, die OS-Projekte die ich mir bisher angesehen habe, sind nicht gerade ausführlich kommentiert. Kurz: Ich verstehe bei pedigree & co überhaupt nichts. Und das ganze ASM & C gemischte bringt mich dann komplett durcheinander.

Wenn Software-Multitasking bei meinem Kernel läuft, schreib ich ein Tutorial, mit dem jeder das zum laufen kriegt

12

OS-Design / Software Multitasking

« am: 19. March 2009, 12:15 »

Hi,
hab gestern versucht (Hardware-)Multitasking in meinen Kernel einzubauen, was in einem GPF geendet hat. Dann hab ich gelesen, das im Long-Mode Hardware-Multitasking sowieso nicht mehr geht.
Mein Problem ist, das ich KEINE Ahnung hab, wie man software-multitasking implementiert.
Software-Multitasking funktioniert (wenn ich das richtig verstanden habe) so:
Task1 wird von Timer unterbrochen
Kernel pusht Daten (Register usw.) auf den Stack von Task1
Kernel läd Stack von Task2
Kernel holt Daten vom Stack

So, wie springt jetzt aber der Kernel zurück zum Task?
Habt ihr da Tutorials, code oder so was für mich?

13

Lowlevel-Coding / Exception wird nicht abgefangen

« am: 29. January 2009, 12:33 »

Hi,
ich schreibe meinen Kernel in FreeBASIC. Jetzt bin ich an der Stelle, an der es sinnvoll wird interrupts nutzen zu können. Daher hab ich mir Routinen geschrieben, die eine IDT erstellen und laden. Testen wollte ich das ganze folgendermaßen:
Ich habe eine funktion als interrupt 0 in die IDT eingetragen, und der Kernel ruft danach (natürlich nachdem die IDT geladen wurde) int 0 auf. Er sollte dann eigentlich einen Text ausgeben, aber alles was er tut, ist abstürzen.
Ich hab mehrmals rumprobiert, aber ich krieg es einfach nicht hin. Ich bin kurz vorm verzweifeln.
Obwohl FreeBASIC eine ungewöhnliche Sprache für einen Kernel ist, hoffe ich das ihr mir helfen könnt.

Die letzte funktionierende Version meines Kernels gibt es auf http://frostkernel.sourceforge.net

Die Version, die Proleme macht, gibts hier (source+image): http://darkinsanity.freehoster.ch/FROST_debug.zip

Die Logfile von Bochs ist hier: http://darkinsanity.freehoster.ch/bochs.log

14

Offtopic / Aktivierungsmail

« am: 17. June 2008, 10:12 »

Hi, hatte Probleme mit der Aktivierungsmail. Bei GMX kommt die Mail nicht an, bei google schon. Sie landet bei GMX auch nicht im Spamfilter. Ich bin jetzt zwar registriert, wollte aber darauf hinweisen.

15

Offtopic / OS mit GRUB auf CD

« am: 17. June 2008, 10:05 »

Hi. wie man eine CD mit ISO-El-Torito Format macht, weiß ich aus dem Magazin. Aber wie macht man eine bootbare CD mit GRUB und einem OS ohne dabei eine Diskette zu simulieren?

Danke für die Antworten

16

Lowlevel-Coding / Kernel stürzt ab

« am: 17. June 2008, 10:01 »

Hi. ich hab mir einen kleinen Kernel geschrieben (hab noch so gut wie keine Ahnung von allem), der von GRUB gebootet werden soll und danach in den Protected Mode springt. Leider startet der PC, nachdem ich meinen Kernel ausgewählt habe, immer neu. Virtual PC meldet einen unbehebbaren Prozessorfehler. Bootloader ist GRUB 0.97. Hier mein Code:

Code: [Auswählen]



; --------------- MULTIBOOTHEADER FÜR GRUB ---------------
_mbh:
Multiboot_Magic equ 0x1BADB002
Multiboot_Flags equ 0x00010000
Multiboot_Checksum equ -Multiboot_Magic-Multiboot_Flags
Multiboot_HeaderOffset equ 0x00100000+_mbh

dd Multiboot_Magic
dd Multiboot_Flags
dd Multiboot_Checksum
dd Multiboot_HeaderOffset
dd 0x00100000
dd 0x00100000+_end
dd 0x00100000+_end
dd 0x00100000+_start


; --------------- KERNEL ---------------
_start:
; jetzt gehen wir in den Protected Mode
jmp afterdeskriptor      ; jetzt werden die drei wichtigen Deskriptoren erzeugt
NULL_Desc:
dd 0
dd 0
CODE_Desc:   ; ein Code-Deskriptor für den Kernel
dw 0xFFFF
dw 0
db 0
db 0x9A
db 0xCF
db 0
DATA_Desc:    ; und noch einen Data-Deskriptor für den Kernel
dw 0xFFFF
dw 0
db 0
db 0x92
db 0xCF
db 0
gdt:            ; Daten für die Global Deskriptor Table
Limit dw 0
Base dd 0
afterdeskriptor:   ; alle Deskriptoren erzeugt und übersprungen, also gehts hier weiter
; Protected Mode, wir kommen!
cli   ; keine Interrupts
mov eax, cs
mov ds, ax

; jetzt müssen wir den Deskriptor ändern, weil wir den Kernel nicht mit Code-Segment+16Bit-Adresse erreichen können
shl eax, 4
mov [CODE_Desc+2], ax
mov [DATA_Desc+2], ax
shr eax, 16
mov [CODE_Desc+4], al
mov [DATA_Desc+4], al
; Jetzt wird die GDT mit Daten gefüllt:
mov eax, cs
shl eax, 4
add eax, NULL_Desc
mov [Base], eax
mov [Limit], WORD gdt - NULL_Desc - 1
; GDT wird geladen
lgdt [gdt]
; Jetzt gehts in den Protected Mode
mov eax, cr0 ; cr0 in eax laden
or eax, 1    ; Das erste Bit auf 1 setzen
mov cr0, eax ; cr0 zurückschreiben
; jetzt noch den FAR JUMP, cs laden und Prefetch leeren
db 0xea
dw PMODE
dw 0x8

[bits 32]  ; Die 16-Bit vorbereitungen sind fertig, jetzt gehen wir auf 32 Bit
;%macro PM_Print 4   ; x, y, zeichen, attribut     ; unser Macro zum schreiben
; ;;;;;;;mov ax, %2*80+%1  ;offset errechnen
; mov ax, %2
; mov bx, 80
; mul bx
; add ax, %1
; add ax, 0xB8000
; mov bx, %3
; or bx, %4
; mov [ax], bx
;%endmacro

PMODE:          ; hierhin wird geJUMPt
mov WORD [CODE_Desc+2], 0    ; Deskriptoren wieder zurücksetzen
mov WORD [DATA_Desc+2], 0
mov WORD [CODE_Desc+4], 0
mov WORD [DATA_Desc+4], 0

mov eax, 2  ; Index 2 der GDT auswählen (also 3.  Eintrag)
shl eax, 3  ; Im Selektor beginnt der Index erst ab Bit 3
mov ds, ax
mov es, ax
mov ss, ax
mov eax, 0
mov fs, ax
mov gs, ax  ; FS und GS auf NULL Deskriptor zeigen lassen
mov gs, ax
mov esp, 0x1FFFFF  ; esp (stack) auf 2 MB setzen

; weil wir den Deskriptor verändert haben, müssen wir noch einmal FAR JUMPen, damit alles richtig geladen wird
jmp 0x8:0x10000 + main
main:         ; wir sind endlich im MAIN-Teil des Kernels angekommen! PARTY!!!
;PM_Print 40, 10, 72, 0x14
;jmp main
jmp main



_end:

achja: mein Makro für die Textausgabe funktioniert auch nicht. Der Code lässt sich dann nicht assemblieren. NASM meldet irgendwas mit invalid segmen/addres oder so. Weiß da jemand warum?