Kernel size problem

If you are new to OS Development, plan on spending some time here first before going into the other forums.

Moderator: Moderators

Re: Kernel size problem

Postby Mike » Wed Jun 01, 2011 4:26 pm

Hello,

It might be helpful to provide the register dump and error information from the Bochs crash log.
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Re: Kernel size problem

Postby Insightsoft » Thu Jun 02, 2011 9:05 am

I can't get anything from here...
Code: Select all
(0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
<bochs:1> c
00000003305i[BIOS ] $Revision: 1.257 $ $Date: 2011/01/26 09:52:02 $
00000200000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000318042i[KBD  ] reset-disable command received
00000444800i[VBIOS] VGABios $Id: vgabios.c,v 1.69 2009/04/07 18:18:20 vruppert Exp $
00000444871i[CLVGA] VBE known Display Interface b0c0
00000444903i[CLVGA] VBE known Display Interface b0c5
00000447828i[VBIOS] VBE Bios $Id: vbe.c,v 1.62 2009/01/25 15:46:25 vruppert Exp $
00000760517i[BIOS ] Starting rombios32
00000761014i[BIOS ] Shutdown flag 0
00000761695i[BIOS ] ram_size=0x02000000
00000762173i[BIOS ] ram_end=32MB
00000802745i[BIOS ] Found 1 cpu(s)
00000821732i[BIOS ] bios_table_addr: 0x000fb928 end=0x000fcc00
00000821835i[PCI  ] 440FX PMC write to PAM register 59 (TLB Flush)
00001149532i[PCI  ] 440FX PMC write to PAM register 59 (TLB Flush)
00001477460i[P2I  ] PCI IRQ routing: PIRQA# set to 0x0b
00001477481i[P2I  ] PCI IRQ routing: PIRQB# set to 0x09
00001477502i[P2I  ] PCI IRQ routing: PIRQC# set to 0x0b
00001477523i[P2I  ] PCI IRQ routing: PIRQD# set to 0x09
00001477533i[P2I  ] write: ELCR2 = 0x0a
00001478418i[BIOS ] PIIX3/PIIX4 init: elcr=00 0a
00001486376i[BIOS ] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 class=0x0600
00001488938i[BIOS ] PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 class=0x0601
00001491339i[BIOS ] PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 class=0x0101
00001491569i[PIDE ] new BM-DMA address: 0xc000
00001492273i[BIOS ] region 4: 0x0000c000
00001494583i[BIOS ] PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 class=0x0680
00001494821i[ACPI ] new irq line = 11
00001494835i[ACPI ] new irq line = 9
00001494865i[ACPI ] new PM base address: 0xb000
00001494879i[ACPI ] new SM base address: 0xb100
00001494907i[PCI  ] setting SMRAM control register to 0x4a
00001659001i[CPU0 ] Enter to System Management Mode
00001659011i[CPU0 ] RSM: Resuming from System Management Mode
00001823031i[PCI  ] setting SMRAM control register to 0x0a
00001832202i[BIOS ] MP table addr=0x000fba00 MPC table addr=0x000fb930 size=0xd0
00001834261i[BIOS ] SMBIOS table addr=0x000fba10
00001836649i[BIOS ] ACPI tables: RSDP addr=0x000fbb30 ACPI DATA addr=0x01ff0000 size=0x988
00001839887i[BIOS ] Firmware waking vector 0x1ff00cc
00001851000i[PCI  ] 440FX PMC write to PAM register 59 (TLB Flush)
00001851844i[BIOS ] bios_table_cur_addr: 0x000fbb54
00014041548i[BIOS ] Booting from 0000:7c00
00070321812e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0e)
00070321812e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00070321812i[CPU0 ] CPU is in protected mode (active)
00070321812i[CPU0 ] CS.d_b = 32 bit
00070321812i[CPU0 ] SS.d_b = 32 bit
00070321812i[CPU0 ] EFER   = 0x00000000
00070321812i[CPU0 ] | RAX=000000000600e20a  RBX=0000000000000000
00070321812i[CPU0 ] | RCX=00000000c000c448  RDX=000000000000007a
00070321812i[CPU0 ] | RSP=0000000000008fec  RBP=00000000c00035c0
00070321812i[CPU0 ] | RSI=00000000c0009c24  RDI=0000000000090934
00070321812i[CPU0 ] |  R8=0000000000000000   R9=0000000000000000
00070321812i[CPU0 ] | R10=0000000000000000  R11=0000000000000000
00070321812i[CPU0 ] | R12=0000000000000000  R13=0000000000000000
00070321812i[CPU0 ] | R14=0000000000000000  R15=0000000000000000
00070321812i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00070321812i[CPU0 ] | SEG selector     base    limit G D
00070321812i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00070321812i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00070321812i[CPU0 ] |  DS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00070321812i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00070321812i[CPU0 ] |  ES:0000( 0000| 0|  0) 00000000 00000000 0 0
00070321812i[CPU0 ] |  FS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00070321812i[CPU0 ] |  GS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00070321812i[CPU0 ] |  MSR_FS_BASE:0000000000000000
00070321812i[CPU0 ] |  MSR_GS_BASE:0000000000000000
00070321812i[CPU0 ] | RIP=00000000c0005ff7 (00000000c0005ff7)
00070321812i[CPU0 ] | CR0=0xe0000011 CR2=0x000000000600e20a
00070321812i[CPU0 ] | CR3=0x0009c000 CR4=0x00000000

(0).[70321812] [0x0000000000105ff7] 0008:00000000c0005ff7 (unk. ctxt): add byte ptr ds:[eax], dl ; 0010

00070321812e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
00070321812i[SYS  ] bx_pc_system_c::Reset(HARDWARE) called
00070321812i[CPU0 ] cpu hardware reset
00070321812i[APIC0] allocate APIC id=0 (MMIO enabled) to 0x00000000fee00000
00070321812i[CPU0 ] CPUID[0x00000000]: 00000003 756e6547 6c65746e 49656e69
00070321812i[CPU0 ] CPUID[0x00000001]: 00000f23 00000800 00002000 07cbfbff
00070321812i[CPU0 ] CPUID[0x00000002]: 00410601 00000000 00000000 00000000
00070321812i[CPU0 ] CPUID[0x00000003]: 00000000 00000000 00000000 00000000
00070321812i[CPU0 ] CPUID[0x00000004]: 00000000 00000000 00000000 00000000
00070321812i[CPU0 ] CPUID[0x00000007]: 00000000 00000000 00000000 00000000
00070321812i[CPU0 ] CPUID[0x80000000]: 80000008 00000000 00000000 00000000
00070321812i[CPU0 ] CPUID[0x80000001]: 00000000 00000000 00000001 2a100800
00070321812i[CPU0 ] CPUID[0x80000002]: 20202020 20202020 20202020 6e492020
00070321812i[CPU0 ] CPUID[0x80000003]: 286c6574 50202952 69746e65 52286d75
00070321812i[CPU0 ] CPUID[0x80000004]: 20342029 20555043 20202020 00202020
00070321812i[CPU0 ] CPUID[0x80000006]: 00000000 42004200 02008140 00000000
00070321812i[CPU0 ] CPUID[0x80000007]: 00000000 00000000 00000000 00000000
00070321812i[CPU0 ] CPUID[0x80000008]: 00003028 00000000 00000000 00000000
00070321812i[     ] reset of 'unmapped' plugin device by virtual method
00070321812i[     ] reset of 'biosdev' plugin device by virtual method
00070321812i[     ] reset of 'speaker' plugin device by virtual method
00070321812i[     ] reset of 'extfpuirq' plugin device by virtual method
00070321812i[     ] reset of 'gameport' plugin device by virtual method
00070321812i[     ] reset of 'iodebug' plugin device by virtual method
00070321812i[     ] reset of 'pci_ide' plugin device by virtual method
00070321812i[     ] reset of 'acpi' plugin device by virtual method
00070321812i[     ] reset of 'ioapic' plugin device by virtual method
00070321812i[     ] reset of 'keyboard' plugin device by virtual method
00070321812i[     ] reset of 'harddrv' plugin device by virtual method
00070321812i[     ] reset of 'serial' plugin device by virtual method
00070321812i[     ] reset of 'parallel' plugin device by virtual method
Next at t=70321813
(0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
<bochs:2>
_____________
Think it, build it, bit by bit...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: Kernel size problem

Postby Andyhhp » Thu Jun 02, 2011 9:18 am

I dont know if it is related to your crash, but you really should sort out
00070321812e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0e)
00070321812e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
Image
Andyhhp
Moderator
 
Posts: 387
Joined: Tue Oct 23, 2007 10:05 am
Location: 127.0.0.1

Re: Kernel size problem

Postby Insightsoft » Thu Jun 02, 2011 8:26 pm

There is no such implementation!
this randon behaviour come out with simple inclusion of a simple function (any kind)???
If you reduce the code, it works.... if add a simple function, for example, to print one byte on screen...
Code: Select all
void printA()
{
    _mov es:[0xb8000], 'a'
}

its enough to make it crash...
_____________
Think it, build it, bit by bit...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: Kernel size problem

Postby Andyhhp » Sun Jun 05, 2011 10:52 pm

Which further supports the theory that you have one of your critical structures corrupted.

How big is your codebase?
Image
Andyhhp
Moderator
 
Posts: 387
Joined: Tue Oct 23, 2007 10:05 am
Location: 127.0.0.1

Re: Kernel size problem

Postby Mike » Mon Jun 06, 2011 6:39 am

Hello,

Notes to take from the log are the following:

-Stack is at 0x8fec;
-Page fault at 0x600e20a due to an instruction at 0xc0005ff7 linear, 0x105ff7 physical;
-PDBR at 0x9c000 physical

It does certainly look like corruption here. Because you can replicate the bug with ease and certainty (the inclusion of a function) you can use that as an advantage by using breakpoints and verifying the integrity of the in memory image and data structures and watching for changes.
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Re: Kernel size problem

Postby Insightsoft » Thu Jun 09, 2011 1:22 am

I found what seems to be the problem...

Here is the instruction line:

this one works fine: small kernel
Code: Select all
(0) [0x0000000000103e29] 0008:00000000c0003e29 (unk. ctxt): mov dword ptr ds:0xc000d140, 0x00005000 ; c70540d100c000500000


this one don't works: bigger kernel
Code: Select all
(0) [0x0000000000105fd9] 0008:00000000c0005fd9 (unk. ctxt): mov dword ptr ds:0xf00ba40, 0x000a6f00 ; c70540ba000f006f0a00      


This two lines correspond to the same c++ instruction:
Code: Select all
InitializeConstructors()
     _atexit_uint32_t()
             pf_atexitlist = (_PVFV *)0x5000;                       (here)

I noticed that the offset, based on DS segment, gets wrong as kernel's size increase...
ds:0xf00ba40 wrong
ds:0xc000d140 correct

It happens at very early stages... even before any other functions invocation...

Now I'm trying to figure out why...
_____________
Think it, build it, bit by bit...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: Kernel size problem

Postby Insightsoft » Tue Jun 14, 2011 6:44 pm

Is there any clue to this problem? This is driving me crazy...
_____________
Think it, build it, bit by bit...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: Kernel size problem

Postby Mike » Wed Jun 15, 2011 12:16 am

Hello,

The instruction mov dword ptr ds:0xf00ba40, 0x000a6f00 appears to contain two invalid values when compared to the other instruction... the offset displacement and immediate value.

Have the compiler (not Bochs debugger) output a disassembly of that function to check what that instruction is supposed to be. Do this for both kernel sizes (when it works and when it crashes) and compare. Post results here please -- code is preferred if you could point out the faulting instruction that causes the crash.

It should also be noted to be very cautious with the pf_atexitlist = (_PVFV *)0x5000; line. This was done in the series OS for simplicity only (and due to it being introduced prior to a mm); it is highly recommended to allocate memory dynamically or properly reserve a region for it.
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Previous

Return to Beginning OS Development

Who is online

Users browsing this forum: No registered users and 1 guest