Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Alan Brady <alan.brady@intel.com>
Cc: netdev@vger.kernel.org, willemdebruijn.kernel@gmail.com,
	intel-wired-lan@lists.osuosl.org, igor.bagnucki@intel.com,
	przemyslaw.kitszel@intel.com
Subject: Re: [Intel-wired-lan] [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages
Date: Tue, 20 Feb 2024 14:47:36 +0100	[thread overview]
Message-ID: <ff4ce794-3c0d-43a9-a991-91aadd44760b@intel.com> (raw)
In-Reply-To: <04033c1e-c3f8-4f05-8c88-f0cd642e8c55@intel.com>

From: Alexander Lobakin <aleksander.lobakin@intel.com>
Date: Wed, 14 Feb 2024 15:49:51 +0100

> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Tue, 6 Feb 2024 18:02:33 +0100
> 
>> From: Alan Brady <alan.brady@intel.com>
>> Date: Mon, 5 Feb 2024 19:37:54 -0800
>>
>>> The motivation for this series has two primary goals. We want to enable
>>> support of multiple simultaneous messages and make the channel more
>>> robust. The way it works right now, the driver can only send and receive
>>> a single message at a time and if something goes really wrong, it can
>>> lead to data corruption and strange bugs.
>>
>> This works better than v3.
>> For the basic scenarios:
>>
>> Tested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> 
> Sorry I'm reverting my tag.
> After the series, the CP segfaults on each rmmod idpf:
> 
> root@mev-imc:/usr/bin/cplane# cp_pim_mdd_handler: MDD interrupt detected
> cp_pim_mdd_event_handler: reg = 40
> Jan  1 00:27:57 mev-imc local0.warn LanCP[190]: cp_pim_mdd_handler: MDD
> interrupt detected
> cp_pim_mdd_event_handler: reg = 1
> Jan  1 00:28:54 mev-imc local0.warn LanCP[190]: [hma_create_vport/4257]
> WARNING: RSS is configured on 1st contiguous num of queuJan  1 00:28:54
> mev-imc local0.warn LanCP[190]: [hma_create_vport/4257] WARNING: RSS is
> configured on 1st contiguous num of queuJan  1 00:28:55 mev-imc
> local0.warn LanCP[190]: [hma_create_vport/4257] WARNING: RSS is
> configured on 1st contiguous num of queues= 16 start Qid= 34
> Jan  1 00:28:55 mev-imc local0.warn LanCP[190]: [hma_create_vport/4257]
> WARNING: RSS is configured on 1st contiguous num of queu16 start Qid= 640
> Jan  1 00:28:55 mev-imc local0.err LanCP[190]:
> [cp_del_node_rxbuff_lst/4179] ERR: Resource list is empty, so nothing to
> delete here
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_tc_q_region/222] ERR: Failed to init vsi LUT on vsi 1.
> Jan  1 00::08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_fxp_config/1101] ERR: cp_uninit_vsi_rss_config() failed
> on vsi (1).
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_tc_q_region/222] ERR: Failed to init vsi LUT on vsi 6.
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_rss_config/340] ERR: faininit_vsi_rss_config() failed on
> vsi (6).
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_tc_q_region/222] ERR: Failed to init vsi LUT on vsi 7.
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_rss_config/340] ERR: failed to remove vsi (7)'s queue
> regions.
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_fxp_config/1101] ERR: cp_uninit_vo init vsi LUT on vsi 8.
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_rss_config/340] ERR: failed to remove vsi (8)'s queue
> regions.
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_fxp_config/1101] ERR: cp_uninit_vsi_rss_config() failed
> on vsi (8).
> Jan  1 00:29:08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_tc_q_region/222] ERR: Failed to init vsi LUT on vsi 1.
> Jan  1 00::08 mev-imc local0.err LanCP[190]:
> [cp_uninit_vsi_fxp_config/1101] ERR: cp_uninit_vsi_rss_config() failed
> on vsi (1).
> 
> [1]+  Segmentation fault      ./imccp 0000:00:01.6 0 cp_init.cfg
> 
> Only restarting the CP helps -- restarting the imccp daemon makes it
> immediately crash again.
> 
> This should be dropped from the next-queue until it's fixed.

The latest firmware works with this series -- the problem was there,
the series only revealed it.

Tested-by: Alexander Lobakin <aleksander.lobakin@intel.com>

Can be taken back to Tony's tree.

Thanks,
Olek

  parent reply	other threads:[~2024-02-20 13:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-06  3:37 [Intel-wired-lan] [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages Alan Brady
2024-02-06  3:37 ` [Intel-wired-lan] [PATCH v4 01/10 iwl-next] idpf: implement virtchnl transaction manager Alan Brady
2024-02-20 14:30   ` Alexander Lobakin
2024-02-20 16:23     ` Alan Brady
2024-02-06  3:37 ` [Intel-wired-lan] [PATCH v4 02/10 iwl-next] idpf: refactor vport virtchnl messages Alan Brady
2024-02-06  3:37 ` [Intel-wired-lan] [PATCH v4 03/10 iwl-next] idpf: refactor queue related " Alan Brady
2024-02-06  3:37 ` [Intel-wired-lan] [PATCH v4 04/10 iwl-next] idpf: refactor remaining " Alan Brady
2024-02-06  3:37 ` [Intel-wired-lan] [PATCH v4 05/10 iwl-next] idpf: add async_handler for MAC filter messages Alan Brady
2024-02-06  3:38 ` [Intel-wired-lan] [PATCH v4 06/10 iwl-next] idpf: refactor idpf_recv_mb_msg Alan Brady
2024-02-06  3:38 ` [Intel-wired-lan] [PATCH v4 07/10 iwl-next] idpf: cleanup virtchnl cruft Alan Brady
2024-02-06  3:38 ` [Intel-wired-lan] [PATCH v4 08/10 iwl-next] idpf: prevent deinit uninitialized virtchnl core Alan Brady
2024-02-06  3:38 ` [Intel-wired-lan] [PATCH v4 09/10 iwl-next] idpf: fix minor controlq issues Alan Brady
2024-02-06  3:38 ` [Intel-wired-lan] [PATCH v4 10/10 iwl-next] idpf: remove dealloc vector msg err in idpf_intr_rel Alan Brady
2024-02-06 17:02 ` [Intel-wired-lan] [PATCH v4 00/10 iwl-next] idpf: refactor virtchnl messages Alexander Lobakin
2024-02-14 14:49   ` Alexander Lobakin
2024-02-14 17:06     ` Alan Brady
2024-02-20 13:47     ` Alexander Lobakin [this message]
2024-02-06 18:57 ` Jakub Kicinski
2024-02-06 19:18   ` Alan Brady
2024-02-06 20:03     ` Jakub Kicinski
2024-02-06 22:50       ` Keller, Jacob E
2024-02-06 23:17         ` Jakub Kicinski

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=ff4ce794-3c0d-43a9-a991-91aadd44760b@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=alan.brady@intel.com \
    --cc=igor.bagnucki@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox