关于kernel log level的基础知识

本文详细介绍了Linux内核中printk函数的优先级设置及其显示规则。包括如何定义不同级别的日志输出,如何调整控制台的日志级别以改变显示的内容,以及如何通过特定命令查看所有级别的日志。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

kernel中用printk来打印debug信息,关于printk有一个level的定义。

3.10.40\include\linux\kern_levels.h

#define KERN_EMERG KERN_SOH "0" /* system is unusable */
#define KERN_ALERT KERN_SOH "1" /* action must be taken immediately */
#define KERN_CRIT KERN_SOH "2" /* critical conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
#define KERN_NOTICE KERN_SOH "5" /* normal but significant condition */
#define KERN_INFO KERN_SOH "6" /* informational */
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
上面定义了8个level的优先级,其中0的优先级最高,7的优先级最低。

#define KERN_DEFAULT KERN_SOH "d" /* the default kernel loglevel */
定义了kernel默认的loglevel。

如果KERN_DEFAULT = 4,那么printk默认的loglevel=4,那么0,1,2,3等级的log可以在控制台直接显示,4或4后面的log无法在控制台直接显示。
但是可以通过cat /proc/kmsg或dmesg的方式查看输出内容。

可以使用如下方式进行打印logLevel=1的打印:
printk(KERN_ALERT "word_count_init_sucess \n");
or
printk("1"  "word_count_init_sucess \n");
通过如上方式指定printk的输出优先级。

可以在控制台查看printk和控制台默认输出的logLevel:
shell@coconut:/ # cat /proc/sys/kernel/printk
4 4 1 7
其中第一个参数表示控制台logLevel,第二个参数表示printk默认的logLevel
即目前的设定,printk默认的输出level是4,控制台logLevel=4,表示printk输出level为0,1,2,3才可以在控制台直接显示,现在直接用printk打印是无法显示的,因为logLevel太低。

可以这样修改控制台的logLevel:
echo 8 > /proc/sys/kernel/printk
shell@coconut:/ #cat  /proc/sys/kernel/printk
8 4 1 7
这样printk的输出都可以在控制台显示了,因为printk的level总是会比控制台的高。
<think>嗯,用户这次的问题转向了安卓系统在CPU卡死时的日志分析,特别是SYS_LAST_CPU_BUS字段的显示情况,还关联到安卓15(实指4.0)的kernel版本3.0.1。这显然是个深度技术问题,用户可能是系统开发工程师或内核调试人员。回顾对话历史,我之前明确解释了安卓15(APILevel15)对应的是Android4.0.x,内核版本3.0.1。这个版本的内核确实比较旧(2011年发布),其调试机制与现代内核差异较大。用户引用的三条站内参考其实都是关于sysrq和内核重启的,但ta真正关心的却是SYS_LAST_CPU_BUS这个特定字段——这属于内核调试基础架构(KD)的范畴。需要特别注意三点技术细节:首先,SYS_LAST_CPU_BUS这个名称更像是特定厂商自定义的日志标签(比如华为麒麟芯片的日志里就常见这类字段),并非标准内核字段;其次,在3.0.x内核时代,panic处理机制比较简陋,很多现代调试功能尚未引入;最后,CPU完全卡死时日志输出依赖于硬件看门狗或NMI中断,当时这些支持也不完善。考虑到用户的专业程度,应该深入解释三个技术层:该字段的理论意义(指示死锁前最后活跃的CPU核心)、实际获取障碍(内存缓冲区未刷新导致丢失日志)、具体解决方法(需结合kmsg和ramconsole)。用户提供的示例日志显示系统曾触发EXCEAP异常重启,这提示我应当关联分析硬件看门狗的工作机制。对于安卓4.0这种老系统,真实的调试建议反而要降低预期:在用户空间完全冻结时,通过sysrq触发kdb或JTAG调试更现实。不过还是要给出可操作的排查步骤,比如建议检查/proc/last_kmsg这个历史遗留接口——尽管在新系统里它已被pstore替代。用户特别强调“尽可能参考上次回答”,所以必须延续之前对内核版本的严谨态度。上次提到sysrq在死机时失效的问题(引用1),这次正好可以呼应:当CPU彻底锁死,不仅仅是sysrq无效,所有软件级日志收集都会失效,这就是为什么需要建议硬件级调试手段。三个生成的问题需要层层递进:从日志捕获原理(解决当前问题)到跨版本差异(扩展知识边界),最后回到真实死机案例处理(实践指导)。尤其要强调3.0.1与4.x以上内核在ramoops机制的根本区别,这是用户后续可能遇到的坎。</think> 在Android 4.0.x(API Level 15)搭载的 **Linux Kernel 3.0.1** 环境下,当系统出现CPU彻底卡死时,`SYS_LAST_CPU_BUS`日志的捕获面临根本性限制。以下是具体分析: --- ### 一、**内核卡死时的日志输出机制** 1. **日志缓冲区依赖** Android内核日志通过`kernel log buffer`(环形缓冲区)暂存,最终由用户态进程`logd`写入文件。但当CPU完全锁死时: - 内核停止调度用户态进程(包括`logd`),日志**无法从缓冲区刷新到存储设备**[^1]。 - 若卡死前缓冲区未写入`SYS_LAST_CPU_BUS`相关信息,**该日志将永久丢失**。 2. **硬件看门狗的影响** 部分设备会触发硬件看门狗(如`resetlog`机制)强制重启[^2][^3]: ```bash # 示例日志中的硬件级复位记录(但无CPU核心状态) [17440.122100] sysreboot reason: Software EXCE AP... [^2] ``` - 这种重启**不会保存CPU死锁瞬间的运行时状态**(如寄存器值、堆栈)。 - `SYS_LAST_CPU_BUS`需依赖软硬件协同调试能力,而Kernel 3.0.x对此支持有限。 --- ### 二、**获取`SYS_LAST_CPU_BUS`的可行性分析** #### 1. **理想场景(非完全死锁)** - 若CPU未完全冻结,可通过`sysrq`触发内核调试: ```bash echo c > /proc/sysrq-trigger # 强制崩溃以捕获panic日志[^1] ``` - 此时`dmesg`或`/proc/last_kmsg`**可能**包含卡死前的核心状态(包括最后活跃CPU)。 #### 2. **完全死锁场景(现实常见)** | 机制 | Kernel 3.0.1支持情况 | 能否捕获`SYS_LAST_CPU_BUS` | |---------------------|--------------------------|--------------------------| | 内存映射调试接口 | ❌ 无`pstore/ramoops` | 不可能 | | JTAG硬件调试 | 依赖设备厂商实现 | 需专用工具 | | SysRq组合键 | 部分按键在死锁时失效[^1] | 极低概率 | --- ### 三、**解决方案建议(针对Kernel 3.0.1)** 1. **结合内核崩溃日志** 检查重启后`/proc/last_kmsg`(若有): ```bash adb shell cat /proc/last_kmsg | grep "CPU\|BUS" ``` - 可能找到类似`CPU1: stuck for 10s!`的**间接线索**(非精确字段)。 2. **启用底层跟踪** 修改内核配置(需重新编译): ```makefile CONFIG_SCHED_DEBUG=y CONFIG_DETECT_HUNG_TASK=y # 增强死锁检测 ``` - 此配置可能输出`blocked_task`信息(但非`SYS_LAST_CPU_BUS`)。 3. **替代方案:使用外接调试器** 通过JTAG或Arm CoreSight捕获CPU指令流,定位死锁点。 --- > **结论**:在**Android 4.0.x(Kernel 3.0.1)**环境下,由于日志机制和调试能力限制,完全CPU死锁时**几乎无法直接获取`SYS_LAST_CPU_BUS`字段**。需依赖硬件级调试或升级到更高内核版本(≥4.4)以支持`ramoops`等持久化日志机制。 --- **
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值