wandboard SMP panic

[Andrew Turner]

On Sun, 24 Aug 2014 10:02:28 -0600
Ian Lepore <ian at FreeBSD.org> wrote:

> On Sun, 2014-08-24 at 11:05 +0100, Andrew Turner wrote:
> > On Sat, 23 Aug 2014 18:57:57 -0600
> > Tom Everett <tom at 0x544745.com> wrote:
> > 
> > > 
> > > Hello everyone.  I am seeing a new panic booting Wandboard:
> > > 
> > > Loaded DTB from file 'wandboard-quad.dtb'.
> > > 
> > > 
> > > Kernel entry at 0x12000100...
> > > 
> > > 
> > > Kernel args: (null)
> > > 
> > > 
> > > KDB: debugger backends: ddb
> > > KDB: current backend: ddb
> > > Copyright (c) 1992-2014 The FreeBSD Project.
> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,
> > > 1993, 1994 The Regents of the University of California. All
> > > rights reserved. FreeBSD is a registered trademark of The FreeBSD
> > > Foundation. FreeBSD 11.0-CURRENT #0 r270430M: Sat Aug 23 17:24:21
> > > MDT 2014 
> > > tom at bernice:/storage/home/tom/crochet/crochet-freebsd/work/obj/arm.armv6/storage/home/tom/crochet/src/FreeBSDHead/head/sys/IMX6 
> > > arm
> > > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)
> > > 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core)
> > >   Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4
> > > Security_Ext WB disabled EABT branch prediction enabled
> > > LoUU:2 LoC:1 LoUIS:2
> > > Cache level 1:
> > >   32KB/32B 4-way data cache WB Read-Alloc Write-Alloc
> > >   32KB/32B 4-way instruction cache Read-Alloc
> > > real memory  = 2147483648 (2048 MB)
> > > avail memory = 2093891584 (1996 MB)
> > > WARNING: Some AP's failed to start
> > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> > > random device not loaded; using insecure entropy
> > > panic: Built bad topology at 0xc2510fb4.  CPU mask (f) != (1)
> > > cpuid = 0
> > > KDB: enter: panic
> > > [ thread pid 0 tid 100000 ]
> > > Stopped at      $d:     ldrb    r15, [r15, r15, ror r15]!
> > > db>
> > 
> > I had a similar problem. It turned out to be a caching issue in
> > U-Boot. It appears to not correctly flush the dcache. You can try
> > to run "dcache off ; dcache flush" before entering ubldr. If this
> > fails you will need to build a version of U-Boot with the dcache
> > disabled.
> > 
> > Andrew
> 
> That's interesting... how are y'all launching ubldr, with a 'go'
> command?  It's been my experience that the bootelf and bootm commands
> manage the cache correctly, but go doesn't.  You can launch ubldr with
> bootelf (it has proper elf headers) but you can't launch the kernel
> directly that way.  But the stock u-boot might not have bootelf.

This was with the bootelf command. I never tracked down why it was
failing to flush the cache correctly and in the end disabled it.

Andrew