Just finished checking and fixed loading and saving of 32-bit TSS(it was having problems loading and storing the segment registers because the pointers to their consecutive segment selectors was updated incorrectly). Having fixed that, task switching seems to work without problems now! The mouse on that OS isn't working, though(probably because it's a serial mouse?).
Edit: Now it double faults due to the #GP fault handler for the debugger fault(because the T-bit of a task is set, which causes a non-existant debug trap, thus causing a general protection fault which has an invalid (also 0x0010) CS segment to use?). Odd.
Edit: Huh? The CR0's paging bit is cleared with the CR3 still containing a paging value? Is paging disabled during the fault oddly?
Edit: Just tried again. Now the fault doesn't seem to happen(the first time)?
Edit: Now the fault seems to be due to opcode 6A(the last executed instruction)?
Edit: Hmmmm... It the #GP fault handler that handles the debug trap fault handler tries to execute INT 0x20. But when loading CS with the value 0x0010, the loading fails for some odd reason?
Edit: The memory at 0x270010 which contained the general protection fault's CS segment descriptor is cleared to zeroes at this point(the INT 0x20)? So it will triple fault because of that reason?
Edit: Both interrupts should have been set at boot time, so something is clearing the IDT entry during the #GP fault handler?
Edit: While enabling the debugger during that error phase(just before until just after the triple fault), I notice it dumping some text into the main window(something about the GP fault, then EIP is written(behind the other window)). Then the INT 20h occurs, leading to the triple fault.
The attachment debugger_TripleFaultingOnINT20h.7z is no longer available
So still some troubles, but progress! 😁
Edit: Hmmmm.... From row 2940096 onwards it seems to process something, writing zeroes into the GDT+0x10h selector?
Edit: Hmmmm... It has something to do with EBP+14 and onwards being zero instead of valid data for a descriptor to be filled?
Edit: Said clearing seems to be done by the code at line 3179983 and onwards (push 00)?
Edit: Hmmmm... Could that be row 33/34 of desctbl.c(it's initializing the GDT with zeroed entries). But after that, it's supposed to set GDT+0x0008 to a linear 4G descriptor, while setting GDT+0010 to ADR_LIMITBOTPAK and ADR_BOTPAK as a code descriptor, which obviously doesn't happen for some odd reason?
Edit: Looks like I'm right: row 3180755 is the end of the set_segmdesc function. After that it returns to the init_gdtidt function at 0010:0000131e, where the next two instruction after that is the for statement it seems(jns 0000130f is the loop executing). So 0010:00001324 should be the end of the for loop, where it calls the function to setup the gdt code segment.
But before it reaches that, the interrupt/fault already happens. I see it reaching "EBX: 00001f00", looking further down, but "EBX: 00001e00" isn't reached?
Edit: The last point it reaches in the loop is line 3292446, where it reaches count 00001eec(of clearing the GDT). So something interrupts said operation, while it shouldn't.
The interrupt flag is set, so there's a problem(interrupts can cause it to break in the middle of setting up the GDT).
Edit: Yup, during the second push, it actually still has the interrupt flag enabled, and the interrupt(which seems to be 20h) tries to use the a valid IDT entry to load CS, which faults because it's still cleared and not setup yet. Then it's the fault of some CLI not being executed before the main changing loop?
Edit: Hmmmm.... Said function that initializes the GDT/IDT doesn't affect the flags in any way(it's a problem with hardware timer(IRQ0) interrupts at this point). The cause of it seems to be within the first function of HariMain(bootpack.c), which is enabling interrupts after said initialization. But interrupts were already enabled before calling said function.... Hmmmm....
Edit: So line 3179898 is the start of the call to the HariMain function. At that point, interrupts are already enabled, which they shouldn't according to the source code?
Edit: Hmmmm.... The IRET at line 2940082 sets the Interrupt Flag on by popping it off the stack at stack address 0030FA3C.
Edit: Looking upwards, I still see it set at line 2939503, where the interrupt was started.