From: Jon Hunter <jonathanh@nvidia.com>
To: Trond Myklebust <trondmy@hammerspace.com>,
linux-tegra <linux-tegra@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION v5.3] SUNRPC: Replace the queue timer with a delayed work function (7e0a0e38fcfe)
Date: Tue, 5 Nov 2019 12:03:49 +0000 [thread overview]
Message-ID: <329228f8-e194-a021-9226-69a9b6a403ce@nvidia.com> (raw)
In-Reply-To: <271ff39f-1f44-b201-6274-85f1085bfc16@nvidia.com>
Hi Trond,
Any feedback on this?
Jon
On 25/10/2019 08:28, Jon Hunter wrote:
> Hi Trond,
>
> Similar to the change 431235818bc3 ("SUNRPC: Declare RPC timers as
> TIMER_DEFERRABLE") I have been tracking down another suspend/NFS related
> issue where again I am seeing random delays exiting suspend. The delays
> can be up to a couple minutes in the worst case and this is causing a
> suspend test we have to fail. For example, with this change I see ...
>
> [ 130.599520] PM: suspend entry (deep)
>
> [ 130.607267] Filesystems sync: 0.000 seconds
>
> [ 130.615800] Freezing user space processes ... (elapsed 0.001 seconds) done.
>
> [ 130.628247] OOM killer disabled.
>
> [ 130.635382] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>
> [ 130.648052] printk: Suspending console(s) (use no_console_suspend to debug)
>
> [ 130.686015] Disabling non-boot CPUs ...
>
> [ 130.689568] IRQ 17: no longer affine to CPU2
>
> [ 130.693435] Entering suspend state LP1
>
> [ 130.693489] Enabling non-boot CPUs ...
>
> [ 130.697108] CPU1 is up
>
> [ 130.700602] CPU2 is up
>
> [ 130.704338] CPU3 is up
>
> [ 130.781259] mmc1: queuing unknown CIS tuple 0x80 (50 bytes)
>
> [ 130.789742] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
>
> [ 130.792793] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
>
> [ 130.820913] mmc1: queuing unknown CIS tuple 0x02 (1 bytes)
>
> [ 131.345569] OOM killer enabled.
>
> [ 131.352643] Restarting tasks ... done.
>
> [ 131.365480] PM: suspend exit
>
> [ 134.524261] asix 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
>
> [ 243.745788] nfs: server 192.168.99.1 not responding, still trying
>
> [ 243.745811] nfs: server 192.168.99.1 not responding, still trying
>
> [ 243.767939] nfs: server 192.168.99.1 not responding, still trying
>
> [ 243.778233] nfs: server 192.168.99.1 OK
>
> [ 243.787058] nfs: server 192.168.99.1 OK
>
> [ 243.787542] nfs: server 192.168.99.1 OK
>
>
> Running a git bisect I was able to track it down to the commit referenced
> in the $subject. Reverting this on top of the current mainline fixes the
> problem and I no longer see these long delays.
>
> Cheers
> Jon
>
--
nvpublic
next prev parent reply other threads:[~2019-11-05 12:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 7:28 Jon Hunter
2019-11-05 12:03 ` Jon Hunter [this message]
2019-11-05 19:37 ` Trond Myklebust
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=329228f8-e194-a021-9226-69a9b6a403ce@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=trondmy@hammerspace.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
all inboxes | Powered by JetHome®