[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c1f25bc-dfc6-56e2-745c-4607f0f41159@lwfinger.net>
Date: Sat, 5 Jan 2019 10:13:12 -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 5:31 AM, Bernd Edlinger wrote:
> On 1/5/19 3:44 AM, Larry Finger wrote:
>> On 1/4/19 6:48 AM, Bernd Edlinger wrote:
>>> This appears to trigger a firmware bug and causes severe
>>> problems with rtl8723ae PCI devices.
>>>
>>> When the power save mode is activated for longer periods
>>> of time the firmware stops to receive any packets.
>>>
>>> This problem was exposed by commit 873ffe154ae0 ("rtlwifi:
>>> Fix logic error in enter/exit power-save mode").
>>>
>>> Previously the power save mode was only active rarely and
>>> only for a short time so that the problem was not noticeable.
>>>
>>> Signed-off-by: Bernd Edlinger <bernd.edlinger@...mail.de>
>>> ---
>>
>> While the Realtek firmware group has a chance to look for a bug, I would like you to perform a couple of tests on the original code.
>>
>> The driver has three module parameters that affect power save. The 'modinfo rtl8723ae' command lists them as
>>
>> parm: ips:Set to 0 to not use link power save (default 1) (bool)
>> parm: swlps:Set to 1 to use SW control power save (default 0) (bool)
>> parm: fwlps:Set to 1 to use FW control power save (default 1) (bool)
>>
>> If you were to load rtl8723ae with 'ips=0', does it still fail?
>> If you were to load the driver with 'swlps=1 fwlps=0', does it still fail?
>>
>
> this does not work:
>
> modprobe rtl8723ae debug_mask=0xFFFFFFFF debug_level=5 ips=0
>
> tail -f /var/log/syslog|grep "AP off"
> Jan 5 11:42:06 w-ed kernel: [ 7267.229713] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:42:08 w-ed kernel: [ 7269.276761] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:42:10 w-ed kernel: [ 7271.323758] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:42:12 w-ed kernel: [ 7273.370759] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:42:14 w-ed kernel: [ 7275.417753] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:42:14 w-ed kernel: [ 7275.417754] rtlwifi: AP off, try to reconnect now
> Jan 5 11:42:28 w-ed kernel: [ 7289.746676] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:42:40 w-ed kernel: [ 7302.028327] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:42:43 w-ed kernel: [ 7304.075327] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:42:45 w-ed kernel: [ 7306.122330] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:42:47 w-ed kernel: [ 7308.169292] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:42:49 w-ed kernel: [ 7310.216236] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:42:49 w-ed kernel: [ 7310.216238] rtlwifi: AP off, try to reconnect now
> Jan 5 11:43:05 w-ed kernel: [ 7326.592222] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:43:07 w-ed kernel: [ 7328.639076] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:43:09 w-ed kernel: [ 7330.686220] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:43:11 w-ed kernel: [ 7332.733078] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:43:13 w-ed kernel: [ 7334.779988] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:43:13 w-ed kernel: [ 7334.779989] rtlwifi: AP off, try to reconnect now
> Jan 5 11:43:28 w-ed kernel: [ 7349.108839] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:43:30 w-ed kernel: [ 7351.155837] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:43:32 w-ed kernel: [ 7353.202838] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:43:42 w-ed kernel: [ 7363.437779] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:43:46 w-ed kernel: [ 7367.531622] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:43:48 w-ed kernel: [ 7369.578597] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:43:50 w-ed kernel: [ 7371.625694] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:43:52 w-ed kernel: [ 7373.672691] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:43:54 w-ed kernel: [ 7375.719690] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:43:54 w-ed kernel: [ 7375.719691] rtlwifi: AP off, try to reconnect now
> Jan 5 11:44:09 w-ed kernel: [ 7390.048406] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:44:11 w-ed kernel: [ 7392.095678] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:44:13 w-ed kernel: [ 7394.142349] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:44:15 w-ed kernel: [ 7396.189352] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:44:17 w-ed kernel: [ 7398.236352] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:44:17 w-ed kernel: [ 7398.236353] rtlwifi: AP off, try to reconnect now
> Jan 5 11:44:31 w-ed kernel: [ 7412.565079] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:44:33 w-ed kernel: [ 7414.612167] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:44:35 w-ed kernel: [ 7416.659101] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:44:37 w-ed kernel: [ 7418.706035] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:44:39 w-ed kernel: [ 7420.753100] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:44:39 w-ed kernel: [ 7420.753101] rtlwifi: AP off, try to reconnect now
> Jan 5 11:44:54 w-ed kernel: [ 7435.081860] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:44:56 w-ed kernel: [ 7437.128857] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:45:08 w-ed kernel: [ 7449.410653] rtlwifi: :<0> AP off for 2 s
> Jan 5 11:45:10 w-ed kernel: [ 7451.457650] rtlwifi: :<0> AP off for 4 s
> Jan 5 11:45:12 w-ed kernel: [ 7453.504647] rtlwifi: :<0> AP off for 6 s
> Jan 5 11:45:14 w-ed kernel: [ 7455.551607] rtlwifi: :<0> AP off for 8 s
> Jan 5 11:45:16 w-ed kernel: [ 7457.598645] rtlwifi: :<0> AP off for 10 s
> Jan 5 11:45:16 w-ed kernel: [ 7457.598646] rtlwifi: AP off, try to reconnect now
>
>
> 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.
Thanks for testing,
Larry
Powered by blists - more mailing lists