Page 1 of 1
problems with the IDT and interrupts
Posted: Sun Apr 08, 2007 7:33 am
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
Posted: Sun Apr 08, 2007 7:40 am
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.
Posted: Sun Apr 08, 2007 7:49 am
by bsunisol
i did not call the interrupt!
Re: problems with the IDT and interrupts
Posted: Sun Apr 08, 2007 7:57 am
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)
Posted: Sun Apr 08, 2007 8:00 am
by bsunisol
yes of course.
Posted: Sun Apr 08, 2007 9:24 am
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...
Posted: Sun Apr 08, 2007 10:29 am
by bsunisol
no the pmode is set later.
and i never jump back to the bootloader.
Posted: Sun Apr 08, 2007 11:51 am
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.
Posted: Sun Apr 08, 2007 12:06 pm
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
Posted: Sun Apr 08, 2007 12:43 pm
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)
Posted: Sun Apr 08, 2007 12:59 pm
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......
Posted: Sun Apr 08, 2007 1:12 pm
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)
Posted: Sun Apr 08, 2007 1:38 pm
by bsunisol
i've found the problem......
it's in OSLDR32.asm.
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?