Nachrichten

41

OS-Design / Re: Paging - Segen oder Fluch?

« am: 12. January 2014, 17:34 »

Das heißt, ich mappen zuviel ich für den Kernel brauche (im Moment 4MB) & mappe die Programm AB der "1GB Grenze" nach oben, bis der Speicher voll ist?

An dieser Stelle auch die Frage, wenn ich einen alten Rechner mit weniger als 4GB benutzer, angenohmen 2GB, wann merke ich dann wenn der Speicher voll ist, bzw. voll belegt? 1GB fällt ja für den Kernel weg! Wenn ich jetzt über Paging noch 3GB zur Verfügung habe, aber nur noch 1GB vorhanden ist, wie löse ich das Problem?

Und natürlich der gute alte 486'er mit 128MB Speicher, wie soll ich da 1GB Kernel mappen + Programme? Eigentlich gar nicht möglich oder?

42

OS-Design / Qemu = ok, echt Hardware = Auaa... ;(

« 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?

43

OS-Design / Re: Paging - Segen oder Fluch?

« am: 12. January 2014, 17:10 »

Um das Thema mit dem Kernel, dass im Tutorial und Page angesprochen wird, dass der Kernel das 1. GB für sich reserviert, würde doch heißen das ich beim Init. Paging statt 4MB gleich 1GB mappen müssen!? Ist dies korrekt?

44

OS-Design / Re: Paging - Segen oder Fluch?

« am: 07. January 2014, 01:28 »

Das heißt also zusammengefasst:
- Paging aktiveren spi. die ersten 4MB mappen.
- Wenn ich jetzt einen Task laden passiert folgendes:
- Neues Page Directory anlegen
- Erstes (altes (4MB)) ins neue kopieren
- Alle Page Table kopieren
- Wie lade ich das neue nach c3, also wie mach ich das neue Page Directory zum aktuellen?
- TLB flushen? (Muss ich dasin ASM machen?)

45

OS-Design / Re: Paging - Segen oder Fluch?

« am: 06. January 2014, 16:31 »

Um den Kernel im Kontext des Prozesses zu mappen, könntest das Mapping, das du bereits hast (die ersten 4 MB) in neue Page Directory übertragen, indem du den ersten Eintrag aus deinem jetzigen Page Directory ins neue kopierst.

Das obere habe ich soweit verstanden. Danke dafür erstmal, aber kann ich den ein Mapping übertragen?
NACHTRAG: Wie mach ich einen für den Task neue Page Directory aktiv, denn ich dachte man kann nur einmal Mappen steht im Tut.?.

46

OS-Design / Re: Paging - Segen oder Fluch?

« am: 05. January 2014, 18:31 »

Ich versteh halt leider noch nicht ganz welcher Befhel hier was an dem Page Directory und an der Pagd Table macht.

47

OS-Design / Re: Paging - Segen oder Fluch?

« am: 05. January 2014, 18:29 »

Ok, dass verstehe ich soweit.

Wie muss ich aber jetzt das Paging erweitern um Programme zusammen mit dem Kernel zu mappen?
Wenn ich im Moment einen Task starte hol dieser sich anscheit ja einen 4KB großen freien Block von pmm_alloc (). Das ist ja jetzt phsy. Speicher, spr. Hat die selbe Adresse wieder der wie als würde ich direkt Zugreifen.

48

OS-Design / Re: Paging - Segen oder Fluch?

« am: 05. January 2014, 15:22 »

Ein vmm_create_context() erzeugt ein Page Directory und initialisiert es mit den Mapping, die sowieso überall sind. Ein vmm_alloc() sucht sich ein (oder mehrere) Speicherblöcke und mappt die als einzelnen, großen Block in ein Page Directory.

Welches Mapping ist sowieso überall und wieso?

Wie kann man mit vmm_alloc () einen großen Speicherblock in dem Page Directory benutzen wenn jeder eintrag nur 4MB groß ist?

Was ich jetzt verstanden habe, dass jeder der 1024 Einträge des Page Directory jeweils auf eine Page Table zeigt die ebenfalls 1024 Einträge hat. Aber wieviel Speicher jeder Eintrag verwaltet und wie ich dann womit auf den tasälichen Speicher lesen und schreiben kann weiß ich leider noch nicht.

49

OS-Design / Paging - Segen oder Fluch?

« am: 04. January 2014, 23:56 »

Hallo alle zusammen,

also mein größtes Problem liegt im Moment wieder am Thema Paging. Ich bin stark dem Tutorial nach gegang. Als das Thema Paging kam habe ich es immer wieder aufgeschoben, da ich es einfach nicht richtig verstehe. Ich habe also die ersten 4MB mit UserFlag gesetzt und es ruhen laßen.
Mittlerweile habe ich meinen KB-, RS232- Treiber fertig und meine SYSCALLS ausgebaut und arbeit mit Programme als Module. Es funktioniert mit einem laufendem Programm auch erstmal, mit mehren wird es problematisch.

Nun möchte ich meinen Floppy Treiber schreiben, dafür benötige ich DMA und ein funktionierendes Paging. Da ich aber mit den Ding gar net klar komme hier ein paar Verstädnisfrage sowie Fragen zum Code:

- Was genau ist ein Page Directory und was eine Page Table ?

- Vor lauter Poiter, was macht vmm_create_context () genau?

- Muss ich nach erstmaligen mappen den KernelBereich später wieder mappen?

- Was müsste vmm_allco () machen? Details?

- In die Struktur task füge ich context hin zu, führe ich nun auch nach interupt-wechsel context nach c3 (wie im Tut. Erklärt) bleibt der Kernel oder das Programm stehen. Es passiert einfach nichts mehr. Wieso?

- Hat jemand vll. ein Blockbild zum Paging um es sich besser vorstellen zu können?

- Braucht jeder Task sein eigenes Paging?

- Brauch ich wirklich Paping oder kann man die Speicherverwaltung auch einfach gestalten?

Ich hoffe ihr könnt mir in einigen Punkten weiterhelfen. Ich dreh sonst mit Paging durch, denn ich komm einfach nicht dazu jedem Task seinen eigenen Speicher zu geben.