OSDev.org

yee1 wrote:I've built task scheduler and it's working fine when running at Bochs.
Problem is running it at real machine / virtualbox.
At virtualbox screen freezes after IRETD instruction is executed.
At real machine IRETD from task code makes it restart.

yee1 wrote:I am using nasm and I call new task this way:

Code: Select all

call dword 0x58:0x0 ;0x58 task selector from GDT

Task code is like that:

Code: Select all

task1:
;some code here
iretd
jmp task1

Brendan wrote:Hi,

yee1 wrote:I've built task scheduler and it's working fine when running at Bochs.
Problem is running it at real machine / virtualbox.
At virtualbox screen freezes after IRETD instruction is executed.
At real machine IRETD from task code makes it restart.

"Restart" normally means "triple fault", which happens when there's an exception and the CPU can't start the exception handler (and then can't start the double fault exception handler either).

yee1 wrote:I am using nasm and I call new task this way:

Code: Select all

call dword 0x58:0x0 ;0x58 task selector from GDT

Task code is like that:

Code: Select all

task1:
;some code here
iretd
jmp task1

I have no idea why this didn't crash on Bochs too. The correct way to return is with the "retf" instruction.


Cheers,

Brendan

00166160841e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0
00166160841e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00166160844e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0
00166160844e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00166160847e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0
00166160847e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00166160850e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0
00166160850e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00166160850e[CPU0 ] interrupt(): gate.type(2) != {5,6,7,14,15}

I have found that it should be IRETD instruction to back from interrupt gate and from task, so where is a problem ?

AJ wrote:Hi,

1. What does IRETD do (and what does it expect on the stack)?
2. What does RETF do (and what does it expect on the stack)?
3. What did your original far CALL do (and what does it push on to the stack)?
4. What is on your stack just before the end of task1? You can very easily investigate this on Bochs.

Cheers,
Adam

iansjack wrote:

I have found that it should be IRETD instruction to back from interrupt gate and from task, so where is a problem ?

I think you must have misinterpreted what you have read. I don't believe that you will find a reliable reference telling you that you should CALL a task and then IRETD from it. On the other hand, you will certainly find references telling you (correctly) that one way to switch tasks is via an IRETD.

Although tasks can't be reentrant, they can be nested. If you switched tasks through a FAR CALL (as opposed to a FAR JMP), the new task is considered to be nested within the old task. The new task will have its Back Link field filled in with a pointer to the old task's TSS; this happens automatically. Both tasks will also have their "busy bit" set, so they can't be called again. The processor also sets the NT (nested task) flag in its EFLAGS register. This is essentially a "valid bit" that says the Back Link field is now officially binding.

With NT set and the back link updated, the processor knows this task is a child of another task. An IRET (interrupt return) instruction will now un-nest the tasks. Normally, an IRET just pops a return address off the stack and performs a normal interrupt return. When NT is set, however, the processor performs a task switch, clears the NT bit, and follows the back link to the parent task. Pretty nice work for a collection of transistors, huh?

By the way, a normal RET instruction won't un-nest tasks, even if they were nested by CALL instructions. Only an IRET will do this.

db 0xEA
dd 0x0000
selector dw 0x0

1. switch to task number 1 => OK (working fine)
2. switch to task number 2 => OK (working fine)
3. switch to task number 3 => OK (working fine)
4. switch to task number 1 => exception occurs

• The assembler you're using is so hideously unusable that you had to resort to not using assembly and using machine code instead (the "db 0xEA, ..." stuff)
• You were using an "interrupt return" to return from a call that was never an interrupt; and this problem was masking the symptoms of another problem
• Something causes the "LDTR.valid=0" error. My best guess is that you never did "LTR" anywhere in your initialisation code, so when the CPU tries to do the very first task switch it can't store the previous task's state (before loading the next task's state).

Brendan wrote:Hi,

Just an extra question (I'm curious) - why are you using "call far" for task switching in the first place? This should only be done when you need to switch to one task for a little while and then always switch back to the original task; which is almost never the case. To be perfectly honest; I can't think of any valid use for "call far" for task switching.

For scheduling, typically some kernel code gets running (due to an IRQ or system call) in the context of the currently running task, and (for whatever reason) the kernel decides to do a task switch; so the kernel code does a "jmp far" from the task that was running to the new task without expecting that new task to return to the original task; and eventually the kernel decides to do another task switch, and does another "jmp far" to the next task, then the next, and so on ("jumping" from task to task to task while never expecting any task to "return" to the previous task).

Also note that (for hardware task switching) the difference between "call far" and "jmp far" is how the CPU handles the "busy" flag in the TSS. For "jumping" the previous task's "busy" flag is cleared (so you can "jump" back to it whenever you like); and for "calling" the previous task's "busy" flag is left set to make sure that the only possible way to switch back to it is via. a "retf" (to guard against recursive calls).


Cheers,

Brendan

irq0_interr_handler:

inc word [currentTask]

mov ax, word [currentTask]

cmp ax, 1
 je runTask1
cmp ax, 2
 je runTask2
; run task 3 code here
jmp dword 0x40:0x0
jmp taskRunEnd
runTask1:
jmp dword 0x30:0x0
jmp taskRunEnd
runTask2:
jmp dword 0x38:0x0
taskRunEnd:

mov al, 60h
out 20h, al
iretd

task1:
task1loop:
;task1's code
jmp task1loop

task2:
task2loop:
;task2's code
jmp task2loop

task3:
task3loop:
;task3's code
jmp task3loop

yee1 wrote:This code is working in Bochs but it's not working with virtual box / real machine. What may be cause of it ?

Brendan wrote:Hi,

yee1 wrote:This code is working in Bochs but it's not working with virtual box / real machine. What may be cause of it ?

It shouldn't be working in Bochs either - you have to send the EOI to the PIC before you do the task switch.

Also note that it's cleaner to do an indirect far jump ("jmp far [currentTSS]") instead of "if(1) jmp 1; elseif(2) jmp 2; elseif(3) jmp 3;...".

Finally (eventually) you want this split into 3 pieces - the IRQ handler, a "reschedule" function and a "goto_task" function. For an example and explanation see this post.


Cheers,

Brendan

    section .data
currentTSSfarPointer:
    dd 0                           ;Note: CPU ignores the "offset" part, so there's not much point having it..
currentTSS:
    dw 0x38
    section .text


;Note: IRQ0 *must* be an "interrupt gate" (and can not be a "trap gate")

irq0_interrupt_service:
    push eax

    ;send eoi signal (end of interrupt)
    mov al, 0x20
    out 0x20, al   

    call reschedule

    pop eax
    iretd


;Find task to run and switch to it

reschedule:
    push eax
    movzx eax,[currentTSS]
    add eax,,8                     ;eax = next TSS to switch to
    cmp eax,0x38                   ;Is it too high?
    jbe .l1                        ; no
    mov eax,0x30                   ; yes, wrap around to first TSS
    call gotoTask
    pop eax
    ret


;Switch to a specific task
;
;Input
; ax = TSS for task to switch to

gotoTask:
    cmp [currentTSS],ax             ;Is this task currently running?
    je .done                        ; yes, do *not* attempt to switch (will cause GPF)

    mov [currentTSS],ax
    jmp far [currentTSSfarPointer] ;WARNING: Task switch and not a JMP (execution continues after the jump)

.done:
    ret

  jmp far [currentTSSfarPointer] ;WARNING: Task switch and not a JMP (execution continues after the jump)

yee1 wrote:I don't understand this line of code

Code: Select all

  jmp far [currentTSSfarPointer] ;WARNING: Task switch and not a JMP (execution continues after the jump)

Why will it continue execution of next instructions after jmp far [currentTSSfarPointer] is executed ?

yee1 wrote:Well I know there should be values to be pop'ed from stack by iret instruction, but how it's possible that after far jump next instruction won't be executed of jumped task ? When irq interrupt is done at stack it has pushed 12 bytes (eip/cs/eflags), right ? But eip/cs/eflags are saved data of task where irq was executed. When iret will be executed it would back task that it was executed from, right ?

yee1 wrote:Well you have used "jmp far" instruction, i suppose it for tasm or fasm. I write my code in nasm and i am using "jmp dword" instruction. Is it wrong ? Opcodes of both instructions are different.