Just found this: https://news.ycombinator.com/item?id=5261598

Combining that info with the 80386 manual in interrupts(and task switching): a stack overflow pushing the error code after switching the task will result in a stack fault? Isn't the fault nesting 'level'(the CPU's idea of the previous fault for determining double faults) cleared/unset after loading state from the new task(thus allowing page faults)? Or is it only cleared after pushing the error code and starting the next instruction fetch(end of the task switch)?

Edit: Although cleared present bit on #SS&#NP in IDT on stack->#NP->double fault might trigger this?

So, my current question is: is the fault status(keeping track of the previous fault to detect double fault) cleared when setting the TS flag in CR0(so immediately before starting to load the CS segment of the new task), or is it only cleared once the whole task swith completes(after the error code is pushed and the CPU is ready to start fetching/excuting the new instruction in the new task)?

I've adjusted my code a bit according to the Bochs taslomg.cc ( http://bochs.sourceforge.net/cgi-bin/lxr/sour … /cpu/tasking.cc ). Now TR is properly reset when switching tasks. Also, the bug during JMP switching tasks(NT flag of incoming task unchanged instead of cleared) has been implemented.

It still somehow seems to try to execute an IRET loading 0x00000000 dwords from memory, causing an invalid #GP(it isn't supposed to happen)?

Looking at the code, it's kind of acting odd: it goes from task 0068 to task 0048 using a CALL(allowing return by IRET because of the Nested flag), then proceeds to execute a JMP to transfer control to task 0058, which breaks the task linkage, continuing the delays(by loading 0 into CX and executing a LOOP instruction), eventually executing an IRET which crashes because NT isn't set anymore(due to the task switch from task 0048)? Or is task 0058 supposed to keep using the same TSS somehow?