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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.