Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Descriptor Overflow #13

Open
vmlemon opened this issue May 3, 2014 · 15 comments
Open

Memory Descriptor Overflow #13

vmlemon opened this issue May 3, 2014 · 15 comments

Comments

@vmlemon
Copy link

vmlemon commented May 3, 2014

Hi,

I've just built the latest Git revision under Ubuntu, including the userland, and I receive the following error, when attempting to run l4test under QEMU:

L4Ka::Pistachio - built on May  3 2014 16:59:50 by tyson@tyson-VirtualBox using gcc version 4.8.1
Checking CPU features
virtual memory layout:
    user area            0 - c0000000
    copy area     c4000000 - c4800000
    ktcb area     e0000000 - f0000000
    kernel area   df000000 - ff000000
    cpulocal data f0119000 - f030008c
    utcb pgarea   df000000
    space link    c5000000
Initializing kernel memory (f0307000-f0327000) [128K]
Initializing kernel space
    Switching to CPU local pagetable 00308000 (CPU 0)
CPU local pagetable activated 308000 (CPU 0)
Initializing TCBs
Activating TSS (Preliminary)
Initializing GDT (Preliminary)
Activating IDT (Preliminary)
Initializing kernel interface page (f0118000)
Adding more kernel memory
Initializing memory info
Memory descriptor overflow (max=204, n=204)

My kernel configuration file looks like:

#
# Automatically generated, don't edit
#
# Generated on: tyson-VirtualBox
# At: Sat, 03 May 2014 15:58:57 +0000
# Linux version 3.11.0-12-generic (buildd@komainu) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7) ) #19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
# CONFIG_ARCH_POWERPC is not set
# CONFIG_ARCH_POWERPC64 is not set


#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
# CONFIG_SUBARCH_X64 is not set


#
# Processor Type
#
# CONFIG_CPU_X86_I486 is not set
# CONFIG_CPU_X86_I586 is not set
CONFIG_CPU_X86_I686=y
# CONFIG_CPU_X86_P4 is not set
# CONFIG_CPU_X86_K8 is not set
# CONFIG_CPU_X86_C3 is not set
# CONFIG_CPU_X86_SIMICS is not set


#
# Platform
#
CONFIG_PLAT_PC99=y


#
# Miscellaneous
#
# CONFIG_IOAPIC is not set
CONFIG_MAX_IOAPICS=2
CONFIG_APIC_TIMER_TICK=1000

# CONFIG_SMP is not set


#
# Kernel
#
CONFIG_EXPERIMENTAL=y

#
# Experimental Features
#
CONFIG_X_PAGER_EXREGS=y
CONFIG_X_CTRLXFER_MSG=y
CONFIG_X_EVT_LOGGING=y

#
# Kernel scheduling policy
#
CONFIG_SCHED_RR=y
# CONFIG_X_SCHED_HS is not set


# CONFIG_IPC_FASTPATH is not set
CONFIG_DEBUG=y
# CONFIG_DEBUG_SYMBOLS is not set
# CONFIG_PERFMON is not set
CONFIG_SPIN_WHEELS=y
# CONFIG_NEW_MDB is not set
# CONFIG_STATIC_TCBS is not set
# CONFIG_X86_SMALL_SPACES is not set


#
# Debugger
#

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_COM=y
CONFIG_KDB_COMPORT=0x0
CONFIG_KDB_COMSPEED=115200
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_BOOT_CONS=0

# CONFIG_KDB_DISAS is not set
# CONFIG_KDB_ON_STARTUP is not set
# CONFIG_KDB_BREAKIN is not set
# CONFIG_KDB_INPUT_HLT is not set
# CONFIG_KDB_NO_ASSERTS is not set

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=y
# CONFIG_TRACEPOINTS is not set
# CONFIG_KMEM_TRACE is not set
# CONFIG_TRACEBUFFER is not set
# CONFIG_X86_KEEP_LAST_BRANCHES is not set



#
# Code Generator Options
#


#
# Derived symbols
#
# CONFIG_HAVE_MEMORY_CONTROL is not set
CONFIG_X86_PSE=y
# CONFIG_BIGENDIAN is not set
# CONFIG_PPC_MMU_TLB is not set
CONFIG_X86_SYSENTER=y
CONFIG_X86_PGE=y
CONFIG_X86_FXSR=y
CONFIG_IS_32BIT=y
# CONFIG_X86_HTT is not set
CONFIG_X86_PAT=y
# CONFIG_PPC_BOOKE is not set
# CONFIG_IS_64BIT is not set
# CONFIG_MULTI_ARCHITECTURE is not set
# CONFIG_X86_EM64T is not set
# CONFIG_PPC_CACHE_L1_WRITETHROUGH is not set
# CONFIG_PPC_TLB_INV_LOCAL is not set
# CONFIG_PPC_CACHE_ICBI_LOCAL is not set
# CONFIG_X86_SMALL_SPACES_GLOBAL is not set
# CONFIG_X86_HVM is not set
# CONFIG_PPC_MMU_SEGMENTS is not set
CONFIG_X86_TSC=y
#
# That's all, folks!

Please can someone enlighten me on what's going wrong?

@vmlemon
Copy link
Author

vmlemon commented May 3, 2014

PS - If it it helps, my GRUB2 configuration file looks like:

#http://docs.oracle.com/cd/E26502_01/html/E28983/gkvif.html#glwbd mentions modules

menuentry "OS Name" {
   insmod part_msdos
   insmod ext2
   set root='hd0,msdos1'

   multiboot /x86-kernel   # The multiboot command replaces the kernel command

   module /sigma0
   module /l4test

   boot
}

@vmlemon
Copy link
Author

vmlemon commented May 3, 2014

Having played some more, I noticed that I misconfigured the GRUB2 config, and set the L4 kernel as the multiboot image, instead of the kickstart.

Changing that resulted in:

KickStart 0.13.06
Detected multiboot compliant loader
 kernel    (0x00111000-0x0031f7af)   => 0x0032a0c0
  (0x00111000-0x001221c7) -> 0x00100000-0x001111c7
     Conflict with multiboot module 0 (0x00111000-0x0031f7af)
     Please choose a different link base
PANIC: FAIL in line 161

I guess that KickStart's incompatible with GRUB2, unless it's modified...

@jkehne
Copy link
Member

jkehne commented May 5, 2014

Looks like it's trying to relocate the kernel on itself. I don't think this is related to GRUB2, as my GRUB1 places the kernel image in the same general area of memory as your GRUB2. Here is what I think: Kickstart relocates each section of your kernel image to the addresses specified in the section header. That address is put there by your linker (the kernel image is really just an ELF file) and should be somewhere well out of the way (> 0x00600000 for me). The question is: How did your linker get the idea that the kernel image should be copied to 0x00100000? This looks like an error in the build system, possibly related to #11.
I'll let you know if I come up with a solution.

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

Thanks,

In the meantime, I noticed that booting using the GRUB 0.97 in the CD-ROM ISO from http://www.rdos.net/rdos/grub.iso works, and I can boot into my custom, basic root task (which is based on a modified version of grabmem, if I remember correctly).

If it helps, I've probably got some of the log files from attempts at building in my fork of the repository (in which I'm mostly just working on the userland, rather than the kernel itself); and I could put some binaries somewhere, for testing (if I can find some broken ones).

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

Also, since it took me forever to figure out, I'm pretty sure that the GRUB2 config file's supposed to look like:

menuentry "OS Name" {
   insmod part_msdos
   insmod ext2
   set root='hd0,msdos1'

   multiboot /kickstart   # The multiboot command replaces the kernel command

   module /x86-kernel
   module /sigma0
   module /l4test

   boot
}

Rather than the aborted attempt, above...

And obviously for GRUB 0.97:

title=L4Ka::Pistachio
root (hd0,0)
kernel=/kickstart
module=/x86-kernel
module=/sigma0
module=/l4test

@jkehne
Copy link
Member

jkehne commented May 5, 2014

Congratulations :) I find it strange though that GRUB2 is making such a difference. Could you post kickstart's output using GRUB 0.97? (The same you posted above for GRUB2, containing the "conflict with multiboot module"-error.) Maybe that will tell me what GRUB2 is doing differently.

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

Aah, sorry for not making things clearer, but if I use the config file above (with all of the experimental bells-and-whistles on), I get the errors when booting (with GRUB2), come to think of it.

That said, I haven't tested an image built that way using the earlier GRUB, yet - but I will do, and report back.

The configuration file that works for me using the 0.97 is:

#
# Automatically generated, don't edit
#
# Generated on: tyson-VirtualBox
# At: Sat, 03 May 2014 19:25:44 +0000
# Linux version 3.11.0-12-generic (buildd@komainu) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7) ) #19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013

#
# Pistachio Kernel Configuration System
#

#
# Hardware
#

#
# Basic Architecture
#
CONFIG_ARCH_X86=y
# CONFIG_ARCH_POWERPC is not set
# CONFIG_ARCH_POWERPC64 is not set


#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
# CONFIG_SUBARCH_X64 is not set


#
# Processor Type
#
# CONFIG_CPU_X86_I486 is not set
# CONFIG_CPU_X86_I586 is not set
CONFIG_CPU_X86_I686=y
# CONFIG_CPU_X86_P4 is not set
# CONFIG_CPU_X86_K8 is not set
# CONFIG_CPU_X86_C3 is not set
# CONFIG_CPU_X86_SIMICS is not set


#
# Platform
#
CONFIG_PLAT_PC99=y


#
# Miscellaneous
#
# CONFIG_IOAPIC is not set
CONFIG_MAX_IOAPICS=2
CONFIG_APIC_TIMER_TICK=1000

# CONFIG_SMP is not set


#
# Kernel
#
# CONFIG_EXPERIMENTAL is not set

#
# Experimental Features
#
# CONFIG_X_PAGER_EXREGS is not set
# CONFIG_X_CTRLXFER_MSG is not set
# CONFIG_X_EVT_LOGGING is not set

#
# Kernel scheduling policy
#
# CONFIG_SCHED_RR is not set
# CONFIG_X_SCHED_HS is not set


# CONFIG_IPC_FASTPATH is not set
CONFIG_DEBUG=y
# CONFIG_DEBUG_SYMBOLS is not set
# CONFIG_PERFMON is not set
CONFIG_SPIN_WHEELS=y
# CONFIG_NEW_MDB is not set
# CONFIG_STATIC_TCBS is not set
# CONFIG_X86_SMALL_SPACES is not set


#
# Debugger
#

#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_COM=y
CONFIG_KDB_COMPORT=0x0
CONFIG_KDB_COMSPEED=115200
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_BOOT_CONS=0

# CONFIG_KDB_DISAS is not set
# CONFIG_KDB_ON_STARTUP is not set
# CONFIG_KDB_BREAKIN is not set
# CONFIG_KDB_INPUT_HLT is not set
# CONFIG_KDB_NO_ASSERTS is not set

#
# Trace Settings
#
CONFIG_VERBOSE_INIT=y
# CONFIG_TRACEPOINTS is not set
# CONFIG_KMEM_TRACE is not set
# CONFIG_TRACEBUFFER is not set
# CONFIG_X86_KEEP_LAST_BRANCHES is not set



#
# Code Generator Options
#


#
# Derived symbols
#
# CONFIG_HAVE_MEMORY_CONTROL is not set
CONFIG_X86_PSE=y
# CONFIG_BIGENDIAN is not set
# CONFIG_PPC_MMU_TLB is not set
CONFIG_X86_SYSENTER=y
CONFIG_X86_PGE=y
CONFIG_X86_FXSR=y
CONFIG_IS_32BIT=y
# CONFIG_X86_HTT is not set
CONFIG_X86_PAT=y
# CONFIG_PPC_BOOKE is not set
# CONFIG_IS_64BIT is not set
# CONFIG_MULTI_ARCHITECTURE is not set
# CONFIG_X86_EM64T is not set
# CONFIG_PPC_CACHE_L1_WRITETHROUGH is not set
# CONFIG_PPC_TLB_INV_LOCAL is not set
# CONFIG_PPC_CACHE_ICBI_LOCAL is not set
# CONFIG_X86_SMALL_SPACES_GLOBAL is not set
# CONFIG_X86_HVM is not set
# CONFIG_PPC_MMU_SEGMENTS is not set
CONFIG_X86_TSC=y
#
# That's all, folks!

@jkehne
Copy link
Member

jkehne commented May 5, 2014

Alternatively, does the config file you just posted work with GRUB2?

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

That's a good question.

I'm just rebuilding my userland, and reassembling my HDD partition (currently working under Ubuntu installed in VMware Player, with an SCSI disk image for the OS, and an IDE one for Pistachio; and using the IDE image directly with QEMU...), so I'll let you know as soon as it's done.

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

If I boot using GRUB2 (exact version is 2.00-19ubuntu2), and specify my custom server (counter) as the root task, I get:

KickStart 0.13.06
Detected multiboot compliant loader
 kernel    (0x00111000-0x00155115)   => 0x0015d0c0
  (0x00111000-0x00123567) -> 0x00100000-0x00112567
     Conflict with multiboot module 0 (0x00111000-0x00155115)
     Please choose a different link base
PANIC: FAIL in line 161

If it helps, I've packaged all of the stuff from the root FS of my disk image, and committed it into an archive as part of vmlemon@2923651 (and I'll happily upload a raw, compressed disk image somewhere convenient, if necessary).

Not sure if it makes a difference, but my libio is slightly modified (mostly by the addition of some functions) from baseline.

For 0.97, I get a successful boot:

KickStart 0.13.06
Detected multiboot compliant loader
 kernel    (0x00819000-0x0085d115)   => 0x0015d0c0
  (0x00819000-0x0082b567) -> 0x00100000-0x00112567
  (0x0082c000-0x008327c2) -> 0x00114000-0x0011a7c2
  (0x00833000-0x00851d58) -> 0x0011b000-0x00139d58
  (0x00852000-0x00855c38) -> 0x0015a000-0x0015dc38
 sigma0    (0x0085e000-0x008793c3)   => 0x00020000
  (0x0085f000-0x00868524) -> 0x00020000-0x00029524
 roottask  (0x0087a000-0x0087ffc6)   => 0x0040000f
  (0x0087a080-0x0087d724) -> 0x00400000-0x004036a4
Launching kernel ...

L4Ka::Pistachio - built on May  3 2014 20:26:28 by tyson@tyson-VirtualBox using gcc version 4.8.1
Checking CPU features
virtual memory layout:
    user area            0 - c0000000
    copy area     c4000000 - c4800000
    ktcb area     e0000000 - f0000000
    kernel area   df000000 - ff000000
    cpulocal data f011c000 - f012f92c
    utcb pgarea   df000000
    space link    c5000000
Initializing kernel memory (f013a000-f015a000) [128K]
Initializing kernel space
    Switching to CPU local pagetable 0013b000 (CPU 0)
CPU local pagetable activated 13b000 (CPU 0)
Initializing TCBs
Activating TSS (Preliminary)
Initializing GDT (Preliminary)
Activating IDT (Preliminary)
Initializing kernel interface page (f011b000)
Adding more kernel memory
    found  16M kmem (6ffe000-7ffdfff) -> (f6ffe000-f7ffdfff)
Initializing memory info
Initializing mapping database
Initializing kernel debugger
Initializing IRQ hardware
Initializing Timer
    Activating TSS (CPU 0)se
    Initializing GDT (CPU 0)
    Activating IDT (CPU 0)
    Enabling global pages (CPU 0)
    Activating MSRS (CPU 0)
    Initializing Timer (CPU 0)
    Calculating processor speed ...
    CPU speed: 1998 MHz
    Initializing Processor (CPU 0)
    Registering processor 0 in KIP (0MHz, 1998MHz)
    Initializing threading (CPU 0)
    Switching to idle thread (CPU 0)
System has 16 hardware interrupts
Initializing root servers
root-servers: utcb_area: bf000110 (128KB), kip_area: bff000c0 (4KB)
Creating sigma0 (SIGMA0)
Creating root server (ROOTTASK)
    Idle thread started on CPU 0
YOU RANG THE BELL!> 

It'd be nice if there was a way to capture the execution flow inside QEMU.

From GRUB 0.97 itself, I get this after loading each image:

grublocs

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

As for GRUB2, I vaguely remember reading something, somewhere about it no longer fully complying with the multiboot spec - which seems pretty ironic, given that the GNU folks were involved in designing it...

@jkehne
Copy link
Member

jkehne commented May 5, 2014

I wouldn't count on pistachio complying with the multiboot spec either ;)
Your GRUB 0.97 works because it is putting your images in a different location than GRUB2. So the question is: Why does GRUB2 think the kernel image belongs at 0x00111000? Unfortunately, I don't have time to dig into that right now, but if I come up with something, I will let you know.
Thanks a lot for your help.

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

No worries.

It seems that others have encountered similar problems - but since I'm wanting to build something using the kernel, it only seems fair that I actually take the time to debug, and report bugs properly. :)

Thanks.

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

I've probably broken things subtly, but in the meantime, I've been trying to instrument KickStart (although it's slow-going, since there are so many execution paths, and files), in the hopes of figuring out where things are breaking...

Since the Ubuntu folks seem to value consumer vanity, over developer sanity, it looks as if they've "enhanced" their GRUB builds to be less verbose, if https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/386922 is to be believed.

With the old GRUB, I get:

[kickstart.cc] : KickStart 0.13.06
[kickstart.cc] : inside loader()

[kickstart.cc] : Detected multiboot compliant loader
 kernel    (0x00819000-0x0085d115)   => 0x0015d0c0
  (0x00819000-0x0082b567) -> 0x00100000-0x00112567
  (0x0082c000-0x008327c2) -> 0x00114000-0x0011a7c2
  (0x00833000-0x00851d58) -> 0x0011b000-0x00139d58
  (0x00852000-0x00855c38) -> 0x0015a000-0x0015dc38
 sigma0    (0x0085e000-0x008793c3)   => 0x00020000
  (0x0085f000-0x00868524) -> 0x00020000-0x00029524
 roottask  (0x0087a000-0x0087ffc6)   => 0x0040000f
  (0x0087a080-0x0087d724) -> 0x00400000-0x004036a4
[kickstart.cc] : Launching kernel ...
[ia32.cc] : Inside launch_kernel(), trying to squeeze into 0x1429696

L4Ka::Pistachio - built on May  3 2014 20:26:28 by tyson@tyson-VirtualBox using gcc version 4.8.1
Checking CPU features
virtual memory layout:
    user area            0 - c0000000
    copy area     c4000000 - c4800000
    ktcb area     e0000000 - f0000000
    kernel area   df000000 - ff000000
    cpulocal data f011c000 - f012f92c
    utcb pgarea   df000000
    space link    c5000000
Initializing kernel memory (f013a000-f015a000) [128K]
Initializing kernel space
    Switching to CPU local pagetable 0013b000 (CPU 0)
CPU local pagetable activated 13b000 (CPU 0)
Initializing TCBs
Activating TSS (Preliminary)
Initializing GDT (Preliminary)
Activating IDT (Preliminary)
Initializing kernel interface page (f011b000)
Adding more kernel memory
    found  16M kmem (6ffe000-7ffdfff) -> (f6ffe000-f7ffdfff)
Initializing memory info
Initializing mapping database
Initializing kernel debugger
Initializing IRQ hardware
Initializing Timer
    Activating TSS (CPU 0)se
    Initializing GDT (CPU 0)
    Activating IDT (CPU 0)
    Enabling global pages (CPU 0)
    Activating MSRS (CPU 0)
    Initializing Timer (CPU 0)
    Calculating processor speed ...
    CPU speed: 2002 MHz
    Initializing Processor (CPU 0)
    Registering processor 0 in KIP (0MHz, 2002MHz)
    Initializing threading (CPU 0)
    Switching to idle thread (CPU 0)
System has 16 hardware interrupts
Initializing root servers
root-servers: utcb_area: bf000110 (128KB), kip_area: bff000c0 (4KB)
Creating sigma0 (SIGMA0)
Creating root server (ROOTTASK)
    Idle thread started on CPU 0
YOU RANG THE BELL!> 

With the new GRUB, I get:

[kickstart.cc] : KickStart 0.13.06
[kickstart.cc] : inside loader()

[kickstart.cc] : Detected multiboot compliant loader
 kernel    (0x00111000-0x00155115)   => 0x0015d0c0
  (0x00111000-0x00123567) -> 0x00100000-0x00112567
     Conflict with multiboot module 0 (0x00111000-0x00155115)
     Please choose a different link base
[ia32.cc] : PANIC: FAIL in line 161

Still need to dig deeper into ia32.cc, and whatever else it calls, in order to do the voodoo that gets the kernel running.

@vmlemon
Copy link
Author

vmlemon commented May 5, 2014

Now I've got a slightly better idea of how KickStart works, I managed to extend it to expose whether an ELF binary is 32-bit, or 64-bit (so I can tell that the elf.cc has been entered), reveal some info regarding the boot info table, and say when the it tried to enter the kernel...

[kickstart.cc] : KickStart 0.13.06
[kickstart.cc] : inside loader()

[kickstart.cc] : Detected multiboot compliant loader
 kernel  <32> | 
  (0x00819000-0x0085d115)   => 0x0015d0c0
  (0x00819000-0x0082b567) -> 0x00100000-0x00112567
  (0x0082c000-0x008327c2) -> 0x00114000-0x0011a7c2
  (0x00833000-0x00851d58) -> 0x0011b000-0x00139d58
  (0x00852000-0x00855c38) -> 0x0015a000-0x0015dc38
 sigma0  <32> | 
  (0x0085e000-0x008793c3)   => 0x00020000
  (0x0085f000-0x00868524) -> 0x00020000-0x00029524
 roottask<32> | 
  (0x0087a000-0x0087ffc6)   => 0x0040000f
  (0x0087a080-0x0087d724) -> 0x00400000-0x004036a4
[bootinfo.cc] : init_bootinfo(), boot info record size & first entry: 32...

[bootinfo.cc] : init_bootinfo(), boot info record version: 1...

[bootinfo.cc] : init_bootinfo(), have 0 entries in the table...

[kickstart.cc] : Launching kernel ...
[ia32.cc] : Inside launch_kernel(), trying to squeeze into 0x15D0C0

Not sure if any of those changes are useful for upstream, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants