Themen

1

Lyrisches Eck / Die GUI

« am: 04. October 2010, 22:31 »

So, da hier so lange niemand mehr was (vor allem Lyrik) geschrieben hat und mich gerade die Lust zu dichten in Ermangelung anderer Lüste (ich meine OS-Dev) übermannt hat, hab ich hier mal was im vierhebigen Trochäus (reimlos, wechselnd männliche und weibliche Verse) erdacht:

Vor dem Rechner saß ich heute,
Wusste nicht, was ich nun tu.
Mein Versuch, mehr Code zu schreiben,
Wird sofort im Keim erstickt.

Muse, ach weh!, komm und küss mich,
Da mir jeder Antrieb fehlt.
Alles scheint kaputt und langsam,
Nichts will wirklich wie es soll.

Doch! Da fällt mir ein, es gibt doch
Noch etwas, was oft verpönt,
Aber vielleicht jetzt grad richtig…
Eine GUI! Das ist es.

Hopps und her mit PPP,
Neuer Ordner, und hinein.
Makefile, die ist schnell erstellt und
Schon kanns losgehn, vim ist offen.

Doch wie mach ich das jetzt richtig?
Erstmal VBE, und dann?
Schalten wir den Modus um und
Leeren voerst nur den Schirm.

Fenster, eines, nur als Anfang!
Und schon bin ich mittendrin,
Linien, Flächen, Texte, Kreise,
Ich kann nur die ersten zwei.

Aber das muss reichen, voerst,
Und da ist ein Fenster, ha!
Darauf habe ich gewartet,
Lohn der Mühen, du bist da.

Und was kann man damit machen?
Nur ein Fenster, toll, und nun?
Brauchen wir den ersten Teil des
Tollen Wortes „Klickibunt“.

Ein Maustreiber! Ha, welch Unsinn,
Ich hätt wirklich nie gedacht,
Dass ich so ein Zeug mal brauche,
Doch auch der ist schnell gemacht.

Und schon wieder kommt die Frage:
Wofür hab ich jetzt den Dreck?
Ganz nett wär vielleicht mal etwas,
Womit ich die Shell dann seh.

Wofür hab ich da den Zeiger?
Ach, vergiss es, mach ich jetzt
Erstmal mit dem Zeichnen weiter.
Ja, ich hass es wie die Pest.

Wenn man eine Datei öffnet,
Gleich ein Fenster auch erscheint,
Zeichnen kann man drauf, ganz klar,
Wenn man die Datei beschreibt.
(Das ist Paloxenalogik)

Und was sag ich? Hui, es geht ja!
Aber, hm, da fehlt doch was…
Ach, verdammt, ja, eine Schriftart, hm,
Das wär jetzt noch wirklich toll.

Woher nehmen, wenn nicht stehlen?
Schücksi, ja, der hat da was:
Eine Schriftart, fünf mal zehn, yay,
Die sieht doch schon fast perfekt aus.

Noch ein paar an Sonderzeichen,
Und dann noch Eszett, in groß,
Schon ist es vollbracht, sehr schön,
Fertig, die Konsolenschrift.

Hm? Ein Link von Chiken in #niwohlos…
„Schreiben Sie hier Text und ich
Sage Ihnen dann, nach wem er klingt.“
Das ist aber lustig, hm…

Wieso schreib ich kein Gedicht, es
Gibt doch eine Ecke, da,
Ja, im Forum, da schreibt sonst doch
Niemand etwas, das wärs jetzt.

Doch, was könnte ich denn dichten?
Was zu meinem letzten Tag?
Das klingt gut, da schreib ich drüber,
Um zu sehen, wie ich schreib.

Wie mir FAZ.net berichtet, klingt das wohl nach Schiller.

(Begriffserklärung: PPP ist das Paketsystem bei Paloxena, wie lbuilds bei týndur)

2

Lowlevel-Coding / Z80 – H-Flag

« am: 01. April 2010, 00:01 »

Hallo,

derzeit beschäftige ich mich etwas mit dem Programmieren (bzw. dem Emulieren, um genau zu sein) eines Z80-Prozessors. Dieser hat ja ein Halfcarryflag, hier wäre jetzt meine Frage, was genau mit dem bei einer Subtraktion geschieht: Ein PDF-Dokument, das ich hier habe, sagt, dass es bei „No borrow from bit 4“ gesetzt wird, eine andere Quelle aus dem Internet besagt genau das Gegenteil. Beim x86-Prozessor ist es so, dass das Auxiliarycarryflag bei Borrow gesetzt wird.

Wie gesagt: Wird das Halfcarryflag gesetzt, wenn ein Borgen vom Bit 4 geschieht, oder dann eben nicht? Dies würde natürlich auch das Carryflag betreffen (ob es beim Borgen vom imaginären Bit 8 gesetzt wird).


In der Hoffnung, dass es hier einen Z80-Experten gibt,

Clici McXan

3

Lowlevel-Coding / 64kB-Problem [gelöst]

« am: 20. April 2009, 20:35 »

Hallo,

Tja, mein Kernel nähert sich so langsam der 64kB-Marke (ist eben ein Monolith) und da tauchen die Probleme auf. Ich habe keine Ahnung, woran es liegen kann, mein Bootloader kann zweifellos über RealMode-Segmentgrenzen hinaus laden und das Restsystem läuft im ProtectedMode mit Paging, sollte also keine Probleme mehr mit diesen 64kB haben.

Also, die Probleme sind:
- Globale Variablen, die initialisiert werden (z. B.: "char *ConsoleBase = (char *)0x800B8000)") sind im Programm uninitialisiert.
- Unter QEMU gibt es einen TripleFault, wenn ich eine Zeile Code zusätzlich schreibe oder eine zusätzliche Variable einfüge (wo auch immer), entferne ich diese wieder, ist alles in Ordnung. Übrigens geht dem TripleFault ein Pagefault voraus, laut dem der Stack nicht gemappt sei.
- Gestartete Programme beenden sich zuerst mit einem Pagefault, starte ich sie später mit den gleichen Parametern noch einmal, ist alles in Ordnung.

Aber das wohl merkwürdigste ist, dass der Kernel noch gar nicht 64kB groß ist. Er hat bloß eine Größe von jetzt genau 62700 Bytes...
Bis jetzt habe ich ihn einfach dadurch klein gehalten, dass ich die Alignflags im Linkerscript entfernt (bzw. auf 1 gesetzt) habe, doch jetzt ist das alles ausgereizt.

Ich dachte, dass es an einem RealMode-Stack liegen könnte, der in den Kernel hineinwächst (der Kernel wird nach 0x10000 geladen, es hätte ja einen Stack bei 0x1000:0xFFFF geben können), doch dem ist nicht so (mein ProtectedMode-Stack liegt übrigens bei 0x4FFFFF). Der Bootloader überschreibt auch keine Daten des Kernels oder so.

Bis jetzt habe ich versucht, dieses Problem einfach - so gut es ging - zu ignorieren, doch das wird nun immer schwerer (neue Treiber sind unmöglich geworden). Ich hoffe, jemand von euch hat eine Ahnung, woran das ganze liegen könnte.



P. S.: Bitte sagt mir jetzt nicht, dass das ein guter Zeitpunkt zum Umsteigen auf einen Microkernel wäre...

4

Lowlevel-Coding / GPF... [gelöst]

« am: 11. March 2009, 22:12 »

Schönen guten Abend,

Nachdem ich nun endlich auf C und Paging umgestiegen bin, habe ich es auch geschafft, Multitasking mit CPL0-Prozessen zu implementieren. Beim Umstieg auf CPL3 habe ich aber noch (mindestens) ein Problem: Wenn ich über einen Syscall Speicher anfordere, dann wird die entsprechende Adresse auch korrekt zurückgegeben, beim Versuch des CPL3-Prozesses, darauf zuzugreifen, enden aber sämtliche "normalen" Computer und BOCHS mit einem GPF, bei QEMU und VirtualBox funktioniert jedoch alles.
Der zurückgegebene Speicher ist korrekt gemappt (der Kernel kann ohne Probleme darauf zugreifen) und eigentlich sollte er auch von Userprozessen verwendet werden können - das Ausführen des Codes funktioniert schließlich und der ist ebenso gemappt.
Am TLB kann es auch nicht liegen, da "invlpg" nach der Allokation ausgeführt wird (ich habe es auch mit Neuschreiben von CR3 versucht).

Falls es wichtig sein sollte: Die IDT besteht aus 256 Elementen, alle sind zumindest auf einen einfachen iret-Handler umgeleitet, der Sysint ist 0x80. Die GDT enthält 6 Elemente (Null-Handler, Systemcode (Von 0 bis 4 GB, DPL=0), Systemdaten (ebenso), Benutzercode (Von 0 bis 2 GB, DPL=3), Benutzerdaten (ebenso) und TSS (nur esp0 und ss0 gesetzt)). Der Kernel ist nach 0x80000000 (bzw. 0x80010000) gemappt.

Daten, die mein BlueScreen(tm) liefert:
ErrorCode = 0
CS:EIP = 0x1B:0x0000094C ("for (i = 0; tmem; i++)" - tmem ist der allokierte Speicher (Typ (char*))
SS:ESP = 0x23:0x000FFD28
(kernel: SS:ESP = 0x10:0x81239FE8)
DS, ES, FS, GS = 0x23
TR = 0x28
GDT ab 0x81000000
IDT ab 0x80017200


Ich hoffe, irgendjemand hat eine Ahnung, woran es liegen könnte...

P. S.: Wenn ich Code posten soll, kein Problem. Es könnte nur ein bisschen unübersichtlich sein (und ich benutze bei Inlineassembler die Intelsyntax (bei GCC)).

5

Lowlevel-Coding / Merkwürdiges LGDT-Problem [Gelöst]

« am: 08. August 2007, 12:20 »

Hallo,
Ich habe ein (meiner Meinung nach) sehr merkwürdiges Problem mit LGDT. Mein Kernel wird im RealMode an die Adresse 0x1000:0x0000 geladen (dazu benutze ich den FAT12-Bootloader von John Fine). Dann wechsele ich in den 800x600x32-VESA-Modus und versuche, den ProtectedMode zu aktivieren. Aber in dem Moment, in dem die GDT geladen wird, hängt sich mein Computer auf. Dasselbe passiert bei Bochs. Allerdings funktioniert alles bei anderen VMs wie VirtualBox, QEMU, VMware oder VirtualPC (Bei VMware funktioniert bloß der VESA-Modus nicht, das ist aber eine andere Geschichte... ).

Hier der Anfang meiner kernel.asm:

Code: [Auswählen]

use16

;Segmentregister updaten
mov   ax,cs
mov   ds,ax
mov   es,ax

;A20 aktivieren
.5:
in    al,0x64
test  al,2
jnz   .5
mov   al,0xD1
out   0x64,al
.6:
in    al,0x64
and   ax,2
jnz   .6
mov   al,0xDF
out   0x60,al

;VESA-Support überprüfen
mov   ax,0x4F00
mov   di,VBEInfoBlock - 0x10000
int 0x10

;Überprüfung des Rückgabewertes in AL
cmp   al,0x4F
je    ctrl_else0_1
mov   si,vbe_chosen_func_not_supported
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while1_1:
or    al,al
je    ctrl_wend1_1
lodsb
or    al,al
je    ctrl_else2_1
stosb
mov   al,7
stosb
ctrl_else2_1:
ctrl_endif2_1:
jmp   ctrl_while1_1
ctrl_wend1_1:
jmp   no_vesa
ctrl_else0_1:
ctrl_endif0_1:

;select ah, Überprüfung, ob der Aufruf geklappt hat

;case 1: Leider nicht.
case1_0:
cmp   ah,1
jne   case1_1
mov   si,vbe_func_call_error
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while2_1:
or    al,al
je    ctrl_wend2_1
lodsb
or    al,al
je    ctrl_else3_1
stosb
mov   al,7
stosb
ctrl_else3_1:
ctrl_endif3_1:
jmp   ctrl_while2_1
ctrl_wend2_1:
jmp   no_vesa
jmp   endselect1

;case 2: Die Funktion wird von der Hardware nicht unterstützt
case1_1:
cmp   ah,2
jne   case1_2
mov   si,vbe_chosen_func_not_supported_by_hw
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while2_2:
or    al,al
je    ctrl_wend2_2
lodsb
or    al,al
je    ctrl_else3_2
stosb
mov   al,7
stosb
ctrl_else3_2:
ctrl_endif3_2:
jmp   ctrl_while2_2
ctrl_wend2_2:
jmp   no_vesa
jmp   endselect1

;case 3: Die Funktion darf hier gar nicht aufgerufen werden
case1_2:
cmp   ah,3
jne   case1_3
mov   si,vbe_func_mustnt_be_called
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while2_3:
or    al,al
je    ctrl_wend2_3
lodsb
or    al,al
je    ctrl_else3_3
stosb
mov   al,7
stosb
ctrl_else3_3:
ctrl_endif3_3:
jmp   ctrl_while2_3
ctrl_wend2_3:
jmp   no_vesa
case1_3:
endselect1:

;Jetzt wird die Signatur überprüft. Ist sie jetzt ungleich "VESA", dann liegt
;ein Fehler vor.
mov   si,VbeSignature - 0x10000
lodsd
cmp   eax,0x41534556
je    ctrl_else0_2
mov   di,answer
stosd
mov   si,func_not_supported
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while1_2:
or    al,al
je    ctrl_wend1_2
lodsb
or    al,al
je    ctrl_else2_2
stosb
mov   al,7
stosb
ctrl_else2_2:
ctrl_endif2_2:
jmp   ctrl_while1_2
ctrl_wend1_2:
jmp   no_vesa
ctrl_else0_2:
ctrl_endif0_2:

;Informationen über den Modus 0x115 (800x600x32) abfragen
mov   ax,0x4F01
mov   di,VbeModeInfoBlock - 0x10000
mov   cx,0x115
int 0x10

;Überprüfung des Rückgabewertes in AL
cmp   al,0x4F
je    ctrl_else0_3
mov   si,vbe_chosen_func_not_supported
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while1_3:
or    al,al
je    ctrl_wend1_3
lodsb
or    al,al
je    ctrl_else2_3
stosb
mov   al,7
stosb
ctrl_else2_3:
ctrl_endif2_3:
jmp   ctrl_while1_3
ctrl_wend1_3:
jmp   no_vesa
ctrl_else0_3:
ctrl_endif0_3:

;select ah, Überprüfung, ob der Aufruf geklappt hat

;case 1: Leider nicht.
case2_0:
cmp   ah,1
jne   case2_1
mov   si,vbe_func_call_error
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while2_4:
or    al,al
je    ctrl_wend2_4
lodsb
or    al,al
je    ctrl_else3_4
stosb
mov   al,7
stosb
ctrl_else3_4:
ctrl_endif3_4:
jmp   ctrl_while2_4
ctrl_wend2_4:
jmp   no_vesa
jmp   endselect2

;case 2: Die Funktion wird von der Hardware nicht unterstützt
case2_1:
cmp   ah,2
jne   case2_2
mov   si,vbe_chosen_func_not_supported_by_hw
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while2_5:
or    al,al
je    ctrl_wend2_5
lodsb
or    al,al
je    ctrl_else3_5
stosb
mov   al,7
stosb
ctrl_else3_5:
ctrl_endif3_5:
jmp   ctrl_while2_5
ctrl_wend2_5:
jmp   no_vesa
jmp   endselect2

;case 3: Die Funktion darf hier gar nicht aufgerufen werden
case2_2:
cmp   ah,3
jne   case2_3
mov   si,vbe_func_mustnt_be_called
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while2_6:
or    al,al
je    ctrl_wend2_6
lodsb
or    al,al
je    ctrl_else3_6
stosb
mov   al,7
stosb
ctrl_else3_6:
ctrl_endif3_6:
jmp   ctrl_while2_6
ctrl_wend2_6:
jmp   no_vesa
case2_3:
endselect2:

;VESA und der 800x600x32-Modus werden unterstützt
mov   si,vesa_supported
mov   ax,0xB000
mov   es,ax
mov   di,0x8000
mov   al,1
ctrl_while0_1:
or    al,al
je    ctrl_wend0_1
lodsb
or    al,al
je    ctrl_else1_1
stosb
mov   al,7
stosb
ctrl_else1_1:
ctrl_endif1_1:
jmp   ctrl_while0_1
ctrl_wend0_1:

;Hier wird der 800x600x32-Modus mit Linearem Framebuffer aktiviert
mov   ax,0x4F02
mov   bx,0x4115
int 0x10

;Teile dem PM-Code mit, dass VESA aktiviert wurde
mov   [IsVESA - 0x10000],1

no_vesa:

;In den PM wechseln

;Interrupts deaktivieren
cli

;Fülle die Segmentregister mit 0 (ansonsten würden Sie nicht auf den
;Dummy-Descriptor verweisen und somit würde ein GPF auftreten)
xor   ax,ax
mov   ds,ax
mov   es,ax
mov   ss,ax
mov   fs,ax
mov   gs,ax
xor   esp,esp

;Versuche, die GDT zu laden
lgdt [gdt_desc]
;Dieser Punkt hier wird nicht mehr erreicht, das Programm ist eingefroren.

;Wäre das nicht so, würde hier der PM aktiviert
mov   eax,cr0
or    eax,1
mov   cr0,eax

;Leere die Pipeline und springe in den 32-bit-Modus
jmp   far 0x28:pmode
;Der gewählte Descriptor besitzt die folgenden Eigenschaften:
;Basis ist 0x10000
;Größe ist 0xFFFEF * 4KB
;Er beschreibt ein lesbares Codesegment mit DPL = 0
;80386+

use32

pmode:

;Fülle die Segmentregister mit den richtigen Werten:
mov   ax,0x10
mov   ds,ax
mov   es,ax
mov   ss,ax
;Der gewählte Descriptor besitzt die folgenden Eigenschaften:
;Basis ist 0x0000
;Größe ist 0xFFFFF * 4KB
;Er beschreibt ein beschreibbares Datensegment mit DPL = 0
;80386+

xor   ax,ax
mov   fs,ax
mov   gs,ax

mov   esp,0x1FFFFF

jmp   far 0x08:start
;Der gewählte Descriptor besitzt die folgenden Eigenschaften:
;Basis ist 0x0000
;Größe ist 0xFFFFF * 4KB
;Er beschreibt ein lesbares Codesegment mit DPL = 0
;80386+

func_not_supported db "VESA functions aren't supported., answer is "
answer db 0,0,0,0,0
vbe_chosen_func_not_supported db "The chosen VBE function isn't supported.",0
vbe_chosen_func_not_supported_by_hw db "The chosen VBE function isn't supported by hardware.",0
vesa_supported db "VESA 800x600x32 is supported.",0
vbe_func_call_error db "The function call wasn't successful.",0
vbe_func_mustnt_be_called db "The function mustn't be called.",0
vbe_invalid_video_mode db "Invalid video mode.",0

org 0x10000+$

;Hier die GDT
gdt_start:
gdt_entry_dummy: ;Index 0 [selector = 0x00]
dd 0, 0
gdt_entry_sys_code: ;Index 1 [selector = 0x08]
dw 0xFFFF
dw 0x0000
db 0x00
db 10011010b
db 11001111b
db 0x00
;Code executable/readable, DPL = 0, Base = 0x00000000, Size = 0xFFFFF * 4KB, 80386

gdt_entry_sys_data: ;Index 2 [selector = 0x10]
dw 0xFFFF
dw 0x0000
db 0x00
db 10010010b
db 11001111b
db 0x00
;Data readable/writeable, DPL = 0, Base = 0x00000000, Size = 0xFFFFF * 4KB, 80386

gdt_entry_sys_video: ;Index 3 [selector = 0x18]
dw 0xFA00
dw 0x0000
db 0x0A
db 10110010b
db 01000000b
db 0x00
;Data readable/writeable, DPL = 1, Base = 0x000A0000, Size = 0xFA00 * 1B, 80386
;This descriptor was used for VGA mode 0x13

gdt_entry_sys_text: ;Index 4 [selector = 0x20]
dw 0x8000
dw 0x8000
db 0x0B
db 10010010b
db 01000000b
db 0x00
;Data readable/writeable, DPL = 0, Base = 0x000B8000, Size = 0x8000 * 1B, 80386

gdt_entry_sys_scode: ;Index 5 [selector = 0x28]
dw 0xFFEF
dw 0x0000
db 0x01
db 10011010b
db 11001111b
db 0x00
;Code executable/readable, DPL = 0, Base = 0x00010000, Size = 0xFFFEF * 4KB, 80386

gdt_entry_sys_sdata: ;Index 6 [selector = 0x30]
dw 0x1000
dw 0x0000
db 0x01
db 10010010b
db 11000000b
db 0x10
;Data readable/writeable, DPL = 0, Base = 0x00010000, Size = 0xFFFEF * 4KB, 80386

gdt_end:

gdt_desc:
dw gdt_end - gdt_start - 1
dd gdt_start
dw 0 ;Ich weiß nicht, wozu das gut sein soll, nur, dass es manchmal
     ;verwendet wird...

VBEInfoBlock:
VbeSignature db "VBE2"
VbeVersion dw 0
VbeOEMStringPtr dd 0
VbeCapabilities dd 0
VbeVideoModePtr dd 0
VbeTotalMemory dw 0
VbeOEMSoftwareRev dw 0
VbeOEMVendorNamePtr dd 0
VbeOEMProductNamePtr dd 0
VbeOEMProductRevPtr dd 0
VbeReserver  db 222 DUP(0)
VbeOEMData  db 256 DUP(0)

VbeModeInfoBlock:
VbeModeModeAttributes dw 0
VbeModeWinAAttributes db 0
VbeModeWinBAttributes db 0
VbeModeWinGranularity dw 0
VbeModeWinSize dw 0
VbeModeWinASegment dw 0
VbeModeWinBSegment dw 0
VbeModeWinFuncPtr dd 0
VbeModeBytesPerScanLine dw 0
VbeModeXResolution dw 0
VbeModeYResolution dw 0
VbeModeXCharSize db 0
VbeModeYCharSize db 0
VbeModeNumberOfPlanes db 0
VbeModeBitsPerPixel db 0
VbeModeNumberOfBanks db 0
VbeModeMemoryModel db 0
VbeModeBankSize db 0
VbeModeNumOfImagePages db 0
VbeModeReserved_page db 0
VbeModeRedMaskSize db 0
VbeModeRedMaskPos db 0
VbeModeGreenMaskSize db 0
VbeModeGreenMaskPos db 0
VbeModeBlueMaskSize db 0
VbeModeBlueMaskPos db 0
VbeModeReservedMaskSize db 0
VbeModeReservedMaskPos db 0
VbeModeDirColorModeInfo db 0
VbeModePhysBasePtr dd 0
VbeModeOffScreenMemOffs dd 0
VbeModeOffScreenMemSize dw 0
VbeModeLinByPerScanLine dw 0
VbeModeBnkNumberOfPages db 0
VbeModeLinNumberOfPages db 0
VbeModeLinRedMaskSize db 0
VbeModeLinRedFieldPos db 0
VbeModeLinGreenMaskSize db 0
VbeModeLinGreenFieldPos db 0
VbeModeLinBlueMaskSize db 0
VbeModeLinBlueFieldPos db 0
VbeModeLinRsvdMaskSize db 0
VbeModeLinRsvdFieldPos db 0
VbeModeMaxPixelClock dd 0
VbeModeReserved  db 190 DUP(0)

IsVESA db 0

start:

;Und hier folgt dann der Rest des Systems
Die Debug-Ausgabe von Bochs:

Code: [Auswählen]

00000450000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000695508e[HD   ] device set to 0 which does not exist
00000695801e[HD   ] device set to 1 which does not exist
00000802818i[CLVGA] VBE set bpp (24)
00000802840i[CLVGA] VBE set xres (800)
00000802921i[CLVGA] VBE set yres (600)
00000802959i[CLVGA] VBE enabling x 800, y 600, bpp 24, 1440000 bytes visible
00000802959i[WGUI ] dimension update x=800 y=600 fontheight=0 fontwidth=0 bpp=24
00003303000p[WGUI ] >>PANIC<< POWER button turned off.
00003303000i[SYS  ] Last time is 1186562163
00003303000i[CPU0 ] real mode
00003303000i[CPU0 ] CS.d_b = 16 bit
00003303000i[CPU0 ] SS.d_b = 16 bit
00003303000i[CPU0 ] | EAX=41530000  EBX=00004115  ECX=000a0115  EDX=00000000
00003303000i[CPU0 ] | ESP=00000000  EBP=00007c00  ESI=0000029c  EDI=0000803a
00003303000i[CPU0 ] | IOPL=0 NV UP DI PL ZR NA PE NC
00003303000i[CPU0 ] | SEG selector     base    limit G D
00003303000i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00003303000i[CPU0 ] |  CS:1000( 0000| 0|  0) 00010000 0000ffff 0 0
00003303000i[CPU0 ] |  DS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00003303000i[CPU0 ] |  SS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00003303000i[CPU0 ] |  ES:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00003303000i[CPU0 ] |  FS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00003303000i[CPU0 ] |  GS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00003303000i[CPU0 ] | EIP=000001bb (000001bb)
00003303000i[CPU0 ] | CR0=0x00000010 CR1=0 CR2=0x00000000
00003303000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00003303000i[     ] restoring default signal behavior
00003303000i[CTRL ] quit_sim called with exit code 1
Hier kann man sehen, dass der Kernel zwar VESA aktivieren kann, sich dann aber aufhängt bis man auf den Power-Knopf drückt. Der EIP ist 0x01BB und genau dort befindet sich der lgdt-Befehl.
Kann mir jemand helfen?

Vielen Dank schon mal im Voraus!