Linux bluetooth development
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-bluetooth@vger.kernel.org
Subject: [Bug 221720] New: Outdated Intel BT firmware ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq (patch 0x27) breaks all HFP/SCO audio — Windows driver ships working patch 0x2b
Date: Sat, 04 Jul 2026 15:19:39 +0000	[thread overview]
Message-ID: <bug-221720-62941@https.bugzilla.kernel.org/> (raw)

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

               URL: https://lore.kernel.org/linux-bluetooth/11453504-20db-
                    45d0-87e0-ce5582dcbab4@fluid8.de/T/#u
            Bug ID: 221720
           Summary: Outdated Intel BT firmware
                    ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq (patch 0x27) breaks
                    all HFP/SCO audio — Windows driver ships working patch
                    0x2b
           Product: Drivers
           Version: 2.5
    Kernel Version: 7.0.0
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: blocking
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: dev@fluid8.de
        Regression: No

## Summary

The legacy Intel Bluetooth firmware `intel/ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq`
in linux-firmware carries RAM patch **0x27 (39)** and has not been updated
since 2014. With this patch level, the HFP/HSP microphone path (SCO/eSCO,
CVSD) of the affected controllers is completely unusable: the decoded audio
is a constant full-scale buzz unrelated to microphone input, and the kernel
log floods with `Bluetooth: hci0: corrupted SCO packet`.

Intel's own Windows driver package for the same hardware ships RAM patch
**0x2b (43)** for the same firmware variant. Loading that patch on Linux
(extracted from the Windows driver, converted 1:1 — the embedded blob is
already in bseq format) **fully fixes HFP audio**: clean, intelligible
microphone audio and zero corrupted SCO packets, on both eSCO and basic SCO.

Since firmware submissions must come from the vendor, this is a request for
Intel to submit their final patch level for the ibt-hw-37.7.x legacy
(Wilkins Peak) firmware files to linux-firmware.

## Hardware

- Intel Dual Band Wireless-AC 3160 combo card
- BT controller: USB `8087:07dc`, "Legacy ROM 2.5 revision 0.0 build 1 week 45
2013"
- Loaded firmware file: `intel/ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq`
- Distro/kernel: Ubuntu, kernel 7.0.0-27-generic, linux-firmware 20260319
- Headset used for testing: Jabra Evolve 65 (BT), PipeWire/WirePlumber 0.5.x,
native HFP backend, CVSD

## Symptom with current linux-firmware (patch 0x27)

- HFP microphone capture is a constant full-scale roar: peak = 32768,
   RMS ≈ 29400, RMS envelope flat at maximum for the whole capture,
   completely uncorrelated with speech. (Typical CVSD delta-decoder railing
   on a desynchronized/garbage bitstream.)
- Kernel log: thousands of `corrupted SCO packet` messages per 10 s capture
   (btusb SCO reassembly desyncs on the controller's bursty/corrupted
   eSCO-over-USB stream).
- Independent of: eSCO vs. basic SCO (tested via forced HV3), xHCI vs. EHCI
   routing, alt-setting, autosuspend. A2DP is unaffected.
- Long-standing reports of the same symptom on this chip family, e.g.
   Ubuntu bug #1310558 (2014, fixed back then by a firmware patch update),
   Linux Mint discussion #662 (2024, kernel 6.8, unresolved).

## Fix: patch 0x2b from Intel's Windows driver

Source (publicly available from Intel): `BT_21.10.1_64_Win8.1.exe`.
The package embeds the RAM patch for each firmware variant inside the
driver binaries, already in bseq format (identical HCI cmd/event record
stream as consumed by btintel's legacy patching):

- Header for fw variant 1.0.1.2d in linux-firmware:
   `018efc0a 00010008 0004012d 0d27` → patch **0x27**
- Header in the Windows driver (identical blob in all driver builds
   20.91.3.1 … 20.100.5.1 contained in the package):
   `018efc0a 00010008 0004012d 0d2b` → patch **0x2b**
- Extracted blob: 22627 bytes, 191 well-formed cmd/event records,
   same first command (0xfc8e) and same final command (0xfc60) as the
   linux-firmware file; sha256 `7a0ca9155e0ec489…` (full hash on request)

Result after installing this blob as
`/lib/firmware/intel/ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq` and cold-booting
(the controller keeps the old RAM patch across warm reloads;
`Intel BT fw patch 0x2b completed & activated` confirmed in dmesg):

- eSCO (stock kernel, CVSD): clean intelligible microphone audio,
   0% clipping, speech-correlated RMS envelope, **0 corrupted SCO packets**
   during 15 s capture (previously ~2600 per 10 s). Some later runs show a
   small residue (~18 per 15 s) with no audible impact.
- Same result with basic SCO.
- Bonus: the USB autosuspend instability we saw with 0x27 (controller
   drops off the bus under SCO load) is also gone with 0x2b — verified
   with default runtime-PM settings including a real suspend/resume cycle.

## Comparison of all 37.7.10 variants

| linux-firmware file | patch in linux-firmware | patch in Windows driver |
|---|---|---|
| fw-1.0.1.2d.d.bseq | 0x27 | **0x2b** |
| fw-1.80.1.2d.d.bseq | 0x2a | **0x2b** |
| fw-1.0.2.3.d.bseq | 0x56 | 0x57 |
| fw-1.80.2.3.d.bseq | 0x57 | 0x57 (current) |

The `.2d` variants are the outdated ones; `1.80.2.3` already matches the
final Windows level.

## Request

Could Intel please submit the final patch level (0x2b) for the
`ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq` (and `fw-1.80.1.2d.d.bseq`) files —
and generally the last released patch levels for the 37.7.x legacy family —
to linux-firmware? The blobs already exist in bseq format inside Intel's
Windows driver packages; only a licensed re-release is needed.

I can provide full captures (WAV), btmon/usbmon traces, exact extraction
offsets, and full hashes on request.

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

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

                 reply	other threads:[~2026-07-04 15:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-221720-62941@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox