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
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
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/
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..."
Yes, I saw that, and I will try the l4ka version of GRUB to see if it will work. At the moment, I'm using tftp to get my files during bootup, and I'm not sure if the l4ka GRUB has that functionality in it.
A bigger problem for me is understanding the relationship between the link addresses in a binary, where GRUB loads that binary to, and whether or not it eventually gets relocated to the correct address.
When a normal program is linked, is it linked with absolute addresses as well? And when it is loaded, it is relocated to the right address? 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?
-- Ian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ian Duggan ian@ianduggan.net http://www.ianduggan.net
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
Doesn't really belong into this list, but I thought I'd just rectify some misconception:
On Fri, 22 Mar 2002 12:36:51 -0800 (PST), k Macy kip_macy@yahoo.com said:
kM> [ ... ]
kM> Basically. Programs would obviously all have to be kM> position independent in a single address space kM> operating system e.g. Mungi or Opal or when running on kM> hardware that doesn't have a proper MMU e.g. uC-Linux.
You don't need position-independent code in a SASOS, not even for dynamic linking (which means less overhead than in a Unix system). See Deller and Heiser, Linking Programs in a Single Address Space, USENIX '99.
Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5533 _,--._* UNSW SYDNEY NSW 2052, Australia mailto:gernot@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot
On Fri, Mar 22, 2002 at 10:49:55AM -0800, Ian Duggan wrote:
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..."
Yes, I saw that, and I will try the l4ka version of GRUB to see if it will work. At the moment, I'm using tftp to get my files during bootup, and I'm not sure if the l4ka GRUB has that functionality in it.
A bigger problem for me is understanding the relationship between the link addresses in a binary, where GRUB loads that binary to, and whether or not it eventually gets relocated to the correct address.
You should read the multiboot specification, I think it explains these things.
Jeroen Dekkers
l4-hackers@os.inf.tu-dresden.de
-
Gernot Heiser -
Ian Duggan -
Jeroen Dekkers -
k Macy