Created attachment 608 [details] anolis7.9 arm64 信息截图 Description of problem: 月度镜像 anolisos_7_9_arm64_20G_rhck_alibase_20230105.vhd 的实例ecs.g6r.large,ecs.g6r.16xlarge在执行手动触发crash后卡死,无法ping通,内存,cmdline,image-id,内核信息等见附件 Version-Release number of selected component (if applicable): 4.18.0-192.28.1.an7.aarch64 How reproducible: 必现 Steps to Reproduce: 1.使用anolisos_7_9_arm64_20G_rhck_alibase_20230105.vhd创建ecs.g6r.large,ecs.g6r.16xlarge实例 2.远程执行触发crash的用例,用例内容包含echo c >/proc/sysrq-trigger 3.实例卡死,无法ping通 Actual results: 实例卡死,无法ping通 Expected results: 实例触发crash后正常启动,并到达登录界面,在/var/crash目录下能看到生成的vmcore等文件 Additional info:
Created attachment 614 [details] Ecs system log after triggering crash
本问题是概率复现问题 月度镜像内核版本为4.18.0-192.28.1.an7.aarch64 在g6r.large上使用centos7.9镜像，内核版本为4.18.0-348.20.1.el7.aarch64，同样存在该问题 问题的现象是在kdump kernel内systemd-udev hung task并且执行reboot -f后systemd-shtdown 也hung task，导致无法重启，卡在kdump kernel 解决方法是将/etc/sysconfig/kdump 内的nr_cpus=1 改为nr_cpus=2
(In reply to xiangzao from comment #2) > 本问题是概率复现问题 > 月度镜像内核版本为4.18.0-192.28.1.an7.aarch64 > 在g6r.large上使用centos7.9镜像，内核版本为4.18.0-348.20.1.el7.aarch64，同样存在该问题 > 问题的现象是在kdump kernel内systemd-udev hung task并且执行reboot -f后systemd-shtdown > 也hung task，导致无法重启，卡在kdump kernel > 解决方法是将/etc/sysconfig/kdump 内的nr_cpus=1 改为nr_cpus=2 /etc/sysconfig/kdump 内的nr_cpus=1 改为nr_cpus=2后，需要执行 kdumpctl rebuild kdumpctl restart
(In reply to xiangzao from comment #3) > (In reply to xiangzao from comment #2) > > 本问题是概率复现问题 > > 月度镜像内核版本为4.18.0-192.28.1.an7.aarch64 > > 在g6r.large上使用centos7.9镜像，内核版本为4.18.0-348.20.1.el7.aarch64，同样存在该问题 > > 问题的现象是在kdump kernel内systemd-udev hung task并且执行reboot -f后systemd-shtdown > > 也hung task，导致无法重启，卡在kdump kernel > > 解决方法是将/etc/sysconfig/kdump 内的nr_cpus=1 改为nr_cpus=2 > > /etc/sysconfig/kdump 内的nr_cpus=1 改为nr_cpus=2后，需要执行 > kdumpctl rebuild > kdumpctl restart 那这个是不是直接在内核上改好 而不是用户遇到了再去改？
和内核同学 @xiangzao 沟通了一下，解决方案中的修改 nr_cpus 的方式存在风险，nr_cpus 1为默认值，2 为特殊场景下的解决方案，2能否作为默认的处理方式我认为还需要更多的测试和分析。目前我的看法是不进行修改，而使用文档说明的方式，提示用户在遇到类似场景时的处理方法。
(In reply to gaochang from comment #6) > 和内核同学 @xiangzao 沟通了一下，解决方案中的修改 nr_cpus 的方式存在风险，nr_cpus 1为默认值，2 > 为特殊场景下的解决方案，2能否作为默认的处理方式我认为还需要更多的测试和分析。 > 目前我的看法是不进行修改，而使用文档说明的方式，提示用户在遇到类似场景时的处理方法。 我觉得文档说明在问题彻底解决之前是必要的 但是一方面这个nr_cpus 2其实没有测试分析支持的话 也不能作为解决方案，如果没有提前配置 机器会hang住 影响范围不可控； 另一方面用户即使能手动改成2 还是存在风险的； 测试这边觉得还是要解决 可以配合进行测试
(In reply to xiangzao from comment #2) > 本问题是概率复现问题 > 月度镜像内核版本为4.18.0-192.28.1.an7.aarch64 > 在g6r.large上使用centos7.9镜像，内核版本为4.18.0-348.20.1.el7.aarch64，同样存在该问题 > 问题的现象是在kdump kernel内systemd-udev hung task并且执行reboot -f后systemd-shtdown > 也hung task，导致无法重启，卡在kdump kernel > 解决方法是将/etc/sysconfig/kdump 内的nr_cpus=1 改为nr_cpus=2 这个概率复现是怎么得出的 我们这边原场景复现 一直都是存在问题的