Re: i386: 9.99.108 traps booting on VirtualBox

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sat, 10 Dec 2022 02:42:05 +0300
> From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> 
> So the culprit is KDTRACE_HOOKS in sys/arch/x86/x86/intr.c
> 
>   revision 1.163
>   date: 2022-10-29 16:59:04 +0300;  author: riastradh;  state: Exp;  lines: +38 -2;  commitid: w28zVvYhMCIOsCZD;
>   x86: Add dtrace probes for interrupt handler entry and return.
> 
> The problem is that clockintr has magic calling convention that
> intr_kdtrace_wrapper doesn't know about.  As a quick hack I changed
> i8254_initclocks to pass a magic argument (that is ignored by
> clockintr anyway) and told the hook code to ignore such handlers:
> 
> #ifdef KDTRACE_HOOKS
> 	if (arg != (void *)0x8042c10c) { /* clockintr is magic */
> 		ih->ih_fun = intr_kdtrace_wrapper;
> 		ih->ih_arg = ih;
> 	}
> #endif
> 
> and that kernel doesn't crash.

Annoying...  We really shouldn't abuse function prototypes like this:
according to the prototype, what I did with intr_kdtrace_wrapper is
correct.  I think it would be reasonable to add an exception like you
did for now, maybe with an INTR_NOTRACE flag (perhaps someone can find
a way to phrase this positively) instead of a magic number, until we
can remove the abuse of calling convention for clockintr.

I searched for other interrupt handler functions with a similar
prototypes on x86, with `void *\*.*(clock|intr)frame'.  I found only
three cases in tree:

- x86/isa/clock.c clockintr -- as you found

- x86/x86/lapic.c lapic_clockintr -- not a problem because this is
  called directly by assembly stubs, not via struct intrhand::ih_func 

- xen/xen/xen_clock.c xen_timer_handler -- not sure if this goes
  through struct intrhand::ih_func on x86, but if it is, then on
  !XENPV it might need to be adjusted similarly

> With KDTRACE_HOOKS enabled (modulo clockintr hack) and the serial
> console (for debugging) I see the system stuck on console output when
> rc runs.  It gets unstuck on a com interrupt (e.g. pressing a key).
> 
> Seems to work fine with KDTRACE_HOOKS disabled.

Do you mean that:

- with KDTRACE_HOOKS enabled, clockintr hack applied, and console on
  serial, system gets stuck on console output until com interrupt

- with KDTRACE_HOOKS disabled, and console on serial, system proceeds
  without getting stuck on console output?

Or do you mean that with KDTRACE_HOOKS disabled it avoids the crash,
but the system still gets stuck on console output?