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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.