Thema: Mit ein paar Zeilem mehr, streikt der Kernel

[rizor]

Morgen zusammen,

ich habe ein Problem mit meinem Kernel. Ich habe mir einen SLAB-Allocator geschrieben, der momentan Slabs fuer allozierbare Caches/Slabs/Objekte erstellt, damit selbst der SLAB-Aufbau moeglichst parallel stattfinden kann. Momentan berechne ich die Anzahl an Objekten, die ich benoetige, damit ich den Speicher moeglichst effektiv verwalten kann.
Meine Formel funktioniert soweit, verschwendet zum Teil nur 300 Byte. Um das zu verhindern, optimiere ich den Speicher danach noch von Hand. Leider spinnt der Kernel, sobald ich ihn mit diesen Optimierungen kompiliere. Woran kann das liegen?

Ohne die Optimierung:

Code: [Auswählen]

inline void __preboot_text slab_struct_count(size_t* objs, size_t* chunks,
size_t size, size_t alloc) {
size_t tmp;

tmp = alloc - sizeof(struct slab_cache);
tmp /= sizeof(struct slab_chunk) + (sizeof(struct slab_object) + size) *
CONFIG_OBJ_PER_CHUNK;

*chunks = tmp;
*objs = tmp * CONFIG_OBJ_PER_CHUNK;
}

Mit der Optimierung:

Code: [Auswählen]

inline void __preboot_text slab_struct_count(size_t* objs, size_t* chunks,
size_t size, size_t alloc) {
size_t tmp;
int diff;

tmp = alloc - sizeof(struct slab_cache);
tmp /= sizeof(struct slab_chunk) + (sizeof(struct slab_object) + size) *
CONFIG_OBJ_PER_CHUNK;

*chunks = tmp;
*objs = tmp * CONFIG_OBJ_PER_CHUNK;

diff = alloc - sizeof(struct slab_cache) - tmp * sizeof(struct slab_chunk) -
(tmp * CONFIG_OBJ_PER_CHUNK) * sizeof(struct slab_object);

//optimize the memory
if(diff - sizeof(struct slab_chunk) >= sizeof(struct slab_object) + size) {
diff -= sizeof(struct slab_chunk);
*chunks += 1;

while(diff >= (int)(sizeof(struct slab_object) + size)) {
diff -= sizeof(struct slab_object) + size;
*objs += 1;
}
}
}

Danke.

Gruss,
rizor

[kevin]

Benutzt du einen eigenen Bootloader? Dass mehr Code zu undefinierbarem Spinnen führt, hat immer mal wieder was damit zu tun, dass der Kernel schon kaputt im Speicher landet. Eine andere Möglichkeit wäre, dass du irgendwelchen Speicher überschreibst und bei einem kleinen Kernel nichts wichtiges trifft, aber bei einem größeren schon.

Oder ist es eine definierte Art von spinnen, d.h. liefert einfach nur dein Allocator Mist zurück? Wenn ja, was für eine Art von Mist?

[rizor]

Nee, ich verwende Grub.
An sich duerfte da nichts passieren.
Mein Boot-Code liegt an der 1MB-Grenze und der Rest (inkl. der Datenstrukturen) liegt an der 3 GB-Grenze. Den Speicher, auf dem ich schreibe, ist der garantiert freie Speicher unterhalb von einem MB (0x8000 -> 0x7ffff). Der Speicher reciht auch, da ich fuer diesen Speicher einen eigenen Manager habe, der den Speicher auch ordentlich verwaltet.
Das komische Verhalten zeigt sich dadurch, dass der GDB sagt, dass ich immer wieder der gleiche Befehl ausgefuehrt wird. Die Funktionen werden zum Teil auch falsch aufgerufen (falsche Parameter).

[rizor]

So, habe die Funktion mal ungeschrieben, da sie zum Teil falsche Ergebnisse geliefert hat und nun funktioniert der Code, sobald ich ihn in einem Image und mit Qemu -fda ... aufrufe.
Aber wenn ich meinen Kernel mit Qemu -kernel ... aufrufe, wird nicht eine meiner Funktionen (nicht mal _start) angesprungen. Was macht Qemu fuer Unterschiede zwischen -kernel und -fda?

[kevin]

Der Unterschied ist der Bootloader. Mit -fda hast du den GRUB vom Diskettenimage, mit -kernel eben qemu.

[rizor]

Also muesste es ein Bug in qemu sein, oder?
Oder was koennte an meinem Kernel falsch sein, dass qemu den Dienst verweigert und GRUB alles richtig macht?

[Svenska]

Vielleicht interpretieren GRUB und Qemu die Multibootspezifikation leicht unterschiedlich und dein Kernel verlässt sich auf ein Verhalten, was Qemu eben nicht hat...

[kevin]

Ohne den Kernel zu kennen, kann man da auch nicht viel dazu sagen. Ich brauch endlich mal einen Debugger mit gescheiter Kristallkugelunterstützung.

[rizor]

Das Problem ist, dass ich nicht genau weiss, wovon das abhaengt, da mein Kernel unter qemu nicht mal aufgerufen wird. Also kann ich auch nicht wirklich sagen wo es haengt

[kevin]

Du könntest beispielsweise deine Kernelbinary irgendwo hochladen, damit man sich das anschauen kann.

[erik.vikinger]

Hallo,


@rizor:
Sicher das Dein Kernel wirklich gar nicht angesprungen wird?
Ich könnte mir ja vorstellen das die unterschiedlichen Loader z.B. die GDT minimal unterschiedlich bauen und deswegen Dein Code beim ersten Speicherzugriff schon im Tripple-Fault landet o.ä., aber das Dein Kernel nichtmal angesprungen wird ohne das der Loader eine Fehlermeldung abgibt erscheint mir doch etwas suspekt.

Ich brauch endlich mal einen Debugger mit gescheiter Kristallkugelunterstützung.

Wenn Du dafür einen preiswerten Lieferanten auftreiben kannst und bereit bist eine Sammelbestellung zu organisieren dann möchte ich schon mal voranmelden das ich auch gerne ein oder zwei Stück hätte. Wichtig wäre mir nur noch die Unterstützung beliebiger CPU-Typen, x86 ist nicht so meine Zielrichtung!


Grüße
Erik

[rizor]

Wenn mein Kernel in einen Triple-Fault springen würde, dann würde Qemu ja aussteigen mit dem Letzten CPU-Dump, das tut es aber nicht.
Es Steht einfach die Meldung über das SeaBIOS da und sonst passiert nichts.
Wenn ich dem GDB sage, dass er den Code bei _start unterbrechen soll, kommt auch nichts.
Außerdem müsste das mit der GDT doch immer auffallen, oder?
Mein erster Code wird ja noch ganz normal im Lowmem-Bereich ausgeführt. Erst nachdem Paging aktiviert wurde, wird der Kernel im Highmem-Bereich ausgeführt.

@taljeth:
Falls das Problem nach meinen Änderungen immer noch besteht, werde ich es machen.

[Jidder]

Mein erster Code wird ja noch ganz normal im Lowmem-Bereich ausgeführt. Erst nachdem Paging aktiviert wurde, wird der Kernel im Highmem-Bereich ausgeführt.

Ich glaube Qemu kann sich an sowas verschlucken, wenn du das im Linkerskript mit AT implementiert hast. Der Multiboot-Loader interpretiert wimre nicht die Felder für die physische Adresse.

[rizor]

Was ist denn AT?

[Jidder]

Wenn du das nicht weißt, hast du vermutlich das Problem nicht.

Mit AT gibt man im Linkerskript die Ladeadresse für eine Sektion an. Damit kann man den Kernel in den hohen Speicherbereich mappen, aber trotzdem mit GRUB an eine niedrige Adresse laden. In vielen Tutorials wird der Kernel ja an die Adresse 0x100000 gelinkt, und muss von GRUB auch dahingeladen werden. Wenn man AT einsetzt, wird GRUB ihn weiterhin an diese Adresse laden, aber gelinkt wird der Kernel an eine andere Adresse (z.B. 0xC0000000).

Ein Beispiel, das das mit einer GDT kombiniert, um von Anfang an unmodifizierte C-Funktionen benutzen zu können, ist hier: http://wiki.osdev.org/Higher_Half_With_GDT

[rizor]

Wenn ich dich richtig verstanden habe, wird der Code gegen 0xc0000000 gelinkt, aber an 0x100000 geladen, oder?
Das mache ich auch so. Wusste nur nicht, dass man das AT nennt.

[Jidder]

Ja, das meine ich.

Das mit dem AT hab ich nicht gut erklärt. Das ist einfach nur das Schlüsselwort dafür, kein Begriff für das Prinzip. Siehe auch http://sourceware.org/binutils/docs-2.17/ld/Output-Section-LMA.html#Output-Section-LMA

[rizor]

Aber wieso klappt das manchmal und dann wieder nicht?
Ich habe den Code mal ein wenig umgeschrieben und nun funktioniert es einwandfrei.