Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8673657ybl; Wed, 25 Dec 2019 04:01:12 -0800 (PST) X-Google-Smtp-Source: APXvYqzLR8gu9yt27rnx8nrXCzOKnhzfTyrTGGzLkAiCW5xt1p+rsuobN/ulRsu/K7s5P48nPBWJ X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr43227237otr.82.1577275272408; Wed, 25 Dec 2019 04:01:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577275272; cv=none; d=google.com; s=arc-20160816; b=wzYwfYOReMNj5+svyYHynN7aYgdYMq6jcP+0pjHPDVytlhOt37Uwasz1QJDmIsEgT0 O4SGMZLwk+9ta5xD/BbELXl8Z2z4HFX3gK8u/zLcv8CAOFlo6z/a4kWgrub6QZ4LTSJr bWeeTp7ctdXHWPFg1oKlR9EqoZH9XIqyvlbkGhHBQMJBC5AK3PgMAWXF/H1nw9sVLH/Q Ko2BwhvVatrcOJaao8tsrNe1aaHW6z8ke1d0GsoqUacLz7O6R+EZLrvnjhVUqSoSIqIZ B2kq6EXnJz8+YESgCpbPo41KB1ulKJZMkI5zCe4ilfOh2Qao3BsiNieWtvdNxzFU3/lC uUsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dmarc-filter:dkim-signature; bh=c6an8/Z23mk72wAndOgi4rRRAW4ieK2ZfE4YK4K4+hE=; b=09s3/x5IlHoqnqCtZe4mCS8ZJ9nOjt7ERKwY7YVZS7sNSdG6uAZrLkDw29LAPcX6ZP OObre8enkElYIV2zbMVIEI/38ht1siAVF6jGePsHLPFritpFHHf61XLczJ1oxRoz9pOJ D5fG2ZJAt/eql6bRkATFD/XMUmEzkA5SofdeDa0odq6a3rreVuji7u31CIJYF2EKIeN7 UJUABPde2IlPHfZa7HNFMvQFlf/JwBCEV7OQIZ/PY/fdu6WLv3pH62Z4GIzuIe1Riog9 DQyPByJNBPN+lcIyKAlwGPYxHKp3tZR/M4oBPu7a2Wp3HISs7fE46WAuhQyMPv1UL7py oSfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=c7EvmUvB; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p62si4070150oig.101.2019.12.25.04.00.52; Wed, 25 Dec 2019 04:01:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=c7EvmUvB; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726352AbfLYMAo (ORCPT + 99 others); Wed, 25 Dec 2019 07:00:44 -0500 Received: from mail26.static.mailgun.info ([104.130.122.26]:10539 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726025AbfLYMAn (ORCPT ); Wed, 25 Dec 2019 07:00:43 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1577275243; h=Content-Transfer-Encoding: MIME-Version: References: In-Reply-To: Message-Id: Date: Subject: Cc: To: From: Sender; bh=c6an8/Z23mk72wAndOgi4rRRAW4ieK2ZfE4YK4K4+hE=; b=c7EvmUvBwuu+HievQfrnkhDzQYmh8+NE4IDvv79Ts3GVIICa4dBY4pAMQhznVKNZCjO3snuo MGEk+r5Etr3VTDjO1sN4SbNqEhyoEZGiDElYjfnE2QbGrWmiNlmybnZZ/WUpCv5QA9Vjzwnc qkZyXAqMhw3UokzW9EAt2mP9IW8= X-Mailgun-Sending-Ip: 104.130.122.26 X-Mailgun-Sid: WyI3YTAwOSIsICJsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5e034f69.7fc37c25eab0-smtp-out-n02; Wed, 25 Dec 2019 12:00:41 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id C49A2C447A0; Wed, 25 Dec 2019 12:00:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,SPF_NONE, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from wgong-HP-Z240-SFF-Workstation.qca.qualcomm.com (unknown [180.166.53.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: wgong) by smtp.codeaurora.org (Postfix) with ESMTPSA id 82971C447A9; Wed, 25 Dec 2019 12:00:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 82971C447A9 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=wgong@codeaurora.org From: Wen Gong To: ath10k@lists.infradead.org Cc: linux-wireless@vger.kernel.org Subject: [PATCH v2 2/2] ath10k: start recovery process when payload length exceeds max htc length for sdio Date: Wed, 25 Dec 2019 20:00:02 +0800 Message-Id: <20191225120002.11163-3-wgong@codeaurora.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191225120002.11163-1-wgong@codeaurora.org> References: <20191225120002.11163-1-wgong@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org When simulate random transfer fail for sdio write and read, it happened "payload length exceeds max htc length" and recovery later sometimes. Test steps: 1. Add config and update kernel: CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y 2. Run simulate fail: cd /sys/kernel/debug/mmc1/fail_mmc_request echo 10 > probability echo 10 > times # repeat until hitting issues 3. It happened payload length exceeds max htc length. [ 199.935506] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 .... [ 264.990191] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 4. after some time, such as 60 seconds, it start recovery which triggered by wmi command timeout for periodic scan. [ 269.229232] ieee80211 phy0: Hardware restart was requested [ 269.734693] ath10k_sdio mmc1:0001:1: device successfully recovered The simulate fail of sdio is not a real sdio transter fail, it only set an error status in mmc_should_fail_request after the transfer end, actually the transfer is success, then sdio_io_rw_ext_helper will return error status and stop transfer the left data. For example, the really RX len is 286 bytes, then it will split to 2 blocks in sdio_io_rw_ext_helper, one is 256 bytes, left is 30 bytes, if the first 256 bytes get an error status by mmc_should_fail_request,then the left 30 bytes will not read in this RX operation. Then when the next RX arrive, the left 30 bytes will be considered as the header of the read, the top 4 bytes of the 30 bytes will be considered as lookaheads, but actually the 4 bytes is not the lookaheads, so the len from this lookaheads is not correct, it exceeds max htc length 4088 sometimes. When happened exceeds, the buffer chain is not matched between firmware and ath10k, then it need to start recovery ASAP. Recently then recovery will be started by wmi command timeout, but it will be long time later, for example, it is 60+ seconds later from the periodic scan, if it does not have periodic scan, it will be longer. Start recovery when it happened "payload length exceeds max htc length" will be reasonable. This patch only effect sdio chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong --- drivers/net/wireless/ath/ath10k/sdio.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c index 7b894dcaad2e..78f431609493 100644 --- a/drivers/net/wireless/ath/ath10k/sdio.c +++ b/drivers/net/wireless/ath/ath10k/sdio.c @@ -557,6 +557,12 @@ static int ath10k_sdio_mbox_rx_alloc(struct ath10k *ar, le16_to_cpu(htc_hdr->len), ATH10K_HTC_MBOX_MAX_PAYLOAD_LENGTH); ret = -ENOMEM; + + if (ar->state == ATH10K_STATE_ON) { + queue_work(ar->workqueue, &ar->restart_work); + ath10k_warn(ar, "exceeds length, start recovery\n"); + } + goto err; } -- 2.23.0