Qemu crashes after interrupt.

[Luca1]

Sorry, but if all people in the OS dev community are as "open" to new people as some people in this thread I am not sure if I want/need friends in here.

imo this is one of the nicest places on the internet.

You just walked in, threw your code on the table and asked other people to fix it and then got upset when nobody spoon fed you more code. There's nothing wrong with asking for help, but you need to put some effort in yourself.

I don't want copy and paste code - but someone telling me that I forgot to read the data it would've been more helpful than what I got.

[xenos]

I doubt that QEMU crashes because you forgot to read the keyboard's status and data.

Well then give me another reason why my code works afterwards.

You are the one who made a claim which doesn't make sense at all, so you are the one from whom to request a proof, not the other way round. If you want to know what was really going wrong, then show all your code, explain every line in it and start understanding it. Right now all you're doing is guesswork, which is impossible to reconstruct.

[Luca1]

I doubt that QEMU crashes because you forgot to read the keyboard's status and data.

Well then give me another reason why my code works afterwards.

You are the one who made a claim which doesn't make sense at all, so you are the one from whom to request a proof, not the other way round. If you want to know what was really going wrong, then show all your code, explain every line in it and start understanding it. Right now all you're doing is guesswork, which is impossible to reconstruct.

You have the full code in my original post, which lead to qemu crashing with the error shown in the original post. After adding

Code: Select all

        unsigned char status = inb(0x64);
	if (status & 0x01) {
		inb(0x60);
       }

to my cihandle function it worked.

[iansjack]

Sorry, but if all people in the OS dev community are as "open" to new people as some people in this thread I am not sure if I want/need friends in here.

One day, should you persist with OS development, you will realise how good the advice to learn debugging was.

Whatever, you say you don't need friends here, and that's fine by me. People do tend to react badly to those who are rude to the unpaid volunteers here who try to help them.

[xenos]

First of all, you have not shown any linker script or specified where the kernel is loaded, or given any compiler / linker command line. Without this information we can only guess what your code does.

Second, the change you introduced does not fix the problem, at best it hides it, or is even completely unrelated. Your code enables interrupts at some point by executing "sti". Once your kmain function is done, it returns and you execute "hlt", with interrupts enabled. As soon as an interrupt occurs, the interrupt handler is executed, and returns. After that, the instruction after hlt is executed, which happens to be your inb function. It ends with a "ret", but since there was no "call" to return from, it jumps to whatever happens to be on the stack right now, obviously some bogus address, and continues running from there, until it leads to a crash (like the one QEMU reports - execution runs somewhere where there is no usable RAM). Now your change may have caused something to run differently, so it doesn't jump to the same bogus address, but it still jumps to a different one, it just doesn't crash immediately (but it will at some point).

The best way to actually figure out what's going wrong is to single-step your code in a debugger, so you could use QEMU + GDB for that, or use Bochs instead, which has its own debugger and also tells you much more about what happens in your code.

[Luca1]

Sorry, but if all people in the OS dev community are as "open" to new people as some people in this thread I am not sure if I want/need friends in here.

One day, should you persist with OS development, you will realise how good the advice to learn debugging was.

Whatever, you say you don't need friends here, and that's fine by me. People do tend to react badly to those who are rude to the unpaid volunteers here who try to help them.

I am not saying that a debugger is not a good advice.
The problem is that the help that was provided to me was not help at all.

First of all, you have not shown any linker script or specified where the kernel is loaded, or given any compiler / linker command line. Without this information we can only guess what your code does.

Second, the change you introduced does not fix the problem, at best it hides it, or is even completely unrelated. Your code enables interrupts at some point by executing "sti". Once your kmain function is done, it returns and you execute "hlt", with interrupts enabled. As soon as an interrupt occurs, the interrupt handler is executed, and returns. After that, the instruction after hlt is executed, which happens to be your inb function. It ends with a "ret", but since there was no "call" to return from, it jumps to whatever happens to be on the stack right now, obviously some bogus address, and continues running from there, until it leads to a crash (like the one QEMU reports - execution runs somewhere where there is no usable RAM). Now your change may have caused something to run differently, so it doesn't jump to the same bogus address, but it still jumps to a different one, it just doesn't crash immediately (but it will at some point).

The best way to actually figure out what's going wrong is to single-step your code in a debugger, so you could use QEMU + GDB for that, or use Bochs instead, which has its own debugger and also tells you much more about what happens in your code.

This is the first thing that actually helped - thanks!

I added

Code: Select all

while(1){asm("hlt");}

to the end of kmain let's hope it stays bug free.

if you are still interested:

link.ld

Code: Select all

OUTPUT_FORMAT(elf32-i386)
ENTRY(start)
SECTIONS
 {
   . = 0x100000;
   .text : { *(.text) }
   .data : { *(.data) }
   .bss  : { *(.bss)  }
 }

and the commands used to compile:

Code: Select all

nasm -f elf32 kernel.asm -o kasm.o
gcc -fno-stack-protector -m32 -g -c kernel.c -o kc.o
ld -m elf_i386 -T link.ld -o kernel kasm.o kc.o

[dozniak]

Whatever, you say you don't need friends here, and that's fine by me. People do tend to react badly to those who are rude to the unpaid volunteers here who try to help them.

I am not saying that a debugger is not a good advice.
The problem is that the help that was provided to me was not help at all.

That's fine, we don't need you too.

[Luca1]

Whatever, you say you don't need friends here, and that's fine by me. People do tend to react badly to those who are rude to the unpaid volunteers here who try to help them.

I am not saying that a debugger is not a good advice.
The problem is that the help that was provided to me was not help at all.

That's fine, we don't need you too.

That

I am not sure if I want/need friends in here.

was meant as "I am not sure if I will continue in OS dev", because if someone is saying

That's, fairly obviously, the cause of your problem.

it means that they know what the problem is without telling me why it occurs or how it is fixed. Which is, in my opinion, not nice.

[FusT]

it means that they know what the problem is without telling me why it occurs or how it is fixed. Which is, in my opinion, not nice.

First off, it's perfectly fine to have that opinion.
Having said that, the goal is to help people out by giving them a push in the right direction, not give them the answer to solve their problem. This is because you should completely understand why your code doesn't do what you expect it to do instead of relying on others to fix it for you. If you don't completely understand why something is/isn't working you'll never be able to fix future (and more complicated) problems by yourself.

I do realize this approach may seem hostile towards newcomers but it scares of copy/pasters not willing to learn.

[iansjack]

That

I am not sure if I want/need friends in here.

was meant as "I am not sure if I will continue in OS dev", because if someone is saying

That's, fairly obviously, the cause of your problem.

it means that they know what the problem is without telling me why it occurs or how it is fixed. Which is, in my opinion, not nice.

Now, do you think it fair to quote a single sentence out of context? The fuller quote is:

Do you know the state of the stack? Do you know how the stack go into that state? (That's, fairly obviously, the cause of your problem.) Is your stack even valid?

I told you exactly what I thought the cause of your problem was (a corrupted stack) and, in the same post I told you exactly how to solve it. (Use a debugger to find out where and why the stack is being corrupted.) You seem to be expecting someone to debug your program for you and then tell you exactly where the incorrect instruction in your program is without putting in any effort yourself. That's not the way it works.

In my opinion it is not nice to be rude to people trying to help you and it is not nice to twist their words - and lie about what they told you - by quoting out of context.

I think your inability to accept advice, and your willingness to give up so easily without putting in a little groundwork, are not going to stand you in good stead with what is a fairly difficult field of study. I think you are right to doubt whether you will continue with OS development.

[obiwac]

This is probably not going to help this situation at all, but why don't you just leave this post, to preserve the kindness / niceness of these forums?

[iansjack]

If that was addressed at me, I'm more than happy to leave.

[Luca1]

it means that they know what the problem is without telling me why it occurs or how it is fixed. Which is, in my opinion, not nice.

First off, it's perfectly fine to have that opinion.
Having said that, the goal is to help people out by giving them a push in the right direction, not give them the answer to solve their problem. This is because you should completely understand why your code doesn't do what you expect it to do instead of relying on others to fix it for you. If you don't completely understand why something is/isn't working you'll never be able to fix future (and more complicated) problems by yourself.

I do realize this approach may seem hostile towards newcomers but it scares of copy/pasters not willing to learn.

It just looks like you are trying to keep the knowledge to yourself if you are not giving answers to the problem. This is the first forum that I'm in where it is handled this way.