On Sat, May 03, 2025 at 10:08:15PM GMT, Marcus Glocker wrote:
> On Sat, May 03, 2025 at 09:53:11PM GMT, Marcus Glocker wrote:
>
> > On Sat, May 03, 2025 at 02:42:09PM GMT, George Koehler wrote:
> >
> > > On Sat, 3 May 2025 08:02:29 +0200
> > > Marcus Glocker <[email protected]> wrote:
> > >
> > > > Managed to get a stack trace meanwhile:
> > > >
> > > > https://nazgul.ch/pub/macpro6,1_st.jpg
> > >
> > > This is your stack trace, beware of typos:
> > >
> > > login: syncing disks... done
> > > Stopped at x86_bus_space_io_write_4+0x1d: leave
> > > x86_bus_space_io_write_4(80,0,5) at x86_bus_space_io_write_4+0x1d
> > > acpi_gasio(ffff800000023800,1,1,80,4,4,60d508a60eff3a3) at
> > > acpi_gasio+0x237
> > > aml_opreg_sysio_handler(0,1,80,4,ffff80003c242b38) at
> > > aml_opreg_sysio_handler+0x3b
> > > acpi_genio(ffff80003c24bdc,1,1,80,4,4,fb4c92c4c56ac154) at acpi_genio+0x9b
> > > aml_rwgen(ffff80000011b308,0,20,ffff80000282f988,1,13) at aml_rwgen+0x4fd
> > > aml_rwfield(ffff80000011c288,0,20,ffff80000282f988,1) at aml_rwfield+0x3ab
> > > aml_store(ffff80000011c288,0,20,ffff80000011c288,0,ffff80000282f988) at
> > > aml_store+0x371
> > > aml_parse(ffff80000282f608,54,b1) at aml_parse+0x1d0d
> > > aml_eval(ffff800002479b88,ffff80000011cc88,54,100200001,0) at
> > > aml_eval+0x338
> > > aml_parse(ffff800002479b88,54,0) at aml_parse+0x26d5
> > > aml_eval(0,ffff800000120508,74,ffff80003c243220,ffff80003c243220) at
> > > aml_eval+0x338
> > > aml_evalnode(ffff800000120508,74,ffff80003c243220,ffff80003c243220) at
> > > aml_eval+0x338
> > > aml_node_setval(ffff800000023800,ffff800000120488,5) at
> > > aml_node_setval+0x7e
> > > acpi_powerdown() at acpi_powerdown+0x7b
> > > end trace frame: 0xffff80003c2432e0, count: 0
> > > ddb{0}>
> >
> > Thanks for the translation!
> >
> > > I don't see a panic message. I guess that you entered ddb from the
> > > db_ktrap call at /sys/arch/amd64/amd64/trap.c:323 (below we_re_toast:
> > > in kerntrap), but I don't know the kind of trap. It might help to
> > > move the trap_print call above the db_ktrap call, then build a kernel
> > > (without your workaround patch) and reproduce.
> >
> > Yes. That's the output when I move trap_print(), and panic() (converted
> > to an printf) before "if (db_ktrap(type, frame->tf_err, frame))":
> >
> > trashcan# halt -p
> > syncing disks... done
> > fatal trace trap in supervisor mode
> > trap type 5 code 0 rip ffffffff8217727d cs 8 rflags 2 cr2 ffff80003c16fa38
> > cpl d rsp ffff80003c083430
>
> "rflags 2" means that the Trap Flag (TF) is set I guess.
>
> void
> x86_bus_space_io_write_4(bus_space_handle_t h, bus_size_t o, u_int32_t v)
> {
> outl(h + o, v);
> }
>
> The next instruction after the outl() will be the 'leave' epilogue,
> where the trace trap gets issued because the TF flag was set.
>
> The question is why the TF flag gets set after the I/O write to port
> 0x80 ...
Ignoring the trace trap in kernel mode works as well for this case.
I just have no idea whether that's feasible to do in general. Also,
would we want to print a message about it?
Probably we need to summon kettenis@ or so :-)
Index: sys/arch/amd64/amd64/trap.c
===================================================================
RCS file: /cvs/src/sys/arch/amd64/amd64/trap.c,v
diff -u -p -u -p -r1.106 trap.c
--- sys/arch/amd64/amd64/trap.c 4 Sep 2024 07:54:51 -0000 1.106
+++ sys/arch/amd64/amd64/trap.c 3 May 2025 21:16:49 -0000
@@ -348,6 +348,10 @@ kerntrap(struct trapframe *frame)
else
return;
#endif /* NISA > 0 */
+
+ case T_TRCTRAP:
+ /* ignore trace traps in kernel mode */
+ return;
}
}
