Bug 267581 - ubt: 13.1-RELEASE fails to attach Intel Wireless-AC 3168 (USB: 0x8087:0x0aa7, ASRock X399 Taichi and others)
Summary: ubt: 13.1-RELEASE fails to attach Intel Wireless-AC 3168 (USB: 0x8087:0x0aa7,...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 13.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-wireless (Nobody)
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2022-11-05 23:06 UTC by Älven
Modified: 2022-12-23 23:02 UTC (History)
3 users (show)

See Also:


Attachments
Dmesg with working BT on 13.0 (19.17 KB, text/plain)
2022-11-12 22:13 UTC, Älven
no flags Details
Dmesg with non-working BT on 13.1 (19.20 KB, text/plain)
2022-11-12 22:14 UTC, Älven
no flags Details
iwmbtfw output on 13.0 (73 bytes, text/plain)
2022-11-22 15:46 UTC, Älven
no flags Details
iwmbtfw output on 13.1 with iwmbt-firmware installed (148 bytes, text/plain)
2022-11-22 15:47 UTC, Älven
no flags Details
iwmbtfw output on 13.1 without iwmbt-firmware installed (638 bytes, text/plain)
2022-11-22 15:48 UTC, Älven
no flags Details
iwmbtfw output on 13.1 when adapter is locked (fail) (332 bytes, text/plain)
2022-11-23 04:40 UTC, Älven
no flags Details
iwmbtfw output on 13.1 when adapter is unlocked (success) (15.51 KB, text/plain)
2022-11-23 04:41 UTC, Älven
no flags Details
iwmbtfw for fw_patch_num 0x34 (Works) (16.41 KB, text/plain)
2022-11-24 18:51 UTC, Älven
no flags Details
iwmbtfw for fw_patch_num 0x36 (Works) (16.10 KB, text/plain)
2022-11-24 18:51 UTC, Älven
no flags Details
iwmbtfw for fw_patch_num 0x41 (Fails) (15.84 KB, text/plain)
2022-11-24 18:53 UTC, Älven
no flags Details
iwmbtfw for fw_patch_num 0x42 (Fails) (16.07 KB, text/plain)
2022-11-24 18:53 UTC, Älven
no flags Details
iwmbtfw for fw_patch_num 0x43 (Fails) (16.07 KB, text/plain)
2022-11-24 18:54 UTC, Älven
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Älven 2022-11-05 23:06:11 UTC
ubt0 device fails to appear for Integrated Bluetooth module Intel Wireless-AC 3168 on ASRock X399 Taichi motherboard after upgrade FreeBSD from 13.0 to 13.1.
Similar to bug #237083.

On 13.0 (works):
ugen0.2: <vendor 0x8087 product 0x0aa7> at usbus0
ubt0 on uhub0
ubt0: <vendor 0x8087 product 0x0aa7, class 224/1, rev 2.00/0.01, addr 1> on usbus0
---
On 13.1 (fails):
ugen0.2: <vendor 0x8087 product 0x0aa7> at usbus0
---

# usbconfig ugen0.2 dump_device_desc
ugen0.2: <vendor 0x8087 product 0x0aa7> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x00e0  <Wireless controller>
  bDeviceSubClass = 0x0001 
  bDeviceProtocol = 0x0001 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x8087 
  idProduct = 0x0aa7 
  bcdDevice = 0x0001 
  iManufacturer = 0x0000  <no string>
  iProduct = 0x0000  <no string>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001
---

Some hint(?): on 13.1 iwmbtfw considers this device as Intel 7260 (by VID:PID) and tries to load it's firmware (ibt-hw-37.8.bseq)… May it be related to this?

I hope, as we already had this device successfully working in 13.0, with all needed firmware, we could make it work again in 13.1 too…
I'm ready to provide any needed information and assist with debugging this issue.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2022-11-06 22:00:22 UTC
@Reporter Could you include a full /var/run/dmesg.boot as an attachment please
Comment 2 Älven 2022-11-12 22:13:59 UTC
Created attachment 238040 [details]
Dmesg with working BT on 13.0
Comment 3 Älven 2022-11-12 22:14:31 UTC
Created attachment 238041 [details]
Dmesg with non-working BT on 13.1
Comment 4 Älven 2022-11-12 22:15:57 UTC
Thank you for your willingness to help me and take my regrets for so long delay with my response.
Comment 5 Tatsuki Makino 2022-11-18 03:51:14 UTC
Not the same as this device, but my ubt is also not attached immediately after reboot.
At that time, when the USB mouse is re-plugged, the ubt is also attached at the same time.
In my case it is 12.4-STABLE, but it has been that way since about 12.3.
Comment 6 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-11-21 18:28:32 UTC
> on 13.1 iwmbtfw considers this device as Intel 7260 (by VID:PID) and tries
> to load it's firmware (ibt-hw-37.8.bseq)… May it be related to this?

Yes, it is related. ibt-hw-37.8.bseq is a dummy firmware. Probably your device does not require any external firmware to work.

What is the output of the following command?:

iwmbtfw -I -d ugen0.2 -f /usr/local/share/iwmbt-firmware
Comment 7 Älven 2022-11-22 15:46:45 UTC
Created attachment 238249 [details]
iwmbtfw output on 13.0
Comment 8 Älven 2022-11-22 15:47:54 UTC
Created attachment 238250 [details]
iwmbtfw output on 13.1 with iwmbt-firmware installed
Comment 9 Älven 2022-11-22 15:48:45 UTC
Created attachment 238251 [details]
iwmbtfw output on 13.1 without iwmbt-firmware installed
Comment 10 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-11-22 22:00:34 UTC
Your iwmbt-firmware looks outdated. It misses ibt-hw-37.8.10-fw-22.50.19.14.f.bseq file which match your bt adapter.

Try to upgrade comms/iwmbt-firmware to latest ports version.
Comment 11 Älven 2022-11-23 04:40:46 UTC
Created attachment 238272 [details]
iwmbtfw output on 13.1 when adapter is locked (fail)
Comment 12 Älven 2022-11-23 04:41:44 UTC
Created attachment 238273 [details]
iwmbtfw output on 13.1 when adapter is unlocked (success)
Comment 13 Älven 2022-11-23 05:07:28 UTC
Thank you for the advice. I've checked my iwmbt-firmware version, it's the latest 20210315 (so should have it). I've just had tried to examine the behavior both with and without this installed (should it be useful).

Now have partial success, as I was able to at least have the firmware downloaded to the device after commenting out devd rule from /etc/devd/iwmbtfw.conf and powering off the machine.

But still no success with attaching ubt device node: adapter seems to lock itself somehow, so now I have 2 states:

1) Default. When devd rule is active something tries to start ng_ubt, fails with timeout and adapter locks. All download attempts fail.
2) Manual. When devd rule is inactive and nothing tries to start ng_ubt, so adapter seems unlocked. Manual firmware downloading succeeds. I may even do `usbconfig reset` and then successfully re-download the firmware. No locking happen, but still no ubt device node appear. When trying to start bluetooth service manually adapter locks so any following download attempts fail until power cycle.

Looks similar to #237083 ?
Some race condition during BT activation?
Should I try to comment out devd rule for automatic service bluetooth quietstart?

I may even try to apply some patches to test, would you advice me to do so…
Thanks in advance
Comment 14 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-11-23 23:10:12 UTC
(In reply to Andrey Korobkov from comment #13)

> No locking happen, but still no ubt device node appear.

ng_ubt is netgraph device, so no /dev/ubt0 should appear

Properly initialized bt device looks like:

# ngctl list
There are 9 total nodes:
  Name: ubt0            Type: ubt             ID: 00000001   Num hooks: 1
  Name: btsock_hci_raw  Type: btsock_hci_raw  ID: 00000002   Num hooks: 1
  Name: btsock_l2c_raw  Type: btsock_l2c_raw  ID: 00000003   Num hooks: 1
  Name: btsock_l2c      Type: btsock_l2c      ID: 00000004   Num hooks: 1
  Name: btsock_sco      Type: btsock_sco      ID: 00000005   Num hooks: 0
  Name: ubt0hci         Type: hci             ID: 00000007   Num hooks: 3
  Name: ubt0l2cap       Type: l2cap           ID: 0000000b   Num hooks: 3
  Name: wlan0           Type: ether           ID: 00000011   Num hooks: 0
  Name: ngctl11859      Type: socket          ID: 00000012   Num hooks: 0


> When trying to start bluetooth service manually adapter locks so any following download attempts fail until power cycle.

There was a report that fw_patch_num 0x41 may not work with our BT stack. Try to downgrade it to fw_patch_num 0x36. It can be downloaded directly from VCS:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq?id=6be4747ea1d731f661c5320acf3f1273a459d6da

It worth to test other firmwares newer than fw_patch_num 0x36. especially fw_patch_num 0x43 (latest). They can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq?showmsg=1
Comment 15 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-11-23 23:13:32 UTC
Don't forget to do power off after each try. It is required to remove old firmware at least on 8260/8265.
Comment 16 Älven 2022-11-24 18:48:46 UTC
YES!!! Thank you very much!! It really helped!
Exactly this: fw_patch_num 0x36 and only this.

fw_patch_num 0x34: Works
fw_patch_num 0x36: Works
fw_patch_num 0x41: Fails
fw_patch_num 0x42: Fails
fw_patch_num 0x43: Fails

Tested with full power-off, just as you've said.
May it be back-ported to 13.1, please?

Thanks once again!
Andrey
Comment 17 Älven 2022-11-24 18:51:15 UTC
Created attachment 238316 [details]
iwmbtfw for fw_patch_num 0x34 (Works)
Comment 18 Älven 2022-11-24 18:51:59 UTC
Created attachment 238317 [details]
iwmbtfw for fw_patch_num 0x36 (Works)
Comment 19 Älven 2022-11-24 18:53:00 UTC
Created attachment 238318 [details]
iwmbtfw for fw_patch_num 0x41 (Fails)
Comment 20 Älven 2022-11-24 18:53:39 UTC
Created attachment 238319 [details]
iwmbtfw for fw_patch_num 0x42 (Fails)
Comment 21 Älven 2022-11-24 18:54:27 UTC
Created attachment 238320 [details]
iwmbtfw for fw_patch_num 0x43 (Fails)
Comment 22 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-12-23 23:01:32 UTC
(In reply to Andrey Korobkov from comment #16)

> May it be back-ported to 13.1, please?

Done in https://cgit.freebsd.org/ports/commit/?id=7aa0e0a09cfad876f9a5a1ff70e31c9614e88fb6