Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Brady <alan.brady@intel.com>
To: Alexander Lobakin <aleksander.lobakin@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: Wed, 14 Feb 2024 09:06:16 -0800	[thread overview]
Message-ID: <7b89cd46-3957-4d57-88ff-ca30e517d214@intel.com> (raw)
In-Reply-To: <04033c1e-c3f8-4f05-8c88-f0cd642e8c55@intel.com>

On 2/14/2024 6:49 AM, Alexander Lobakin wrote:
> 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.
> 
> Thanks,
> Olek


I definitely tested rmmod so I'm frankly not understanding how this can 
be possible. If you would like I'm happy to sync on how you're able to 
cause this to happen. Our internal validation verified 1000 load/unloads 
passed their testing.

Is there more you're doing other than just rmmod?

Alan

  reply	other threads:[~2024-02-14 17:06 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 [this message]
2024-02-20 13:47     ` Alexander Lobakin
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=7b89cd46-3957-4d57-88ff-ca30e517d214@intel.com \
    --to=alan.brady@intel.com \
    --cc=aleksander.lobakin@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