4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • E
    Mod

    Fehler war in der pci_write_byte-Fkt.

    0
  • T

    Also bei mir wird richtig BIOS owned 0 und OS owned 1 angezeigt, der Host System Error bleibt allerdings.

    0
  • ?

    Revision 271

    Solange KERNEL und USER den gleichen "Videobereich" (0xB8000) für Ausgaben nutzen, sollte KERNEL nach erfolgreicher Ausführung von "elf_exec" auf eigene Ausgaben verzichten. Sonst gerät die Ausgabe vom USER u.U. völlig durcheinander:

    // file.c revision 271

int32_t flpydsk_load(const char* name, const char* ext)
{
(...)
    if( elf_exec( file, f.size ) ) // <- falls erfolgreich ...
    {
    }
(...)
// printf("\n\n");                 // <- ... sollte auf ausgaben ab hier verzichtet werden
 flpydsk_control_motor(false);     // <- hier drin dann auch
 sleepSeconds(3);
 return 0;
}

    (Betrifft aber nicht die Statuszeilen).

    Die Wirksamkeit des VirtualBox-Workaround kann ich nicht bestätigen. Bei mir hat VB ein Problem mit dem Host. Manchmal kann VB der gestarteten VM USB zur Verfügung stellen, manchmal aber auch nicht. Das hängt wahrscheinlich vom Wetter ab. Aber es liegt garantiert nicht am IRQ in der VM von VB. (Wäre ja erschreckend, wenn es so wäre).

    0
  • E
    Mod

    Danke für den Hinweis, wurde umgesetzt.

    VBox und Qemu (Version mit EHCI) laufen momentan am besten. Bei Bochs und VPC fehlen EHCI, und bei VMWare kommt leider nur 00h zurück im IN qTD anstelle 12h etc. Bei realer Hardware klappt es entweder gut oder erst nach einigen Anläufen. Bei Tobikings Laptop macht das BIOS Anstalten und gibt den Staffelstab nicht an den EHCI-Treiber ab, obwohl wir alles brav nach Lehrbuch (Intel PRM) durchführen.

    0
  • E
    Mod

    Solange KERNEL und USER den gleichen "Videobereich" (0xB8000) für Ausgaben nutzen

    Denkst Du man sollte hier einen umschaltbaren Bildschirm schaffen für verschiedene Tasks?

    0
  • M

    Du hast mich zwar nicht direkt gefragt, sag aber, wo Du es ansprichst, auch mal was dazu, ehenkes 😉

    Ich denke, wir brauchen langfristig mehrere Konsolen.
    Daher schlage ich vor: Eine Log-Konsole, wo alle Ausgabe außer der Statusleiste hinkommt.
    Plus n User-Konsolen, wo man Programme ausführen kann.

    Vlt. kann die Log-Konsole auch eine Steuerungskonsole sein, von der aus zusätzlich zur Log-Funktion Befehle ausgeführt werden, wobei Programme dabei in andere Konsolen umgeleitet werden, in die man dann umschalten kann.

    0
  • ?

    Hoffentlich habe ich etwas im Quelltext von PrettyOS übersehen (oder nur nicht verstanden). Dann diesen Beitrag einfach ignorieren. 🙂

    Revision 277

    KERNEL und USER nutzen für die Ausgabe putch() in der video.c. KERNEL "direkt" und USER via syscall.

    ⚠ Innerhalb von putch() ist es aber nicht möglich herauszufinden, wer putch() aufgerufen hat. ⚠

    Somit kann man auch nicht festlegen, ob putch() direkt in den Videospeicher schreiben soll oder vorerst in einen Puffer (Array).

    Sollte das korrekt sein, dann sind umschaltbare Bildschirme (und somit mehrere Konsolen) z.Zt. nicht realisierbar.

    0
  • M

    Ich wär dafür, das auch der Kernel nicht unkontrolliert seine Nachrichten absetzt, sondern das Kernel-Output in einer separaten Konsole abläuft.

    Ich werde mal an etwas entsprechendem arbeiten und das dann vorzeigen.

    0
  • ?

    Revision 281

    // FloppyImage.bin (Rootdir nach dem Schreiben)

00002660  48 45 4C 4C 4F|[u]20 20 20[/u]|45 4C 46 20 00 01 BA A2  HELLO   ELF ..º¢
00002670  1E 3B 5A 3B 00 00 3C 86 5A 3B 82 00 62 1C 00 00  .;Z;..<†Z;‚.b...
00002680  34 30|[u]00 00 00 00 00 00[/u]|54 58 54 20 00 00 00 00  40......TXT ....
00002690  00 00 00 00 00 00 00 00 00 00 91 00 04 10 00 00  ..........‘.....
000026A0  38 30|[u]00 00 00 00 00 00[/u]|54 58 54 20 00 00 00 00  80......TXT ....
000026B0  00 00 00 00 00 00 00 00 00 00 9A 00 04 10 00 00  ..........š.....

    Da fehlen noch die nachfolgenden Leerzeichen um auf "8" zu kommen. Seltsamerweise haben VMs damit keine Schwierigkeiten. 🙂

    0
  • F

    Seltsamerweise haben VMs damit keine Schwierigkeiten.

    Die VM hat damit gar nichts zu tun, nur der Code der die Daten liest!

    0
  • ?

    VMs reagieren unterschiedlich auf gleichen Code. Wenn bei PrettyOS irgendwas auf Anhieb nicht funktioniert, ist bei mir erstmal die/eine VM dran schuld. Danach erst eventuelle geringfügige Programmierfehler im Quellcode. 🙂

    Zum Thema:
    Eine VM mit MS-DOS als "Gast" (oder wie das sonst heißt) kann die "neuen" Dateien auf der FloppyImage.bin nicht lesen, da ... siehe oben.

    0
  • ?

    Revision 293

    Die Shell sieht nun aus wie eine bunte Kuh :). Aber sie ist nun um etliches besser als in vorherigen Revisionen.

    Sehr gute userfriendly Arbeit! 👍 Aber wie starte ich nun eine zweite (und dritte ...) Shell?

    0
  • M

    Danke für das Lob, +gjm+ 🙂

    Mehr Programme gehen bald (vmtl. rev 294). Derzeit gibts noch eine Blockade in der Shell, die das verhindert (Mit Absicht, sonst stören sich die Progs alle gegenseitig)

    EDIT: Seit Rev. 294 gehts.

    0
  • E
    Mod

    Erst ab Rev. 295 läuft das Multikonsolen-System von MrX sehr gut. Wir mussten die shell auf einen anderen Stackpointer setzen als die restlichen User-Programme. Das verstehen wir nicht wirklich. Hier das start.asm:

    ; start.asm

[BITS 32]
extern __bss_start
extern __end
extern _main
extern _exit
extern _test
global _start

_start:
    mov esp, 0x500000 ; stackpointer
    call _main	

	call _exit	
	call _test
	jmp  $

    Bei den User-Programmen nehmen wir 0x600000.

    Setzt man Shell und die anderen Programme auf 0x500000, dann erlebt man so etwas:

    Page Fault ( user-mode) at 00000000h - EIP: 00000000h err_code: 00000005h address(eip): 00000000h edi: 00000001h esi: 01401688h ebp: 000000C8h eax: 004FFFAFh ebx: 004FFFAFh ecx: 00000000h edx: 00000006h cs: 0000001Bh ds: 00000023h es: 00000023h fs: 00000023h gs 00000023h ss 00000023h int_no 14 eflags 00000246h useresp 004FFF90h

    Ich hoffe auf die geniale "Spürnase" +gjm+

    Jarvix (im IRC) meint, dass es am User-Stack liegt, den wir nicht richtig für jede User-App allokieren. Die Methode in start.asm sei falsch für viele Programme.

    0
  • ?

    Revision 295
    Es gibt tatsächlich ein Paging-Problem:

    ; user\user_tools\start.asm 295

_start:
; mov esp, 0x600000 ; stackpointer

  mov esp, 0x01402000 ; <- solange das problem nicht beseitigt ist

    Wenn der Stack der USER mit Adresse 0x600000 inititialisiert wird, benutzen sämtliche USER einen identischen Stack (und somit auch identische lokale Variablen (was heißt Adresse und Wert sämtlicher lokalen Variablen sind bei sämtlichen USERN identisch (sofern man ein Programm mehrmals startet). ( <- Hoffentlich kam das verständlich rüber 🙂 .).

    Irgendwie wird Adresse 0x600000 (und KERNELs 0x500000) nicht korrekt "gepaged".

    Wenn KERNEL (Shell) und alle USER die 0x01402000 benutzen, gibt es keine Probleme. Ein (dann neues) Problem gäbe es erst, wenn die Shell und/oder die Userprogramme > 0x2000 Bytes wären.

    0
  • E
    Mod

    Irgendwie wird Adresse 0x600000 (und KERNELs 0x500000) nicht korrekt "gepaged".

    Das passiert hier in paging.c, line 262, in paging_install:

    // Setup 0x00400000 to 0x00600000 as writeable userspace
    kernel_pd->codes[1] |= MEM_USER | MEM_WRITE;
    for (int i=0; i<512; ++i)
        kernel_pd->tables[1]->pages[i] |= MEM_USER | MEM_WRITE;

    wobei wir nicht 0x600000, sondern 0x5fffff nehmen sollten.

    Die shell ist übrigens ein User_Programm und wird auch genauso gestartet.

    0
  • X

    Erhard Henkes schrieb:

    wobei wir nicht 0x600000, sondern 0x5fffff nehmen sollten.

    Nein, da ein PUSH zuerst ESP um vier verringert und dann den Wert auf den Stack legt. Somit führt ESP==0x600000 dazu, dass das erste PUSH den Wert nach 0x5FFFFC legt (im Übrigen sollte man wohl besser keinen unalignten Stack benutzen, der Wert sollte IMO besser immer an vier ausgerichtet sein).

    0
  • E
    Mod

    @XanClic: ja, ist richtig. Sorry, da hat Jarvix mich irritiert. 😉

    @+gjm+: danke, wir nehmen nun 0x1420000 als gemeinsame virtuelle Stackadresse, allokieren aber für jedes User-Programm in create_task und nicht nur einmal in paging_install. Damit sind die physikalischen Speicheradressen wirklich verschieden.

    0
  • X

    Wie bereits im IRC gesagt, bekomme ich direkt nach dem Start einen Pagefault:

    PrettyOS schrieb:

    `<RAM Disk at C0005000h DIR> dev

    35 info

    13104 shell

    Page Fault ( read-only - write operation user-mode) at 004FFFFCh - EIP: 014013F5h

    err_code: 00000007h address(eip): 014013F5h

    edi: 00000000h esi: 00000000h ebp: 00000000h eax: 00000000h ebx: 00000000h ecx: 00000000h edx: 00000000h

    cs: 0000001Bh ds: 00000023h es: 00000023h fs: 00000023h gs 00000023h ss 00000023h

    int_no 14 eflags 00000202h useresp 00500000h

    Page Fault >>> Exception. System Halted! <<<`

    Offensichtlich wird da wohl versucht, was auf den Stack zu legen, das klappt aber nicht (warum auch immer, ob die Page jetzt wirklich Read-Only ist, wie es angezeigt wird, oder ob sie nicht für den Usermode ist) und das Programm verabschiedet sich mit einer Protection Violation.

    EDIT: OK, das Problem bestand darin, dass man offensichtlich erstmal make clean ausführen muss, was ich nicht getan habe. Jetzt läuft es. 🙂

    0
  • E
    Mod

    Lag offenbar daran, dass immer noch 0x500000 vorgegeben wurde durch alte Dateien, jetzt aber 0x1420000. Nach Update auch bei XanClic: "Na ja, es scheint zu funktionieren". 😉

    Bei mir läuft es aber auf real PC noch nicht, stürzt bei Eingabe in TTT ab.

    0
Anmelden zum Antworten