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
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.
