Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp11999396rwd; Thu, 22 Jun 2023 23:20:23 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7bVYwpKAB5DSbjQ5ADuf5FCFRto8M0eVn0NdfzpKP3uJJ8/yBICK3t0vuGi4EGdBpes+n7 X-Received: by 2002:a92:d1cd:0:b0:342:6da0:6a1f with SMTP id u13-20020a92d1cd000000b003426da06a1fmr12227732ilg.32.1687501223648; Thu, 22 Jun 2023 23:20:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687501223; cv=none; d=google.com; s=arc-20160816; b=iX4Sbuep7XPsShzHL5E05tuuDLzW0KD7PfuKZMn3v4S5pHStDrulArRqGVmoFR7ZkO 9WpMdJ0TPhvTZ6tinBx3s1KJHIQWZf5Wet0qYj3K/BJU8pJ3AtUI3rhaQ6WH4CrGQbqz wa+cGn1CrGcvWhJ9q0LyaoFbuxMi63qZe+r7AqCVIjWVX3aKdD6GxyBuzp+k6LWzQ2+W dlwlM2Nn9oQfjE5dogSQENr9cP4rQtK8JN6RWJwWbsXhvMwJtvXKeHbezUrqECON9YcL UqKlmAZJ4GSlzxOEXABquiSmdB4H++MbAAIG8PdCEhYROZS7PUVlftDJr+pRW6nZSPZu baKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :authorized-sender; bh=sJHpLvVJ0/2+fwlFEgc3w5mu0GImTSxSOxPAQmPTKVw=; b=r6U8F3lFbPswdCjOulbd0dAauAjFg/1Bc833XOM7aVqLx55So/4McPIOjX6n9RPGeZ 9xN0TrY1jZn1qSOKzVzX6bAtsTxbp0SCRYdqd/0MzYwYkWZg/AdBuNsCdfFJE4b3wuRw ruDzihzVyOJ8VuuLcbLSiXxqywvZsObvVApkrdFHnE5M87Yzah3641WdTeGhWXktEqN3 Grli0joiNoC9fZHfaTy/9vSbP2+WwasNWMhUWfS9cFi9R8Cj+7ouzP4JxqbCWR/Ab0zP hd2WFsj9mZbNqsFJRAuKeqBAj2D/Mf0msWpj9+zJdurtepOyv/9ma09Tfd/3RE6Wgyjn vrzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p27-20020a637f5b000000b00553d074198fsi7726110pgn.137.2023.06.22.23.20.11; Thu, 22 Jun 2023 23:20:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230165AbjFWGKT (ORCPT + 58 others); Fri, 23 Jun 2023 02:10:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229902AbjFWGKR (ORCPT ); Fri, 23 Jun 2023 02:10:17 -0400 Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A18EA10DB for ; Thu, 22 Jun 2023 23:10:12 -0700 (PDT) X-Halon-ID: 98de02d7-118c-11ee-80b4-ade5659629c7 Authorized-sender: petter@technux.se Received: from localhost.localdomain (user33.85-195-12.netatonce.net [85.195.12.33]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 98de02d7-118c-11ee-80b4-ade5659629c7; Fri, 23 Jun 2023 08:10:09 +0200 (CEST) From: petter@technux.se To: s.hauer@pengutronix.de Cc: Larry.Finger@lwfinger.net, andreas@fatal.se, iam@valdikss.org.ru, kernel@pengutronix.de, kvalo@kernel.org, linux-wireless@vger.kernel.org, linux@ulli-kroll.de, petter.mabacker@esab.se, petter@technux.se, pkshih@realtek.com Subject: Re: rtw8822cu (LM842) stalls when running HW offload scan Date: Fri, 23 Jun 2023 08:10:03 +0200 Message-Id: <20230623061003.472077-1-petter@technux.se> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230616122612.GL18491@pengutronix.de> References: <20230616122612.GL18491@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, Jun 12, 2023 at 03:30:23PM +0200, petter@technux.se wrote: >> Some time ago https://bugzilla.kernel.org/show_bug.cgi?id=217034 was >> created. From the beginning it was just about some error printouts. >> Then Andreas (who created the bug report) mentioned that it seems to >> work worse after bumping the firmware to > 9.9.10. After some fixes >> from Sascha the error printouts dissappeared. But when I also started >> to run this using firmware > 9.9.10 I also got problems. On my i.MX8 >> and RPi4 board it works fine, but on some of my less powerful boards >> such as and older RPi and my i.MX6 SoloX board, it always fails using >> 9.9.10 firmware. After some digging in the git log, I discovered <> that HW scan offload was introduced in a later firmware. So when I >> disable HW offload scan it seems to work again on all my boards. But >> still I want to understand why the HW offload scan don't work for >> me. >> >> Like described in the bug report I get below when running on latest >> 6.4 mainline with all relevant patches around rtw88 applied. >I can't reproduce this here. I am currently running v6.4-rc3 plus: > >wifi: rtw88: usb: silence log flooding error message > >I tested on a i.MX6S (not SoloX) board with Firmware 9.9.14. > >A "nmcli dev wifi rescan" works just fine and the link also continues to >work. > >I verified that FW_FEATURE_SCAN_OFFLOAD is set and used in the driver, >also that it's not set in Firmware 9.9.9. I also tried to put some >load on the link by running iperf3, still no difference. > >Sascha > Thanks for your valuable feedback, this finding made think in another direction about this. First I tried to reproduced the issue using the same setup 6.4-rc3 + 'wifi: rtw88: usb: silence log flooding error message' but instead of using NM, I used wpa_cli to perform the scan. This time it works fine. After some digging I realised that I had a business application still running, that uses libnm and among other things reacts on some callback during scan. So I agree with your finding that this doesn't seems to be related to the actual HW offload scanning after all, instead it seems like using nmcli + HW offload scan + our internal application using libnm might trigger the same behavior that I reported in: https://lore.kernel.org/linux-wireless/20230526055551.1823094-1-petter@technux.se/T/#t I will try to do some investigations if I can use this info to find a better way to reproduce that issue. However it's still the case that I cannot reproduce above problem on for example an i.MX8 using maxcpus=1. Thanks, Petter