Public bug reported: Intermittent shutdown hang — fans and power remain on for several minutes after shutdown is initiated, requiring a forced power-off. Appears to correlate with upgrade from kernel `7.0.0-27-generic` to `7.0.0-28-generic`.
## System Information - **Laptop:** Lenovo IdeaPad L340-15API, Type 81LW - **CPU/APU:** AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (Picasso/Raven2, VBIOS 113-PICASSO-114) - **BIOS/UEFI:** ARCN37WW, dated 05/14/2021 — confirmed to be the latest version available from Lenovo for this model - **OS:** Kubuntu 26.04 LTS, KDE Plasma 6.6.5, Wayland session only (no X11) - **Kernel at time of both incidents:** `7.0.0-28-generic` - **Kernel previously in use for ~3 weeks with no incident:** `7.0.0-27-generic` ## Symptom A normal shutdown is initiated (via the desktop environment's shutdown menu). All applications and the session close normally, and the screen goes blank as expected. However, the laptop's fans and power/status continue running for an extended period afterward (~10 minutes observed) with no display output. The system does not respond to the power button being pressed briefly; holding it for ~10 seconds forces a full power- off. This has occurred at least five times, on separate dates, all while running kernel `7.0.0-28-generic`. It is intermittent and has not been reproduced on demand. ## Timeline / Possible Regression - Kernel upgraded from `7.0.0-27-generic` to `7.0.0-28-generic`: approximately 6 days before the first observed hang - No shutdown hang was observed at any point during the ~3 weeks of normal use on `7.0.0-27-generic` - All observed hangs occurred while running `7.0.0-28-generic` ## Log Evidence In all two incidents that was observed, the OS-level shutdown sequence completed fully and normally — `systemd-shutdown` reached its final logged steps (syncing filesystems, sending SIGTERM to remaining processes, journal stopping) in well under two seconds, with no hung services, timeouts, or errors within the shutdown sequence itself: ```markup systemd[1]: Reached target poweroff.target - System Power Off. systemd[1]: Shutting down. systemd-shutdown[1]: Syncing filesystems and block devices. systemd-shutdown[1]: Sending SIGTERM to remaining processes… systemd-journald[XXX]: Journal stopped ``` No further OS-level logging exists beyond this point in either incident, since journald stops at this stage by design. This indicates the hang occurs after the kernel/OS has finished its shutdown work and handed off control to firmware/hardware to actually power off — i.e., after the point where OS logging can capture anything further. **An anomaly present in both incidents' boot logs** (occurring at boot time, not at shutdown time, in each of the two affected boots): ```markup acpi PNP0C02:01: Could not reserve [io 0x0cf9] ``` Port `0xCF9` is the standard ACPI reset/power-off control register. The kernel reports being unable to reserve this I/O port at boot in both of the affected boots. It has not been confirmed whether this is causally related to the later shutdown hang, or a separate, possibly benign condition that happens to co-occur; it is the only anomaly of any kind found in either boot's logs relating to ACPI/power management. **Incident #2 additionally showed** a non-fatal timeout during the shutdown sequence: ```markup systemd[1]: [email protected]: State 'stop-sigterm' timed out. Killing. systemd[1]: [email protected]: Killing process 1410 (systemd) with signal SIGKILL. systemd[1]: [email protected]: Killing process 1924 (obexd) with signal SIGKILL. systemd[1]: [email protected]: Failed with result 'timeout'. ``` `obexd` is the Bluetooth OBEX object-exchange daemon. This timeout added a delay of several seconds to the shutdown sequence but did not by itself account for the full multi-minute hang, since the OS-level shutdown sequence still completed normally afterward (reaching `poweroff.target` as shown above). Checking a separate, unrelated boot (a normal desktop logout/login cycle, not a shutdown-hang incident) showed the same `[email protected]`/`obexd` stop completing cleanly and quickly with no timeout, so this specific timeout was not confirmed to be a consistent, repeatable pattern. ## What Has Been Checked and Ruled out - USB and Ethernet Wake-on-LAN settings (`enp3s0`, and the USB interfaces associated with the wifi/Bluetooth combo chip, Qualcomm Atheros QCA9377) — checked directly via sysfs and already found to be `disabled` - A `powertop` report flagged several devices' wakeup settings as suboptimal for battery-life purposes — determined on inspection to be an unrelated battery-tuning recommendation, not connected to the shutdown hang - A manually-installed GRUB boot theme present on the system — confirmed to be cosmetic only (fonts and images, no scripts or kernel parameter changes) and unrelated - BIOS confirmed to already be at the latest version available from Lenovo for this model - Secure Boot was disabled during troubleshooting; no mechanism was identified connecting Secure Boot state to this issue, and no kernel modules or packages were found to have been blocked or held back as a result of it having previously been enabled - A BIOS setting called "Flip to Boot," reported elsewhere by other Lenovo IdeaPad owners as a fix for an outwardly identical symptom, was searched for in this laptop's BIOS but is not present as an available option on this model/BIOS revision - Kernel boot parameter `reboot=acpi` was tried as a mitigation (to prefer the ACPI-defined reset method) — this did **not** prevent recurrence; the hang occurred again with this parameter active, and the `0xCF9` reservation anomaly was still present in that boot's log, unchanged - Kernel boot parameter `amdgpu.gpu_recovery=1` was also in place during both incidents (added in response to a separate, unrelated `amdgpu` PSP firmware issue on this same machine) — did not appear to have any effect on this shutdown-hang issue either way ## Filesystem/data Safety Note In both observed incidents, disks were confirmed fully synced and filesystems unmounted (per the log excerpt above) before the hang began. Forcing a power-off via the power button at this stage has not resulted in any observed filesystem corruption or data loss. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2161635 Title: shutdown hang. power and fans remain on forever To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161635/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
