lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 27 Aug 2020 09:07:02 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>,
        brcm80211-dev-list@...ress.com,
        brcm80211-dev-list.pdl@...adcom.com,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Broadcom WiFi SDIO performance regression after commit "mmc: sdhci:
 Remove finish_tasklet"

Hello!

I was debugging WiFi performance problems on Acer A500 tablet device
that has BCM4329 WiFi chip which is connected to NVIDIA Terga20 SoC via
SDIO and found that the following commit causes a solid 5-10 Mbit/s of
WiFi throughput regression after 5.2 kernel:

commit c07a48c2651965e84d35cf193dfc0e5f7892d612
Author: Adrian Hunter <adrian.hunter@...el.com>
Date:   Fri Apr 5 15:40:20 2019 +0300

    mmc: sdhci: Remove finish_tasklet

    Remove finish_tasklet. Requests that require DMA-unmapping or
sdhci_reset
    are completed either in the IRQ thread or a workqueue if the
completion is
    not initiated by the IRQ.

Reverting the offending commit on top of recent linux-next resolves the
problem.

Ulf / Adrian, do you have any ideas what could be done in regards to
restoring the SDIO performance? Should we just revert the offending commit?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ