PrettyOS Fehler-/Testthread


  • 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. 🙂


  • Mod

    Cuervo meldet im chat folgende notwendige Korrekturen/Ergänzungen an:

    1. EVENT_TCP_CLOSED sollte sofort ausgelöst werden, wenn die Verbindung ESTABLISHED verlässt, nicht erst, wenn sie gelöscht wird (<--- erledigt)
    2. Wir brauchen EVENT_TCP_CONNECTION_FAILED (<--- timeout bitte im user-prg)
    3. fopen() soll keine Ausgaben erzeugen (<--- erledigt)
    4. Es ist definitiv ein Fehler im Floppytreiber (error 34 und seek error)
    5. Fehler in PCI ? (häufiger durchlauf der for-schleife in function)



  • Fehler im Floppytreiber auf real PCs:

    Wenn man, ausserhalb des bootloaders, von Diskette lesen will, tauchen folgende Meldungen auf (Beispiel mit fdir, gleiches Verhalten beim Laden von Programmen):

    Bild: http://prettyos.fanofblitzbasic.de/flp2.jpg

    Vergrößerung: http://prettyos.fanofblitzbasic.de/flp1.jpg



  • Fehler des Tages:
    Unsere pow-Implementation gibt falsche Werte für negative Exponenten zurück.



  • Warum der Fehler auftritt, ist zwar nicht geklärt, aber es lässt sich mit diesem Workaround beheben:

    if(exponent < 0.0)
            return 1.0 / (isOdd * pow2x(yMulLog(base,-exponent)));
        else
            return isOdd * pow2x(yMulLog(base,exponent));
    

Anmelden zum Antworten