tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: i386: 9.99.108 traps booting on VirtualBox
> 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?
Home |
Main Index |
Thread Index |
Old Index