New: Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

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

Bug ID: 221346
Summary: Bluetooth: btintel_pcie (8086:e476) may hang in
shutdown path (synchronize_irq) during reboot stress test
Product: Drivers
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Bluetooth
Assignee: [email protected]
Reporter: [email protected]
Regression: No

On a system with Intel Bluetooth device [8086:e476] using the btintel_pcie driver, the system intermittently hangs during reboot or shutdown, especially under stress test conditions (continuous reboot cycles).

During shutdown, systemd-udevd is observed to be stuck in D state. Kernel stack traces show the task blocked in the driver removal path, waiting in synchronize_irq() after free_irq() is called.

The relevant call trace is:

btintel_pcie_remove()
→ free_irq()
→ synchronize_irq()
→ __synchronize_irq()
→ wait for IRQ handler completion (never returns)

This indicates that the interrupt handler associated with the device may not be properly quiesced before free_irq(), leading to a deadlock during teardown.

The issue is reproducible and disappears when the btintel_pcie module is unloaded or blacklisted, suggesting the problem is specific to the btintel_pcie driver.

No firmware loading errors are observed, and the device is otherwise functional during normal operation.

This may indicate incomplete interrupt shutdown handling in the btintel_pcie driver.

You may reply to this email to add a comment.

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

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

Zhang Zhigang ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
Kernel Version| |6.18.1

--- Comment #1 from Zhang Zhigang ([email protected]) --- ### Additional system information

#### Hardware

```
00:14.3 Network controller [0280]: Intel Corporation Device [8086:e440] (rev
01)
00:14.7 Bluetooth [0d11]: Intel Corporation Device [8086:e476] (rev 01)
```

#### PCI device details

```
00:14.7 Bluetooth [0d11]: Intel Corporation Device [8086:e476] (rev 01)
        Subsystem: Intel Corporation Device [8086:0011]
        Kernel driver in use: btintel_pcie
        Kernel modules: btintel_pcie
```

#### Loaded Bluetooth-related modules

```
btintel_pcie           45056  0
btintel                69632  1 btintel_pcie
bluetooth             958464  43 btintel_pcie,btintel,bnep,rfcomm
```

#### Driver information

```
filename:      
/lib/modules/6.18.1-01-perlis001-20260409003/kernel/drivers/bluetooth/btintel_pcie.ko
version:        0.1
description:    Intel Bluetooth PCIe transport driver ver 0.1
```

#### Kernel version

```
6.18.1-01-perlis001-20260409003
```

#### Firmware

Available firmware files under /lib/firmware/intel/ (ibt-*.sfi / .ddc present)

Note:
No firmware loading messages observed in dmesg.

#### dmesg (Bluetooth-related)

```
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
```

#### udev device path

```
/devices/pci0000:00/0000:00:14.7/bluetooth/hci0
```

#### Interrupts

```
IR-PCI-MSIX-0000:00:14.7    btintel_pcie
```

#### Additional observations

* systemd-udevd enters D state during shutdown
* Issue disappears when btintel_pcie is unloaded or blacklisted
* Problem reproducible under reboot stress test

You may reply to this email to add a comment.

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

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

--- Comment #2 from Zhang Zhigang ([email protected]) --- Created attachment 309857
--> https://bugzilla.kernel.org/attachment.cgi?id=309857&action=edit
crash log images

You may reply to this email to add a comment.

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

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

Zhang Zhigang ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

You may reply to this email to add a comment.

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

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

Paul Menzel ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |pmenzel+bugzilla.kernel.org
                   |                            |@molgen.mpg.de

--- Comment #3 from Paul Menzel ([email protected]) --- It’d be great if you could comment, what the problem was making you close this as invalid.

You may reply to this email to add a comment.

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

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

--- Comment #4 from Zhang Zhigang ([email protected]) --- Hi,

Thanks for your follow-up.

I’d like to clarify that I did not close the issue because the problem was resolved. The issue still exists, but I temporarily marked it as invalid due to lack of sufficient debugging data from my side.

Here is the current status:

1. The system still occasionally hangs during shutdown.
2. The hang happens at a relatively late stage of the shutdown process.
3. It is difficult to capture logs, since at that point most logging services are already stopped. Currently, I can only observe the last messages on the screen.

I also attempted to rule out Bluetooth-related causes by blacklisting the relevant kernel modules:

* btintel_pcie
* btintel
* btusb
* bluetooth

However, even with Bluetooth disabled, the shutdown hang still occurs. This suggests that the issue is likely unrelated to Bluetooth.

Given that my understanding of the kernel is still relatively limited, I would greatly appreciate any suggestions on more effective debugging methods, especially for capturing logs during late shutdown stages.

Thank you for your time and support.
Additional information:

* The issue is intermittent and not easily reproducible.
* I am willing to test patches or enable additional debug options if needed.
* Please let me know if enabling specific kernel parameters (e.g. debug, earlyprintk, pstore, etc.) would help capture more useful logs.

You may reply to this email to add a comment.

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

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

--- Comment #5 from Zhang Zhigang ([email protected]) --- Created attachment 309872
--> https://bugzilla.kernel.org/attachment.cgi?id=309872&action=edit
The machine used

You may reply to this email to add a comment.

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

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

--- Comment #6 from Zhang Zhigang ([email protected]) --- I would like to provide more details about my system setup, as it may be relevant to the shutdown hang issue.

My filesystem layout is non-standard. In addition to /boot and /, I have a separate /data partition, and several key directories are bind-mounted from it.

Current block layout:

* nvme0n1p1 → /boot
* nvme0n1p3 → / (root filesystem)
* nvme0n1p5 → /data

The /data partition contains subdirectories which are bind-mounted to standard system paths:

* /data/home      → /home
* /data/var       → /var
* /data/local     → /usr/local
* /data/opt       → /opt

Example mount output:

```
aa [ ~ ]$ lsblk 
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476.9G  0 disk 
├─nvme0n1p1 259:1    0   511M  0 part /boot
├─nvme0n1p2 259:2    0  14.6G  0 part 
├─nvme0n1p3 259:3    0  19.5G  0 part /
├─nvme0n1p4 259:4    0  19.5G  0 part 
└─nvme0n1p5 259:5    0 422.7G  0 part /var
                                      /usr/local
                                      /opt
                                      /home
                                      /data
aa [ ~ ]$ mount | grep nvme
/dev/nvme0n1p3 on / type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p1 on /boot type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/nvme0n1p5 on /data type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p5 on /home type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p5 on /opt type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p5 on /usr/local type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p5 on /var type ext4 (rw,relatime,seclabel)

aa [ ~ ]$ ls -a /data/
.  ..  home  local  opt  .swap.img  var
```

These mounts are managed via systemd .mount units . Key characteristics:

1. /data is mounted early with DefaultDependencies=no
2. Other mount points (/home, /var, /usr/local, /opt) are bind mounts with:

* BindsTo=data.mount
* After=data.mount
3. All mount units explicitly include:

* Conflicts=umount.target shutdown.target
4. Additional ordering is enforced via:
/etc/systemd/system/sysinit.target.d/data-mount.conf

This setup ensures that /data is mounted before other system paths and that dependent mounts are tied to it.

```
cat >/etc/systemd/system/data.mount <<"EOF"
[Unit]
Description=Data Partition
DefaultDependencies=no

After=systemd-udevd.service
Before=systemd-journald.service sysinit.target local-fs.target

OnFailure=emergency.target
Conflicts=umount.target shutdown.target

[Mount]
What=/dev/disk/by-uuid/UUID
Where=/data
Type=ext4
Options=defaults

[Install]
WantedBy=local-fs.target
EOF

cat >/etc/systemd/system/home.mount <<"EOF"
[Unit]
Description=Bind /data/home → /home
DefaultDependencies=no

BindsTo=data.mount
After=data.mount
Before=sysinit.target local-fs.target
Conflicts=umount.target shutdown.target

[Mount]
What=/data/home
Where=/home
Type=none
Options=bind

[Install]
WantedBy=local-fs.target
EOF

cat >/etc/systemd/system/var.mount <<"EOF"
[Unit]
Description=Bind /data/var → /var
DefaultDependencies=no

BindsTo=data.mount
After=data.mount
Before=systemd-journald.service sysinit.target local-fs.target
Conflicts=umount.target shutdown.target

[Mount]
What=/data/var
Where=/var
Type=none
Options=bind

[Install]
WantedBy=local-fs.target
EOF

cat >/etc/systemd/system/usr-local.mount <<"EOF"
[Unit]
Description=Bind /data/local → /usr/local
DefaultDependencies=no

BindsTo=data.mount
After=data.mount
Before=sysinit.target local-fs.target
Conflicts=umount.target shutdown.target

[Mount]
What=/data/local
Where=/usr/local
Type=none
Options=bind

[Install]
WantedBy=local-fs.target
EOF

cat >/etc/systemd/system/opt.mount <<"EOF"
[Unit]
Description=Bind /data/opt → /opt
DefaultDependencies=no

BindsTo=data.mount
After=data.mount
Before=sysinit.target local-fs.target
Conflicts=umount.target shutdown.target

[Mount]
What=/data/opt
Where=/opt
Type=none
Options=bind

[Install]
WantedBy=local-fs.target
EOF

mkdir -pv /etc/systemd/system/sysinit.target.d
cat >/etc/systemd/system/sysinit.target.d/data-mount.conf <<"EOF"
[Unit]
Requires=data.mount var.mount home.mount usr-local.mount opt.mount
After=data.mount var.mount home.mount usr-local.mount opt.mount
EOF
```

However, I suspect this layout might be contributing to the shutdown hang, especially during the late unmount phase. Since multiple critical directories (e.g. /var) are bind-mounted from a single filesystem, there may be ordering or dependency issues when systemd tries to unmount them.

The issue still occurs intermittently and typically at a late stage of shutdown, where logging is limited.

If this filesystem layout or mount configuration could potentially trigger such behavior, I would appreciate any guidance on how to further debug or simplify the setup for testing.

Thank you.

You may reply to this email to add a comment.

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