All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Joakim Zhang <qiangqing.zhang@nxp.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back
Date: Thu, 25 Mar 2021 08:00:56 +0000	[thread overview]
Message-ID: <8e92b562-fa8f-0a2b-d8da-525ee52fc2d4@nvidia.com> (raw)
In-Reply-To: <DB8PR04MB6795863753DAD71F1F64F81DE6629@DB8PR04MB6795.eurprd04.prod.outlook.com>


On 25/03/2021 07:53, Joakim Zhang wrote:
> 
>> -----Original Message-----
>> From: Jon Hunter <jonathanh@nvidia.com>
>> Sent: 2021年3月24日 20:39
>> To: Joakim Zhang <qiangqing.zhang@nxp.com>
>> Cc: netdev@vger.kernel.org; Linux Kernel Mailing List
>> <linux-kernel@vger.kernel.org>; linux-tegra <linux-tegra@vger.kernel.org>;
>> Jakub Kicinski <kuba@kernel.org>
>> Subject: Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac
>> resume back
>>
>>
>>
>> On 24/03/2021 12:20, Joakim Zhang wrote:
>>
>> ...
>>
>>> Sorry for this breakage at your side.
>>>
>>> You mean one of your boards? Does other boards with STMMAC can work
>> fine?
>>
>> We have two devices with the STMMAC and one works OK and the other fails.
>> They are different generation of device and so there could be some
>> architectural differences which is causing this to only be seen on one device.
> It's really strange, but I also don't know what architectural differences could affect this. Sorry.


Maybe caching somewhere? In other words, could there be any cache
flushing that we are missing here?

>>> We do daily test with NFS to mount rootfs, on issue found. And I add this
>> patch at the resume patch, and on error check, this should not break suspend.
>>> I even did the overnight stress test, there is no issue found.
>>>
>>> Could you please do more test to see where the issue happen?
>>
>> The issue occurs 100% of the time on the failing board and always on the first
>> resume from suspend. Is there any more debug I can enable to track down
>> what the problem is?
>>
> 
> As commit messages described, the patch aims to re-init rx buffers address, since the address is not fixed, so I only can 
> recycle and then re-allocate all of them. The page pool is allocated once when open the net device.
> 
> Could you please debug if it fails at some functions, such as page_pool_dev_alloc_pages() ?


Yes that was the first thing I tried, but no obvious failures from
allocating the pools.

Are you certain that the problem you are seeing, that is being fixed by
this change, is generic to all devices? The commit message states that
'descriptor write back by DMA could exhibit unusual behavior', is this a
known issue in the STMMAC controller? If so does this impact all
versions and what is the actual problem?

Jon

-- 
nvpublic

  reply	other threads:[~2021-03-25  8:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 10:50 Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back Jon Hunter
2021-03-24 12:20 ` Joakim Zhang
2021-03-24 12:39   ` Jon Hunter
2021-03-25  7:53     ` Joakim Zhang
2021-03-25  8:00       ` Jon Hunter [this message]
2021-03-25  8:12         ` Joakim Zhang
2021-03-30 12:50           ` Jon Hunter
2021-03-31  7:43             ` Joakim Zhang
2021-03-31 11:10               ` Joakim Zhang
2021-03-31 11:29                 ` Jon Hunter
2021-03-31 11:41                   ` Joakim Zhang
2021-04-01 16:28                     ` Jon Hunter
2021-04-13  8:41                       ` Jon Hunter
2021-04-13 12:13                         ` Joakim Zhang
2021-04-13 16:06                           ` Thierry Reding
2021-04-13 16:43                             ` Jakub Kicinski
2021-04-14  2:18                             ` Joakim Zhang
2021-04-14  7:40                               ` Thierry Reding
2021-04-14  8:06                                 ` Joakim Zhang
2021-04-14 12:22                                   ` Joakim Zhang
2021-03-31 11:11               ` Jon Hunter

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=8e92b562-fa8f-0a2b-d8da-525ee52fc2d4@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=qiangqing.zhang@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.