PrettyOS Fehler-/Testthread



  • PrettyOS Fehler-/Testthread

    Dieser Thread dient der Sammlung aller Fehler, die in PrettyOS gefunden werden und nicht im Tracker landen.

    PrettyOS Tracker:
    http://sourceforge.net/tracker/?group_id=282954

    Cuervo



  • Revision 85 geht bei mir nur auf einem einzigen Computer fehlerfrei, und zwar PC 2.
    PC 1 gibt einen GPF in der PCI-Liste aus und PC 3 startet neu (das ist der, der früher IMMER ging aber kaputt war und ich gestern wieder zusammengebaut habe).
    In qemu läuft es, in VirtualBox auch, MS VPC hab ich nicht. In VitualBox läuft es allerdings SEHR langsam... da kann man die roten Punkte mitzählen^^



  • anubis2k5 schrieb:

    Revision 86: bei Eingabe von HELLO.ELF wird -->.ELF<-- nicht gefunden.
    Bei Eingabe von "hello" hingegen funktioniert es - gewollt?! (Steht bereits auf der To-Do Liste, Nachtrag von Cuervo)

    Nachtrag: Besteht die Möglichkeit einen extra Threat zum Testen der Revisionen zu öffnen? Ich glaube hier wird's langsam voll... (Danke für den Hinweis)

    Nachtrag 2: Nachdem ich alle .bin;.map;*.elf - Dateien gelöscht habe, um ein "sauberes" System zu bekommen, musste ich feststellen, dass die Datei "HELLO.ELF" nicht gefunden wird. Wirklich aussagekräftige Fehlermeldung erhalte ich nicht. Habt ihr eine Idee?

    tools/CreateFloppyImage2 PrettyOS FloppyImage.bin stage1_bootloader/boot.bin sta
    ge2_bootloader/BOOT2.BIN kernel/KERNEL.BIN user/user_test_c/HELLO.ELF
    Cannot open the file 'user/user_test_c/HELLO.ELF'
    mingw32-make: *** [ckernel] Error -1
    

  • Mod

    HELLO.ELF unbedingt in Großschrift liefern.



  • Ist es so gedacht, dass sich die externen Dateien nur ohne die Eingabe der Endung aufrufen lassen? Bsp: hello - funktioniert; hello.elf funktioniert nicht?!


  • Mod

    Ist es so gedacht, dass sich die externen Dateien nur ohne die Eingabe der Endung aufrufen lassen? Bsp: hello - funktioniert; hello.elf funktioniert nicht?!

    Beides sollte funktionieren. Da ist was durch die Veränderungen durcheinander geraten. Gib bitte solange

    HELLO   .ELF
    

    ein, bis es wieder geht. 😉



  • OK...

    Nächste Meldung: Habe unter Bochs Probleme PrettyOS zum laufen zu bringen. Bochs kann scheinbar nicht vom Image booten - Pfadanpassung in der entsprechenden Config brachte leider keine Erfolge.

    Meldung:
    00020932447p[BIOS ] >>PANIC<< No bootable device.


  • Mod

    Ich verwende momentan bochs überhaupt nicht mehr, sondern nur noch qemu, weil es deutlich schneller ist.

    Ich habe es gerade mal wieder mit Bochs getestet, geht bestens vom Image:

    romimage: file=$BXSHARE/BIOS-bochs-latest 
    
    cpu: count=1, ips=10000000, reset_on_triple_fault=1
    
    megs: 1024
    
    vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest
    
    vga: extension=vbe
    
    floppya: 1_44=G:\OSDev\PrettyOS\trunk\Source\FloppyImage.bin, status=inserted
    
    ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
    ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15
    ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11
    ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9
    
    boot: floppy
    
    floppy_bootsig_check: disabled=0
    
    log: bochsout.txt
    
    panic: action=ask
    error: action=report
    info: action=report
    debug: action=ignore
    
    debugger_log: -
    
    parport1: enabled=1, file="parport.out"
    
    vga_update_interval: 300000
    
    keyboard_serial_delay: 250
    
    keyboard_paste_delay: 100000
    
    mouse: enabled=0
    
    private_colormap: enabled=0
    
    keyboard_mapping: enabled=0, map=
    
    i440fxsupport: enabled=0
    


  • So, ich meld mich hier auch mal...

    Mein Problem:
    Texteingabe funktioniert in user-programmen nicht. ich bekomme nicht die möglichkeit (weder selbstgeschriebene noch hello.elf) einen Text einzugeben; das Programm beendet sich in dem Moment, wo man etwas eingeben müsste. (Wenn man den Text ausgeben lässt, nachdem man getch() genutzt hat, wird der Text nicht angezeigt, andernfalls jedoch schon).

    EDIT: ich hätt wohl noch auf die Revision und die Umgebung eingehen sollen: Das Problem besteht mindestens seit Revision 86. 87 enthält es auch. Verwendetes System: Sun Virtual Box 3.1.2



  • Hast du irgendwo eine Test-File im Repository liegen?


  • Mod

    Bitte mal http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=88 testen (den Absturz des user-program habe ich hoffentlich verhindert, denn ab und zu läuft das einfach über exit hinaus! 😕


  • Mod

    http://www.c-plusplus.net/forum/viewtopic-var-p-is-1853944.html#1853944

    Rev. 89 hat das Problem nun endlich im Griff. Während gets wurde der Task gewechselt. Die shell hat dem User-Programm die Eingaben gestohlen.

    Was ist hier die beste Lösung?



  • Beste Lösung: Der Kernel verwaltet die Tastatureingaben und gibt sie an das aktuelle Programm weiter (das, das sichtbar (oder so) ist), oder an das, das gemeldet hat, dass es eine Eingabe will. Dann müsste die Shell solange "anhalten".

    Ausserdem kommen die Farben beim Multitasking durcheinander, also sollte jedes Programm seine Farbe merken und wieder aktivieren, wenn es dran ist...



  • Rev. 89 läuft bei mir Fehlerfrei. Auch das mehrfache ausführen von hello.elf funktioniert tatellos!



  • eigentlich funktioniert alles soweit, aber ich hab noch etwas (nicht so wichtig, eigentlich) gefunden: Die Sekunden seit dem Start laufen viel! zu schnell.



  • Noch ein (erheblich größeres) Problem.
    Es kommt mglw. durch das Multithreading.

    Die Konsolenausgabe läuft nicht geordnet. Das äußert sich wie folgt:
    Textfarbe ändert sich ohne zutun meinerseits mitten im user-programm und es werden Zeilen vertauscht. Dies tritt insbesondere nach Benutzereingabe auf.

    EDIT: hälfte vergessen 😉
    getch funktioniert garnicht; selbe problem wie gehabt (falls das eigentlich hätte behoben sein sollen)


  • Mod

    getch funktioniert garnicht; selbe problem wie gehabt

    Hast Du den Stack-Pointer auch gegenüber program.c verändert für das weitere Programm hello.c (oder test.c oder was auch immer)? Ist offenbar notwendig. Darüber müssen wir noch diskutieren.
    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  $
    


  • ich hab die neue start.asm verwendet...


  • Mod

    OK, dann wundert mich das schon etwas. Kannst Du genau ausführen oder testen, was nicht geht? Mit was testest Du (real, simulation)?



  • ich teste mit Virtual Box 3.1.2

    Hab übrigens da gleich mal virtualPC gestartet: Kann keine User-progs laden. Lesefehler von der Disk


Anmelden zum Antworten