[Bug 221065] ideapad_acpi: unexpected charge_types spam on Yoga Pro 7 14ASP9

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221065

--- Comment #83 from Rong Zhang (i@rong.moe) ---
(In reply to Rick from comment #82)
> (In reply to Rong Zhang from comment #81)
> 
> > Anyway, my suggestions on monitoring and testing should reveal more
> > information on this.
> 
> I do not have SSH setup at all and have never used remote SSH so that seemed
> like it was going to take more time to setup than I wanted to spend right
> now.  Sorry there was limited testing today and I don't think the below is
> going to add much - but here is what I did get done:
> 
> Using s-tui:
> 
> Running in a standard terminal window results in it's graphs stopping during
> the pause events but when it comes back it looks like the power usage was
> reduced during the event.  This does not seem surprising as the entire GUI
> stops updating.

Hmm, did it reduce by a little or a lot? And how about CPU frequencies?

> 
> Running in a virtual terminal (the ones built into Mint using ctrl-alt-F1
> for a terminal and ctrl-alt-F7 to return to the GUI) I did not see any
> variation whatsoever while watching it through enough time for an event to
> happen.  Power was lower than the test in a standard terminal window (I
> suspect because the GUI was not updating).  There were no pauses as you
> suspected.

Just for confirmation, did the "unexpected charge_types" appears when using VT?

> 
> Running in a virtual terminal and turning stress on I got the same results
> (I did not see any parameter substantially change when an event should have
> happened).

That sounds like your desktop environment was somehow blocked when it tried to
read charge_types synchronously, instead of CPU throttling.

GPU throttling may also lead to the same effects, which we can't rule out yet.
You can monitor GPU statistics with amdgpu_top's GUI, which provides graphs so
that you can check them after a pause.

> 
> > So I speculate that some userspace utilities (probably upower or the
> desktop
> > environment?) read charge_types regularly or upon power events. Before
> v6.17, 
> > ideapad-laptop didn't support it, so nothing could be read. However, since 
> > v6.17, they can actually read it, and reading it triggers ECMT chaos upon
> > power events.
> 
> This seems highly likely as there is a tray applet called Power Manager
> which shows battery and charging information.  I know in Mint Cinnamon the
> tray icons do their stuff in the same process as the UI (they warn that
> misbehaved applets can cause system pauses and lockups).  I think it uses
> upower to get it's info.
> Disabling these applets does not make the problem go completely away (upower
> is still running).

The weird part is that it freezes other applications. It may freeze the DE
itself (desktop, tray, etc), but it really shouldn't prevent other applications
from rendering. That's why more information is still helpful.

> 
> > Oh, that was when the charge_types attribute was added to ideapad-laptop.
> 
> This makes sense and ties into everything else - and explains the kernel
> versions and why disabling ideapad_laptop removes the pauses.

I guess I will send a patch disabling unreliable features due to the firmware
bug on corresponding devices.

> 
> At this point is there really value in me taking the time to get SSH working
> from  my phone to get the information on processes running or kernel
> information you mentioned above?  Let me know if this would provide value to
> you and I will see what I can do.

Yes, triggering magic sysrq to see stacktraces in dmesg during the pause event
is very helpful and reveals what's going on.

The key is that you should use your DE as normal but trigger magic sysrq
immediately when you see a pause. Control variates...

If you can't use remote SSH, you can trigger magic sysrq from keyboards
(Alt+SysRq+l and Alt+SysRq+w). Most laptop lacks a SysRq key so you may need a
USB keyboard instead. Don't forget to enable all magic sysrq actions from
keyboards by `sudo sysctl kernel.sysrq=1'. See
https://docs.kernel.org/admin-guide/sysrq.html for more details.

> 
> I would think running s-tui from the phone would be the same as running it
> in the virtual terminal (which didn't really show anything interesting
> happening).  Unless you think the pause events just don't happen while I am
> watching a virtual terminal?

You don't need to run s-tui from the phone as it's not freezed under DE. Your
post-event observations are sufficient for s-tui.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.