Public bug reported:
[Impact]
Bluetooth call trace shows up during boot on Dell systems with Intel PCIe
Bluetooth controllers (CID: F14-DVT2-C1X). It can hang the system's
shutdown/boot flow. Hit rate is about 1 in 500 boots.
Error log:
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000db0
kernel: RIP: 0010:btintel_pcie_dump_debug_registers+0x20/0x8f0 [btintel_pcie]
kernel: Call Trace:
kernel: ? bt_err+0x7a/0xa7 [bluetooth]
kernel: btintel_pcie_irq_msix_handler+0x1a2/0x230 [btintel_pcie]
kernel: irq_thread_fn+0x26/0x70
kernel: irq_thread+0xbc/0x1c0
kernel: kthread+0xf7/0x130
kernel: ret_from_fork+0x195/0x2a0
kernel: ret_from_fork_asm+0x1a/0x30
The crash hits in the MSI-X interrupt thread while dumping debug registers, and
the reset/coredump path around it has several races that can corrupt driver
state or drop RX events during a coredump.
[Fix]
Eight btintel_pcie driver fixes, in dependency order. Merged in v7.2:
e43b33bf8d671 Bluetooth: btintel_pcie: Load IOSF debug regs by controller
variant
Fixes the debug register base address for Scorpius Peak vs Blazar family
controllers. This is the direct fix for the NULL pointer crash in
btintel_pcie_dump_debug_registers() above: the driver read the wrong IOSF base
for the controller variant on the affected system.
2d00975c841fa Bluetooth: btintel_pcie: Support Product level reset
975a70ff0aec8 Bluetooth: btintel_pcie: Add support for smart trigger dump
4d62d88e7ae6d Bluetooth: btintel_pcie: Add 50 ms delay before MAC init on
BlazarIW
f70f7f2512c6b Bluetooth: btintel_pcie: Separate coredump work from RX work
These add product-level reset support, smart trigger coredumps, and a
timing fix for BlazarIW fast-restart, and move coredump processing off
the RX workqueue so RX events don't get dropped while a coredump runs.
They land ahead of the reset-path rework below.
Not yet in a released kernel, merged in the bluetooth-next tree (not yet
released upstream):
603b91aeb20a2 Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()
ca75417ab1793 Bluetooth: btintel_pcie: split coredump worker into per-trigger
works
bd8bee79e1fa8 Bluetooth: btintel_pcie: serialize reset_type with
RECOVERY_IN_PROGRESS
These rework the reset/coredump internals: FLR now shares the same
teardown/re-init path as PLDR through device_reprobe() instead of an
open-coded, easy-to-desync copy; the combined coredump worker is split
into three single-purpose workers (coredump, hw-exception, fw-trigger)
each owning one guard bit, closing a race where a duplicate IRQ could
requeue while the previous coredump was still finishing; and reset_type
is now written only after the RECOVERY_IN_PROGRESS bit is won, closing a
window where two concurrent hardware-error events could pick different
reset types for the same recovery attempt.
These 3 follow-up patches were requested directly by the ODM (Hugh Chao)
after testing showed the debug-register fix alone was not enough; they
close races that the ODM's stress test could still trigger.
[Test Plan]
Reproduce on the affected Dell platform with the Intel PCIe Bluetooth
controller:
Run WB (wireless/Bluetooth) stress test across repeated boot cycles (the ODM's
test hit the bug at roughly 1/500 boots).
Without patches: btintel_pcie_dump_debug_registers NULL pointer
dereference call trace shows up in dmesg during boot, can block
shutdown.
With patches: no call trace, no NULL pointer dereference across repeated
boot/stress cycles. ODM confirmed the 3 bluetooth-next patches fixed the
issue on their test kernel.
[Where problems could occur]
Could break the Bluetooth btintel_pcie driver's reset and coredump paths on
Intel PCIe Bluetooth controllers (Blazar and Scorpius Peak families).
If the IOSF base address selection by variant is wrong for some SKU,
coredump reads would return garbage instead of crashing, making register
dumps useless without an obvious symptom.
If the FLR-to-device_reprobe() refactor has a bug, a function-level
reset could leave the Bluetooth hci device half torn down, causing
btintel_pcie_probe() to fail on reprobe and BT to stay non-functional
after a reset event, instead of the driver silently working around it as
before.
If the split coredump workers or the RECOVERY_IN_PROGRESS serialization
miss a case, two reset/coredump triggers could still race, corrupting a
coredump buffer or leaving a stale reset_type, which would show up as an
incomplete or garbled coredump, or the wrong reset variant (FLR vs PLDR)
running when a hardware error hits.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Affects: linux-oem-7.0 (Ubuntu)
Importance: Undecided
Status: Invalid
** Affects: linux (Ubuntu Resolute)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Affects: linux-oem-7.0 (Ubuntu Resolute)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Affects: linux (Ubuntu Stonking)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Affects: linux-oem-7.0 (Ubuntu Stonking)
Importance: Undecided
Status: Invalid
** Also affects: linux (Ubuntu Resolute)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Stonking)
Importance: Undecided
Status: New
** Also affects: linux-oem-7.0 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-oem-7.0 (Ubuntu Stonking)
Status: New => Invalid
** Changed in: linux-oem-7.0 (Ubuntu Resolute)
Status: New => In Progress
** Changed in: linux-oem-7.0 (Ubuntu Resolute)
Assignee: (unassigned) => AceLan Kao (acelankao)
** Changed in: linux (Ubuntu Resolute)
Status: New => In Progress
** Changed in: linux (Ubuntu Stonking)
Status: New => In Progress
** Changed in: linux (Ubuntu Resolute)
Assignee: (unassigned) => AceLan Kao (acelankao)
** Changed in: linux (Ubuntu Stonking)
Assignee: (unassigned) => AceLan Kao (acelankao)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163723
Title:
btintel_pcie NULL pointer call trace during boot on Intel Bluetooth
PCIe controllers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163723/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
