Hi

On 1/4/22 12:48, Hans de Goede wrote:
> So I've written another patch, which I believe is something which we will want
> regardless of the question if we should mask interrupts at boot or not.
> 
> I've attached this patch here. Jarkko, can you test a linux-next kernel with
> just this patch added?
> 
> This should still lead to the "interrupt on unused interrupt line %u" message
> getting printed, but hopefully the system will actually boot despite this,
> since the code path printing the msg now acks the interrupt.
> 
> Thinking more about this I believe that this is likely the correct fix for
> the caused regression, because the spurious IRQ was always there already.
> 
> Fixing the spurious IRQ is still good to do but is a somewhat separate issue
> really.
> 
Unfortunately it doesn't fix:

[   13.060619] cherryview-pinctrl INT33FF:00: interrupt on unused 
interrupt line 0
[   13.068888] cherryview-pinctrl INT33FF:00: interrupt on unused 
interrupt line 0
[   13.077146] cherryview-pinctrl INT33FF:00: interrupt on unused 
interrupt line 0
[   13.085364] cherryview-pinctrl INT33FF:00: interrupt on unused 
interrupt line 0
...

I did dev_err_ratelimited() conversion to the error print together with 
your patch and that allowed to boot.

That gave me an idea to look at is there anything suspicious in "top" or 
/proc/interrupts (no and no) but powertop shows CPU 0 is over 90 % in C0 
state and max frequency.

But comparing powertop on v5.16-rc8 it does look sometimes the same and 
sometimes CPU 0 is less in C0 (but still over 30 %). Hard to say is 
there difference but obviously v5.16-rc8 either is not good on this 
machine since CPU 0 and package seems to reach idle only 5 % or less.

Jarkko