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

Date:   Sat, 5 Jan 2019 16:30:11 +0000
From:   Bernd Edlinger <bernd.edlinger@...mail.de>
To:     Larry Finger <Larry.Finger@...inger.net>,
        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 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.

Thanks
Bernd.