Re: Creative X-Fi hw20k2 (SB0880) that appeared in kernel 6.12.85

Hi Takashi,

Thank you for the pointer to 7.0.x. I reviewed the recent ctxfi commits in
linux-7.0.y and believe commit e9418da50d9e ("ALSA: ctxfi: Limit PTP to a
single page") is the fix for my issue. Here is why I believe this matches
my symptoms:

1. My system is AMD64, which is exactly the architecture where the page
fault occurs — a single PTP page covers 512 PTEs (2MB) on AMD64, and
aggregate mmap allocations from PulseAudio exceed this limit.

2. aplay -l shows 256 subdevices on my X-Fi (card 0, device 0, Subdevices:
255/256), confirming that commit 391e69143d0a ("Bump playback substreams to
256") is active and CT_PTP_NUM was set to 4 on my system.

3. PulseAudio opens the device in mmap+timer mode (device.access_mode =
"mmap+timer"). When it does so, atc_pcm_playback_prepare() -> ct_vm_map()
is called, which accesses beyond vm->ptp[0].area when allocations exceed
512 PTEs. This produces no oops visible to userspace — PA silently gets a
bad mapping and audio transfers go nowhere.

4. Direct ALSA access via speaker-test (which uses read/write mode, not
mmap) works correctly on all 8 analog channels, confirming the hardware and
driver are otherwise functional.

5. Forcing PulseAudio to close and reopen the PCM device via pactl
suspend-sink / resume-sink reliably restores audio each time, consistent
with the allocation starting fresh within the single-page boundary on a
clean open.

I also note commit 95b1ee8442ca ("ALSA: ctxfi: Add fallback to default RSR
for S/PDIF", May 7) is also present in 7.0.y.

My testing environment is Home Assistant OS on dedicated x86-64 hardware,
which limits my ability to test arbitrary kernel builds without significant
disruption. I can test once the fix is backported to 6.12.x stable and
picked up by a Home Assistant OS release. Please let me know if there is
any additional diagnostic information I can provide from the running system
in the meantime.

Best regards,

Cliff

On Tue, Jun 2, 2026 at 6:38 AM Takashi Iwai <[email protected]> wrote:

> On Tue, 02 Jun 2026 13:32:42 +0200,
> Cliff Brady wrote:
> >
> >
> > Hi Takashi,
> >
> > I'm writing to report a regression on the Creative X-Fi hw20k2 (SB0880)
> that
> > appeared in kernel 6.12.85, and which I believe is related to commit
> > b045ab3dff97 ("ALSA: ctxfi: Fix missing SPDIFI1 index handling").
> >
> > Hardware:
> >   Card: Creative X-Fi 20K2, model SB0880 (PCI ID 1102:000b)
> >   Driver: snd_ctxfi
> >   Kernel: 6.12.85 (Home Assistant OS 17.3, generic x86-64)
> >
> > Symptom:
> > After upgrading from HAOS 17.2 (kernel 6.12.77) to HAOS 17.3 (kernel
> 6.12.85),
> > the X-Fi analog outputs produce no audio when accessed via PulseAudio.
> HAOS
> > 17.1 (kernel 6.12.67) X-Fi analog outputs also  successfully produced
> audio
> > when accessed via PulseAudio  The PA sink reports RUNNING and all ALSA
> mixer
> > controls are at full volume and unmuted, but no audio is heard from any
> analog
> > output channel (front, rear, side, center/LFE).
> >
> > Diagnosis:
> > PA opens the device with device.access_mode = "mmap+timer". Direct ALSA
> access
> > via speaker-test bypassing PA produces audio correctly on all channels.
> > Forcing PA to close and reopen the PCM device via pactl suspend-sink /
> > resume-sink restores audio, suggesting the mmap buffer handshake between
> PA
> > and the ctxfi driver is failing silently on device open.
> >
> > The issue is reproducible every time PA opens the device fresh (e.g.
> after pa
> > restart or sink resume from suspended state following idle timeout). The
> > suspend/resume workaround reliably restores audio each time.
> >
> > Hypothesis:
> > The out-of-bounds array access fixed by commit b045ab3dff97 in
> > daio_device_index() for hw20k2 may have been inadvertently masking a
> > pre-existing deficiency in the ctxfi mmap implementation. With the fix in
> > place, mmap+timer mode is negotiated successfully at the PA/kernel
> interface
> > but audio transfers silently fail. A possible fix would be to set
> > SNDRV_PCM_INFO_NO_MMAP in the hw20k2 PCM capabilities, forcing PA to
> fall back
> > to read/write mode which works correctly.
> >
> > Kernel was working: 6.12.77
> > Kernel regression introduced: 6.12.85
> >
> > I am happy to test any patch or provide further diagnostics.
>
> Could you check the latest 7.0.x kernel?  There are a few more fixes
> for ctxfi recently.
>
>
> Takashi
>