OSDev.org

calling int 0x80 to issue system call causes the following error message on Bochs:
Message: I/O apic write at unaligned address 0x0000fec00ffc

I've tracked it to the specific 0x80 command that causes the problem. what could be the issue ?

By the way, qemu doesn't output that message.

What operating system is this happening in? And what system call number? The error message seems to be fairly clear.

My operating system, the one that I'm writing .
The system call number is irrelevant, this occurs even before it get's to the ISR handler.

My guess that it's something regarding TSS or something, because it never occurred when I was working in ring 0.
Now that I switch between ring 3 to ring 0 I encounter this error.

It's very difficult to make a reasonable suggestion based on almost no information. Can you provide a link to your code repository.

And have you tried single-stepping the code to see exactly what is happening?

Yes. I'm single stepping at assembly level and I get the error immediately after it executes the int 0x80 instruction.

You can follow the code here:
https://github.com/mellowcandle/epOS

relevant parts:

APIC/IOAPIC init code:
https://github.com/mellowcandle/epOS/bl ... nel/apic.c
User space program:
https://github.com/mellowcandle/epOS/bl ... /program.c

Thanks.

I'm lost. There is no system call in that user program.

syscall is implemented in libc.
Here's the code:
https://github.com/mellowcandle/epOS/bl ... syscalls.c

If you recall a few posts earlier, stdcall changed int 0x80 to int 0x40, due to gdb misbehaving

What is relevant is that something is trying to write to the physical address where the I/O APIC registers are located. However, the access is way off. Those registers are accessed indirectly through only like 80 MMIO bytes or so at 0xfec00000. Any access past that would have asserted a few lines later in Boschs's code, because the entire page belongs to the I/O APIC, but should not be accessed past that.

I hoped that it must be either something in your virtual to physical translation or something in your kmalloc. The only way in which this could be relevant to the processing of int 0x40 in and of itself, is if you have configured the kernel stack to that I/O APIC page. Which explains the address (descending from the top of the page, as the CPU tries to push the user context.)

I see that in mem_init total_memory is computed from the longest mmap->len from GRUB, but mmap->addr is not taken into account. It is assumed to coincide with the region where the kernel was loaded. At least to me this seems problematic. Another possible issue, which I have not investigated in detail, is what happens when the explicit memory mappings by mem_page_map overlap virtual memory already allocated by mem_page_map_kernel. But those are just things to look into.

You are a genius. by mistake I configured the TSS stack to the kernel stack page start and not to the end of it (stack grows downwards).
Thanks !!!!