-
Notifications
You must be signed in to change notification settings - Fork 54
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
Comments
PS - If it it helps, my GRUB2 configuration file looks like:
|
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:
I guess that KickStart's incompatible with GRUB2, unless it's modified... |
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. |
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). |
Also, since it took me forever to figure out, I'm pretty sure that the GRUB2 config file's supposed to look like:
Rather than the aborted attempt, above... And obviously for GRUB 0.97:
|
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. |
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:
|
Alternatively, does the config file you just posted work with GRUB2? |
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. |
If I boot using GRUB2 (exact version is 2.00-19ubuntu2), and specify my custom server (
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 For 0.97, I get a successful boot:
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: |
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... |
I wouldn't count on pistachio complying with the multiboot spec either ;) |
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. |
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:
With the new GRUB, I get:
Still need to dig deeper into ia32.cc, and whatever else it calls, in order to do the voodoo that gets the kernel running. |
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...
Not sure if any of those changes are useful for upstream, though. |
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:
My kernel configuration file looks like:
Please can someone enlighten me on what's going wrong?
The text was updated successfully, but these errors were encountered: