From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Jon Hunter <jonathanh@nvidia.com>,
Chuck Lever III <chuck.lever@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Neil Brown <neilb@suse.de>, linux-stable <stable@vger.kernel.org>,
"patches@lists.linux.dev" <patches@lists.linux.dev>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Guenter Roeck <linux@roeck-us.net>,
"shuah@kernel.org" <shuah@kernel.org>,
"patches@kernelci.org" <patches@kernelci.org>,
"lkft-triage@lists.linaro.org" <lkft-triage@lists.linaro.org>,
"pavel@denx.de" <pavel@denx.de>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"sudipm.mukherjee@gmail.com" <sudipm.mukherjee@gmail.com>,
"srw@sladewatkins.net" <srw@sladewatkins.net>,
"rwarsow@gmx.de" <rwarsow@gmx.de>,
"conor@kernel.org" <conor@kernel.org>,
"allen.lkml@gmail.com" <allen.lkml@gmail.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH 5.15 00/23] 5.15.160-rc1 review
Date: Tue, 28 May 2024 20:38:12 +0000 [thread overview]
Message-ID: <d5adc4a4-81b6-46f6-bcf6-7debf48d2bbf@alliedtelesis.co.nz> (raw)
In-Reply-To: <8b6fe99f-7fa9-493c-afe7-8e75b7f59852@nvidia.com>
On 29/05/24 02:18, Jon Hunter wrote:
>
> On 28/05/2024 14:14, Chuck Lever III wrote:
>>
>>
>>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>>
>>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>>>> Hi Greg,
>>>>>
>>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>>>> This is the start of the stable review cycle for the 5.15.160
>>>>>> release.
>>>>>> There are 23 patches in this series, all will be posted as a
>>>>>> response
>>>>>> to this one. If anyone has any issues with these being applied,
>>>>>> please
>>>>>> let me know.
>>>>>>
>>>>>> Responses should be made by Sat, 25 May 2024 13:03:15 +0000.
>>>>>> Anything received after that time might be too late.
>>>>>>
>>>>>> The whole patch series can be found in one patch at:
>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>>>>>
>>>>>> or in the git tree and branch at:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>>>>> linux-5.15.y
>>>>>> and the diffstat can be found below.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>>>
>>>>>> -------------
>>>>>> Pseudo-Shortlog of commits:
>>>>>
>>>>> ...
>>>>>
>>>>>> NeilBrown <neilb@suse.de>
>>>>>> nfsd: don't allow nfsd threads to be signalled.
>>>>>
>>>>>
>>>>> I am seeing a suspend regression on a couple boards and bisect is
>>>>> pointing
>>>>> to the above commit. Reverting this commit does fix the issue.
>>>> Ugh, that fixes the report from others. Can you cc: everyone on that
>>>> and figure out what is going on, as this keeps going back and forth...
>>>
>>>
>>> Adding Chuck, Neil and Chris from the bug report here [0].
>>>
>>> With the above applied to v5.15.y, I am seeing suspend on 2 of our
>>> boards fail. These boards are using NFS and on entry to suspend I am
>>> now seeing ...
>>>
>>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>>> freeze, wq_busy=0):
>>>
>>> The boards appear to hang at that point. So may be something else
>>> missing?
>>
>> Note that we don't have access to hardware like this, so
>> we haven't tested that patch (even the upstream version)
>> with suspend on that hardware.
>
>
> No problem, I would not expect you to have this particular hardware :-)
>
It's probably not much help but for the oops I originally reported we've
been carrying "nfsd: don't allow nfsd threads to be signalled" locally
and that resolved it. Now that we've updated to 5.15.160 and dropped the
local patch it's still resolved for us. Our systems don't make use of
suspend so they won't hit any issue related to that.
>> So, it could be something missing, or it could be that
>> patch has a problem.
>>
>> It would help us to know if you observe the same issue
>> with an upstream kernel, if that is possible.
>
>
> I don't observe this with either mainline, -next or any other stable
> branch. So that would suggest that something else is missing from
> linux-5.15.y.
>
> Jon
>
next prev parent reply other threads:[~2024-05-28 20:47 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 13:12 [PATCH 5.15 00/23] 5.15.160-rc1 review Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.15 01/23] drm/amd/display: Fix division by zero in setup_dsc_config Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.15 02/23] pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin() Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.15 03/23] nfsd: dont allow nfsd threads to be signalled Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 04/23] KEYS: trusted: Fix memory leak in tpm2_key_encode() Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 05/23] Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems" Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 06/23] net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 07/23] net: bcmgenet: synchronize UMAC_CMD access Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 08/23] tls: rx: simplify async wait Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 09/23] tls: extract context alloc/initialization out of tls_set_sw_offload Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 10/23] net: tls: factor out tls_*crypt_async_wait() Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 11/23] tls: fix race between async notify and socket close Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 12/23] net: tls: handle backlogging of crypto requests Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 13/23] netlink: annotate lockless accesses to nlk->max_recvmsg_len Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 14/23] netlink: annotate data-races around sk->sk_err Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 15/23] KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 16/23] drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 17/23] binder: fix max_thread type inconsistency Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 18/23] usb: typec: ucsi: displayport: Fix potential deadlock Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 19/23] serial: kgdboc: Fix NMI-safety problems from keyboard reset code Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 20/23] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 21/23] KEYS: trusted: Do not use WARN when encode fails Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 22/23] admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET Greg Kroah-Hartman
2024-05-23 13:13 ` [PATCH 5.15 23/23] docs: kernel_include.py: Cope with docutils 0.21 Greg Kroah-Hartman
2024-05-23 17:02 ` [PATCH 5.15 00/23] 5.15.160-rc1 review SeongJae Park
2024-05-23 18:20 ` Mark Brown
2024-05-23 18:50 ` Florian Fainelli
2024-05-24 6:54 ` Harshit Mogalapalli
2024-05-24 8:16 ` Anders Roxell
2024-05-24 14:36 ` Shuah Khan
2024-05-24 20:44 ` Ron Economos
2024-05-24 23:13 ` Jon Hunter
2024-05-25 14:20 ` Greg Kroah-Hartman
2024-05-28 9:04 ` Jon Hunter
2024-05-28 13:14 ` Chuck Lever III
2024-05-28 14:18 ` Jon Hunter
2024-05-28 20:38 ` Chris Packham [this message]
2024-05-28 20:55 ` Chuck Lever III
2024-05-28 22:01 ` NeilBrown
2024-05-28 23:33 ` Chuck Lever III
2024-05-28 23:44 ` NeilBrown
2024-05-29 0:13 ` Chuck Lever III
2024-05-28 23:42 ` NeilBrown
2024-05-29 8:59 ` Jon Hunter
2024-05-29 20:59 ` NeilBrown
2024-05-30 12:11 ` Jon Hunter
2024-06-06 14:32 ` Chuck Lever
2024-06-03 13:44 ` Chuck Lever III
2024-05-25 0:58 ` Kelsey Steele
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=d5adc4a4-81b6-46f6-bcf6-7debf48d2bbf@alliedtelesis.co.nz \
--to=chris.packham@alliedtelesis.co.nz \
--cc=akpm@linux-foundation.org \
--cc=allen.lkml@gmail.com \
--cc=broonie@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=conor@kernel.org \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkft-triage@lists.linaro.org \
--cc=neilb@suse.de \
--cc=patches@kernelci.org \
--cc=patches@lists.linux.dev \
--cc=pavel@denx.de \
--cc=rwarsow@gmx.de \
--cc=shuah@kernel.org \
--cc=srw@sladewatkins.net \
--cc=stable@vger.kernel.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=torvalds@linux-foundation.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).