MT6639 BT (0489:e13a) never initializes: HW/SW version reads 0x00000000, controller drops off USB bus during wmt patch download — identical with DKMS and in-tree (7.1) btusb

[Sciruss]

Configuration

Board: ASUS ProArt X870E-Creator WiFi, rev 2 (WiFi 14c3:7927, BT 0489:e13a — both confirmed via lspci/journalctl). BIOS 2402 (2026-07, latest).
Distro / kernel: CachyOS, 7.1.8-1-cachyos (CONFIG_BT_HCIBTUSB=m, CONFIG_BT_HCIBTUSB_MTK=y), fully updated as of 2026-08-15
Package: mediatek-mt7927-dkms 2.13-1 (AUR)
Secure Boot: disabled
WiFi status: working normally via DKMS mt7925e throughout
Current BT config: stock in-tree btusb/btmtk restored to the kernel tree; DKMS btusb/btmtk manually sidelined (this is why dkms status reports "Differences between built and installed modules" — intentional, see packaging section)

Summary

Bluetooth has never initialized on this board. The controller enumerates normally, btusb probes it, the HW/SW version query returns all zeros, and the controller then disconnects itself from the USB bus during the wmt patch download. This puts it into the #23 lockup state (absent from lsusb, persists across warm reboots; only a full PSU drain restores enumeration — after which the next boot reproduces the same crash).

Critically, the failure is identical with the in-tree kernel 7.1 driver and with the DKMS driver (captures below), so this does not appear to be a bug in this package's BT patches. I'm reporting it here because this is where MT6639/e13a expertise is concentrated, and because I found two packaging issues along the way (bottom section) that are bugs regardless.

Failure captures

All boots below are clean cold boots after a full PSU drain per the #23 workaround. USB autosuspend disabled and confirmed (enable_autosuspend=N).

In-tree btusb — current canonical capture (2026-08-17, BIOS 2402, system fully updated)

Stock kernel 7.1.8 module, verified: modinfo -F filename btusb → kernel/drivers/bluetooth/btusb.ko.zst, loaded srcversion 6510C8D2538FEDC20BE17F1 (btmtk 755548AA70EFE4F298B5146).

[    2.459679] usb 1-6: new high-speed USB device number 5 using xhci_hcd
[    2.646735] usb 1-6: New USB device found, idVendor=0489, idProduct=e13a, bcdDevice= 1.00
[    2.646742] usb 1-6: Manufacturer: MediaTek Inc.
[   33.710945] usbcore: registered new interface driver btusb
[   33.712989] Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20250606201235
[   35.016091] usb 1-6: USB disconnect, device number 5
[   45.135573] Bluetooth: hci0: Execution of wmt command timed out
[   45.135579] Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
[   45.135593] Bluetooth: hci0: failed to reset (-19)
[   45.135594] Bluetooth: hci0: Failed to set up firmware (-110)

DKMS btusb (v2.13 — srcversion 07AED3D4468A5E067DC40F0, loaded from updates/dkms/)

[    2.459587] usb 1-6: new high-speed USB device number 5 using xhci_hcd
[    2.647395] usb 1-6: New USB device found, idVendor=0489, idProduct=e13a, bcdDevice= 1.00
[   32.879988] Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20250606201235
[   34.013527] Bluetooth: hci0: Failed to send wmt patch dwnld (-19)
[   34.013528] usb 1-6: USB disconnect, device number 5
[   34.013539] Bluetooth: hci0: Failed to set up firmware (-19)
[   34.015130] Bluetooth: hci0: Failed to read uhw reg(-19)

Subsequent boots (either driver, controller wedged from prior crash)

[   79.796202] Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20250606201235
[   91.214662] Bluetooth: hci0: Execution of wmt command timed out
[   91.214668] Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
[   91.214682] Bluetooth: hci0: failed to reset (-19)
[   91.214684] Bluetooth: hci0: Failed to set up firmware (-110)

The anomaly: HW/SW Version 0x00000000

Every attempt — clean cold boots, either driver, before and after the BIOS update — reads HW/SW Version: 0x00000000. A working e13a system in the mt76#927 thread reports HW 0x8a108a10 in its test-driver.sh output. So this controller answers enumeration and the build-time query but returns a zeroed hardware version before the patch download ever starts, then crashes off the bus when the transfer begins. Question for those who know the WMT protocol: is an all-zeros version read a known bad-state indicator (ROM bootloader wedged, module fault), and is there any deeper reset than a PSU drain / BIOS-flash settings reset short of a module reseat or RMA?

Verified / ruled out

• In-tree driver fails identically (see captures) — rules out the DKMS BT patches as the cause. Verified via /sys/module/btusb/srcversion in both configurations.
• BIOS updated to 2402 (latest, 2026-07) — flash included a settings reset to defaults, subsequently reconfigured. No change.
• Full system update (2026-08-15) — no change; kernel remained 7.1.8.
• Kernel support present: CONFIG_BT_HCIBTUSB_MTK=y; the in-tree 7.1.8 btmtk declares firmware: mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin in modinfo.
• Firmware present: /lib/firmware/mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin (688,341 bytes, from this package).
• USB autosuspend: disabled via modprobe.d + initramfs rebuild, confirmed N at runtime. No change.
• USB authorization: authorized_default=1.
• rfkill: no soft or hard block. Secure Boot: disabled.
• Module reload after failure does nothing — device is already off the bus.
• WiFi side of the same module works normally throughout (mt7925e, DKMS).

Packaging issues found along the way (bugs regardless of my BT failure)

1. Native-support detection never fires on CachyOS. The build conditional greps $KERNEL_BUILD/drivers/bluetooth/btmtk.h for MT6639, but the CachyOS headers package does not ship that file (/usr/lib/modules/7.1.8-1-cachyos/build/drivers/bluetooth/ contains only Kconfig). The grep fails, so the DKMS btusb/btmtk are built and installed even on kernel 7.1.8, where MT6639 support is already in-tree.
2. DKMS displaces the working in-tree driver. Because of (1), DKMS archives the stock btusb.ko.zst/btmtk.ko.zst to original_module/ and replaces them. On kernels ≥ 7.1 this swaps a current in-tree driver for out-of-tree modules patched against an older baseline. Suggest skipping the BT BUILT_MODULE_NAME entries when the target kernel version is ≥ 7.1 (version check rather than the header grep, since header packages may omit driver sources). My current workaround — stock BT modules copied back from original_module/, DKMS copies removed — is what produces the "Differences between built and installed modules" flag in the attached dkms status, and must be redone after every kernel upgrade until the conditional is fixed.

Neither packaging issue caused my failure (in-tree fails the same way), but both will affect other rolling-distro users on 7.1+.

Full diagnostics

bt-diag-20260817.txt

Attached: bt-diag-20260817.txt — full current-state capture (system/BIOS/package versions, dkms status, module provenance incl. srcversions, headers/original_module evidence for the packaging issues, enumeration, ruled-out settings, firmware listing, full dmesg, end state).

Happy to test patches or alternate firmware, capture btmon/usbmon traces of the disconnect, or run test-driver.sh on request.

[Sciruss]

Follow-up: same controller initializes fine under bare-metal Windows — hardware ruled out, and a possible root-cause signal

New differential result that changes the picture from my original report.

Test: full PSU power drain (the same #23-workaround precondition as every Linux failure capture in the original report), then cold-booted bare-metal Windows 11 on the same board (same BIOS 2402) and captured the BT state via PowerShell (full transcript attached: bt-diag-windows-20260817.txt).

Result: the controller initializes and runs normally under Windows — from the identical cold-controller state in which both Linux drivers crash it.

FriendlyName : MediaTek Bluetooth Adapter
Status       : OK
InstanceId   : USB\VID_0489&PID_E13A&MI_00\B&26E6BFF2&0&0000
Problem      : CM_PROB_NONE

DEVPKEY_Device_DriverVersion   1.1044.0.556
DEVPKEY_Device_DriverProvider  Mediatek Inc.
DEVPKEY_Device_DriverDate      9/16/2025
DEVPKEY_Device_DriverInfPath   oem30.inf   (mtkbtfilter.inf, Lower Filter: MTKBTFilterX64)

Kernel-PnP 410: Device USB\VID_0489&PID_E13A&MI_00\... was started. Service: BTHUSB

Full BT child stack (BTHLE, BTHBRB, RFCOMM, BTHPAN) enumerated and OK — and Kernel-PnP history shows this adapter has been working under Windows on this board since March 2026. So the hardware is functional and the MT6639 firmware download can succeed on this module; what it rejects is specifically the btusb/btmtk WMT sequence (which, per the original report, crashes it off the USB bus identically with both the in-tree 7.1 driver and this package's DKMS driver).

Possible root-cause signal: controller looks unprovisioned

Three independent observations now line up:

• Linux reads HW/SW Version: 0x00000000 on every attempt (a working e13a in mt76#927 reports HW 0x8a108a10)
• USB SerialNumber: 000000000 (visible under both Linux and Windows)
• Windows event log: "Windows cannot store Bluetooth authentication codes (link keys) on the local adapter" — plus recurring non-fatal BTHUSB "expected an HCI event with a certain size but did not receive it" errors (×4 per boot; same pattern on the post-power-drain cold boot as on warm boots)

This looks like a blank/unreadable OTP-eFuse provisioning region on my module. MediaTek's Windows filter driver tolerates that state and completes the firmware download; hypothesis: btmtk's WMT download path is parameterized by the HW/SW version read, and the zeroed value routes it into a sequence this controller answers by disconnecting.

Offer

If useful for anyone who knows the WMT download code, I can capture:

• usbmon trace of the Linux crash (in-tree or DKMS btusb, your pick), and
• USBPcap trace of the working Windows download by the MediaTek filter driver

so the two sequences can be diffed without needing my hardware. Also happy to test patches probing the version-0 path, or firmware extracted from the working Windows driver bundle (1.1044.0.556).

[jetm]

This is not the #23 failure mode, and the distinction decides everything else, so let me separate them first.

The one I have root-caused looks like this:

usb 1-6: device descriptor read/64, error -110
usb 1-6: device not accepting address 5, error -71
usb usb1-port6: unable to enumerate USB device

There, every ep0 control transfer fails, the device is never identified, btusb never binds, and no driver or quirk can reach it because usb_detect_quirks() only runs after hub_port_init() succeeds. That case turned out to be platform firmware timing and it cleared on an AGESA update plus a CMOS clear.

Yours is the opposite end. New USB device found, idVendor=0489, idProduct=e13a means the descriptor read completed, btusb bound, and hci0 came up. You get all the way into the firmware download before anything breaks. So the BIOS answer does not apply to you. You land in the #23 state afterwards as a consequence of the crash, which is why the two look related.

Now the part I can settle outright. HW/SW Version: 0x00000000 is not a read from your controller. It is a print of two fields out of the firmware file header. btmtk_setup_firmware_79xx() casts the loaded firmware to struct btmtk_patch_header and prints hwver and swver straight out of the file, from offsets 0x14 and 0x16. Here are the first 32 bytes of the 688341-byte BT_RAM_CODE_MT6639_2_1_hdr.bin this package ships, which is the same file you have:

000000  32 30 32 35 30 36 30 36 32 30 31 32 33 35 00 00  >20250606201235..<
000010  41 4c 50 53 00 00 00 00 ff ff ff ff 00 00 00 00  >ALPS............<

datetime is 20250606201235, which is exactly the build time your log printed. platform is ALPS. hwver and swver are both zero. Every MT6639 user running this firmware prints 0x00000000, and it carries no information about your silicon at all. The HW 0x8a108a10 you saw elsewhere is a different firmware binary with those fields populated, not a healthier module, so the eFuse provisioning theory loses its main leg.

The second half of that theory does not hold either. The download path is not parameterised by the version read; the MT6639 section filter keys on the chip ID, and your log proves dev_id already resolved to 0x6639. That is the only branch producing the mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin path, and the build time it printed matches that file byte for byte. So the zero-CHIPID workaround fired correctly, the right firmware loaded, and the section filter that skips the sections which hang the chip was active. The chip left anyway.

Which leaves the actual open question, and your timings are the most useful thing in the report. In-tree: version print at 33.712, disconnect at 35.016, so 1.30 s. DKMS: 32.879 to 34.013, so 1.13 s. Same point in the sequence both times. The -110 in the in-tree capture is downstream noise; the disconnect is the event, and the later timeout is just the WMT timer expiring against a device that was already gone. The real error in both captures is -19, ENODEV.

Two things would move this, and you have already offered both.

The usbmon trace is the one I want first:

modprobe -r btusb btmtk
modprobe usbmon
cat /sys/kernel/debug/usb/usbmon/1u > /tmp/bt-crash.mon &
modprobe btusb
sleep 20; kill %1

Your device is on bus 1 per usb 1-6, hence 1u. What that answers is whether the last acknowledged control transfer lands at the same section and offset on every attempt, which would point at one specific block in the firmware, and whether the detach is device-initiated or a port error on the host side.

The higher-value test is the firmware itself. The binary this package ships was extracted from an ASUS bundle dated 2025-07. The Windows stack you just proved works is driver 1.1044.0.556 dated 2025-09-16, which is later and almost certainly carries a different BT_RAM_CODE. Before we diff WMT sequences it is worth ruling out that we are simply feeding your controller an older patch than Windows does. If you can pull BT_RAM_CODE_MT6639* out of that bundle and drop it in as /lib/firmware/mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, that is a five-minute test with a clean answer either way. The USBPcap diff is worth doing after that, if newer firmware changes nothing.

On the packaging report, your conclusion is right and your mechanism is not, so let me correct the record. There is no btmtk.h or MT6639 grep anywhere in 2.13 or 2.14. I checked the PKGBUILD, dkms.conf, the Makefile and the install hook; BUILT_MODULE_NAME[0]="btusb" and [1]="btmtk" are unconditional, so the modules are built and installed on every kernel and there is no detection to fail. That gate did exist once and was removed in v2.12-1, because it was itself causing an install error. What you observed is the intended behaviour, and it is now the wrong behaviour, which is your second point and it stands: since 7.1 the only thing these modules add over in-tree is 0489:e156 for the HP EliteMini. I verified 0489:e13a is in both btusb_table and btmtk_mt6639_devs[] at v7.2, and 0489:e156 is in neither.

A blanket version gate is not quite enough, because it would strand the e156 users who need btmtk_mt6639_devs[] to match and cannot get that from a new_id write. So the direction is a kernel-version gate that skips Bluetooth by default on 7.1+, with an explicit opt-in for e156. I will track that separately and it does not depend on your case being solved.

[jetm]

Follow-up on the packaging half of your report, which is now done.

v2.14-6 stops building btusb and btmtk on kernel 7.1 and newer. Your reasoning was right: from 7.1 these modules add only 0489:e156, which is not upstream, while replacing the in-tree Bluetooth stack for every device on the system. That is a bad trade for everyone who does not own an e156.

The blanket version gate on its own would have stranded e156 owners, since that ID has to be matched by the driver's own btmtk_mt6639_devs[] table and a new_id write cannot supply it. So there is an opt-in, written to /etc/mediatek-mt7927-dkms.conf:

BUILD_BT=yes

followed by dkms autoinstall. Install and upgrade also warn if an e156 is actually plugged in and the opt-in is not set, so nobody loses Bluetooth without being told.

Worth recording why this took a second attempt. A gate like this existed once and was removed in v2.12-1, because it skipped the Bluetooth build while still naming btusb and btmtk in BUILT_MODULE_NAME. DKMS then went looking for modules that were never produced and the install failed (#85). The module arrays are now built conditionally, so anything not built is also not declared. Verified across eight kernel version strings and with a clean install on 7.2, where modinfo -n btusb correctly moves from updates/dkms/ to kernel/drivers/bluetooth/ and the controller still comes up.

That leaves your actual crash, which none of this touches and which stays open. The usbmon trace and the newer-firmware test from my previous comment are still the two things that would move it, and the firmware one is worth doing first now that v2.14-4 stopped shipping the WiFi blobs and left provenance clearer.

[Sciruss]

Resolved: root cause was a local udev rule, not the driver or firmware

This is deeply embarrassing, and I apologize for any time wasted on this effort. Closing the loop on this issue with full findings. TL;DR: this was never a driver bug. The controller was being killed by a leftover udev rule on my system that disabled its USB port during every boot. With that rule removed, Bluetooth works with the stock in-tree 7.1 btusb/btmtk and the distro-shipped June firmware. Details below in case the diagnostic trail is useful to others chasing similar "MT6639 drops off the bus" symptoms.

Environment

• ASUS ProArt X870E-Creator WiFi (rev 2), BIOS 2402
• BT: MT6639 function of the MT7927 combo, USB 0489:e13a
• CachyOS, kernel 7.1.8-1-cachyos, stock in-tree drivers (btusb srcversion 6510C8D2538FEDC20BE17F1, btmtk srcversion 755548AA70EFE4F298B5146)
• LUKS root with FIDO2 unlock (relevant: userspace start is delayed until unlock)

Root cause

A file I had created during USB device troubleshooting months ago — prior to finding out about the mediatek-mt7927-dkms package — and forgotten:

# /etc/udev/rules.d/99-disable-usb1-port6.rules
ACTION=="add", SUBSYSTEM=="usb", KERNEL=="1-0:1.0", RUN+="/bin/sh -c 'echo 1 > /sys/bus/usb/devices/usb1/1-0:1.0/usb1-port6/disable'"

It matches the root hub's own interface add event, so it fires on every udev coldplug replay and disables port 6 — exactly where the BT controller lives. Removing the rule (plus udevadm control --reload and an initramfs rebuild, since udev rules are copied into the image) fixed everything.

Why it looked exactly like a driver/firmware bug

Worth documenting because the symptoms were a near-perfect impostor:

1. "Firmware download crashes the controller": the rule fired seconds into userspace — often mid-wmt download — so the download appeared to knock the device off the bus. The kernel logs later proved the detach was driverless: in two captured boots the disconnect precedes btusb registration entirely, and a usbmon capture from the original crash session shows only an idle interrupt completion from the controller. A device-side vanish with no host traffic is exactly what an out-of-band port disable looks like.
2. The lockup state: after the port-disable hit the controller mid-operation, it entered a wedged state (descriptor read errors, "not responding to setup address") that only a full power drain cleared — matching the lockup behavior reported by others.
3. Death timing tracked the LUKS unlock, not power-on: disconnect always landed at unlock time + 3–6 s (fast FIDO2 unlock → ~21 s deaths; slow passphrase entry → 171 s; one stalled boot → 249 s), because coldplug replay runs right after switch-root. That formula held across nine observed deaths.
4. Everything else acquitted one variable at a time: identical behavior with stock vs DKMS btusb, with btusb never loaded at all, with USB runtime PM globally disabled (usbcore.autosuspend=-1), with rfkill states verified clear, with WiFi radio off, with mt7925e blacklisted entirely, and in rescue.target with no multi-user services running. The rule fired in every one of those configurations because udev coldplug runs in all of them.

Lesson learned (mine): when hunting a udev suspect, ls /etc/udev/rules.d/ for local overrides before pattern-grepping for specific mechanisms. The filename alone would have ended this weeks earlier.

Firmware findings (with the rule removed)

Tested both firmware builds from clean power-drained starts and warm reboots:

Firmware	SHA-256 (BT_RAM_CODE_MT6639_2_1_hdr.bin)	Cold start (post-drain)	Warm reboot
linux-firmware June build (Build Time 20250606201235)	669c5c99…ffbbc76	Works, setup ~19.4 s	Works, setup ~2.6 s
Sep build carved from Windows driver package (Build Time 20250926201235)	27c6a385…ce5079f	Works, setup ~19.4 s	Works, setup ~2.6 s

• Both builds work. The long first-init (~19.4 s) is a cold-start property, not a firmware property; warm re-inits are ~2.6 s with either.
• One real quirk found: switching firmware versions across a warm reboot failed. With the Sep build resident in the controller from the prior session, a warm reboot into the June file timed out at wmt func ctrl (-110) and wedged the chip until a power drain. Same-version warm reboots are fine (verified). If anyone swaps firmware builds on this chip: do it from a cold start.

Suggestion: newer firmware exists for upstreaming

MediaTek's Windows driver package (mtkbtfilter, driver 1.1044.0.556) ships a 2025-09-26 BT_RAM_CODE build for MT6639 inside the mtkbt.dat container (8-entry MTK container format; the Sep BT entry is 574,421 bytes), while linux-firmware still carries the 2025-06-06 build. Both work here, but the Sep build is three months newer and presumably carries fixes. I can share the container decode details / extraction offsets if useful for an upstream linux-firmware submission — redistribution licensing is obviously the maintainers' call.

Supporting captures (attached)

Each attachment proves one link in the chain:

• bt-rescue-152518.txt — controller death at ~21 s in rescue.target with only sysinit-level units running (unit list included): multi-user services acquitted, killer narrowed to the coldplug layer.
• bt-early-20260821-123738-dmesg.txt — disconnect at 21.8 s, before btusb registered at 25.1 s: the kernel log itself shows no BT driver ever touched the device that died. (A second driverless death at 55.9 s vs driver at 59.6 s is available on request.)
• bt-spont-20260821-113442-dmesg.txt — device enumerated at 2.6 s, untouched for four minutes, disconnected at 249.1 s with no BT driver loaded: a second, independent driverless death.
• bt-crash-105725-dev004-only.mon — the usbmon trace from the original crash session, filtered to the controller's own URBs: the entirety of host↔controller traffic in the window is one idle interrupt-in completion (16 zero bytes) and its resubmission. The raw bus-wide captures are withheld because usbmon on this bus also records HID interrupt reports from input devices (keystroke-bearing); see README-sanitization.txt in the archive for exactly what was filtered and why the raw captures add nothing beyond the dmesg sequencing anyway (they began seconds after the detach).
• bt-pmwatch-161436.log — power/control=on / runtime_status=active sampled every 0.5 s right up to the disconnect: the device vanished while runtime suspend was administratively impossible (runtime PM acquitted).
• bt-Junefw-162009.txt — the cross-version warm-transition failure: Sep-resident controller, warm reboot into the June file, wmt func ctrl timeout (-110), then the wedged state until a power drain.
• bt-working-Junefw-bootc-170345.txt — final state: stock in-tree driver, distro June firmware, no custom configuration, clean init and stable operation.

For this package

• Both open items from your last comment are answered above: the usbmon traces are attached (device-side detach, zero host traffic), and the newer-firmware test is done — both the June and Sep builds initialize and run correctly once the udev rule is removed, so the firmware was never the crash's cause either.
• v2.14-6 verified on this system (7.1.8-1-cachyos, warm reboot included): dkms status reports installed (Original modules exist) with no btusb/btmtk entries, modinfo -n btusb and modinfo -n btmtk both resolve to /lib/modules/7.1.8-1-cachyos/kernel/drivers/bluetooth/, nothing remains under updates/dkms/, and the controller comes up clean on the stock modules. The conditional gate works exactly as described.
• No driver changes needed for 0489:e13a — stock in-tree 7.1 handles it fine.

Thanks for the earlier corrections on the firmware-header version string and the packaging mechanics — both kept this investigation pointed the right way. From my side this can be closed.

mt6639-diagnostics.zip