[Bug 222164] New: 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

            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.