[Bug 222234] New: btintel_pcie: unable to recover from 8086:e476 (BE211) hardware exeption

[Bug 222234] New: btintel_pcie: unable to recover from 8086:e476 (BE211) hardware exeption

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=222234

            Bug ID: 222234
           Summary: btintel_pcie: unable to recover from 8086:e476 (BE211)
                    hardware exeption
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: alastair.swan@bommanager.org
        Regression: No

Hi,

I've had occasional problems where something causes Bluetooth to fail on my
laptop while in normal use and it does not recover without either rebooting or
reloading the btintel_pcie driver.

The specific symptoms are that everything disconnects (mouse, headphones), but
the OS doesn't acknowledge the disconnection and attempts to reconnect fail.
This occurs once or twice a week.

The failure includes these log messages:
[161556.628515] Bluetooth: hci0: Received hw exception interrupt
[161556.628544] Bluetooth: hci0: Received gp1 mailbox interrupt
[161556.628614] Bluetooth: hci0: Controller in error state (boot_stage:
0xd0fb6047)
[161556.630738] Bluetooth: hci0: Invalid exception dump signature: 0x20142001
[175081.190541] Bluetooth: hci0: sending frame failed (-19)
[175088.484946] Bluetooth: hci0: sending frame failed (-19)
[175088.484961] Bluetooth: hci0: Opcode 0x0c1a failed: -19
And every subsequent entry gives the -19 failure. 

I think the underlying hw exception is a real, environmentally driven problem
since it only occurs in a specific room in the house and I've had similar
Bluetooth stability problems in that same room on other laptops but I can't
reproduce it on demand.

I believe I've traced the failure to recover to the `btintel_pcie_read_hwexp`
function in btintel_pcie.c.

I think the -19 failures are due to the `BTINTEL_PCIE_CORE_HALTED` flag getting
set by the initial hw exception interrupt and then never getting cleared.

When attempting to read the dump, the `if (val != BTINTEL_PCIE_MAGIC_NUM)`
check trips and the function cleans up and exits, but there is nothing that
allows the failure to be detected so no recovery can be initiated.

In my kernel version (7.2.11-200.fc44.x86_64) the `if (val !=
BTINTEL_PCIE_MAGIC_NUM)` check might be failing because the driver is trying to
read from a possibly incorrect hardcoded address of `0xB030F800` and so gets
garbage data. This address is no longer hardcoded in 7.4-rc1 and is instead
read on startup which may mask the issue if the correct address is used, but
the fragile code path remains present.

The hardware and firmware that I'm using is: "Intel Bluetooth PCI 8086:e476,
firmware build 102163 (2026.36, ibt-00a0-01a1-pci.sfi)"

Claude suggests the following patch against v7.2.11 but I am unable to test or
vouch for it myself as the right solution. Mainline has changed so the patch
likely won't apply cleanly.

```
diff --git a/drivers/bluetooth/btintel_pcie.c
b/drivers/bluetooth/btintel_pcie.c
index ed4ba2e46..4551098c3 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -1296,9 +1296,13 @@ static int btintel_pcie_recv_frame(struct
btintel_pcie_data *data,
        return ret;
 }

-static void btintel_pcie_read_hwexp(struct btintel_pcie_data *data)
+/* Returns true if at least one HCI event was recovered from device memory
+ * and handed to the stack.
+ */
+static bool btintel_pcie_read_hwexp(struct btintel_pcie_data *data)
 {
        int len, err, offset, pending;
+       bool delivered = false;
        struct sk_buff *skb;
        u8 *buf, prefix[64];
        u32 addr, val;
@@ -1317,7 +1321,7 @@ static void btintel_pcie_read_hwexp(struct
btintel_pcie_data *data)
        case BTINTEL_CNVI_BLAZARIW:
                /* only from step B0 onwards */
                if (INTEL_CNVX_TOP_STEP(data->dmp_hdr.cnvi_top) != 0x01)
-                       return;
+                       return false;
                len = BTINTEL_PCIE_BLZR_HWEXP_SIZE; /* exception data length */
                addr = BTINTEL_PCIE_BLZR_HWEXP_DMP_ADDR;
                break;
@@ -1332,7 +1336,7 @@ static void btintel_pcie_read_hwexp(struct
btintel_pcie_data *data)
                break;
        default:
                bt_dev_err(data->hdev, "Unsupported cnvi 0x%8.8x",
data->dmp_hdr.cnvi_top);
-               return;
+               return false;
        }

        buf = kzalloc(len, GFP_KERNEL);
@@ -1398,10 +1402,12 @@ static void btintel_pcie_read_hwexp(struct
btintel_pcie_data *data)
                               tlv->val, pkt_len, false);

                btintel_pcie_recv_frame(data, skb);
+               delivered = true;
        } while (offset < len);

 exit_on_error:
        kfree(buf);
+       return delivered;
 }

 static int btintel_pcie_dump_fwtrigger_event(struct btintel_pcie_data *data)
@@ -1520,7 +1526,15 @@ static void btintel_pcie_coredump_worker(struct
work_struct *work)
                 * exception event from device memory and passes it stack for
                 * further processing.
                 */
-               btintel_pcie_read_hwexp(data);
+               /* CORE_HALTED is already set, so every TX now fails with
+                * -ENODEV. Recovery (FLR + reprobe) is only started from
+                * hdev->hw_error, which needs an HCI Hardware Error event.
+                * If none could be read back from device memory (e.g. bad
+                * dump signature), inject one so the controller is not left
+                * permanently dead until the module is reloaded.
+                */
+               if (!btintel_pcie_read_hwexp(data))
+                       hci_reset_dev(data->hdev);
                clear_bit(BTINTEL_PCIE_HWEXP_INPROGRESS, &data->flags);
        }
 }
```

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

RE: [Bug,222234] New: btintel_pcie: unable to recover from 8086:e476 (BE211) hardware exeption

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: git diff header lacks filename information when removing 1 leading pathname component (line 2)
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth