OSDev.org

Multitasking in my kernel work, except that it GPFs after a while. Here's what will happen, my kernel will say

I've also had it do this

Here's my task creation code

my task switching code

my IRQ 0 code

the code for my tasks


Has anybody had a similar problem? or any ideas as to why this is happening?

Try this for your irq0



This is pretty much how mine works, except that I also set ds,es,fs,gs to my kernel data section and use my kernel stack (this is for usermode- >kernel switches). Also, since when each task is FIRST run, it doesn't have a valid value to pop off the stack for the pop %esp call, so you must also update your create_task function with one more value, and since it's discarded, the value can just be 0 . I chose to just remove the pop %eax, it makes things a bit simpler, since you already stored the ESP, and you wipe this out on the next call after the pop, there is no reason for it.

Unless I missed something, this should work alright, I rearranged some things and tried to make it simpler to read. I don't typically use AT&T syntax (read, almost never), so if there is a syntax problem, sorry .

Hi,

In my experience, multitasking crashing after a certain interval tends to be due to "stack creep". Ensure that when your IRQ happens, the value of ESP isn't gradually creeping down in memory due to dodgy updating of TSS or similar.

Cheers,
Adam

and then



At the end of each entry into kernel mode, you should set the current kernel stack pointer to the base of the stack. What is happening is that the task starts at the original stack(lets say at 0x1000). Then the irq is called and you push values and now the stack is (0xFEE, these are just examples.) Now when the task is schedule again, the kernel stack base is 0xFEE. Then on the next task switch you again push everything and you save the current stack pointer so your stack goes down again(maybe 0xFCC). As you can see your stack gets lower and lower. So sooner or later it will reach an unmapped address or something like that.

Hope that helps.

That entire task_switcher routine looks somewhat fishy though. Like, why should it being just initialized mean that you need to do somethin special? The ESP value should be correct on start, and if you pushed the registers of the current task on the current stack (whatever stack your actual kernel is using), it won't screw with any of your tasks anyways, you could easily make that much simpler to read. Disregard what the guy above said, he obviously didn't read your code or missed something sinc you are obviously poping values back off the stack after storing ESP, i have no clue where he got that from (pulled from his a$$?) Like I mentioned you have the extra pop in there, fix that and let us know, also I will post a bit later on how to fix your task_switch so it doesn't look so clustered and waste time with those checks every time after it's started.

--- Edit ---
Ok, here is how mine works (mine uses pointers so it's a bit simpler, but i'll show you how with an array like you're using).



See how much simpler your task_switch is now, and since it's called a lot, it will make a difference! Please keep us updated on how it's going if you got it working yet or not .

There's a good reason i have the extra pop %eax. For whatever reason when task_switcher gets called. It doesn't pop the last value off the stack, and if i remove the pop eax, it corrupts the stack and causes a GPF.

--Edit--
Okay, i figured out how to create a proper bootable image using grub, so now i can run my OS in bochs here's what it tells me

The actual screen

what the log says

Well, then something is wrong somewhere, here is a walkthrough of your code:

esp = 0x1000 (for simplicity)

pusha ;Pushes 8 dwords, 32 bytes
;esp = 0xFE0
mov %ds, %eax
push %eax ;4 more bytes
;esp = 0xFDC
mov %es, %eax
push %eax ;4 more bytes
;esp = 0xFD8
mov %fs, %eax
push %eax ; and 4 more
;esp = 0xFD4
mov %gs, %eax
push %eax ;and 4 more...
;esp = 0xFD0

mov %esp, %eax ; Here we are pushing ESP, so EAX = 0xFD0
push %eax
;esp = 0xFCC (but remember, we pushed FD0, not FCC!)

call task_switcher ;Returns the STORED ESP value

mov %eax, %esp ;restore ESP to 0xFD0

mov $0x20, %al ;eoi for pic
out %al, $0x20
pop %eax
;esp = 0xFD4

pop %eax
;esp = 0xFD8
pop %eax
;esp = 0xFDC
pop %eax
;esp = 0xFE0
pop %eax
;esp = 0xFE4
popa
;esp = 0x1004 ;Uh-oh, we blew past our stack start, this is a problem!
;Crap, now if we iret, we will jump to the incorrect EIP, and GPF occurs


Please tell me what i'm missing, because you have more pop's than pushes as demonstrated, it will destroy your stack, and the wrong values are ending up in the wrong registers. if you remove that pop, and it's still crashing, then start looking in your other functions and let us know. This is how the stack works, you cannot fool the stack, if you aren't pushing the correct # of values to the stack on task creation (i push more than you do, so possible problem), then it will work on the first run through (poping a bogus value from the stack for it to work and put the EIP in the correct location for the first iret, then never work again when the task is called, which looks to be your problem). Every time you switch BACK to a task, it will crash, if you had 15 tasks, each one would run ONCE then GPF when the first task is called again. So, again, please remove that pop and let me know what happens, and we can try to find the ACTUAL problem. I know how a stack works, i'm not trying to point you in a wrong direction i promise. Also, for me, I had to put an additional *stack--=0x10 to compensate for the pushed SS value.

This is what happens when i remove the pop
It doesn't even go through the list once

Ok, so now that you are there, try a few extra things... firstly, try putting known values into eax, ebx, ecx, etc in your create task function, then before your interrupt can return (right before the sti I would) hlt the cpu or put an infinite loop, then exit out and check if the correct values are put into the correct registers. If they differ, then you can see which values ended up where and have an idea on what is going on. Once you figure this out, you can proceed to the next trouble shooting step. this is why bochs is great, it allows you to stop the CPU and see what is going on inside at any point. I would use something closer to how my code is (actually push/pop es,ds,gs, and fs) that way, if you ever want to do other code/dats segments, you are already popping the correct values into their perspective registers (rather than just incrementing esp by poping the values into EAX). This will also help determine if they are popping the correct values as you are expecting. also, in your create task function, trying pushing another value for SS at the start (as the first value put on the stack).

Getting closer to having this working
The value that's in ebp should be in ecx
which means the stack is off my 16 bytes

So, this is how bug tracing typically goes with Bochs. So, you see your stack is off by 16-bytes, which is 4 dwords. So, how are you first starting your task switching? Are you just letting the interrupt fire? calling a function or sorts, etc? Any clue where those 16 bytes could come from? Also, are you sure that you are reading them properly, remember, that the stack starts at the top, and moves downwards, so it should push in this order:

ss
eflags
cs
eip
eax
ecx
edx
ebx
esp
ebp
esi
edi
ds
es
fs
gs

Now, also, look at your ESP value... in your print out, it says the stack is at 0x001241D4... then in your printout, it shows it at 0x001241F0... what value are you printing (before the stack is moved or after?) These things can give you hints on the problem. You appear to be pushing the correct # of things onto the stack (although I would add one more *stack-- = 0x10 at the beginning to reserve it for ss). Now, one BIG thing that I did notice, is that you're post decrementing..., you need to pre-decrement...
*--stack = xxx;. The reason for this is, the stack grows downwards right.. lets assume 0x1000 for ease of use again:

esp = 0x1000
*stack-- = 0x10;

Lets break this down:
*stack = 0x10;
stack--;

So, you are setting 0x1000 = 0x10, when indeed you are trying to set 0xFFC = 0x10; So you must predecrement:

*--stack = 0x10, etc, etc. This was your reason for off by one, hence why you had to add the extra pop in there to get it to even fire each task once (which doesn't work once the tasks is reentered due to the off by one problem). So, I hope this concludes this lessons learned, and you should have a functioning multi-tasker once you fix the post/pre decrement, and have that extra pop instruction removed. I hope you learned a bit about bug-hunting and can learn from this and move forward. If you're still having issues, post your updated code so I can see what you're currently working with and can assist further. Like I said, I wasn't trying to lead you astray telling you you had an extra pop in there, it WAS a problem masking the real problem (post decrement rather than pre), so putting it back allowed us to find the actual problem.

I guess that pre-decrementing was the answer. It works perfectly now. Thanks for all your help.

Glad it's working, hope you got some stuff out of troubleshooting a bit. Now if I could only figure out the bugs in my own kernel i'd be set . Anyways, let us know if you run into more issues and don't be affraid to put endless loops, etc to check outputs in bochs to see what is going on with the registers, and think it through logically (like I did when I described what was happening with ESP when it is calling your function to prove why you didn't want that extra pop in there, to figure out the problem was else where).