Re: Crash on resume after suspend (5.17.5 and 5.15.36)

[Manuel Ullmann <labre@posteo.de>]

Holger Hoffstätte <holger@applied-asynchrony.com> writes:
> On 2022-05-04 21:25, Manuel Ullmann wrote:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.17.y&id=cbe6c3a8f8f4315b96e46e1a1c70393c06d95a4c
>> Yup, that’s my fault and I reproduced this myself yesterday. I actually
>> expected this to happen and attempted to test suspend with the patch,
>> but must have screwed up by kexec-rebooting into an unpatched kernel
>> version or something like that. I’ll disable the kexec service in the
>> future, if I ever need to prepare a patch again.
>>> 05:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02)
>> Yes, I have the same one.
>> 
>>> Please let me know if there is any more info I can give that will help.
>> Can you confirm, that hibernation works with the patch, but not without
>> it? The patch was an attempt to fix it, because I had the same behaviour
>
> Cannot test hibernation, but..

That’s unfortunate.

>> with hibernation. I tried to make sense of the deep parameter in
>> atl_resume_common pm function calls, but apparently it’s always required
>> to be true and thus obsolete.
>
> ..I patched 5.15.38 to pass true as deep arg everywhere, and now resume
> seems to work again reliably, 5 out of 5. \o/

Thanks for confirming that my patch should work. For some reason I had
the same idea. ;)

>> I’ll leave the cleanup of that parameter to the maintainers for mainline
>> and prepare a patch. Last time I sent it against mainline. If this fixup
>> of a stable patch regression should be posted differently, it would be
>> nice, if someone could give me a pointer.
>
> Send fix to mainline first, with Fixes: <mainline commit id> tag and
> Cc: stable mentioning the affected versions.
Thanks for the hint. I did that.

> cheers
> Holger