From: bugzilla-daemon@kernel.org
To: linux-bluetooth@vger.kernel.org
Subject: [Bug 221346] Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test
Date: Wed, 15 Apr 2026 06:16:22 +0000 [thread overview]
Message-ID: <bug-221346-62941-puMcSTn4q7@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-221346-62941@https.bugzilla.kernel.org/>
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.
prev parent reply other threads:[~2026-04-15 6:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 12:38 [Bug 221346] New: Bluetooth: btintel_pcie (8086:e476) may hang in shutdown path (synchronize_irq) during reboot stress test bugzilla-daemon
2026-04-11 12:41 ` [Bug 221346] " bugzilla-daemon
2026-04-11 12:45 ` bugzilla-daemon
2026-04-14 6:07 ` bugzilla-daemon
2026-04-14 6:45 ` bugzilla-daemon
2026-04-15 5:53 ` bugzilla-daemon
2026-04-15 5:59 ` bugzilla-daemon
2026-04-15 6:16 ` bugzilla-daemon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-221346-62941-puMcSTn4q7@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox