如何测试内核是否出现内核恐慌？
我正在嵌入式设备上测试 Linux 内核，并希望找到 Linux 内核会发出紧急情况的情况/场景。
您能否建议一些测试步骤（手动或自动代码）来创建内核恐慌？
I am testing the Linux Kernel on an embedded device and would like to find situations / scenarios in which Linux Kernel would issue panics.
Can you suggest some test steps (manual or code automated) to create Kernel panics?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用多种工具来尝试使计算机崩溃：
crashme 尝试随机执行代码;这对于测试流程生命周期代码很有用。
fsx 是一个尝试广泛运用文件系统代码的工具；它非常适合测试驱动程序、块 io 和文件系统代码。
Linux 测试项目 旨在创建一个大型的内核测试用例存储库；它可能不会特别考虑崩溃系统，但它可能会在帮助您和您的团队保持一切按计划运行方面大有帮助。 （请注意，LTP 并不是禁止性的——内核社区并不将他们的测试视为任何重要的事情——但是 LTP 团队非常努力地对内核做什么和不做什么。）
如果您的设备已连接网络，您可以对其运行 nmap ，使用各种扫描选项：
-sV --version-all将尝试查找所有正在运行的服务的版本（这可能会带来压力），-O --osscan-guess> 将尝试通过向机器抛出奇怪的网络数据包并通过响应猜测输出是什么来确定操作系统。nessus 扫描工具还可以对正在运行的服务进行版本识别；不过，它可能会也可能不会对 nmap 提供任何改进。
您还可以将您的设备交给用户；他们找出软件中最疯狂的事情，他们会发现你从未想过要寻找的错误。 :)
There's a variety of tools that you can use to try to crash your machine:
crashme tries to execute random code; this is good for testing process lifecycle code.
fsx is a tool to try to exercise the filesystem code extensively; it's good for testing drivers, block io and filesystem code.
The Linux Test Project aims to create a large repository of kernel test cases; it might not be designed with crashing systems in particular, but it may go a long way towards helping you and your team keep everything working as planned. (Note that the LTP isn't proscriptive -- the kernel community doesn't treat their tests as anything important -- but the LTP team tries very hard to be descriptive about what the kernel does and doesn't do.)
If your device is network-connected, you can run nmap against it, using a variety of scanning options:
-sV --version-allwill try to find versions of all services running (this can be stressful),-O --osscan-guesswill try to determine the operating system by throwing strange network packets at the machine and guessing by responses what the output is.The nessus scanning tool also does version identification of running services; it may or may not offer any improvements over nmap, though.
You can also hand your device to users; they figure out the craziest things to do with software, they'll spot bugs you'd never even think to look for. :)
您可以尝试以下组合键
SysRq + c
或
You can try following key combination
SysRq + c
or
众所周知，Crashme 可以发现未知的内核恐慌情况，但它必须以有效的方式运行，以创建在进程内处理的各种信号异常和各种进程退出条件。
Crashme 生成的消息的主要目的是确定是否发生了足够有趣的事情来表明可能的效力。例如，如果需要
mprotect调用来允许使用malloc分配的内存作为指令执行，并且如果您没有mprotect> 在你的平台的源代码crashme.c中启用，那么Crashme就无能为力了。x64 架构上的操作系统似乎倾向于关闭数据段的执行。最近我更新了 http://crashme.codeplex.com/ 上的 crashme.c 以使用
mprotect在__APPLE__的情况下，并在运行 MAC OS X Lion 的 MacBook Pro 上进行了测试。这是自 1994 年以来 Crashme 的第一次重大更新。预计很快就会看到更新的 Centos 和 Freebsd 支持。Crashme has been known to find unknown kernel panic situations, but it must be run in a potent way that creates a variety of signal exceptions handled within the process and a variety of process exit conditions.
The main purpose of the messages generated by Crashme is to determine if sufficiently interesting things are happening to indicate possible potency. For example, if the
mprotectcall is needed to allow memory allocated withmallocto be executed as instructions, and if you don't have themprotectenabled in the source code crashme.c for your platform, then Crashme is impotent.It seems that operating systems on x64 architectures tend to have execution turned off for data segments. Recently I have updated the crashme.c on http://crashme.codeplex.com/ to use
mprotectin case of__APPLE__and tested it on a MacBook Pro running MAC OS X Lion. This is the first serious update to Crashme since 1994. Expect to see updated Centos and Freebsd support soon.