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

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

[bugzilla-daemon]

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

            Bug ID: 222164
           Summary: MT7902 Bluetooth: firmware coredump after ~10h uptime,
                    then "subsys reset fail" and permanent USB disconnect
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: hongweifei@cyue.net
        Regression: No

[1.] One line summary of the problem:

    MT7902 Bluetooth controller dies after ~10 hours of uptime with a firmware
    coredump, then "Can't get device id, subsys reset fail", after which the
USB
    device becomes permanently unresponsive and only a reboot restores
Bluetooth.

[2.] Full description of the problem/report:

    On an ASUS Vivobook X1605VA (MediaTek MT7902: WiFi over PCIe, Bluetooth
over
    USB), the Bluetooth controller stops working after roughly 10 hours of
    uptime. Kernel log at the moment of failure:

        Bluetooth: hci0: Mediatek coredump end
        Bluetooth: hci0: Can't get device id, subsys reset fail.
        usb 1-10: device descriptor read/64, error -110
        usb 1-10: USB disconnect, device number 4

    After this, hci0 never reappears. None of the recovery methods in [6.]
bring
    it back; only a full reboot restores Bluetooth.

    The most interesting observation: the failure is highly time-consistent.
    Two independent occurrences, each from a clean boot:

        #1  2026-10-19 10:19:24 boot -> 2026-10-19 20:21:44 crash  (10h02m20s)
        #2  2026-10-20 09:50:30 boot -> 2026-10-20 20:01:29 crash  (10h10m59s)

    The difference between the two is only 519 seconds (8.7 minutes) out of a
    ~10 hour period, i.e. within 1.5% of each other. This does not look like a
    random firmware fault; it looks like something counting up (a timer, a
    watchdog, a log buffer, or a leak crossing a threshold after fixed
activity).

    The machine is on 24/7 and was idle in both cases: no Bluetooth audio
    streaming, no active connections, paired keyboard and mouse both idle.

[3.] Keywords (modules, filesystems, etc):

    bluetooth, btusb, btmtk, mt7902, usb, xhci_hcd, devcoredump

[4.] Kernel information:

    Kernel: 7.2.8-9-omarchy (Arch-based; Omarchy 4.0.4)
    BlueZ: 5.87-2
    linux-firmware: 20260916-1
    btusb: version 0.8 (in-tree)

    Bluetooth firmware:
        HW/SW Version: 0x008a008a, Build Time: 20250826211444

    Hardware:
        PCI WiFi:  0000:02:00.0  MEDIATEK MT7902 802.11ax [14c3:7902]
        USB BT:    13d3:3579 (AzureWave / MediaTek), on usb1-10

    IMPORTANT VARIABLE: the WiFi half is running an OUT-OF-TREE driver
    (morrownr/mt76 build, module names mt7921e_git / mt7921_common_git /
    mt792x_lib_git) with disable_aspm=1, and the in-tree mt76 is blacklisted
via
    /etc/modprobe.d/mt76_git.conf. This is a deliberate workaround for a
separate
    MT7902 WiFi TX-power bug (ACPI MTGS 0xFF treated as -1 dBm, capping TX at
    ~2 dBm). I have NOT yet tested whether the Bluetooth crash also occurs with
    the stock in-tree WiFi driver. I mention it because it may be relevant, and
I
    am willing to test with the in-tree driver if requested.

    Relevant modules loaded at crash time:
        btusb                0
        btmtk                1  btusb
        mt7921e_git          0
        mt7921_common_git    1  mt7921e_git
        mt792x_lib_git       2  mt7921e_git, mt7921_common_git

[5.] Most recent kernel version which did not have the bug:

    Unknown. I do not have logs from before these two occurrences, so I cannot
    say whether this is a regression.

[6.] Output of Oops.. message (if applicable) with symbolic information:

    There is NO oops, KASAN report, lockdep splat, or any kernel warning in the
    logs. This does not appear to be a kernel memory corruption in the driver;
    the controller itself becomes unresponsive at the USB level.

    Recovery methods attempted while in the failed state, ALL of which failed:

      1. USB port re-enumeration:
           echo 1 > /sys/bus/usb/devices/usb1/1-0:1.0/usb1-port10/disable
           (sleep) ; echo 0 > .../disable
         -> no device comes back

      2. Driver reload:
           modprobe -r btusb btmtk ; modprobe btusb
         -> no hci0

      3. Combined: unload drivers -> port re-enumerate -> load drivers
         -> no hci0

      4. xHCI controller unbind/bind:
           echo 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
           echo 0000:00:14.0 > /sys/bus/pci/drivers/xhci_hcd/bind
         -> controller re-bound successfully and ALL OTHER USB devices on the
            same controller re-enumerated normally (webcam, USB storage,
            keyboard), but the Bluetooth device did NOT come back. This
strongly
            suggests the BT controller is not merely in a bad driver state; it
is
            not responding on the bus at all after the firmware crash.

    Only reboot restores it.

[7.] A small shell script or example program which triggers the bug:

    None. It appears to be time-based / idle-triggered; no user action
required.
    Uptime alone (about 10 hours) seems sufficient.

[8.] Environment:

    Arch Linux / Omarchy 4.0.4, Hyprland 0.56.2 (Wayland), kernel
7.2.8-9-omarchy.
    Laptop: ASUS Vivobook X1605VA, Intel Raptor Lake-P, Iris Xe graphics.

[9.] Other notes:

    No coredump payload was captured. /sys/class/devcoredump/disabled is 0
    (feature enabled) but the directory contains no devcd* entry. Either the
    default 5-minute devcd_timeout expired long before I inspected it, or the
    dump never materialised because the device stopped responding mid-dump. I
    will raise devcd_timeout and try to capture it on the next occurrence.

    Also note there is only a "Mediatek coredump end" line in the log, with no
    matching "coredump start" line before it. I do not know if that is expected
    for this firmware.

    WiFi (the same MT7902 chip, PCIe side) continues to work fine through the
    Bluetooth failure; the two halves appear independent here.

    The machine is on 24/7 and gets a clean boot daily, so this reproduces
    roughly every 10 hours. I am happy to run btmon captures, enable
    tracepoints, or collect firmware debug logs on request.

    Questions I would appreciate help with:
      - What could be time-based here? A watchdog/keepalive/counter in btmtk
for
        MT7902 that could trip after a fixed period?
      - Is this a known failure mode? I only found CVE-2024-56653
        ("btmtk: avoid UAF in btmtk_process_coredump"), which does not appear
to
        apply: that is a UAF in dump handling, there is no KASAN report here,
and
        the fix long predates 7.2.
      - Should "subsys reset" be able to recover this? It reports "Can't get
        device id". Is there a btmtk recovery path that resets the controller
        over USB without losing the device, or is full USB re-enumeration the
        only option (and if so, why did it fail here)?
      - Anything specific I should capture next time?

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

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

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

[bugzilla-daemon]

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

--- Comment #1 from hongweifei@cyue.net ---
Created attachment 311208
  --> https://bugzilla.kernel.org/attachment.cgi?id=311208&action=edit
Kernel log around crash #2 (2026-10-20 20:01:29), unfiltered

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

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

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

[bugzilla-daemon]

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

--- Comment #2 from hongweifei@cyue.net ---
Created attachment 311209
  --> https://bugzilla.kernel.org/attachment.cgi?id=311209&action=edit
System info: kernel/bluez/firmware versions, hardware IDs, loaded modules,
crash timing

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

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

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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #4 from hongweifei@cyue.net ---
Created attachment 311214
  --> https://bugzilla.kernel.org/attachment.cgi?id=311214&action=edit
Crash #3 quantitative analysis: 11348 Vendor Diagnostic events in 1.65s, 20 min
of silence before coredump, uptime comparison

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

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

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

[bugzilla-daemon]

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

--- Comment #5 from hongweifei@cyue.net ---
Created attachment 311215
  --> https://bugzilla.kernel.org/attachment.cgi?id=311215&action=edit
Crash #3 btmon excerpt: first 40 lines of the Vendor Diagnostic flood, middle
sample, last 300 lines through close/delete index

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

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

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

[bugzilla-daemon]

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     |then "subsys reset
                   |fail" and permanent    |fail" and
                   |USB disconnect              |permanent USB disconnect

--- Comment #6 from hongweifei@cyue.net ---
I analyzed the captured HCI trace to answer whether the host side triggers
this, and
to separate two questions that the log actually supports differentiating:

  (a) what makes the firmware die, and
  (b) why the driver cannot bring the controller back afterwards.

## (a) The host is not triggering the firmware crash

From the btmon trace of occurrence #3, the host side was completely quiet for
over
ten minutes before the firmware fell over:

    12:30:45.022549   < HCI Command (0x08|0x0042) LE Set Extended Scan Enable
                      -> Status: Success (0x00)
                      (last HCI command sent by the host, ever)

    12:30:45.02  ->  12:41:16.37     = 10 min 31 s with ZERO host commands

    during that same window the firmware kept working normally, sending 19
    HCI events of its own (Authentication (0x57), etc.)

    12:41:16.374569   firmware starts emitting the Vendor Diagnostic flood
    12:41:18.025926   Bluetooth: hci0: Mediatek coredump end

So: no failed command, no error status, no unusual command sequence, no command
flood from the driver. The last thing the driver did was a routine scan-enable
that
returned Success, and then it did nothing at all for 10.5 minutes. The firmware
then
entered an abnormal state on its own and produced ~6878 diagnostic
events/second,
ending in a 41 KB event and a coredump.

Also worth stating explicitly: there is no KASAN, oops, or lockdep output
anywhere
in the kernel log for any of the three occurrences. So this is not memory
corruption
inside the driver either.

## (b) But the recovery failure may still be ours

This is where I think the kernel side could help, even though the crash itself
looks
firmware-side:

The diagnostic flood arrives through the normal HCI event path, so `btmtk` is
processing it while the firmware is dying — including that final 41 KB event,
which
is far larger than any normal HCI event. Two things I would like to understand:

1. **Is `btmtk_process_coredump()` handling a pathological input stream
safely?**
   11348 events in 1.65 s, ending in a 41 KB event, with 2372 all-zero payload
   fragments mixed in. If the dump path allocates per-event or has any bound
that
   assumed sane firmware behaviour, this is exactly the input that would break
it.

2. **Why does `subsys reset` fail, and can recovery be stronger?**
   The failure is `Bluetooth: hci0: Can't get device id, subsys reset fail.`
   after which the USB device stops answering descriptor reads entirely
   (`device descriptor read/64, error -110`) and never comes back.

   From the user side I tried and confirmed the following do NOT recover it
   (details and the exact commands are in my original report):
   USB port re-enumerate, driver reload (`btusb`/`btmtk`), unload-drivers-then-
   re-enumerate-then-reload, and finally xHCI controller unbind/bind. For the
last
   one, the controller re-bound fine and every other USB device on it (webcam,
   storage, keyboard) re-enumerated normally — only the Bluetooth controller
   stayed dead. That says the controller is not merely stuck in a bad driver
state.

   Question: is there a recovery path that re-downloads the firmware to the
   controller over USB after a coredump (like a full re-initialisation rather
than
   a subsystem reset)? If the firmware can crash on its own after hours,
"notify
   the user, they must reboot" is a poor outcome when the device might be
   recoverable by re-uploading firmware. I do not know whether the MT7902
hardware
   allows that after this particular failure mode — hence asking rather than
   assuming.

## Summary of where the evidence points

- Firmware crash: appears to be firmware-side. Host idle for 10.5 min
beforehand,
  firmware answering normally right up to the moment it starts dumping.
- Permanent controller loss afterwards: possibly improvable on the kernel side,
  either in coredump handling robustness or in a deeper recovery path than
  `subsys reset`.

Happy to collect more targeted data — e.g. ftrace on the btmtk coredump path,
or a
run with the flood piped through while watching allocation behaviour — if that
would
be useful.

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

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