Hi -
Andrey has made a nice new branch "linux-linaro-tracking" with some "nexty" goodies in it
http://git.linaro.org/gitweb?p=people/ynk/linux-linaro-tracking.git%3Ba=shor...
I rebased tilt-tracking on top of it at v3.2 basis at the moment.
Quite early in boot, it blows a new BUG() in the code around iotable_init(), I added some debug and see it's blowing up when trying to define io memory in omap_barriers_init(). A bunch of earlier machine-defined iotable_inits go OK.
[ 0.000000] iotable_init: adding addr=DA000000 size=02000000 phys_addr=9A000000 [ 0.000000] iotable_init: adding addr=F8000000 size=00100000 phys_addr=44000000 [ 0.000000] iotable_init: adding addr=FC000000 size=00400000 phys_addr=4A000000 [ 0.000000] iotable_init: adding addr=F9000000 size=00100000 phys_addr=50000000 [ 0.000000] iotable_init: adding addr=FD100000 size=00100000 phys_addr=4C000000 [ 0.000000] iotable_init: adding addr=FD200000 size=00100000 phys_addr=4D000000 [ 0.000000] iotable_init: adding addr=FD300000 size=00100000 phys_addr=4E000000 [ 0.000000] iotable_init: adding addr=FA000000 size=00400000 phys_addr=48000000 [ 0.000000] iotable_init: adding addr=FE800000 size=00800000 phys_addr=54000000 ... [ 0.538024] omap_barriers_init: calling iotable_init [ 0.543243] iotable_init: adding addr=FE600000 size=00100000 phys_addr=AF600000 [ 0.550872] ------------[ cut here ]------------ [ 0.555725] Kernel BUG at c087c74c [verbose debug info unavailable] [ 0.562255] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP [ 0.569610] Modules linked in: [ 0.572845] CPU: 1 Tainted: G W (3.2.0-panda_tracking-topic-syslink-k3u+ #6) [ 0.581451] PC is at vm_area_add_early+0x20/0x84 [ 0.586303] LR is at iotable_init+0xa8/0xbc [ 0.590698] pc : [<c087c74c>] lr : [<c086cd48>] psr: 20000113 [ 0.590698] sp : ef78ff54 ip : ef78fe10 fp : 00000000 [ 0.602691] r10: c086cca0 r9 : 00000000 r8 : 40000001 [ 0.608154] r7 : ef7ffee0 r6 : ef78ff90 r5 : ef7ffec0 r4 : 00000001 [ 0.614959] r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : ef7ffec0 [ 0.621765] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.629394] Control: 10c5387d Table: 8000404a DAC: 00000015 [ 0.635406] Process swapper/0 (pid: 1, stack limit = 0xef78e2f8) [ 0.641662] Stack: (0xef78ff54 to 0xef790000) [ 0.646240] ff40: 00000001 00000000 af600000 [ 0.654754] ff60: c09299e0 ef78e000 00000000 00000000 c0870f8c c0871070 c08d7f9c c08a7bf8 [ 0.663269] ff80: fe600000 000af600 00100000 0000000e c08a7bfc c0008870 0000009f c009f590 [ 0.671783] ffa0: 0000009f c0870f8c c0014640 00393531 00000000 c0150000 00000000 c08e5604 [ 0.680297] ffc0: 0000019a c08a7bfc c08a842c c0014640 00000013 00000000 00000000 00000000 [ 0.688812] ffe0: 00000000 c08668bc 00000000 00000000 c0866830 c0014640 55555555 45515555 [ 0.697326] [<c087c74c>] (vm_area_add_early+0x20/0x84) from [<00000000>] ( (null)) [ 0.705322] Code: 059f3068 01a0c003 05933000 0a000010 (e7f001f2) [ 0.711700] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.716552] Kernel panic - not syncing: Attempted to kill init! [ 0.722747] CPU0: stopping [ 0.725646] [<c001a930>] (unwind_backtrace+0x0/0xf8) from [<c0018cf8>] (handle_IPI+0x114/0x140) [ 0.734710] [<c0018cf8>] (handle_IPI+0x114/0x140) from [<c00086c0>] (gic_handle_irq+0x88/0xac) [ 0.743682] [<c00086c0>] (gic_handle_irq+0x88/0xac) from [<c05fa0c0>] (__irq_svc+0x40/0x70) [ 0.752380] Exception stack(0xc08adf70 to 0xc08adfb8) [ 0.757659] df60: ffffffed 00000000 c08adfb8 00000000 [ 0.766174] df80: c08ac000 c0929aa8 c0603f50 c08c9bd8 c08c9d98 412fc09a 00000000 00000000 [ 0.774688] dfa0: 00000000 c08adfb8 c00146bc c00146c0 60000013 ffffffff [ 0.781616] [<c05fa0c0>] (__irq_svc+0x40/0x70) from [<c00146c0>] (default_idle+0x24/0x28) [ 0.790130] [<c00146c0>] (default_idle+0x24/0x28) from [<c001493c>] (cpu_idle+0xfc/0x11c) [ 0.798645] [<c001493c>] (cpu_idle+0xfc/0x11c) from [<c08667e0>] (start_kernel+0x260/0x2b0) [ 0.807342] [<c08667e0>] (start_kernel+0x260/0x2b0) from [<80008044>] (0x80008044)
You can see what's going on in omap_barriers_init() here:
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=blob%...
Does anyone have an idea why pulling in the new stuff in Andrey's tree would provoke this problem? There's a lot of stuff around device tree but I now rebuild the dtb every kernel build, so it shouldn't be that what's in there is out of date.
There's also stuff from rmk-devel-stable.
-Andy
Is there an update on this at all? Has anyone reported something similar upstream on 3.2 or 3.3-rc?
~Deepak
On 8 January 2012 23:29, Andy Green andy.green@linaro.org wrote:
Hi -
Andrey has made a nice new branch "linux-linaro-tracking" with some "nexty" goodies in it
http://git.linaro.org/gitweb?p=people/ynk/linux-linaro-tracking.git%3Ba=shor...
I rebased tilt-tracking on top of it at v3.2 basis at the moment.
Quite early in boot, it blows a new BUG() in the code around iotable_init(), I added some debug and see it's blowing up when trying to define io memory in omap_barriers_init(). A bunch of earlier machine-defined iotable_inits go OK.
[ 0.000000] iotable_init: adding addr=DA000000 size=02000000 phys_addr=9A000000 [ 0.000000] iotable_init: adding addr=F8000000 size=00100000 phys_addr=44000000 [ 0.000000] iotable_init: adding addr=FC000000 size=00400000 phys_addr=4A000000 [ 0.000000] iotable_init: adding addr=F9000000 size=00100000 phys_addr=50000000 [ 0.000000] iotable_init: adding addr=FD100000 size=00100000 phys_addr=4C000000 [ 0.000000] iotable_init: adding addr=FD200000 size=00100000 phys_addr=4D000000 [ 0.000000] iotable_init: adding addr=FD300000 size=00100000 phys_addr=4E000000 [ 0.000000] iotable_init: adding addr=FA000000 size=00400000 phys_addr=48000000 [ 0.000000] iotable_init: adding addr=FE800000 size=00800000 phys_addr=54000000 ... [ 0.538024] omap_barriers_init: calling iotable_init [ 0.543243] iotable_init: adding addr=FE600000 size=00100000 phys_addr=AF600000 [ 0.550872] ------------[ cut here ]------------ [ 0.555725] Kernel BUG at c087c74c [verbose debug info unavailable] [ 0.562255] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP [ 0.569610] Modules linked in: [ 0.572845] CPU: 1 Tainted: G W (3.2.0-panda_tracking-topic-syslink-k3u+ #6) [ 0.581451] PC is at vm_area_add_early+0x20/0x84 [ 0.586303] LR is at iotable_init+0xa8/0xbc [ 0.590698] pc : [<c087c74c>] lr : [<c086cd48>] psr: 20000113 [ 0.590698] sp : ef78ff54 ip : ef78fe10 fp : 00000000 [ 0.602691] r10: c086cca0 r9 : 00000000 r8 : 40000001 [ 0.608154] r7 : ef7ffee0 r6 : ef78ff90 r5 : ef7ffec0 r4 : 00000001 [ 0.614959] r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : ef7ffec0 [ 0.621765] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.629394] Control: 10c5387d Table: 8000404a DAC: 00000015 [ 0.635406] Process swapper/0 (pid: 1, stack limit = 0xef78e2f8) [ 0.641662] Stack: (0xef78ff54 to 0xef790000) [ 0.646240] ff40: 00000001 00000000 af600000 [ 0.654754] ff60: c09299e0 ef78e000 00000000 00000000 c0870f8c c0871070 c08d7f9c c08a7bf8 [ 0.663269] ff80: fe600000 000af600 00100000 0000000e c08a7bfc c0008870 0000009f c009f590 [ 0.671783] ffa0: 0000009f c0870f8c c0014640 00393531 00000000 c0150000 00000000 c08e5604 [ 0.680297] ffc0: 0000019a c08a7bfc c08a842c c0014640 00000013 00000000 00000000 00000000 [ 0.688812] ffe0: 00000000 c08668bc 00000000 00000000 c0866830 c0014640 55555555 45515555 [ 0.697326] [<c087c74c>] (vm_area_add_early+0x20/0x84) from [<00000000>] ( (null)) [ 0.705322] Code: 059f3068 01a0c003 05933000 0a000010 (e7f001f2) [ 0.711700] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.716552] Kernel panic - not syncing: Attempted to kill init! [ 0.722747] CPU0: stopping [ 0.725646] [<c001a930>] (unwind_backtrace+0x0/0xf8) from [<c0018cf8>] (handle_IPI+0x114/0x140) [ 0.734710] [<c0018cf8>] (handle_IPI+0x114/0x140) from [<c00086c0>] (gic_handle_irq+0x88/0xac) [ 0.743682] [<c00086c0>] (gic_handle_irq+0x88/0xac) from [<c05fa0c0>] (__irq_svc+0x40/0x70) [ 0.752380] Exception stack(0xc08adf70 to 0xc08adfb8) [ 0.757659] df60: ffffffed 00000000 c08adfb8 00000000 [ 0.766174] df80: c08ac000 c0929aa8 c0603f50 c08c9bd8 c08c9d98 412fc09a 00000000 00000000 [ 0.774688] dfa0: 00000000 c08adfb8 c00146bc c00146c0 60000013 ffffffff [ 0.781616] [<c05fa0c0>] (__irq_svc+0x40/0x70) from [<c00146c0>] (default_idle+0x24/0x28) [ 0.790130] [<c00146c0>] (default_idle+0x24/0x28) from [<c001493c>] (cpu_idle+0xfc/0x11c) [ 0.798645] [<c001493c>] (cpu_idle+0xfc/0x11c) from [<c08667e0>] (start_kernel+0x260/0x2b0) [ 0.807342] [<c08667e0>] (start_kernel+0x260/0x2b0) from [<80008044>] (0x80008044)
You can see what's going on in omap_barriers_init() here:
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=blob%...
Does anyone have an idea why pulling in the new stuff in Andrey's tree would provoke this problem? There's a lot of stuff around device tree but I now rebuild the dtb every kernel build, so it shouldn't be that what's in there is out of date.
There's also stuff from rmk-devel-stable.
-Andy
-- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On Tue, 17 Jan 2012, Deepak Saxena wrote:
Is there an update on this at all? Has anyone reported something similar upstream on 3.2 or 3.3-rc?
commit 716a3dc20084da9b3ab17bd125005a5345e23e3b Author: Russell King rmk+kernel@arm.linux.org.uk Date: Fri Jan 13 15:00:51 2012 +0000
ARM: Add arm_memblock_steal() to allocate memory away from the kernel
Several platforms are now using the memblock_alloc+memblock_free+ memblock_remove trick to obtain memory which won't be mapped in the kernel's page tables. Most platforms do this (correctly) in the ->reserve callback. However, OMAP has started to call these functions outside of this callback, and this is extremely unsafe - memory will not be unmapped, and could well be given out after memblock is no longer responsible for its management.
So, provide arm_memblock_steal() to perform this function, and ensure that it panic()s if it is used inappropriately. Convert everyone over, including OMAP.
As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot with this change. Mark this option as BROKEN and make it depend on BROKEN. OMAP needs to be fixed, or 137d105d50 (ARM: OMAP4: Fix errata i688 with MPU interconnect barriers.) reverted until such time it can be fixed correctly.
Signed-off-by: Russell King rmk+kernel@arm.linux.org.uk
On 8 January 2012 23:29, Andy Green andy.green@linaro.org wrote:
Hi -
Andrey has made a nice new branch "linux-linaro-tracking" with some "nexty" goodies in it
http://git.linaro.org/gitweb?p=people/ynk/linux-linaro-tracking.git%3Ba=shor...
I rebased tilt-tracking on top of it at v3.2 basis at the moment.
Quite early in boot, it blows a new BUG() in the code around iotable_init(), I added some debug and see it's blowing up when trying to define io memory in omap_barriers_init(). A bunch of earlier machine-defined iotable_inits go OK.
[ 0.000000] iotable_init: adding addr=DA000000 size=02000000 phys_addr=9A000000 [ 0.000000] iotable_init: adding addr=F8000000 size=00100000 phys_addr=44000000 [ 0.000000] iotable_init: adding addr=FC000000 size=00400000 phys_addr=4A000000 [ 0.000000] iotable_init: adding addr=F9000000 size=00100000 phys_addr=50000000 [ 0.000000] iotable_init: adding addr=FD100000 size=00100000 phys_addr=4C000000 [ 0.000000] iotable_init: adding addr=FD200000 size=00100000 phys_addr=4D000000 [ 0.000000] iotable_init: adding addr=FD300000 size=00100000 phys_addr=4E000000 [ 0.000000] iotable_init: adding addr=FA000000 size=00400000 phys_addr=48000000 [ 0.000000] iotable_init: adding addr=FE800000 size=00800000 phys_addr=54000000 ... [ 0.538024] omap_barriers_init: calling iotable_init [ 0.543243] iotable_init: adding addr=FE600000 size=00100000 phys_addr=AF600000 [ 0.550872] ------------[ cut here ]------------ [ 0.555725] Kernel BUG at c087c74c [verbose debug info unavailable] [ 0.562255] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP [ 0.569610] Modules linked in: [ 0.572845] CPU: 1 Tainted: G W (3.2.0-panda_tracking-topic-syslink-k3u+ #6) [ 0.581451] PC is at vm_area_add_early+0x20/0x84 [ 0.586303] LR is at iotable_init+0xa8/0xbc [ 0.590698] pc : [<c087c74c>] lr : [<c086cd48>] psr: 20000113 [ 0.590698] sp : ef78ff54 ip : ef78fe10 fp : 00000000 [ 0.602691] r10: c086cca0 r9 : 00000000 r8 : 40000001 [ 0.608154] r7 : ef7ffee0 r6 : ef78ff90 r5 : ef7ffec0 r4 : 00000001 [ 0.614959] r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : ef7ffec0 [ 0.621765] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.629394] Control: 10c5387d Table: 8000404a DAC: 00000015 [ 0.635406] Process swapper/0 (pid: 1, stack limit = 0xef78e2f8) [ 0.641662] Stack: (0xef78ff54 to 0xef790000) [ 0.646240] ff40: 00000001 00000000 af600000 [ 0.654754] ff60: c09299e0 ef78e000 00000000 00000000 c0870f8c c0871070 c08d7f9c c08a7bf8 [ 0.663269] ff80: fe600000 000af600 00100000 0000000e c08a7bfc c0008870 0000009f c009f590 [ 0.671783] ffa0: 0000009f c0870f8c c0014640 00393531 00000000 c0150000 00000000 c08e5604 [ 0.680297] ffc0: 0000019a c08a7bfc c08a842c c0014640 00000013 00000000 00000000 00000000 [ 0.688812] ffe0: 00000000 c08668bc 00000000 00000000 c0866830 c0014640 55555555 45515555 [ 0.697326] [<c087c74c>] (vm_area_add_early+0x20/0x84) from [<00000000>] ( (null)) [ 0.705322] Code: 059f3068 01a0c003 05933000 0a000010 (e7f001f2) [ 0.711700] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.716552] Kernel panic - not syncing: Attempted to kill init! [ 0.722747] CPU0: stopping [ 0.725646] [<c001a930>] (unwind_backtrace+0x0/0xf8) from [<c0018cf8>] (handle_IPI+0x114/0x140) [ 0.734710] [<c0018cf8>] (handle_IPI+0x114/0x140) from [<c00086c0>] (gic_handle_irq+0x88/0xac) [ 0.743682] [<c00086c0>] (gic_handle_irq+0x88/0xac) from [<c05fa0c0>] (__irq_svc+0x40/0x70) [ 0.752380] Exception stack(0xc08adf70 to 0xc08adfb8) [ 0.757659] df60: ffffffed 00000000 c08adfb8 00000000 [ 0.766174] df80: c08ac000 c0929aa8 c0603f50 c08c9bd8 c08c9d98 412fc09a 00000000 00000000 [ 0.774688] dfa0: 00000000 c08adfb8 c00146bc c00146c0 60000013 ffffffff [ 0.781616] [<c05fa0c0>] (__irq_svc+0x40/0x70) from [<c00146c0>] (default_idle+0x24/0x28) [ 0.790130] [<c00146c0>] (default_idle+0x24/0x28) from [<c001493c>] (cpu_idle+0xfc/0x11c) [ 0.798645] [<c001493c>] (cpu_idle+0xfc/0x11c) from [<c08667e0>] (start_kernel+0x260/0x2b0) [ 0.807342] [<c08667e0>] (start_kernel+0x260/0x2b0) from [<80008044>] (0x80008044)
You can see what's going on in omap_barriers_init() here:
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=blob%...
Does anyone have an idea why pulling in the new stuff in Andrey's tree would provoke this problem? There's a lot of stuff around device tree but I now rebuild the dtb every kernel build, so it shouldn't be that what's in there is out of date.
There's also stuff from rmk-devel-stable.
-Andy
-- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
Hi -
Thanks Nicolas that does seem to be the root cause. Last week I found that barrier init for sram and dram regions cause this problem, so I changed the ordering of their init vs vm init and verified all of the oldstyle memory kidnapping is happening before as is now mandatory.
Unfortunately I still get a freeze after end of kernel boot, I think when it uses the barriers.
Pressure to continue tracking is now intolerable so I had to revert the basis to just Linus tree for now. Although no doubt this stuff is a preview of what we anyway can expect to deal with, maybe by the time it turns up barrier code is also in mainline and adapted.
-Andy
Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 17 Jan 2012, Deepak Saxena wrote:
Is there an update on this at all? Has anyone reported something similar upstream on 3.2 or 3.3-rc?
commit 716a3dc20084da9b3ab17bd125005a5345e23e3b Author: Russell King rmk+kernel@arm.linux.org.uk Date: Fri Jan 13 15:00:51 2012 +0000
ARM: Add arm_memblock_steal() to allocate memory away from the kernel
Several platforms are now using the memblock_alloc+memblock_free+ memblock_remove trick to obtain memory which won't be mapped in the kernel's page tables. Most platforms do this (correctly) in the ->reserve callback. However, OMAP has started to call these functions outside of this callback, and this is extremely unsafe - memory will not be unmapped, and could well be given out after memblock is no longer responsible for its management.
So, provide arm_memblock_steal() to perform this function, and ensure that it panic()s if it is used inappropriately. Convert everyone over, including OMAP.
As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot with this change. Mark this option as BROKEN and make it depend on BROKEN. OMAP needs to be fixed, or 137d105d50 (ARM: OMAP4: Fix errata i688 with MPU interconnect barriers.) reverted until such time it can be fixed correctly.
Signed-off-by: Russell King rmk+kernel@arm.linux.org.uk
On 8 January 2012 23:29, Andy Green andy.green@linaro.org wrote:
Hi -
Andrey has made a nice new branch "linux-linaro-tracking" with some "nexty" goodies in it
http://git.linaro.org/gitweb?p=people/ynk/linux-linaro-tracking.git%3Ba=shor...
I rebased tilt-tracking on top of it at v3.2 basis at the moment.
Quite early in boot, it blows a new BUG() in the code around iotable_init(), I added some debug and see it's blowing up when trying to define io memory in omap_barriers_init(). A bunch of earlier machine-defined iotable_inits go OK.
[ 0.000000] iotable_init: adding addr=DA000000 size=02000000 phys_addr=9A000000 [ 0.000000] iotable_init: adding addr=F8000000 size=00100000 phys_addr=44000000 [ 0.000000] iotable_init: adding addr=FC000000 size=00400000 phys_addr=4A000000 [ 0.000000] iotable_init: adding addr=F9000000 size=00100000 phys_addr=50000000 [ 0.000000] iotable_init: adding addr=FD100000 size=00100000 phys_addr=4C000000 [ 0.000000] iotable_init: adding addr=FD200000 size=00100000 phys_addr=4D000000 [ 0.000000] iotable_init: adding addr=FD300000 size=00100000 phys_addr=4E000000 [ 0.000000] iotable_init: adding addr=FA000000 size=00400000 phys_addr=48000000 [ 0.000000] iotable_init: adding addr=FE800000 size=00800000 phys_addr=54000000 ... [ 0.538024] omap_barriers_init: calling iotable_init [ 0.543243] iotable_init: adding addr=FE600000 size=00100000 phys_addr=AF600000 [ 0.550872] ------------[ cut here ]------------ [ 0.555725] Kernel BUG at c087c74c [verbose debug info unavailable] [ 0.562255] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP [ 0.569610] Modules linked in: [ 0.572845] CPU: 1 Tainted: G W (3.2.0-panda_tracking-topic-syslink-k3u+ #6) [ 0.581451] PC is at vm_area_add_early+0x20/0x84 [ 0.586303] LR is at iotable_init+0xa8/0xbc [ 0.590698] pc : [<c087c74c>] lr : [<c086cd48>] psr: 20000113 [ 0.590698] sp : ef78ff54 ip : ef78fe10 fp : 00000000 [ 0.602691] r10: c086cca0 r9 : 00000000 r8 : 40000001 [ 0.608154] r7 : ef7ffee0 r6 : ef78ff90 r5 : ef7ffec0 r4 : 00000001 [ 0.614959] r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : ef7ffec0 [ 0.621765] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.629394] Control: 10c5387d Table: 8000404a DAC: 00000015 [ 0.635406] Process swapper/0 (pid: 1, stack limit = 0xef78e2f8) [ 0.641662] Stack: (0xef78ff54 to 0xef790000) [ 0.646240] ff40: 00000001 00000000 af600000 [ 0.654754] ff60: c09299e0 ef78e000 00000000 00000000 c0870f8c c0871070 c08d7f9c c08a7bf8 [ 0.663269] ff80: fe600000 000af600 00100000 0000000e c08a7bfc c0008870 0000009f c009f590 [ 0.671783] ffa0: 0000009f c0870f8c c0014640 00393531 00000000 c0150000 00000000 c08e5604 [ 0.680297] ffc0: 0000019a c08a7bfc c08a842c c0014640 00000013 00000000 00000000 00000000 [ 0.688812] ffe0: 00000000 c08668bc 00000000 00000000 c0866830 c0014640 55555555 45515555 [ 0.697326] [<c087c74c>] (vm_area_add_early+0x20/0x84) from [<00000000>] ( (null)) [ 0.705322] Code: 059f3068 01a0c003 05933000 0a000010 (e7f001f2) [ 0.711700] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.716552] Kernel panic - not syncing: Attempted to kill init! [ 0.722747] CPU0: stopping [ 0.725646] [<c001a930>] (unwind_backtrace+0x0/0xf8) from [<c0018cf8>] (handle_IPI+0x114/0x140) [ 0.734710] [<c0018cf8>] (handle_IPI+0x114/0x140) from [<c00086c0>] (gic_handle_irq+0x88/0xac) [ 0.743682] [<c00086c0>] (gic_handle_irq+0x88/0xac) from [<c05fa0c0>] (__irq_svc+0x40/0x70) [ 0.752380] Exception stack(0xc08adf70 to 0xc08adfb8) [ 0.757659] df60: ffffffed 00000000 c08adfb8 00000000 [ 0.766174] df80: c08ac000 c0929aa8 c0603f50 c08c9bd8 c08c9d98 412fc09a 00000000 00000000 [ 0.774688] dfa0: 00000000 c08adfb8 c00146bc c00146c0 60000013 ffffffff [ 0.781616] [<c05fa0c0>] (__irq_svc+0x40/0x70) from [<c00146c0>] (default_idle+0x24/0x28) [ 0.790130] [<c00146c0>] (default_idle+0x24/0x28) from [<c001493c>] (cpu_idle+0xfc/0x11c) [ 0.798645] [<c001493c>] (cpu_idle+0xfc/0x11c) from [<c08667e0>] (start_kernel+0x260/0x2b0) [ 0.807342] [<c08667e0>] (start_kernel+0x260/0x2b0) from [<80008044>] (0x80008044)
You can see what's going on in omap_barriers_init() here:
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=blob%...
Does anyone have an idea why pulling in the new stuff in Andrey's tree would provoke this problem? There's a lot of stuff around device tree but I now rebuild the dtb every kernel build, so it shouldn't be that what's in there is out of date.
There's also stuff from rmk-devel-stable.
-Andy
-- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
linaro-kernel@lists.linaro.org
-
Andy Green -
Deepak Saxena -
Nicolas Pitre