OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 4:39 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: IDT Problem: Bochs says "physical address not found"
PostPosted: Fri Jun 29, 2018 6:10 am 
Offline

Joined: Tue Dec 12, 2017 6:51 am
Posts: 23
Hi Guys,

Lately, I was developing other stuff in my kernel - but for some reasing GRUB denied loading my kernel due to relocations (the kernel relocated itself later on, and yah all kernel modules, including the main one are position-independent). Hence, I decided my kernel was complex enough, that it deserved a initializer module. The initializer module, being a static, non-relocation requiring binary, was loaded at the 1 MB mark instead of the kernel (main module, named KernelHost). It loaded the other modules, (at a physical address, but relocated at virtual addresses above 3 GB mark), relocated them, passed symbol-tables, hash-tables, string-tables, and so on to the KernelHost.

Now, everything works fine - functions are callable. I map the interrupt hooks (ISRs) to the IDT, then load it. To test whether a interrupt works:

Code:
int $0x21


Boom, the kernel crashs (maybe triple faults). In Bochs, however, I get a message too that

Code:
??? physical address not found # or available, don't remember, as I am on another PC


I did the following counter-tests:

1. Called the interrupt hook from the code (there is a while loop before the IRET instruction) - yep, it works! That means it is paged, and physical address should be available.

2. I also debugged the whole IDT - everything was at its place. Entries left filled with zeros were as is - and filled entries where correct - segments, DPL, and so on.

3. Even the GDT selectors were correct - CS:0x8, DS:0x10.

What could possibly be wrong with the kernel? Note that, before the initializer module was present it was working. The kernel is now loaded at 16-MB (on the VM I am testing, but the initializer module loads it wherever it wants to). That is the only change with the module which loads the IDT (Hardware Abstraction Layer module).


Top
 Profile  
 
 Post subject: Re: IDT Problem: Bochs says "physical address not found"
PostPosted: Fri Jun 29, 2018 8:51 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
You didn't say whether 32-bit or 64-bit, but your comment about mapping beyond 3GB makes me think it is 32-bits. In that case: Is the interrupt descriptor in the IDT a task gate? If so, is the TSS set up for that?

Other than that, I couldn't find your error message in the source.

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: IDT Problem: Bochs says "physical address not found"
PostPosted: Fri Jun 29, 2018 9:09 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
That error often results from an invalid physical address in cr3. Step through the interrupt call in the debugger and check the value in that register.


Top
 Profile  
 
 Post subject: Re: IDT Problem: Bochs says "physical address not found"
PostPosted: Sun Jul 01, 2018 1:57 am 
Offline

Joined: Tue Dec 12, 2017 6:51 am
Posts: 23
Hello Friends,

Actually, the problem had a very different nature then all of us thought. Actually, I overwritten the 0x21 interrupt later in the code to a different function __irqCallback21 (actually HAL maps interrupts from 32 to 191 for device drivers), and then __irqCallback21 depended on some later initialization - causing a fault. I was trying to test my dummie ISR at 0x21, while the problem was at __irqCallback21.

How did I find that I overwritten the entry?

Well, I mapped a Spurious ISR at 0x21 for testing. But actually, it was also mapped at 0xFE (the APIC used it as spurious vector later) - but while debugging in Bochs, the IDT entries had different addresses. That meant that the vectors 0x21 and 0xFE did not map to the same entry.

I also found a different problem in the code too.

My initializer performed relocations on the kernel, yah. So, in the Spurious ISR, I did a test function call - but that also caused a fault (after fixing the above 0x21, 0xFE mistake). I used readelf to check the relocation on that function call - PC32. I checked my PC32 relocation - everything was right, wait. In PC32 relocation, you subtract the address where the relocation was occuring. But my initializer did that - except the physical address. That caused the whole problem - it was in physical memory, but was being relocated for virtual memory, so I fixed that to subtract the virtual address of the relocation patch.

Thanks, everyone! My updated code will be available at GitHub - if you see the new Initializer folder, then it is the patched version (search Silcos-Kernel to get it)!!!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot], Google [Bot] and 112 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group