Thinkpad Yoga c13 CPU Locked to 400MHz

jonas5 · January 14, 2024, 4:20pm

[Issue]
At some stage the CPU gets throttled and overheated.
This sends the laptop into CPU locked to 400 MHz on all cores, this makes the laptop utilise only ~20% of it full potential (the battery will last for ages). The laptop wont switch back automatically.

[OS]
Linux / Ubuntu 23.04

[BIOS]
MrChromebox-4.22.0-5-g1da77761371

[specs]
Yoga is an AMD R5 3500c, (*1)
base frequency at 2.1 GHz
Boost to 3.7 GHz
Idle at 1.4 GHz

[Possible solutions]
I have been reading up and down google on other forms, there seems to be a common issue with certain AMD CPU’s(also intel) and has to do with the possible solutions of:
A) power brick not being powerful enough to engage full mode
B) Something to do with the battery not being able to turn off this “limp mode”.

This last option is usually done in bios on other laptops(*2), but as custom bios has not this option, try disconnect the battery and boot the laptop only via Power outlet, this CPU lock of 400 MHz should be switched back to normal.

Similar issues has been identified by vendors and being patched with a new bios update. (*3)

[troubleshooting that has been unsuccessful]
a) cpufreq-set (of any kind)
b) changing governor profile to performance (*4)

[source]

s31bz · January 14, 2024, 8:58pm

I’m on a slightly newer release of this firmware and I’m not experiencing this issue:

	Vendor: coreboot
	Version: MrChromebox-4.22.0-6-g135ae7306d6
	Release Date: 01/08/2024
	ROM Size: 16 MB

This Ryzen 5 “C” edition is a lower power version of the Ryzen 5 3600, so it likely won’t have “high performance” modes in the gnome battery dropdown menu.
I’m also running Fedora for what that’s worth:

s31bz · January 14, 2024, 9:07pm

So, for now, I’d say to either update coreboot and make sure you’re on an up to date 6.5+ kernel and see if things are working, or try other distros that have more up to date software and see if those function differently. If running Ubuntu, I’d recommend something more recent than outdated and out-of-support 23.04- mayb 23.10 or the 24.04 beta: https://ubuntu.com/download/desktop

jonas5 · January 14, 2024, 9:19pm

Thanks for your input, I appreciate it very much.

This issue happens once a blue moon when the laptop has been on for a good while, rather unattended during the night and the thermal throttling has kicked in.

I do not get the option to install the MrChromebox-4.22.0-6-g135ae7306d6 version ?
Their roadmap says something about once per quarter?

As seen in sources, there are other with this issue sent in for RMA or others have done a bios update.

If this is an issue resolved with detaching the battery, maybe the battery(firmware?) is bad?
Kernel 6.5, 6.6.9 and 6.7.0 is giving some issues and this was working fine before 4.22.

Issue persist on 23.10 (ubuntu) as far as I know.

s31bz · January 14, 2024, 9:28pm

Interesting. Does the firmware update script not offer you the option of that newer version?

s31bz · January 14, 2024, 9:33pm

Also I haven’t seen unplugging and replugging the battery affect any sort of performance on my unit, but your mileage may vary.
Maybe I haven’t had this issue because I’ve only been running Fedora 39 or openSUSE Tumbleweed on my unit? I don’t know. Might be worth a look.

On the topic of Ubuntu-based distros, I used to work at System76 and recall that they liked to push newer kernels/wayland support/audio drivers/cpu schedulers so maybe give Pop!_OS an install?

Also, when in the firmware update utility script, what does yours look like? I installed Full ROM firmware on mine, so this is what I’m seeing…maybe you need to do Full ROM instead of RW_Legacy to get access to the newer coreboot BIOS?
Screenshot from 2024-01-14 14-33-12

jonas5 · January 14, 2024, 9:47pm

ChromeOS Device Firmware Utility Script [2024-01-07]
(c) Mr Chromebox [email protected]

** Device: Lenovo ThinkPad C13 Yoga Chromebook (MORPHIUS)
** Platform: AMD Picasso
** Fw Type: Full ROM / UEFI
** Fw Ver: MrChromebox-4.22.0-5-g1da77761371 (01/04/2024)
** Update Available (01/07/2024)

When I try to update it wont give me the update from 01/07 but 01/04.
I have tried to manually install it from an USB device (coreboot_edk2-morphius-mrchromebox_20240107.rom) but no luck.

s31bz · January 14, 2024, 9:49pm

If you run that firmware update natively from your Ubuntu install, and then reboot, are you then on the 0107 update? You should be able to get the 0108 update from there.

jonas5 · January 14, 2024, 9:53pm

do you have the official filename for the 0108 release? maybe I can grab it manually?

jonas5 · January 14, 2024, 10:13pm

from the github; scripts/sources.sh at master · MrChromebox/scripts · GitHub

export coreboot_uefi_morphius=“coreboot_edk2-morphius-mrchromebox_20240107.rom”
export coreboot_uefi_morphius_tp=“coreboot_edk2-morphius_tp-mrchromebox_20240107.rom”

jonas5 · January 14, 2024, 10:49pm

For me it looks like the file stored on the repository of mrchromebox.tech is incorrect.

# wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_edk2-morphius-mrchromebox_20240107.rom
# strings coreboot_edk2-morphius-mrchromebox_20240107.rom

/* build system definitions (autogenerated) */
#ifndef __BUILD_H
#define __BUILD_H
#define COREBOOT_VERSION "4.22-104-g1da777613710"
/* timesource: git */
#define COREBOOT_VERSION_TIMESTAMP 1704386719
#define COREBOOT_ORIGIN_GIT_REVISION "1da777613710"
#define COREBOOT_EXTRA_VERSION "-MrChromebox-4.22.0-5-g1da77761371"
#define COREBOOT_MAJOR_VERSION 4
#define COREBOOT_MINOR_VERSION 22
#define COREBOOT_BUILD "Thu Jan 04 16:45:19 UTC 2024"
#define COREBOOT_BUILD_YEAR_BCD 0x24
#define COREBOOT_BUILD_MONTH_BCD 0x01
#define COREBOOT_BUILD_DAY_BCD 0x04
#define COREBOOT_BUILD_WEEKDAY_BCD 0x4
#define COREBOOT_BUILD_EPOCH "1704386719"
#define COREBOOT_DMI_DATE "01/04/2024"
#define COREBOOT_COMPILE_TIME "16:45:19"
#define ASL_VERSION 0x20230628
#endif

if you have a different version, from where?

s31bz · January 15, 2024, 10:26pm

Hmm, this should be working for you.

When you update are you booting to a full local install of Ubuntu 23.10 or newer and then running the update script?

I saw in another forum post that the team here doesn’t support Ubuntu, which is understandable. If you can’t run the update script from a more-recent Ubuntu install, I would recommend to boot to a Fedora USB installer:

Then, when booted from the live USB, run the update script:

Then reboot and you should be in the new release.

jonas5 · January 16, 2024, 12:32am

Hello again!

So, issue is partly resolved and not.
And yes I ended up reinstalling to Ubuntu 23.04(lunar) as it has 6.2.x kernel.

First of all, the firmware on the repository that does not have the TP(touchpad) must be incorrect version.
I managed to upgrade to 01/08 using the TP version.

So apparently updating to 23.10 something did remove the iommu=pt tag in default grub loader. which created a chain of problems.
When the problem triggered, it had to be reset from disconnecting the battery, then load a kernel with 6.2.x including a iommu=pt (even via usb boot install).

It seems like the laptop now is able to switch on and off power mode fine accordingly to heat and running power supply or battery.

Next is to see how it works for the newer kernels i suppose.

s31bz · January 17, 2024, 10:54pm

Yup, I always recommend checking distros or newer releases of distros running the most recent kernel before attempting to correct a problem on a possibly older release. Lemme know how the newer kernels are running.

s31bz · January 19, 2024, 5:56pm

Just checking back in here. Have you tried an up-to-date install of Fedora 39 gnome, Ubuntu 23.10 with kernel 6.6+ or Linux Mint Debian Edition on your Morphius? How are things working?

s31bz · January 23, 2024, 7:49am

we can probably close this

jonas5 · January 23, 2024, 9:09pm

Sorry I am having issues to test anything newer than 6.2.
6.5, 6.6, 6.7, 6.8-rc1 > Has all same issues with iommu (i do believe).
It pretty much stalls during the boot and mounting /boot/efi, in the same way that older kernels than 6.2 would without iommu=pt in grub.

If/when it works or takes it sweet time(4-5 mins), none of the pci devices works, eg wifi and mouse (touchpad). I cannot locate the exact issue, but I believe that would be a separate issue to this topic.

But – It works some times.
I am still investigation to see when it issue occurs, currently running 6.8-rc1,
I have seen others experiencing the same, with just idling the laptop over night.

cat /proc/cpuinfo | grep MHz (on battery - idle)
cpu MHz : 1242.566
cpu MHz : 1400.000
cpu MHz : 1319.239
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1320.019
cpu MHz : 2100.000

cat /proc/cpuinfo | grep MHz (on charger with load)
cpu MHz : 3229.245
cpu MHz : 3229.244
cpu MHz : 3228.757
cpu MHz : 3228.788
cpu MHz : 3229.262
cpu MHz : 3229.251
cpu MHz : 3228.940
cpu MHz : 3228.949

currently upgraded to: Version: MrChromebox-4.22.2
But there were only a few updates for intel sata ?

s31bz · January 29, 2024, 4:52am

I was a bit half-awake so forgive the sloppiness here, but here’s a recording I made in response to this, while on battery in Fedora.
https://asciinema.org/a/aaJgckoObgvRQ3yqLKjI8F8qj

jonas5 · January 31, 2024, 3:03pm

I found this in my feed earlier,
https://lore.kernel.org/linux-pm/[email protected]/

It is mainly for and threadripper. But it said something about other legacy devices too.

Unfortunately they aren’t being implemented until kernel 6.9 or possibly 6.8?

It seem to be similar issue returning to state regarding the MHz and the amd_pstate driver communication with the bios.

jonas5 · February 5, 2024, 2:54pm

The Problem and the Solution

Efforts have been made to address a recurring issue, yet pinpointing its exact source has proven difficullt. The problem at hand involves a throttling mechanism aimed at safeguarding the battery from overheating[1], referred to as BD-PROCHOT[2]. Despite its intended protective function, this mechanism often results in the CPU being stuck at a frequency of 400MHz, rendering it unable to return to its normal operational state. Notably, this issue typically arises when the CPU temperature reaches 90 degrees Celsius, failing to revert to normal operation until it drops back down to 80 degrees Celsius. Interestingly, this behavior persists regardless of the CPU governor[1] in use, though using the ‘performance’ governor tends to expedite the occurrence while the ‘ondemand’ governor offers a more softer approach.

By default, the ‘acpi-cpufreq’ driver governs CPU frequency. Accessing its features requires the utilization of linux-tools compatible with the kernel version in use, a requirement that varies across different Linux distributions.

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

To reproduce the issue, running a stress tests with both the ‘performance’ and ‘ondemand’ governors over time consistently results in CPU throttling over time to 400MHz at 90 degrees Celsius.

$ stress -c 8

Proposed Solutions:

Utilizing Fan Controls: Consider implementing Thinkfan[4][5] to manage fan controls, although certain systems may not present the necessary unit. To identify available sensors and units, commands:
To find the sensors:

$ find /sys/devices -type f -name “temp*_input”
/sys/devices/pci0000:00/0000:00:18.3/hwmon/hwmon5/temp1_input
/sys/devices/pci0000:00/0000:00:01.7/0000:03:00.0/nvme/nvme0/hwmon3/temp1_input
/sys/devices/pci0000:00/0000:00:01.7/0000:03:00.0/nvme/nvme0/hwmon3/temp2_input
/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.0/hwmon/hwmon8/temp1_input
/sys/devices/virtual/thermal/thermal_zone0/hwmon1/temp1_input

Expected location of unit[5]:

$ cat /proc/acpi/ibm/fan
cat: /proc/acpi/ibm/fan: No such file or directory

Switching to amd_pstate[1][3]:
Transitioning to the amd_pstate driver may offer a solution, albeit with some caveats. From kernel version 6.3 onwards, this driver operates in ‘active’ mode by default, necessitating BIOS[6][7] settings adjustment to enable CPPC* support.

*To enable CPPC support in BIOS, navigate to the corresponding settings (often found under AMD CBS > NBIO > SMU > CPPC), and switch from ‘Auto’ to ‘Enabled’. If these settings are not readily available, consulting the vendor’s website for updates is recommended[6].

In Conclusion:

The most immediate solution involves utilizing a script to address the battery sensor issue, use with caution on your own responsibility[2].
Using a Linux kernel with compatible linux-tools and utilizing the ‘ondemand’ governor can mitigate the issue to some extent.
Considering reapplying thermal paste to the CPU, especially if discrepancies are observed between the copper and the die due to high torque and high temperature.

[1] Lenovo ThinkPad T480 - ArchWiki
[2] GitHub - yyearth/turnoff-BD-PROCHOT
[3] amd-pstate CPU Performance Scaling Driver — The Linux Kernel documentation
[4] ThinkPad ACPI Extras Driver — The Linux Kernel documentation
[5] Fan speed control - ArchWiki
[6] CPU frequency scaling - ArchWiki
[7] https://www.reddit.com/r/archlinux/comments/1381g2g/amd_pstate_epp_scaling_driver_available_with/