On Mon, Dec 12, 2022 at 20:12:57 +0000, Taylor R Campbell wrote: > Annoying... We really shouldn't abuse function prototypes like this: > according to the prototype, what I did with intr_kdtrace_wrapper is > correct.
Right, we decieved the compiler and the compiler was like, ok, boomer... > 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. As I said, it was just a quick kludge to avoid a bunch of files recompiled (and I didn't even get the number right...). > > 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 Yes, I get some of the early output from rc and then the system stalls. There's no further rc output and I don't get a login prompt on the wscons. When I type a key into the serial console, the output gets unstuck and I get the rest of the rc output and the login prompt on wscons. > - with KDTRACE_HOOKS disabled, and console on serial, system proceeds > without getting stuck on console output? Yes. -uwe
