Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <0190dde1170bd1ee810e99b9799678f4f5b8f30e.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:   Mon, 25 Sep 2023 08:03:09 +0200
In-Reply-To: <87jzsf9dme.fsf@angela.anarc.at>
References: <87ttrncuc8.fsf@angela.anarc.at>
         <60e2c052f3cedc5c80964e4be90c50cdaa899a87.camel@sipsolutions.net>
         <87jzsf9dme.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 Sun, 2023-09-24 at 22:43 -0400, Antoine Beaupr=C3=A9 wrote:
>=20
> Interestingly, for the above fault, there's no wpa_supplicant line just
> *before*. There's this *after*:
>=20
> sep 21 09:33:14 angela wpa_supplicant[1563]: wlan0: CTRL-EVENT-SCAN-FAILE=
D ret=3D-5

Yeah I saw this, just wasn't sure where it was scanning, hence the
question. But I don't think it mattered.

> But an earlier one is preceeded by:
>=20
> sep 21 09:32:45 angela wpa_supplicant[1563]: wlan0: CTRL-EVENT-SCAN-FAILE=
D ret=3D-5
> sep 21 09:32:45 angela kernel: iwlwifi 0000:a6:00.0: Microcode SW error d=
etected. Restarting 0x0.
> [...]

Well I guess there was just another scan before that one :)

>=20
> > I think something like this, perhaps:
> >=20
> > --- 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_m=
vm *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;
>=20
> Interesting! In any case, the firmware is certainly out of date in
> Debian stable, and I guess it's to be expected that having it out of
> sync with the running kernel is a Bad Idea, it's just not something I've
> thought of before. :)

Did that patch help?

> Thanks for the debugging, I'll make sure to keep the firmware and kernel
> in better lockstep in the future!

Yes, you can ... but I mean, we still do want to consider this a bug, I
think, since we explicitly built the thing to load the older firmware.
It just gets _far_ less testing.

johannes