Hi,
I'm encountering a problem where the memory region of BOOTFS of L4Re got overwritten. Interestingly, the page is overwritten by things in the bootfs.
Here are the physical memory mapping set up by BOOTFS:
... BOOTFS: [2227000-23297b8] [C:506000] rtc BOOTFS: [232a000-26d5411] [C:507000] mag BOOTFS: [26d6000-2848a94] [C:508000] fb-drv BOOTFS: [129d000-129daa4] [C:509000] vandroid-x86.cfg BOOTFS: [126b000-126b3b7] [C:50a000] x86-legacy.devs …
The page 0x2239000 (which belongs to rtc) is magically overwritten by the first page of x86-legacy.devs. I confirmed it with both JDB and QEMU monitor.
I'm running the newest snapshot of L4Re / L4Android on top of the UP version L4.Fiasco kernel.
What would be the best approach to debug the problem? is it there a way to mark the whole BOOTFS as read-only so that I can figure out what's going on?
Thanks!
~Haohui
What is more interesting is that only that page is overwritten: The page before and after it stays the same.
~Haohui
On Apr 19, 2012, at 1:40 PM, Haohui Mai wrote:
Hi,
I'm encountering a problem where the memory region of BOOTFS of L4Re got overwritten. Interestingly, the page is overwritten by things in the bootfs.
Here are the physical memory mapping set up by BOOTFS:
... BOOTFS: [2227000-23297b8] [C:506000] rtc BOOTFS: [232a000-26d5411] [C:507000] mag BOOTFS: [26d6000-2848a94] [C:508000] fb-drv BOOTFS: [129d000-129daa4] [C:509000] vandroid-x86.cfg BOOTFS: [126b000-126b3b7] [C:50a000] x86-legacy.devs …
The page 0x2239000 (which belongs to rtc) is magically overwritten by the first page of x86-legacy.devs. I confirmed it with both JDB and QEMU monitor.
I'm running the newest snapshot of L4Re / L4Android on top of the UP version L4.Fiasco kernel.
What would be the best approach to debug the problem? is it there a way to mark the whole BOOTFS as read-only so that I can figure out what's going on?
Thanks!
~Haohui
It turns out that bootstrap overwrites the memory during relocation. Here are the logs:
moving module 11 { 29d000-29d3b7 } -> { 126b000-126b3b7 } ... moving module 07 { 1259000-135b7b8 } -> { 2227000-23297b8 } ...
Module 07 is the rtc module, which is the module has been overwritten. As you can see that module 11 overwrite the page 0x126b000 before moving module 07, which causes the corruption.
The detection in bootstrap doesn't seem to be sufficient since it only detects whether the new region is overlapped to roottask and sigma0.
What would be the best way of fixing it?
~Haohui
On Thu, Apr 19, 2012 at 1:46 PM, Haohui Mai haohui.mai@gmail.com wrote:
What is more interesting is that only that page is overwritten: The page before and after it stays the same.
~Haohui
On Apr 19, 2012, at 1:40 PM, Haohui Mai wrote:
Hi,
I'm encountering a problem where the memory region of BOOTFS of L4Re got overwritten. Interestingly, the page is overwritten by things in the bootfs.
Here are the physical memory mapping set up by BOOTFS:
... BOOTFS: [2227000-23297b8] [C:506000] rtc BOOTFS: [232a000-26d5411] [C:507000] mag BOOTFS: [26d6000-2848a94] [C:508000] fb-drv BOOTFS: [129d000-129daa4] [C:509000] vandroid-x86.cfg BOOTFS: [126b000-126b3b7] [C:50a000] x86-legacy.devs …
The page 0x2239000 (which belongs to rtc) is magically overwritten by the first page of x86-legacy.devs. I confirmed it with both JDB and QEMU monitor.
I'm running the newest snapshot of L4Re / L4Android on top of the UP version L4.Fiasco kernel.
What would be the best approach to debug the problem? is it there a way to mark the whole BOOTFS as read-only so that I can figure out what's going on?
Thanks!
~Haohui
Hi,
I probably should include the full logs here. You can see that it breaks the code because the module lists are not sorted by grub.
moving module 16 { 2835000-296ac76 } -> { 3803000-3938c76 } moving module 15 { 2470000-2835000 } -> { 343e000-3803000 } moving module 14 { 1c70000-2470000 } -> { 2c3e000-343e000 } moving module 13 { 187c000-1c6f98a } -> { 284a000-2c3d98a } moving module 12 { 187b000-187b618 } -> { 2849000-2849618 } moving module 11 { 29d000-29d3b7 } -> { 126b000-126b3b7 } moving module 10 { 2cf000-2cfaa4 } -> { 129d000-129daa4 } moving module 09 { 1708000-187aa94 } -> { 26d6000-2848a94 } moving module 08 { 135c000-1707411 } -> { 232a000-26d5411 } moving module 07 { 1259000-135b7b8 } -> { 2227000-23297b8 } moving module 06 { 85c000-1258bde } -> { 182a000-2226bde } moving module 05 { 629000-85b826 } -> { 15f7000-1829826 } moving module 04 { 503000-628310 } -> { 14d1000-15f6310 } moving module 03 { 2e2000-5029b4 } -> { 12b0000-14d09b4 } moving module 02 { 193000-1e69f5 } -> { 1161000-11b49f5 } moving module 01 { 132000-192880 } -> { 1100000-1160880 }
~Haohui
On Thu, Apr 19, 2012 at 5:58 PM, Mai, Haohui haohui.mai@gmail.com wrote:
It turns out that bootstrap overwrites the memory during relocation. Here are the logs:
moving module 11 { 29d000-29d3b7 } -> { 126b000-126b3b7 } ... moving module 07 { 1259000-135b7b8 } -> { 2227000-23297b8 } ...
Module 07 is the rtc module, which is the module has been overwritten. As you can see that module 11 overwrite the page 0x126b000 before moving module 07, which causes the corruption.
The detection in bootstrap doesn't seem to be sufficient since it only detects whether the new region is overlapped to roottask and sigma0.
What would be the best way of fixing it?
~Haohui
On Thu, Apr 19, 2012 at 1:46 PM, Haohui Mai haohui.mai@gmail.com wrote:
What is more interesting is that only that page is overwritten: The page before and after it stays the same.
~Haohui
On Apr 19, 2012, at 1:40 PM, Haohui Mai wrote:
Hi,
I'm encountering a problem where the memory region of BOOTFS of L4Re got overwritten. Interestingly, the page is overwritten by things in the bootfs.
Here are the physical memory mapping set up by BOOTFS:
... BOOTFS: [2227000-23297b8] [C:506000] rtc BOOTFS: [232a000-26d5411] [C:507000] mag BOOTFS: [26d6000-2848a94] [C:508000] fb-drv BOOTFS: [129d000-129daa4] [C:509000] vandroid-x86.cfg BOOTFS: [126b000-126b3b7] [C:50a000] x86-legacy.devs …
The page 0x2239000 (which belongs to rtc) is magically overwritten by the first page of x86-legacy.devs. I confirmed it with both JDB and QEMU monitor.
I'm running the newest snapshot of L4Re / L4Android on top of the UP version L4.Fiasco kernel.
What would be the best approach to debug the problem? is it there a way to mark the whole BOOTFS as read-only so that I can figure out what's going on?
Thanks!
~Haohui
Hi,
On Thu Apr 19, 2012 at 18:01:32 -0500, Mai, Haohui wrote:
I probably should include the full logs here. You can see that it breaks the code because the module lists are not sorted by grub.
moving module 16 { 2835000-296ac76 } -> { 3803000-3938c76 } moving module 15 { 2470000-2835000 } -> { 343e000-3803000 } moving module 14 { 1c70000-2470000 } -> { 2c3e000-343e000 } moving module 13 { 187c000-1c6f98a } -> { 284a000-2c3d98a } moving module 12 { 187b000-187b618 } -> { 2849000-2849618 } moving module 11 { 29d000-29d3b7 } -> { 126b000-126b3b7 } moving module 10 { 2cf000-2cfaa4 } -> { 129d000-129daa4 } moving module 09 { 1708000-187aa94 } -> { 26d6000-2848a94 } moving module 08 { 135c000-1707411 } -> { 232a000-26d5411 } moving module 07 { 1259000-135b7b8 } -> { 2227000-23297b8 } moving module 06 { 85c000-1258bde } -> { 182a000-2226bde } moving module 05 { 629000-85b826 } -> { 15f7000-1829826 } moving module 04 { 503000-628310 } -> { 14d1000-15f6310 } moving module 03 { 2e2000-5029b4 } -> { 12b0000-14d09b4 } moving module 02 { 193000-1e69f5 } -> { 1161000-11b49f5 } moving module 01 { 132000-192880 } -> { 1100000-1160880 }
Interesting. Which kind/version of Grub is that?
Adam
I'm using grub-install (GRUB) 1.99-12ubuntu5, which is the default boot loader of Ubuntu 11.10.
~Haohui
On Apr 22, 2012, at 8:28 AM, Adam Lackorzynski wrote:
Hi,
On Thu Apr 19, 2012 at 18:01:32 -0500, Mai, Haohui wrote:
I probably should include the full logs here. You can see that it breaks the code because the module lists are not sorted by grub.
moving module 16 { 2835000-296ac76 } -> { 3803000-3938c76 } moving module 15 { 2470000-2835000 } -> { 343e000-3803000 } moving module 14 { 1c70000-2470000 } -> { 2c3e000-343e000 } moving module 13 { 187c000-1c6f98a } -> { 284a000-2c3d98a } moving module 12 { 187b000-187b618 } -> { 2849000-2849618 } moving module 11 { 29d000-29d3b7 } -> { 126b000-126b3b7 } moving module 10 { 2cf000-2cfaa4 } -> { 129d000-129daa4 } moving module 09 { 1708000-187aa94 } -> { 26d6000-2848a94 } moving module 08 { 135c000-1707411 } -> { 232a000-26d5411 } moving module 07 { 1259000-135b7b8 } -> { 2227000-23297b8 } moving module 06 { 85c000-1258bde } -> { 182a000-2226bde } moving module 05 { 629000-85b826 } -> { 15f7000-1829826 } moving module 04 { 503000-628310 } -> { 14d1000-15f6310 } moving module 03 { 2e2000-5029b4 } -> { 12b0000-14d09b4 } moving module 02 { 193000-1e69f5 } -> { 1161000-11b49f5 } moving module 01 { 132000-192880 } -> { 1100000-1160880 }
Interesting. Which kind/version of Grub is that?
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
On Sun Apr 22, 2012 at 21:38:01 -0500, Haohui Mai wrote:
I'm using grub-install (GRUB) 1.99-12ubuntu5, which is the default boot loader of Ubuntu 11.10.
I looked more closely at what Grub2 is doing with the modules to find out that bootstrap needs a more sophisticated way of handling the way how they have been laid out in memory. As a workaround using a proper modaddr should avoid any clashes.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Haohui Mai -
Mai, Haohui