Page 1 of 3
pitticks, the forbidden variable [solved]
Posted: Fri Aug 15, 2008 12:31 pm
by cr2
I haven't made much progress on OS-LUX (I am working on the PIT). My PIT driver does work, but when I increment pitticks (inside pit_irq), bochs GPFs. I have defined pitticks as an unsigned int. When I set, increment, and even access pitticks, the same error still pops up.
pitticks is defined as:
my PIT irq:
Code: Select all
void __declspec(naked) _cdecl pit_irq()
{
_asm cli
pitticks++;
_asm sti
_asm iretd
}
Yes, I am using MSVC++.
Any ideas on how to solve this?
Re: pitticks, the forbidden variable
Posted: Fri Aug 15, 2008 12:35 pm
by souradipm
Try declaring it as volatile. Also, are you sure it is not something else causing the GPF?
Re: pitticks, the forbidden variable
Posted: Fri Aug 15, 2008 2:16 pm
by cr2
souradipm wrote:Try declaring it as volatile. Also, are you sure it is not something else causing the GPF?
I tried declaring it volatile, and it didn't work. I also tried commenting out all the code that uses pitticks, and it worked.
Re: pitticks, the forbidden variable
Posted: Fri Aug 15, 2008 5:49 pm
by cr2
OK, I am using an object-oriented approach to the PIT, but I don't think that contributed to the problem.
Re: pitticks, the forbidden variable
Posted: Fri Aug 15, 2008 9:28 pm
by neon
What happens if you declare it static? Can you access it from other routines?
Also, can you post the bochs log?
Re: pitticks, the forbidden variable
Posted: Fri Aug 15, 2008 11:11 pm
by cr2
yep, tried declaring it static.
the log:
Code: Select all
00000000000i[MEM0 ] allocated memory at 011E0020. after alignment, vector=011E1000
00000000000i[MEM0 ] 4.00MB
00000000000i[MEM0 ] rom at 0xf0000/65536 ('BIOS-bochs-latest')
00000000000i[MEM0 ] rom at 0xc0000/27392 ('VGABIOS-lgpl-latest')
00000000000i[CMOS ] Setting initial clock to: Fri Aug 15 19:14:21 2008 (time0=1218845661)
00000000000i[DMA ] channel 4 used by cascade
00000000000i[DMA ] channel 2 used by Floppy Drive
00000000000i[FDD ] fd0: 'a:' ro=0, h=2,t=80,spt=18
00000000000i[VGA ] interval=30000
00000000000i[VGA ] VBE Bochs Display Extension Enabled
00000000000i[ ] init_mem of 'harddrv' plugin device by virtual method
00000000000i[ ] init_mem of 'keyboard' plugin device by virtual method
00000000000i[ ] init_mem of 'serial' plugin device by virtual method
00000000000i[ ] init_mem of 'parallel' plugin device by virtual method
00000000000i[ ] init_dev of 'harddrv' plugin device by virtual method
00000000000i[HD ] Boot device will be 'a'
00000000000i[HD ] Floppy boot signature check is enabled
00000000000i[ ] init_dev of 'keyboard' plugin device by virtual method
00000000000i[KBD ] will paste characters every 1000 keyboard ticks
00000000000i[ ] init_dev of 'serial' plugin device by virtual method
00000000000i[SER ] com1 at 0x3f8/8 irq 4
00000000000i[ ] init_dev of 'parallel' plugin device by virtual method
00000000000i[PAR ] parallel port 1 at 0x378
00000000000i[ ] reset of 'harddrv' plugin device by virtual method
00000000000i[ ] reset of 'keyboard' plugin device by virtual method
00000000000i[ ] reset of 'serial' plugin device by virtual method
00000000000i[ ] reset of 'parallel' plugin device by virtual method
00000003980i[BIOS ] rombios.c,v 1.85 2002/12/13 16:26:17 cbothamy Exp $
00000330071i[KBD ] reset-disable command received
00000353362i[VBIOS] VGABios $Id: vgabios.c,v 1.20 2002/10/20 15:12:33 vruppert Exp $
00000353593i[VGA ] VBE known Display Interface b0c1
00000353678i[VGA ] VBE known Display Interface b0c0
00000356623i[VBIOS] VBE Bios $Id: vbe.c,v 1.22 2002/09/19 17:03:21 cbothamy Exp $
00000356738i[VGA ] VBE known Display Interface b0c1
00000356822i[VGA ] VBE disabling
00000693499i[VGA ] VBE known Display Interface b0c1
00000781141e[HD ] device set to 0 which does not exist
00000781434e[HD ] device set to 1 which does not exist
00001007287e[CPU ] load_seg_reg: LDT invalid
00001007287p[CPU ] >>PANIC<< exception(): 3rd (13) exception with no resolution
00001007287i[SYS ] Last time is 1218845663
00001007287i[CPU ] protected mode
00001007287i[CPU ] CS.d_b = 32 bit
00001007287i[CPU ] SS.d_b = 32 bit
00001007287i[CPU ] | EAX=600001fe EBX=001000e4 ECX=00130004 EDX=00000ffe
00001007287i[CPU ] | ESP=0008fff8 EBP=00000010 ESI=000006ff EDI=00000200
00001007287i[CPU ] | IOPL=0 NV UP DI NG NZ AC PO CY
00001007287i[CPU ] | SEG selector base limit G D
00001007287i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00001007287i[CPU ] | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00001007287i[CPU ] | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
00001007287i[CPU ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00001007287i[CPU ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00001007287i[CPU ] | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00001007287i[CPU ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00001007287i[CPU ] | EIP=001001e8 (001001e8)
00001007287i[CPU ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00001007287i[CPU ] | CR3=0x00000000 CR4=0x00000000
00001007287i[ ] restoring default signal behavior
00001007287i[CTRL ] quit_sim called with exit code 1
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 12:22 am
by xyzzy
Have you disassembled the code produced to make sure that VC++ isn't putting anything unexpected in your function that could cause the iretd to fail? Also, does the EIP given by Bochs correspond exactly to the increment of pitticks? It'd probably be much wiser to write the entire function in ASM (or a wrapper for it) - for a start you're not pushing registers (I'm guessing this is the raw ISR function that's set in the IDT from the way it's written?), so the code generated by VC++ could be clobbering registers, and then returning to the previous function with incorrect registers.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 12:49 am
by cr2
I didn't track down the code that is listed by EIP, but I have tracked it down to pitticks++. I commented out the increment of pitticks, and it worked. But, I could be wrong here.
I put #pragma optimize("", off) and #pragma optimize("", on), and it still failed.
I also deleted the pitticks++, and replaced it with:
...and it fails.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 1:29 am
by Telgin
Ok, so what's different about this variable compared to any other you are using? Anything? I didn't see where you specified if it was a class member or anything special. Finding out what makes it different is going to be one step in the right direction to solve it.
Can you step through the assembly and see which instruction is throwing the exception? If even accessing it is causing the exception, then it sounds to me like something isn't configured right in the environment. Segment registers / selectors might be doing something funky that you don't realize, or there might be some stack corruption or something throwing the variable's address off and causing accesses and the like to modify incorrect memory addresses, which might be outside of the segment selector range or something.
Eh... sorry, that's about the best I can do. I haven't actually even got as far as paging or protected mode yet, so my actual experience with how these things works is rather limited.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 2:14 am
by xyzzy
Could you post a disassembly of the entire function?
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 9:38 am
by cr2
Telgin wrote:Ok, so what's different about this variable compared to any other you are using? Anything? I didn't see where you specified if it was a class member or anything special. Finding out what makes it different is going to be one step in the right direction to solve it.
I didn't add it as a class member (it
was(like my PIT IRQ) part of _pit, but I later removed it from the class to solve another error that came up). "pitticks" is not defined in a class, function, or struct. It is not referenced in a header file. It is not volatile or static. The only thing unusual about it is that it is completely usual.
Telgin wrote:Can you step through the assembly and see which instruction is throwing the exception? If even accessing it is causing the exception, then it sounds to me like something isn't configured right in the environment. Segment registers / selectors might be doing something funky that you don't realize, or there might be some stack corruption or something throwing the variable's address off and causing accesses and the like to modify incorrect memory addresses, which might be outside of the segment selector range or something.
I commented out the code that initializes the GDT in kmain, lemme see if it works when I uncomment it.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 9:42 am
by cr2
When I initialize the GDT it GPFs.
...and the function is still not working.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 10:46 am
by neon
I think we need to see the disassembly of the routine.
I tested your code in my MSVC kernel and it works fine: (A little modified)
Code: Select all
void __declspec(naked) _cdecl pit_irq()
{
_asm pushad
pitticks++;
interruptdone(0); // just sends EOI to the PIC
_asm popad
_asm iretd
}
The preserving of the stack seems needed (pushad/popad)--not doing so seems to cause problems.
*A slight nitpick: You can also take out the declspec(naked) and just add 12 to ESP at the beginning of the routine. It makes your code look nicer
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 11:27 am
by cr2
It still doesn't work.
New code:
Code: Select all
static volatile unsigned int pitticks = 0;
//////////////////////////////////////////////
// pit_irq() - //
// irq for the PIT //
//////////////////////////////////////////////
void __declspec(naked) _cdecl pit_irq()
{
_asm pushad
pitticks++;
outportb (0x20, 0x20);
_asm popad
_asm iretd
}
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 12:06 pm
by neon
Could you post a disassembly of the entire function?
With a direct copy+paste your new code works fine as well for me. /me thinks the problem is somewhere else.
Also, you should set GS and FS to 0x10--the same segment descriptor as your data desc.