After some private coaching from Serge Belyshev on git-revert I can confirm that reverting that commit atop the current tree resolves the issue (the wifi card scans for and finds networks just fine, no dmesg errors reported, etc.).
On Sat, Aug 17, 2019 at 11:59:59AM +0300, Serge Belyshev wrote:
>
> > I am on an Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz running Linux
> > x86_64 (Slackware), with a custom-compiled 5.3.0-rc4 (.config
> > attached).
> >
> > I am using the Intel wifi adapter on this machine:
> >
> > 02:00.0 Network controller: Intel Corporation Device 24fb (rev 10)
> >
> > with the iwlwifi driver. I am attaching the output to 'lspci -vv -s
> > 02:00.0' as the file device-info.
> >
> > All 5.3.0-rc* versions I have tried (including rc4) cause multiple
> > dmesg iwlwifi-related errors (dmesg attached). Examples:
> >
> > iwlwifi 0000:02:00.0: Failed to get geographic profile info -5
> > iwlwifi 0000:02:00.0: Microcode SW error detected. Restarting 0x82000000
> > iwlwifi 0000:02:00.0: 0x00000038 | BAD_COMMAND
> >
>
> I have my logs filled with similar garbage throughout 5.3-rc*. Also
> since 5.3-rcsomething not only it WARNS in dmesg about firmware failure,
> but completely stops working after suspend/resume cycle.
>
> It looks like that:
>
> commit 4fd445a2c855bbcab81fbe06d110e78dbd974a5b
> Author: Haim Dreyfuss <[email protected]>
> Date: Thu May 2 11:45:02 2019 +0300
>
> iwlwifi: mvm: Add log information about SAR status
>
> Inform users when SAR status is changing.
>
> Signed-off-by: Haim Dreyfuss <[email protected]>
> Signed-off-by: Luca Coelho <[email protected]>
>
>
> is the culprit. (manually) reverting it on top of 5.3-rc4 makes
> everything work again.
On Sat, 2019-08-17 at 17:44 -0400, Stuart Little wrote:
> After some private coaching from Serge Belyshev on git-revert I can
> confirm that reverting that commit atop the current tree resolves the
> issue (the wifi card scans for and finds networks just fine, no dmesg
> errors reported, etc.).
Sorry for the delay in responding, I had to go and dig in our FW
sources to see what was going on.
Unfortunately when this feature was implemented in the FW, we forgot to
add the usual flag (capabilities TLV) that we add to let the driver
know whether the command is supported or not. So we need to match on
the FW version instead, but apparently that doesn't work for all
different NICs.
I'll have to look into all NIC/FW-version combinations that we have and
update the iwl_mvm_sar_geo_support() function accordingly, which is,
BTW, the easier place for you to change if you want to workaround the
issue.
--
Cheers,
Luca.
On Tue, Aug 20, 2019 at 01:45:37PM +0300, Luciano Coelho wrote:
> I'll have to look into all NIC/FW-version combinations that we have and
> update the iwl_mvm_sar_geo_support() function accordingly, which is,
> BTW, the easier place for you to change if you want to workaround the
> issue.
Thanks!
I didn't quite know how to interpret this suggestion (i.e. what the change should be), so I was poking around in there out of curiosity. One simple-minded thing that worked was to just pretend that that function always returns false:
--- cut here ---
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 5de54d1559dd..8c0160e5588f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -925,7 +925,7 @@ int iwl_mvm_get_sar_geo_profile(struct iwl_mvm *mvm)
.data = { data },
};
- if (!iwl_mvm_sar_geo_support(mvm))
+ /*if (!iwl_mvm_sar_geo_support(mvm))*/
return -EOPNOTSUPP;
ret = iwl_mvm_send_cmd(mvm, &cmd);
@@ -953,7 +953,7 @@ static int iwl_mvm_sar_geo_init(struct iwl_mvm *mvm)
int ret, i, j;
u16 cmd_wide_id = WIDE_ID(PHY_OPS_GROUP, GEO_TX_POWER_LIMIT);
- if (!iwl_mvm_sar_geo_support(mvm))
+ /*if (!iwl_mvm_sar_geo_support(mvm))*/
return 0;
ret = iwl_mvm_sar_get_wgds_table(mvm);
--- cut here ---
On Tue, Aug 20, 2019 at 12:45 PM Luciano Coelho
<[email protected]> wrote:
>
> On Sat, 2019-08-17 at 17:44 -0400, Stuart Little wrote:
> > After some private coaching from Serge Belyshev on git-revert I can
> > confirm that reverting that commit atop the current tree resolves the
> > issue (the wifi card scans for and finds networks just fine, no dmesg
> > errors reported, etc.).
>
> Sorry for the delay in responding, I had to go and dig in our FW
> sources to see what was going on.
>
> Unfortunately when this feature was implemented in the FW, we forgot to
> add the usual flag (capabilities TLV) that we add to let the driver
> know whether the command is supported or not. So we need to match on
> the FW version instead, but apparently that doesn't work for all
> different NICs.
>
> I'll have to look into all NIC/FW-version combinations that we have and
> update the iwl_mvm_sar_geo_support() function accordingly, which is,
> BTW, the easier place for you to change if you want to workaround the
> issue.
For the records (here: Linux v5.2.y)
"iwlwifi: Add support for SAR South Korea limitation"
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.2.y&id=2b9d99b399d5e4cd516973a4c56035fb0e2ee744
- Sedat -