RE: [Intel-wired-lan] [PATCH iwl-next v3] libie: log more info when virtchnl fails

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf
> Of Li Li via Intel-wired-lan
> Sent: Wednesday, April 29, 2026 10:41 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@xxxxxxxxx>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@xxxxxxxxx>; David S. Miller
> <davem@xxxxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Eric Dumazet
> <edumazet@xxxxxxxxxx>; intel-wired-lan@xxxxxxxxxxxxxxxx
> Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; David
> Decotigny <decot@xxxxxxxxxx>; Singhai, Anjali
> <anjali.singhai@xxxxxxxxx>; Samudrala, Sridhar
> <sridhar.samudrala@xxxxxxxxx>; Brian Vazquez <brianvv@xxxxxxxxxx>; Li
> Li <boolli@xxxxxxxxxx>; Tantilov, Emil S <emil.s.tantilov@xxxxxxxxx>
> Subject: [Intel-wired-lan] [PATCH iwl-next v3] libie: log more info
> when virtchnl fails
> 
> Virtchnl failures can be hard to debug without logs. Logging the
> details of virtchnl transactions can be useful for debugging virtchnl-
> related issues.
> 
> Tested: Built & booted on a test machine and synthetically produced a
> virtual failure to produce the following log:
> 
> idpf 0000:01:00.0: Non-zero virtchnl ret val (msg op: 1, ret val: 6,
> data_len: 8); xn id: 0, cookie: 0
> idpf 0000:01:00.0: Transaction failed (op 1, xn state:
> 3, id: 0, cookie: 0, size: 8)
> 
> Signed-off-by: Li Li <boolli@xxxxxxxxxx>
> ---
> v3:
>  - Use dev_err_ratelimited in both logs.
>  - Move log placement to after virtchnl field validation.
>  - Remove redundant op/cookie fields since they were validated.
> v2:
>  - Use dev_warn_ratelimited instead of dev_notice_ratelimited based on
>    reviewer feedback.
> 
>  drivers/net/ethernet/intel/libie/controlq.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/libie/controlq.c
> b/drivers/net/ethernet/intel/libie/controlq.c
> index ebc05355e39d..ceca8a076d79 100644
> --- a/drivers/net/ethernet/intel/libie/controlq.c
> +++ b/drivers/net/ethernet/intel/libie/controlq.c
> @@ -766,6 +766,14 @@ libie_ctlq_xn_process_recv(struct
> libie_ctlq_xn_recv_params *params,
>  	    msg_cookie != xn->cookie)
>  		return false;
> 
> +	if (ctlq_msg->chnl_retval) {
> +		dev_err_ratelimited(
> +			params->ctlq->dev,
> +			"Non-zero virtchnl ret val (msg op: %u, ret val:
> %u, data_len: %u); xn id: %u, cookie: %u\n",
> +			ctlq_msg->chnl_opcode, ctlq_msg->chnl_retval,
> +			ctlq_msg->data_len, xn->index, xn->cookie);
'virtchnl ret val' 'ret val:' looks like a duplication in dmesg.


> +	}
> +
>  	spin_lock(&xn->xn_lock);
>  	if (xn->state != LIBIE_CTLQ_XN_ASYNC &&
>  	    xn->state != LIBIE_CTLQ_XN_WAITING) { @@ -1011,6 +1019,11
> @@ int libie_ctlq_xn_send(struct libie_ctlq_xn_send_params *params)
>  		params->recv_mem = xn->recv_mem;
>  		break;
>  	default:
> +		dev_err_ratelimited(
> +			params->ctlq->dev,
> +			"Transaction failed (op %u, xn state: %d, id: %u,
> cookie: %u, size: %zu)\n",
> +			params->chnl_opcode, xn->state, xn->index, xn-
> >cookie,
> +			xn->recv_mem.iov_len);
Probably %u fits better for enums than %d, what do you think?

>  		ret = -EBADMSG;
>  		break;
>  	}
> --
> 2.54.0.545.g6539524ca2-goog