KernelPatch 0.13.8 fundamental incompatibility with MTK 4.14 (begonia/Redmi Note 8 Pro)

[1ARCH-USER1]

Upstream Report: KernelPatch Incompatibility with MTK 4.14 (begonia/Redmi Note 8 Pro)

Device Information

• Codename: begonia
• Device: Redmi Note 8 Pro (Xiaomi)
• Platform: MT6785 (MTK)
• Kernel: 4.14.356-openela-rc1-Suzakukernel-V2
• Compiler: Clang version 11.0.1 (Android build)
• KP version: 0.13.8 (d08)

Executive Summary

KernelPatch's early-boot virtual-memory rework (_paging_init + memblock reserve/alloc/image relocation) is fundamentally incompatible with this MTK 4.14 kernel across ALL KP versions (0.13.0 through 0.13.8), even with zero hooks installed. The fault is in KP's core boot-time mapping machinery, not the hook subsystem or feature toggles.

Cross-Version Behavioral Matrix (all fresh-repatched from boot_work.img)

kpimg	map/start path	failure mode	time->recovery	boots?
stock (no KP)	n/a	none	n/a	YES
0.13.8 d08	new _paging_init	quick crash → recovery	~1 min	NO
0.13.8 no-hooks (patch()=0)	none	quick crash → recovery	~1 min	NO
0.13.0 d00	old/simple paging	LONG hang → recovery	~7 min	NO
0.13.7 d07	intermediate	LONG hang → recovery	~7 min	NO

Key observation: 0.13.0/0.13.7 with the old simpler paging path ALSO fail. This is NOT a 0.13.8 regression — the entire KP early mapping path is incompatible with this device.

Root-Cause Localization

1. Memblock 5-arg argument fragility (CONFIRMED)

On begonia, memblock_phys_alloc_try_nid (3-arg) is absent from the kernel. The patcher falls back to the 5-arg memblock_alloc_try_nid(size, align, min_addr, max_addr, nid).

The bug: KP's map_phys_alloc() calls through a 3-arg typedef memblock_phys_alloc_try_nid_f(size, align, int nid) even when the resolved function is the 5-arg memblock_alloc_try_nid. Only x0=size, x1=align, x2=third_arg(=0) are set; x3 (max_addr) and x4 (nid) hold garbage from registers at the call site.

Consequence: In memblock_alloc_try_nid, if the garbage max_addr lands below min_addr=0, the range is empty, allocation fails, start_pa returns 0, and the paging hook relocates the kernel into physical address 0 → init SIGSEGV at ~2.4s.

Evidence:

• Patch log line 53-56: [?] no symbol: memblock_phys_alloc_try_nid / [+] use memblock_alloc_try_nid as map phys alloc
• Upstream 0.13.8 map.c lines 54-64 already has the third_arg distiction but it's insufficient when the 5-arg path is taken with garbage max_addr

Fix: When memblock_phys_alloc_type == MAP_SYM_MEMBLOCK_ALLOC_TRY_NID, call the 5-arg function with all 5 arguments properly: (size, align, 0, ~0ULL, 0) — i.e., min_addr=0, max_addr=anywhere, nid=0.

2. mem_proc linear_voffset probe (same class of bug)

The linear map offset detection at map.c lines 140-149 calls memblock_phys_alloc_try_nid(0, 0x10, NUMA_NO_NODE) through the 3-arg typedef against the 5-arg function, producing garbage detect_phys → linear_voffset is wrong → kernel image relocation is wrong → later crash.

Fix: Same pattern — detect the memblock_phys_alloc_type and call the 5-arg memblock_alloc_try_nid with all 5 args when needed.

3. Fundamental KP/core incompatibility (CONFIRMED by cross-version)

• 0.13.8 (new _paging_init scratch path, gated to 6.x via new_era = kmajor > 5) → crashes on 4.14 taking legacy path
• 0.13.0 (old simple paging, no scratch) → crashes with long hang
• 0.13.7 (intermediate) → crashes
• Zero-hooks build (patch() returns 0 immediately, no panic/rest_init/kernel_init hooks installed) → still crashes
• Conclusion: The bug is in KP's early start.c/map.c mapping code, not the hook subsystem or feature toggles. The entire _paging_init/_paging_init rework approach is incompatible with this MTK 4.14 kernel.

Diagnostic Channels

/sys/fs/pstore/console-ramoops — USELESS

• Returns the same 27711-byte dump (md5 912f79c4358489313533346be5c068d8) every crash
• Even after rm -f and a fresh crash
• MTK crashes go through mrdump/aee path which does NOT refresh console-ramoops

/dev/block/by-name/expdb — RELIABLE CRASH CHANNEL

• Captures fresh mrdump crash logs via MTK's mrdump/aee mechanism
• Contains full backtrace: dump_backtrace → mrdump_common_die → make_task_dead → panic → ipanic
• KP bootlog lines NOT observed in the kernel log immediately before panic — meaning KP's printk either doesn't reach the log buffer before crash, or the mrdump RAM console capture starts after KP's phase
• 20MB partition, always openable without a mounted filesystem

File-dump to /cache/``/data//sdcard` — FAILS

• Partitions are not mounted at 2.4s crash time during normal boot
• filp_open/kernel_write silently fail (or before_panic never runs)

Evidence Summary

Evidence Type	Result
Cross-version matrix (0.13.0/0.13.7/0.13.8)	ALL crash → fundamental incompatibility
Zero-hooks build	Still crashes → fault in core mapping, not hooks
Memblock 5-arg fragility	Confirmed bug; fixable but not sole root cause
pstore console-ramoops	STALE — unusable
File-dump to /cache /data /sdcard	Fails (partitions not mounted at crash)
Expdb mrdump channel	Fresh crash logs captureable; KP lines not visible
Custom tail-return in start.c	Present in upstream 0.13.8; may contribute but not sole cause

Requested Actions for Upstream

1. Add a 4.x-safe mapping path or config option in KP to bypass the _paging_init rework on kernels where it's known incompatible (similar to the new_era = kmajor > 5 gate, but for specific known-incompatible devices/SoCs).

2. Fix the memblock 5-arg calling convention in map_phys_alloc() and mem_proc() to pass all 5 arguments when the resolved function is the 5-arg memblock_alloc_try_nid (rather than the 3-arg typedef call that leaves max_addr/nid as garbage).

3. Consider a device-specific quirk for MTK 4.14 kernels (begonia, sagit, etc.) that notes the absent memblock_phys_alloc_try_nid symbol and the fallback path fragility.

4. Enable the expdb diagnostic channel in future KP releases so developers can capture fresh crash logs via mrdump → expdb for post-crash analysis.

Maintainer Notes

• This is NOT a 0.13.8 regression — the issue exists in 0.13.0 and 0.13.7 as well, confirming it's a fundamental KP/core incompatibility with this device's MTK 4.14 kernel.
• The new_era = kmajor > 5 gate in map.c correctly routes 4.14 to the legacy path, but the legacy path itself has device-specific breakage (the 5-arg memblock calling convention).
• The two anonymous panic frames (offset 0x17f8ff3d8 / 0x17f901204) are KP core code in the vmalloc region it allocates during early mapping — not user-space or init code.
• pstore console-ramoops is NOT usable for observing fresh crashes on MTK devices; use the expdb mrdump channel instead.

---

Report generated from extensive behavioral bisection on real device (begonia, adb serial 8t9dl7ukaulvh6h6). All test images flashed via TWRP dd if=/sdcard/*.img of=/dev/block/by-name/boot bs=4k. Device restored to working stock V2 after testing.