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

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

[bugzilla-daemon]

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: linux-bluetooth@vger.kernel.org
          Reporter: zhangzhigang1996@gmail.com
        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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

Zhang Zhigang (zhangzhigang1996@gmail.com) changed:

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

--- Comment #1 from Zhang Zhigang (zhangzhigang1996@gmail.com) ---
### 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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

--- Comment #2 from Zhang Zhigang (zhangzhigang1996@gmail.com) ---
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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

Zhang Zhigang (zhangzhigang1996@gmail.com) 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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pmenzel+bugzilla.kernel.org
                   |                            |@molgen.mpg.de

--- Comment #3 from Paul Menzel (pmenzel+bugzilla.kernel.org@molgen.mpg.de) ---
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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

--- Comment #4 from Zhang Zhigang (zhangzhigang1996@gmail.com) ---
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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

--- Comment #5 from Zhang Zhigang (zhangzhigang1996@gmail.com) ---
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.

[Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test

[bugzilla-daemon]

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

--- Comment #6 from Zhang Zhigang (zhangzhigang1996@gmail.com) ---
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.