qemu keeps restarting after grub menu

[leledumbo]

I just start continuing my kernel, but suddenly qemu keeps restarting after choosing from grub menu. I try removing one of the object files and now it boots, but the multiboot header doesn't match. I've put my asm entry point as the first object file to ld, so other than this, is there any explanation why it happens?

[-m32]

I'm sure the reason is in the following list:

• Power Surge
  Gremlins
  Broken Code
  Chuck Norris

Seriously though, we're going to need a lot more information than a vague description that doesn't tell us anything at all. There are innumerable reasons for rebooting like that.

[gravaera]

I'm sure the reason is in the following list:

• Power Surge
  Gremlins
  Broken Code
  Chuck Norris

Nice one. I laughed for while at that.

[gedd]

In general, a GPF due to broken code, a jump aniwhere but not in your code , ...
Try Bochs to have details and debug

[leledumbo]

Here's what I got with Bochs 2.4.1:

00000000000i[ ] Bochs x86 Emulator 2.4.1
00000000000i[ ] Build from CVS snapshot on June 7, 2009
00000000000i[ ] System configuration
00000000000i[ ] processors: 1 (cores=1, HT threads=1)
00000000000i[ ] A20 line support: yes
00000000000i[ ] CPU configuration
00000000000i[ ] level: 6
00000000000i[ ] SMP support: no
00000000000i[ ] APIC support: yes
00000000000i[ ] FPU support: yes
00000000000i[ ] MMX support: yes
00000000000i[ ] SSE support: 2
00000000000i[ ] CLFLUSH support: yes
00000000000i[ ] VME support: yes
00000000000i[ ] 3dnow! support: no
00000000000i[ ] PAE support: yes
00000000000i[ ] PGE support: yes
00000000000i[ ] PSE support: yes
00000000000i[ ] 1G paging support: no
00000000000i[ ] x86-64 support: yes
00000000000i[ ] SEP support: yes
00000000000i[ ] MWAIT support: no
00000000000i[ ] XSAVE support: no
00000000000i[ ] AES support: no
00000000000i[ ] VMX support: no
00000000000i[ ] Optimization configuration
00000000000i[ ] RepeatSpeedups support: yes
00000000000i[ ] Trace cache support: yes
00000000000i[ ] Fast function calls: yes
00000000000i[ ] Devices configuration
00000000000i[ ] ACPI support: yes
00000000000i[ ] NE2000 support: yes
00000000000i[ ] PCI support: yes
00000000000i[ ] SB16 support: yes
00000000000i[ ] USB support: yes
00000000000i[ ] VGA extension support: vbe cirrus
00000000000i[MEM0 ] allocated memory at 01DE0020. after alignment, vector=01DE1000
00000000000i[MEM0 ] 128,00MB
00000000000i[MEM0 ] rom at 0xfffe0000/131072 ('C:\Bochs\BIOS-bochs-latest')
00000000000i[MEM0 ] rom at 0xc0000/40448 ('C:\Bochs\VGABIOS-lgpl-latest')
00000000000i[VTIME] using 'realtime pit' synchronization method
00000000000i[CMOS ] Using local time for initial clock
00000000000i[CMOS ] Setting initial clock to: Tue Jul 28 18:26:34 2009 (time0=1248780394)
00000000000i[DMA ] channel 4 used by cascade
00000000000i[DMA ] channel 2 used by Floppy Drive
00000000000i[PCI ] 440FX Host bridge present at device 0, function 0
00000000000i[PCI ] PIIX3 PCI-to-ISA bridge present at device 1, function 0
00000000000i[MEM0 ] Register memory access handlers: 0x000a0000 - 0x000bffff
00000000000i[WGUI ] Desktop Window dimensions: 1024 x 768
00000000000i[WGUI ] Number of Mouse Buttons = 3
00000000000i[WGUI ] IME disabled
00000000000i[MEM0 ] Register memory access handlers: 0xe0000000 - 0xe0ffffff
00000000000i[CLVGA] VBE Bochs Display Extension Enabled
00000000000i[CLVGA] interval=50000
00000000000i[ ] init_dev of 'unmapped' plugin device by virtual method
00000000000i[ ] init_dev of 'biosdev' plugin device by virtual method
00000000000i[ ] init_dev of 'speaker' plugin device by virtual method
00000000000i[ ] init_dev of 'extfpuirq' plugin device by virtual method
00000000000i[ ] init_dev of 'gameport' plugin device by virtual method
00000000000i[ ] init_dev of 'pci_ide' plugin device by virtual method
00000000000i[PCI ] PIIX3 PCI IDE controller present at device 1, function 1
00000000000i[ ] init_dev of 'acpi' plugin device by virtual method
00000000000i[PCI ] ACPI Controller present at device 1, function 3
00000000000i[ ] init_dev of 'ioapic' plugin device by virtual method
00000000000i[IOAP ] initializing I/O APIC
00000000000i[MEM0 ] Register memory access handlers: 0xfec00000 - 0xfec00fff
00000000000i[ ] init_dev of 'keyboard' plugin device by virtual method
00000000000i[KBD ] will paste characters every 1000 keyboard ticks
00000000000i[ ] init_dev of 'harddrv' plugin device by virtual method
00000000000i[HD ] CD on ata0-0: 'fpos.iso'
00000000000i[HD ] Media not present in CD-ROM drive
00000000000i[HD ] Using boot sequence cdrom, none, none
00000000000i[HD ] Floppy boot signature check is enabled
00000000000i[ ] init_dev of 'serial' plugin device by virtual method
00000000000i[SER ] com1 at 0x03f8 irq 4
00000000000i[ ] init_dev of 'parallel' plugin device by virtual method
00000000000i[PAR ] parallel port 1 at 0x0378 irq 7
00000000000i[ ] register state of 'unmapped' plugin device by virtual method
00000000000i[ ] register state of 'biosdev' plugin device by virtual method
00000000000i[ ] register state of 'speaker' plugin device by virtual method
00000000000i[ ] register state of 'extfpuirq' plugin device by virtual method
00000000000i[ ] register state of 'gameport' plugin device by virtual method
00000000000i[ ] register state of 'pci_ide' plugin device by virtual method
00000000000i[ ] register state of 'acpi' plugin device by virtual method
00000000000i[ ] register state of 'ioapic' plugin device by virtual method
00000000000i[ ] register state of 'keyboard' plugin device by virtual method
00000000000i[ ] register state of 'harddrv' plugin device by virtual method
00000000000i[ ] register state of 'serial' plugin device by virtual method
00000000000i[ ] register state of 'parallel' plugin device by virtual method
00000000000i[SYS ] bx_pc_system_c::Reset(HARDWARE) called
00000000000i[CPU0 ] cpu hardware reset
00000000000i[APIC0] allocate APIC id=0 (MMIO enabled) to 0xfee00000
00000000000i[ ] reset of 'unmapped' plugin device by virtual method
00000000000i[ ] reset of 'biosdev' plugin device by virtual method
00000000000i[ ] reset of 'speaker' plugin device by virtual method
00000000000i[ ] reset of 'extfpuirq' plugin device by virtual method
00000000000i[ ] reset of 'gameport' plugin device by virtual method
00000000000i[ ] reset of 'pci_ide' plugin device by virtual method
00000000000i[ ] reset of 'acpi' plugin device by virtual method
00000000000i[ ] reset of 'ioapic' plugin device by virtual method
00000000000i[ ] reset of 'keyboard' plugin device by virtual method
00000000000i[ ] reset of 'harddrv' plugin device by virtual method
00000000000i[ ] reset of 'serial' plugin device by virtual method
00000000000i[ ] reset of 'parallel' plugin device by virtual method
00000000000i[ ] set SIGINT handler to bx_debug_ctrlc_handler
00000003553i[BIOS ] $Revision: 1.231.2.1 $ $Date: 2009/06/07 07:49:09 $
00000025000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000316674i[KBD ] reset-disable command received
00000441684i[VBIOS] VGABios $Id: vgabios.c,v 1.69 2009/04/07 18:18:20 vruppert Exp $

00000441755i[CLVGA] VBE known Display Interface b0c0
00000441787i[CLVGA] VBE known Display Interface b0c5
00000444712i[VBIOS] VBE Bios $Id: vbe.c,v 1.62 2009/01/25 15:46:25 vruppert Exp $
00000754305i[BIOS ] Starting rombios32
00000754802i[BIOS ] Shutdown flag 0
00000755483i[BIOS ] ram_size=0x08000000
00000755988i[BIOS ] ram_end=128MB
00000862776i[BIOS ] Found 1 cpu(s)
00000881895i[BIOS ] bios_table_addr: 0x000fba88 end=0x000fcc00
00000882003i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush)
00001209700i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush)
00001537628i[P2I ] PCI IRQ routing: PIRQA# set to 0x0b
00001537649i[P2I ] PCI IRQ routing: PIRQB# set to 0x09
00001537670i[P2I ] PCI IRQ routing: PIRQC# set to 0x0b
00001537691i[P2I ] PCI IRQ routing: PIRQD# set to 0x09
00001537701i[P2I ] write: ELCR2 = 0x0a
00001538586i[BIOS ] PIIX3/PIIX4 init: elcr=00 0a
00001546544i[BIOS ] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 class=0x0600
00001549120i[BIOS ] PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 class=0x0601
00001551535i[BIOS ] PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 class=0x0101
00001551775i[PIDE ] new BM-DMA address: 0xc000
00001552479i[BIOS ] region 4: 0x0000c000
00001554793i[BIOS ] PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 class=0x0680
00001555045i[ACPI ] new irq line = 11
00001555059i[ACPI ] new irq line = 9
00001555089i[ACPI ] new PM base address: 0xb000
00001555103i[ACPI ] new SM base address: 0xb100
00001555131i[PCI ] setting SMRAM control register to 0x4a
00001719225i[CPU0 ] Enter to System Management Mode
00001719235i[CPU0 ] RSM: Resuming from System Management Mode
00001883255i[PCI ] setting SMRAM control register to 0x0a
00001892424i[BIOS ] MP table addr=0x000fbb60 MPC table addr=0x000fba90 size=0xd0
00001894366i[BIOS ] SMBIOS table addr=0x000fbb70
00001896750i[BIOS ] ACPI tables: RSDP addr=0x000fbc80 ACPI DATA addr=0x07ff0000 size=0x988
00001899989i[BIOS ] Firmware waking vector 0x7ff00cc
00001911102i[PCI ] 440FX PMC write to PAM register 59 (TLB Flush)
00001911946i[BIOS ] bios_table_cur_addr: 0x000fbca4
00005794232i[BIOS ] IDE time out
00011713506e[HD ] ata0-0: atapi_cmd_error: key=02 asc=3a
00011716684i[BIOS ] ata_is_ready returned 1
00011717282e[HD ] ata0-0: atapi_cmd_error: key=02 asc=3a
00011741299i[BIOS ] CDROM boot failure code : 0003
00011797491p[BIOS ] >>PANIC<< No bootable device.

And there's a weird thing. If the debugging symbols included, then (sometimes, usually at 2nd try) it can boot, but with error because of the the magic number returned by grub is 0x2BADB0FF instead of 0x2BADB002 (remote debugging result using qemu and gdb). Something must have overwritten the last byte...

Could any of you please try the ISO (debugging symbols included. If required, the source is also available)?
ISO: http://fpos.googlecode.com/files/fpos-iso.zip
Src: http://fpos.googlecode.com/files/fpos-src.zip

[manonthemoon]

First of all, posting the entire Bochs log is a little unnecessary. All you had to do is post the relevant error message:

00000000000i[HD ] CD on ata0-0: 'fpos.iso'
00000000000i[HD ] Media not present in CD-ROM drive
00000000000i[HD ] Using boot sequence cdrom, none, none
...
00011713506e[HD ] ata0-0: atapi_cmd_error: key=02 asc=3a
00011716684i[BIOS ] ata_is_ready returned 1
00011717282e[HD ] ata0-0: atapi_cmd_error: key=02 asc=3a
00011741299i[BIOS ] CDROM boot failure code : 0003
00011797491p[BIOS ] >>PANIC<< No bootable device.

That would have been enough. Did you read this log yourself? Did you look up the errors in the Bochs documentation?

See: http://bochs.sourceforge.net/doc/docboo ... -tips.html

For this error, the cdrom support has not been compiled in Bochs, or Bochs could not open the file or device. This is what you get if Bochs is not able to read the cd.

So your Bochs config file is wrong, or the ISO image is bad, or (unlikely) Bochs wasn't compiled with cdrom support.

In fact, I just got your ISO image to boot in Bochs, but it immediately restarts with an error about multiboot (it flashes too fast to read).

So I'm guessing there is a problem with your kernel or the way you compile/link your kernel. You should carefully check the things you do to get your kernel compiled. If necessary, try making a floppy image instead of CD to see if the problem is in your kernel or in your disc image. The problem with the 0x2BADB002 is most likely something in your kernel's boot code.

[leledumbo]

In fact, I just got your ISO image to boot in Bochs, but it immediately restarts with an error about multiboot (it flashes too fast to read).

I guess the error is in my config file then, perhaps I've changed it somehow. Could you please post your .bxrc? If I can boot from Bochs, I can debug from my boot code and watch registers from the beginning (I don't know why I can't do it from qemu + gdb, I can only start from the kernel entrypoint instead of boot code) .

[manonthemoon]

Could you please post your .bxrc?

I didn't use one. If you boot Bochs from a command line, you can manually set the options. Under "disk options" I set the first drive to load the ISO image as a CD-ROM, and then I set the boot order to CD-ROM first. Everything else was the default.

As far as the 0x2BADB002, I'm guessing your early boot code uses an opcode that alters EAX. But of course that's just my guess, I can't tell for sure.

If you really want a .bxrc, you should add:

Code: Select all

ata0-master: type=cdrom, path="<your image file>"

but that's not exactly what I did when I got it to run. If it still doesn't work, try not using a bxrc and just set the relevant options manually (like I did).

[-m32]

Your iso doesn't reboot in VirtualBox..

I see:
Booting FreePascal OS 0.01
732803327
732803074
ERROR: a multiboot-compliant boot loader is needed!

732803327 is the value sent to your kernel (which is 0x2BADBOFF), 732803074 is the expected value (0x2BADBOO2). In your startup code you have this:

Code: Select all

  mov  esp,KERNEL_STACK+KERNEL_STACKSIZE ; Create kernel stack
  mov  [MagicNumber],eax                 ; Multiboot magic number
  mov  [MultiBootInfo],ebx               ; Multiboot info
  call PASCALMAIN                        ; Call kernel entrypoint
  cli                                    ; Clear interrupts
  hlt                                    ; Halt machine

MagicNumber and MultiBootInfo are defined in kernel.pas:

Code: Select all

var
  MB: PMultiBootInfo; public name 'MultiBootInfo';
  MagicNumber: LongWord; public name 'MagicNumber';
begin

Alignment issue perhaps? I'm not at all familiar with how Pascal builds, but could MultiBootInfo and MagicNumber be overlapping? Maybe do a cmp on eax for the magic number before calling you kernel entry point?

[leledumbo]

Alignment issue perhaps? I'm not at all familiar with how Pascal builds, but could MultiBootInfo and MagicNumber be overlapping?

Not very sure, too. Perhaps there's a change in the compiler that I wasn't aware of. I'm a daily snapshot user of the compiler, so a code that works today might not tomorrow (or even a minute later ). I'll try asking the development team.

Maybe do a cmp on eax for the magic number before calling you kernel entry point?

Aha! You're a genius!

[leledumbo]

Found the bug, but I don't know how to fix. Here's a bochsdbg session that shows the change of eax:

<bochs:13> s
(0).[25892406] [0x0010000a] 0008:000000000010000a (unk. ctxt): push edx
; 52
Next at t=25892407
(0) [0x0010000b] 0008:000000000010000b (unk. ctxt): in al, 0xbc ;
e4bc
<bochs:14> r
rax: 0x00000000:2badb002 rcx: 0x00000000:00000000
rdx: 0x00000000:0010ff00 rbx: 0x00000000:00034820
rsp: 0x00000000:00067a78 rbp: 0x00000000:00067a9c
rsi: 0x00000000:00034995 rdi: 0x00000000:ffffffff
r8 : 0x00000000:00000000 r9 : 0x00000000:00000000
r10: 0x00000000:00000000 r11: 0x00000000:00000000
r12: 0x00000000:00000000 r13: 0x00000000:00000000
r14: 0x00000000:00000000 r15: 0x00000000:00000000
rip: 0x00000000:0010000b
eflags 0x00000297
id vip vif ac vm rf nt IOPL=0 of df IF tf SF zf AF PF CF
<bochs:15> s
(0).[25892407] [0x0010000b] 0008:000000000010000b (unk. ctxt): in al, 0xbc
; e4bc
Next at t=25892408
(0) [0x0010000d] 0008:000000000010000d (unk. ctxt): and cl, ah ;
20e1
<bochs:16> r
rax: 0x00000000:2badb0ff rcx: 0x00000000:00000000
rdx: 0x00000000:0010ff00 rbx: 0x00000000:00034820
rsp: 0x00000000:00067a78 rbp: 0x00000000:00067a9c
rsi: 0x00000000:00034995 rdi: 0x00000000:ffffffff
r8 : 0x00000000:00000000 r9 : 0x00000000:00000000
r10: 0x00000000:00000000 r11: 0x00000000:00000000
r12: 0x00000000:00000000 r13: 0x00000000:00000000
r14: 0x00000000:00000000 r15: 0x00000000:00000000
rip: 0x00000000:0010000d
eflags 0x00000297
id vip vif ac vm rf nt IOPL=0 of df IF tf SF zf AF PF CF

So, after executing instruction at address 0x10000b, the value of eax gets changed due to in instruction that uses al. Objdump-ing that part gives me this (relevant part only):

Code: Select all

prt0.asm:50
  100008:	fb                   	sti
  100009:	4f                   	dec    edi
  10000a:	52                   	push   edx
  10000b:	e4 bc                	in     al,0xbc

0010000c <Start>:
prt0.asm:66
  10000c:	bc 20 e1 12 00       	mov    esp,0x12e120
prt0.asm:67
  100011:	a3 24 e1 12 00       	mov    ds:0x12e124,eax

and looking at the corresponding source lines:

Code: Select all

30: ;
31: ; Multiboot header defines
32: ;
33: MULTIBOOT_HEADER_MAGIC          equ     0x1BADB002
34: MULTIBOOT_HEADER_FLAGS          equ     MULTIBOOT_MODULE_ALIGN | MULTIBOOT_MEMORY_MAP
35: MULTIBOOT_HEADER_CHECKSUM       equ     -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
36:
37: ;
38: ; Kernel stack size
39: ;
40: KERNEL_STACKSIZE                equ     0x4000
41:
42: section .text
43:
44: ;
45: ; Multiboot header
46: ;
47: align 4
48: dd MULTIBOOT_HEADER_MAGIC
49: dd MULTIBOOT_HEADER_FLAGS
50: dd MULTIBOOT_HEADER_CHECKSUM
51:
52: ;
53: ; Export entrypoint
54: ;
55: global Start

So, it happens on dd instruction? How come? I just upgrade my NASM (2.07) anyway and AFAIR the previous 2.05.01 works fine. 2.06rc12 also fails.

[-m32]

Well, given:

Code: Select all

MULTIBOOT_HEADER_MAGIC          equ     0x1BADB002
MULTIBOOT_HEADER_FLAGS          equ     MULTIBOOT_MODULE_ALIGN | MULTIBOOT_MEMORY_MAP
MULTIBOOT_HEADER_CHECKSUM       equ     -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)

and

Code: Select all

section .text
;
; Multiboot header
;
align 4
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd MULTIBOOT_HEADER_CHECKSUM

MULTIBOOT_MODULE_ALIGN | MULTIBOOT_MEMORY_MAP == 0x3
MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS == 0x1BADB005

Negated, that's 0xE4524FFB

Look familiar?

Code: Select all

prt0.asm:50
  100008:   fb                      sti
  100009:   4f                      dec    edi
  10000a:   52                      push   edx
  10000b:   e4 bc                   in     al,0xbc

My guess is because you have your multiboot header in the TEXT section before "start"...

[Combuster]

More likely, because you forgot to specify the entry point during linkage...

[leledumbo]

My guess is because you have your multiboot header in the TEXT section before "start"...

If not there, then where should I put it? Doesn't GRUB require it?

More likely, because you forgot to specify the entry point during linkage...

I believe no, because it boots correctly. It's just the multiboot header (while it's still in eax) gets modified by an instruction.

[Combuster]

More likely, because you forgot to specify the entry point during linkage...

I believe no, because it boots correctly. It's just the multiboot header (while it's still in eax) gets modified by an instruction.

It doesn't boot correctly. It executes random code, which happens to have you end up in main() and make it appear that it works. For the time being.