Increase L4linux ramdisk size ?
Hello, I am using Fiasco.OC/L4Re/L4Linux on a Beagleboard. After having successfully used/customized the L4Linux ramdisk provided as part of the snapshot, I created a larger ramdisk (8Mb instead of ~3Mb) from scratch and adjusted the "ramdisk_size" option on the linux boot args line in my LUA script, and rebuilt my u-boot image. I then get plenty of errors during linux boot, starting with: RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 8000KiB [1 disk] into ram disk... l4linux1| Non-resolvable page fault at e0d1619, ip 170384. l4linux1| Page fault (non-resolved): pfa=e0d1619 pc=170384 l4linux1| Non-resolvable page fault at e0d161a, ip 170384. Internal error: Boom!: 410005 [#1] etc... My questions: - is there a specific way to create a ramdisk file for l4linux, and/or specific constraints on the ramdisk size ? - am I missing other configuration parameters than ramdisk_size that should be adjusted to reflect the larger ramdisk size ? Thanks, Julien
Hi, On Thu Mar 31, 2011 at 12:16:05 +0200, Julien Heyman wrote:
I am using Fiasco.OC/L4Re/L4Linux on a Beagleboard. After having successfully used/customized the L4Linux ramdisk provided as part of the snapshot, I created a larger ramdisk (8Mb instead of ~3Mb) from scratch and adjusted the "ramdisk_size" option on the linux boot args line in my LUA script, and rebuilt my u-boot image. I then get plenty of errors during linux boot, starting with:
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 8000KiB [1 disk] into ram disk... l4linux1| Non-resolvable page fault at e0d1619, ip 170384. l4linux1| Page fault (non-resolved): pfa=e0d1619 pc=170384 l4linux1| Non-resolvable page fault at e0d161a, ip 170384.
Internal error: Boom!: 410005 [#1] etc...
My questions: - is there a specific way to create a ramdisk file for l4linux, and/or specific constraints on the ramdisk size ?
No specific way. Ramdisk size should not exceed half of the memory given to L4Linux itself. This should not happen to you as there's a check preventing this pitfall.
- am I missing other configuration parameters than ramdisk_size that should be adjusted to reflect the larger ramdisk size ?
No, ramdisk_size is enough. There's something different happening here. Can you tell me where 0x170384 is in the binary? Probably the backtrace was printed. Is there anything strange in the bootup log? Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Thank you for the prompt reply. I don't have access to my Beagleboard right now, but I'll redo the test and capture the full boot log as soon as I can. Julien On Mar 31, 2011, at 6:55 PM, Adam Lackorzynski wrote:
Hi,
On Thu Mar 31, 2011 at 12:16:05 +0200, Julien Heyman wrote:
I am using Fiasco.OC/L4Re/L4Linux on a Beagleboard. After having successfully used/customized the L4Linux ramdisk provided as part of the snapshot, I created a larger ramdisk (8Mb instead of ~3Mb) from scratch and adjusted the "ramdisk_size" option on the linux boot args line in my LUA script, and rebuilt my u-boot image. I then get plenty of errors during linux boot, starting with:
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 8000KiB [1 disk] into ram disk... l4linux1| Non-resolvable page fault at e0d1619, ip 170384. l4linux1| Page fault (non-resolved): pfa=e0d1619 pc=170384 l4linux1| Non-resolvable page fault at e0d161a, ip 170384.
Internal error: Boom!: 410005 [#1] etc...
My questions: - is there a specific way to create a ramdisk file for l4linux, and/or specific constraints on the ramdisk size ?
No specific way. Ramdisk size should not exceed half of the memory given to L4Linux itself. This should not happen to you as there's a check preventing this pitfall.
- am I missing other configuration parameters than ramdisk_size that should be adjusted to reflect the larger ramdisk size ?
No, ramdisk_size is enough. There's something different happening here. Can you tell me where 0x170384 is in the binary? Probably the backtrace was printed. Is there anything strange in the bootup log?
Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi Adam, Here is what I notice now: it seems to be related to memory settings somehow. Even though my ramdisk is indeed smaller than half the ram size I assign to the linux instance loading it, the presence of other L4Re executables (that take their share of the global memory...) has an impact, as illustrated in the tests below: Test 1: - I am running two instances of L4Linux simultaneously. The first instance gets 16Mb RAM and has a ramdisk of ~3Mb, while the second instance gets 40Mb RAM and has a ramdisk of 16Mb => in this case the boot fails in the second linux instance, with the symptoms I mentionned earlier, when loading the 16Mb ramdisk (full log attached) Test 2: - same setup, but I comment out the creation of the first linux instance in the boot script => in this case the 16Mb ramdisk is properly loaded in the "second" linux and boot is OK (full log attached) Test 3: - similar setup as test 1, running two linux instances, but this time reducing the ramdisk in the second instance to 8Mb instead of 16Mb: boot is OK in this case too (full log attached) Do the logs and/or my test descriptions above allow to understand the reason for the failed case ? As a side question, I see at boot time that Fiasco uses a total of only 128 Mb of RAM, whereas the Beagleboard xM I am using has 512 Mb RAM. Is this amount predefined somewhere in Fiasco, or does it autodetect available RAM at boot time ? (and in this case why doesn't it see the full 512 Mb ?) Thanks, Julien On Thu, Mar 31, 2011 at 10:40 PM, Julien HEYMAN <bidsomail@gmail.com> wrote:
Thank you for the prompt reply. I don't have access to my Beagleboard right now, but I'll redo the test and capture the full boot log as soon as I can.
Julien
On Mar 31, 2011, at 6:55 PM, Adam Lackorzynski wrote:
Hi,
On Thu Mar 31, 2011 at 12:16:05 +0200, Julien Heyman wrote:
I am using Fiasco.OC/L4Re/L4Linux on a Beagleboard. After having successfully used/customized the L4Linux ramdisk provided as part of the snapshot, I created a larger ramdisk (8Mb instead of ~3Mb) from scratch and adjusted the "ramdisk_size" option on the linux boot args line in my LUA script, and rebuilt my u-boot image. I then get plenty of errors during linux boot, starting with:
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 8000KiB [1 disk] into ram disk... l4linux1| Non-resolvable page fault at e0d1619, ip 170384. l4linux1| Page fault (non-resolved): pfa=e0d1619 pc=170384 l4linux1| Non-resolvable page fault at e0d161a, ip 170384.
Internal error: Boom!: 410005 [#1] etc...
My questions: - is there a specific way to create a ramdisk file for l4linux, and/or specific constraints on the ramdisk size ?
No specific way. Ramdisk size should not exceed half of the memory given to L4Linux itself. This should not happen to you as there's a check preventing this pitfall.
- am I missing other configuration parameters than ramdisk_size that should be adjusted to reflect the larger ramdisk size ?
No, ramdisk_size is enough. There's something different happening here. Can you tell me where 0x170384 is in the binary? Probably the backtrace was printed. Is there anything strange in the bootup log?
Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi Julien, On Wed Apr 06, 2011 at 16:42:07 +0200, Julien Heyman wrote:
Here is what I notice now: it seems to be related to memory settings somehow. Even though my ramdisk is indeed smaller than half the ram size I assign to the linux instance loading it, the presence of other L4Re executables (that take their share of the global memory...) has an impact, as illustrated in the tests below:
Test 1: - I am running two instances of L4Linux simultaneously. The first instance gets 16Mb RAM and has a ramdisk of ~3Mb, while the second instance gets 40Mb RAM and has a ramdisk of 16Mb => in this case the boot fails in the second linux instance, with the symptoms I mentionned earlier, when loading the 16Mb ramdisk (full log attached)
Test 2: - same setup, but I comment out the creation of the first linux instance in the boot script => in this case the 16Mb ramdisk is properly loaded in the "second" linux and boot is OK (full log attached)
Test 3: - similar setup as test 1, running two linux instances, but this time reducing the ramdisk in the second instance to 8Mb instead of 16Mb: boot is OK in this case too (full log attached)
I'll try to reproduce this. It didn't work in the first try but I'll try harder.
Do the logs and/or my test descriptions above allow to understand the reason for the failed case ? As a side question, I see at boot time that Fiasco uses a total of only 128 Mb of RAM, whereas the Beagleboard xM I am using has 512 Mb RAM. Is this amount predefined somewhere in Fiasco, or does it autodetect available RAM at boot time ? (and in this case why doesn't it see the full 512 Mb ?)
The reason is simple. The older Beagleboard (without 'xM') has 128MB, so this is the default setting. When building the image, add RAM_SIZE_MB=512 to the make command and it will use 512MB. Adding it to conf/Makeconf.boot will make it the default. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Hi Adam, Thanks for the RAM_SIZE_MB tip, I now have 512 Mb properly detected/usable on my BB xM. The test scenario still fails as before though (if I keep the RAM/ramdisk settings I mentionned previously). I will increase the amount of RAM I allocate to each L4linux instance, to workaround the problem, but in case you find something interesting on the reason for this behavior I am of course still interested to know. Regards, Julien On Thu, Apr 7, 2011 at 3:42 PM, Adam Lackorzynski <adam@os.inf.tu-dresden.de
wrote:
Hi Julien,
On Wed Apr 06, 2011 at 16:42:07 +0200, Julien Heyman wrote:
Here is what I notice now: it seems to be related to memory settings somehow. Even though my ramdisk is indeed smaller than half the ram size I assign to the linux instance loading it, the presence of other L4Re executables (that take their share of the global memory...) has an impact, as illustrated in the tests below:
Test 1: - I am running two instances of L4Linux simultaneously. The first instance gets 16Mb RAM and has a ramdisk of ~3Mb, while the second instance gets 40Mb RAM and has a ramdisk of 16Mb => in this case the boot fails in the second linux instance, with the symptoms I mentionned earlier, when loading the 16Mb ramdisk (full log attached)
Test 2: - same setup, but I comment out the creation of the first linux instance in the boot script => in this case the 16Mb ramdisk is properly loaded in the "second" linux and boot is OK (full log attached)
Test 3: - similar setup as test 1, running two linux instances, but this time reducing the ramdisk in the second instance to 8Mb instead of 16Mb: boot is OK in this case too (full log attached)
I'll try to reproduce this. It didn't work in the first try but I'll try harder.
Do the logs and/or my test descriptions above allow to understand the reason for the failed case ? As a side question, I see at boot time that Fiasco uses a total of only 128 Mb of RAM, whereas the Beagleboard xM I am using has 512 Mb RAM. Is this amount predefined somewhere in Fiasco, or does it autodetect available RAM at boot time ? (and in this case why doesn't it see the full 512 Mb ?)
The reason is simple. The older Beagleboard (without 'xM') has 128MB, so this is the default setting. When building the image, add RAM_SIZE_MB=512 to the make command and it will use 512MB. Adding it to conf/Makeconf.boot will make it the default.
Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
participants (3)
-
Adam Lackorzynski -
Julien Heyman -
Julien HEYMAN