Re: Regression: mt7921e unable to change power state from d3cold to d0 - 6.12.x broken, past LTS 6.6.x works

[Sergio Callegari <sergio.callegari@gmail.com>]

Happened again, so I could make a test:

Kernel 6.9.12 does not have the issue. When the system comes up on 
kernel 6.12 and no wifi, no ability to change the power state, booting 
6.9.12 fixes the issue.

As the issue is fixed, the dmesg is interesting.

I have a long series of

mt7921e 0000:05:00.0: not ready <some time> after FLR; waiting

where <some time> is a time in ms that is progressively doubled, until:

[   57.726146] mt7921e 0000:05:00.0: not ready 32767ms after FLR; waiting
[   91.812263] mt7921e 0000:05:00.0: not ready 65535ms after FLR; giving up
[   91.955247] mt7921e 0000:05:00.0: enabling device (0000 -> 0002)

Next time it happens, I'll try to see what happens with one or more 
kernels between 6.9.12 and 6.12.

Thanks,
Sergio

On 30/03/2025 18:35, Sergio Callegari wrote:
> Hi Christian,
> 
> Thanks for your nice offer, details below:
> 
> On 20/03/2025 11:05, Christian Heusel wrote:
>> Hey Sergio,
>>
>> On 25/03/20 08:49AM, Sergio Callegari wrote:
>>> Might be able to test on the distro built kernels that basically 
>>> trace the
>>> releases and stable point releases. This should start helping 
>>> bracketing the
>>> problem a bit better as a starter. But it is going to take a lot of 
>>> time,
>>> since the issue happens when the machine fails to get out of 
>>> hibernation,
>>> that is not always, and obvioulsy I need to try avoiding this 
>>> situation as
>>> much as possible.
>>
>> Which linux distro are you using? If you're on Arch Linux I can provide
>> you with prebuilt images for the bisection :)
> 
> I am on manjaro, where the kernel follows slightly different naming 
> conventions, but the arch kernels should be OK. So thank you very much 
> for the nice offer. The thing is possibly a bit premature, in that I 
> would like to identify first what is the kernel RC or point release 
> where the issue started to appear, because I have these kernels 
> available for my distro which makes things easier. Unfortunately, I am 
> still in the dark even wrt this.
> 
> The issue is nasty, because it only happens when you crash on restore 
> from hibernation, which is something that I am desperately trying to 
> avoid because this is my work machine and I really don't want to risk 
> data loss.
> 
> The big problem with this bug is that you remain with the impression 
> that your hardware is bricked. On the web I read that booting windows 
> immediately gives you back the wifi device on pcie, but I really cannot 
> say, as I have no windows to try. What I can say is that the 6.6 LTS 
> kernel also lets you recover the WIFI, while 6.12 LTS does not.
> 
> As a stopgap, would be great to know if there is anything that can be 
> done while on 6.12 to fully reset the pcie (or the pcie device, I still 
> don't know what is the culprit), so you don't need to boot an older kernel.
> 
> Thanks again,
> Sergio
> 
>>
>>>
>>> Incidentally, the machine seems to hibernate-resume just fine. It is 
>>> when I
>>> suspend-then-hibernate that I get the failures.
>>>
>>> Before contacting the network driver authors, I just wanted to query 
>>> whether
>>> the issue is likely in it or in the power-management or pcie subsystems.
>>>
>>> Thanks,
>>> Sergio
>>
>> Cheers,
>> Chris
>>
>>>
>>> On 20/03/2025 00:54, Greg KH wrote:
>>>> On Wed, Mar 19, 2025 at 08:38:52PM +0100, Sergio Callegari wrote:
>>>>> There is a nasty regression wrt mt7921e in the last LTS series 
>>>>> (6.12). If
>>>>> your computer crashes or fails to get out of hibernation, then at 
>>>>> the next
>>>>> boot the mt7921e wifi does not work, with dmesg reporting that it 
>>>>> is unable
>>>>> to change power state from d3cold to d0.
>>>>>
>>>>> The issue is nasty, because rebooting won't help.
>>>>
>>>> Can you do a 'git bisect' to track down the issue?  Also, maybe letting
>>>> the network driver authors know about this would be good.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>>
>