[Bug 221660] New: btmtk (MT7921K / RZ608): BR/EDR outgoing connection always fails with Page Timeout (0x04); scan/receive works, same device pairs fine on Windows

[Bug 221660] New: btmtk (MT7921K / RZ608): BR/EDR outgoing connection always fails with Page Timeout (0x04); scan/receive works, same device pairs fine on Windows

[bugzilla-daemon]

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

            Bug ID: 221660
           Summary: btmtk (MT7921K / RZ608): BR/EDR outgoing connection
                    always fails with Page Timeout (0x04); scan/receive
                    works, same device pairs fine on Windows
           Product: Drivers
           Version: 2.5
    Kernel Version: 7.0.12-arch1-1
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: bynxmusic@gmail.com
        Regression: No

Created attachment 310333
  --> https://bugzilla.kernel.org/attachment.cgi?id=310333&action=edit
btmon HCI trace (binary + decoded) of the Page Timeout + system info

btmtk (MT7921K / RZ608): every BR/EDR outgoing connection fails with Page
Timeout (0x04). Scan/receive works, and the same device pairs fine on Windows.

HARDWARE
  WiFi+BT combo: MediaTek MT7921K (RZ608) Wi-Fi 6E, PCI 14c3:0608, driver
mt7921e
  Bluetooth function: USB 0e8d:0608 (MediaTek Inc. Wireless_Device), btusb +
btmtk
  Motherboard onboard radio, AMD desktop platform

SOFTWARE
  Kernel: 7.0.12-arch1-1 (x86_64), Arch Linux (rolling)
  linux-firmware: 20260519-1 ; linux-firmware-mediatek: 20260519-1
  BlueZ: 5.86
  BT controller firmware: HW/SW Version 0x008a008a, Build Time 20260224111243
  BT firmware blob loads OK: mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin

WHAT WORKS
  Controller initializes cleanly every boot ("hci0: Device setup in ~160000
  usecs", AOSP extensions v1.00). Inquiry/scan works: remote devices (a
  Skullcandy Crusher Evo headset and a Samsung TV) are reliably discovered with
  RSSI, so the RX path is fine.

THE BUG
  Every outgoing connection (page) to any BR/EDR device times out. HCI Create
  Connection is issued and accepted (Command Status: Success), but roughly 7.7
s
  later the controller returns Connect Complete with Status: Page Timeout
(0x04).
  BlueZ reports org.bluez.Error.ConnectionAttemptFailed. The remote device
never
  registers a connection. The same headset on the same PC pairs and works
  perfectly under Windows, so this is not dead hardware or a peripheral issue;
  it is the btmtk/MT7921K outgoing-connection path on Linux.

KEY HCI TRACE (btmon), captured with the WiFi driver (mt7921e) UNLOADED, i.e.
WiFi/BT coexistence ruled out:

  < HCI Command: Create Connection (0x01|0x0005) plen 13   #9  [hci0] 14.208614
          Address: 88:08:94:13:8F:94 (Skullcandy)
          Packet type: 0xcc18 (DM1/DH1/DM3/DH3 ...)
  > HCI Event: Command Status (0x0f) plen 4               #10 [hci0] 14.209664
        Create Connection (0x01|0x0005) ncmd 1
          Status: Success (0x00)
  > HCI Event: Connect Complete (0x03) plen 11            #11 [hci0] 21.899975
          Status: Page Timeout (0x04)
          Handle: 0
          Address: 88:08:94:13:8F:94 (Skullcandy)
          Link type: ACL (0x01)

  Also seen intermittently in dmesg during attempts:
  Bluetooth: hci0: ACL packet for unknown connection handle 3837

STEPS TO REPRODUCE
  1. Boot with MT7921K onboard Bluetooth.
  2. Put any BR/EDR device (e.g. a freshly factory-reset BT headset) in pairing
     mode.
  3. In bluetoothctl: scan on (device IS discovered), then pair <MAC>.
  4. Pairing fails with org.bluez.Error.ConnectionAttemptFailed; btmon shows
     Connect Complete: Page Timeout (0x04).

EXPECTED vs ACTUAL
  Expected: Create Connection succeeds and pairing/bonding proceeds (as on
  Windows).
  Actual: every Create Connection ends in Page Timeout; no outgoing connection
  ever completes.

ALREADY RULED OUT
  - USB autosuspend: disabled via options btusb enable_autosuspend=0 (confirmed
    power/control=on). No change.
  - WiFi/BT coexistence: Page Timeout persists even with mt7921e fully unloaded
    (modprobe -r mt7921e); the trace above is from that state. Also tested with
    rfkill block wifi. No change.
  - LE vs BR/EDR bearer: tested with and without Experimental, and with
    ControllerMode = bredr. No change.
  - Stale/half state: reproduced after a fresh cold boot (controller not
wedged).
  - Remote device: Crusher Evo factory-reset; nothing else paired to it
    (phone/TV BT off); works on Windows.

ATTACHMENTS
  - bt-hci-trace.btsnoop: full binary btmon capture of one failed pairing.
  - bt-bugreport.txt: full system diagnostic bundle (versions, lspci/lsusb,
dmesg).

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

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

Re: [Bug 221660] New: btmtk (MT7921K / RZ608): BR/EDR outgoing connection always fails with Page Timeout (0x04); scan/receive works, same device pairs fine on Windows

[Paul Menzel]

[Cc: +Mediatek]

Am 17.06.26 um 00:39 schrieb bugzilla-daemon@kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=221660
> 
>              Bug ID: 221660
>             Summary: btmtk (MT7921K / RZ608): BR/EDR outgoing connection
>                      always fails with Page Timeout (0x04); scan/receive
>                      works, same device pairs fine on Windows
>             Product: Drivers
>             Version: 2.5
>      Kernel Version: 7.0.12-arch1-1
>            Hardware: AMD
>                  OS: Linux
>              Status: NEW
>            Severity: normal
>            Priority: P3
>           Component: Bluetooth
>            Assignee: linux-bluetooth@vger.kernel.org
>            Reporter: bynxmusic@gmail.com
>          Regression: No
> 
> Created attachment 310333
>    --> https://bugzilla.kernel.org/attachment.cgi?id=310333&action=edit
> btmon HCI trace (binary + decoded) of the Page Timeout + system info
> 
> btmtk (MT7921K / RZ608): every BR/EDR outgoing connection fails with Page
> Timeout (0x04). Scan/receive works, and the same device pairs fine on Windows.
> 
> HARDWARE
>    WiFi+BT combo: MediaTek MT7921K (RZ608) Wi-Fi 6E, PCI 14c3:0608, driver mt7921e
>    Bluetooth function: USB 0e8d:0608 (MediaTek Inc. Wireless_Device), btusb + btmtk
>    Motherboard onboard radio, AMD desktop platform
> 
> SOFTWARE
>    Kernel: 7.0.12-arch1-1 (x86_64), Arch Linux (rolling)
>    linux-firmware: 20260519-1 ; linux-firmware-mediatek: 20260519-1
>    BlueZ: 5.86
>    BT controller firmware: HW/SW Version 0x008a008a, Build Time 20260224111243
>    BT firmware blob loads OK: mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
> 
> WHAT WORKS
>    Controller initializes cleanly every boot ("hci0: Device setup in ~160000
>    usecs", AOSP extensions v1.00). Inquiry/scan works: remote devices (a
>    Skullcandy Crusher Evo headset and a Samsung TV) are reliably discovered with
>    RSSI, so the RX path is fine.
> 
> THE BUG
>    Every outgoing connection (page) to any BR/EDR device times out. HCI Create
>    Connection is issued and accepted (Command Status: Success), but roughly 7.7
> s
>    later the controller returns Connect Complete with Status: Page Timeout (0x04).
>    BlueZ reports org.bluez.Error.ConnectionAttemptFailed. The remote device never
>    registers a connection. The same headset on the same PC pairs and works
>    perfectly under Windows, so this is not dead hardware or a peripheral issue;
>    it is the btmtk/MT7921K outgoing-connection path on Linux.
> 
> KEY HCI TRACE (btmon), captured with the WiFi driver (mt7921e) UNLOADED, i.e.
> WiFi/BT coexistence ruled out:
> 
>    < HCI Command: Create Connection (0x01|0x0005) plen 13   #9  [hci0] 14.208614
>            Address: 88:08:94:13:8F:94 (Skullcandy)
>            Packet type: 0xcc18 (DM1/DH1/DM3/DH3 ...)
>    > HCI Event: Command Status (0x0f) plen 4               #10 [hci0] 14.209664
>          Create Connection (0x01|0x0005) ncmd 1
>            Status: Success (0x00)
>    > HCI Event: Connect Complete (0x03) plen 11            #11 [hci0] 21.899975
>            Status: Page Timeout (0x04)
>            Handle: 0
>            Address: 88:08:94:13:8F:94 (Skullcandy)
>            Link type: ACL (0x01)
> 
>    Also seen intermittently in dmesg during attempts:
>    Bluetooth: hci0: ACL packet for unknown connection handle 3837
> 
> STEPS TO REPRODUCE
>    1. Boot with MT7921K onboard Bluetooth.
>    2. Put any BR/EDR device (e.g. a freshly factory-reset BT headset) in pairing
>       mode.
>    3. In bluetoothctl: scan on (device IS discovered), then pair <MAC>.
>    4. Pairing fails with org.bluez.Error.ConnectionAttemptFailed; btmon shows
>       Connect Complete: Page Timeout (0x04).
> 
> EXPECTED vs ACTUAL
>    Expected: Create Connection succeeds and pairing/bonding proceeds (as on
>    Windows).
>    Actual: every Create Connection ends in Page Timeout; no outgoing connection
>    ever completes.
> 
> ALREADY RULED OUT
>    - USB autosuspend: disabled via options btusb enable_autosuspend=0 (confirmed
>      power/control=on). No change.
>    - WiFi/BT coexistence: Page Timeout persists even with mt7921e fully unloaded
>      (modprobe -r mt7921e); the trace above is from that state. Also tested with
>      rfkill block wifi. No change.
>    - LE vs BR/EDR bearer: tested with and without Experimental, and with
>      ControllerMode = bredr. No change.
>    - Stale/half state: reproduced after a fresh cold boot (controller not
> wedged).
>    - Remote device: Crusher Evo factory-reset; nothing else paired to it
>      (phone/TV BT off); works on Windows.
> 
> ATTACHMENTS
>    - bt-hci-trace.btsnoop: full binary btmon capture of one failed pairing.
>    - bt-bugreport.txt: full system diagnostic bundle (versions, lspci/lsusb, dmesg).

[Bug 221660] btmtk (MT7921K / RZ608): BR/EDR outgoing connection always fails with Page Timeout (0x04); scan/receive works, same device pairs fine on Windows

[bugzilla-daemon]

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

The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |regressions@leemhuis.info

--- Comment #1 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
Did this work with earlier kernel versions? Is 7.1 affected (7.0 is likely EOL
in week anyway).

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

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