linux-kernel - Re: [PATCH 1/4] rtlwifi: rtl8723ae: Take the FW LPS mode handling out

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-prev] [day] [month] [year] [list]

Date:   Sat, 5 Jan 2019 10:37:01 -0600
From:   Larry Finger <Larry.Finger@...inger.net>
To:     Bernd Edlinger <bernd.edlinger@...mail.de>,
        Ping-Ke Shih <pkshih@...ltek.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        "David S. Miller" <davem@...emloft.net>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] rtlwifi: rtl8723ae: Take the FW LPS mode handling out

On 1/5/19 10:30 AM, Bernd Edlinger wrote:
> On 1/5/19 5:13 PM, Larry Finger wrote:
>>> but this works:
>>>
>>> modprobe rtl8723ae debug_mask=0xFFFFFFFF debug_level=5 swlps=1 fwlps=0
>>
>> Yes, I think that is a better thing to do now. If and when Realtek finds a firmware bug, and when the new firmware is readily available, then there will not be a lot of code to reinstall.
>>
> 
> Okay, my assumption of how the firmware bug "works" is this:
> 
> Once the firmware enters power save mode, it will deliver exactly one (or maybe two)
> Rx interrupts. If one of those triggers the driver to leave the power save mode again,
> the firmware continues to work.
> If those are only beacons, they won't leave the power save mode.  Then the firmware
> will usually not recover.
> Since prior to commit 873ffe154ae0 ("rtlwifi: Fix logic error in enter/exit power-save mode")
> the power save mode was only activated when there _is_ busy traffic, the next
> packet did usually wake the firmware, rarely it did freeze however.
> Other things like changing the cck_packet_detection_threshold or refresh_rate_adaptive_mask
> can also kick the firmware back to life.
> 
> Hope this helps to track down the root cause of this bug.

As I know nothing of the firmware, that is outside my expertise, but that 
observation should be of great help to PK Shih, and his colleagues at Realtek.

Larry