problems with the IDT and interrupts

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

problems with the IDT and interrupts

Post by bsunisol »

hi,
bochs says my idt is not valid when int 13 is called.
but i didn't do that and ints are deactivated.
i didn't filled the idt with asm in real mode yet. i want
to do that in my osloader with c++ 'cause the idt is
located at 0x110000.
the gdt and idt registers are set correctly.

does anyone know what could call int 13?
00016065912-e-@00007c54-[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00016065912-e-@00007c52-[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00016065912-e-@00007c52-[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00016065912-i-@00007c52-[CPU0 ] protected mode
00016065912-i-@00007c52-[CPU0 ] CS.d_b = 32 bit
00016065912-i-@00007c52-[CPU0 ] SS.d_b = 32 bit
00016065912-i-@00007c52-[CPU0 ] | EAX=d08e9000 EBX=00008003 ECX=00000004 EDX=00000001
00016065912-i-@00007c52-[CPU0 ] | ESP=c6f6ffff EBP=00000000 ESI=0000803c EDI=00000010
00016065912-i-@00007c52-[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00016065912-i-@00007c52-[CPU0 ] | SEG selector base limit G D
00016065912-i-@00007c52-[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00016065912-i-@00007c52-[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00016065912-i-@00007c52-[CPU0 ] | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00016065912-i-@00007c52-[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00016065912-i-@00007c52-[CPU0 ] | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
00016065912-i-@00007c52-[CPU0 ] | FS:0000( 0000| 0| 0) 000ffff0 0000ffff 0 0
00016065912-i-@00007c52-[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00016065912-i-@00007c52-[CPU0 ] | EIP=00007c52 (00007c52)
00016065912-i-@00007c52-[CPU0 ] | CR0=0x00000011 CR1=0 CR2=0x00000000
00016065912-i-@00007c52-[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00016065912-i-@00007c52-[CPU0 ] >> int 0x13 : CD13
00016065912-e-@00007c52-[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
Top
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

If you are trying to call "INT 0x13" to access BIOS, then you must realize you can't do that in protected mode. You either return to real-mode for that, use a VM86-monitor (which you have to implement) or just implement the functionality yourself with direct I/O to the relevant devices. Usually you'd implement stuff yourself.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Top
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

Post by bsunisol »

i did not call the interrupt!
Top
urxae
Member
Member
Posts: 149
Joined: Sun Jul 30, 2006 8:16 am
Location: The Netherlands

Re: problems with the IDT and interrupts

Post by urxae »

bsunisol wrote:hi,
bochs says my idt is not valid when int 13 is called.
but i didn't do that and ints are deactivated.
[snip]
does anyone know what could call int 13?
00016065912-i-@00007c52-[CPU0 ] protected mode
[snip]
00016065912-i-@00007c52-[CPU0 ] | EIP=00007c52 (00007c52)
Judging by the address it's called from, it looks like your bootsector tries to call it. Since protected mode is enabled, that's not going to work.


(Posted while I was typing:)
bsunisol wrote:i did not call the interrupt!
Any chance you could post your bootsector? (preferably source, not binary)
Top
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

Post by bsunisol »

yes of course.
Attachments
bootloader.asm
bootloader
(6.57 KiB) Downloaded 93 times
Top
urxae
Member
Member
Posts: 149
Joined: Sun Jul 30, 2006 8:16 am
Location: The Netherlands

Post by urxae »

Well, I can see two calls to int 13h in that code, but I can't see where you enable protected mode. Is this done in a second stage loaded from disk?
Anyway, judging by the address it looks like the first int 13h call is the one where it crashes. You should check that you never (accidentally?) call or jump to the JUMP or CODE_SECTION label (or any other address in 0x7C00 - 0x7C52) after enabling protected mode.

If you can't find it yourself, you should post some more code...
Top
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

Post by bsunisol »

no the pmode is set later.
and i never jump back to the bootloader.
Attachments
OSLDR16.asm
setting up the pmode
(4.22 KiB) Downloaded 90 times
OSLDR32.asm
jumping to c++
(4.29 KiB) Downloaded 97 times
Top
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:
Contact Combuster

Post by Combuster »

What is the purpose of
[ORG 0x0500]
in the bootloader? (shouldn't it be 0x7c00)

Btw, the interrupt you are getting is most likely an exception. a GPF to be precise.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Top
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

Post by bsunisol »

the bootloader is org 0x7c00

the order is:

(1) Bootloader @0x7C00
(2) OSLDR16 @0x0500 *
(3) OSLDR32 @0x0700 *
(4) OSLDRC @0x0834 *

* all in one file: OSLDR
Top
urxae
Member
Member
Posts: 149
Joined: Sun Jul 30, 2006 8:16 am
Location: The Netherlands

Post by urxae »

Combuster wrote:What is the purpose of
[ORG 0x0500]
in the bootloader? (shouldn't it be 0x7c00)
His bootsector (bootloader.asm) was attached to a previous post. It has [ORG 0x7c00]. The file with [ORG 0x0500]
(OSLDR16.asm) seems to be setup code for his kernel (A20, GDT, IDT, P-mode) and is hopefully linked & loaded right before OSLDR32.asm since the code runs off the end of the file.
Btw, the interrupt you are getting is most likely an exception. a GPF to be precise.
The interrupt he's getting is 0x13, not 13 (which would be GPF in P-mode). 0x13 == 19, which is "#XF—SIMD Floating-Point Exception" according to my AMD documentation.
Also, Bochs reports EIP as 0x7c52, which is right after the 'int 13h' in his bootloader. All that leads me to conclude that for some reason he's back in his boot code after enabling protected mode...

This could have lots of causes. To name a few: a corrupted stack (esp. return addresses), general memory corruption (vtables, code, function pointers), an error in (inline?) asm or (if multithreading is implemented) errors in the scheduler (task creation & switching)...
Note that Bochs makes it relatively easy to land back in the bootsector code. It initializes memory to zero, which of "add [eax],al"s in 32-bit mode. That's a non-jumping non-faulting instruction, so anything that causes EIP to be between the kernel and the bootcode would get him to the bootsector.
(That's a 2-byte instruction, but an unaligned address just means that the data at the start is executed. Since it disassembles to similar harmless instructions and the instruction boundaries synchronize before the 'int 13h', that still gets executed)
Top
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

Post by bsunisol »

i've looked for jmp or other instructions in the code.
but there was nothing.

i can post my list files from the compiler. but i don't
think that it will be helpfull 'cause it's very hard to
read it......
Top
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:
Contact Kevin McGuire

Post by Kevin McGuire »

You need to reduce you're problem to something much simpler. It is my opinion that you have made the problem extremely complex and we are unable to help you any better than you can help you're self.
Volume is not precision

You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that is breaking a program, try to trim it and make it as small as possible.

This is useful for at least three reasons. One: being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround yourself.
You need to break everything down, and verify what parts make it where. You need to completely check the OSLDR16.ASM. Then check the OSLDR32.ASM. Then check what ever other complex modules you have loaded into memory one at a time.

Use bochs in debugging mode. Insert hlt and nop instructions to stop the execution and disable interrupts where you can press ctrl+c, and verify things are correct by examining memory and registers. Then step through until you find the fault. If not move the hlt and nop further along the program flow until you either miss the fault or find it by stepping again with the bochs's debugger.

You can even print a character in the upper left corner of the screen for each point in the program you pass to let you know the fault is not here, or bug if you wish to call it instead of fault.

And believe me I know exactly how you feel. I am just trying to help you understand that you are the ultimate problem solver at large test cases since you have the environment and tools already positioned for doing exactly what we would do to find the bug. We can only help most efficiently with smaller test cases and in extremely large conceptual things.

(test cases)[small]<--------------------------------->[large](conceptual cases)
Top
User avatar
bsunisol
Member
Member
Posts: 40
Joined: Fri Apr 06, 2007 3:00 pm
Location: Germany, Berlin and near Hamburg

Post by bsunisol »

i've found the problem......

it's in OSLDR32.asm.

Code: Select all

start:	call	__support_start
jumps to an incorrect adress. but why? the adresses
are managed by the linker. is the order of the input
files relevant? could that be the reason?
Attachments
link.txt
my linkerscript
(943 Bytes) Downloaded 160 times
Top
Post Reply

Return to “OS Development”