关于禁用编译Kernel 是warning as a error

本文详细介绍了如何在Android Kernel编译过程中取消将警告视为错误的处理方式,通过在Makefile中添加特定参数实现快速迭代模式的需求。

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

android编译Kernel时,从高版本GCC起,就开始把warning作为error对待,比如出现错误:

error, forbidden warning  --等等

这样处理对于想快速见到结果的快速迭代模式来说有点碍手,怎样取消呢?

Kernel\Makefile中找到下面的语句

KBUILD_CFLAGS   :=

之后添加上这个参数:

-Wno-error, 如果还不起作用的话,就使用下面最强的开关


-w , 注意w小写


比如添加之后是这样的:

KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
  -fno-strict-aliasing -fno-common \
  -Werror-implicit-function-declaration \
  -Wno-format-security \
  -Wno-error \

  -w \                                                  //上面不起作用时可以使用这个
  -fno-delete-null-pointer-checks

<think>我们正在处理一个内核调度相关的警告信息:WARNING:CPU:7PID:0at kernel/sched/fair.c这个警告发生在fair.c文件中,属于调度器的一部分(具体来说是CFS调度器)。PID0表示是内核线程(通常是swapper线程)触发的。根据引用[3]中关于Linux进程调度的描述,我们知道CFS调度器并不直接分配时间片,而是通过分配使用比(基于进程的优先级和权重)来调度进程。这种警告通常表示调度器在运行过程中遇到了某种异常情况。分析可能的原因:1.调度器内部状态不一致,例如负载跟踪、组调度权重计算等出现问题。2.可能由于硬件问题(如CPU缓存不一致)导致内核数据损坏。3.内核调度器代码中的BUG,尤其是在特定条件下触发的边界情况。由于错误信息没有给出具体的行号,我们无法直接定位到问题代码。但是,我们可以根据警告信息的内容(在fair.c文件中)以及PID0(内核线程)来推测。常见的解决方案:1.更新内核:该警告可能是已知的内核BUG,新版本可能已经修复。2.检查硬件:特别是内存和CPU,运行内存检测工具(如memtest86+)排除硬件故障。3.检查内核配置:某些调度器相关的配置(如组调度、CONFIG_SCHED_DEBUG等)可能导致问题,尝试使用默认配置。4.收集更多信息:使用dmesg查看完整日志,或者启用内核调试选项(如CONFIG_DEBUG_KERNEL)获取更多上下文。由于引用[2]中提到了一个类似的警告(sysfs_warn_dup),它是由重复创建sysfs文件导致的,但当前问题发生在调度器,因此两者没有直接关联。根据经验,fair.c中的警告通常与负载平衡、组调度权重计算有关。例如,当调度组(sched group)的权重变为0时,调度器可能会触发警告。建议步骤:1.查看完整的dmesg输出,定位到该警告的上下文,看是否有其他相关信息。2.尝试复现问题,记录触发该警告时的系统状态(如运行了哪些进程、负载情况等)。3.搜索内核邮件列表或BUG报告,看是否有类似问题的补丁。如果问题持续存在,可以考虑升级到更新的内核版本,或者向内核社区报告该问题(提供详细的日志和系统信息)。注意:由于内核调度的复杂性,没有通用的解决方案,需要根据具体错误信息进一步分析。相关问题:1.如何分析内核调度警告信息?2.内核调度器(CFS)的基本原理是什么?3.如何调试Linux内核中的问题?</think>### WARNING: CPU: 7 PID: 0 at kernel/sched/fair.c 的解释与解决方案 #### **问题分析** 1. **警告来源**: - 该警告发生在 Linux 内核的公平调度器(CFS)代码中(`fair.c`),这是负责进程时间片分配和负载均衡的核心模块[^3]。 - `PID: 0` 表示触发警告的是内核线程(通常是 `swapper` 或 `idle` 线程),而非用户进程。 - 典型触发场景: - 调度器在负载均衡时检测到非法状态(如空任务队列) - 时间片计算异常(如负值或溢出) - CPU 核心间的任务迁移失败 2. **常见原因**: - **硬件问题**:CPU 缓存不一致或内存故障导致调度数据结构损坏。 - **内核BUG**:特定内核版本的调度器逻辑缺陷(常见于定制内核或新硬件支持)。 - **配置错误**:错误的调度参数(如 `sched_min_granularity_ns` 设置过小)。 - **资源冲突**:CPU 热插拔或节能状态切换时触发的竞争条件。 --- #### **解决方案** 1. **基础排查**: ```bash # 查看完整警告上下文 dmesg | grep "WARNING: CPU: 7" -A 10 # 检查硬件错误日志 grep -i error /var/log/kern.log ``` 2. **针对性修复**: - **更新内核**:升级到最新稳定版内核(修复已知调度器BUG)。 ```bash sudo apt update && sudo apt dist-upgrade ``` - **调整调度参数**(临时缓解): ```bash # 增大最小调度粒度(单位:纳秒) echo 10000000 > /proc/sys/kernel/sched_min_granularity_ns ``` - **禁用节能特性**:若发生在低功耗状态切换时: ```bash # 关闭CPU深度睡眠 sudo sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/&processor.max_cstate=1 /' /etc/default/grub sudo update-grub ``` 3. **深度调试**: - 启用调度器调试: ```bash echo 1 > /sys/kernel/debug/sched/debug ``` - 使用 `perf` 工具捕获调度事件: ```bash perf record -e sched:sched_process* -C 7 -g -- sleep 10 ``` --- #### **预防措施** - **硬件检测**:运行 `memtest86+` 排除内存故障。 - **内核配置**: - 避免启用实验性调度特性(如 `CONFIG_SCHED_DEBUG` 未充分测试时)。 - 确保内核编译选项 `CONFIG_PREEMPT_VOLUNTARY=y` 已启用[^3]。 - **监控工具**:部署 `sysstat` 持续跟踪 CPU 调度延迟: ```bash sar -P 7 1 # 监控7号CPU核心的调度状态 ``` > **关键提示**:若问题在升级内核后仍出现,需向内核社区提交完整日志(包含堆栈跟踪)和 `lscpu`/`dmesg` 输出。调度器警告可能掩盖更深层的硬件兼容性问题[^2]。 --- ### 相关问题 1. Linux 公平调度器(CFS)如何分配进程时间片? 2. 如何解读内核警告日志中的 CPU/PID 信息? 3. 哪些硬件故障会导致内核调度器异常? 4. 如何为特定工作负载优化 Linux 调度器参数? [^1]: 内核链接脚本位置参考 [^2]: 内核模块加载错误与调度器警告的关联性 [^3]: Linux 进程调度机制与 CFS 设计原理
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值