Autor Thema: Qemu stürzt ab bei Multitasking  (Gelesen 14431 mal)

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« am: 24. December 2012, 03:13 »
Qemu stürtzt ab bei Multitaskingpflash_write: Unimplemented flash cmd sequence (offset 000000000001fffc, wcycle 0x0 cmd 0x0 value 0xf000e2c3)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001fff8, wcycle 0x0 cmd 0x0 value 0xf000ff53)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001fff4, wcycle 0x0 cmd 0x0 value 0xf000ff53)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001fff0, wcycle 0x0 cmd 0x0 value 0xfffffff4)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffec, wcycle 0x0 cmd 0x0 value 0x1007ac)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffe8, wcycle 0x0 cmd 0x0 value 0xf000ff53)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffd0, wcycle 0x0 cmd 0x0 value 0x103074)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001ffcc, wcycle 0x0 cmd 0x0 value 0x101048)
PFLASH: Possible BUG - Write block confirm
« Letzte Änderung: 30. December 2012, 19:58 von Martin Erhardt »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 24. December 2012, 03:15 »
Oh, sowas hab ich noch nie gesehen. Kannst du das komplette qemu.log posten?
Dieser Text wird unter jedem Beitrag angezeigt.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 24. December 2012, 03:24 »
Klar ich post auch noch den Quellcode auf soner FileHostingPlattform. aber wo ist noch mal qemu.log.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 24. December 2012, 03:28 »
Achso das ist gar nicht aus dem log. Dann würde ich doch erstmal fragen, wo diese Meldungen aufgetaucht sind. In der Konsole, in der du Qemu gestartet hast?

Die qemu.log ist entweder in /tmp (Linux) oder im aktuellen Verzeichnis (Windows). Ruf mal qemu mit dem Parametern -d int auf. Das sorgt dafür, das die aufgetretenen Interrupts in das log geschrieben werden.
Dieser Text wird unter jedem Beitrag angezeigt.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 24. December 2012, 03:33 »
Ja also im Terminal kam das, ist irgendwie auch bisschen seltsam, dass Qemu abstürtzt. An der GDT kanns nicht liegen z.zT ist alles KernelMode
SMM: enter
EAX=00000001 EBX=17fe1f30 ECX=02000000 EDX=00000cfc
ESI=000f28dd EDI=0003802d EBP=17fe1d50 ESP=00006eb0
EIP=000f2c4a EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     000fd3a8 00000037
IDT=     000fd3e6 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=000f28b0 CCD=00000001 CCO=LOGICB 
EFER=0000000000000000
SMM: after RSM
EAX=00000001 EBX=17fe1f30 ECX=02000000 EDX=00000cfc
ESI=000f28dd EDI=0003802d EBP=17fe1d50 ESP=00006eb0
EIP=000f2c4a EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     000fd3a8 00000037
IDT=     000fd3e6 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=EFLAGS 
EFER=0000000000000000
     0: v=20 e=0000 i=0 cpl=0 IP=0008:0000000000100466 pc=0000000000100466 SP=0010:000000000010600c EAX=0000000000103f84
EAX=00103f84 EBX=00036d04 ECX=00000000 EDX=00108050
ESI=0005d980 EDI=0005d976 EBP=00067e5c ESP=0010600c
EIP=00100466 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00126960 00000027
IDT=     00126160 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00105fc8 CCO=EFLAGS 
EFER=0000000000000000
check_exception old: 0xffffffff new 0xd
     1: v=0d e=c894 i=0 cpl=0 IP=0008:0000000000100868 pc=0000000000100868 SP=0010:0000000000000024 EAX=00000000f000ff53
EAX=f000ff53 EBX=f000ff53 ECX=f000e2c3 EDX=f000ff53
ESI=f000ff53 EDI=f000ff53 EBP=f000ff53 ESP=00000024
EIP=00100868 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00126960 00000027
IDT=     00126160 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000008 CCD=00000024 CCO=ADDL   
EFER=0000000000000000

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 24. December 2012, 03:36 »
Das einzige verdächtige an dem Log ist, dass EAX = f000ff53. Das heißt, dass ein NULL-Pointer derefenziert wurde. Du solltest deinen Multitasking-Code am besten mal mit Checks auf NULL-Pointer spicken oder manuell den Code durchgehen. Irgendwo wird da ein ungültiger Zeiger geladen.

Edit: Genauer gesagt: Vermutlich wird der Stackpointer auf einen Wert gleich 0 oder nahe 0 gesetzt.
« Letzte Änderung: 24. December 2012, 03:44 von Jidder »
Dieser Text wird unter jedem Beitrag angezeigt.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 24. December 2012, 03:49 »
Ja also Ich schau in den naächsten Tagen noch mal drüber. Ich seh grad nix aber ich post mal meinen Quelltext:
http://uploadingit.com/file/4lsfedzw2blyzvvu/el_toro_repo.zip

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 24. December 2012, 04:03 »
Eine Spekulation auf die Schnelle wäre, dass das Problem verursacht wird, weil du Interrupts aktivierst, bevor das Multitasking eingerichtet ist. In der Zwischenzeit kann nämlich ein Timer-Interrupt auftreten. Du kannst diese Theorie testen, indem du Interrupts erst aktivierst (sti), nachdem die Tasks erstellt wurden. Deine schedule-Funktion testet nur beim Speichern des Zustands, ob ein Task läuft. Aber wenn kein Task existiert, wird trotzdem current_task um 1 erhöht. Meine erste Idee wäre aus dieser einfach return cpu; auszuführen, wenn current_task == -1.
Dieser Text wird unter jedem Beitrag angezeigt.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 24. December 2012, 04:08 »
Ja also das habe ich miteinkalkuliert. Dazu gibt es nämlich den boolean mtenabled der auf True gesetzt wird beim ersten init_task . Der Scheduler wird nur ausgeführt wenn mtenabled = true.Ok ist wahrscheinlich viel zu kompliziert aber der Grund für den Fehler kann das nicht sein.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 24. December 2012, 04:14 »
Ich hab mir noch nicht den kompletten Quelltext anschauen können, aber ich glaube handle_irq ruft direkt schedule anstatt timer_handler (welches mtenabled prüft) auf, und damit wäre der Mechanismus nicht aktiv.

edit: letzter post für heute. gn8  :mrgreen:
Dieser Text wird unter jedem Beitrag angezeigt.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 24. December 2012, 04:29 »
Achso *push the head against the wall* :-o
das hab ich ja als Notlösung geändert weil sich anders gar NICHTS getan hat. Da hab ich dann den Fehler bekommen und gedacht näher dran zu sein. Den Check hat ich da schon vergessen.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 24. December 2012, 04:38 »
Idee Ich habe den Stack als Lokale Variable definiert. Das heißt aber der wird wieder gepopt was schlecht ist.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 28. December 2012, 22:18 »
das kanns nicht gewesen sein :x
es passiert weiter nichts obwohl multitasking eigentlich eingeschaltet ist .
Wenn ihr wegen der Geschichte "keinen bock habt mir zu helfen"- no problem, falls doch:

http://uploadingit.com/file/hxhu7n8o1d3whcvx/el_toro_repo.zip
« Letzte Änderung: 28. December 2012, 22:27 von Martin Erhardt »

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 28. December 2012, 23:37 »
Stack als lokale Variable? Du meinst, du legst den Stack auf den Stack?

Rekursion, die: siehe Rekursion.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 28. December 2012, 23:47 »
Mein Compiler beschwert sich in deiner sc2kc.c darüber, dass du " statt ' bei den Buchstaben verwendest. Das solltest du korrigieren.

Außerdem funktionieren deine kprintf-Funktionen nicht richtig. Wenn eine Funktion, die "..." in der Parameterliste hat, muss diese die Parameter als va_list weitergeben. Die Signatur deiner kprintfstrcol-Funktion sollte so aussehen: int kprintfstrcol(atrbyt font, const char* fmt, va_list ap);. Das Makro CALL_VA_FUNC sollte so aussehen
#define CALL_VA_FUNC(func,param,param1) \
        va_start(ap,param1);\
        func(param,param1,ap);\
        va_end(ap);
Da hab ich einmal die doppelte Deklaration der Variable ap entfernt und den Parameter ap in die Parameterliste vom Aufruf von func hinzugefügt.

Ich würde übrigens empfehlen gar kein Makro dafür zu verwenden. Da musst du ja ziemliche Verrenkungen mit der globalen Variable machen, um an den Rückgabewert zu kommen. Schreib den Code lieber in der Funktion aus, und speichere den Rückgabewert in einer temporären Variable während du va_end aufrufst. Anschließend gibst du die temporäre Variable zurück.

Zum Problem: Ich habs jetzt noch nicht fehlerfrei zum Laufen bekommen, aber ein paar Fehler, die ich gefunden habe und die du irgendwie beheben/umgehen solltest:
- Dein timer_handler sollte einen cpu_state* zurückgeben. Einfach nur new_cpu = schedule(new_cpu); funktioniert nicht.
- irq.c sollte timer_handler entsprechend aufrufen
- In init_task hast du immer noch das Problem, dass du Zeiger auf lokale Variablen zurückgibst. Du könntest die Rückgabe des Tasks irgendwie so versuchen:
    tasks[num_tasks].state = state;
tasks[num_tasks].pid = num_tasks + 1;
task *new_task = &tasks[num_tasks];

num_tasks++;
return new_task;
(Der Rückgabewert wird ja derzeit nicht verwendet, deswegen sollte das erstmal keinen Effekt haben.)
- schedule() sollte nur dann zurückkehren, wenn num_tasks == 0:
    if (current_task >= 0) {
        tasks[current_task].state = cpu;
    }
if (num_tasks == 0) {
return cpu;
}
Diese Änderung sorgt dafür, dass das Taskswitchung wieder aktiviert wird.

Wie gesagt, bei mir funktioniert das derzeit auch noch nicht, deswegen keine Garantie, dass die Fehler tatsächlich durch die vorgeschlagenen Lösungen behoben werden.
« Letzte Änderung: 28. December 2012, 23:51 von Jidder »
Dieser Text wird unter jedem Beitrag angezeigt.

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 29. December 2012, 00:19 »
Tipp: Nutze nicht nur -Wall sondern auch -Werror (also lass dich nicht nur mit Warnungen zu bombardieren, sondern behebe sie auch)

(beim Rest war Jidder schneller)

[Edit]
Bei mir läuft es jetzt.
In den Tasks fehlt noch etwas wie:
 asm("1: jmp 1b");
am ende, damit die nicht returnen
« Letzte Änderung: 29. December 2012, 00:59 von MNemo »
„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 30. December 2012, 00:06 »
Ähm Ich habe jetzt alle Warnings gefixt und asm("1: jmp 1b"); aber es tut sich immer noch nichts.
MNemo hast du vllt sonst noch was gemacht?


Code(asm("1: jmp 1b"); hab ich rausgelassen weils eben nicht ging):
http://uploadingit.com/file/wxog60n1yhzblo6x/el_toro_repo_5.zip
Sonstiges
Stack als lokale Variable? Du meinst, du legst den Stack auf den Stack?

Rekursion, die: siehe Rekursion.
Nicht mehr.
- schedule() sollte nur dann zurückkehren, wenn num_tasks == 0:
Ich habe ja schon dieses else nach if (current_task >= 0). current_task ist zu Anfang ja noch null
« Letzte Änderung: 30. December 2012, 00:37 von Martin Erhardt »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 30. December 2012, 00:29 »
- schedule() sollte nur dann zurückkehren, wenn num_tasks == 0:
Ich habe ja schon dieses else nach if (current_task >= 0). current_task ist zu Anfang ja noch null
Das ist nicht dasselbe. current_task ist anfangs -1. current_task ist größergleich 0, nachdem zu einem Task gewechselt wurde. num_tasks ist ungleich 0, wenn ein Task erstellt wurde.
Dieser Text wird unter jedem Beitrag angezeigt.

Martin Erhardt

  • Beiträge: 165
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 30. December 2012, 00:37 »
- schedule() sollte nur dann zurückkehren, wenn num_tasks == 0:
Ich habe ja schon dieses else nach if (current_task >= 0). current_task ist zu Anfang ja noch null
Das ist nicht dasselbe. current_task ist anfangs -1. current_task ist größergleich 0, nachdem zu einem Task gewechselt wurde. num_tasks ist ungleich 0, wenn ein Task erstellt wurde.
OK das else hb ich dann durch das num_task if ersetzt, aber es ist wie vehext ich kann machen was ich will es erscheinen kein  A und Bs.
Vlllt kann man da mit GDB noch was zurückverfolgen

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 30. December 2012, 11:24 »
Ähm Ich habe jetzt alle Warnings gefixt und asm("1: jmp 1b"); aber es tut sich immer noch nichts.
MNemo hast du vllt sonst noch was gemacht?
Ich denke, ich habe einfach nur was Jidder auch bemängelt hat ordentlich gefixt ;) (Siehe angehängter patch)

Sollte irgend eine Änderung dir nicht sofort einleuchten, frag einfach!

noch ein TIPP: mach mehr commits, wenn man sich git diff anguckt und da sind nur ein haufen nicht zusammengehöriger änderungen zu sehen, dann macht das das leben unnötig schwer.
« Letzte Änderung: 30. December 2012, 14:24 von MNemo »
„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

 

Einloggen