This is not the same error message, but it sounds like the same problem. On the FAQ for L4KA: from http://www.l4ka.org/projects/hazelnut/faq.asp Linux does not start - I get the error "sigma0: page 0x200002 requested twice..." At boot time RMGR configures reserved memory areas based on the system's memory configuration. The Linux kernel binary is pretty big and overlaps sometimes with needed memory. Thus, the physical memory is not available anymore and sigma0 denies to hand it out. Our GRUB version provides a keyword (modaddr) to specify the load address of modules. Simply add the modaddr-line to your menu.lst file as following: kernel=(nd)/l4-ka/rmgr -configfile -sigma0 modaddr=0x03000000 module=(nd)/l4-ka/x86-kernel module=(nd)/l4-ka/sigma0 module=(nd)/l4-ka/rmgr.cfg module=(nd)/l4-ka/glinux root=/dev/hda1 no-scroll All module images are now loaded starting at physical address 0x03000000 (48MB). --- Ian Duggan <ian@ianduggan.net> wrote:

I'm trying to get linux22 working on the recent CVS version of fiasco. I've run into an obstacle that hopefully someone here can assist with.

When my machine is booting up, I get an "overlapping modules" error that looks like this:

-------------------------------------------------------

RMGR: loading /sigma0 RMGR: loading kernel /main

RMGR: overlaps: 00300000-00301c78 : /main RMGR: 00100000-0015fc69 module 02: 001e6000-00345be4 : /glinux root=/dev/hdb1 init=/bin/sh overlaps, 1, mem_high = 0x09f9fc00

RMGR: overlapping modules

-------------------------------------------------------

00300000 is the starting link address of /main 00100000 is the starting link address of /rmgr

I thought that maybe I needed to move the starting link address of /glinux, so I adjusted the corresponding vmlinux.lds file used for linking linux22, but there is no change in the result. I verified all code start/end addresses using objdump -d.

Just now I noticed that 001e5000 is where GRUB is loading the /glinux image to. Grub shows:

[Multiboot-modules @ 0x1e6000 ...

when it is starting up.

The problem seems to be that rmgr is calling check_inside_myself and croaking when it sees that the /glinux module overlaps it.

I don't understand why the /main and /rmgr images are being loaded to their correct link locations, but /glinux is not. Is grub supposed to load things directly to the correct location, or are the modules supposed to be relocated at some point in the boot process.

Any suggestions on what to look at?

-- Ian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ian Duggan ian@ianduggan.net

http://www.ianduggan.net

_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de

http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/

I can only answer your questions with respect to a normal UNIX application. I'm not sure they apply here where resources get resolved in terms of physical memory (and hence absolute offsets). I hope someone from the L4 group can tell you what the "right thing" is.

When a normal program is linked, is it linked with absolute addresses as well? Yes. Every program (on a UNIX style system) has the entire address space to itself. At compile time functions get positions within an object file, when the program is linked, those offsets get resolved relative to everything else in the executable. Those all then get put in the text portion of the address space. Shared libraries get compiled as position independent code (relative offsets) so that the loader can choose where to put them in a program's address space.

And when it is loaded, it is relocated to the

right address? Any physical address is the "right address", all programs start from virtual address 0.

Is

the virtual memory mechanism of making each program think it has all the memory to itself what allows this, rather than having to have programs linked in such a way that they could be loaded and run from whereever the program loader wants them to be?

Basically. Programs would obviously all have to be position independent in a single address space operating system e.g. Mungi or Opal or when running on hardware that doesn't have a proper MMU e.g. uC-Linux. __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/

Basically. Programs would obviously all have to be position independent in a single address space operating system e.g. Mungi or Opal or when running on hardware that doesn't have a proper MMU e.g. uC-Linux.

Ok, so it's technically possible to compile all programs an libraries as position independent code, it's just not the way it is one on Unix like sysems. Is there a reason the choice of absolute address was chosen over position independent code in this case? Are there performance benefits? -- Ian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian@ianduggan.net http://www.ianduggan.net