kexec fails with 3.18.12

[wbx-github]

Hi,

we implemented some firmware update mechanism. You can upload a new firmware
to a second partition on the SD card and then use kexec to boot into the new firmware
including a new kernel. When the bootup works fine, the U-Boot configuration is changed,
so on next boot, the new kernel and system is used.
With 3.12.x and ATAGS this worked fine. Now I tried today with 3.18.12 with device-tree enabled.

I get following crash:
kreboot
Currten Kernel Partition: /dev/mmcblk0p2
Partition Number 2
Partiton without number: mmcblk0p
Current Device: /dev/mmcblk0p2
mount -r /dev/mmcblk0p3 /mnt
Device Tree available
Modified cmdline:dma.dmachans=0x7f35 sdhci-bcm2708.emmc_clock_freq=250000000 console=ttyAMA0,9600 root=/dev/mmcblk0p3 ro�o�ooting Linux on physical CPU 0x0
Linux version 3.18.12 (wbrodkorb@wbrodkorb-ws) (gcc version 4.9.2 (GCC) ) #1 Wed May 6 11:34:41 CEST 2015
CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine model: Raspberry Pi Model B
cma: Reserved 128 MiB at 0x14000000
Memory policy: Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: dma.dmachans=0x7f35 sdhci-bcm2708.emmc_clock_freq=250000000 console=ttyAMA0,9600 root=/dev/mmcblk0p3 rootwait smsc95xx.macaddr=00:50:C2:F9:22:F4
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Sorting __ex_table...
BUG: Bad page state in process swapper pfn:0e400
page:d3e00000 count:0 mapcount:0 mapping:fff70028 index:0xfff6002a
flags: 0x7ff80026(error|referenced|lru|swapbacked|unevictable|mlocked)
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
bad because of flags:
flags: 0x300020(lru|unevictable|mlocked)
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.12 #1

Any ideas what is causing this? Will enable symbols now for the backtrace.

[popcornmix]

Any different with DT disabled (add device_tree= to config.txt to disable).

[wbx-github]

Hi,
yes, with DT disabled it works.

With DT:

Device Tree available
kernel: 0xb6a0e008 kernel_size: 0x1dba7c
Modified cmdline:dma.dmachans=0x7f35 sdhci-bcm2708.emmc_clock_freq=250000000 console=ttyAMA0,9�o** 137 printk messages dropped ** [<c03900c4>] (mem_init) from [<c038daec>] (start_kernel+0x1b4/0x2e4)
 r7:c03b0000 r6:ffffffff r5:c03d4e00 r4:00000000
[<c038d938>] (start_kernel) from [<00008068>] (0x8068)
 r9:410fb767 r8:00004008 r7:c03b2ab0 r6:c03a3720 r5:c03b0020 r4:c03d4f74
BUG: Bad page state in process swapper  pfn:0e404
page:d3e00080 count:0 mapcount:-393219 mapping:fffbfffc index:0xfffafffc
flags: 0xfffbfbf9(locked|uptodate|dirty|lru|active|slab|owner_priv_1|arch_1|private|private_2|writeback|head|tail|swapcache|mappedtodisk|swapbacked|unevictable|mlocked)
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
bad because of flags:
flags: 0x3138e1(locked|lru|active|slab|private|private_2|writeback|swapcache|unevictable|mlocked)
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: G    B          3.18.12 #5
Backtrace:
[<c00107cc>] (dump_backtrace) from [<c00109a8>] (show_stack+0x18/0x1c)
 r6:00313ce1 r5:d3e00080 r4:c03f9b1c r3:00200000
[<c0010990>] (show_stack) from [<c02b2590>] (dump_stack+0x20/0x28)
[<c02b2570>] (dump_stack) from [<c005c808>] (bad_page+0xe0/0x10c)
[<c005c728>] (bad_page) from [<c005c8d0>] (free_pages_prepare+0x9c/0xec)
 r7:00000004 r6:00000400 r5:00000004 r4:d3e00080
[<c005c834>] (free_pages_prepare) from [<c005dc18>] (__free_pages_ok+0x24/0xa0)
 r9:c03a9efc r8:c03a9ef8 r7:d3e00000 r6:0000000a r5:d3c38000 r4:00000000
[<c005dbf4>] (__free_pages_ok) from [<c005e2b4>] (__free_pages+0x44/0x48)
 r7:c03a9f00 r6:00000350 r5:00000000 r4:00000000
[<c005e270>] (__free_pages) from [<c0395450>] (__free_pages_bootmem+0x98/0xa0)
 r4:000003ff r3:00000001
[<c03953b8>] (__free_pages_bootmem) from [<c0396ee0>] (free_all_bootmem+0xf4/0x164)
 r5:00000772 r4:00013bc8
[<c0396dec>] (free_all_bootmem) from [<c03901a4>] (mem_init+0xe0/0x274)
 r10:003a2d98 r9:d3fffbe0 r8:c03a3724 r7:c03f9c84 r6:0000000c r5:c03ca878
 r4:c03f9d00
[<c03900c4>] (mem_init) from [<c038daec>] (start_kernel+0x1b4/0x2e4)
 r7:c03b0000 r6:ffffffff r5:c03d4e00 r4:00000000
[<c038d938>] (start_kernel) from [<00008068>] (0x8068)
 r9:410fb767 r8:00004008 r7:c03b2ab0 r6:c03a3720 r5:c03b0020 r4:c03d4f74

[pelwell]

1. 9600 baud is very slow for a serial port - you shouldn't be seeing lost messages at that stage in the boot process. I run at 115200 with no problems.

2. What is the origin of your kernel? Are you using bcm2709_defconfig?

3. What is in your config.txt? Any specialised settings such as initramfs?

[wbx-github]

1.) I can not change it, the boss decided a while ago to use 9600 as most Cisco devices use.
2.) it is a raspberry pi 1 b
The kernel configuration is generated via a buildsystem, the result used is here
http://www.openadk.org/rpi
3.) nothing special:
kernel=kernel
start_file=start.elf
fixup_file=fixup.dat

Okay, I identified the problem. When using u-boot as intermediate bootloader it
does fail. When using the broadcom bootloader only, everything is fine.

Hmpf. So a u-boot problem?

[pelwell]

Similar stack traces I've found online have been caused by the kernel memory overlapping something else - the compressed kernel, etc. From my previous experience with u-boot I recall you have to compile it to run at a particular base address - I suggest you look at that configuration and think about your memory layout.

[wbx-github]

But this means that u-boot+kernel-with-dt uses another memory layout than u-boot+kernel-without-dt?

[pelwell]

No - the layout is the largely the same, except that more of the first 32KB is used to hold the DT blob.

Does your u-boot implementation preserve that space? I presume it must be passing on the address of the DTB in r2, since that mechanism is also used for ATAGs.

Is it possible that u-boot is making use of the ATAGs provided by the firmware, and that their absence (as hinted at above, you either provide ATAGs or DTB, but not both) is causing problem?

[notro]

If you want the GPU provided dtb, this may apply to your case: How to U-Boot with FDT on a Pi 2?

[wbx-github]

I changed the u-boot settings to use following:
fdt_addr_r=0x00000100
scriptaddr=0x02000000
mmc_boot1=setenv bootargs ${boot_common_args} ${bootargs1} ${boot_extra_args}; ext4load mmc ${mmcdev}:${mmcpart1} ${kernel_addr_r} ${boot_prefix}${boot_kernel}; bootz ${kernel_addr_r} - ${fdt_addr_r}

But kexec still fails. So u-boot uses the DTB provided by the GPU bootloader in 0x00000100.
u-boot.bin is marked via mkknlimg.

[Ruffio]

@wbx-github has your issue been resolved? If so, please close this issue. Thanks.

[popcornmix]

Duplicate of #27