Open Xinmudotmoe opened 8 months ago
内核无法构建
Kernel type and options
- Page Table Layout
- 64KB with 2 levels
注:64KB 3 Levels也会触发mm/huge_memory.c: 在函数‘hugepage_init’中:
././include/linux/compiler_types.h:442:45: 错误:call to ‘__compiletime_assert_381’ declared with attribute error: BUILD_BUG_ON failed: ((16 + (16 - 3))-16) > 11
442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
././include/linux/compiler_types.h:423:25: 附注:in definition of macro ‘__compiletime_assert’
423 | prefix ## suffix(); \
| ^~~~~~
././include/linux/compiler_types.h:442:9: 附注:in expansion of macro ‘_compiletime_assert’
442 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: 附注:in expansion of macro ‘compiletime_assert’
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:50:9: 附注:in expansion of macro ‘BUILD_BUG_ON_MSG’
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
./include/linux/bug.h:24:25: 附注:in expansion of macro ‘BUILD_BUG_ON’
24 | BUILD_BUG_ON(cond); \
| ^~~~~~~~~~~~
mm/huge_memory.c:686:9: 附注:in expansion of macro ‘MAYBE_BUILD_BUG_ON’
686 | MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER > MAX_PAGE_ORDER);
| ^~~~~~~~~~~~~~~~~~
避免在以64K页表为目标时编译 mm/huge_memory.c 关闭透明大页特性. 龙架构下 CONFIG_PAGE_SIZE_64KB 与 CONFIG_TRANSPARENT_HUGEPAGE 配置可能冲突.
不能构建那前面的panic从何而来?
不能构建那前面的panic从何而来?
关掉透明大页配置后构建出来的
ARCH_FORCE_MAX_ORDER设置的是多少?
ARCH_FORCE_MAX_ORDER设置的是多少?
CONFIG_ARCH_FORCE_MAX_ORDER=11 CONFIG_PAGE_SIZE_64KB=y
不过看arch/loongarch/Kconfig 的话, ARCH_FORCE_MAX_ORDER有
default "13" if PAGE_SIZE_64KB
问题是否出在make defconfig
?
make defconfig应该做不到非常智能地解决这个问题。
Just put a static_assert to reject invalid ARCH_FORCE_MAX_ORDER + PAGE_SIZE combinations and tell the user to adjust ARCH_FORCE_MAX_ORDER?
IIUC the static assert (actually a BUILD_BUG_ON) is in-place now. I hit it several days ago building a MIPS kernel.
https://sourceware.org/pipermail/binutils/2024-October/137333.html https://sourceware.org/pipermail/binutils/2024-October/137348.html (EDIT: original submission is missing DCO signoff)
IMO it's overall best to just bump the BFD default maximum page size to 64KiB so every new binary would get aligned as such afterwards.
同时 大多数elf的配置中对齐为0x4000(16k) 这可能与ld.bfd的代码有关