Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <60e2c052f3cedc5c80964e4be90c50cdaa899a87.camel@sipsolutions.net>
Subject: Re: Microcode SW error since Linux 6.5
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Antoine =?ISO-8859-1?Q?Beaupr=E9?= <anarcat@debian.org>,
        linux-wireless@vger.kernel.org
Cc:     Gregory Greenman <gregory.greenman@intel.com>, ilan.peer@intel.com
Date:   Thu, 21 Sep 2023 21:29:27 +0200
In-Reply-To: <87ttrncuc8.fsf@angela.anarc.at>
References: <87ttrncuc8.fsf@angela.anarc.at>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2023-09-21 at 13:24 -0400, Antoine Beaupr=C3=A9 wrote:
> Hi,
>=20
> I've found what I feel might be a regression between Linux 6.1 and
> 6.5. For other reasons, I upgraded the kernel on my Debian 12
> ("bookworm", stale) laptop from the distribution 6.1.52 to the unstable
> ("sid") version, 6.5.3.
>=20
> After the upgrade, I started to notice stuttering in my audio player, I
> tracked it down and managed to correlate it with some kernel errors
> related to the iwlwifi driver.
>=20
> What's interesting is that this happens regardless of whether or not the
> NIC is connected to a network. In at least one of the traces, the
> computer was connected over a wire and wireless was not associated in
> Network Manager.

This happens when scanning.


> Here's an example of the problem:
>=20
> sep 21 09:33:14 angela kernel: iwlwifi 0000:a6:00.0: Microcode SW error d=
etected. Restarting 0x0.

Can you give a few wpa_supplicant lines (there were some below) above
this? Just want to make sure it really is scanning on wlan0, not
something with P2P device.

> sep 21 09:33:14 angela kernel: iwlwifi 0000:a6:00.0: 0x20103600 | ADVANCE=
D_SYSASSERT

> sep 21 09:33:14 angela kernel: iwlwifi 0000:a6:00.0: 0x000000FF | umac da=
ta1

This means that somehow scan_start_mac_or_link_id in the driver ended up
0xff which is invalid, but I'm not sure I see immediately how that
happened, since it looks like in 6.5.3 we do assign it reasonably. I
guess somehow in the code link_info->fw_link_id must be 0xff (invalid
ID), but I'm not sure I see how that could happen.

*thinks*

Oh.. This is an older firmware, so it doesn't have
IWL_UCODE_TLV_CAPA_MLD_API_SUPPORT! Hah. I feel like I had some concerns
in this area before ... but maybe the other way around.

I think something like this, perhaps:

--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@ -2342,7 +2342,7 @@ iwl_mvm_scan_umac_fill_general_p_v12(struct iwl_mvm *=
mvm,
 	if (gen_flags & IWL_UMAC_SCAN_GEN_FLAGS_V2_FRAGMENTED_LMAC2)
 		gp->num_of_fragments[SCAN_HB_LMAC_IDX] =3D IWL_SCAN_NUM_OF_FRAGS;
=20
-	if (version < 12) {
+	if (version < 12 || !iwl_mvm_has_mld_api(mvm->fw)) {
 		gp->scan_start_mac_or_link_id =3D scan_vif->id;
 	} else {
 		struct iwl_mvm_vif_link_info *link_info;

johannes