Messages in this thread | | | Date | Thu, 28 Jul 2022 19:52:10 +0700 | From | Ammar Faizi <> | Subject | Re: x86_64/kvm: kernel hangs on poweroff |
| |
On 7/26/22 2:02 AM, Linus Torvalds wrote: > On Mon, Jul 25, 2022 at 11:40 AM Yury Norov <yury.norov@gmail.com> wrote: >>> [ 22.162259] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 >>> [ 22.163539] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc6 #198 >>> [ 22.164327] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 >>> [ 22.164327] Call Trace: >>> [ 22.164327] <TASK> >>> [ 22.164327] dump_stack_lvl+0x34/0x44 >>> [ 22.164327] panic+0x107/0x28a >>> [ 22.164327] do_exit.cold+0x15/0x15 >>> [ 22.164327] ? sys_off_notify+0x3e/0x60 >>> [ 22.164327] __do_sys_reboot+0x1df/0x220 >>> [ 22.164327] ? vfs_writev+0xc7/0x190 >>> [ 22.164327] ? virtio_crypto_ctrl_vq_request+0xd0/0xd0 >>> [ 22.164327] ? fpregs_assert_state_consistent+0x1e/0x40 >>> [ 22.164327] do_syscall_64+0x3b/0x90 >>> [ 22.164327] entry_SYSCALL_64_after_hwframe+0x46/0xb0 >>> [ 22.164327] RIP: 0033:0x7f42b4118443 >>> [ 22.164327] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 f9 c9 0d 00 f7 d8 > > That's literally the "exit()" system call.
I took a look and it turned out it's not the "exit()" system call.
The disassembly is:
0: 64 89 01 mov %eax,%fs:(%rcx) 3: 48 83 c8 ff or $0xffffffffffffffff,%rax 7: c3 ret 8: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) f: 00 00 00 12: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 17: 89 fa mov %edi,%edx 19: be 69 19 12 28 mov $0x28121969,%esi 1e: bf ad de e1 fe mov $0xfee1dead,%edi 23: b8 a9 00 00 00 mov $0xa9,%eax 28: 0f 05 syscall 2a:* 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax <-- trapping instruction
The syscall is with orig %rax being 0xa9 (169 in dec). That is the reboot system call. The problem here is that the reboot system call calls do_exit(0) with @current being the init.
So I think the way to investigate it is take a look at kernel/reboot.c, understand why did you end up in do_exit(0) path. Hope that helps.
-- Ammar Faizi
| |