From: James Cameron <quozl@laptop.org>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: linux-wireless@vger.kernel.org, Ping-Ke Shih <pkshih@realtek.com>,
Kalle Valo <kvalo@codeaurora.org>
Subject: Re: rtl8821ae keep alive not set, connection lost
Date: Thu, 21 Sep 2017 09:22:28 +1000 [thread overview]
Message-ID: <20170920232228.GC9210@us.netrek.org> (raw)
In-Reply-To: <476b183f-5cc5-9a34-1a85-332dd5244b66@lwfinger.net>
On Wed, Sep 20, 2017 at 04:48:23PM -0500, Larry Finger wrote:
> On 09/20/2017 04:36 AM, James Cameron wrote:
> >When the problem occurs, register 0x350 bit 25 is set, for which a
> >comment in _rtl8821ae_check_pcie_dma_hang says means there is an RX
> >hang.
> >
> >So perhaps driver should call _rtl8821ae_check_pcie_dma_hang
> >and _rtl8821ae_reset_pcie_interface_dma.
> >
> >Any ideas where to do this?
>
> Thanks for the extended debugging.
>
> I was able to repeat your findings. With the 8-bit read of
> REG_DBI_RDATA, I got poor connection stability. Reverting that part
> made it stable again. For that reason, I pushed the partial
> reversion of commit 40b368af4b75 ("rtlwifi: Fix alignment issues").
That's great you were able to reproduce, thanks!
> Where did you detect that bit 25 of register 0x350 was set?
In _rtl8821ae_check_pcie_dma_hang on link up.
REG_DBI_FLAG (0x350 bits 16-31) is observed as;
- 0x0000 on entry to function after warm boot,
- 0x0400 on exit from function; debug bit 23 is set by the function,
- 0x0400 on entry to function on link up when the problem has not
happened,
- 0x0600 on entry to function on link up when the problem has
happened.
But I don't know if 0x0600 is useful to detect earlier, or if it is
only a symptom of link down while device active. Either way, if it
truly does signal an RX hang or firmware RX queue full, it's useful.
My "-q9" and "-qa" test kernels dump REG_DBI_CTRL and REG_DBI_FLAG.
"-q9" is with 8-bit read of REG_DBI_RDATA.
"-qa" is with 16-bit read of REG_DBI_DATA.
My "-qa" test kernel;
http://dev.laptop.org/~quozl/y/1dunwN.txt (git diff v4.13)
http://dev.laptop.org/~quozl/z/1dubX7.txt (dmesg)
REG_DBI_CTRL+3 used by _rtl8821ae_check_pcie_dma_hang is effectively
REG_DBI_FLAG+1 (0x353).
REG_DBI_CTRL is REG_DBI_ADDR; a duplicate register definition.
I'm still pondering a few more theories;
- change write_readback, it is true now, and the while()/udelay in
_rtl8821ae_dbi_read seems a waste, it never executes,
- clearing REG_DBI_CTRL write enable bits at the end of
_rtl8821ae_dbi_write,
- switching to 32-bit access as used by rtl8192de.
And a giggle from reviewing the code,
_rtl8821ae_wowlan_initialize_adapter says "Patch Pcie Rx DMA hang
after S3/S4 several times. The root cause has not be found."
... I've learned that root causes that aren't found tend to cause
further problems later. ;-)
Given this, my gut feel is firmware or silicon problem; RX DMA ceases,
the driver does not detect it, the connection is lost.
--
James Cameron
http://quozl.netrek.org/
next prev parent reply other threads:[~2017-09-20 23:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 22:09 rtl8821ae keep alive not set, connection lost James Cameron
2017-09-13 15:01 ` Larry Finger
2017-09-13 21:46 ` James Cameron
2017-09-14 0:39 ` Larry Finger
2017-09-14 9:27 ` James Cameron
2017-09-19 9:42 ` James Cameron
2017-09-20 9:36 ` James Cameron
2017-09-20 21:48 ` Larry Finger
2017-09-20 23:22 ` James Cameron [this message]
2017-09-21 8:07 ` James Cameron
2017-09-21 14:40 ` Larry Finger
2017-09-22 5:35 ` James Cameron
2018-01-31 17:06 ` Larry Finger
2018-02-01 6:22 ` James Cameron
2018-02-02 7:50 ` Pkshih
2018-02-02 20:13 ` Larry Finger
2018-02-03 4:45 ` Pkshih
2018-02-04 18:18 ` Larry Finger
2018-02-02 20:27 ` Larry Finger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170920232228.GC9210@us.netrek.org \
--to=quozl@laptop.org \
--cc=Larry.Finger@lwfinger.net \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pkshih@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).