All of lore.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 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.