问题分析报告：
关于一台AWS云主机出现连续crash的问题，通过查看系统dmesg日志，我们发现出现了NMI（非中断）导致的系统panic。NMI通常用于指示硬件故障等重大问题。
一、日志分析：
日志中显示的具体错误信息为：“Uhhuh. NMI received for unknown reason 21 on CPU 6”，以及“Kernel panic – not syncing: NMI: Not continuing”。这说明系统接收到了一个未知原因的NMI，导致内核恐慌并停止同步。
二、源码定位：
结合内核源码查看发生的panic的地方，我们可以定位到具体的代码位置。源码中的`unknown_nmi_error`函数处理了未知NMI的错误。
三、可能原因：
1. 软件bug：通过查找在crash时间点左右的atop系统快照，我们发现可能是业务进程game的子进程异常导致了系统panic。但通常用户空间的操作不太可能引起系统crash。
2. 硬件问题：这是另一种可能的原因。从社区讨论和官方描述中，我们看到有可能是RAM问题或其他硬件故障导致的NMI。已经有人提到可能是AMD主板电源的机器的问题。分析kdump文件可能有助于进一步确定硬件故障的原因。
四、排查方向：
1. 软件方面：分析crash时的系统快照，定位异常进程，尝试找出可能的软件bug。
2. 硬件方面：统计挂掉的机器的ip，看硬件分布，分析是否是特定硬件环境导致的问题。查看kdump文件以获取更多关于硬件故障的信息。提交dmesg日志给AWS的硬件工程师排查。
五、解决方案：
1. 临时设置内核参数以关闭nmi panic，以便系统不再因为NMI而崩溃。可以通过编辑`/etc/sysctl.conf`文件并设置`kernel.unknown_nmi_panic=0`和`kernel.panic_on_unrecovered_nmi=0`来实现。然后执行`sysctl -p`使设置生效。
2. 使用分析工具：分析dmesg日志、Kdump文件和Atop工具收集的数据，以获取更多关于系统崩溃的信息。使用crash命令可以帮助分析崩溃转储文件。
这个问题可能是由软件bug或硬件故障引起的。我们需要分别从不同方向进行排查，并采取相应的解决方案来修复问题。
