[Bug 222164] MT7902 Bluetooth: firmware coredump after ~10h uptime, then "subsys reset fail" and permanent USB disconnect

[bugzilla-daemon@kernel.org]

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

hongweifei@cyue.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|MT7902 Bluetooth: firmware  |MT7902 Bluetooth: firmware
                   |coredump after ~10h uptime, |coredump after ~10h uptime,
                   |then "subsys reset fail"    |then "subsys reset
                   |and permanent USB           |fail" and permanent
                   |disconnect                  |USB disconnect

--- Comment #3 from hongweifei@cyue.net ---
New data: captured a third occurrence with btmon running, and it revealed
something
much more specific than the original report.

First, an important correction to the timing pattern in my initial report: this
time
the controller died after only 2h38m43s, not ~10h.

    #1  2026-10-19 10:19:24 -> 20:21:44   = 10h02m20s
    #2  2026-10-20 09:50:30 -> 20:01:29   = 10h10m59s
    #3  2026-10-21 10:02:35 -> 12:41:18   =  2h38m43s   <-- much shorter

The difference for #3: btmon was running for the whole session (I started a
capture
at 10:02:35 to collect data for this report). btmon subscribes to all HCI
events, so
firmware event traffic through the driver was higher than usual. I cannot prove
causation, but the correlation is worth noting: the crash came ~4x sooner while
the
monitor was attached. If a firmware-side counter or queue related to diagnostic
events feeds into this, that would fit.

## What the capture shows

Immediately before the coredump, the controller emits a massive flood of
MediaTek **Vendor Diagnostic** events:

    12:41:16.374569   flood starts
                     -> 11348 Vendor Diagnostic events in 1.65 seconds
                     -> ~6878 events/second
                     -> final packet: len 41047 (41 KB in one event;
                        normal HCI events here are tens to ~200 bytes)
    12:41:18.025926   Bluetooth: hci0: Mediatek coredump end
    12:41:28.338162   Bluetooth: hci0: Can't get device id, subsys reset fail.
    12:41:28.370      MGMT Close Index / Delete Index  (controller gone)

Two further observations:

1. **Normal traffic stopped ~20 minutes before the crash.** The last ordinary
ACL
   packet is at 12:20:44.820571; between then and 12:41:18 there is nothing but
   diagnostic events. So the firmware appears to have entered an abnormal state
   well before it finally died, rather than failing instantly.

2. **2372 lines inside the flood contain 16 consecutive zero bytes** (all-zero
   payload fragments). I have not confirmed what they mean; possibly invalid
memory
   being drained, possibly benign padding in diagnostic records.

Sample payload from the flood (first bytes of one 202-byte event):

    6f fc c6 00 5b f0 1a 41 00 2c 51 74 dc 31 5d 5b
    f4 1a 41 00 2c b1 54 bd bf 5d 5b f8 1a 41 00 2c
    0a f2 83 2a 5d 5b fc 1a 41 00 2c 19 a6 39 7b 5d
    ...

This looks more like a memory dump than a meaningful diagnostic stream.

## Attachments

- `mt7902-crash3-analysis.txt` — the numbers above, in one place
- `mt7902-crash3-vendor-flood.log` — excerpt of the flood: first 40 lines at
  12:41:16.374, a middle sample, and the last 300 lines through
  12:41:28.468 (close/delete index). Kept small on purpose.

The full capture is 86 MB of btmon text plus a 15 MB btsnoop; I can upload
those
somewhere if the excerpt is not enough. My question: is there anything specific
in
the Vendor Diagnostic stream you would want extracted? I do not know the
MediaTek
diagnostic event format, so I can pull whatever subset is useful.

One more note: after `subsys reset fail`, nothing recovers the controller short
of
a reboot — details already in my original report.

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

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