PrettyOS Fehler-/Testthread


  • Mod

    Es liegt am Readcache. Der genaue Fehler muss noch gefunden und beseitigt werden.


  • Mod

    Vorbemerkung: Unerkannte Bugs sind ein echtes Problem, weil sie an unpassender Stelle zuschlagen können, vor allem in Kombination, und Verwirrung stiften.
    Bugs müssen zeitnah erkannt werden, da man so am besten reagieren kann. Daher wird hier ein systematischer Test vorgeschlagen.
    Dinge, die man ständig beim Ausführen von PrettyOS implizit testet, werden ausgelassen, z.B. Boot-Verhalten.

    Test für PrettyOS (sollte alle 10 commits durchgeführt und dokumentiert werden):
    ---------------------------------------------------------------------------------

    CPU:
    FPU-Test (should be implemented at ESC+f)

    Memory:
    recognized correctly? (should be implemented at ESC+m)

    Keyboard:
    Are AltGr keys recognized? Test known combinations of strg+key or ESC+key?

    Video/Monitor:
    Physical Address of grafics card?
    Which vbe modes are shown?
    Does vbe grafics work properly?

    Tasking/Scheduler:
    Start different programs in their own consoles. Check with strg+t.
    Change freqency at timer_install(100). Try 1000 Hz.

    Floppy Disk Device:
    Please test the sequence strg+s, fdir, strg+s, fdir.
    Load "arrow" two times.

    USB mass storage devices:
    Try FAT16 and FAT32 (and FAT12 if possible):
    Please test the sequence strg+u, strg+u, strg+u. Test the Directory and the content of screenshot (3 texts in "screen.txt").

    Networking:
    Describe environment. Test ARP reply, PING reply. All incoming packets recognized?

    User Library:
    Load program "test" (to be developed).

    Bitte um Mithilfe, diesen Test weiter auszuarbeiten.


  • Mod

    Neben der Optimierung des äußeren Testens (eigentlich Overhead) gilt es, folgende Strategie verstärkt zu beachten:

    1. Loggen/Visualisieren
    2. Internes Testen durch PrettyOS selbst
    3. Verstärkte Kommunikation bezüglich Änderungen bei Memory und Prozess Management (hier sind ausführliches Loggen und Tests bei mehreren Umgebungen unerlässlich, um Fehler möglichst früh zu detektieren und zu debuggen)

  • Mod

    problem im task management:

    0.0.1.223 - Rev: 807
    ...
    current task: pid: 6
    running tasks:
    pid: 5 esp: C020CEB0h eip: 001150DEh PD: 01021000h k_stack: C020D000h
    parent: 0
    pid: 0 esp: 0018FF00h eip: 00000000h PD: 01021000h k_stack: 00000000h
    child-threads: 5
    pid: 6 esp: C02055C0h eip: 001150DEh PD: 01021000h k_stack: C0205720h
    parent: 0
    blocked tasks:
    pid: 3 esp: C0002F70h eip: 001150DEh PD: C0208000h k_stack: C0003120h
    freetime task:
    pid: 1 esp: C0001054h eip: 001150DEh PD: 01021000h k_stack: C00010A8h

    pid0 hat 2 kinder, verleugnet aber eines davon


  • Mod

    http://www.c-plusplus.net/forum/viewtopic-var-p-is-1948598.html#1948598
    Der neue beschleunigte Lesevorgang bewirkt massive Kollateralschäden. strg+s zerschlägt z.B. so einiges. Um Analyse / Behebung wird gebeten, damit wir das beschleunigte Lesen beibehalten können.



  • Wir tappen bei dem Fehler bislang im dunkeln. Ich fasse mal hier kurz zusammen, was ich festgestellt habe (auch um selbst den Überblick zu behalten):

    Das bloße abstellen des neuen Cachings (z. 616 auskommentieren) bewirkt keine Besserung (aber natürlich eine Lese-Verlangsamung, weil für jeden Sektor der Track neu gelesen wird (trackweise!)).
    -> Am Caching liegt es nicht.

    Eine Umstellung auf sektorweises Lesen bewirkt keine Fehler bei strg+s.
    -> Es hat was mit dem trackweisen Lesen zu tun

    Leert man den DMA_BUFFER, bevor man schreibt (und schreibt anschließend das rein, was man schreiben will), verändert dies den Zustand des Floppyimages nach strg+s. Korrekt wäre, wenn sich nichts ändern würde am Verhalten.
    -> Es scheint, als würde fälschlicherweise ein ganzer Track (oder zumindest mehr aus dem DMA_BUFFER als nötig) geschrieben.


  • Mod

    Es scheint, als würde fälschlicherweise ein ganzer Track (oder zumindest mehr aus dem DMA_BUFFER als nötig) geschrieben.

    Hier liegt der Hebel. Das passiert auch, wenn man Zeile 616 auskommentiert und Zeilen 625 und 655 (anstelle 624 u. 654) verwendet!



  • Das Rätsel ist gelüftet.

    Erklärung: Die meisten Floppy-Treiber, die ich bislang gesehen habe (z.B. Tyndur und CDI), inklusive zahlreicher Seiten zum FDC (lowlevel-wiki, osdev.org) sind fehlerhaft. Wir merken es nur, weil unsere DMA-Implementation marode ist.

    Der Schlüssel ist Bit 7 des Kommandos an den FDC beim lesen/schreiben eines Sektors. lowlevel war (ist jetzt korrigiert) der Meinung, dort müsste die Anzahl der Sektoren pro Track stehen.
    Osdev.org behauptete, dort müsste die Anzahl der zu lesenden Sektoren stehen.
    Die Treiber, die ich auch zu Rate gezogen habe folgten dem lowlevel-Vorschlag.

    Nachdem ich auf einen Kommentar im CDI-Treiber gestoßen bin (der die richtige Info enthielt, sie aber nicht anwendete im Code) wurde mir das Problem klar. Kwolf/taljeth und ich haben in #lost dann darüber diskutiert, wer Recht hat und letztlich fanden wir auch in der offiziellen Spec den Hinweis, das dort der letzte zu bearbeitende Sektor stehen muss. Steht dort 18, wird bis zum letzten Sektor des Tracks gearbeitet (Also trackweise, wenn man von 1 an liest^^). (Beim lesen ists ja ohnehin egal, ob zuviel gelesen wird.)

    Bei uns wurde durch die falsche Angabe zuviel geschrieben, bei tyndur aber nicht. Das liegt am DMA-Treiber. Die zweite Begrenzung für die geschriebene Datenmenge ist die Datenmenge, die DMA dem FDC gibt. Das ist bei uns falsch eingestellt (immer Trackgröße), bei tyndur hingegen richtig (Sektorgröße, wenn nur ein Sektor gelesen/geschrieben wird)


  • Mod

    Hervorragende Leistung! Da bin ich mal auf die nächste Version gespannt, ob der Hexeditor endlich Entwarnung geben kann.

    Ja, hat geklappt! Echt klasse.


  • Mod

    Das track-weise Schreiben fehlt noch.

    Zunächst Analyse read/write bei strg+s (screenshot to floppy):

    Screenshot to Floppy (Thread)

    > sectorRead: 19 <<<<<
    > sectorRead: 19 <<<<<
    > sectorRead: 19 <<<<<
    > sectorRead: 19 <<<<<
    > sectorRead: 19 <<<<<
    > sectorWrite: 19 <<<<<
    > sectorRead: 1 <<<<<
    > sectorRead: 2 <<<<<
    > sectorRead: 3 <<<<<
    > sectorRead: 4 <<<<<
    > sectorWrite: 1251 <<<<<
    > sectorRead: 19 <<<<<
    > sectorWrite: 19 <<<<<
    > sectorRead: 19 <<<<<
    > sectorRead: 1251 <<<<<
    > sectorRead: 1251 <<<<<
    > sectorWrite: 1251 <<<<<
    > sectorWrite: 1252 <<<<<
    > sectorWrite: 1253 <<<<<
    > sectorWrite: 1254 <<<<<
    > sectorWrite: 1255 <<<<<
    > sectorWrite: 1256 <<<<<
    > sectorWrite: 1257 <<<<<
    > sectorWrite: 1258 <<<<<
    > sectorWrite: 1259 <<<<<
    > sectorWrite: 4 <<<<<
    > sectorWrite: 13 <<<<<
    > sectorRead: 19 <<<<<
    > sectorWrite: 19 <<<<<

    Zur Orientierung: http://henkessoft.de/OS_Dev/Bilder/FAT1_FAT2_Root.PNG

    Schaut man sich diesen Ablauf an, so erkennt man noch Optimierungspotenzial:
    - Warum wird sector 19 fünf Mal nacheinander gelesen?
    - Warum wird sector 1251 doppelt gelesen?

    Erforderliche Schreibvorgänge:
    3 nach root dir (Name, erster Cluster, Größe)
    9 nach data (4098 byte)
    1 nach FAT1
    1 nach FAT2

    Warum doppelt nach sector 1251 geschrieben wird, ist nicht klar.


  • Mod

    BL2-Problem beim Laden des Kernels bei PCs von MrX:

    <MrX>So, ich hab den Fehler bei mir sehr genau eingrenzen können.
    <MrX>Er gerät in eine Endlosschleife (.COPY_TO_DEST in ReadSectors (Fat12.inc)), und zwar bei dem ersten Leseaufruf der .LOAD_IMAGE-Schleife in LoadFile (Fat12.inc)
    <MrX>Herausgefunden durch Debugausgaben: Ein print direkt vor der Schleife erscheint, eines direkt danach nicht.

    Quelle: IRC://irc.euirc.net/#prettyos

    .SUCCESS:
        pop     bx
        mov     edi, ebx                            ; copy to destination buffer
        mov     cx, WORD [BytesPerSec]
        shr     cx, 1
        xor     si, si
        .COPY_TO_DEST:
            mov     ax, [es:si]
            mov     [fs:edi], ax
            add     si, 2
            add     edi, 2
            loop    .COPY_TO_DEST
    

  • Mod

    fformat geht nicht mehr.



  • Hast Recht, ich kümmer mich drum. (Fehler ist im floppytreiber)



  • Hab "Probleme" beim Kompilieren gefunden:

    nasm -Ox -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootloader/BOOT2.BIN
    gdt.inc:32: warning: signed byte value exceeds bounds
    

    Geht aber trotzdem weiter. Ist das bei euch auch so?

    TIA
    Cuervo

    EDIT:
    Nach Update von nasm 2.08 auf nasm 2.09.04 geht es wieder ohne Probleme..



  • So, hab heute mal PrettyOS in Parallels Desktop 6 getestet. Mag ja sein, dass es für graphische OS gedacht ist, aber ich dachte mir, ich könnte es ja mal versuchen. Es trat folgender Fehler auf:

    http://prettyos.fanofblitzbasic.de/mem.png
    Zur Erklärung: Eigentlich müsste statt "Continuing anyway..." dort "OS halted!" stehen, aber ich habe die Endlosschleife danach auskommentiert.
    (Maustreiber geht sogar^^)

    Kann mir jemand erklären, was da genau passiert?

    Das ist bisher das erste Mal, dass das passiert, kann man nicht einfach den Speicher an der Stelle vorher einmal leeren? Ich weiß, das ist nicht wichtig, aber wenn es doch mal woanders passiert?

    TIA
    Cuervo


  • Mod

    Gute Idee im Chat:
    <MrX>Wir brauchen ein Testprogramm
    <MrX>Ein Userprogramm (test.elf), dass verschiedene Dinge austestet.
    <ehenkes>Das ist eine hervorragende Idee
    <ehenkes>Dann sehen wir auch, wo wir noch User-Kernel-Barrieren haben

    (Doku hier, damit sie nicht verloren geht)


  • Mod

    <ehenkes><Pretty00001>1234567 sieben zeichen gehen
    <ehenkes>bei 12345678 (Eingabe) bleibt das User-Programm hängen.
    <ehenkes>Ich baue auf dich, denn für networking benötigen wir das funktionsfähig
    <ehenkes>ich verwende qemu 0.14.1, spielt das eine rolle?
    <MrX>ich denke nein.
    <ehenkes>hardwaretest notwendig?
    <ehenkes>ich teset einfach mal
    <MrX>Ich werde gets mal gezielt testen, wenn ich Zeit habe.
    <ehenkes>re
    <ehenkes>wenn man irc eingibt, wird hello.elf angezeigt, z.T. auch absturz beim laden
    <ehenkes>was Cuervo auch sagte
    <ehenkes>merkwürdiges verhalten bei der floppy
    <ehenkes>aber absturz nur ab und zu
    <ehenkes>zur Zeit komme ich über SYN_SENT nicht raus, der IRC server mag mich nicht mehr ^^
    <ehenkes>MrX: schau bitte auch mal nach dieser merkwürdigen anzeige der falschen datei beim von floppy laden
    <ehenkes>das war früher nicht
    <ehenkes>hab eben browser eingegeben, da lädt er rasend schnell
    <ehenkes>auch keine komischen anzeigen falscher files
    <ehenkes>bei starwars lädt er etwas klänger, aber auch sehr schnell, keine fehlanzeigen

    Stand bei rev. 1022

    Leider haben wir inzwischen einige kleine Schwächen im OS.
    Auch Abstürze, freezes.

    Nach Neuformatieren der Floppy und laden von irc.elf kommt kein hello.elf, dafür aber absturz. 🙄


  • Mod

    event_poll <--- fehler bezüglich task / task->parent (MrX behebt dies demnächst)



  • Habe heute starwars geöffnet,
    plötzlich, während des Vorspanns ist folgendes passiert:

    Über serielle Konsole wurde "invalid ack - drop!!!" ausgegeben (mehrfach) und starwars war stehengeblieben. Habe mit ESCape beendet und folgendes Bild war zu sehen:

    http://prettyos.fanofblitzbasic.de/net1.png


  • Mod

    Eine interessante Möglichkeit ist der stack backtrace bei einem Pagefault:
    http://www.henkessoft.de/OS_Dev/Bilder/PF_backtrace_stack.PNG
    Damit kann man die betroffene Funktion und den vorherigen Verlauf ausreichend genau lokalisieren. 🙂


Anmelden zum Antworten