Context Switch #PF when idle selected

[NOOOCCCC]

Hi to all,

This is my second topic in this forum, after a year I returned to my hobby OS.
I started working on multitasking, all seems to work, at least partially, but I realized that when... Let me explain a bit.

My multitasking code is very simple:
-Timer interrupt arrives
-IRQ handler pushes all registers
-Selects a process from “ready tasks”
-Gets registers(cpu state) from selected task and returns them
-Again, in the IRQ handler it does a stack swap

How does it select a process:
-I have a one-way linked list of processes.
-Two pointers, one to the first task(the head) and the other to the last task in the list(the tail)
-For each switch I select the next task(forward in the list)
-If there is no “next”, then I select the first task again

The problems comes here, when I return to the first task(in my example is the idle task), so I get a page fault with this state before the interrupt is raised.

Code: Select all

Cause of exception: Page fault
Interrupt Number:0x0000000E
Error Code:0x00000000
EFLAGS:0x00000008


Segments:
DS:0x00000010	ES:0x00000010
FS:0x00000010		GS:0x00000010
Registers:
EAX:0x10400E40	EBX:0x00000000	ECX:0x0000001A
EDX:0x00000001	ESI:0x00000000	EDI:0x00000000
EIP:0x00000000
Stacks:
EBP:0x0014C83C
ESP:0x0014C80C

I do not know why my EIP becomes 0 (¿…?).

I am with this from 2 days ago. I will attach my task.c(only with important functions), I feel it is probably a silly mistake.

Thank you in advance for your help and sorry for my bad English.

EDIT: If I do not share where the code is mirrored is because of privacy reasons.

[iansjack]

I can't see enough information to see where your problem might be. You show a task_switch() function, but this doesn't load the state into the cpu's registers. You really need to link to an on-line repository of all of your code. Someone might then look at it all in context and suggest where the problem might lie.

But that someone won't be me.

Let me explain, in case that sounds rude. I am of the "give a man a fish and you feed him for a day, teach him how to fish and you feed him for life" school. So I will make my usual boring suggestion here. Run the code under qemu and debug it using gdb. And, if you don't know how to use a debugger, now's the time to learn. I can guarantee that the problem here is a simple one that you can solve yourself with debugging. Take this opportunity to learn how to do so before you are faced with less tractable problems.

[NOOOCCCC]

I can't see enough information to see where your problem might be. You show a task_switch() function, but this doesn't load the state into the cpu's registers. You really need to link to an on-line repository of all of your code. Someone might then look at it all in context and suggest where the problem might lie.

But that someone won't be me.

Let me explain, in case that sounds rude. I am of the "give a man a fish and you feed him for a day, teach him how to fish and you feed him for life" school. So I will make my usual boring suggestion here. Run the code under qemu and debug it using gdb. And, if you don't know how to use a debugger, now's the time to learn. I can guarantee that the problem here is a simple one that you can solve yourself with debugging. Take this opportunity to learn how to do so before you are faced with less tractable problems.

I already executed qemu and gdb on remote several times... when debugging there is no problem at all.
I will give you an advice too, do not assume what others know or do not know, until they tell you.

Below you have the asm code attached, not for you, but for all if they can help. But that code is 100% correct, for sure.
Thanks anyways.

[iansjack]

My next bit of advice would be:

When seeking help with a problem give as much information as possible.

You've already tried debugging it but it works OK under those circumstance? That's very important information.

Are you saying it always works in qemu, or just in combination with gdb?

Does it only fail on real hardware? That's a whole different problem. Does that mean that the output that you show is produced by an exception handler that you have written, rather than by a virtual machine. In that case I would advise that when printing a trace for a page fault you include the contents of register CR2, which tells you where that page fault occurred. As the error code is 0 that indicates that the operating instruction tried to read (but not fetch an instruction) from a non-present (probably not mapped) page. It would be interesting to know what it was trying to read, and what instruction was doing that read.

Anyway, if it's a fault that only happens on real hardware (or doesn't happen when running under a debugger) then try inserting print statements at various locations to narrow down the source of the error.

Sorry if I'm still telling you stuff that you've known for ages. But clearly the advisability of giving as much information as possible is something you are not familiar with.

Now, I think I've probably annoyed you enough so I'll leave it up to someone more sympathetic to solve the problem for you.

[NOOOCCCC]

Now, I think I've probably annoyed you enough so I'll leave it up to someone more sympathetic to solve the problem for you.

Unintentional(I do not know what have you understand), but...
Sorry(really sorry) might be a good reply right now. You can go now.

[iansjack]

You want me to apologize because you asked a question without supplying any real information? (And, incidentally, you still haven't supplied any useful information about your problem.)

I don't think so. My only regret is that I tried to help.

[NOOOCCCC]

It was me apologizing. This is a bad day to do things.