[Bug 221481] New: btintel_pcie: suspend fails with -EBUSY on Intel Lunar Lake (s2idle)

[Bug 221481] New: btintel_pcie: suspend fails with -EBUSY on Intel Lunar Lake (s2idle)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=221481

            Bug ID: 221481
           Summary: btintel_pcie: suspend fails with -EBUSY on Intel Lunar
                    Lake (s2idle)
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: blocking
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: vladko@duck.com
        Regression: No

Summary:
btintel_pcie returns -16 (EBUSY) during suspend, causing the entire suspend
operation to abort on Intel Lunar Lake hardware. The system immediately resumes
after every suspend attempt.

Hardware:
- CPU/Platform: Intel Lunar Lake
- Bluetooth device: btintel_pcie at PCI 0000:00:14.7
- iGPU: Intel Arc 140V (xe driver)

Software
- Kernel: 6.19.13-arch1-1
- Distribution: EndeavourOS (Arch-based)
- Desktop: KDE Plasma (Wayland)
- Sleep state: s2idle only (mem_sleep shows [s2idle], no S3/deep)

Reproduction
1. Boot system with btintel_pcie loaded
2. Run: systemctl suspend
3. System immediately wakes up; suspend never enters sleep state

Kernel log (relevant excerpt)
  kernel: PM: suspend entry (s2idle)
  kernel: btintel_pcie 0000:00:14.7: PM: pci_pm_suspend(): btintel_pcie_suspend
[btintel_pcie] returns -16
  kernel: btintel_pcie 0000:00:14.7: PM: dpm_run_callback(): pci_pm_suspend
returns -16
  kernel: btintel_pcie 0000:00:14.7: PM: failed to suspend async: error -16
  kernel: PM: Some devices failed to suspend, or early wake event detected
  kernel: PM: suspend exit
  systemd-sleep: Failed to put system to sleep. System resumed again: Device or
resource busy

Workaround
Manually unloading the module before suspend allows sleep to succeed:
modprobe -r btintel_pcie && systemctl suspend

Expected behavior
btintel_pcie should successfully suspend alongside the rest of the system
during
s2idle, or yield gracefully so the suspend proceeds without it.

Notes
/sys/power/mem_sleep reports [s2idle] only (no deep/S3), consistent with
Lunar Lake's lack of S3 support. The issue is reproducible 100% of the time
with the module loaded.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.