Summary
On a 2019 Mac Pro (MacPro7,1), Linux completes an orderly ACPI S5 shutdown and logs reboot: Power down, but the machine then powers itself back on within a few seconds. Controlled testing isolated this to the PCI wake settings on the two Thunderbolt/Titan Ridge chains.
Disabling power/wakeup on all seven relevant PCI functions makes shutdown remain off. Disabling Ethernet WOL, or disabling only the Thunderbolt parent, does not. d3cold_allowed can remain enabled.
The attached Thunderbolt DAS continues to work normally with the workaround; only wake capability is disabled.
System
- Apple Mac Pro 2019,
MacPro7,1
- Ubuntu 24.04.4 LTS with Kubuntu/KDE
- Kernel:
7.1.5-1-t2-noble
- AMD Radeon Pro 580X used for display;
amdgpu.dpm=0 is required on this machine
- NVIDIA RTX PRO 6000 installed headlessly
- Noontec D2 Thunderbolt 3 dual-SATA enclosure, exposing an ASMedia SATA/AHCI controller
- Thunderbolt device enrolled in
boltd with automatic authorization
Behaviour
A normal systemctl poweroff performs complete userspace, filesystem, md RAID and disk teardown. EFI pstore preserves the end of the shutdown, including:
pcieport 0000:12:00.0: AER: Uncorrectable (Non-Fatal) error received: 0000:16:02.0
...
xhci_hcd 0000:18:00.0: AER: can't recover
...
device recovery failed
...
ACPI: PM: Preparing to enter system sleep state S5
...
reboot: Power down
The 16:02.0 event reports Unsupported Request and ACS violation status. The downstream Titan Ridge USB controller at 18:00.0 cannot recover, and the Thunderbolt device disconnects during the shutdown sequence.
External smart-plug measurements confirm a genuine power transition rather than a warm reboot: approximately 133 W -> 56 W -> 4 W, followed about two seconds later by 6/8/10 W and then the normal POST ramp to over 200 W. A successful shutdown settles at 0-1 W.
macOS shuts down and remains off with the same Thunderbolt hardware attached.
Relevant PCI functions
0000:12:00.0 Intel [8086:203f] MCP0 parent
0000:16:02.0 Intel Titan Ridge bridge [8086:15ea]
0000:17:00.0 Intel Titan Ridge NHI [8086:15eb]
0000:18:00.0 Intel Titan Ridge USB [8086:15ec]
0000:8a:02.0 Intel Titan Ridge bridge [8086:15ea]
0000:8b:00.0 Intel Titan Ridge NHI [8086:15eb]
0000:8c:00.0 Intel Titan Ridge USB [8086:15ec]
Controlled tests
| Test |
Ethernet WOL |
PCI wake disabled |
D3cold allowed |
Result |
| 1 |
Both Aquantia interfaces disabled |
None |
Yes |
Powered back on |
| 2 |
Disabled |
Only 12:00.0 parent |
Yes |
Powered back on |
| 3 |
Disabled |
All seven functions above |
Yes |
Stayed off |
| 4 |
Enabled (Wake-on: g) |
All seven functions above |
Yes |
Stayed off |
The important incremental change is therefore disabling wake on the Thunderbolt child functions. Ethernet WOL is not required for the unwanted restart, and disabling D3cold is not required for the workaround.
Workaround
The live test was equivalent to:
for dev in 0000:12:00.0 0000:16:02.0 0000:17:00.0 0000:18:00.0 \
0000:8a:02.0 0000:8b:00.0 0000:8c:00.0; do
echo disabled | sudo tee "/sys/bus/pci/devices/$dev/power/wakeup"
done
sudo systemctl poweroffIt is now made persistent with exact-address ACTION=="add|bind" udev rules in /etc/udev/rules.d/80-bertha-thunderbolt-no-wake.rules. The rules change only power/wakeup; they do not alter d3cold_allowed, Thunderbolt authorization, Ethernet WOL, or normal enclosure operation.
Possible interpretation
The evidence suggests that the shutdown-time AER/recovery failure on the Titan Ridge USB branch generates or leaves a wake event asserted while that branch is armed. The system does reach S5, but firmware/SMC then responds to the wake event by starting a new boot.
Would a MacPro7,1 DMI/platform quirk disabling wake on these Thunderbolt functions be appropriate, or should shutdown handling quiesce/clear the Titan Ridge branch differently?
Possibly separate T2/BCE incident
After several rapid shutdown/boot experiments, three early Linux boots looped around 35-41 seconds into boot with console messages including:
t2bce_vhci: Possible desync, cmd cancel timed out
usb 7-1: hub failed to enable device, error -5
usb usb7-port1: cannot disable device (err = -110)
usb usb7-port1: cannot reset device (err = -110)
A one-time boot using nomodeset systemd.unit=multi-user.target still looped, so this was not avoided by bypassing the graphical AMD path. Halting from GRUB and removing mains power for 60 seconds restored a normal boot. The failed-boot journals ended before capturing the console messages, and I do not know whether this incident was caused by the shutdown testing or Thunderbolt workaround.
A similar BCE desynchronisation signature appears in t2linux/T2-Ubuntu#195, although that report has a different suspend/AMD trigger. I am including this as a clearly separate observation in case the persistent controller state is useful context; it should not be treated as the diagnosed cause of the S5 restart.
Summary
On a 2019 Mac Pro (
MacPro7,1), Linux completes an orderly ACPI S5 shutdown and logsreboot: Power down, but the machine then powers itself back on within a few seconds. Controlled testing isolated this to the PCI wake settings on the two Thunderbolt/Titan Ridge chains.Disabling
power/wakeupon all seven relevant PCI functions makes shutdown remain off. Disabling Ethernet WOL, or disabling only the Thunderbolt parent, does not.d3cold_allowedcan remain enabled.The attached Thunderbolt DAS continues to work normally with the workaround; only wake capability is disabled.
System
MacPro7,17.1.5-1-t2-nobleamdgpu.dpm=0is required on this machineboltdwith automatic authorizationBehaviour
A normal
systemctl poweroffperforms complete userspace, filesystem, md RAID and disk teardown. EFI pstore preserves the end of the shutdown, including:The
16:02.0event reports Unsupported Request and ACS violation status. The downstream Titan Ridge USB controller at18:00.0cannot recover, and the Thunderbolt device disconnects during the shutdown sequence.External smart-plug measurements confirm a genuine power transition rather than a warm reboot: approximately 133 W -> 56 W -> 4 W, followed about two seconds later by 6/8/10 W and then the normal POST ramp to over 200 W. A successful shutdown settles at 0-1 W.
macOS shuts down and remains off with the same Thunderbolt hardware attached.
Relevant PCI functions
Controlled tests
12:00.0parentWake-on: g)The important incremental change is therefore disabling wake on the Thunderbolt child functions. Ethernet WOL is not required for the unwanted restart, and disabling D3cold is not required for the workaround.
Workaround
The live test was equivalent to:
It is now made persistent with exact-address
ACTION=="add|bind"udev rules in/etc/udev/rules.d/80-bertha-thunderbolt-no-wake.rules. The rules change onlypower/wakeup; they do not alterd3cold_allowed, Thunderbolt authorization, Ethernet WOL, or normal enclosure operation.Possible interpretation
The evidence suggests that the shutdown-time AER/recovery failure on the Titan Ridge USB branch generates or leaves a wake event asserted while that branch is armed. The system does reach S5, but firmware/SMC then responds to the wake event by starting a new boot.
Would a
MacPro7,1DMI/platform quirk disabling wake on these Thunderbolt functions be appropriate, or should shutdown handling quiesce/clear the Titan Ridge branch differently?Possibly separate T2/BCE incident
After several rapid shutdown/boot experiments, three early Linux boots looped around 35-41 seconds into boot with console messages including:
A one-time boot using
nomodeset systemd.unit=multi-user.targetstill looped, so this was not avoided by bypassing the graphical AMD path. Halting from GRUB and removing mains power for 60 seconds restored a normal boot. The failed-boot journals ended before capturing the console messages, and I do not know whether this incident was caused by the shutdown testing or Thunderbolt workaround.A similar BCE desynchronisation signature appears in t2linux/T2-Ubuntu#195, although that report has a different suspend/AMD trigger. I am including this as a clearly separate observation in case the persistent controller state is useful context; it should not be treated as the diagnosed cause of the S5 restart.