[Kos-dev] Bug : trouve :)

[Thomas Petazzoni]

salut,

j'ai enfin trouve le bug apres avoir remarque que juste avant que le
thread_recursive commence a tourner tout seul sans que les interruptions
marchent, une interruption 32 (timer) est interrompute par une
interruption 8 (double fault).

en effet, il y a un stack overflow durant l'execution du handler de
l'irq timer. et le hic c'est que dans ce cas, la fin du handler de
l'interruption 32 n'est pas execute, et le EOI n'est pas fait !

nous, on avait decide que si stack overflow pendant l'execution d'un
handler d'IRQ, et bien on arrete le systeme. mais on a pas reflechi : on
a mis le if(get_hw_isr_nested_level()) dans le if qui teste si l'adresse
de la pile est invalide. resultat si l'adresse de pile est invalide, et
que isr_nested_level >=1, on arrete le systeme, mais si l'adresse de
pile est valide (accroissement normal de la pile, comme c'est le cas
pour le thread recursive), eh ben on testait jamais ce truc. j'ai ramene
le test en dehors du if, et a la place d'un mechant freeze, j'avais bien
l'arret correct du systeme.

ceci m'amene a penser que dans ce cas, au lieu d'arreter le systeme
faudrait ptet mieux que le machin restart le handler d'IRQ d'une maniere
ou d'une autre. en effet, la maniere donc on gere ca pour le moment
permet d'avoir un fonctionnement aleatoire du systeme, qui depend de
quand tombent les interruptions horloge. bref, c'est pas du tout potable
tel quel.

faudrait donc prevoir un moyen de relancer le handler d'irq si un double
fault est detecte. pour cela, on peut lire le mask d'irq et on peut
savoir quelle irq etait en cours, mais le hic c'est qu'on va restarter
le handler d'irq depuis le debut, pas la ou ca s'etait arrete... est-ce
que ca va poser un probleme, je ne sais pas ...

la question reste ouverte.

amicalement,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/