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

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

[bugzilla-daemon]

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

            Bug ID: 221065
           Summary: ideapad_acpi: unexpected charge_types spam on Yoga Pro
                    7 14ASP9
           Product: Drivers
           Version: 2.5
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: low
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: rbitton@linux.com
        Regression: No

Hi,

I'm experiencing constant dmesg spam from ideapad_acpi on my Lenovo Yoga Pro 7
14ASP9:

[  733.997072] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast]
and [Long_Life] are enabled

This started on 6.19.0 on both my distro's mainline kernel and the vanilla
mainline kernel I compiled. The issue is not present in 6.18. It happens about
every minute starting about a minute after boot regardless of if I'm charging
or not.

Model: Lenovo Yoga Pro 7 14ASP9 (83HN)
CPU: AMD Ryzen AI 9 365
BIOS: PSCN17WW (up to date)

The laptop appears to be reporting both Fast and Long_Life charge modes
simultaneously, which the driver considers unexpected. Functionally everything
works fine, including fast charging, but the log spam is excessive.

Of note:
zsh rbitton@rbitton-linux3 01:46 /sys/class/power_supply/BAT0 > cat
/sys/class/power_supply/BAT*/charge_types    
[Fast] Standard Long_Life

All attempts to fix it on my end have failed.Let me know if you need any
additional information; I would be more than willing to test any fixes.

Thanks,
Raphael Bitton

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

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

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

[bugzilla-daemon]

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

Raphael Bitton (rbitton@linux.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Regression|No                          |Yes

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

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

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

[bugzilla-daemon]

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

Armin Wolf (W_Armin@gmx.de) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |W_Armin@gmx.de

--- Comment #1 from Armin Wolf (W_Armin@gmx.de) ---
Can you share the output of "acpidump"?

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

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

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

[Rong Zhang]

Hi Raphael,

On Mon, 2026-02-09 at 07:50 +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221065
> 
>             Bug ID: 221065
>            Summary: ideapad_acpi: unexpected charge_types spam on Yoga Pro
>                     7 14ASP9
>            Product: Drivers
>            Version: 2.5
>           Hardware: AMD
>                 OS: Linux
>             Status: NEW
>           Severity: low
>           Priority: P3
>          Component: Platform_x86
>           Assignee: drivers_platform_x86@kernel-bugs.osdl.org
>           Reporter: rbitton@linux.com
>         Regression: No
> 
> Hi,
> 
> I'm experiencing constant dmesg spam from ideapad_acpi on my Lenovo Yoga Pro 7
> 14ASP9:
> 
> [  733.997072] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast]
> and [Long_Life] are enabled

Please attach the full dmesg log along with the acpidump of your
device.

This error log is intended to remind users to write either Fast or
Long_Life to charge_types to break the dilemma. Could you check
/sys/kernel/debug/ideapad/status before and after writing into
charge_types?

> This started on 6.19.0 on both my distro's mainline kernel and the vanilla
> mainline kernel I compiled. The issue is not present in 6.18. It happens about
> every minute starting about a minute after boot regardless of if I'm charging
> or not.

In your case there was a userspace process reading charge_types every
minute and triggering the error log.

What process was it? Could you check with

   sudo perf --no-pager ftrace -T ideapad_psy_ext_get_prop

to see its pid and find out what it is?

> Model: Lenovo Yoga Pro 7 14ASP9 (83HN)
> CPU: AMD Ryzen AI 9 365
> BIOS: PSCN17WW (up to date)
> 
> The laptop appears to be reporting both Fast and Long_Life charge modes
> simultaneously, which the driver considers unexpected. Functionally everything
> works fine, including fast charging, but the log spam is excessive.

Did it stop charging at 60%/80%? That's what I got (i.e., both fast
charging and charge threshold) when I manually put my device into such
a state.

> Of note:
> zsh rbitton@rbitton-linux3 01:46 /sys/class/power_supply/BAT0 > cat
> /sys/class/power_supply/BAT*/charge_types    
> [Fast] Standard Long_Life

Wait, I don't understand how this could happen. Reading charge_types
should have failed with -EINVAL when it ran into the error path. In
other words, you have already got out of the dilemma when reading
charge_types returns successfully. So at least it temporarily recovered
to an expected state when you read charge_types, but was somehow broken
by other things afterward...

Could you check `sudo lsmod | grep acpi_call'? Did you ever set up
anything abusing acpi_call?

> All attempts to fix it on my end have failed.Let me know if you need any
> additional information; I would be more than willing to test any fixes.

Could you try booting into a livecd (or a fresh installation) of your
distro with 6.19 kernel and monitoring any upcoming kmsg with `sudo
dmesg -w', then:

1. read charge_types
2. write Fast into charge_types
   a. read charge_types
   b. unplug and replug AC power
   c. read charge_types
   d. wait several minutes
   e. read charge_types
3. write Standard into charge_types
   repeat a-e
4. write Long_Life into charge_types
   repeat a-e

And attach your observation in reply.

If the issue persist in fresh installation/livecd, the firmware on your
device may have its own thoughts (?!) and messes up charge modes on its
own.

Thanks,
Rong

> Thanks,
> Raphael Bitton

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

[bugzilla-daemon]

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

--- Comment #2 from Rong Zhang (i@rong.moe) ---
Hi Raphael,

On Mon, 2026-02-09 at 07:50 +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221065
> 
>             Bug ID: 221065
>            Summary: ideapad_acpi: unexpected charge_types spam on Yoga Pro
>                     7 14ASP9
>            Product: Drivers
>            Version: 2.5
>           Hardware: AMD
>                 OS: Linux
>             Status: NEW
>           Severity: low
>           Priority: P3
>          Component: Platform_x86
>           Assignee: drivers_platform_x86@kernel-bugs.osdl.org
>           Reporter: rbitton@linux.com
>         Regression: No
> 
> Hi,
> 
> I'm experiencing constant dmesg spam from ideapad_acpi on my Lenovo Yoga Pro
> 7
> 14ASP9:
> 
> [  733.997072] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast]
> and [Long_Life] are enabled

Please attach the full dmesg log along with the acpidump of your
device.

This error log is intended to remind users to write either Fast or
Long_Life to charge_types to break the dilemma. Could you check
/sys/kernel/debug/ideapad/status before and after writing into
charge_types?

> This started on 6.19.0 on both my distro's mainline kernel and the vanilla
> mainline kernel I compiled. The issue is not present in 6.18. It happens
> about
> every minute starting about a minute after boot regardless of if I'm charging
> or not.

In your case there was a userspace process reading charge_types every
minute and triggering the error log.

What process was it? Could you check with

   sudo perf --no-pager ftrace -T ideapad_psy_ext_get_prop

to see its pid and find out what it is?

> Model: Lenovo Yoga Pro 7 14ASP9 (83HN)
> CPU: AMD Ryzen AI 9 365
> BIOS: PSCN17WW (up to date)
> 
> The laptop appears to be reporting both Fast and Long_Life charge modes
> simultaneously, which the driver considers unexpected. Functionally
> everything
> works fine, including fast charging, but the log spam is excessive.

Did it stop charging at 60%/80%? That's what I got (i.e., both fast
charging and charge threshold) when I manually put my device into such
a state.

> Of note:
> zsh rbitton@rbitton-linux3 01:46 /sys/class/power_supply/BAT0 > cat
> /sys/class/power_supply/BAT*/charge_types    
> [Fast] Standard Long_Life

Wait, I don't understand how this could happen. Reading charge_types
should have failed with -EINVAL when it ran into the error path. In
other words, you have already got out of the dilemma when reading
charge_types returns successfully. So at least it temporarily recovered
to an expected state when you read charge_types, but was somehow broken
by other things afterward...

Could you check `sudo lsmod | grep acpi_call'? Did you ever set up
anything abusing acpi_call?

> All attempts to fix it on my end have failed.Let me know if you need any
> additional information; I would be more than willing to test any fixes.

Could you try booting into a livecd (or a fresh installation) of your
distro with 6.19 kernel and monitoring any upcoming kmsg with `sudo
dmesg -w', then:

1. read charge_types
2. write Fast into charge_types
   a. read charge_types
   b. unplug and replug AC power
   c. read charge_types
   d. wait several minutes
   e. read charge_types
3. write Standard into charge_types
   repeat a-e
4. write Long_Life into charge_types
   repeat a-e

And attach your observation in reply.

If the issue persist in fresh installation/livecd, the firmware on your
device may have its own thoughts (?!) and messes up charge modes on its
own.

Thanks,
Rong

> Thanks,
> Raphael Bitton

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

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

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

[bugzilla-daemon]

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

Avraham Hollander (anhollander516@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anhollander516@gmail.com

--- Comment #3 from Avraham Hollander (anhollander516@gmail.com) ---
I'm also seeing this on an IdeaPad 5 2-in-1 14AHP9 (83DR),  after upgrading to
Linux 6.19.

I'll attached dmesg and acpidump, but this is not a vanilla kernel, so take it
with a grain of salt. This kernel doesn't have debugfs, so I can't provide
that.

/sys/class/power_supply/BAT0/charge_types is [Fast] Standard Long_Life.

/sys/bus/platform/drivers/ideapad_acpi/VPC2004:00/conservation_mode is 0.

I'm using the BIOS default charging configuration and haven't set up any weird
ACPI stuff, afaik.

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

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

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

[Rong Zhang]

Hi Avraham,

On Tue, 2026-02-10 at 17:56 +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221065
> 
> Avraham Hollander (anhollander516@gmail.com) changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |anhollander516@gmail.com
> 
> --- Comment #3 from Avraham Hollander (anhollander516@gmail.com) ---
> I'm also seeing this on an IdeaPad 5 2-in-1 14AHP9 (83DR),  after upgrading to
> Linux 6.19.
> 
> I'll attached dmesg and acpidump, but this is not a vanilla kernel, so take it
> with a grain of salt. This kernel doesn't have debugfs, so I can't provide
> that.

Thanks for your dmesg and acpidump. I will find some time looking into
them.

As for debugfs, every major distribution have it enabled [1] and so do
any sane downstream kernel. debugfs can only be accessed by the root
user by default. Did you try with the root user (e.g., `sudo -i')?

[1]: https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DEBUG_FS

And since you are using a downstream kernel, could you provide a link
to its website or so? So that I can check if it's the root cause
(though unlikely).

> /sys/class/power_supply/BAT0/charge_types is [Fast] Standard Long_Life.
> 
> /sys/bus/platform/drivers/ideapad_acpi/VPC2004:00/conservation_mode is 0.
> 
> I'm using the BIOS default charging configuration and haven't set up any weird
> ACPI stuff, afaik.

Thanks,
Rong

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

[bugzilla-daemon]

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

--- Comment #4 from Avraham Hollander (anhollander516@gmail.com) ---
Created attachment 309340
  --> https://bugzilla.kernel.org/attachment.cgi?id=309340&action=edit
acpidump from IdeaPad 5 2-in-1 14AHP9 (83DR)

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

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

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

[bugzilla-daemon]

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

--- Comment #5 from Avraham Hollander (anhollander516@gmail.com) ---
Created attachment 309341
  --> https://bugzilla.kernel.org/attachment.cgi?id=309341&action=edit
dmesg from acpidump from IdeaPad 5 2-in-1 14AHP9 (83DR), but not vanilla kernel

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

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

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

[bugzilla-daemon]

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

--- Comment #6 from Rong Zhang (i@rong.moe) ---
Hi Avraham,

On Tue, 2026-02-10 at 17:56 +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221065
> 
> Avraham Hollander (anhollander516@gmail.com) changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |anhollander516@gmail.com
> 
> --- Comment #3 from Avraham Hollander (anhollander516@gmail.com) ---
> I'm also seeing this on an IdeaPad 5 2-in-1 14AHP9 (83DR),  after upgrading
> to
> Linux 6.19.
> 
> I'll attached dmesg and acpidump, but this is not a vanilla kernel, so take
> it
> with a grain of salt. This kernel doesn't have debugfs, so I can't provide
> that.

Thanks for your dmesg and acpidump. I will find some time looking into
them.

As for debugfs, every major distribution have it enabled [1] and so do
any sane downstream kernel. debugfs can only be accessed by the root
user by default. Did you try with the root user (e.g., `sudo -i')?

[1]: https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DEBUG_FS

And since you are using a downstream kernel, could you provide a link
to its website or so? So that I can check if it's the root cause
(though unlikely).

> /sys/class/power_supply/BAT0/charge_types is [Fast] Standard Long_Life.
> 
> /sys/bus/platform/drivers/ideapad_acpi/VPC2004:00/conservation_mode is 0.
> 
> I'm using the BIOS default charging configuration and haven't set up any
> weird
> ACPI stuff, afaik.

Thanks,
Rong

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

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

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

[bugzilla-daemon]

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

--- Comment #7 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #6)
> Hi Avraham,
> 
> On Tue, 2026-02-10 at 17:56 +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=221065
> > 
> > Avraham Hollander (anhollander516@gmail.com) changed:
> > 
> >            What    |Removed                     |Added
> >
> ----------------------------------------------------------------------------
> >                  CC|                            |anhollander516@gmail.com
> > 
> > --- Comment #3 from Avraham Hollander (anhollander516@gmail.com) ---
> > I'm also seeing this on an IdeaPad 5 2-in-1 14AHP9 (83DR),  after upgrading
> > to
> > Linux 6.19.
> > 
> > I'll attached dmesg and acpidump, but this is not a vanilla kernel, so take
> > it
> > with a grain of salt. This kernel doesn't have debugfs, so I can't provide
> > that.
> 
> Thanks for your dmesg and acpidump. I will find some time looking into
> them.
> 
> As for debugfs, every major distribution have it enabled [1] and so do
> any sane downstream kernel. debugfs can only be accessed by the root
> user by default. Did you try with the root user (e.g., `sudo -i')?
> 
> [1]: https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DEBUG_FS
> 
> And since you are using a downstream kernel, could you provide a link
> to its website or so? So that I can check if it's the root cause
> (though unlikely).
> 
> > /sys/class/power_supply/BAT0/charge_types is [Fast] Standard Long_Life.
> > 
> > /sys/bus/platform/drivers/ideapad_acpi/VPC2004:00/conservation_mode is 0.
> > 
> > I'm using the BIOS default charging configuration and haven't set up any
> > weird
> > ACPI stuff, afaik.
> 
> Thanks,
> Rong

I build my own kernel with a selection of out-of-tree patches
(https://github.com/Frogging-Family/linux-tkg) and a heavily tuned
configuration, which indeed doesn't have debugfs. I don't mind building a
vanilla kernel with debugfs; I have just been using my laptop and haven't had
the time too. Probably later today.

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

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

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

[bugzilla-daemon]

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

--- Comment #8 from Avraham Hollander (anhollander516@gmail.com) ---
Created attachment 309342
  --> https://bugzilla.kernel.org/attachment.cgi?id=309342&action=edit
linux-tkg customization.cfg

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

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

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

[bugzilla-daemon]

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

--- Comment #9 from Avraham Hollander (anhollander516@gmail.com) ---
Created attachment 309343
  --> https://bugzilla.kernel.org/attachment.cgi?id=309343&action=edit
Linux kernel configuration

This will probably only boot on an IdeaPad 5 2-in-1 14AHP9 (83DR), or similar
hardware. It also makes the assumption of a single-partition BTRFS root
filesystem with no initramfs. It also only has iwlwifi for a wireless driver.

Rather than using linux-tkg's install.sh to compile the kernel, I call
"install.sh config" and then run "LLVM=1 make -j16". This is because even with
the provided custom kernel config, some options are still overridden by the
configuration scripts, and I don't want that.

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

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

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

[bugzilla-daemon]

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

--- Comment #10 from Avraham Hollander (anhollander516@gmail.com) ---
Ok compiling a vanilla kernel with debugfs only took a couple minutes.

/sys/kernel/debug/ideapad/status before changing the setting:
Backlight max:  16
Backlight now:  0
BL power value: off (0)
=====================
Radio status: off (0)
Wifi status:  off (0)
BT status:    off (0)
3G status:    off (0)
=====================
Touchpad status: on (1)
Camera status:   on (1)
=====================
GBMD: 0x00860004
HALS: 0x0000ca40

After writing "Fast" it took a few seconds to output the same:
Backlight max:  16
Backlight now:  0
BL power value: off (0)
=====================
Radio status: off (0)
Wifi status:  off (0)
BT status:    off (0)
3G status:    off (0)
=====================
Touchpad status: on (1)
Camera status:   on (1)
=====================
GBMD: 0x00860004
HALS: 0x0000ca40

After writing "Standard" it took a few seconds to output the same:
Backlight max:  16
Backlight now:  0
BL power value: off (0)
=====================
Radio status: off (0)
Wifi status:  off (0)
BT status:    off (0)
3G status:    off (0)
=====================
Touchpad status: on (1)
Camera status:   on (1)
=====================
GBMD: 0x00860000
HALS: 0x0000ca40

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

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

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

[bugzilla-daemon]

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

--- Comment #11 from Avraham Hollander (anhollander516@gmail.com) ---
It seems also that after writing something to charge_types, the ucsi-acpi
driver complains too, along with an ACPI error whenever the charger is plugged
in:

ACPI Error: Thread 2157330176 cannot release Mutex [ECMT] acquired by thread
2188863744 (20250807/exmutex-378)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-531)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.RPAM due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-531)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q92 due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-531)
ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and [Long_Life]
are enabled
ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed
(-5)
ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed
(-5)
ucsi_acpi USBC000:00: GET_CONNECTOR_STATUS failed (-5)
ACPI Error: Thread 2156041472 cannot release Mutex [ECMT] acquired by thread
2188863744 (20250807/exmutex-378)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-531)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.RPAM due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-531)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q9E due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-531)
ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and [Long_Life]
are enabled
ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed
(-110)
ucsi_acpi USBC000:00: ucsi_handle_connector_change entered without
EVENT_PENDING
ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed
(-110)


The ideapad_acpi driver's behavior doesn't seem to be affected by plugging in
or unplugging the charger.

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

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

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

[bugzilla-daemon]

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

--- Comment #12 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Avraham Hollander from comment #11)
> It seems also that after writing something to charge_types, the ucsi-acpi
> driver complains too, along with an ACPI error whenever the charger is
> plugged in:
> 
> ACPI Error: Thread 2157330176 cannot release Mutex [ECMT] acquired by thread
> 2188863744 (20250807/exmutex-378)
> ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
> (AE_AML_NOT_OWNER) (20250807/psparse-531)
> ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.RPAM due to previous error
> (AE_AML_NOT_OWNER) (20250807/psparse-531)
> ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q92 due to previous error
> (AE_AML_NOT_OWNER) (20250807/psparse-531)
> ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and
> [Long_Life] are enabled
> ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS
> failed (-5)
> ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS
> failed (-5)
> ucsi_acpi USBC000:00: GET_CONNECTOR_STATUS failed (-5)
> ACPI Error: Thread 2156041472 cannot release Mutex [ECMT] acquired by thread
> 2188863744 (20250807/exmutex-378)
> ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
> (AE_AML_NOT_OWNER) (20250807/psparse-531)
> ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.RPAM due to previous error
> (AE_AML_NOT_OWNER) (20250807/psparse-531)
> ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q9E due to previous error
> (AE_AML_NOT_OWNER) (20250807/psparse-531)
> ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and
> [Long_Life] are enabled
> ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS
> failed (-110)
> ucsi_acpi USBC000:00: ucsi_handle_connector_change entered without
> EVENT_PENDING
> ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS
> failed (-110)
> 
> 
> The ideapad_acpi driver's behavior doesn't seem to be affected by plugging
> in or unplugging the charger.

Actually, I take that back. All of this is triggerable without writing to
charge_types.

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

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

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

[bugzilla-daemon]

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

--- Comment #13 from Avraham Hollander (anhollander516@gmail.com) ---
Ok, I am 100% sure now that writing an appropriate value to charge_types
doesn't stop the driver from complaining when charge_types is read.

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

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

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

[bugzilla-daemon]

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

--- Comment #14 from Armin Wolf (W_Armin@gmx.de) ---
I think that the ACPI errors you shown us are somehow connected to this
problem, which has something to do with a shared memory area called SMA2 is
protected by the ECMT mutex

Both the usci driver and ideapad_acpi call ACPI methods that want to access
SMA2 and thus attempt to acquire the ECMT mutex. usci times out after ~2
seconds when attempting to acquire said mutex, but tries to release it anyway
due to a firmware bug, leading to the above errors. ideapad_laptop also likely
times out when acquiring the mutex, returning a bitmask with all bits set as a
result. ideapad_laptop now sees that all bits are set at the same time and
rightfully complains

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

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

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

[bugzilla-daemon]

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

--- Comment #15 from Armin Wolf (W_Armin@gmx.de) ---
Please check what kind of device is mapped at 0xFEEC2A00 using /proc/iomem
(needs root privileges). Also, can you check if the thread number that is
holding the ECMT mutex is always the same? In the ACPI error message you shared
above, the thread number is 2188863744.

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

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

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

[bugzilla-daemon]

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

--- Comment #16 from Armin Wolf (W_Armin@gmx.de) ---
Also, do receive a notification when pluggin in your charger? If yes, how long
does it take for said notification to arrive?

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

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

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

[bugzilla-daemon]

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

--- Comment #17 from Armin Wolf (W_Armin@gmx.de) ---
Also, can you read your current battery status successfully?

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

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

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

[bugzilla-daemon]

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

--- Comment #18 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Armin Wolf from comment #15)
> Please check what kind of device is mapped at 0xFEEC2A00 using /proc/iomem
> (needs root privileges). Also, can you check if the thread number that is
> holding the ECMT mutex is always the same? In the ACPI error message you
> shared above, the thread number is 2188863744.

Pretty sure nothing is mapped there at all. It jumps straight from fee00fff to
ff000000:
00000000-00000fff : Reserved
00001000-0009ffff : System RAM
000a0000-000effff : PCI Bus 0000:00
000f0000-000fffff : System ROM
00100000-09bfffff : System RAM
09c00000-09e00fff : Reserved
09e01000-09efffff : System RAM
09f00000-09f3bfff : ACPI Non-volatile Storage
09f3c000-2f232fff : System RAM
2f233000-30a32fff : ACPI Non-volatile Storage
  30a1a000-30a1afff : USBC000:00
30a33000-30ab2fff : ACPI Tables
30ab3000-342b2fff : Reserved
  31a00000-31a1ffff : amd_sfh
342b3000-72916fff : System RAM
72917000-72917fff : Reserved
72918000-76afdfff : System RAM
76afe000-7a9fdfff : Reserved
7a9fe000-7bfe8fff : System RAM
7bfe9000-7bfecfff : Reserved
7bfed000-7bfeefff : System RAM
7bfef000-7cffffff : Reserved
7d790000-7d7effff : Reserved
7d7f5000-7fffffff : Reserved
80000000-dfffffff : PCI Bus 0000:00
  80000000-806fffff : PCI Bus 0000:04
    80000000-801fffff : 0000:04:00.0
    80200000-802fffff : 0000:04:00.3
      80200000-802fffff : xhci-hcd
    80300000-803fffff : 0000:04:00.4
      80300000-803fffff : xhci-hcd
    80400000-804fffff : 0000:04:00.7
      80400000-804fffff : pcie_mp2_amd
    80500000-805fffff : 0000:04:00.2
      80500000-805fffff : ccp
    80600000-8067ffff : 0000:04:00.0
    80680000-806bffff : 0000:04:00.5
      80680000-806bffff : AMD ACP6.2 audio
        80680000-8069c000 : acp_ps_pdm_dma.0
    806c0000-806c7fff : 0000:04:00.6
      806c0000-806c7fff : ICH HD audio
    806c8000-806cbfff : 0000:04:00.1
      806c8000-806cbfff : ICH HD audio
    806cc000-806cdfff : 0000:04:00.7
    806ce000-806cffff : 0000:04:00.2
      806ce000-806cffff : ccp
  80700000-808fffff : PCI Bus 0000:06
    80700000-807fffff : 0000:06:00.3
      80700000-807fffff : xhci-hcd
    80800000-808fffff : 0000:06:00.4
      80800000-808fffff : xhci-hcd
  80900000-809fffff : PCI Bus 0000:05
    80900000-8097ffff : 0000:05:00.1
    80980000-809bffff : 0000:05:00.1
    809c0000-809c1fff : 0000:05:00.1
  80a00000-80afffff : PCI Bus 0000:03
    80a00000-80a03fff : 0000:03:00.0
      80a00000-80a03fff : nvme
  80b00000-80bfffff : PCI Bus 0000:02
    80b00000-80b03fff : 0000:02:00.0
      80b00000-80b03fff : iwlwifi
  80c00000-80cfffff : PCI Bus 0000:01
    80c00000-80c00fff : 0000:01:00.0
      80c00000-80c00fff : rtsx_pci
e0000000-efffffff : Reserved
  e0000000-efffffff : pnp 00:00
f0000000-fdbfffff : PCI Bus 0000:00
fe100000-fe100fff : MSFT0101:00
  fe100040-fe10006f : MSFT0101:00
  fe100080-fe100fff : MSFT0101:00
fe108000-fe108003 : MSFT0101:00
fe108028-fe10802b : MSFT0101:00
fec00000-fec003ff : IOAPIC 0
fec01000-fec013ff : IOAPIC 1
fed00000-fed003ff : HPET 2
  fed00000-fed003ff : PNP0103:00
fed80000-fed80fff : Reserved
fed81500-fed818ff : AMDI0030:00
  fed81500-fed818ff : AMDI0030:00 AMDI0030:00
fedc2000-fedc2fff : AMDI0010:00
  fedc2000-fedc2fff : AMDI0010:00 AMDI0010:00
fedc4000-fedc4fff : AMDI0010:02
  fedc4000-fedc4fff : AMDI0010:02 AMDI0010:02
fee00000-fee00fff : pnp 00:00
ff000000-ffffffff : pnp 00:03
100000000-45e2fffff : System RAM
  1a1000000-1a1c1b31f : Kernel code
  1a1e00000-1a20d6fff : Kernel rodata
  1a2200000-1a22dffff : Kernel data
  1a27d1000-1a29fffff : Kernel bss
45e300000-45f33ffff : RAM buffer
45f340000-47fffffff : Reserved
4a0200000-7f3fffffff : PCI Bus 0000:00
  4a0200000-4a03fffff : PCI Bus 0000:01
  4b0000000-4c07fffff : PCI Bus 0000:04
    4b0000000-4bfffffff : 0000:04:00.0
    4c0000000-4c07fffff : 0000:04:00.5
      4c0000000-4c07fffff : AMD ACP6.2 audio
  4c0800000-4c08fffff : PCI Bus 0000:05
    4c0800000-4c083ffff : 0000:05:00.1

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

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

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

[bugzilla-daemon]

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

--- Comment #19 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Armin Wolf from comment #16)
> Also, do receive a notification when pluggin in your charger? If yes, how
> long does it take for said notification to arrive?

Usually it only takes a second, but sometimes it takes a little longer. Often
times when unplugging the charger too. It took around 6 seconds when the errors
showed up just now.

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

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

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

[bugzilla-daemon]

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

--- Comment #20 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Armin Wolf from comment #17)
> Also, can you read your current battery status successfully?

Yes, battery and charger reporting works just fine, other than it sometimes
taking a little longer to detect a change in charger state.

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

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

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

[bugzilla-daemon]

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

--- Comment #21 from Armin Wolf (W_Armin@gmx.de) ---
(In reply to Avraham Hollander from comment #19)
> (In reply to Armin Wolf from comment #16)
> > Also, do receive a notification when pluggin in your charger? If yes, how
> > long does it take for said notification to arrive?
> 
> Usually it only takes a second, but sometimes it takes a little longer.
> Often times when unplugging the charger too. It took around 6 seconds when
> the errors showed up just now.

Interesting, the ECMT mutex is also acquired when sending those notifications
to the charger and the battery. Maybe they somehow take too long to process
said notification?

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

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

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

[bugzilla-daemon]

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

Rong Zhang (i@rong.moe) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i@rong.moe,
                   |                            |mpearson-lenovo@squebb.ca

--- Comment #22 from Rong Zhang (i@rong.moe) ---
+CC Mark Pearson.

Thanks for Armin's insight!

Yeah, the root cause should lie in the ACPI table. It's super broken as I even
found more ECMT issues...

I've noticed these methods are broken while glancing at all occurrences of ECMT
in DSDT: WTER, ECCC, _BTP.

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

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

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

[bugzilla-daemon]

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

--- Comment #23 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #22)
> +CC Mark Pearson.
> 
> Thanks for Armin's insight!
> 
> Yeah, the root cause should lie in the ACPI table. It's super broken as I
> even found more ECMT issues...
> 
> I've noticed these methods are broken while glancing at all occurrences of
> ECMT in DSDT: WTER, ECCC, _BTP.

Speaking of firmware-related issues, TSC is broken on my laptop, causing
reliance on HPET as clocksource and increased scheduling latency. Unless I have
no idea what I'm talking about, I think it's a BIOS issue as well. I made a
post on the Lenovo Linux forum about it that I'll post here for visibility:
https://forums.lenovo.com/t5/Other-Linux-Discussions/1-second-TSC-warp-on-IdeaPad-5-2-in-1-14AHP9-due-to-bad-initialization-in-BIOS-forces-HPET-fallback/m-p/10021248

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

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

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

[bugzilla-daemon]

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

--- Comment #24 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #22)
> +CC Mark Pearson.
> 
> Thanks for Armin's insight!
> 
> Yeah, the root cause should lie in the ACPI table. It's super broken as I
> even found more ECMT issues...
> 
> I've noticed these methods are broken while glancing at all occurrences of
> ECMT in DSDT: WTER, ECCC, _BTP.

Raphael Bitton can you post your acpidump as well? You have a different model
laptop, it would help to show that they both have the same ACPI table problems.

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

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

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

[bugzilla-daemon]

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

--- Comment #25 from Rong Zhang (i@rong.moe) ---
Created attachment 309348
  --> https://bugzilla.kernel.org/attachment.cgi?id=309348&action=edit
workaround for the FW bug

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

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

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

[bugzilla-daemon]

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

--- Comment #26 from Rong Zhang (i@rong.moe) ---
Avraham, could you test if the patch fixes the issue?

It's just a PoC as I haven't seen Raphael's acpidump so IDK if it works on
their device.

Mark, could you check the documentation of the GBMD interface? Will its return
value have any byte being 0xFF under normal circumstances? If not, I think the
workaround can be applied unconditionally without a DMI quirk. Also the issue
should really be fixed from the FW side. Could you coordinate with the FW team
about this?

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

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

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

[bugzilla-daemon]

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

--- Comment #27 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #26)
> Avraham, could you test if the patch fixes the issue?
> 
> It's just a PoC as I haven't seen Raphael's acpidump so IDK if it works on
> their device.
> 
> Mark, could you check the documentation of the GBMD interface? Will its
> return value have any byte being 0xFF under normal circumstances? If not, I
> think the workaround can be applied unconditionally without a DMI quirk.
> Also the issue should really be fixed from the FW side. Could you coordinate
> with the FW team about this?

It did not. Unplugging and replugging the charger a bunch of times results in:

ACPI Error: Thread 386093824 cannot release Mutex [ECMT] acquired by thread
32582016 (20250807/exmutex-378)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.RPAM due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q93 due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-529)
power_supply BAT0: driver failed to report `charge_types' property: -5
power_supply BAT0: driver failed to report `charge_types' property: -5
ACPI Error: Thread 348558528 cannot release Mutex [ECMT] acquired by thread
350311168 (20250807/exmutex-378)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-529)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.VPC0.DYTC due to previous error
(AE_AML_NOT_OWNER) (20250807/psparse-529)
ucsi_acpi USBC000:00: GET_CONNECTOR_STATUS failed (-110)
power_supply BAT0: driver failed to report `charge_types' property: -5
power_supply BAT0: driver failed to report `charge_types' property: -5
ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed
(-5)
ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed
(-5)
ucsi_acpi USBC000:00: GET_CONNECTOR_STATUS failed (-5)

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

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

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

[bugzilla-daemon]

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

--- Comment #28 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #22)
> +CC Mark Pearson.
> 
> Thanks for Armin's insight!
> 
> Yeah, the root cause should lie in the ACPI table. It's super broken as I
> even found more ECMT issues...
> 
> I've noticed these methods are broken while glancing at all occurrences of
> ECMT in DSDT: WTER, ECCC, _BTP.

Is there anything you notice in there that could potentially cause the system
to take excessively long (2-6 seconds) to resume from s2idle? That's another
probably ACPI issue that I've always had. This is almost certainly unrelated to
the charger bug and I don't want to go completely off topic, but I figure it's
worth mentioning now that I have contact with the relevant people.

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

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

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

[bugzilla-daemon]

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

--- Comment #29 from Rong Zhang (i@rong.moe) ---
(In reply to Avraham Hollander from comment #27)

Thanks for your test.

> It did not. Unplugging and replugging the charger a bunch of times results
> in:
> [...]

Ahh, my fault. I meant fixing the issue that ideapad-laptop misinterprets the
error returned by the GBMD method as a valid return value. According to your
log, the patch seems correct.

As for the issue of the mutex chaos (and hence the error logs you got), we
can't really fix it from the kernel side. It can only be fixed by a BIOS
update. That's why I added Mark to the CC list.

I've seen GBMD, SALS, SBMC, and DYTC calling ECCC. I think we will have to add
a DMI quirk disabling most (if not all) features of ideapad-laptop on 83DR
until a BIOS update fixes the mutex bug. Doing so should make the mutex less
likely to break. As a quick test, could you test if blacklisting ideapad-laptop
in modprobe.d (reboot required, ofc) helps?

(In reply to Avraham Hollander from comment #28)
> Is there anything you notice in there that could potentially cause the
> system to take excessively long (2-6 seconds) to resume from s2idle? That's
> another probably ACPI issue that I've always had. This is almost certainly
> unrelated to the charger bug and I don't want to go completely off topic,
> but I figure it's worth mentioning now that I have contact with the relevant
> people.

I guess this is also related to the mutex bug in DSDT, considering it has a
bunch of EC queries calling ECCC. Blacklisting ideapad-laptop may have some
help, as doing so reduces the probability of running into a race condition.

I am not really familiar with s2idle and EC queries, so I may not be the best
person to answer this. Armin, do you have any thoughts?

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

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

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

[bugzilla-daemon]

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

--- Comment #30 from Rong Zhang (i@rong.moe) ---
(In reply to Rong Zhang from comment #29)
> I've seen GBMD, SALS, SBMC, and DYTC calling ECCC.

Errata: s/GBMD/RPAM/

To summarize:

ECCC callers: RPAM[1], SALS[2], SBMC[2], DYTC[2].
WTER callers: none.
_BTP callers: none[3].

[1]: called by EC queries: _Q0A, _Q92, _Q93, _Q9E
[2]: called by ideapad-laptop
[3]: but itself is called by battery (drivers/acpi/battery.c)

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

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

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

[bugzilla-daemon]

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

--- Comment #31 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #29)
> (In reply to Avraham Hollander from comment #27)
> 
> Thanks for your test.
> 
> > It did not. Unplugging and replugging the charger a bunch of times results
> > in:
> > [...]
> 
> Ahh, my fault. I meant fixing the issue that ideapad-laptop misinterprets
> the error returned by the GBMD method as a valid return value. According to
> your log, the patch seems correct.
> 
> As for the issue of the mutex chaos (and hence the error logs you got), we
> can't really fix it from the kernel side. It can only be fixed by a BIOS
> update. That's why I added Mark to the CC list.
> 
> I've seen GBMD, SALS, SBMC, and DYTC calling ECCC. I think we will have to
> add a DMI quirk disabling most (if not all) features of ideapad-laptop on
> 83DR until a BIOS update fixes the mutex bug. Doing so should make the mutex
> less likely to break. As a quick test, could you test if blacklisting
> ideapad-laptop in modprobe.d (reboot required, ofc) helps?
> 
> (In reply to Avraham Hollander from comment #28)
> > Is there anything you notice in there that could potentially cause the
> > system to take excessively long (2-6 seconds) to resume from s2idle? That's
> > another probably ACPI issue that I've always had. This is almost certainly
> > unrelated to the charger bug and I don't want to go completely off topic,
> > but I figure it's worth mentioning now that I have contact with the
> relevant
> > people.
> 
> I guess this is also related to the mutex bug in DSDT, considering it has a
> bunch of EC queries calling ECCC. Blacklisting ideapad-laptop may have some
> help, as doing so reduces the probability of running into a race condition.
> 
> I am not really familiar with s2idle and EC queries, so I may not be the
> best person to answer this. Armin, do you have any thoughts?

I can't get it to trigger either way now, whether ideapad_laptop is loaded or
not. Could the cause be that my battery is fully charged now? I'm going to
discharge it some and try it again.

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

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

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

[bugzilla-daemon]

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

--- Comment #32 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Avraham Hollander from comment #31)
> (In reply to Rong Zhang from comment #29)
> > (In reply to Avraham Hollander from comment #27)
> > 
> > Thanks for your test.
> > 
> > > It did not. Unplugging and replugging the charger a bunch of times
> results
> > > in:
> > > [...]
> > 
> > Ahh, my fault. I meant fixing the issue that ideapad-laptop misinterprets
> > the error returned by the GBMD method as a valid return value. According to
> > your log, the patch seems correct.
> > 
> > As for the issue of the mutex chaos (and hence the error logs you got), we
> > can't really fix it from the kernel side. It can only be fixed by a BIOS
> > update. That's why I added Mark to the CC list.
> > 
> > I've seen GBMD, SALS, SBMC, and DYTC calling ECCC. I think we will have to
> > add a DMI quirk disabling most (if not all) features of ideapad-laptop on
> > 83DR until a BIOS update fixes the mutex bug. Doing so should make the
> mutex
> > less likely to break. As a quick test, could you test if blacklisting
> > ideapad-laptop in modprobe.d (reboot required, ofc) helps?
> > 
> > (In reply to Avraham Hollander from comment #28)
> > > Is there anything you notice in there that could potentially cause the
> > > system to take excessively long (2-6 seconds) to resume from s2idle?
> That's
> > > another probably ACPI issue that I've always had. This is almost
> certainly
> > > unrelated to the charger bug and I don't want to go completely off topic,
> > > but I figure it's worth mentioning now that I have contact with the
> > relevant
> > > people.
> > 
> > I guess this is also related to the mutex bug in DSDT, considering it has a
> > bunch of EC queries calling ECCC. Blacklisting ideapad-laptop may have some
> > help, as doing so reduces the probability of running into a race condition.
> > 
> > I am not really familiar with s2idle and EC queries, so I may not be the
> > best person to answer this. Armin, do you have any thoughts?
> 
> I can't get it to trigger either way now, whether ideapad_laptop is loaded
> or not. Could the cause be that my battery is fully charged now? I'm going
> to discharge it some and try it again.

Actually, it just seems to be really intermittent. Now I'm getting the errors
from ucsi_acpi but not the mutex error, with ideapad_laptop loaded. It's hard
to say for sure whether blacklisting the module helps or not.

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

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

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

[bugzilla-daemon]

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

--- Comment #33 from Rong Zhang (i@rong.moe) ---
(In reply to Avraham Hollander from comment #32)
> Actually, it just seems to be really intermittent.

That's expected. These error logs are due to two reasons:

#1

Many ACPI methods need to acquire the ECMT mutex while executing. Most of them
are helper methods, meant to be called by outer methods.

When the laptop is connected to or disconnected from AC power, a bunch of
events is generated simultaneously, causing the corresponding ACPI methods to
be invoked simultaneously and to compete for the mutex. After several seconds,
some methods have waited for too long and timed out, causing them to return an
error.

However, some outer methods don't confirm if the helper method succeeded. They
blindly propagate the helper methods' return values, even if they are error
codes or nonsense. If an outer method calls a helper method multiple times, it
will end up returning a half-valid-half-nonsense value.

That's how the ideapad-laptop and ucsi_acpi errors are produced.

#2

Some helper methods are not implemented properly. They release the ECMT mutex
even if they have failed to acquire it due to the timeout. When they are
unlucky and time out, releasing the mutex (even if they do not own it) causes
the ACPI error.

Hence, not seeing the mutex error simply means that the ECCC method was lucky
and didn't time out.

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

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

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

[bugzilla-daemon]

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

--- Comment #34 from Rong Zhang (i@rong.moe) ---
I also found some time looking into ucsi_acpi and the AML code of the ACPI
device (in SSDT17).

Two helper methods (\_SB.PCI0.LPC0.EC0.ECRD for reading,
\_SB.PCI0.LPC0.EC0.ECWT for writing) are repeatedly called a total of 25 (!)
times when handling a UCSI command. Their timeout for acquiring the ECMT mutex
is 1s. Therefore, it is not surprising that some of these calls will time out.

Considering this, it seems that ucsi_acpi will cause significant pressure on
the ECMT mutex, as each UCSI command acquires and releases it 25 times. Instead
of blacklisting ideapad-laptop, could you try to blacklist ucsi_acpi? Doing so
should reduce the pressure on the ECMT mutex a lot, so other ACPI methods may
be less likely to time out. Again, this won't completely "fix" the issue, and a
BIOS update is the only way to fix it.

Moreover, there is no way for us to determine if any call within them has
failed, so we can't trust the UCSI ACPI device anymore -- a quirk will also be
required to disable usci_acpi on 83DR.

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

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

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

[bugzilla-daemon]

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

bcuseudshjvtquiocv@nespj.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bcuseudshjvtquiocv@nespj.co
                   |                            |m

--- Comment #35 from bcuseudshjvtquiocv@nespj.com ---
If this is a system firmware issue, we can probably close this ticket. Ideapad
laptops are not supported under linux (they don't even let you update the
firmware with fwupd even though the infrastructure works just fine, you have to
use windows) and it's extremely unlikely that someone from Lenovo will be
interested in fixing this if it works on windows.

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

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

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

[bugzilla-daemon]

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

--- Comment #36 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Rong Zhang from comment #34)
> I also found some time looking into ucsi_acpi and the AML code of the ACPI
> device (in SSDT17).
> 
> Two helper methods (\_SB.PCI0.LPC0.EC0.ECRD for reading,
> \_SB.PCI0.LPC0.EC0.ECWT for writing) are repeatedly called a total of 25 (!)
> times when handling a UCSI command. Their timeout for acquiring the ECMT
> mutex is 1s. Therefore, it is not surprising that some of these calls will
> time out.
> 
> Considering this, it seems that ucsi_acpi will cause significant pressure on
> the ECMT mutex, as each UCSI command acquires and releases it 25 times.
> Instead of blacklisting ideapad-laptop, could you try to blacklist
> ucsi_acpi? Doing so should reduce the pressure on the ECMT mutex a lot, so
> other ACPI methods may be less likely to time out. Again, this won't
> completely "fix" the issue, and a BIOS update is the only way to fix it.
> 
> Moreover, there is no way for us to determine if any call within them has
> failed, so we can't trust the UCSI ACPI device anymore -- a quirk will also
> be required to disable usci_acpi on 83DR.

I don't *seem* to be getting the mutex error with it blacklisted. However, I'm
still getting the original error from ideapad_acpi.

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

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

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

[bugzilla-daemon]

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

--- Comment #37 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to bcuseudshjvtquiocv from comment #35)
> If this is a system firmware issue, we can probably close this ticket.
> Ideapad laptops are not supported under linux (they don't even let you
> update the firmware with fwupd even though the infrastructure works just
> fine, you have to use windows) and it's extremely unlikely that someone from
> Lenovo will be interested in fixing this if it works on windows.

 Rong Zhang's choice to CC Mark Pearson proves otherwise.

There's also a difference between "not officially supported" and "we don't care
about this at all and will offer little to no help."

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

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

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

[bugzilla-daemon]

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

--- Comment #38 from Mark Pearson (mpearson-lenovo@squebb.ca) ---
> Rong Zhang's choice to CC Mark Pearson proves otherwise.

I can't promise anything - I don't have any official levers to pull for this
platform I'm afraid (it is better to buy Linux supported/certified systems ;) )

But, having all the details above is very useful and I can ask for help from
platforms that aren't officially in the Linux program and sometimes get lucky.

Last week was very busy for me so I didn't look at this thread properly. With
it being Chinese New Year this week there's no point me sending off emails
which will get lost in the holiday swamp.
Can someone nudge me next week if I don't post a note? I'll get this ticket
forwarded to the Yoga team then and ask for them to look at it.

Mark

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

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

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

[bugzilla-daemon]

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

--- Comment #39 from Avraham Hollander (anhollander516@gmail.com) ---
Question: If the problem lies purely in the DSDT, would it not be possible to
test a fix with a DSDT override? I am open to doing that.

I think it should also be possible to fix these errors with a DSDT patch?

ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP6._S0W],
AE_ALREADY_EXISTS (20250807/dswload2-327)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
(20250807/psobject-220)
ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP6._PRW],
AE_ALREADY_EXISTS (20250807/dswload2-327)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
(20250807/psobject-220)
ACPI: Skipping parse of AML opcode: OpcodeName unavailable (0x0014)
ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP6.RTKW],
AE_ALREADY_EXISTS (20250807/dswload2-327)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
(20250807/psobject-220)
ACPI: Skipping parse of AML opcode: OpcodeName unavailable (0x0014)
ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP1._PRW],
AE_ALREADY_EXISTS (20250807/dswload2-327)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
(20250807/psobject-220)
ACPI: Skipping parse of AML opcode: OpcodeName unavailable (0x0014)

Maybe that would help with the long resume time.

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

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

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

[bugzilla-daemon]

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

--- Comment #40 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Mark Pearson from comment #38)
> > Rong Zhang's choice to CC Mark Pearson proves otherwise.
> 
> I can't promise anything - I don't have any official levers to pull for this
> platform I'm afraid (it is better to buy Linux supported/certified systems
> ;) )
> 
> But, having all the details above is very useful and I can ask for help from
> platforms that aren't officially in the Linux program and sometimes get
> lucky.
> 
> Last week was very busy for me so I didn't look at this thread properly.
> With it being Chinese New Year this week there's no point me sending off
> emails which will get lost in the holiday swamp.
> Can someone nudge me next week if I don't post a note? I'll get this ticket
> forwarded to the Yoga team then and ask for them to look at it.
> 
> Mark

Don't worry about it, we're patient.

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

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

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

[bugzilla-daemon]

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

--- Comment #41 from Rong Zhang (i@rong.moe) ---
(In reply to Avraham Hollander from comment #36)
> I don't *seem* to be getting the mutex error with it blacklisted. However,
> I'm still getting the original error from ideapad_acpi.

That should be a good sign.

Not making the ideapad-laptop error disappear hints that there must be other
methods holding the ECMT mutex for too long after resuming from s2idle.
Debugging with https://docs.kernel.org/firmware-guide/acpi/debug.html may
reveal more details.

(In reply to Avraham Hollander from comment #39)
> Question: If the problem lies purely in the DSDT, would it not be possible
> to test a fix with a DSDT override? I am open to doing that.
> 
> I think it should also be possible to fix these errors with a DSDT patch?

From my perspective, everything built around ECMT is broken. Fixing ECCC, WTER,
and _BTP by overriding DSDT only resolves #2 (see comment #33).

To resolve #1, every method that relies on ECMT must explicitly check the
helper functions' return values and must stop propagating nonsense on error.

Of course, you may lengthen the timeouts of acquiring ECMT and pray for
success...

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

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

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

[bugzilla-daemon]

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

fililip (team@nitrosubs.live) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |team@nitrosubs.live

--- Comment #42 from fililip (team@nitrosubs.live) ---
I think I'm having this issue as well on my 83HN laptop.

dmesg says:

[   48.931988] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast]
and [Long_Life] are enabled

However, listing the contents of
/sys/bus/platform/drivers/ideapad_acpi/VPC2004:00 returns:

camera_power       driver_override  fn_lock  modalias          rfkill    
usb_charging
conservation_mode  fan_mode         input    platform-profile  subsystem
driver             firmware_node    leds     power             uevent

There's no charge_types file.

Is that intentional?

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

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

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

[bugzilla-daemon]

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

--- Comment #43 from fililip (team@nitrosubs.live) ---
I apologize, I was looking in the wrong directory.

cat /sys/class/power_supply/BAT0/charge_types returns:

Fast Standard [Long_Life]

So it looks like it's already set to long life for me, but the ideapad driver
thinks otherwise.

I'm on 6.19.5, running PSCN21WW firmware.

BTW, someone in the thread seems to be spreading misinformation, as you can
unpack the firmware update (PE32/exe) and use the included ~34MiB bin file with
fwupd which is how I have the latest firmware actually.

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

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

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

[bugzilla-daemon]

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

--- Comment #44 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to fililip from comment #43)
> I apologize, I was looking in the wrong directory.
> 
> cat /sys/class/power_supply/BAT0/charge_types returns:
> 
> Fast Standard [Long_Life]
> 
> So it looks like it's already set to long life for me, but the ideapad
> driver thinks otherwise.
> 
> I'm on 6.19.5, running PSCN21WW firmware.
> 
> BTW, someone in the thread seems to be spreading misinformation, as you can
> unpack the firmware update (PE32/exe) and use the included ~34MiB bin file
> with fwupd which is how I have the latest firmware actually.

I didn't know you could do that with fwupd either. I'll have to try it next
time.

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

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

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

[bugzilla-daemon]

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

--- Comment #45 from fililip (team@nitrosubs.live) ---
(In reply to Avraham Hollander from comment #44)
> I didn't know you could do that with fwupd either. I'll have to try it next
> time.

This only works for AMD platforms, I think, but all you need to do is run

doas fwupdtool get-devices | grep -A 1 "System Firmware"

get the ID, and then execute

doas fwupdtool install-blob WinPSCN21WW.fd [that ID]

with WinPSCN21WW.fd being that extracted update file.

Then fwupd will prompt you for a reboot and install the update from the EFI.

Intel platforms have an additional IME update and I'm not sure how that's
supposed to work, so caution is advised.

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

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

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

[bugzilla-daemon]

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

--- Comment #46 from Rong Zhang (i@rong.moe) ---
(In reply to fililip from comment #42)
> I think I'm having this issue as well on my 83HN laptop.
> [...]

Could you attach the acpidump of your device? This will help a lot in figuring
out what's going on in the FW.

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

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

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

[bugzilla-daemon]

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

--- Comment #47 from fililip (team@nitrosubs.live) ---
Created attachment 309511
  --> https://bugzilla.kernel.org/attachment.cgi?id=309511&action=edit
acpidump from 83HN

Sure, here it is.

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

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

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

[bugzilla-daemon]

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

--- Comment #48 from Rong Zhang (i@rong.moe) ---
(In reply to fililip from comment #47)
> Created attachment 309511 [details]
> acpidump from 83HN

Thanks. I found some time looking into it. It has exactly the same issues and
broken patterns as 83DR.

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

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

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

[bugzilla-daemon]

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

--- Comment #49 from fililip (team@nitrosubs.live) ---
A thing that I noticed over the past few days is that while the laptop is
plugged in (before boot) and in conservation mode, no errors are present in
dmesg. Only when I try to view/change KDE power management settings or
unplug/replug the power supply does anything happen (like ACPI errors or the
ideapad_acpi charge type duality issue).

I've also seen problems with delayed responses to unplugging the charger
(though plugging it in seems to make the OS react much faster) even on 6.18 and
prior, but no ACPI errors were ever logged to my knowledge.

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

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

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

[bugzilla-daemon]

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

--- Comment #50 from fililip (team@nitrosubs.live) ---
(In reply to Mark Pearson from comment #38)
> Can someone nudge me next week if I don't post a note? I'll get this ticket
> forwarded to the Yoga team then and ask for them to look at it.
> 
> Mark

Hi, did you get a chance to notify the team about this problem?

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

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

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

[bugzilla-daemon]

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

--- Comment #51 from Mark Pearson (mpearson-lenovo@squebb.ca) ---
Thanks for the nudge - I'm checking with them.

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

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

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

[bugzilla-daemon]

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

jeffrey@waelti.dev changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeffrey@waelti.dev

--- Comment #52 from jeffrey@waelti.dev ---
Created attachment 309756
  --> https://bugzilla.kernel.org/attachment.cgi?id=309756&action=edit
14AKP10 acpidump

I'm seeing the same behaviour on my Lenovo Yoga 7 2-in-1 14AKP10, I've added
the ACPI dump in case this can help to diagnose the issue further.

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

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

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

[bugzilla-daemon]

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

nael (naelblog@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |naelblog@gmail.com

--- Comment #53 from nael (naelblog@gmail.com) ---
+1
Using a "Yoga 7 14ARP8", "AMD Ryzen 7 7735U", kernel 6.19.9 (although I think
it started happening on previous 6.19 revisions as well). I am using gentoo.

`/sys/class/power_supply/BAT0/charge_types` says "[Fast] Standard Long_Life".

I just registered and I don´t know how to add the acpidump file...

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

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

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

[bugzilla-daemon]

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

--- Comment #54 from nael (naelblog@gmail.com) ---
Created attachment 309759
  --> https://bugzilla.kernel.org/attachment.cgi?id=309759&action=edit
Yoga 7 14ARP8 acpidump

Attached acpidump

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

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

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

[bugzilla-daemon]

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

--- Comment #55 from fililip (team@nitrosubs.live) ---
I see there's a new firmware update available (at least for my laptop):
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/yoga-series/yoga-pro-7-14asp9/83hn/downloads/ds570271?category=BIOS%2FUEFI

Is it worth installing to see if it fixes the issue or is the root cause still
under investigation?

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

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

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

[bugzilla-daemon]

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

--- Comment #56 from Avraham Hollander (anhollander516@gmail.com) ---
You should probably install it anyways. There's a lot of security fixes in
that update. There's no mentioned changes to ACPI, so it shouldn't have an
effect on the issue at hand.

On Wed, Apr 1, 2026, 8:58 AM <bugzilla-daemon@kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=221065
>
> --- Comment #55 from fililip (team@nitrosubs.live) ---
> I see there's a new firmware update available (at least for my laptop):
>
>
> https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/yoga-series/yoga-pro-7-14asp9/83hn/downloads/ds570271?category=BIOS%2FUEFI
>
> Is it worth installing to see if it fixes the issue or is the root cause
> still
> under investigation?
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are on the CC list for the bug.

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

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

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

[bugzilla-daemon]

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

--- Comment #57 from fililip (team@nitrosubs.live) ---
Alright, I did the update which was easy thanks to fwupdtool but unfortunately
the issue still remains.

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

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

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

[bugzilla-daemon]

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

george.stafilidis@proton.me changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |george.stafilidis@proton.me

--- Comment #58 from george.stafilidis@proton.me ---
This also happens on my Lenovo IdeaPad 3 15ALC6 but all I did was change a file
from 1 to 0 and then back to 1 again with a text editor and now I don't see the
error anymore on my logs and preserver battery mode shows up on my settings. (I
don't remember the file I opened I am on Fedora Workstation and Preverse
battery mode did not show up on 6.19xxx kernels until I made this change.)

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

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

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

[bugzilla-daemon]

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

--- Comment #59 from Rong Zhang (i@rong.moe) ---
(In reply to george.stafilidis from comment #58)
> This also happens on my Lenovo IdeaPad 3 15ALC6 but all I did was change a
> file from 1 to 0 and then back to 1 again with a text editor and now I don't
> see the error anymore on my logs and preserver battery mode shows up on my
> settings. (I don't remember the file I opened I am on Fedora Workstation and
> Preverse battery mode did not show up on 6.19xxx kernels until I made this
> change.)

Then your device probably doesn't have the FW bug.

Seeing the warning message in this case is not a bug. It tells you that having
conservation mode and rapid charge enabled at the same time is out of spec.
Writing 1 to conservation_mode clears the rapid charge bit. As long as the
warning doesn't appear again after tuning charge_types or conservation_mode,
you can safely forget it.

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

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

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

[bugzilla-daemon]

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

Rick (rickk1166@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rickk1166@gmail.com

--- Comment #60 from Rick (rickk1166@gmail.com) ---
I also have the Lenovo Yoga 7 2-in-1 14AKP10 (specifically Model #: 83JR0002US
which is AMD Ryzen AI 5 340).

Running Linux Mint 22.3 using Kernel 7.0.1 from Mainline (but same effect with
earlier kernels starting somewhere after 6.14)

I found this bug trying to track down a system (GUI?) pause every 7 minutes or
so which seems to correlate with the event discussed in this bug (as seen using
"dmesg -w").  The pause is around a second in duration and oddly the mouse
cursor will still move but everything else stops.  

If this is the cause of my pauses then at least I can stop looking and wait for
either a bug fix here or in the Lenovo BIOS.

Can someone confirm that this event correlates with a system GUI pause?

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

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

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

[bugzilla-daemon]

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

boite.pour.spam@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |boite.pour.spam@gmail.com

--- Comment #61 from boite.pour.spam@gmail.com ---
Same behavior for me, with a 83HY system.

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

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

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

[bugzilla-daemon]

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

--- Comment #62 from boite.pour.spam@gmail.com ---
Created attachment 309966
  --> https://bugzilla.kernel.org/attachment.cgi?id=309966&action=edit
ACPI Dump for 83HY

If it's of any help, done with the latest BIOS installed.

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

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

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

[bugzilla-daemon]

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

--- Comment #63 from boite.pour.spam@gmail.com ---
What changed with version 6.19 that made this errors pops out? I don't remember
seeing this with 6.18.

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

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

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

[bugzilla-daemon]

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

--- Comment #64 from Rong Zhang (i@rong.moe) ---
(In reply to boite.pour.spam from comment #63)
> What changed with version 6.19 that made this errors pops out? I don't
> remember seeing this with 6.18.

v6.19 added a check against insane values. See also
https://bugzilla.kernel.org/show_bug.cgi?id=221065#c14 for how the insane value
is produced.

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

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

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

[bugzilla-daemon]

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

--- Comment #65 from boite.pour.spam@gmail.com ---
Would it be possible to serialize the ideapad-laptop and ucsi_acpi simultaneous
accesses to a kernel mutex so that it's not possible for the kernel to timeout
on the ACPI mutex if only one kthread can be accessing it?

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

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

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

[bugzilla-daemon]

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

--- Comment #66 from Rong Zhang (i@rong.moe) ---
(In reply to boite.pour.spam from comment #65)
> Would it be possible to serialize the ideapad-laptop and ucsi_acpi
> simultaneous accesses to a kernel mutex so that it's not possible for the
> kernel to timeout on the ACPI mutex if only one kthread can be accessing it?

It's a completely dirty hack and would not fix the issue completely. The ECMT
mutex is not only used by ideapad-laptop and ucsi_acpi, but also heavily used
elsewhere. If you really care about that, you can simply blacklist usci_acpi as
it also returns garbage due to the FW bug, see
https://bugzilla.kernel.org/show_bug.cgi?id=221065#c34

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

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

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

[bugzilla-daemon]

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

--- Comment #67 from boite.pour.spam@gmail.com ---
I've read all the comments above and I'm trying to understand how the broken
ACPI tables would work on Windows. If there's a "deadlock" in the ACPI
implementation, how does Windows works around it? 
If I understand correctly, the solving options are:
1. Have Lenovo to fix the ACPI tables (which is very unlikely)
2. Implement a "live" ACPI fix with a DSDT override but it won't fix the bad
releasing of the ACPI's mutex (but we can probably live with it, since, except
for the dmesg noise, doesn't break anything)
3. Blacklist both usci_acpi and ideapad-laptop, so that there aren't any
contender on the mutex anymore, but I'm not clear about what's lost when we do
so?

Am I right?

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

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

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

[bugzilla-daemon]

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

Hans de Goede (hansg@kernel.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hansg@kernel.org

--- Comment #68 from Hans de Goede (hansg@kernel.org) ---
@Rong Zhang wrote: "If you really care about that, you can simply blacklist
usci_acpi as it also returns garbage due to the FW bug".

Would it be an idea to add a DMI id deny quirk-list to usci_acpi for this and
simply make that driver refuse to load for the known to be broken ideapad
models from this bug ?

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

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

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

[bugzilla-daemon]

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

--- Comment #69 from Rong Zhang (i@rong.moe) ---
(In reply to Hans de Goede from comment #68)
> @Rong Zhang wrote: "If you really care about that, you can simply blacklist
> usci_acpi as it also returns garbage due to the FW bug".
> 
> Would it be an idea to add a DMI id deny quirk-list to usci_acpi for this
> and simply make that driver refuse to load for the known to be broken
> ideapad models from this bug ?

Sure. I will find some time to check all acpidumps here for fragile USCI ACPI
methods and send a patch accordingly.

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

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

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

[bugzilla-daemon]

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

--- Comment #70 from Rong Zhang (i@rong.moe) ---
(In reply to boite.pour.spam from comment #67)
> I've read all the comments above and I'm trying to understand how the broken
> ACPI tables would work on Windows. If there's a "deadlock" in the ACPI
> implementation, 

How did you conclude that? No one had mentioned "deadlock". The issue is about:

#1. Errors in mutex acquisition are propagated blindly
#2. Some ACPI methods release a mutex owned by others

I think my conclusion is clear enough:
https://bugzilla.kernel.org/show_bug.cgi?id=221065#c33

> how does Windows works around it? 

Just ask Microsoft and Lenovo.

TBH, comparing Linux to Windows in that way is hardly helpful. On Windows, the
ideapad ACPI methods are used by Lenovo Vantage (or something else), which is a
userspace program. It probably doesn't query charge types after power events,
but blindly assumes nothing has changed. It probably doesn't check ACPI return
values to see if they are insane, but propagates them blindly again. I don't
think "Windows works around it," as burying one's head in the sand works around
nothing.

> If I understand correctly, the solving options are:
> 1. Have Lenovo to fix the ACPI tables (which is very unlikely)
> 2. Implement a "live" ACPI fix with a DSDT override but it won't fix the bad
> releasing of the ACPI's mutex

Again, how did you conclude that? If you used an AI to "help" you understand
the thread, you probably chose the wrong AI.

The easiest thing to fix is, however, "bad releasing" (#2). Just delete or move
several lines of ASL code, and that's it.

But most of the issues here are caused by #1. It generates a lot of garbage
return values, and there's no easy way to distinguish them afterward. Every
method that recursively depends on ECMT must be rewritten, which means that not
only the DSDT, but also some SSDTs, need to be overridden.

I've almost said the same in
https://bugzilla.kernel.org/show_bug.cgi?id=221065#c41

> (but we can probably live with it, since,
> except for the dmesg noise, doesn't break anything)

The error messages generated by ideapad-laptop don't break anything either.
They're harmlessly noisy right after power events, but everything should work
well once the events settle.

> 3. Blacklist both usci_acpi and ideapad-laptop, so that there aren't any
> contender on the mutex anymore, but I'm not clear about what's lost when we
> do so?

It's usually OK to blacklist usci_acpi. Most Lenovo laptops have most USCI
commands stubbed to a certain extent, so they're hardly useful. The EC will
always handle USB-C events itself despite that.

You don't need to blacklist ideapad-laptop if you can live with harmless dmesg
noise.

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

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

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

[bugzilla-daemon]

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

--- Comment #71 from Avraham Hollander (anhollander516@gmail.com) ---
Removing ucsi_acpi fixes the charge state reporting problems.

However, with only ideapad_laptop loaded and not ucsi_acpi, I still got:

ACPI Error: Thread 2463875008 cannot release Mutex [ECMT] acquired by thread
2221167872 (20251212/exmutex-378)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.ECCC due to previous error
(AE_AML_NOT_OWNER) (20251212/psparse-531)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0.RPAM due to previous error
(AE_AML_NOT_OWNER) (20251212/psparse-531)
ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q93 due to previous error
(AE_AML_NOT_OWNER) (20251212/psparse-531)

When unplugging and replugging the charger a bunch of times to test.

Removing ideapad_laptop, you lose control over features like the ACPI platform
profile. It can still be changed via a BIOS setting, but that's not helpful if
you want a different setting on AC vs. battery.

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

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

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

[bugzilla-daemon]

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

--- Comment #72 from Hans de Goede (hansg@kernel.org) ---
> However, with only ideapad_laptop loaded and not ucsi_acpi, I still got ...

There is nothing we can do about those messages. The real question is if there
are still any messages which repeat periodically filling the disk with logs,
like the original messages starting this bug.

Or if there are any actual problems when using the laptop?

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

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

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

[bugzilla-daemon]

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

--- Comment #73 from Avraham Hollander (anhollander516@gmail.com) ---
(In reply to Hans de Goede from comment #72)
> > However, with only ideapad_laptop loaded and not ucsi_acpi, I still got ...
> 
> There is nothing we can do about those messages. The real question is if
> there are still any messages which repeat periodically filling the disk with
> logs, like the original messages starting this bug.
> 
> Or if there are any actual problems when using the laptop?

Oh yeah, it is indeed still printing the "unexpected charge_type" message.  Not
sure why I didn't just mention that.

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

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

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

[bugzilla-daemon]

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

--- Comment #74 from jeffrey@waelti.dev ---
(In reply to Rick from comment #60)
> I found this bug trying to track down a system (GUI?) pause every 7 minutes
> or so which seems to correlate with the event discussed in this bug (as seen
> using "dmesg -w").  The pause is around a second in duration and oddly the
> mouse cursor will still move but everything else stops.  
> 
> If this is the cause of my pauses then at least I can stop looking and wait
> for either a bug fix here or in the Lenovo BIOS.
> 
> Can someone confirm that this event correlates with a system GUI pause?

I can't confirm whether this is the cause, but I also see freezes (most
noticeable by the shell becoming unresponsive in the terminal), which when
checking the logs always seems to correlate with one of these errors.

(In reply to Hans de Goede from comment #72)
> > However, with only ideapad_laptop loaded and not ucsi_acpi, I still got ...
> 
> There is nothing we can do about those messages. The real question is if
> there are still any messages which repeat periodically filling the disk with
> logs, like the original messages starting this bug.
> 
> Or if there are any actual problems when using the laptop?

If this is actually the cause, then there are definitely problems using
affected devices, since these very regular freezes of the whole system are more
than just a cosmetic issue in the logs.

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

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

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

[bugzilla-daemon]

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

--- Comment #75 from Rong Zhang (i@rong.moe) ---
(In reply to jeffrey from comment #74)
> (In reply to Rick from comment #60)
> > 
> > Can someone confirm that this event correlates with a system GUI pause?
> 
> I can't confirm whether this is the cause, but I also see freezes (most
> noticeable by the shell becoming unresponsive in the terminal), which when
> checking the logs always seems to correlate with one of these errors.
> 
> (In reply to Hans de Goede from comment #72)
> > 
> > Or if there are any actual problems when using the laptop?
> 
> If this is actually the cause, then there are definitely problems using
> affected devices, since these very regular freezes of the whole system are
> more than just a cosmetic issue in the logs.

These logs are symptoms. They are caused by a lot of poorly implemented ACPI
methods competing for the same mutex.

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

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

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

[bugzilla-daemon]

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

--- Comment #76 from Rick (rickk1166@gmail.com) ---
(In reply to jeffrey from comment #74)

> 
> If this is actually the cause, then there are definitely problems using
> affected devices, since these very regular freezes of the whole system are
> more than just a cosmetic issue in the logs.

I completely blacklisted Ideapad_laptop on my system (using Mint Kernel
6.17.0-23-generic) and this seems to have completely solved the 1 second pauses
every 7 minutes for me.

For anyone else with a Lenovo Yoga 2 in 1 Ryzen AI 5 340 (2025 version) (Model
83JR0002US) searching for an immediate solution:
I added file "/etc/modprobe.d/blackist-ideapad_laptop.conf" with the following
lines:
blacklist ideapad_laptop
install ideapad_laptop /bin/false
Then in a terminal I ran "sudo update-initramfs -u" to make it active - after
reboot I no longer get the pauses or the associated messages in the log.

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

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

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

[bugzilla-daemon]

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

--- Comment #77 from Rong Zhang (i@rong.moe) ---
(In reply to Rick from comment #76)
> (In reply to jeffrey from comment #74)
> 
> I completely blacklisted Ideapad_laptop on my system (using Mint Kernel
> 6.17.0-23-generic) and this seems to have completely solved the 1 second
> pauses every 7 minutes for me.

Hmm, interesting. I assume the pauses had existed before I introduced the
warning message (unexpected charge_types...), right?

This sounds like a slow SMI handling due to the broken firmware.

Could you kindly provide more detailed information about the pause? When it
happened, did you notice a spike in CPU usage? Did you see any dmesg message at
that time? Did it freeze your system completely or just make things laggy?

Could you also monitor the SMI count, i.e.,

  sudo perf stat -e ls_smi_rx -I 1000

..., wait for the pause to occur, and check how many SMIs have occurred during
the pause?

You can also mess around with sysfs attributes of ideapad-laptop, power_supply,
and firmware-attributes to see if reading them causes SMIs:

  sudo tail /sys/bus/acpi/devices/VPC2004\:00/physical_node/*
  sudo tail /sys/class/power_supply/*/*
  sudo tail /sys/class/firmware-attributes/*/attributes/*/*

On my device, reading /sys/class/firmware-attributes/thinklmi/attributes/*/*
always causes 580 SMIs, and other attributes do not cause any SMI.

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

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

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

[bugzilla-daemon]

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

--- Comment #78 from Rick (rickk1166@gmail.com) ---
(In reply to Rong Zhang from comment #77)
> (In reply to Rick from comment #76)
> > (In reply to jeffrey from comment #74)
> > 
> > I completely blacklisted Ideapad_laptop on my system (using Mint Kernel
> > 6.17.0-23-generic) and this seems to have completely solved the 1 second
> > pauses every 7 minutes for me.
> 
> Hmm, interesting. I assume the pauses had existed before I introduced the
> warning message (unexpected charge_types...), right?

Correct - this pause happens in Kernel 6.17 with no messages, when I load
Kernel 6.19 I started getting the messages and that lead me to this thread.
I tried Kernel 6.16 and the pause does not happen - so I believe this behavior
was introduced in Kernel 6.17

> 
> This sounds like a slow SMI handling due to the broken firmware.
> 
> Could you kindly provide more detailed information about the pause? When it
> happened, did you notice a spike in CPU usage? Did you see any dmesg message
> at that time? Did it freeze your system completely or just make things laggy?

The system appears to freeze solid for about 1 to 2 seconds (hard to tell the
exact timing - but the pause feels like it is always the same duration).
Nothing on screen changes.

When running system monitor during the event I see it freeze but when it
restarts I don't see any spikes or anything interesting on any graph.

When I was running the "perf stat" stuff below I did notice that during the
freeze it stopped updating and when it resumed it looked like it filled in all
the data that was paused. Normally the perf stat seems to just produce a row of
data on a periodic basis and when the pause happens it stops but after the
freeze it looks like it prints a bunch of rows to catch up to where it should
be.

There is no laggy behavior either before or after the freeze. The system works
perfectly at all times except for the duration of the freeze. 

No message in dmesg under Kernel 6.17 (the default kernel in Mint - my daily
driver).

The dmesg message shows up (Kernel 6.19 used for this) as soon as the freeze is
finished (here are three consecutive events captured using "dmesg -w" so you
can see the timing between them:
[ 107.554265] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and
[Long_Life] are enabled
[ 501.851737] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and
[Long_Life] are enabled
[ 933.076412] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and
[Long_Life] are enabled

> 
> Could you also monitor the SMI count, i.e.,
> 
>   sudo perf stat -e ls_smi_rx -I 1000
> 
> ..., wait for the pause to occur, and check how many SMIs have occurred
> during the pause?

There number stayed at 0 the entire time I was testing the pause - the pause
did not make the number increment.

> 
> You can also mess around with sysfs attributes of ideapad-laptop,
> power_supply, and firmware-attributes to see if reading them causes SMIs:
> 
>   sudo tail /sys/bus/acpi/devices/VPC2004\:00/physical_node/*
>   sudo tail /sys/class/power_supply/*/*
>   sudo tail /sys/class/firmware-attributes/*/attributes/*/*
> 
> On my device, reading /sys/class/firmware-attributes/thinklmi/attributes/*/*
> always causes 580 SMIs, and other attributes do not cause any SMI.

On my device, reading /sys/class/firmware-attributes/thinklmi/attributes/*/*
always causes 504 SMIs, and other attributes do not cause any SMI.

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

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

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

[bugzilla-daemon]

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

--- Comment #79 from Rick (rickk1166@gmail.com) ---
(In reply to Rick from comment #78)

> The system appears to freeze solid for about 1 to 2 seconds (hard to tell
> the exact timing - but the pause feels like it is always the same duration).
> Nothing on screen changes.

Let me clarify this - After further testing: the mouse cursor continues to move
on screen during a pause event.

For testing I was in a text editor scrolling a long document up and down (using
mouse wheel) while moving the mouse in a circle.  When the pause happens the
document stops scrolling and the performance monitor stops updating.

During the freeze the mouse cursor stayed fully responsive to my movements and
did not seem laggy or out of the ordinary.

For reference I am running Linux Mint 22.3 - Cinnamon 64-bit - Cinnamon 6.6.7

I was also typing this comment with the ideapad_laptop kernel module enabled
and I think the pause also allows keyboard input to buffer and not be ignored.
(I was typing when a pause happened and I could have sworn that a key didn't
register on screen so I hit it again and when the pause ended I ended up with
two of the characters).

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

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