call trace when loading - but still seems to do something

[montdidier]

I get the following when loading the module on Alpine 3.18.4. It looks like it bombs out but it seems to work. Not sure if this is expected or it just recovers.

Linux bitbucket 6.1.55-0-virt #1-Alpine SMP PREEMPT_DYNAMIC Sun, 24 Sep 2023 23:14:02 +0000 x86_64 Linux

This is the relevant output of dmesg

[    4.660706] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/1053
[    4.660707] caller is vmm_clock_init+0x3d6/0x1000 [vmm_clock]
[    4.660711] CPU: 0 PID: 1053 Comm: modprobe Tainted: G           OE      6.1.55-0-virt #1-Alpine
[    4.660712] Hardware name: OpenBSD VMM, BIOS 1.14.0p3-OpenBSD-vmm 01/01/2011
[    4.660713] Call Trace:
[    4.660714]  <TASK>
[    4.660715]  dump_stack_lvl+0x44/0x66
[    4.660717]  check_preemption_disabled+0xe6/0xf0
[    4.660719]  vmm_clock_init+0x3d6/0x1000 [vmm_clock]
[    4.660721]  ? 0xffffffffc03f9000
[    4.660722]  do_one_initcall+0x54/0x220
[    4.660724]  do_init_module+0x45/0x1d0
[    4.660726]  __do_sys_init_module+0x18f/0x1c0
[    4.660727]  do_syscall_64+0x5b/0x90
[    4.660729]  entry_SYSCALL_64_after_hwframe+0x64/0xce
[    4.660731] RIP: 0033:0x7fe5a1c6d698
[    4.660732] Code: 48 83 ec 08 89 d2 b8 45 01 00 00 0f 05 48 89 c7 e8 03 e9 ff ff 48 83 c4 08 c3 e9 2d 94 01 00 48 83 ec 08 b8 af 00 00 00 0f 05 <48> 89 c7 e8 e6 e8 ff ff 48 83 c4 08 c3 48 83 ec 08 89 f6 b8 b0 00
[    4.660733] RSP: 002b:00007fff15225170 EFLAGS: 00000202 ORIG_RAX: 00000000000000af
[    4.660734] RAX: ffffffffffffffda RBX: 00007fe5a1b66f80 RCX: 00007fe5a1c6d698
[    4.660735] RDX: 000055ba8e9edba1 RSI: 000000000004a378 RDI: 00007fe5a11ff090
[    4.660736] RBP: 00007fe5a1b66f80 R08: 0000000054833312 R09: 0000000000008000
[    4.660736] R10: 0000000000000117 R11: 0000000000000202 R12: 0000000000040000
[    4.660737] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[    4.660738]  </TASK>
[    4.660738] vmm_register_clock: cpu 0, msr 2642001, primary cpu clock
[    4.660739] vmm_sched_clock_init: using sched offset of 1696600343161676036 cycles
[    4.660740] vmm_clock_init: attempting to register clocksource
[    4.660741] clocksource: vmm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[    4.660749] clocksource: Switched to clocksource vmm-clock

[montdidier]

I've been running this overnight and I can confirm its doing a much better job. This is In conjunction with an out-of-box Alpine Linux chrony configuration seems to be keeping accurate time.

I don't necessarily expect you to know the answer to this but is there some understanding of why the default vmd emulated clock sources don't work well? I am starting to suspect it is something to do with my older AMD host hardware.