> Date: Fri, 28 Jul 2023 09:42:30 -0400
> From: Brad Spencer <b...@anduin.eldar.org>
>
> Thanks, that allowed the dtrace to execute, but I never have time to
> execute the second probe, as this kernel panic occures within a few
> seconds of the first probe being run (probably on the order of 4 - 5
> seconds):
>
> [ 213.9904671] fatal page fault in supervisor mode
> [ 213.9904671] trap type 6 code 0 rip 0xffffffff824d29ad cs 0xe030 rflags
> 0x10283 cr2 0xd8 ilevel 0x7 rsp 0xffff92032de8db58
> [ 213.9904671] curlwp 0xffff92001784e9c0 pid 0.16 lowest kstack
> 0xffff92032de892c0
> kernel: page fault trap, code=0
> Stopped in pid 0.16 (system) at cyclic:cyclic_clock+0x86: movq
> d8(%rbx)
> ,%rax
> cyclic_clock() at cyclic:cyclic_clock+0x86
Oy... I bet this is the following logic in cyclic_clock:
if (TRAPF_USERMODE(frame)) {
c->cpu_profile_pc = 0;
c->cpu_profile_upc = TRAPF_PC(frame);
} else {
c->cpu_profile_pc = TRAPF_PC(frame);
c->cpu_profile_upc = 0;
}
TRAPF_USERMODE and TRAPF_PC are aliases for CLKF_USERMOADE and
CLKF_PC, respectively, which are defined differently on Xen and !Xen.
But the module is built assuming !Xen, and the module ABI is supposed
to be the same, so these are forbidden in modules.
I guess we need to add an out-of-line function that modules can call
for this.
Or, alternatively (though not for pullup to 9 or 10) -- perhaps we can
nix the clockframe nonsense once and for all and use struct cpu_info
members unconditionally, which would eliminate the grody hack in the
i8254 interrupt handler.
