Distribution
Linux Mint 22.3 Zena, Cinnamon edition, X11
Package version
Cinnamon 6.6.9
Graphics hardware in use
AMD Radeon RX 6600 (Navi 23, PCI ID 1002:73ff), using amdgpu/radeonsi; dual monitors at 2560×1440 and 1920×1080
Frequency
Quite often
Bug description
After Cinnamon has been running for several hours, choosing Restart directly from the active Cinnamon X11 session can intermittently result in Linux completing its normal shutdown sequence while the machine fails to complete the final hardware reset.
When this happens, the display turns off, but the CPU and case fans remain spinning and the machine never begins POST. A forced physical power-off is required.
The journal still reaches reboot.target and systemd-shutdown, with no kernel panic, GPU reset, amdgpu ring timeout, fence timeout, PCIe AER error, RCU stall, hard/soft lockup, hung task, or filesystem unmount failure near the end of shutdown.
The strongest correlation found so far is whether the Cinnamon/X graphical session has fully finished teardown before the reboot request is made.
In a retained failed reboot, Cinnamon requested the restart and logind accepted it before the graphical session had fully closed:
03:03:25.368190 Cinnamon requests restart
03:03:25.374468 logind accepts reboot
03:03:25.396... cinnamon.desktop killed by SIGTERM
03:03:25.442787 graphical user session closes
03:03:27.313366 LightDM stopped
03:03:27.452882 drm_fb_helper_damage_work warnings begin
03:03:38.711672 reboot.target reached
03:03:38.747900 systemd-shutdown sync
03:03:38.769289 journal stops
Externally, that reboot failed to reach POST and required a forced power-off.
By contrast, if I first log out of Cinnamon, wait until the LightDM greeter is fully visible, and then restart from LightDM, the reboot succeeds.
I reproduced this successfully after multiple genuine long sessions, including approximately 4h05m and 4h13m of Cinnamon use.
In the 4h05m control, the graphical session had been closed for only 13.627 seconds before the reboot request was made, and the reboot succeeded normally. This suggests that waiting several minutes is not necessary; the important difference appears to be that Cinnamon/X teardown had already completed before reboot was requested.
A separate test using:
sudo systemctl stop lightdm
sudo reboot
also rebooted successfully, even though the local screen remained black after LightDM was stopped.
BIOS/UEFI-initiated reboot also succeeds, including after several hours of Linux use.
The failure has also been reproduced with Secure Boot disabled, so Secure Boot does not appear to be required for the problem.
Successful controlled reboots report:
x86/amd: Previous system reset reason [0x00080800]:
software wrote 0x6 to reset control register 0xCF9
while the retained failed direct-Cinnamon reboot was followed by:
x86/amd: Previous system reset reason [0x00200800]:
ACPI power state transition occurred
I am treating this reset-reason difference only as a correlation, not proof of the exact failing component, because physical recovery is required after a failed reboot.
Similar incomplete poweroffs have also occurred, but the strongest controlled A/B evidence I have is for reboot.
The current workaround is:
Log out of Cinnamon → wait until LightDM is fully ready → Restart
I am reporting this here because the outcome changes depending on whether reboot is requested from the active Cinnamon session or after Cinnamon has completed logout. The final root cause may still involve Cinnamon session teardown, Xorg, LightDM/X teardown, DRM/amdgpu display-state cleanup, kernel shutdown ordering, firmware/platform reset handling, or an interaction between them.
Steps to reproduce
Log into Linux Mint Cinnamon using the normal X11 session.
Use the desktop normally for several hours.
While still logged into the active Cinnamon desktop, choose Restart from Cinnamon's power menu.
Cinnamon begins logout/session teardown and the reboot request is accepted by systemd-logind.
Intermittently, Linux reaches reboot.target / systemd-shutdown, the displays turn off, but the machine does not begin POST.
CPU and case fans continue spinning and a forced physical power-off is required.
Control/workaround that succeeds:
Use Cinnamon normally for several hours.
Choose Log Out instead of Restart.
Wait until the LightDM login/greeter screen is fully visible and ready.
Wait several seconds.
Choose Restart from LightDM.
The machine reboots normally and reaches POST.
This workaround has succeeded after genuine long Cinnamon sessions, including approximately 4h05m and 4h13m.
Expected behavior
Requesting Restart or Shut Down from an active Cinnamon session should reliably complete the hardware/platform reboot or power-off, just as it does when the operation is requested after logging out to LightDM.
Cinnamon/X/display teardown should be ordered so that it does not intermittently interfere with the final kernel/platform reset or power transition.
Additional information
Failed direct-Cinnamon reboot
The clearest retained failed reboot shows the restart request beginning while Cinnamon/X/session teardown was still occurring.
03:03:23.229970 Cinnamon logout sequence begins
03:03:25.368190 Cinnamon explicitly requests restart
"Requesting system restart..."
"Attempting to restart using systemd..."
03:03:25.374468 logind accepts reboot request
03:03:25.396... cinnamon.desktop killed by SIGTERM
(~28 ms after restart request)
03:03:25.396563 graphical.target stopped
03:03:25.409237 LightDM begins stopping
03:03:25.442787 user's graphical session closes
(~68 ms after reboot was already accepted)
03:03:26.762895 fbcon takes over console
03:03:27.313366 LightDM stopped
03:03:27.452882 first drm_fb_helper_damage_work warning
... DRM/amdgpu workqueue activity continues during shutdown ...
03:03:38.440524 shutdown.target reached
03:03:38.521885 final drm_fb_helper_damage_work warning
cumulative count: 35
03:03:38.711672 reboot.target reached
03:03:38.711705 systemd begins final shutdown
03:03:38.747900 systemd-shutdown syncs filesystems/block devices
03:03:38.769164 SIGTERM sent to remaining processes
03:03:38.769289 journal stops
The last framebuffer warning occurred only about 190 ms before reboot.target, but Linux continued making orderly shutdown progress after it.
Externally, the result was:
Display off
CPU/case fans remain running
No POST
Forced physical power-off required
The next boot reported:
x86/amd: Previous system reset reason [0x00200800]:
ACPI power state transition occurred
Successful controlled software reboots instead report:
x86/amd: Previous system reset reason [0x00080800]:
software wrote 0x6 to reset control register 0xCF9
I am treating this reset-reason difference as a correlation, not proof of the exact failing component. A failed reboot requires later physical recovery, so the ACPI transition value may partly reflect that subsequent transition.
No evidence was found near the failed reboot for:
kernel panic
GPU reset
amdgpu ring timeout
fence timeout
explicit amdgpu shutdown/removal failure
PCIe AER / PCIe Bus Error
RCU stall
soft lockup
hard lockup
hung task / blocked task
watchdog lockup
filesystem unmount failure
Successful 4h05m logout-first control
A later controlled test deliberately separated Cinnamon/X teardown from the reboot request.
The Cinnamon graphical session had been running for approximately 4 hours 5 minutes.
00:10:52.818236 Cinnamon begins normal logout
00:10:54.925573 LightDM closes user's graphical session
00:10:54.928998 logind records user session logged out
00:10:56.178821 new LightDM greeter session opens
00:10:56.847831 last clear greeter initialization/auth marker
00:11:08.553022 reboot requested
00:11:08.555642 system is rebooting
00:11:09.032147 LightDM stopped
00:11:09.675627 reboot.target reached
00:11:09.706173 systemd-shutdown filesystem sync
00:11:09.728691 final journal termination
Measured intervals:
Graphical-session closure -> reboot request:
13.627449 seconds
Last clear greeter initialization marker -> reboot request:
11.705191 seconds
Reboot request -> reboot.target:
1.122605 seconds
The machine successfully reset and reached POST.
The following boot reported the normal CF9 software-reset reason.
This shows that several minutes of passive waiting are not required; approximately 13.6 seconds after graphical-session closure was sufficient in this test.
Second long-session logout-first control
Another logout-first test followed a Cinnamon session lasting approximately 4 hours 13 minutes.
In that test:
Cinnamon/X session closes
LightDM greeter starts
3m36.847s later reboot is requested
Reboot succeeds
Next boot reports normal CF9 reset
Together with the 13.6-second successful test, this makes a simple "needs several minutes to settle" explanation less likely.
The more important distinction appears to be:
Cinnamon/X graphical teardown completes before reboot request
-> successful reboot
Reboot is requested while Cinnamon/X/display teardown is occurring
-> intermittent failure
This is still correlation, not proof of a deterministic race.
User-service distinction
The successful logout-first tests did not require the entire user manager to exit before reboot.
After Cinnamon and the graphical X session were gone, some user services could still remain until final reboot, including:
systemd --user
D-Bus
PipeWire
WirePlumber
some portal processes
The machine still rebooted normally.
One successful logout-first reboot also contained unrelated errors including a Discord coredump, a cups-browsed shutdown timeout/SIGKILL, and portal/permission-store errors, yet still completed a normal CF9 reboot.
This appears to narrow the important difference toward the Cinnamon/X/display teardown path rather than generic user-service shutdown.
LightDM-stopped control
A separate test was performed over SSH:
sudo systemctl stop lightdm
sudo reboot
After stopping LightDM, the local display went black and no visible VT appeared, but the machine remained alive and responsive remotely.
Reboot then succeeded and the next boot showed the normal CF9 reset signature.
This makes the LightDM service itself less likely to be the primary cause, although X/display teardown associated with it may still be part of the broader interaction.
BIOS/UEFI control
Firmware-initiated reboot from UEFI/BIOS succeeds.
It also succeeded after several hours of Linux use.
This makes a simple motherboard reset-circuit or PSU failure less likely, although firmware/platform reset handling could still be the final point of failure if Linux leaves a problematic device/display state behind.
Secure Boot control
The failure was reproduced with:
secureboot: Secure boot disabled
Therefore Secure Boot does not appear to be a necessary or primary cause.
Kernel-version observation
The behavior has been observed on more than one installed kernel version and does not appear to be exclusive to the current kernel.
Current kernel:
7.0.0-30-generic
DRM/amdgpu workqueue observations
During the retained failed direct-Cinnamon reboot, these warnings were clustered during graphical/display teardown:
workqueue: drm_fb_helper_damage_work hogged CPU for >10000us
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us
There was also:
workqueue: inode_switch_wbs_work_fn hogged CPU for >10000us
The graphics warnings should not be interpreted as proof of the failure.
They also occur during successful reboot history. In fact, an older successful LightDM-stopped reboot showed much higher cumulative counts:
drm_fb_helper_damage_work: up to 1027
dm_handle_vmin_vmax_update [amdgpu]: at least 131
and still rebooted normally.
Therefore warning count/intensity alone does not predict failure.
What may be more relevant is their timing in the failed case, where display-related work was still occurring while Cinnamon/X/LightDM/fbcon teardown and global reboot were overlapping.
System information
Distribution: Linux Mint 22.3 Zena
Desktop: Cinnamon 6.6.9
Session: X11
Display manager: LightDM 1.30.0
Kernel: 7.0.0-30-generic
Mesa: 25.2.8
CPU: AMD Ryzen 5 5500
GPU: AMD Radeon RX 6600 (Navi 23)
PCI ID: 1002:73ff
Driver: amdgpu / radeonsi
Displays:
2560x1440
1920x1080
Motherboard:
MSI MAG B550 TOMAHAWK MAX WIFI
MS-7C91
BIOS:
2.B0
Current interpretation
The strongest discriminator found through controlled testing is:
Cinnamon/X graphical-session teardown finishes
before reboot is requested
-> successful POST / CF9 reset
Restart is requested by Cinnamon while
Cinnamon/X/DRM/display teardown is concurrent
-> intermittent failure to reach POST
This suggests a teardown/reset ordering or timing interaction, but does not establish which component is ultimately defective.
Possible interacting components include:
Cinnamon / cinnamon-session
Xorg
LightDM/X teardown
DRM framebuffer handover / fbcon
amdgpu display-state teardown
kernel shutdown ordering
firmware/chipset platform-reset handling
The exact root cause remains undetermined.
Related issue
Possibly related:
#12423 — "Linux Mint 22 Won't properly shutdown after the PC is powered ON for more than 8 hours"
I do not believe this is an exact duplicate because that report described shutdown failure on Intel graphics and specifically stated that restart worked.
This case includes:
failed reboots as well as incomplete poweroff behavior;
direct-Cinnamon vs logout-first A/B testing;
successful long-session LightDM-greeter reboots;
successful LightDM-stopped reboot;
successful long-session UEFI reboot;
CF9 vs ACPI reset-reason correlation;
precise Cinnamon/X/session teardown ordering;
DRM/amdgpu warning comparisons between successful and failed reboots.
The intent of this report is to provide enough controlled evidence to determine whether the active Cinnamon restart path is exposing an ordering problem elsewhere in the graphics/kernel/platform shutdown stack.
Distribution
Linux Mint 22.3 Zena, Cinnamon edition, X11
Package version
Cinnamon 6.6.9
Graphics hardware in use
AMD Radeon RX 6600 (Navi 23, PCI ID 1002:73ff), using amdgpu/radeonsi; dual monitors at 2560×1440 and 1920×1080
Frequency
Quite often
Bug description
After Cinnamon has been running for several hours, choosing Restart directly from the active Cinnamon X11 session can intermittently result in Linux completing its normal shutdown sequence while the machine fails to complete the final hardware reset.
When this happens, the display turns off, but the CPU and case fans remain spinning and the machine never begins POST. A forced physical power-off is required.
The journal still reaches reboot.target and systemd-shutdown, with no kernel panic, GPU reset, amdgpu ring timeout, fence timeout, PCIe AER error, RCU stall, hard/soft lockup, hung task, or filesystem unmount failure near the end of shutdown.
The strongest correlation found so far is whether the Cinnamon/X graphical session has fully finished teardown before the reboot request is made.
In a retained failed reboot, Cinnamon requested the restart and logind accepted it before the graphical session had fully closed:
03:03:25.368190 Cinnamon requests restart
03:03:25.374468 logind accepts reboot
03:03:25.396... cinnamon.desktop killed by SIGTERM
03:03:25.442787 graphical user session closes
03:03:27.313366 LightDM stopped
03:03:27.452882 drm_fb_helper_damage_work warnings begin
03:03:38.711672 reboot.target reached
03:03:38.747900 systemd-shutdown sync
03:03:38.769289 journal stops
Externally, that reboot failed to reach POST and required a forced power-off.
By contrast, if I first log out of Cinnamon, wait until the LightDM greeter is fully visible, and then restart from LightDM, the reboot succeeds.
I reproduced this successfully after multiple genuine long sessions, including approximately 4h05m and 4h13m of Cinnamon use.
In the 4h05m control, the graphical session had been closed for only 13.627 seconds before the reboot request was made, and the reboot succeeded normally. This suggests that waiting several minutes is not necessary; the important difference appears to be that Cinnamon/X teardown had already completed before reboot was requested.
A separate test using:
sudo systemctl stop lightdm
sudo reboot
also rebooted successfully, even though the local screen remained black after LightDM was stopped.
BIOS/UEFI-initiated reboot also succeeds, including after several hours of Linux use.
The failure has also been reproduced with Secure Boot disabled, so Secure Boot does not appear to be required for the problem.
Successful controlled reboots report:
x86/amd: Previous system reset reason [0x00080800]:
software wrote 0x6 to reset control register 0xCF9
while the retained failed direct-Cinnamon reboot was followed by:
x86/amd: Previous system reset reason [0x00200800]:
ACPI power state transition occurred
I am treating this reset-reason difference only as a correlation, not proof of the exact failing component, because physical recovery is required after a failed reboot.
Similar incomplete poweroffs have also occurred, but the strongest controlled A/B evidence I have is for reboot.
The current workaround is:
Log out of Cinnamon → wait until LightDM is fully ready → Restart
I am reporting this here because the outcome changes depending on whether reboot is requested from the active Cinnamon session or after Cinnamon has completed logout. The final root cause may still involve Cinnamon session teardown, Xorg, LightDM/X teardown, DRM/amdgpu display-state cleanup, kernel shutdown ordering, firmware/platform reset handling, or an interaction between them.
Steps to reproduce
Log into Linux Mint Cinnamon using the normal X11 session.
Use the desktop normally for several hours.
While still logged into the active Cinnamon desktop, choose Restart from Cinnamon's power menu.
Cinnamon begins logout/session teardown and the reboot request is accepted by systemd-logind.
Intermittently, Linux reaches reboot.target / systemd-shutdown, the displays turn off, but the machine does not begin POST.
CPU and case fans continue spinning and a forced physical power-off is required.
Control/workaround that succeeds:
Use Cinnamon normally for several hours.
Choose Log Out instead of Restart.
Wait until the LightDM login/greeter screen is fully visible and ready.
Wait several seconds.
Choose Restart from LightDM.
The machine reboots normally and reaches POST.
This workaround has succeeded after genuine long Cinnamon sessions, including approximately 4h05m and 4h13m.
Expected behavior
Requesting Restart or Shut Down from an active Cinnamon session should reliably complete the hardware/platform reboot or power-off, just as it does when the operation is requested after logging out to LightDM.
Cinnamon/X/display teardown should be ordered so that it does not intermittently interfere with the final kernel/platform reset or power transition.
Additional information
Failed direct-Cinnamon reboot
The clearest retained failed reboot shows the restart request beginning while Cinnamon/X/session teardown was still occurring.
03:03:23.229970 Cinnamon logout sequence begins
03:03:25.368190 Cinnamon explicitly requests restart
"Requesting system restart..."
"Attempting to restart using systemd..."
03:03:25.374468 logind accepts reboot request
03:03:25.396... cinnamon.desktop killed by SIGTERM
(~28 ms after restart request)
03:03:25.396563 graphical.target stopped
03:03:25.409237 LightDM begins stopping
03:03:25.442787 user's graphical session closes
(~68 ms after reboot was already accepted)
03:03:26.762895 fbcon takes over console
03:03:27.313366 LightDM stopped
03:03:27.452882 first drm_fb_helper_damage_work warning
... DRM/amdgpu workqueue activity continues during shutdown ...
03:03:38.440524 shutdown.target reached
03:03:38.521885 final drm_fb_helper_damage_work warning
cumulative count: 35
03:03:38.711672 reboot.target reached
03:03:38.711705 systemd begins final shutdown
03:03:38.747900 systemd-shutdown syncs filesystems/block devices
03:03:38.769164 SIGTERM sent to remaining processes
03:03:38.769289 journal stops
The last framebuffer warning occurred only about 190 ms before reboot.target, but Linux continued making orderly shutdown progress after it.
Externally, the result was:
Display off
CPU/case fans remain running
No POST
Forced physical power-off required
The next boot reported:
x86/amd: Previous system reset reason [0x00200800]:
ACPI power state transition occurred
Successful controlled software reboots instead report:
x86/amd: Previous system reset reason [0x00080800]:
software wrote 0x6 to reset control register 0xCF9
I am treating this reset-reason difference as a correlation, not proof of the exact failing component. A failed reboot requires later physical recovery, so the ACPI transition value may partly reflect that subsequent transition.
No evidence was found near the failed reboot for:
kernel panic
GPU reset
amdgpu ring timeout
fence timeout
explicit amdgpu shutdown/removal failure
PCIe AER / PCIe Bus Error
RCU stall
soft lockup
hard lockup
hung task / blocked task
watchdog lockup
filesystem unmount failure
Successful 4h05m logout-first control
A later controlled test deliberately separated Cinnamon/X teardown from the reboot request.
The Cinnamon graphical session had been running for approximately 4 hours 5 minutes.
00:10:52.818236 Cinnamon begins normal logout
00:10:54.925573 LightDM closes user's graphical session
00:10:54.928998 logind records user session logged out
00:10:56.178821 new LightDM greeter session opens
00:10:56.847831 last clear greeter initialization/auth marker
00:11:08.553022 reboot requested
00:11:08.555642 system is rebooting
00:11:09.032147 LightDM stopped
00:11:09.675627 reboot.target reached
00:11:09.706173 systemd-shutdown filesystem sync
00:11:09.728691 final journal termination
Measured intervals:
Graphical-session closure -> reboot request:
13.627449 seconds
Last clear greeter initialization marker -> reboot request:
11.705191 seconds
Reboot request -> reboot.target:
1.122605 seconds
The machine successfully reset and reached POST.
The following boot reported the normal CF9 software-reset reason.
This shows that several minutes of passive waiting are not required; approximately 13.6 seconds after graphical-session closure was sufficient in this test.
Second long-session logout-first control
Another logout-first test followed a Cinnamon session lasting approximately 4 hours 13 minutes.
In that test:
Cinnamon/X session closes
LightDM greeter starts
3m36.847s later reboot is requested
Reboot succeeds
Next boot reports normal CF9 reset
Together with the 13.6-second successful test, this makes a simple "needs several minutes to settle" explanation less likely.
The more important distinction appears to be:
Cinnamon/X graphical teardown completes before reboot request
-> successful reboot
Reboot is requested while Cinnamon/X/display teardown is occurring
-> intermittent failure
This is still correlation, not proof of a deterministic race.
User-service distinction
The successful logout-first tests did not require the entire user manager to exit before reboot.
After Cinnamon and the graphical X session were gone, some user services could still remain until final reboot, including:
systemd --user
D-Bus
PipeWire
WirePlumber
some portal processes
The machine still rebooted normally.
One successful logout-first reboot also contained unrelated errors including a Discord coredump, a cups-browsed shutdown timeout/SIGKILL, and portal/permission-store errors, yet still completed a normal CF9 reboot.
This appears to narrow the important difference toward the Cinnamon/X/display teardown path rather than generic user-service shutdown.
LightDM-stopped control
A separate test was performed over SSH:
sudo systemctl stop lightdm
sudo reboot
After stopping LightDM, the local display went black and no visible VT appeared, but the machine remained alive and responsive remotely.
Reboot then succeeded and the next boot showed the normal CF9 reset signature.
This makes the LightDM service itself less likely to be the primary cause, although X/display teardown associated with it may still be part of the broader interaction.
BIOS/UEFI control
Firmware-initiated reboot from UEFI/BIOS succeeds.
It also succeeded after several hours of Linux use.
This makes a simple motherboard reset-circuit or PSU failure less likely, although firmware/platform reset handling could still be the final point of failure if Linux leaves a problematic device/display state behind.
Secure Boot control
The failure was reproduced with:
secureboot: Secure boot disabled
Therefore Secure Boot does not appear to be a necessary or primary cause.
Kernel-version observation
The behavior has been observed on more than one installed kernel version and does not appear to be exclusive to the current kernel.
Current kernel:
7.0.0-30-generic
DRM/amdgpu workqueue observations
During the retained failed direct-Cinnamon reboot, these warnings were clustered during graphical/display teardown:
workqueue: drm_fb_helper_damage_work hogged CPU for >10000us
workqueue: dm_handle_vmin_vmax_update [amdgpu] hogged CPU for >10000us
There was also:
workqueue: inode_switch_wbs_work_fn hogged CPU for >10000us
The graphics warnings should not be interpreted as proof of the failure.
They also occur during successful reboot history. In fact, an older successful LightDM-stopped reboot showed much higher cumulative counts:
drm_fb_helper_damage_work: up to 1027
dm_handle_vmin_vmax_update [amdgpu]: at least 131
and still rebooted normally.
Therefore warning count/intensity alone does not predict failure.
What may be more relevant is their timing in the failed case, where display-related work was still occurring while Cinnamon/X/LightDM/fbcon teardown and global reboot were overlapping.
System information
Distribution: Linux Mint 22.3 Zena
Desktop: Cinnamon 6.6.9
Session: X11
Display manager: LightDM 1.30.0
Kernel: 7.0.0-30-generic
Mesa: 25.2.8
CPU: AMD Ryzen 5 5500
GPU: AMD Radeon RX 6600 (Navi 23)
PCI ID: 1002:73ff
Driver: amdgpu / radeonsi
Displays:
2560x1440
1920x1080
Motherboard:
MSI MAG B550 TOMAHAWK MAX WIFI
MS-7C91
BIOS:
2.B0
Current interpretation
The strongest discriminator found through controlled testing is:
Cinnamon/X graphical-session teardown finishes
before reboot is requested
-> successful POST / CF9 reset
Restart is requested by Cinnamon while
Cinnamon/X/DRM/display teardown is concurrent
-> intermittent failure to reach POST
This suggests a teardown/reset ordering or timing interaction, but does not establish which component is ultimately defective.
Possible interacting components include:
Cinnamon / cinnamon-session
Xorg
LightDM/X teardown
DRM framebuffer handover / fbcon
amdgpu display-state teardown
kernel shutdown ordering
firmware/chipset platform-reset handling
The exact root cause remains undetermined.
Related issue
Possibly related:
#12423 — "Linux Mint 22 Won't properly shutdown after the PC is powered ON for more than 8 hours"
I do not believe this is an exact duplicate because that report described shutdown failure on Intel graphics and specifically stated that restart worked.
This case includes:
failed reboots as well as incomplete poweroff behavior;
direct-Cinnamon vs logout-first A/B testing;
successful long-session LightDM-greeter reboots;
successful LightDM-stopped reboot;
successful long-session UEFI reboot;
CF9 vs ACPI reset-reason correlation;
precise Cinnamon/X/session teardown ordering;
DRM/amdgpu warning comparisons between successful and failed reboots.
The intent of this report is to provide enough controlled evidence to determine whether the active Cinnamon restart path is exposing an ordering problem elsewhere in the graphics/kernel/platform shutdown stack.