Re: [PATCH] ALSA: ctxfi: Limit PTP to a single page

[Takashi Iwai <tiwai@suse.de>]

On Mon, 06 Apr 2026 12:32:43 +0200,
Harin Lee wrote:
> 
> On 4/6/26 5:50 PM, Takashi Iwai wrote:
> > On Mon, 06 Apr 2026 09:48:57 +0200,
> > Harin Lee wrote:
> >> 
> >> Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256
> >> playback streams, but the additional pages are not used by the card
> >> correctly. The CT20K2 hardware already has multiple VMEM_PTPAL
> >> registers, but using them separately would require refactoring the
> >> entire virtual memory allocation logic.
> >> 
> >> ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of
> >> CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When
> >> aggregate memory allocations exceed this limit, ct_vm_map() tries to
> >> access beyond the allocated space and causes a page fault:
> >> 
> >>    BUG: unable to handle page fault for address: ffffd4ae8a10a000
> >>    Oops: Oops: 0002 [#1] SMP PTI
> >>    RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]
> >>    Call Trace:
> >>    atc_pcm_playback_prepare+0x225/0x3b0
> >>    ct_pcm_playback_prepare+0x38/0x60
> >>    snd_pcm_do_prepare+0x2f/0x50
> >>    snd_pcm_action_single+0x36/0x90
> >>    snd_pcm_action_nonatomic+0xbf/0xd0
> >>    snd_pcm_ioctl+0x28/0x40
> >>    __x64_sys_ioctl+0x97/0xe0
> >>    do_syscall_64+0x81/0x610
> >>    entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >> 
> >> Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count
> >> remain unchanged.
> >> 
> >> Fixes: 391e69143d0a ("ALSA: ctxfi: Bump playback substreams to 256")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Harin Lee <me@harin.net>
> > 
> > Applied to for-next branch now, as it's no regression in 7.0, per se.
> > 
> > But, I wonder whether fixing in ctvmem.c would be relatively easy.
> > Isn't it only about ct_vm_map() and ct_get_ptp_phys()?
> > 
> > 
> > thanks,
> > 
> > Takashi
> 
> Hi Takashi.
> 
> info.vm_pgt_phys is set in atc_create_hw_devs().
> 
>   ...
>   /* Initialize card hardware. */
>   info.rsr = atc->rsr;
>   info.msr = atc->msr;
>   info.vm_pgt_phys = atc_get_ptp_phys(atc, 0);
>   err = hw->card_init(hw, &info);
>   if (err < 0)
>     return err;
>   ...
> 
> The atc_get_ptp_phys() function actually calls ct_get_ptp_phys().
> However, the index is 0, which only retrieves the address of the
> first PTP.
> 
> The hw_trn_init() for CT20K1 and CT20K2 writes the value of
> info.vm_pgt_phys to the hardware registers.
> 
>   ...
>   ptp_phys_low = (u32)info->vm_pgt_phys;
>   ptp_phys_high = upper_32_bits(info->vm_pgt_phys);
>   ...
> 
> CT20K1 implementation writes to the PTPALX and PTPAHX registers.
> CT20K2 implementation writes same single PTP address to all 64
> VMEM_PTPAL and VMEM_PTPAH registers.
> 
> We don't know if CT20K2 hardware actually supports independent PTPs,
> and refactoring would be risky. So I think the current approach is
> the safest for now.
> 
> This is what I've found so far.

Makes sense.  As already mentioned, your patch was applied.
If any further development to extend PTPs again, feel free to
resubmit.


thanks,

Takashi