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 <mar...@nazgul.ch> 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 ...
> gsbase 0xffffffff82a0eff0 kgsbase 0x0
> trap type 5, code=0 pc=ffffffff8217727dStopped at
> x86_bus_space_io_write_4+0x1d: leave
> ddb{0}>
>
> > On some Macs, holding down the power button forces a power off.
>
> Yes that works, but I would prefer "halt -p" to work ;-) The power
> button on the MacPro6,1 is on the back of the machine below the RJ45
> port, and when a cable is plugged in there (which is the case for me),
> it's not very convenient to press it every time after "halt -p" has
> failed.
>
> I'm a bit afraid that this issue might be related to the firmware of
> the machine, and there might be no nice way to fix it in the OS. I'm
> aware that introducing quirks isn't our preferred method, but I see that
> NetBSD and Linux have quite some quirks introduced in their ACPI code.
> Obviously my last diff can be polished to be more generic, and like we
> introduce quirks in other areas.
