Question

我正在尝试将当前ASB修补的LOS12.1（github“ cm12-amami”）移植到缺少内核源的Teclast 98（M1E9）平板电脑上。我的构建完成得很好，但是，由于内核崩溃（至少对我而言），我陷入了一个引导循环：完全无用的堆栈跟踪：

在init.rc处理期间，当logd尝试使用以下堆栈跟踪读取/ proc / meminfo时，内核在启动logd时会出现紧急情况：

[  126.200788]00:02:29.656321 openat(AT_FDCWD, "/proc/meminfo", O_RDONLY) = 4
[  126.200956]00:02:29.656496 fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[  126.201077]00:02:29.656614 mprotect(0x7faf52b000, 4096, PROT_READ|PROT_WRITE) = 0
[  126.201187]00:02:29.656726 mprotect(0x7faf52b000, 4096, PROT_READ) = 0
[  126.202709]00:02:29.656833 read(4,

*这里出现内核紧急情况！！！ *

[  126.202739]<1> (1)[949:logd]<1>start....
[  126.202805]<1> (1)[949:logd]Unable to handle kernel NULL pointer dereference at virtual address 00000016
[  126.202817]<1> (1)[949:logd]pgd = ffffffc070dee000

[  126.202828]<1> (1)[949:logd][00000016] *pgd=0000000000000000 (1)[949:logd]
[  126.202846]<1> (1)[949:logd][KERN Warning] ERROR/WARN forces debug_lock off!
[  126.202854]<1> (1)[949:logd][KERN Warning] check backtrace:
[  126.202868]<1> (1)[949:logd]CPU: 1 PID: 949 Comm: logd Tainted: G        W    3.10.65+ #1
[  126.202878]<1> (1)[949:logd]Call trace:
[  126.202899]<1> (1)[949:logd][<ffffffc000088f50>] dump_backtrace+0x0/0x16c
[  126.202913]<1> (1)[949:logd][<ffffffc0000890cc>] show_stack+0x10/0x1c
[  126.202931]<1> (1)[949:logd][<ffffffc0009a69a0>] dump_stack+0x1c/0x28
[  126.202947]<1> (1)[949:logd][<ffffffc0002f7210>] debug_locks_off+0x40/0x5c
[  126.202960]<1> (1)[949:logd][<ffffffc00009a260>] oops_enter+0xc/0x28
[  126.202974]<1> (1)[949:logd][<ffffffc000089100>] die+0x28/0x1d8
[  126.202989]<1> (1)[949:logd][<ffffffc0009a49ec>] __do_kernel_fault.part.5+0x70/0x84
[  126.203003]<1> (1)[949:logd][<ffffffc000094260>] do_page_fault+0x348/0x34c
[  126.203017]<1> (1)[949:logd][<ffffffc000094350>] do_translation_fault+0x40/0x4c
[  126.203030]<1> (1)[949:logd][<ffffffc0000813fc>] do_mem_abort+0x38/0x98

这似乎并没有发现根本原因，但是根本原因堆栈跟踪似乎是：

[  133.341226]<1>-(1)[949:logd]Call trace:
[  133.341239]<1>-(1)[949:logd][<ffffffc0001f37d8>] meminfo_proc_show+0x50/0x3c4
[  133.341255]<1>-(1)[949:logd][<ffffffc0001aefb8>] seq_read+0x1a4/0x40c
[  133.341271]<1>-(1)[949:logd][<ffffffc0001ebeec>] proc_reg_read+0x4c/0x7c
[  133.341285]<1>-(1)[949:logd][<ffffffc00018e75c>] vfs_read+0x88/0x170
[  133.341298]<1>-(1)[949:logd][<ffffffc00018ebf0>] SyS_read+0x40/0x8c
[  133.341310]<1>-(1)[949:logd]Code: 52800001 91326000 97fe67c1 aa0003f3 (f9400c00) 
[  133.341322]<1>-(1)[949:logd]---[ end trace 1b75b31a2719ed20 ]---
[  133.341332]<1>-(1)[949:logd]Kernel panic - not syncing: Fatal exception
[  133.341423]<1>-(1)[949:logd]mrdump: cpu[1] tsk:ffffffc073a3e000 ti:ffffffc070e64000
[  134.241428]<1>-(1)[949:logd]

最有趣的是，完全相同的内核blob可以成功启动股票Android 5.1，并从股票boot.img启动时成功从/ proc / meminfo读取，而它因我的LOS12.1构建boot.img而崩溃。

bootimg.cfg（使用abootimg）在两种情况下都是相同的（启动大小除外）：

bootsize = 0x780000
pagesize = 0x800
kerneladdr = 0x40080000
ramdiskaddr = 0x44000000
secondaddr = 0x40f00000
tagsaddr = 0x4e000000
name = 1513588375
cmdline = bootopt=64S3,32N2,64N2 androidboot.selinux=permissive

预先感谢一百万个关于此备用内核blob可能出问题的想法或指针，以及关于meminfo_proc_show（）的LOS12.1版本！

Answer 1

最后通过对CM12.1构建的系统分区进行更改（进行了很多更改，因此我没有将其跟踪到某个特定更改）来解决，从而使其与库存图像更相似。

我仍然没有任何线索为什么内核会由于系统分区（/系统文件系统）中的“错误” /错误内容而从/ proc / meminfo读取时崩溃，但是随着问题得以解决，这可以被视为系统中此类内容确实对内核行为至关重要的证明……

我为Teclast 98（M1E9）定制的ROM现在运行良好，我将很快在xda上发布下载链接。

Android：meminfo_proc_show（）3.10.65+中的启动循环内核崩溃试图执行LOS12.1端口

1 个答案: