> Date: Wed, 30 Apr 2025 17:05:21 +0200
> From: Marcus Glocker <marcus@nazgul.ch>
> 
> I've installed an amd64 snap on an MacPro6,1 (trash can), and noticed 
> that during power-down the system is crashing at the very last steps:
> 
> 	syncing disks... done
> 	Stopped at	x86_bus_space_io_write_4+0x1d:  leave

So why did it stop here?  Can you get a backtrace?

> After some investigations I found that this happens when we try to
> write to the I/O port 0x80.  This seems to be the POST debug port used
> by the BIOS and firmware to output POST status codes, and is most
> likely not implement on systems like the MacPro6,1.

Writing to an address that doesn't "exist" typically doesn't do
anything in x86.

> I couldn't come up with a more elegant solution, but this diff lets me
> nicely power down this machine.

So this write is initiated from ACPI code.  That suggests that the
machine explicitly directs us to make that write.

> Better ideas or OKs?

Maybe start with a proper bug report?

> Index: sys/dev/acpi/acpi.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> diff -u -p -u -p -r1.444 acpi.c
> --- sys/dev/acpi/acpi.c	24 Mar 2025 09:53:20 -0000	1.444
> +++ sys/dev/acpi/acpi.c	30 Apr 2025 14:47:29 -0000
> @@ -253,6 +253,14 @@ acpi_gasio(struct acpi_softc *sc, int io
>  		else
>  			iot = sc->sc_iot;
>  
> +		/*
> +		 * Accessing the I/O port 0x80 (POST debug port) on a
> +		 * MacPro6,1 will crash the system since this port is likely
> +		 * not implemented.
> +		 */
> +		if (address == 0x80 && strcmp(hw_prod, "MacPro6,1") == 0)
> +			return (-1);
> +
>  		if (acpi_bus_space_map(iot, address, len, 0, &ioh) != 0) {
>  			printf("%s: unable to map iospace\n", DEVNAME(sc));
>  			return (-1);
> 
>