Android:meminfo_proc_show() 3.10.65+ 尝试执行 LOS12.1 端口时启动循环内核崩溃
Android: boot loop kernel panic in meminfo_proc_show() 3.10.65+ trying to do a LOS12.1 port
我正在尝试将当前的 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 可以成功启动 stock Android 5.1 并在从 stock 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 和我的 LOS12.1 构建可能出现的问题的任何想法或指示 meminfo_proc_show()!
最终通过对我的 CM12.1 构建的系统分区进行更改(整数,所以我没有追踪到一个特定的更改)来解决,使其更接近库存图像。
由于系统分区(/系统文件系统)中的 "wrong"/buggy 内容,我仍然不知道为什么内核会在从 /proc/meminfo 读取时崩溃,但是作为问题已解决,这可以被视为系统中的此类内容确实对内核行为具有关键影响的证明...
我的Teclast 98 (M1E9) 自定义ROM现在运行良好,我会尽快在xda上发布下载link。
我正在尝试将当前的 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 可以成功启动 stock Android 5.1 并在从 stock 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 和我的 LOS12.1 构建可能出现的问题的任何想法或指示 meminfo_proc_show()!
最终通过对我的 CM12.1 构建的系统分区进行更改(整数,所以我没有追踪到一个特定的更改)来解决,使其更接近库存图像。
由于系统分区(/系统文件系统)中的 "wrong"/buggy 内容,我仍然不知道为什么内核会在从 /proc/meminfo 读取时崩溃,但是作为问题已解决,这可以被视为系统中的此类内容确实对内核行为具有关键影响的证明...
我的Teclast 98 (M1E9) 自定义ROM现在运行良好,我会尽快在xda上发布下载link。