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;a=shortlog;h=refs/heads/linux-linaro-tracking
> >
> > 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;a=blob;f=arch/arm/mach-omap2/omap4-common.c;h=ad8c30d610736dde454bfe81f764f4a98b902dbf;hb=refs/heads/temp#l97
> >
> > 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/#!/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
>