[BUG] btintel_pcie: Intel BE211 8086:a876 requests unavailable ibt-0190-01a1 firmware

[BUG] btintel_pcie: Intel BE211 8086:a876 requests unavailable ibt-0190-01a1 firmware

[Mark Gerlach]

Hello,

i am seeing a Bluetooth initialization failure with an Intel BE211
on a Lenovo ThinkPad E14 Gen 7 with Intel Lunar Lake
(Core Ultra 7 258V).

The PCI device is detected and btintel_pcie binds to it:

00:14.7 Bluetooth [0d11]: Intel Corporation Device [8086] (rev 10)
Subsystem: Intel Corporation Device [8086:0011]
Kernel driver in use: btintel_pcie
Kernel modules: btintel_pcie

During initialization, the driver requests:

intel/ibt-0190-01a1-iml.sfi

Loading the firmware then fails with ENOENT (-2):

Bluetooth: hci0: Failed to load Intel firmware file
intel/ibt-0190-01a1-iml.sfi (-2)

As a result, the controller does not complete initialization and

bluetoothctl list

shows no controller.

The issue is reproducible with:

Fedora 44 x86_64
kernel 7.1.9-200.fc44.x86_64
kernel 7.1.12-200.fc44.x86_64
linux-firmware-20260810-1.fc44.noarch

Hardware details:

Laptop: Lenovo ThinkPad E14 Gen 7
CPU: Intel Core Ultra 7 258V (Lunar Lake)
WLAN/BT: Intel BE211
PCI ID: 8086rev 10
Subsystem ID: 8086:0011

Wi-Fi on the same BE211 works correctly.

The installed linux-firmware package contains related Intel Bluetooth
firmware variants, including:

ibt-0190-0291-*
ibt-1190-01a1-*
ibt-00a0-01a1-*

but no:

ibt-0190-01a1-*

For diagnostic purposes, I temporarily created aliases from the
existing ibt-0190-0291 firmware files to the requested 0190-01a1
filenames.

With these aliases, the firmware files were found and downloaded, but
initialization then failed later with:

Bluetooth: hci0: Timeout (3000 ms) on alive interrupt,
alive context: intel_reset1
Bluetooth: hci0: Failed to send Intel Reset command
Bluetooth: hci0: Intel Soft Reset failed (-62)

I removed the aliases afterwards.

This suggests that the existing 0190-0291 firmware cannot simply be
used for this controller.

The same BE211 hardware works correctly under Windows using the HP OEM
driver package rather than Intel's generic driver package.

I initially reported this to Fedora to determine whether this might be
a Fedora packaging issue or an incorrect firmware selection by
btintel_pcie.

The Fedora developer has now confirmed that the issue is missing
firmware upstream and replied:

"The issue is missing firmware, we consume what ever the vendor pushes
upstream, it's not yet upstream, there's not much we can do about that
until the vendor bothers to send it upstream."

This therefore appears to require the corresponding Intel firmware to
be published upstream.

Could you please confirm that ibt-0190-01a1 is the expected firmware
variant for this BE211 / 8086/ subsystem 8086:0011 controller?

If so, could this be forwarded to the appropriate Intel firmware
maintainer, or is there an Intel contact or issue tracker where the
missing ibt-0190-01a1 firmware should be requested?

The Fedora bug report contains the full journal and lspci output:

https://bugzilla.redhat.com/show_bug.cgi?id=2527721 
<https://bugzilla.redhat.com/show_bug.cgi?id=2527721>

There is also kernel Bug 221481 concerning btintel_pcie on Lunar Lake.
That report concerns a separate suspend issue. I previously added
information there about this controller's firmware loading failure.

Thanks,
Mark

Re: [BUG] btintel_pcie: Intel BE211 8086:a876 requests unavailable ibt-0190-01a1 firmware

[Sergey Lebedev]

Mark,

The driver is asking for the right file. That file has never existed in
linux-firmware, so no update and no other distribution will produce it.

The name is built in btintel.c from two hardware fields, and the source
says which:

  /* ibt-<cnvi_top type+cnvi_top step>-<cnvr_top type+cnvr_top step-fw_id> */
  format = "intel/ibt-%04x-%04x-iml.%s";
  snprintf(fw_name, len, format, cnvi, cnvr, suffix);

Both paths that can produce an "-iml" name build it the same way. First
field is cnvi_top, the connectivity part in the SoC; second is cnvr_top,
the radio. So yours is cnvi 0190 with cnvr 01a1, and the request matches
your silicon.

I have the same SoC side. Surface Pro 11 (Intel), Lunar Lake, and the
8086:a876 rev 10 you report - but subsystem 8086:000e where yours is
8086:0011. It works here, and loads:

  Found device firmware: intel/ibt-0190-0291-iml.sfi
  Found device firmware: intel/ibt-0190-0291-pci.sfi
  Found Intel DDC parameters: intel/ibt-0190-0291-pci.ddc

Same 0190, and 0291 against your 01a1. Two machines on the same
connectivity part carrying different radios.

I checked linux-firmware.git itself rather than any distribution package,
since package version strings do not compare across distributions - a
frozen LTS string can carry backported content and say nothing about it.
The tree listing and WHENCE agree on what is published:

  ibt-0190-*   with 0041 and 0291
  *-01a1-*     with 00a0 and 1190

And a path history query - run with two known-present files as controls,
because an empty result from a broken query looks identical to an empty
result from a true absence - returns 11 commits for ibt-0190-0291-pci.sfi,
6 for ibt-1190-01a1-pci.sfi, and none at all for ibt-0190-01a1-pci.sfi.
The file has never been in the tree, not merely dropped from it.

If it helps in asking Intel, their commits name each pair as a core:

  0190-0291   BlazarI          (this machine)
  0190-0041   BlazarIGfP
  1190-01a1   BlazarIW
  00a0-01a1   Scorpius

There is no commit for 0190-01a1 under any name.

One thing not to do: rename a neighbouring blob. ibt-1190-01a1 is your
radio against a different connectivity part and ibt-0190-0291 the reverse,
and the driver will not stop you - it validates the CSS header version and
the SBE type against hw_variant, but nothing checks that the image belongs
to your radio, so a renamed file is handed to the controller rather than
rejected.

So this is a firmware publication request and not a kernel bug, and it
needs Intel. I have put Kiran and Chandrashekar on Cc, who work on
btintel_pcie and are better placed than I am to say whether 0190-01a1 is
coming, or whether the module in your machine is not yet enabled on Linux.

Your report: 72098331-fa7c-443c-8b56-7671f9d711f2@mailbox.org

Sergey