Bug 260161 - usb enumeration stalls on a framework laptop
Summary: usb enumeration stalls on a framework laptop
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks: frameworklaptop
  Show dependency treegraph
 
Reported: 2021-12-01 22:25 UTC by Mark Johnston
Modified: 2024-04-21 16:56 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Johnston freebsd_committer freebsd_triage 2021-12-01 22:25:52 UTC
If I boot FreeBSD on a framework laptop, then do a soft reboot, mountroot pauses for a couple of minutes until USB enumeration times out.

During the first boot, ng_ubt is autoloaded and I see some errors:

ubt_ctrl_write_callback:909: control transfer failed: USB_ERR_TIMEOUT
ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout

On a subsequent boot, I get a hang, and the bluetooth device doesn't appear to get enumerated.  The next boot after that is fine, but then the BT device shows up again and the next boot after _that_ hangs.  So I guess we're not properly detaching the device.  I believe this is also causing problems with S3 resume.
Comment 1 Mark Johnston freebsd_committer freebsd_triage 2021-12-01 22:35:04 UTC
Setting devmatch_blocklist="ng_ubt" in rc.conf works around the problem.  This also lets the laptop resume reliably.  I'll try to dig into it further.
Comment 2 Mark Johnston freebsd_committer freebsd_triage 2021-12-02 17:17:49 UTC
ng_ubt_intel is missing the device ID for this particular adapter.  Adding it "fixes" the problem, but only because ng_ubt_intel then fails to probe the firmware version.  It seems that newer devices return firmware version info in a TLV array, and ng_ubt_intel (and iwmbtfw) doesn't know about it.

Dumping the returned TLV:

0000   00 10 04 10 04 40 00 11 04 10 04 40 00 12 04 00  |.....@.....@....|
0010   37 17 00 15 02 13 04 16 02 00 00 17 02 87 80 18  |7...............|
0020   02 32 00 1c 01 01 1d 02 28 13 1e 01 01 1f 04 26  |.2......(......&|
0030   00 00 00 27 01 00 28 01 01 29 01 00 2a 01 01 2b  |...'..(..)..*..+|
0040   01 01 2c 01 00 2d 03 01 0a 0e 2e 01 00 2f 01 01  |..,..-......./..|
0050   30 06 20 6f 9c 09 7b f4 31 01 00 00 00 00        |0. o..{.1.....  |

Image type TLV: 1c 01 01, and apparently a value of 0x01 there means that the device is in boot loader mode.

I'm not sure how much work it is to extend ng_ubt_intel to support this device.  I'll try adding TLV parsing support and see how it goes.

I wonder if ng_ubt_intel should match on all Intel bluetooth devices, otherwise we'll keep having to diagnose the same problem over and over again.
Comment 3 Vladimir Kondratyev freebsd_committer freebsd_triage 2021-12-02 21:07:41 UTC
According to Linux driver sources, this device have different firmware downloading scheme called BTUSB_INTEL_NEWGEN in pre v5.15 btusb.c which we do not support:

https://elixir.bootlin.com/linux/v5.14.21/source/drivers/bluetooth/btusb.c#L371
Comment 4 Jose Quinteiro 2021-12-04 18:16:06 UTC
Also experiencing this problem. I worked around it by adding hw.usb.no_boot_wait=1 to /boot/loader.conf.
Comment 5 commit-hook freebsd_committer freebsd_triage 2021-12-05 15:53:03 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=b25ba58adc04ca475df1e8125d2a16a07d68b49d

commit b25ba58adc04ca475df1e8125d2a16a07d68b49d
Author:     Mark Johnston <markj@FreeBSD.org>
AuthorDate: 2021-12-05 15:45:12 +0000
Commit:     Mark Johnston <markj@FreeBSD.org>
CommitDate: 2021-12-05 15:51:46 +0000

    ng_ubt: Avoid attaching to several newer Intel controllers

    Like other Intel controllers, these require firmware to be loaded, and
    generic ng_ubt attach causes them to lock up until a power cycle.
    However, their firmware interface for querying version info and loading
    operational firmware is different from that implemented by ng_ubt_intel
    and iwmbtfw, so they are not usable yet.  Just disable attach for now to
    avoid stalls during USB device enumeration.

    PR:             260161
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week

 sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c | 7 +++++++
 1 file changed, 7 insertions(+)
Comment 6 commit-hook freebsd_committer freebsd_triage 2021-12-13 13:29:04 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=d74c589ead91118a46370edc30f10e7d65ed2636

commit d74c589ead91118a46370edc30f10e7d65ed2636
Author:     Mark Johnston <markj@FreeBSD.org>
AuthorDate: 2021-12-05 15:45:12 +0000
Commit:     Mark Johnston <markj@FreeBSD.org>
CommitDate: 2021-12-13 13:26:19 +0000

    ng_ubt: Avoid attaching to several newer Intel controllers

    Like other Intel controllers, these require firmware to be loaded, and
    generic ng_ubt attach causes them to lock up until a power cycle.
    However, their firmware interface for querying version info and loading
    operational firmware is different from that implemented by ng_ubt_intel
    and iwmbtfw, so they are not usable yet.  Just disable attach for now to
    avoid stalls during USB device enumeration.

    PR:             260161
    Sponsored by:   The FreeBSD Foundation

    (cherry picked from commit b25ba58adc04ca475df1e8125d2a16a07d68b49d)

 sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c | 7 +++++++
 1 file changed, 7 insertions(+)
Comment 7 Stephen Hurd freebsd_committer freebsd_triage 2024-04-21 16:56:16 UTC
Work to support AX210 is in https://reviews.freebsd.org/D44861