Bug 204571 - iwlwifi: AX200: firmware fails on 5.2.5 - 5.2.8 regression from 5.1.20: loads ver 48 instead of 46
Summary: iwlwifi: AX200: firmware fails on 5.2.5 - 5.2.8 regression from 5.1.20: loads...
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: Intel Linux
: P1 blocking
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-13 19:00 UTC by Arcadiy Ivanov
Modified: 2019-11-13 04:32 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.2.5, 5.2.6, 5.2.7, 5.2.8
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Arcadiy Ivanov 2019-08-13 19:00:56 UTC
The bug reported downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1738361

Basically AX200 driver in 5.2.x seems to be confused about what card it's operating on, and looks like it tries to load AX201 firmware into AX200. This ends up pulling in firmware 48.x vs in 5.1.20 46.x. This results in a perpetual firmware crash and non-functioning wireless in 5.2.x.
Comment 1 Arcadiy Ivanov 2019-08-19 17:59:20 UTC
The bug appears to be fixed in 5.2.9.
Comment 2 Arcadiy Ivanov 2019-08-19 18:03:55 UTC
Presumably the follwing were the fixes:

commit be088ac6e1c29655de1329a86ca017a65cf1c631
Author: Luca Coelho <luciano.coelho@intel.com>
Date:   Fri Jul 19 12:21:59 2019 +0300

    iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support
    
    commit f5a47fae6aa3eb06f100e701d2342ee56b857bee upstream.
    
    We erroneously added a check for FW API version 41 before sending
    GEO_TX_POWER_LIMIT, but this was already implemented in version 38.
    Additionally, it was cherry-picked to older versions, namely 17, 26
    and 29, so check for those as well.
    
    Cc: stable@vger.kernel.org
    Fixes: eca1e56ceedd ("iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares")
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2985d54cc5f7b0bc9f35032521e66039e1a559c
Author: Luca Coelho <luciano.coelho@intel.com>
Date:   Mon Jun 24 22:29:33 2019 +0300

    iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41
    
    commit 39bd984c203e86f3109b49c2a2e20677c4d3ab65 upstream.
    
    Firmware versions before 41 don't support the GEO_TX_POWER_LIMIT
    command, and sending it to the firmware will cause a firmware crash.
    We allow this via debugfs, so we need to return an error value in case
    it's not supported.
    
    This had already been fixed during init, when we send the command if
    the ACPI WGDS table is present.  Fix it also for the other,
    userspace-triggered case.
    
    Cc: stable@vger.kernel.org
    Fixes: 7fe90e0e3d60 ("iwlwifi: mvm: refactor geo init")
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a985a6b398d6054f5abf048cba18c30d3cffd8a0
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Jul 22 13:02:25 2019 +0300

    iwlwifi: mvm: fix a use-after-free bug in iwl_mvm_tx_tso_segment
    
    commit 71b256f8f7a5c09810d2c3ed6165629c2cc0a652 upstream.
    
    Accessing the hdr of an skb that was consumed already isn't
    a good idea.
    First ask if the skb is a QoS packet, then keep that data
    on stack, and then consume the skb.
    This was spotted by KASAN.
    
    Cc: stable@vger.kernel.org
    Fixes: 08f7d8b69aaf ("iwlwifi: mvm: bring back mvm GSO code")
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54ae6149f4cb0ae9c622ba2ef9cb908446ed8c45
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Jul 22 12:47:27 2019 +0300

    iwlwifi: mvm: fix an out-of-bound access
    
    commit ba3224db78034435e9ff0247277cce7c7bb1756c upstream.
    
    The index for the elements of the ACPI object we dereference
    was static. This means that if we called the function twice
    we wouldn't start from 3 again, but rather from the latest
    index we reached in the previous call.
    This was dutifully reported by KASAN.
    
    Fix this.
    
    Cc: stable@vger.kernel.org
    Fixes: 6996490501ed ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table")
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddee2b078360038527a7feece687307ea2685940
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Sun Jul 21 14:02:27 2019 +0300

    iwlwifi: don't unmap as page memory that was mapped as single
    
    commit 87e7e25aee6b59fef740856f4e86d4b60496c9e1 upstream.
    
    In order to remember how to unmap a memory (as single or
    as page), we maintain a bit per Transmit Buffer (TBs) in
    the meta data (structure iwl_cmd_meta).
    We maintain a bitmap: 1 bit per TB.
    If the TB is set, we will free the memory as a page.
    This bitmap was never cleared. Fix this.
    
    Cc: stable@vger.kernel.org
    Fixes: 3cd1980b0cdf ("iwlwifi: pcie: introduce new tfd and tb formats")
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Comment 3 Luca Coelho 2019-08-21 12:42:06 UTC
Thanks for reporting and following up to say it's fixed in 5.2.9.  We had some issues with FW API versioning and detection of the NIC, but all the known problems regarding this are already fixed.
Comment 4 Naruto windy 2019-11-13 04:32:00 UTC
im using 5.3.10-arch1-1 still facing same problem, It appears to have bugs in firmware , this chip has problem with the 5Ghz connections,frequently disconnecting with AP.

[3.011344] iwlwifi 0000:3b:00.0: loaded firmware version 48.4fa0041f.0 op_mode iwlmvm

Note You need to log in before you can comment on or make changes to this bug.