My experience with Clear Linux and Ubuntu:

- Setup: external monitors connected via TB4 docking station (make and model does not matter, it happens with all TB4 docks I got) to an LGGram laptop (I have two recent different models (2021 and 2022), happens on both);
- Symptoms: pretty much all symptoms mentioned in the link posted above (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1987829). The most glaring symptoms are: (a) overheating--CPU temperature hovers around 90C--and (b) syslog spamming;
- Palliative "cure":
       1. run the `sudo rmmod int3403_thermal` command sometime after boot (~1min) either manually or automatically: this stops the kernel spamming, though it does not deal w/the overheating;
       2. blacklist the int3403_thermal module fixes both issues, at the expense of very high CPU utilization(!), that renders the whole system pretty much unusable.

More details:
- https://community.clearlinux.org/t/execute-command-upon-reboot-systemd-timer/8484/10
- https://www.reddit.com/r/linuxhardware/comments/x97m6l/comment/j2r7irr/?utm_source=reddit&utm_medium=web2x&context=3

Hello,

Here is my experience. I am using an LG Gram 14Z90Q-G.AA76B and have faced high CPU usage from kworker threads on every distro I have tried (Fedora, ArchLinux, VanillaOS, Ubuntu). From my experience, there is a somewhat reliable way to temporarily stop the high CPU usage. I don't dualboot windows, so I cannot test the suggestion of booting from windows to linux. Rather, I have noticed the following pattern:

1. Plug In USB-C cable (charging/HDMI)
2. Run "top" to verify that 3 kworker threads appear with high CPU usage. The fan will eventually kick in
3. Suspend the laptop (close the lid, press power button, press Fn+s, or manually suspend) and wait for the fan to completely turn off. Optionally unplug and plug in USB-C cable (sometimes helps).
4. Wake device from sleep.
5. Run "top" again, kworkers will be gone

Now this does not work 100% of the time, as sometimes after waking from sleep the device still keeps the kworker threads up and running, but eventually after doing this they disappear until the next reboot. This workaround gets the job done for me, as long as I don't have to reboot often.

Hello,

I am experiencing similar issues. I have the LG Gram 17-ZD90Q. I am on Archlinux-KDE and I dual-booted with windows in order to check if the problem was related to the kernel or if it was in the BIOS. Windows apparently goes well, so it is something related to linux. I tried several linux kernels but any of them worked. Right now I'm on linux-zen.
One day I did something (probably update the whole packages) and the fans started to slow down as did the cpu's... That was surprising but on the next boot the problem reappeared. :(

Also I cannot sleep my laptop because when I try to do it, the laptop freezes... And I think it is a problem related to the cpu's utilization too, because that time when the error disappeared magically I could sleep my laptop without any problems.

I thought the error could come from the inappropriate handling of Intel gen12 in the linux kernels (6.xxx) but they are supposed to handle well the intel gen13, so that makes me doubt...

As this problem is also related with the large number of acpi interrupts, some people say that you should mask (at the boot-up) the gpeXX with a high number of interrupts that you get with the command

grep -r enabled /sys/firmware/acpi/interrupts

But that's not a solution!!! Because, it may reduce the high cpu usage, but on the other hand, other important interrupts that should be resolved 'instantaneously' (for example, key presses) also get masked... As a result keys such as the ones for increasing the brightness or the Captial letters one did not work properly.

Any kind of help is welcome!! Thank you.

(In reply to Pixel from comment #2)

> Rather, I have noticed the following pattern:
> 
> 1. Plug In USB-C cable (charging/HDMI)
> 2. Run "top" to verify that 3 kworker threads appear with high CPU usage.
> The fan will eventually kick in
> 3. Suspend the laptop (close the lid, press power button, press Fn+s, or
> manually suspend) and wait for the fan to completely turn off. Optionally
> unplug and plug in USB-C cable (sometimes helps).
> 4. Wake device from sleep.
> 5. Run "top" again, kworkers will be gone
> 
> Now this does not work 100% of the time, as sometimes after waking from
> sleep the device still keeps the kworker threads up and running, but
> eventually after doing this they disappear until the next reboot. This
> workaround gets the job done for me, as long as I don't have to reboot often.

Thanks for sharing! This works for me too. I have 

In my experience the key point here seems to wait for several minutes and unplug the cable after suspending. Otherwise the 3 kworker threads will remain in `top`.

... I have a LG Gram 16Z90Q-G.CD78C, which runs Arch Linux with kernel 6.3.3-arch1-1

I found a similar but different workaround.

1- Boot into your linux as always (plugged-in or not, I think it doesn't matter).
2- Immediately after logging into your desktop, suspend the laptop (I did it by closing the lid).
3- Wait for a few seconds (1 or 2) and wake it again from sleep. 
4- The kworkers shouldn't appear now.

It seems that this workaround prevents the kworkers from initiating during startup. Once the laptop is suspended, they are unable to appear again, for some unknown reason.

Same issues with LG Gram 17Z90R-A.ADB9U1 tested with debian 6.1.0-9 and torvalds/linux.git 6.4.0-rc4.

When charging via USB-C I'm getting ACPI errors messages in dmesg and noticably high CPU usage with kworker processes like others above.

ACPI Error: Aborting method \_SB.PC00.LPCB.LGEC.SEN1._TMP due to previous error (AE_NOT_EXIST) (20220331/psparse-529)
ACPI Error: Aborting method \_SB.PC00.LPCB.LGEC.SEN2._TMP due to previous error (AE_NOT_EXIST) (20220331/psparse-529)
ACPI Error: No handler for Region [XIN1] (000000004f00cfe9) [UserDefinedRegion] (20220331/evregion-130)
ACPI Error: Region UserDefinedRegion (ID=143) has no handler (20220331/exfldio-261)
thermal thermal_zone7: failed to read out thermal zone (-5)
thermal thermal_zone7: failed to read out thermal zone (-61)
	with thermal_zone 2,3,4,6,7 ...

Workarounds for now:
- Blacklisting module int3403_thermal prevents the ACPI and thermal errors messages.
- Booting with kernel parameter "acpi_mask_gpe=0x6E" prevents the high CPU usage.

Can confirm the issue on my LG Gram 17Z90Q-K (2022 model) running Manjaro (Arch) with Kernels:
6.4.2-3 (latest version I have available on my system)
6.1.38-1 (LTS)

Happens both connected to my Thunderbolt 3 dock that also charges the computer, or to the power supply. Doesn't happen when running on battery power.

Doesn't happen on my LG gram from 2021.

1. I didn't find any reports of this issue for the 2023 models. Did anyone?

I believe that we need either a Linux Kernel patch or a BIOS update, but there doesn't seem to be any updates to the BIOS of the 2022 lined up of LG Gram.

2. How can we get this fixed? Who can save us!?

3. Are there any workarounds that can be programmatically applied?

(In reply to eric from comment #7)
> Workarounds for now:
> - Blacklisting module int3403_thermal prevents the ACPI and thermal errors
> messages.
> - Booting with kernel parameter "acpi_mask_gpe=0x6E" prevents the high CPU
> usage.

I'm resistant to try it because:

```
When you specify a kernel boot parameter like acpi_mask_gpe=0x6E, you're telling the kernel to ignore or mask a specific ACPI GPE, in this case, the GPE with the address 0x6E.

This can be useful in certain scenarios where a specific GPE is causing issues, like system instability or high CPU usage. By masking the GPE, you prevent the system from processing that event, which can work around the issue.

However, you should only use this parameter if you are sure that the specific GPE is causing issues and you understand the implications of masking it. In some cases, it can lead to other problems, like certain hardware events not being correctly detected by the OS.
``` - Chat GPT 4

Here is my elegant workaround to the problem:
```
[Unit]
Description=Fixes many issues with the 2022 LG Grams running linux and sets charging limit to 80

# save this script to /etc/systemd/system/lg-gram.service
# then run:
# sudo systemctl daemon-reload
# sudo systemctl enable lg-gram.service
# sudo systemctl start lg-gram.service

# more documentation: https://www.reddit.com/r/LGgram/comments/150p3rg/critical_bug_affecting_the_2022_lineup_on_linux/

[Service]
Type=oneshot
# Unmask GPE interrupts to resolve the issue of high temperatures and fan noise even on idle when the laptop is charging through USB-C/TB:
ExecStart=/bin/bash -c "echo 'unmask' > /sys/firmware/acpi/interrupts/gpe6E"

# sets charging limit to 80 to increase battery longevity:
ExecStart=/bin/bash -c "echo 80 > /sys/class/power_supply/CMB0/charge_control_end_threshold"

# Disable "Silent mode":
ExecStart=/bin/bash -c "echo 1 > /sys/devices/platform/lg-laptop/fan_mode"

# Unload the int3403 temp sensor library from the kernel to fix ACPI flood issue:
# ExecStart=/bin/sh -c "rmmod int3403_thermal"

# Disable turbo boost (trade single threaded performance for lower heat output and maybe battery life)
# ExecStart=/bin/sh -c 'echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo'
# ExecStop=/bin/sh -c 'echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo'

# Fix for thermal throttle issue that on some distros can put the CPU running on low wattages:
# ExecStart=/bin/bash -c "systemctl disable --now thermald"

RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
```

--
The issue seems to be caused by:
some miscommunication between Linux thinking it can probe for thermal info on a device which did not register a handler to do so
Source - https://www.reddit.com/r/linuxhardware/comments/x97m6l/fedora_lg_gram_16_2022_12th_gen_alder_lake/ (added to the original post)

I'm happy to confirm that the kernel parameter acpi_mask_gpe=0x6E seems to fix the issue of fans blasting and high temperatures even on idle!
An observed drawback from this solution is that is breaks the functionality of the screen brighness buttons: it still works, but you can hold it, and it also has a big delay in applying each setting - This doesn't bother me as I already use some scripts with a custom keyboard shortcut to set the brighness of all my displays at once. Another solution is unmasking the GPE interrupts not through a kernel parameter, but after boot with: echo unmask > /sys/firmware/acpi/interrupts/gpe6E - This way the brightness button issues don't manifest.
Furthermore, setting the kernel parameter acpi_mask_gpe=0x6E, it could be affecting idle power draws if the values returned by GPE are used to put cpus into idle states. Thankfully the issue only happens when the laptops are charging, so it wouldn't kill battery life.
From the kernel documentation I could find:
acpi_mask_gpe=  [HW,ACPI]Due to the existence of _Lxx/_Exx, some GPEs triggeredby unsupported hardware/firmware features can result inGPE floodings that cannot be automatically disabled bythe GPE dispatcher.This facility can be used to prevent such uncontrolledGPE floodings.Format: <byte> or <bitmap-list>
So the documentation is aligned with the observations of the fix/workaround.

--
Furthermore, there is another possible fix: journalctl seems to output many ACPI errors, probably due to the miscommunication between Linux thinking it can probe for thermal info on a device which did not register a handler to do so. The ACPI issue is a flood
caused by the int3403 temp sensor library, which can be unloaded from the kernel without any other visible system effect
sudo rmmod int3403_thermal is how it's unloaded
A permanent fix seems to be patching the int3403 library to add something like
if (sensorNotPresent) then skip or unregister until next launch

--
There seems to be yet another issue related to this:
power usage goes way up to around 10W at idle (instead of like 3W) and there's a kernel thread with high load (visible in powertop) related to the i915 graphics driver
The solution seems to be:
echo 1 > /sys/kernel/debug/dri/1/i915_hpd_short_storm_ctl
That should be run on every boot to stop another interrupt flooding from happening, but this solution:
it might break multi-stream transport on DisplayPort - the short storm detection is enabled by default unless multi-stream transport is supported

--
Another finding: The laptop is by default running on  "Silent mode" which can be disabled by:
echo 1 > /sys/devices/platform/lg-laptop/fan_mode

--
The laptop indeed seems to have no BIOS updates.

--
Another issue seems to be that on some distros the laptop might thermal throttle to very low wattages, and the fix is:
systemctl disable --now thermald

--
I'm also adding to my original post a script that seems to be an elegant workaround to solve the issues observed.

(In reply to PinkFromTheFuture from comment #8)
> Doesn't happen on my LG gram from 2021.

I can confirm that on my LGGram 2021.

> 1. I didn't find any reports of this issue for the 2023 models. Did anyone?

I got a new LGGram *2023*, and yes, it DOES happen there too. (And yes, I have a 2022 LGGram as well.)

> I believe that we need either a Linux Kernel patch or a BIOS update, but
> there doesn't seem to be any updates to the BIOS of the 2022 lined up of LG
> Gram.

Fat chance! I spent a lot of time w/LG support on the phone, and their canned reply is always: "this computer is for WINDOWS ONLY. Linux need not apply!"

> 2. How can we get this fixed? Who can save us!?

Same workarounds: upon reboot (1) mask gpe0x6E, and (2) unload the int3403_thermal module. That does it for both my LGGrams 2022 and 2023. This can be elegantly done via a systemd service.

Note that, in my experience, unmasking gpe0x6E some time after reboot (as some have suggested) triggers the ACPI storm back on, so I prefer to leave it masked. I have not noticed any issues from any of these two workarounds.

Alternatively, you could go back to Windows! :-)

> 
> 3. Are there any workarounds that can be programmatically applied?

See above.

(In reply to Cristian Cocos from comment #10)
> Same workarounds: upon reboot (1) mask gpe0x6E, and (2) unload the
> int3403_thermal module. That does it for both my LGGrams 2022 and 2023. This
> can be elegantly done via a systemd service.
Thanks! I just posted the results of my saga above.

Could unloading int3403_thermal cause other issues?? I see you said it didn't cause any issues for you, but I heard it could, so I'm not using it as part of my solution (but I added it to the service file I shared, to help others)


> Note that, in my experience, unmasking gpe0x6E some time after reboot (as
> some have suggested) triggers the ACPI storm back on, so I prefer to leave
> it masked. I have not noticed any issues from any of these two workarounds.

I didn't quite understand this point and it feels important to me to understand it. Could you be more precise as to what you're doing?
I thought the solution was to unmask... But you're masking it instead?


> Alternatively, you could go back to Windows! :-)

NO WAY! Argh! lol XD
I rather spend hours trying to patch this issue! ;)

(In reply to PinkFromTheFuture from comment #11)
 
> Could unloading int3403_thermal cause other issues??

I haven't heard of any issues from anybody about that.

> I didn't quite understand this point and it feels important to me to
> understand it. Could you be more precise as to what you're doing?
> I thought the solution was to unmask... But you're masking it instead?

gpe0x6E needs to be MASKED: acpi_mask_gpe=0x6E (note the "mask" in there). *That* is what stops the ACPI storm. Some people have reported that UNmasking that ACPI interrupt some time AFTER masking it at boot-time gives you the best of both worlds, but that is not my experience. It may work in Ubuntu, but that is not what I am running. I, for one, prefer to keep it masked.

See also this: https://www.reddit.com/r/linuxhardware/comments/x97m6l/comment/izdwsxn/?utm_source=reddit&utm_medium=web2x&context=3

(In reply to PinkFromTheFuture from comment #9)
> Here is my elegant workaround to the problem:
> ```
> [Unit]
> Description=...
> # more documentation:
> #
> https://www.reddit.com/r/LGgram/comments/150p3rg/critical_bug_affecting_the_2022_lineup_on_linux/
> 
> [Service]
> Type=oneshot
> Restart=on-failure
> 
> # To resolve the issue with GPE interrupts, causing high temperatures and fan
> noise even on idle when the laptop is charging through USB-C/TB, 
> # add to the kernel parameters `acpi_mask_gpe=0x6E`
> # However, this will cause issues with the keyboard screen brightness
> shortcuts which can be resolved by adding the Unmask GPE interrupts during
> boot: 
> ExecStart=/bin/bash -c "echo 'unmask' > /sys/firmware/acpi/interrupts/gpe6E"
> 
> ...


Thanks for your workaround and explanation! 

However in my case, I found that unmask ACPI interrupt immediately after boot will bring the CPU throttle issue back. 

I've fixed it by adding a 1 minute sleep: 


```
[Service]
Type=oneshot
Restart=on-failure

ExecStartPre=/bin/sleep 60
ExecStart=/bin/bash -c "echo 'unmask' > /sys/firmware/acpi/interrupts/gpe6E"
```

Reneabling the interrupts after boot, even with one minute delay, causes the problem to come back for me, on Debian testing, with any recent kernel, on an 2022 LG Gram 16.


As a separate comment, the 'workaround' changes many other things that are unconnected to the problem, that the user may wish to set up differently.

(In reply to Ralph Martin from comment #14)
> Reneabling the interrupts after boot, even with one minute delay, causes the
> problem to come back for me, on Debian testing, with any recent kernel, on
> an 2022 LG Gram 16.

Yeah, just keep the interrupt masked and you're golden. I have not noticed any downside so far, and I have been using LG Grams for a couple of years now.

As noted in an earlier messge:
an observed drawback from [masking these interrupts]] is that it breaks the functionality of the screen brightness buttons

(In reply to Ralph Martin from comment #16)
> As noted in an earlier messge:
> an observed drawback from [masking these interrupts]] is that it breaks the
> functionality of the screen brightness buttons

Could be. I use my LG Grams mostly through docking stations, where this does not apply.

(In reply to Ralph Martin from comment #16)
> As noted in an earlier messge:
> an observed drawback from [masking these interrupts]] is that it breaks the
> functionality of the screen brightness buttons

Yeah, exactly. For the moment I have it like that because I prefere to scrifice the brightness keys (and change it manually from a widget bar or something) than  hearing all the time the fan at 100%. 

On the other hand, I was thinking if whether is possible or not to migrate (in some sense) the lecture of the brightness keys to some other acpi events with the other keyboard keys, which are 'instantaneously' read. For example the volume keys that should have a 'similar' behaviour but instead they work perfectly. 
Maybe this is not possible, I'm not expert in that, just suggesting something to you if you know something...

The brightness keys are the only easy to spot issue.
Lots of other issues happen because of the workaround.
My computer definitely behaves weirdly and seems crippled.

To the point that I am even considering just using Windows on it :'(

Anyone with more luck on this?

Even when masking with acpi_mask_gpe=0x6E, I am still getting around 5% cpu usage from each of several kworker tasks.

   122 root      20   0       0      0      0 D   6.6   0.0   0:12.72 kworker/u32:12+USBC000:00-con2
                                      
    168 root      20   0       0      0      0 R   5.6   0.0   0:08.44 kworker/0:2+events
                                                
      9 root      20   0       0      0      0 D   4.3   0.0   0:07.28 kworker/0:1+kacpi_notify
                                        
   1744 root      20   0       0      0      0 I   2.3   0.0   0:00.74 kworker/8:3-kec_query
                                           
    143 root      20   0       0      0      0 I   1.7   0.0   0:00.21 kworker/8:1-events
                                            
   1506 root      20   0 1200444 128252  89052 S   1.7   0.4   0:06.29 Xorg
                                                                
    298 root      20   0       0      0      0 I   1.0   0.0   0:01.01 kworker/8:2-events
                                 
   136 root      20   0       0      0      0 I   0.7   0.0   0:02.11 kworker/1:1-kec_query
                                           
    296 root     -51   0       0      0      0 S   0.7   0.0   0:01.21 irq/79-ELAN0E03:00
                                                
    708 root      20   0       0      0      0 I   0.7   0.0   0:00.63 kworker/10:2-mm_percpu_wq                                       

(Other unrelated tasks removed)

The above showing ACPI masking is not working around the problem is on Debian testing, with kernel 6.5.13-1

Running PopOs 22.04 LTS on 6.6.10 kernel

LG Gram 17Z90Q-K

Only have to blacklist int3403_thermal, reboot and done deal. System is snappy, brightness works as expected, no ACPI error flood.

Willing to pop around my system to help solve this problem for others if someone with more Linux experience (which is probably most of you) can direct me.

Not for me. I have blacklisted int3403_thermal, and get various threads running as above, causing the fans to start spinning, with or without masking 6E. Seems worse when not masking, 

Still happens on kernel 6.6.13.

Can you try running "rmmod ucsi_acpi" and see if that solves the issue?

Hi Diogo
thanks for that suggestion. 
rmmod ucsi_acpi does indeed seem to fix the problem.
Are there likely to be any unwanted side effects of doing this?
Ralph

Not really, UCSI is used to communicate the state of the USB-C port to the OS and also allows for the user to set the state manually, so nothing critical. What happens is that when something is plugged to the USB-C port the EC starts spamming notifications for some reason, and I am still trying to understand why.
If anyone has any suggestions I can try them out :)

(In reply to Diogo Ivo from comment #26)
> Not really, UCSI is used to communicate the state of the USB-C port to the
> OS and also allows for the user to set the state manually, so nothing
> critical. What happens is that when something is plugged to the USB-C port
> the EC starts spamming notifications for some reason, and I am still trying
> to understand why.
> If anyone has any suggestions I can try them out :)

Have you tried masking gpe0x6E + rmmod int3403_thermal? Does that do it for you?

Note that there are two distinct problems here, and I am not sure how related they are:
1. ACPI error flood;
2. High CPU usage.

Which one of these is rmmod ucsi_acpi a fix for?

This fix does not deal with the ACPI flood (in fact on my system I don't see that) and only addresses the high CPU usage.

What is happening, at least on my system and I suspect on the remaining ones as well, is that there is some bug regarding UCSI and the EC keeps reporting events to the CPU via a interrupt when there is something connected to a USB-C port, leading to high CPU usage.

Since the CPU gets notified through GPE0x6E masking it does also fix the issue, at the expense of all the other functionality also covered by the EC, so this is not the best approach IMHO. rmmod int3403_thermal does nothing on my system.

I will try to dig deeper into the ucsi driver and see if there is anything we can do there or if this is just a firmware bug in the EC and in that case I am unsure of what the best approach is.

(In reply to Diogo Ivo from comment #28)
> This fix does not deal with the ACPI flood (in fact on my system I don't see
> that) and only addresses the high CPU usage.

If I remember correctly, the ACPI flood only happens if you hook up your computer to a Thunderbolt docking station (and(?) run an external monitor on the docking station). Do you have any of those lying around?

As for issue #2, if it works, your fix would, indeed, be better than masking gpe0x6E. I'll give it a try, and report back.

I can confirm: prima facie, rmmod ucsi_acpi works fine as a substitute for masking gpe0x6E. If it is proven over time to have less of an impact on the system as a whole, I think we have a winner!

(NB: rmmod int3403_thermal is still needed to stem the ACPI flood.)

I am also going to test the solution with rmmod ucsi_acpi, without the masking of gpe6E.

Please keep in mind that our solution consists of first masking it with the grub options, but after the system has booted, we unmask it - it does not stay masked.

I believe the solution using rmmod ucsi_acpi could have cosnequences when it coems to battery management, or interfacing with usb devices, so I'm curious to learn more about it.

(In reply to Cristian Cocos from comment #29)
> If I remember correctly, the ACPI flood only happens if you hook up your
> computer to a Thunderbolt docking station (and(?) run an external monitor on
> the docking station). Do you have any of those lying around?

False, it happens when anything is connected on the USB-C port, including the charging cable.

Ok, so when you do that masking and unmasking can you check if something regarding an UCSI timeout appears in the dmesg?

(In reply to PinkFromTheFuture from comment #31)
> Please keep in mind that our solution consists of first masking it with the
> grub options, but after the system has booted, we unmask it - it does not
> stay masked.

Masking at boot-time and unmasking some time afterward does not always work (see, e.g., comment #14 above). To make sure the issue has been fixed, the mask needs to stay on all the time. This is my experience.

(In reply to Cristian Cocos from comment #33)
> (In reply to PinkFromTheFuture from comment #31)
> > Please keep in mind that our solution consists of first masking it with the
> > grub options, but after the system has booted, we unmask it - it does not
> > stay masked.
> 
> Masking at boot-time and unmasking some time afterward does not always work
> (see, e.g., comment #14 above). To make sure the issue has been fixed, the
> mask needs to stay on all the time. This is my experience.

Same experience with me, unless I add to my service:
```
ExecStartPre=/bin/sleep 120
```

Before unmasking it.

(In reply to Diogo Ivo from comment #32)
> Ok, so when you do that masking and unmasking can you check if something
> regarding an UCSI timeout appears in the dmesg?

Yes. How?

Just  do the following?
```
sudo dmesg
```

Or maybe I can grep the output?

Yes, sudo dmesg and then check if there is anything regarding ucsi by grepping; if you can it would be nice to send the full log to this thread.

(In reply to Diogo Ivo from comment #35)
> Yes, sudo dmesg and then check if there is anything regarding ucsi by
> grepping; if you can it would be nice to send the full log to this thread.

I have an LG gram 15ZD90R. This is what I get

$ sudo dmesg | grep ucsi
[    9.430616] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

I forgot to say that it's an Intel i7-1360p and I'm booting with this:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_mask_gpe=0x6E"

This makes sense, when you mask GPE 0x6E during boot the initialization of the UCSI driver fails with this timeout and then it is safe for us to unmask the GPE again since the driver will not care for the EC UCSI notifications.

Thank you for checking!

I have been investigating this problem and I have found out that the UCSI implementation in these laptops does not conform to the UCSI specification in multiple locations.
I am trying to figure out the best way to approach this to mainline a fix but for the moment being my recommendation is to just 'rmmod ucsi_acpi'. Since the goal of this functionality is only to report the current state of the USB-C connectors to the OS there will be no change in how the system operates, as this control will still be done by the EC regardless.

(In reply to Diogo Ivo from comment #39)
> I have been investigating this problem and I have found out that the UCSI
> implementation in these laptops does not conform to the UCSI specification
> in multiple locations.
> I am trying to figure out the best way to approach this to mainline a fix
> but for the moment being my recommendation is to just 'rmmod ucsi_acpi'.
> Since the goal of this functionality is only to report the current state of
> the USB-C connectors to the OS there will be no change in how the system
> operates, as this control will still be done by the EC regardless.

I was just going to ask if this was an Intel problem, or an LG one, but I guess it's LG's fault, right?

And I guess that should be fixed in the BIOS, and they won't do it, because afaik, LG doesn't release BIOS fixes...

Yeah, the fix should come from LG but as you said they are not providing BIOS updates. What happens in these situations is that we accept that the thing is buggy and add quirks for these devices to the drivers (the UCSI driver already has quirks for Dell and Asus laptops).

Hello,

I think I have a fix for this problem and would like your help in confirming that the fix does indeed work and to collect all of the affected models. For that I would really appreciate that everyone that is able to compile and run their own kernel tries out the patch in the link below [1] and to report their findings here, namely if it worked or not and the specific model of the laptop. I can also provide a compiled kernel module with the patch applied if that is more convenient.

Thanks!

[1]: https://lore.kernel.org/linux-usb/5qc55gruhn4pmutiukohauki5dehba6n2k22jgvpt7i3hafkon@v2ng2a33o7vv/T/#u

Created attachment 306276 [details]
attachment-25303-0.html

Great news! But could you also provide instructions on how to easily do
what you are asking us to do? I would be happy to help, but I don't have
time to tinker with it too much right now.


I imagine we should also disable the workarounds that we put into place?

On Thu, May 9, 2024 at 8:42 AM <bugzilla-daemon@kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=217076
>
> --- Comment #42 from Diogo Ivo (diogo.ivo@tecnico.ulisboa.pt) ---
> Hello,
>
> I think I have a fix for this problem and would like your help in
> confirming
> that the fix does indeed work and to collect all of the affected models.
> For
> that I would really appreciate that everyone that is able to compile and
> run
> their own kernel tries out the patch in the link below [1] and to report
> their
> findings here, namely if it worked or not and the specific model of the
> laptop.
> I can also provide a compiled kernel module with the patch applied if that
> is
> more convenient.
>
> Thanks!
>
> [1]:
>
>
> https://lore.kernel.org/linux-usb/5qc55gruhn4pmutiukohauki5dehba6n2k22jgvpt7i3hafkon@v2ng2a33o7vv/T/#u
>
> --
> 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.

Same for me, but I don't know how I can compile the kernel by myself. I usually use zen kernel.

Hi Diogo,
it would probably be easier for many of us if you could provide the module and instructions on how to use it...
Thanks.
Ralph

Created attachment 306277 [details]
Stock ucsi_acpi kernel module with debug prints

Created attachment 306278 [details]
Fixed ucsi_acpi kernel module with debug prints

Ok, I have submitted two versions of the kernel module: ucsi_acpi_old.ko and ucsi_acpi_fix.ko. Both of them print debug messages to dmesg.

Important:

These should only fix the problem for laptops with a model like xxZ90Qxx (example: 16Z90Q-xxxx); if your model does not contain the exact string Z90Q then you can skip the following for now and please let me know what your exact model number is so that I can add support for those models as well.

In order to use them you need to:

Download modules, place them somewhere and cd to that folder, then open a terminal on that folder and, with everything unplugged from USB-C ports, do:

sudo dmesg -w // Do this in another terminal window

sudo rmmod ucsi_acpi
sudo insmod -f ucsi_acpi_old.ko // Insert the stock module with debug info

Let it finish outputting things to dmesg and then connect something to a USB-C port, wait a few seconds and then disconnect.
Collect the logs from that to a file

Then:

sudo rmmod ucsi_acpi
sudo insmod -f ucsi_acpi_fix.ko // Insert the (hopefully) fixed module with debug info

Again, let it finish outputting things to dmesg and then connect something to a USB-C port, wait a few seconds and then disconnect.
Collect the logs from that to a file.

Finally,

sudo rmmod ucsi_acpi

When all of this is done please send the files to this thread so that I can see if this is working.

Thank you for testing this, it is really helpful :)

Model 16Z90Q-K.AD78A1

Unfortunately, I get the below trying to unload then insert your (old) module:

rmmod: ERROR: Module ucsi_acpi is not currently loaded

insmod: ERROR: could not insert module ucsi_acpi_old.ko: Key was rejected by service

The first message is presumably because I had originally blacklisted the module.

The second also  resulted in the following in the dmesg window:

Loading of unsigned module is rejected

I guess this is because I am using secure boot.

Is there anything else I can do (can I disable secure boot on a temporary basis?)

OK, I used mokutil to turn off secure boot, but when I tried to insert the old version of your module I got 

insmod: ERROR: could not insert module ucsi_acpi_old.ko: Invalid module format

and in the log 

 module ucsi_acpi: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time

uname -a reports I am running the following kernel on debian testing


Linux gram 6.7.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24) x86_64 GNU/Linux

I also tried 6.5 and 6.6 series kernels, with the same outcome.

Hi Diogo, 
any suggestion  how I can proceed beyond the error message I reported when trying to install your patched module?
Thanks
Ralph

Hi Ralph,

I guess the only option is to compile the kernel module from source. I'll place the patches and instructions here soon.

Thanks,
Diogo

Hello,

The updated instructions are:

 - Get the kernel source from kernel.org (v6.9.1) and extract it to a folder. Download both debug.patch and fix.patch as well.

 - Extract the kernel tarball:
      tar xf linux-6.9.1.tar.xz

 - cd into the folder where the kernel was extracted and apply only debug.patch:
       git apply /path/to/debug.patch

 - Compile the modules with:
       make -C /lib/modules/`uname -r`/build M=$PWD/drivers/usb/typec/ucsi/

 - Remove both ucsi_acpi and typec_ucsi:
       sudo rmmod ucsi_acpi
       sudo rmmod typec_ucsi

 - Insert the compiled versions of the modules (with all USB-C cables unplugged):
       sudo insmod drivers/usb/typec/ucsi/typec_ucsi.ko
       sudo insmod drivers/usb/typec/ucsi/ucsi_acpi.ko

Then follow the procedure I described in the previous instruction post to obtain the log file. When this is done

 - Apply fix.patch on top:
       git apply /path/to/fix.patch

- Compile the modules with:
       make -C /lib/modules/`uname -r`/build M=$PWD/drivers/usb/typec/ucsi/

 - Remove ucsi_acpi:
       sudo rmmod ucsi_acpi

 - Insert the updated version of the module (with all USB-C cables unplugged):
       sudo insmod drivers/usb/typec/ucsi/ucsi_acpi.ko

And again follow the procedure described above to get the log file.

Hopefully these instructions are clear. If you need further clarification I'll be happy to help!

Thanks,
Diogo

Created attachment 306314 [details]
Debug patch

Created attachment 306315 [details]
Fix patch

Hi Diogo

I followed your instructions (I am using the current testing kernel 6.7.12), building the module with the 6.9.1 sources, disabling safe boot, and got

insmod: ERROR: could not insert module drivers/usb/typec/ucsi/typec_ucsi.ko: Unknown symbol in module

insmod: ERROR: could not insert module drivers/usb/typec/ucsi/ucsi_acpi.ko: Unknown symbol in module

when trying to insert the compiled modules.

(ucsi_acpi is blacklisted at boot, but that does not sound like it is the problem

so it was not unexpected that I got the following when trying to unload the existing modules

rmmod: ERROR: Module ucsi_acpi is not currently loaded

rmmod: ERROR: Module typec_ucsi is not currently loaded

Happy to try again if there is something else I can do. Perhaps I really need to build a new kernel - time I learnt how to do that?

Hi Diogo

When I try to compile the modules following your instructions, I got

Skipping BTF generation for /home/ralph/Downloads/linux-6.9.1/drivers/usb/typec/ucsi/ucsi_acpi.ko due to unavailability of vmlinux

It was not clear if that was essential or not. I tried to fix this up, but after copying `/sys/kernel/btf/vmlinux` to corresponding position and with
`dwarves` installed, building the kernel module throws an error: 
`/bin/sh: 1: ./tools/bpf/resolve_btfids/resolve_btfids: not found`.

I see  Bug#1027306: mentions this issue. 

I am getting further from trying out your fix it seems, rather than closer...

Hi Ralph,

Thank you for trying the instructions. You can safely ignore the BTF related stuff, don't worry about it :). Do you have any newer kernels pre-built that you can try running on your system?

Logs now collected with your guidance, and emailed to you.

I can also confirm that with your patch, I no longer see lots of kworker tasks eating up cpu associated with plugging in usb devices.

Thanks for helping resolve this issue.

Hi Ralph,

That's great, thank you for your time! So this is confirmed working on the 16Z90Q by both me and you.

It would be great if people with the other affected models chimed in as well so we can fix this everywhere. If anyone has a model other than the 16Z90Q you can write to me here or via e-mail and I'll be happy to help you get this tested.

Thank you very much Diogo. My model is 17ZD90Q, with the D in the middle, which right now I don't remember exactly what was its meaning (maybe without OS by default?). Let me know if it should work, thanks in advance.

Hi Víctor,

If you are seeing the problem then it should work :)

Can you send me an e-mail with the distro you are using and current kernel version?

Thanks!

Hi Diogo,

Thank you so much for the patch! I have a 2023 LG Gram 17Z90R model (17Z90R-G.CD7BC to be exact) and I'm experiencing the same problem that can't be fixed by `rmmod int3403_thermal`. I'm using Arch with kernel 6.9.3-arch1-1. Given that the vast majority of contributors here are using models ending with 90Q, I was wondering if the kernel patch above would work for me as well. I'd be more than happy to share my logs with you if you need additional information to determine the compatibility.

Thanks!

Hi Lyn,

To see if the problem is the same as the 1xZ90Q models can you follow the procedure I described in comment 48? Just the part that refers to ucsi_acpi_old.ko as this is enough for me to see if the problem is the same.

Let me know if you encounter any problems.

Thanks!

Diogo

I am currently using a ThinkPad X1 Carbon Gen 8 with an Intel(R) Core(TM) i7-10510U CPU. My kernel version is 6.9.3-arch1-1. I am encountering an issue with kacpi_notify threads running at 100% usage. When I set the governor through cpupower to "performance," the sensors quickly show temperatures of up to 90+ degrees Celsius.

This issue persists even when no devices are connected to the USB-C port, and even when the laptop is completely unplugged. The problem is temporarily resolved by utilizing the suspend/wake functionality, but it reoccurs after the next reboot. I am eagerly anticipating a permanent solution to this problem.

Hi Diogo,

Logs collected and emailed to you, thanks!

Hi Diogo,
any idea when your fix will become official?
Thanks
Ralph

Hello,

I have submitted the patch here:

https://lore.kernel.org/linux-usb/20240612-gram_quirk-v1-1-52b0ff0e1546@tecnico.ulisboa.pt/

and it already has the Reviewed-by from the UCSI driver maintainer,
so if all goes well we could see this in Linux 6.11.
If there are any updates I'll be sure to post them here!

Thanks,
Diogo

(In reply to Diogo Ivo from comment #70)
> Hello,
> 
> I have submitted the patch here:
> 
> https://lore.kernel.org/linux-usb/20240612-gram_quirk-v1-1-
> 52b0ff0e1546@tecnico.ulisboa.pt/
> 
> and it already has the Reviewed-by from the UCSI driver maintainer,
> so if all goes well we could see this in Linux 6.11.
> If there are any updates I'll be sure to post them here!
> 
> Thanks,
> Diogo

Hi Diogo,

I cannot thank you enough for your involvement in resolving this issue.

The how and whys of the fix go beyond my understanding, but I'm really glad to see this on the way to be resolved!

Thank you so much!

The question is who among us would not build a monument for Diogo...

Thanks a lot!

Excellent! Thank you again, Diogo for your assistance with this quirk of the LG Gram series.

I can confirm that I have built a new version of your module using your patch, with your debugging code stripped out, and have been using it a while now with Debian testing kernel 6.7.12, to great effect and no side effects as far as I can see. It is also working well with kernel 6.8.12, since this morning.

Ralph

Good news, the fix has been merged and will make it into Linux 6.10, one version sooner than expected! You can find the commit here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9e3caa9dd51b23e232f095a98336a84f42e4a7f2

Since we are in 6.10-rc6 I expected that the final kernel version will be released in about two weeks time, meaning that if you are running a rolling release distro you should get it around this time as well. For other distros I don't know when they will package 6.10 (or later) kernels, but keep an eye out for it.

Excellent news! Thanks again, Diogo!

Unfortunately I bring bad news: I'm still experiencing this issue when I plug the computer to my Thunderbolt hub and it starts charging. I'm running:

$ uname -a
Linux epiphyte 6.10.7-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 30 00:08:59 UTC 2024 x86_64 GNU/Linux

And it's a LG Gram 14Z90Q. So, in theory, I'm running your fix, right? However, as I said, I still experience this issue. :( Should we open a new bug?

I am not experiencing this issue with Debian testing and Linux 6.10.6. The fix still seems to be working for me.

I do however see some ACPI UCSI issues in the log which may or may not be relevant:

Sep 02 06:53:18 gram kernel: ucsi_acpi USBC000:00: failed to reset PPM!
Sep 02 06:53:18 gram kernel: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

I see the following log messages:

kernel: ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-34)
kernel: ucsi_acpi USBC000:00: unknown error 4104
kernel: ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)

And the kworker/u64:19+USBC000:00-con2 keeps spinning, and the IRQ 9 storm continues.

(In reply to Iñaki Ucar from comment #76)
> Unfortunately I bring bad news: I'm still experiencing this issue when I
> plug the computer to my Thunderbolt hub and it starts charging. I'm running:
> 
> $ uname -a
> Linux epiphyte 6.10.7-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 30
> 00:08:59 UTC 2024 x86_64 GNU/Linux
> 
> And it's a LG Gram 14Z90Q. So, in theory, I'm running your fix, right?
> However, as I said, I still experience this issue. :( Should we open a new
> bug?

6.10.7 has the fix from this bug-report yes.

So either the fix is not working, or the DMI match does not work for your laptop model.

Can you provide the output of running the following command as a normal user:

grep . /sys/class/dmi/id/* 2> /dev/null

please?

Sure, here it is:

$ grep . /sys/class/dmi/id/* 2> /dev/null
/sys/class/dmi/id/bios_date:12/06/2022
/sys/class/dmi/id/bios_release:0.1
/sys/class/dmi/id/bios_vendor:Phoenix Technologies Ltd.
/sys/class/dmi/id/bios_version:A1ZG0420 X64
/sys/class/dmi/id/board_asset_tag:Base Board Asset Tag
/sys/class/dmi/id/board_name:14Z90Q
/sys/class/dmi/id/board_vendor:LG Electronics
/sys/class/dmi/id/board_version:FAB1
/sys/class/dmi/id/chassis_asset_tag:Asset Tag
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:LG Electronics
/sys/class/dmi/id/chassis_version:0.1
/sys/class/dmi/id/ec_firmware_release:38.0
/sys/class/dmi/id/modalias:dmi:bvnPhoenixTechnologiesLtd.:bvrA1ZG0420X64:bd12/06/2022:br0.1:efr38.0:svnLGElectronics:pn14Z90Q-G.AD78B:pvr0.1:rvnLGElectronics:rn14Z90Q:rvrFAB1:cvnLGElectronics:ct10:cvr0.1:skuEVO:
/sys/class/dmi/id/product_family:LG gram PC
/sys/class/dmi/id/product_name:14Z90Q-G.AD78B
/sys/class/dmi/id/product_sku:EVO
/sys/class/dmi/id/product_version:0.1
/sys/class/dmi/id/sys_vendor:LG Electronics
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnPhoenixTechnologiesLtd.:bvrA1ZG0420X64:bd12/06/2022:br0.1:efr38.0:svnLGElectronics:pn14Z90Q-G.AD78B:pvr0.1:rvnLGElectronics:rn14Z90Q:rvrFAB1:cvnLGElectronics:ct10:cvr0.1:skuEVO:

The functions added in the patch should be running correctly, right?

Confirmed. I did:

$ sudo stap -v -e 'probe module("ucsi_acpi").function("ucsi_gram_read").call { log("patch working") }'

and "patch working" is printed out.

I found a workaround. The steps are:

0. Starting with the laptop disconnected (to the Thunderbolt hub).
1. Run "echo mask > /sys/firmware/acpi/interrupts/gpe6E"
2. Connect the laptop to the Thunderbolt hub.
3. Run "echo unmask > /sys/firmware/acpi/interrupts/gpe6E"

And in this way I see no interrupt storm. Could it be some timing issue?

> The functions added in the patch should be running correctly, right?

Right, the DMI match should match your laptop as you have already confirmed yourself.

> I found a workaround. The steps are: ...

Ok, this points to the same issue of an interrupt storm happening if UCSI events are enabled during plug in as which this bug was originally about.

So it seems that the fix for this bug is not complete and there still is some scenario where plugging in a thunderbolt dock can cause the storm. I wonder if the original fix only fixes the charger case and the thunderbolt dock is causing some other (non charger) events which are not filtered by the fix.

Diggo since you debugged and fixed the original issue, can you work with Iñaki to try and also fix his interrupt storm issue ?

Currently on 6.10.12 kernel. Up until a week ago things worked fine in my case with the following two hacks:

1. rmmod int3403_thermal
2. rmmod ucsi_acpi

Lately, don't exactly recall the kernel version, that doesn't do it anymore: gpe6E interrupt flood started happening again. The only thing that stems this new flood is masking gpe6E again.

In short, masking gpe6E needs to be added to the above two hacks.

Hi, sorry for the late reply, I haven't had much time to look into this.

It seems that for both cases you (Iñaki and Cristian) are reporting the problem comes from connecting a Thunderbolt hub to the laptop, so what Hans said makes sense and is a good place to start looking into.

Are you comfortable compiling your own kernel/kernel modules? If so I'll post a new debug patch so we can start looking into it.

Thanks,
Diogo

Thanks, Diogo. We can leverage the Fedora kernel package + infra for this.

Great!

In that case since you are running a 6.10.x kernel the patch is basically the debug.patch attachment in this thread. I don't know if it will apply cleanly but if it doesn't it should be simple to add the print statements by hand as well and then follow the instructions I posted earlier in order to get a dmesg log.

Let me know if you need assistance for this.
Diogo

We have v6.10.12 and the patch doesn't apply cleanly anymore I'm afraid.

In that case do you mind applying the print statements by hand? It's a bit annoying but if you could do it I could start taking a look at it tomorrow. If you can't I'll post a new patch tomorrow and we'll go from there.

Thanks!
Diogo

Created attachment 306963 [details]
v6.10.12 with debug prints

If you just need these prints, I think it's easier if I plug them using systemtap instead of creating a patch, recompiling the kernel and so on. I replicated your debug patch with systemtap and I attach here the output when I plug the laptop into the hub. Please let me know if you need prints in other places or for other variables.

Created attachment 306964 [details]
v6.10.12 function calls

I did the same "exercise" as above, but in this case, I instructed systemtap to print a line for every function call in the typec_usci or usci_acpi modules, just in case this is useful. The numbers at each line start are microseconds (since the script was launched).

Thanks, the prints should be enough. I did not know about systemtap, would have saved me some time as well :)

And just to confirm, do the prints keep being emitted for as long as the dock is connected?

The log ends when I killed the script producing them after a few seconds, but yes, the prints keep going.

Created attachment 306966 [details]
systemtap script for debug prints

For your reference, this is the script I used to generate the debug prints as follows:

$ sudo stap -vg ucsi.stap > ucsi.log

Hmm, does systemtap allow you to specify where in the function you want the prints to happen? The logs you sent me are not printing the command correctly because the print is happening before we set ua->cmd with the new command, so we print the old one.

If you can't specify where the print occurs and it is always in the beginning of the function then we actually need to print the val function argument.

Created attachment 306967 [details]
debug_6.10

The debug statements need to be in those exact positions

Oh, I see. It should be statement 61, not 59 in my script above. Let me try again.

Created attachment 306968 [details]
v6.10.12 with debug prints

Let me know if this one is ok.

Unfortunately it's still printing the previous command.

Are you sure? I'm printing:

- val at line 61 (return)
- ua->cmd at line 72 (return)
- cci at line 213 (after the conditional return)

Yes, I am sure.

The first command that should be printed is a GET_CONNECTOR_STATUS, that ends with 0x12 (in the case of that port 0x20012 and in case of using the other port 0x10012), while in the log the first one we get is an ACK_CC_CI (ending in 0x4), from the last command before plugging in the charger.

And could this be the issue? That the order of the calls is wrong and then the module is processing the previous command? Because I don't see any issues in the systemtap script. If I increment the line offset, systemtap tells me that I'm going outside the function and I get a compilation error.

No, this order is core code in ucsi_handle_connector_change(), where you can see that the first thing that happens is GET_CONNECTOR_STATUS. Could you try just printing out *val rather than ua->cmd and see if that changes things?

Created attachment 306969 [details]
v6.10.12 with debug prints

I'm now printing the following at line 72:

STAP_PRINTF("COMMAND (ua): %llx\n", ((struct ucsi_acpi *)STAP_ARG_ua)->cmd);
STAP_PRINTF("COMMAND (val): %llx\n", *(uint64_t *)STAP_ARG_val);

Why are these values different in the trace attached? I have no idea.

Created attachment 306970 [details]
v6.10.12 with debug prints (successful connection and disconnection)

Sometimes, randomly, it works fine. I got one of these successful connections (lines 1-20), and disconnection (21-30), just in case this is useful.

So guys, what's the latest on this please? Anyone working on it?

Diogo, please let me know if the previous attachments are useful or you need anything else. Thanks!

I've been quite busy lately to look at this; hopefully that will change soon so we can have this fixed.

Iñaki, thanks for your availability. I'll probably need some more info when I start looking into this so I'll contact you at that point.

Created attachment 307018 [details]
Output of the logging patch for LG Gram 17Z90SP

I am also experiencing this on LG Gram 17 Pro 2024 (`17Z90SP-G.AA78G`) running `6.11.2-4-MANJARO`.

The workaround of `rmmod ucsi_acpi` works for me for now.

I have also tried 6.12.0-rc3 (c964ced7726294d40913f2127c3f185a92cb4a41) and can observe the same result there. Afterwards i also tried modifying the quirks section for my device id, but there i had the same result.

Additionally i have also tried the patch with logging (see attachment `patch-output-17z90sp.log` messages collected for 1 minute).

Relevant dmi id output:

```
$ grep . /sys/class/dmi/id/* 2> /dev/null
/sys/class/dmi/id/bios_date:02/23/2024
/sys/class/dmi/id/bios_release:0.1
/sys/class/dmi/id/bios_vendor:Phoenix Technologies Ltd.
/sys/class/dmi/id/bios_version:M2ZI0440 X64
/sys/class/dmi/id/board_asset_tag:Base Board Asset Tag
/sys/class/dmi/id/board_name:17Z90SP
/sys/class/dmi/id/board_vendor:LG Electronics
/sys/class/dmi/id/board_version:FAB1
/sys/class/dmi/id/chassis_asset_tag:Asset Tag
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:LG Electronics
/sys/class/dmi/id/chassis_version:0.1
/sys/class/dmi/id/ec_firmware_release:48.0
/sys/class/dmi/id/modalias:dmi:bvnPhoenixTechnologiesLtd.:bvrM2ZI0440X64:bd02/23/2024:br0.1:efr48.0:svnLGElectronics:pn17Z90SP-G.AA78G:pvr0.1:rvnLGElectronics:rn17Z90SP:rvrFAB1:cvnLGElectronics:ct10:cvr0.1:skuEVO:
/sys/class/dmi/id/product_family:gram PC
/sys/class/dmi/id/product_name:17Z90SP-G.AA78G
/sys/class/dmi/id/product_sku:EVO
/sys/class/dmi/id/product_version:0.1
/sys/class/dmi/id/sys_vendor:LG Electronics
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnPhoenixTechnologiesLtd.:bvrM2ZI0440X64:bd02/23/2024:br0.1:efr48.0:svnLGElectronics:pn17Z90SP-G.AA78G:pvr0.1:rvnLGElectronics:rn17Z90SP:rvrFAB1:cvnLGElectronics:ct10:cvr0.1:skuEVO:
```

Small update: here I'm running kernel 6.11.7-300.fc41.x86_64. Same issue.