iansjack wrote:
I'm lost. There is no system call in that user program.
If you recall a few posts earlier, stdcall changed int 0x80 to int 0x40, due to gdb misbehaving
stdcall wrote:
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 ?
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.