Repository navigation
sm8650_b_16.0.0 分支 block/blk-mq.c 重复导出 test_task_ux，按源码编译的内核开机崩溃 / Duplicate test_task_ux export breaks first-stage module loading #42
Description
受影响分支
block/blk-mq.c 中存在 EXPORT_SYMBOL_GPL(test_task_ux); 的分支：
oneplus/sm8650_b_16.0.0_oneplus12oneplus/sm8650_b_16.0.0_ace_3_prooneplus/sm8650_b_16.0.0_ace_5oneplus/sm8650_b_16.0.0_oneplus_13roneplus/sm8650_b_16.0.0_pad2
v_15.0.0、u_14.x 各分支没有这一行。
现象
按以上分支源码编译的内核刷入后开机即崩溃，与 #35 描述一致。
原因
厂商模块源码 vendor/oplus/kernel/cpu/sched/sched_assist/sa_common.c（android_kernel_modules_and_devicetree_oneplus_sm8650）本身已经定义并导出了 test_task_ux，编译为 oplus_bsp_sched_assist.ko，位于 vendor_boot 的第一阶段 modules.load 中。
内核再导出同名符号后：
oplus_bsp_sched_assist.ko因重复导出被拒绝加载；sched-walt.ko、oplus_bsp_schedinfo.ko、oplus_bsp_eas_opt.ko、oplus_bsp_qos_sched.ko解析到内核里的test_task_ux，CRC 不符（模块期望0x6aae72bc，内核为0x41fa1ee1）；
这些都是第一阶段模块，加载失败后 first stage init 直接失败。
作为对照，量产 OTA 内核并不导出 test_task_ux（由 oplus_bsp_sched_assist.ko 提供）。对量产内核与设备上全部 vendor_boot / vendor_dlkm 模块逐一核对符号与 CRC，结果完全一致；对按源码编译的内核核对，致命差异只有上述 test_task_ux 一处。
建议
删除 block/blk-mq.c 中的 EXPORT_SYMBOL_GPL(test_task_ux);。f2fs 对它是内建调用，不需要导出。
另外
量产 OTA 内核自 ColorOS 15 起启用了 CONFIG_HMBIRD_SCHED，并导出 task_is_scx、hmbird_dir、scx_get_md_info 等符号，供 oplus_bsp_sched_ext.ko、oplus_bsp_game_opt.ko 使用，但公开的源码中没有这部分实现。这不影响开机，但公开源码与实际内核不一致，希望一并补齐。
EN: On the sm8650_b_16.0.0_* branches listed above, block/blk-mq.c exports test_task_ux, but the vendor module oplus_bsp_sched_assist.ko (first-stage, from sched_assist/sa_common.c) already exports the same symbol. The duplicate export makes that module fail to load, and sched-walt.ko etc. then hit a CRC mismatch on test_task_ux (expected 0x6aae72bc, kernel 0x41fa1ee1), so first-stage init fails and the device bootloops (see #35). Production OTA kernels do not export it. Please drop EXPORT_SYMBOL_GPL(test_task_ux); from block/blk-mq.c. Also, OTA kernels since ColorOS 15 enable CONFIG_HMBIRD_SCHED, which is missing from the published source.
Activity
fatalcoder524 commentedon Oct 28, 2026
Hi @siri666666
Can you explain how you came to this conclusion and is there a way you got this from device logs? If yes, how did you get the logs!
Getting early boot logs of failed boots on OnePlus is difficult or not well documented!
siri666666 commentedon Oct 28, 2026
No device logs — I couldn't get early boot logs either (the 900E minidump was encrypted). It's a static check:
boot.img, and all modules fromvendor_boot(first-stagelib/modules/modules.load) and/vendor_dlkm/lib/modules.__ksymtab_strings(its own exports) and__versions(expected CRCs).Image, locate__ksymtab(PREL32 entries) and the__kcrctabthat follows it, which gives the exported names and CRCs.The stock kernel gives zero diffs, which validates the parser. A kernel built from
sm8650_b_16.0.0_pad2gives exactly one first-stage problem:test_task_uxis exported by bothblock/blk-mq.candoplus_bsp_sched_assist.ko, andsched-walt.ko,oplus_bsp_schedinfo.ko,oplus_bsp_eas_opt.ko,oplus_bsp_qos_sched.kothen hit a CRC mismatch on it. After dropping the export, there are zero first-stage diffs. Since a failed first-stage module load makes init fail, that explains the bootloop.Script: https://github.com/siri666666/OKI-AK3-Builder/blob/main/tools/kernel_compat_check.py
block: don't export test_task_ux, vendor module already exports it
Fix bootloop caused by export test_task_ux
Fix bootloop caused by export test_task_ux
block: don't export test_task_ux, vendor module already exports it
block: don't export test_task_ux, vendor module already exports it
fatalcoder524 commentedon Nov 3, 2026
Reports from my users:
Tried something similar to Alhugh233/android_kernel_common_oneplus_sm7675@f10f8e3
Will update if other device users report the results!
Edit:-
The solution works as expected. OnePlus broke more stuff on Nord 5 and Nord 4 OOS 16 branches when upstreaming to 6.1.157.
Solution tested on
Add revert patches to fix bootloops in a14-6.1.141+ OnePlus kernels
Fix bootloop caused by export test_task_ux