[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 #82 from Rick (rickk1166@gmail.com) ---
(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.

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.

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).

> 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).

> 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.

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.

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?

I am currently running with ideapad_laptop blocked and the system seems
functional - so my assumption is I have to wait for a BIOS update and try this
again to see if the BIOS is working correctly.  From previous discussions above
it did not sound like there were any really good other options to investigate.

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

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