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]
Message-ID: <DB7PR07MB53539F1836CE716739F2409AE48F0@DB7PR07MB5353.eurprd07.prod.outlook.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ