[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     |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.