Nachrichten

1

OS-Design / Re: CPU-Zeit-Verteilung und insbesondere Leerlauf

« am: 24. February 2013, 23:26 »

Ich glaub ihr habt recht. ^^

Solange meine Tasks nichts anderes machen als Sinnlose Textausgaben, brauche ich meinen scheduler nicht optimieren. Da kann ich mich erstmal um wichtigere Dinge kümmern.^^

Ich habe btw gerade gemerkt, dass der scheduler bei mir gar nicht den CPU Stand in der jeweiligen Struktur speichert, sondern einfach so den nächsten Task lädt. Trotzdem hatte ich nie Probleme damit, auch Tasks die erst A ausgeben, dann solange warten, sodass sie unterbrochen werden müssen und dann B ausgeben funktionieren. Mysteriös...

2

OS-Design / Re: CPU-Zeit-Verteilung und insbesondere Leerlauf

« am: 19. February 2013, 19:45 »

Jetzt wo es schon so einen schönen Thread gibt, hätte ich auch noch 2 Fragen zum Thema scheduling.

1. Was ist momentan der optimale Intervall zwischen den Taskswitches? Ich weiß nähmlich nicht wie lange moderne CPUs für einen Taskswitch brauchen (also bei einem einfachen scheduler und ohne swapping oder so).

2. Gibt es eine gute Methode um die Performance zu messen? Es bringt ja nicht, wenn ich am scheduling alogrithmus rumspiele ohne zu wissen ob sich die performance verbessert oder verschlechter.

3

OS-Design / Re: RTC mit QEMU

« am: 19. February 2013, 17:36 »

Ich merke gerade das ich meinen Post vor einem Monat nicht richtig abgeschickt habe.

Die Antwort hat mir sehr geholfen, jetzt stimmen alle Daten. Vielen Dank.

4

OS-Design / Re: CPU-Zeit-Verteilung und insbesondere Leerlauf

« am: 19. February 2013, 17:32 »

Ich denke schon. Das ist einfach ein Pseudoprozess mit einer so niedrigen Priorität, damit er nur dann läuft, wenn kein anderer Prozess gerade bereit ist.
Man braucht ihn halt, damit das Multitasking komplett zum Stillstand kommt wenn alle "echten" Prozesse geblockt sind oder beendet wurden.

Korrigiert mich wenn ich falsch liege.

5

OS-Design / RTC mit QEMU

« am: 20. January 2013, 10:58 »

Tag Leute,

ich bin gerade dabei eine date()-Funktion, wie man das aus PHP kennt zu implementieren. Dabei ist mir aufgefallen, dass das Datum bei QEMU total falsch ist (zB haben wir laut QEMU das Jahr 2019). Außerdem werden die Sekunden bis 100 gezählt anstatt 60.
Ansonsten funktioniert das ganze eigentlich richtig, die Sekunden steigen auch im Sekundentakt usw.
Ich habe die QEMU Version 1.1.2 Ist das ein Bug oder gibt es da Einstellungsmöglichkeiten?

Grüße,
jo

6

OS-Design / Re: Keine Interrupts im Ring 3

« am: 03. January 2013, 14:12 »

Nochetwas:

Im Tutorial Teil 8 steht ganz am Ende

Code: [Auswählen]

  ...
    } else {
        /*
         * Wenn wir mindestens ein Multiboot-Modul haben, kopieren wir das
         * erste davon nach 2 MB und erstellen dann einen neuen Task dafuer.
         */
        struct multiboot_module* modules = mb_info->mbs_mods_addr;
        init_elf((void*) modules[0].mod_start);
    }
So wird allerdings nur ein Modul geladen, damit das "Experiment" im Teil 9 funktioniert muss es ne Schleife geben, die modules[0] bis modules[mb_info->mods_count-1] initialisiert.

7

OS-Design / Re: Keine Interrupts im Ring 3

« am: 03. January 2013, 13:55 »

Yay es funktioniert.

Danke.

8

OS-Design / Re: Keine Interrupts im Ring 3

« am: 03. January 2013, 12:16 »

Vielen Dank.

Das wird es sein. Ich habe nähmlich nirgendswo das Ring3 Flag angegeben.

/e: An welcher Stelle steht eigentlich das Flag?
/e2: Im Wiki steht es ja^^^(bits 45-46).
/e3: Ich habe für die ganzen Flags 0x8E angegeben (10001110). Da müsste doch eigentlich das Ring3 Flag gesetzt sein oder? 

9

OS-Design / Re: Keine Interrupts im Ring 3

« am: 02. January 2013, 22:42 »

An der TSS sollte das eigentlich nicht liegen. Denn nach dem GPR wird ganz normal der Fehlerscreen ausgegeben und die CPU eingefroren und das dürfte doch im Ring 3 nicht funktionieren. Und wenn die TSS kaputt wäre dann würde die CPU doch nicht zurück in Ring0 kommen, oder hab ich das falsch verstanden? 

10

OS-Design / Re: Keine Interrupts im Ring 3

« am: 02. January 2013, 22:34 »

Ich habe ungefähr das selbe Problem. Wenn ich in den (Ring 3) - Tasks Syscalls oder andere Interrupts aufrufe, wird ein GPR ausgelößt. Allerdings gibt es bei mir keinen TSS-Fault, im Interrupt-log kommt erst der Syscall und direkt danach der GPR.

Code: [Auswählen]

    42: v=30 e=0000 i=1 cpl=3 IP=001b:00200010 pc=00200010 SP=0023:00008ff8 EAX=00000000
EAX=00000000 EBX=00000030 ECX=00000000 EDX=00000030
ESI=00000000 EDI=00000000 EBP=00008ffc ESP=00008ff8
EIP=00200010 EFL=00000202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
CS =001b 00000000 ffffffff 00cffa00 DPL=3 CS32 [-R-]
SS =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00102120 00000080 0000e900 DPL=3 TSS32-avl
GDT=     00106040 0000002f
IDT=     00126080 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=00007fec CCO=EFLAGS 
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
    43: v=0d e=0182 i=0 cpl=3 IP=001b:00200010 pc=00200010 SP=0023:00008ff8 EAX=00000000
EAX=00000000 EBX=00000030 ECX=00000000 EDX=00000030
ESI=00000000 EDI=00000000 EBP=00008ffc ESP=00008ff8
EIP=00200010 EFL=00000202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
CS =001b 00000000 ffffffff 00cffa00 DPL=3 CS32 [-R-]
SS =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
DS =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0028 00102120 00000080 0000e900 DPL=3 TSS32-avl
GDT=     00106040 0000002f
IDT=     00126080 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=00007fec CCO=EFLAGS 
EFER=0000000000000000
Mit -d in_asm werde ich auch nicht schlauer, nach dem Syscall wird eben direkt 0xD an den Interrupt-Handler übergeben.

Vielleicht weiß irgendwer wie man da weiterkommt. 

11

Offtopic / Re: Weihnachten!

« am: 24. December 2012, 21:35 »

Frohe Weihnachten.

12

Lowlevel-Coding / Re: Integer fehlerhaft?!

« am: 15. December 2012, 02:15 »

Es lag tatsächlich am itoa, wie ich gedacht hatte.

Vorher habe ich erst noch irgendwelche temporären Buffer benutzt um den String umzukehren. Jetzt wird es einfach direkt falschrum in den Buffer geschrieben.

Jetzt funktioniert auch endlich die PMM richtig. Danke für den Tipp. 

13

Lowlevel-Coding / Re: Integer fehlerhaft?!

« am: 14. December 2012, 23:23 »

Die funktionieren auch. Wie stellst du denn fest, dass das Ergebnis nicht korrekt ist?

Es können natürlich noch mehr/andere Probleme als nur im Ausgabecode bestehen. Zum Beispiel, dass lokale Variablen von fehlerhaftem Code überschrieben werden. (Buffer Overflow)

Wenn ich ein solche Variable irgendwo mit multipliziere und das Ergebnis ausgebe, kommt 0 raus. Das mit dem Buffer Overflow könnte natürlich sein. Ich habe da auch schon einen Verdacht wo der auftritt.

14

Lowlevel-Coding / Re: Integer fehlerhaft?!

« am: 14. December 2012, 22:13 »

Ja, das ist ein verbreiteter Fehler. Es ist allerdings ein Fehler in deinem Code. Vermutlich stimmt etwas mit deinen Ausgabefunktionen nicht.

Aber dann würden doch zumindest die Rechenoperationen funktionieren, oder irre ich mich?

15

Lowlevel-Coding / Integer fehlerhaft?!

« am: 14. December 2012, 21:16 »

Mir ist gerade aufgefallen, dass irgendwie hin und wieder Integer kaputt sind. Kaputt bedeutet, dass man mit ihnen nicht rechnen kann (als Ergebnis kommt 0 heraus). Wenn man ich den Integer ausgebe, wird die Zahl mit einem angehängten Ç (kein C). Das ist zumindest meistens der Fall. Manchmal sind es auch andere Zeichen dessen Existenz ich nichtmal kannte^^. Interessanterweise kann man den Fehler manchmal beheben, indem man vor der Ausgabe einen anderen Integer deklariert.
Ich frage mich vorallem wie diese Zeichen in die Ausgabe kommen. Eigentlich sollte es bei %x nur 1-F geben...

Vielleicht ist das ja ein verbreiterter Fehler in der Lowlevelprogrammierung. Ich hoffe das mir da wer weiterhelfen kann.

16

Offtopic / Re: Entwickungsumgebungen

« am: 09. December 2012, 21:17 »

KDevelope. 

17

OS-Design / Re: Multiboot Information Structure

« am: 29. November 2012, 14:22 »

Aha 

Ich habe mir qemu jetzt aus der backports-repository geholt und es funktioniert einwandfrei. 

Vielen Dank für eure Tipps

18

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 21:59 »

Laut Paketverwaltung habe ich ja schon die neuste Version 

19

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 21:46 »

Hmm der Befehl update akzeptiert keine Argumente.

20

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 21:25 »

Hallo,

mein Qemu ("QEMU emulator version 1.1.2 (Debian 1.1.2+dfsg-2), Copyright (c) 2003-2008 Fabrice Bellard") zeigt auch brav 0x4F an und versaut die Umlaute. Also dürfte dein Qemu kaputt sein.

"qemu -version" ist das Stichwort. Vermutlich musst du mal dein Qemu (oder deine Linux-Distribution) aktualisieren.

Gruß,
Svenska

Es scheint so.

Code: [Auswählen]

QEMU PC emulator version 0.12.5 (Debian 0.12.5+dfsg-3squeeze2), Copyright (c) 2003-2008 Fabrice Bellard
Wie genau kann ich denn qemu aktualisieren? In der Paketverwaltung steht, dass ich die aktuelle Version habe. Ich habe übrigens Debian.