On Mon, 2024-01-01 17:55:50 -0500, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote: > > Just ftr: My invocation is like this: > > [...] > > -deqna 0disable > > Aha. If I try it with no DEQNA, I find that the NetBSD ISO panics for > me too (I guess with XQA0 present, it doesn't get far enough to). > > I did the full-tracing thing again: set output breaks on "mscpbus1:" > and "panic:", then, when the first one tripped, turn on full tracing > and slow down clock ticks by a factor of 100. Turns out it's doing an > LDPCTX when not on the interrupt stack. This is either a bug in the > kernel or fallout from something else wrong with the emulator. Given > the recent successes on real hardware, I'm more inclined to suspect the > latter. > > In the trace from the crash, the offending instruction is > > (217086589 001f0000) 8000079a: 06 ldpctx > > I've put the trace, from "mscpbus1:" to "panic:", up on > ftp.rodents-montreal.org, in > /mouse/misc/vax/2024-01-01.15:26:33.nb-iso-no-deqna, in case anyone > wants to have a look. (It's a much bigger file than the other files I > put up for fetch - this one is 26163980 bytes.) There are two ldpctx > instructions executed in the trace; the second one is the problematic > one. I recommend searching for "ldpctx". Looking at the pre-executed instructions, this must be softint_process (in /usr/src/sys/arch/vax/vax/subr.S), so generally this ist softint-handling code. MfG, JBG (who's now going to bed) --
Attachment:
signature.asc
Description: PGP signature