Alexander Bluhm <alexander.bluhm@gmx.net> writes:

> On Mon, Jan 05, 2026 at 09:23:20PM -0500, Dave Voutila wrote:
>> This has bothered me for awhile and I finally got to the bottom of
>> it. On some Alpine Linux versions, attempting a reboot via reboot(1)
>> results in a double fault and a hung vcpu. You get a panic like:
>>
>> [  615.066340] traps: PANIC: double fault, error_code: 0x0
>> [  615.066347] Oops: double fault: 0000 [#1] SMP PTI
>> [  615.066353] CPU: 0 UID: 0 PID: 2381 Comm: init Not tainted 6.18.2-0-virt #1-Alpine PREEMPT(none)
>> [  615.066355] Hardware name: OpenBSD VMM, BIOS 1.16.3p0-OpenBSD-vmm 01/01/2011
>> [  615.066356] RIP: 0008:0x9a070
>> [  615.066360] Code: Unable to access opcode bytes at 0x9a046.
>> [  615.066361] RSP: 0018:00000000405ebb78 EFLAGS: 00010046
>> [  615.066362] RAX: ffff951d00098000 RBX: 0000000000000000 RCX: 0000000000000000
>> [  615.066363] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
>> [  615.066363] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>> [  615.066364] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
>> [  615.066364] R13: 00000000fee1de01 R14: 0000000028121969 R15: ffffffffb1a63ea0
>> [  615.066365] FS:  00007f836bf6eb28(0000) GS:ffff951e2a16a000(0000) knlGS:0000000000000000
>> [  615.066366] CS:  0008 DS: 0000 ES: 0000 CR0: 0000000080050013
>> [  615.066366] CR2: 00000000405ebb68 CR3: 000000000009c000 CR4: 0000000000b50eb0
>>
>> It appears for some reason Alpine Linux kernels don't go the
>> triple-fault route that most other distro kernels do and instead tries a
>> reset function in the BIOS. At some point, the trampoline setup to get
>> into the BIOS must be getting busted.
>>
>> I'm not sure the exact cause, but by tweaking the RAM vs. Reserved point
>> for the first memory regions setup by vmd, it avoids breaking things.
>>
>> OK?
>
> Tested on Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
>
> My alpine Linux still does not reboot.  I have not seen the panic
> you mention.

Hmm, this looks like it terminates instead?

Did it terminate like this without the diff?

How much memory do you assign to this guest? I strongly suspect the
culprit is still how we define memory regions and my diff only fixes it
for specific sizes.

>
> Welcome to Alpine Linux 3.22
>
> lt63:~# reboot
> lt63:~#  * Stopping tcpbench ... [ ok ]
>  * Stopping sshd ... [ ok ]
>  * Saving random number generator seed ... * Seeding 256 bits and crediting
>  * Saving 256 bits of creditable seed for next boot
>  [ ok ]
>  * Stopping NTP Server ... [ ok ]
>  * Stopping iperf3 ... [ ok ]
>  * Stopping busybox crond ... [ ok ]
>  * Stopping busybox syslog ... [ ok ]
>  * Unmounting loop devices
>  * Unmounting filesystems
>  *   Unmounting /tmp ... [ ok ]
>  *   Unmounting /boot ... [ ok ]
>  * Deactivating swap devices ... [ ok ]
>  * Setting hardware clock using the system clock [UTC] ... [ ok ]
>  * Stopping busybox mdev ... [ ok ]
>  * Terminating remaining processes ...[   37.141768] reboot: Restarting system
>
> This is vmd -dvv output
>
> vm/lt63: vcpu_process_com_data: guest reading com1 when not ready
> vm/lt63: virtio_shutdown: waiting on device pid 19551
> vm/lt63: virtio_dispatch_dev: pipe dead (EV_READ)
> vm/lt63/vionet0: rx_run_loop: exiting (0)
> vm/lt63/vionet1: tx_run_loop: exiting (0)
> vm/lt63/vionet0: tx_run_loop: exiting (0)
> vm/lt63/vionet1: rx_run_loop: exiting (0)
> vm/lt63: virtio_shutdown: device for pid 19551 is stopped
> vm/lt63: virtio_shutdown: waiting on device pid 27363
> vm/lt63: virtio_shutdown: device for pid 27363 is stopped
> vm/lt63: virtio_shutdown: waiting on device pid 11734
> vm/lt63: virtio_shutdown: device for pid 11734 is stopped
> vmm: vmm_sighdlr: handling signal 20
> vmm: vmm_sighdlr: terminated vm lt63 (id 4)
> vmm: vm_remove: vmm vmm_sighdlr removing vm 4 from running config
> vmm: vm_stop: vmm vmm_sighdlr stopping vm 4
> vmd: vm_stop: vmd vmd_dispatch_vmm stopping vm 4
>
> bluhm