[Kos-dev] #DF et interruptions

[Thomas Petazzoni]

> Si le #DF apparait suite a un push explicite dans notre ISR a nous
> qu'on a ecrit, le #DF doit etre capable de revenir dans l'ISR sans
> probleme, non ? Dans ce cas, pas besoin de le relancer. A verifier.

bin dixit un ancien mail de hlide de la ml kos-dev, apparemment non.

> Quelques interrogations :
>   - on n'est pas sur que le system tss (contexte interrompu) est
>     charge avec qqch de correct :
>       + quel eip ? celui de la tache ? Ou la premiere instruction (non
>         executee) de l'ISR ?
>       + quel esp ? cf suite...

dixit hlide, c'est celui de la tache interrompute, mais c'est a verifier
!

>   - on ne sait pas ce qui a ete empile ou pas empile avant la
>     frontiere de page qui a cause le #DF. La pile etait-elle :
>     Comment on differencie les 4 cas au niveau du #DF ? A quoi sera
>     positionne le esp du contexte interrompu ?

effectivement c'est un probleme.

> Bref : comment detecter que le #DF est intervenu a l'interieur de
> *notre* code d'ISR, ou a l'interieur de la sequence interne du
> processeur (celle qui charge la pile avec le contexte interrompu) ?
> Dans le 2eme cas, est-on sur de recuperer *quoi qu'il arrive* le
> contexte 1/ de l'ISR interrompu, puis 2/ de la *tache* interrompue
> (necessaire pour la fin de l'ISR), qui nous permette de retourner
> correctement vers la tache interrompue ?
> 
> Faudrait essayer. Je suis pas sur que la doc Intel soit tres locace a
> ce sujet.

bin au niveau des tests, quand on a un pb de stack overflow pdt un IRQ,
j'ai affiche le ISR (interrupt service register). et il se met a 0x1
quand l'int timer a ete interrompute par un stack overflow. c'est
bizarre car normalement c'est l'irq 0, mais j'ai pas bcp de docs pour
verifier.

par contre j'espere que hlide pourra repondre a quelques unes de nos
interrogations.

-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com
ICQ : 34937744
Projet KOS : http://kos.enix.org