> Date: Sat, 10 Dec 2022 02:42:05 +0300 > From: Valery Ushakov <u...@stderr.spb.ru> > > 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?