On 9/8/21 2:21 AM, David Hildenbrand wrote:
On 08.09.21 00:40, Sean Anderson wrote:
Hi David,
This patch breaks booting on my custom Xilinx ZynqMP board. Booting
fails just after/during GIC initialization:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.14.0 (sean@plantagenet) (aarch64-linux-gnu-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #251 SMP Tue Sep 7 18:11:50 EDT 2021
[ 0.000000] Machine model: xlnx,zynqmp
[ 0.000000] earlycon: cdns0 at MMIO 0x00000000ff010000 (options '115200n8')
[ 0.000000] printk: bootconsole [cdns0] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x000000087fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fefffff]
[ 0.000000] node 0: [mem 0x0000000800000000-0x000000087fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000087fffffff]
[ 0.000000] On node 0, zone Normal: 256 pages in unavailable ranges
[ 0.000000] cma: Reserved 1000 MiB at 0x0000000041400000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] percpu: Embedded 19 pages/cpu s46752 r0 d31072 u77824
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: detected: ARM erratum 845719
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1033987
[ 0.000000] Kernel command line: earlycon clk_ignore_unused root=/dev/mmcblk0p2 rootwait rw cma=1000M
[ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] software IO TLB: mapped [mem 0x000000003d400000-0x0000000041400000] (64MB)
[ 0.000000] Memory: 3023384K/4193280K available (4288K kernel code, 514K rwdata, 1200K rodata, 896K init, 187K bss, 145896K reserved, 1024000K cma-reserved)
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GIC: Adjusting CPU interface base to 0x00000000f902f000
[ 0.000000] Root IRQ handler: gic_handle_irq
[ 0.000000] GIC: Using split EOI/Deactivate mode
and I bisected it to this patch. Applying the following patch (for 5.14)
fixes booting again:
Hi Sean,
unfortunately that patch most likely (with 99.9999% confidence) revealed another latent BUG in your setup.
I suspected as much; however even after inspecting this patch I was
unsure what I should investigate further.
Some memory that shouldn't be handed to the buddy as free memory is getting now allocated earlier than later, resulting in that issue.
I had all different kinds of reports, but they were mostly
a) Firmware bugs that result in uncached memory getting exposed to the buddy, resulting in severe performance degradation such that the system will no longer boot. [3]
I wrote kstream [1] to be run under the old kernel, to identify these.
b) BUGs that result in unsuitable memory getting exposed to either the buddy or devices, resulting in errors during device initialization. [6]
c) Use after free BUGs.
Exposing memory, such as used for ACPI tables, to the buddy as free memory although it's still in use. [4]
d) Hypervisor BUGs
The last report (heavy performance degradation) was due to a BUG in dpdk. [2]
What the exact symptoms you're experiencing? Really slow boot/stall? Then it could be a) and kstream might help.
Well, as it turns out DDR chips of half the correct size were installed.
This caused the upper half of memory to alias to the lower half. As it
happened, due to some lucky circumstances this didn't initially cause
problems. Sorry for the noise.
--Sean
