Page 1 of 1
Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 1:31 am
by pauldinhqd
In my OS project, the boot sequence is like this:
- the MBR (16 bit, of course) loads the kernel (which has the first half
of code in 16bit, and the second half in 64-bit code).
- after loading kernel, MBR passes the control to 16-bit kernel code
- 16bit kernel code switches to 64bit long mode and jumps to the 64bit section in kernel
My MBR is 512 bytes (no doubts)
My kernel 16bit code is also 512 bytes, kernel loaded to 7E00h,
so the 64bit section starts at 8000h
The fisrt few lines of the 64bit section in kernel is as follow (NASM):
Code: Select all
[bits 64]
;;
; Long mode entry point
; Memory address is 0:8000h here!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
;;
longmode: jmp longmode_start
;;
; 64-bit kernel data & subroutines used by this 64bit section of kernel
;;
%include "64bit/macros.asm"
%include "64bit/subs/system.asm"
%include "64bit/subs/text8025.asm"
%include "64bit/subs/keybrd.asm"
%include "64bit/subs/harddsk.asm"
times 4*1024 db 99h ;<--THIS IS WHAT MAKES TROUBLE
;;
; Main 64bit code of kernel, this is where kernel starts actually
;;
longmode_start: cli ;no IDT has been set up
call init_system ;init System Data Area (SDA)
...
The amount of 4*1024 bytes as seen in the code above is
just for testing.
The problem is, when I try to increase this amount of data
to 6KB or more, Bochs doesn't run as normal anymore,
it keeps restarting!
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 2:04 am
by xenos
This looks like a triple fault to me. What does bochs' log file tell you about the reason why it's restarting?
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 2:43 am
by turdus
It's quite possible that you load only a few sectors of your kernel, and with padding the code is not loaded into memory at all. Which leads to executing rubbish, which in turn causes Bochs to triple fault.
Start bochs debugger, and examine memory at 8000h to see if your full kernel (>6k) is there or only the first part of it.
Also, because of "call init_system" you should have a valid stack (check that in debugger too).
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 3:16 am
by pauldinhqd
XenOS wrote:This looks like a triple fault to me. What does bochs' log file tell you about the reason why it's restarting?
This is the Bochs output (the portion that Bochs writes out each time it resets):
Code: Select all
...
00256808715i[CPU0 ] cpu hardware reset
00256808715i[APIC0] allocate APIC id=0 (MMIO enabled) to 0x00000000fee00000
00256808715i[CPU0 ] CPUID[0x00000000]: 00000005 756e6547 6c65746e 49656e69
00256808715i[CPU0 ] CPUID[0x00000001]: 00000633 00010800 00002008 0fcbfbff
00256808715i[CPU0 ] CPUID[0x00000002]: 00410601 00000000 00000000 00000000
00256808715i[CPU0 ] CPUID[0x00000003]: 00000000 00000000 00000000 00000000
00256808715i[CPU0 ] CPUID[0x00000004]: 00000000 00000000 00000000 00000000
00256808715i[CPU0 ] CPUID[0x00000005]: 00000040 00000040 00000003 00000020
00256808715i[CPU0 ] CPUID[0x80000000]: 80000008 00000000 00000000 00000000
00256808715i[CPU0 ] CPUID[0x80000001]: 00000000 00000000 00000101 2a100000
00256808715i[CPU0 ] CPUID[0x80000002]: 20202020 20202020 20202020 6e492020
00256808715i[CPU0 ] CPUID[0x80000003]: 286c6574 50202952 69746e65 52286d75
00256808715i[CPU0 ] CPUID[0x80000004]: 20342029 20555043 20202020 00202020
00256808715i[CPU0 ] CPUID[0x80000005]: 01ff01ff 01ff01ff 40020140 40020140
00256808715i[CPU0 ] CPUID[0x80000006]: 00000000 42004200 02008140 00000000
00256808715i[CPU0 ] CPUID[0x80000007]: 00000000 00000000 00000000 00000000
00256808715i[CPU0 ] CPUID[0x80000008]: 00003028 00000000 00000000 00000000
00256808715i[ ] reset of 'acpi' plugin device by virtual method
00256808715i[ ] reset of 'unmapped' plugin device by virtual method
00256808715i[ ] reset of 'biosdev' plugin device by virtual method
00256808715i[ ] reset of 'speaker' plugin device by virtual method
00256808715i[ ] reset of 'extfpuirq' plugin device by virtual method
00256808715i[ ] reset of 'gameport' plugin device by virtual method
00256808715i[ ] reset of 'ioapic' plugin device by virtual method
00256808715i[ ] reset of 'keyboard' plugin device by virtual method
00256808715i[ ] reset of 'harddrv' plugin device by virtual method
00256808715i[ ] reset of 'pci_ide' plugin device by virtual method
00256808715i[ ] reset of 'serial' plugin device by virtual method
00256808715i[ ] reset of 'parallel' plugin device by virtual method
00256813565i[BIOS ] $Revision: 10789 $ $Date: 2011-11-24 17:03:51 +0100 (Do, 24. Nov 2011) $
00257133814i[KBD ] reset-disable command received
00257142074i[BIOS ] Starting rombios32
00257142521i[BIOS ] Shutdown flag 0
00257143131i[BIOS ] ram_size=0x02000000
00257143566i[BIOS ] ram_end=32MB
00257293118i[BIOS ] Found 1 cpu(s)
00257309372i[BIOS ] bios_table_addr: 0x000fbde8 end=0x000fcc00
00257309455i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush)
00257637155i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush)
00257965077i[P2I ] PCI IRQ routing: PIRQA# set to 0x0b
00257965105i[P2I ] PCI IRQ routing: PIRQB# set to 0x09
00257965126i[P2I ] PCI IRQ routing: PIRQC# set to 0x0b
00257965147i[P2I ] PCI IRQ routing: PIRQD# set to 0x09
00257965147i[P2I ] write: ELCR2 = 0x0a
00257965956i[BIOS ] PIIX3/PIIX4 init: elcr=00 0a
00257973663i[BIOS ] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 class=0x0600
00257975978i[BIOS ] PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 class=0x0601
00257978132i[BIOS ] PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 class=0x0101
00257979001i[BIOS ] region 4: 0x0000c000
00257981066i[BIOS ] PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 class=0x0680
00257981291i[ACPI ] new irq line = 11
00257981313i[ACPI ] new irq line = 9
00257981366i[PCI ] setting SMRAM control register to 0x4a
00258145486i[CPU0 ] Enter to System Management Mode
00258145490i[CPU0 ] RSM: Resuming from System Management Mode
00258309509i[PCI ] setting SMRAM control register to 0x0a
00258318273i[BIOS ] MP table addr=0x000fbec0 MPC table addr=0x000fbdf0 size=0xd0
00258320126i[BIOS ] SMBIOS table addr=0x000fbed0
00258322352i[BIOS ] ACPI tables: RSDP addr=0x000fbff0 ACPI DATA addr=0x01ff0000 size=0x988
00258325616i[BIOS ] Firmware waking vector 0x1ff00cc
00258326947i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush)
00258327706i[BIOS ] bios_table_cur_addr: 0x000fc014
00258455320i[VBIOS] VGABios $Id: vgabios.c,v 1.75 2011/10/15 14:07:21 vruppert Exp $
00258455390i[BXVGA] VBE known Display Interface b0c0
00258455422i[BXVGA] VBE known Display Interface b0c5
00258458348i[VBIOS] VBE Bios $Id: vbe.c,v 1.64 2011/07/19 18:25:05 vruppert Exp $
00258804173i[BIOS ] ata0-0: PCHS=16/2/63 translation=none LCHS=16/2/63
00262684979i[BIOS ] IDE time out
00307920100i[BIOS ] Booting from 0000:7c00
00308170459e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00308170459e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00308170459e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00308170459i[CPU0 ] CPU is in long mode (active)
00308170459i[CPU0 ] CS.mode = 64 bit
00308170459i[CPU0 ] SS.mode = 64 bit
00308170459i[CPU0 ] EFER = 0x00000500
00308170459i[CPU0 ] | RAX=0000000000000100 RBX=00000000e0000011
00308170459i[CPU0 ] | RCX=00000000c0000080 RDX=0000000000000000
00308170459i[CPU0 ] | RSP=0000000000007e00 RBP=0000000000007e03
00308170459i[CPU0 ] | RSI=00000000000e7c03 RDI=000000000000d000
00308170459i[CPU0 ] | R8=0000000000000000 R9=0000000000000000
00308170459i[CPU0 ] | R10=0000000000000000 R11=0000000000000000
00308170459i[CPU0 ] | R12=0000000000000000 R13=0000000000000000
00308170459i[CPU0 ] | R14=0000000000000000 R15=0000000000000000
00308170459i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df IF tf sf zf af PF cf
00308170459i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00308170459i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 00000000 0 0
00308170459i[CPU0 ] | DS:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00308170459i[CPU0 ] | SS:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00308170459i[CPU0 ] | ES:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00308170459i[CPU0 ] | FS:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00308170459i[CPU0 ] | GS:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00308170459i[CPU0 ] | MSR_FS_BASE:0000000000000000
00308170459i[CPU0 ] | MSR_GS_BASE:0000000000000000
00308170459i[CPU0 ] | RIP=000000000000b000 (000000000000b000)
00308170459i[CPU0 ] | CR0=0xe0000011 CR2=0x0000000000000000
00308170459i[CPU0 ] | CR3=0x0000a000 CR4=0x000000a0
00308170459i[CPU0 ] 0x000000000000b000>> (invalid) : 2F
00308170459e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
00308170459i[SYS ] bx_pc_system_c::Reset(HARDWARE) called
00308170459i[CPU0 ] cpu hardware reset
...
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 3:24 am
by pauldinhqd
turdus wrote:It's quite possible that you load only a few sectors of your kernel, and with padding the code is not loaded into memory at all. Which leads to executing rubbish, which in turn causes Bochs to triple fault.
Start bochs debugger, and examine memory at 8000h to see if your full kernel (>6k) is there or only the first part of it.
Also, because of "call init_system" you should have a valid stack (check that in debugger too).
The total number of sectors loaded from disk is 255 (which is around 128KB), so the whole kernel code is loaded for sure.
(however, i will debug to check whether it is really so)
When this 64bit code (at 0:8000h) is executed, the stack is set at 0:7E00h, meaning it overlaps MBR code in memory
but the MBR is no longer used at this stage. (the stack goes from 7E00h down, the most number of bytes ever pushed
in stack is by PUSHAQ (a macro to push only 15 general purpose registers into stack))
Is there any debugger for Bochs with GUI
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 4:01 am
by stlw
pauldinhqd wrote:XenOS wrote:This looks like a triple fault to me. What does bochs' log file tell you about the reason why it's restarting?
This is the Bochs output (the portion from beginning of output file to first hardware reset):
Who needs the first hardware reset (which happens even before first instruction was executed) ?
You have to learn reading that file and understand what useful information you can get from it, otherwise nobody will be able to help you ever.
Stanislav
P.S> You need last reset, not the first one.
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 4:33 am
by Solar
pauldinhqd wrote:Is there any debugger for Bochs with GUI
Yes.
(I got our own Wiki entry on
Bochs as hit #3, adding insult to injury.)
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 5:28 am
by pauldinhqd
Solar wrote:pauldinhqd wrote:Is there any debugger for Bochs with GUI
Yes.
(I got our own Wiki entry on
Bochs as hit #3, adding insult to injury.)
tks, i find the bochs internal debugger very useful
Re: Strange behaviour of Bochs
Posted: Mon Apr 16, 2012 9:27 pm
by pauldinhqd
turdus wrote:It's quite possible that you load only a few sectors of your kernel, and with padding the code is not loaded into memory at all. Which leads to executing rubbish, which in turn causes Bochs to triple fault.
Start bochs debugger, and examine memory at 8000h to see if your full kernel (>6k) is there or only the first part of it.
Also, because of "call init_system" you should have a valid stack (check that in debugger too).
yes, turdus,
i seem to have found out the reason,
in my MBR, i use bios INT 13h, function 42h (extended read) to read my kernel.
strangely, this function of Bochs BIOS reads only 12KB,
i dont know why it is limited to this value,
or am i wrong about this thing of Bochs BIOS?
Re: Strange behaviour of Bochs
Posted: Tue Apr 17, 2012 4:42 am
by Yoda
pauldinhqd wrote:in my MBR, i use bios INT 13h, function 42h (extended read) to read my kernel.
strangely, this function of Bochs BIOS reads only 12KB
Most BIOSes read sectors (if given the sector count other than 1) only up to the end of the current track. So try to avoid multiple sectors read and organize loop with counter. The actual number of sectors read will depend on drive geometry and BIOS implementation.
Re: Strange behaviour of Bochs
Posted: Tue Apr 17, 2012 5:08 am
by Rudster816
Your DS\ES\FS\GS segments are 0, so they are not a valid long mode entry (entry 0 MUST be a NULL descriptor). Any data access that relies on these segments (all but stack operations) will cause a segmentation fault, and a triple fault without an IDT\Interrupt handlers.
Re: Strange behaviour of Bochs
Posted: Fri Apr 20, 2012 12:42 am
by pauldinhqd
Yoda wrote:pauldinhqd wrote:in my MBR, i use bios INT 13h, function 42h (extended read) to read my kernel.
strangely, this function of Bochs BIOS reads only 12KB
Most BIOSes read sectors (if given the sector count other than 1) only up to the end of the current track. So try to avoid multiple sectors read and organize loop with counter. The actual number of sectors read will depend on drive geometry and BIOS implementation.
Yoda is true
,
when i changed to read the kernel to memory sector by sector
then things work as normal
(included that i had to change the code which switch to long mode a bit.
this code
http://wiki.osdev.org/Entering_Long_Mode_Directly
puts the PML4 at 0x9000, i didn't notice that it overlapped my kernel code)