public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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