As stated in Subject, for DPAA2 devices, the service_select_by_cpu() function in drivers/soc/fsl/dpio/dpio-service.c file, will cause calltrace when runs in preempt state and enable CONFIG_DEBUG_PREEMPT. The calltrace as following on LX2160ardb Rev2.0 board:
check_preemption_disabled: 2397 callbacks suppressed
BUG: using smp_processor_id() in preemptible  code: ifconfig/1938
caller is dpaa2_io_query_fq_count+0xd0/0x148
CPU: 6 PID: 1938 Comm: ifconfig Not tainted 5.2.50-yocto-standard #1
Hardware name: NXP Layerscape LX2160ARDB (DT)
This is because when the CONFIG_DEBUG_PREEMPT enabled, smp_processor_id will be set to debug_smp_processor_id(), which will check wether in preemptable environment of current task.
I want to query if this issue will be fixed in future or not?
Which version LSDK do you use?
What application is running on the target board to trigger this cause trace exception?
Would you please provide the whole console log on your target board?
Sorry for late reply.
Actually, this issue is not so complicated.
It is not triggered by applications, it is triggered by the enable of CONFIG_DEBUG_PREEMPT.
When the config CONFIG_DEBUG_PREEMPT enabled in kernel config, the calltrace will show as users to use the dpaa2 ethernet ports.
I find it in LSDK20.04, but I think it is a generic issue.
The followings give the relation of function trace.
-->service_select() (inline func)
-->service_select_by_cpu() (inline func)
-->smp_processor_id() ( == debug_smp_processor_id when CONFIG_DEBUG_PREEMPT enabled)
debug_smp_processor_id() will check wether in preemptable environment for current task, if it is preemptable,
the calltrace will show.
In LSDK 20.04, a separate branch “linux-4.19-rt” of Linux kernel is used for PREEMP RT, and PREEMP_RT patches have been applied in this kernel branch.