framework_tool segfaults on framework 13 Core Ultra 125H running kubuntu 24.04.2 lts

[stuart-nolan]

I can build and partially run framework_tool on a framework 13 Intel Core Ultra Series 1 125H running kubuntu 24.04.2 LTS, kernel 6.11.0-25-generic:

sudo ./target/debug/framework_tool --info
[sudo] password for ul: 
Summary
  Is Framework: true
  Platform:     IntelCoreUltra1
BIOS Information
  Vendor:       INSYDE Corp.
  Version:      03.04
  Release Date: 10/09/2024
System Information
  Version:      Some(MassProduction) (A2)
  Manufacturer: Framework
  Product Name: Laptop 13 (Intel Core Ultra Series 1)
  Wake-Up-Type: PowerSwitch
  SKU Number:   FRANDJCP02
  Serial Number:<redacted>
  Family:       Laptop
BaseBoard Information
  Version:      Some(MassProduction) (A2)
  Manufacturer: Framework
  Product:      FRANMECP02
  Serial Number:<redacted>
System Chassis Information
  Type:         Notebook

However I get seg faults for many args. For example:

sudo ./target/debug/framework_tool --charge-limit
Segmentation fault

The charge limit is currently set to 60% via bios.

I can get the following back trace:

sudo rust-gdb --args ./target/debug/framework_tool --charge-limit

...

(gdb) r
Starting program: /home/ul/tmp/framework-system/target/debug/framework_tool --charge-limit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcap.so.2

Program received signal SIGSEGV, Segmentation fault.
0x00005555556807f3 in hwio::pio::{impl#2}::write (self=0x7fffffff9a52, value=288)
    at /home/ul/.cargo/git/checkouts/rust-hwio-1ba602c57f8be0b1/9bcff42/src/pio.rs:228
228                 asm!("out dx, ax", in("ax") value, in("dx") self.port, options(nostack));
(gdb) bt
#0  0x00005555556807f3 in hwio::pio::{impl#2}::write (self=0x7fffffff9a52, value=288)
    at /home/ul/.cargo/git/checkouts/rust-hwio-1ba602c57f8be0b1/9bcff42/src/pio.rs:228
#1  framework_lib::chromium_ec::portio_mec::transfer_read (address=288, size=2)
    at framework_lib/src/chromium_ec/portio_mec.rs:173
#2  0x0000555555664f99 in framework_lib::chromium_ec::portio::init ()
    at framework_lib/src/chromium_ec/portio.rs:95
#3  0x000055555566693f in framework_lib::chromium_ec::portio::send_command (
    command=15875, command_version=0, data=&[u8](size=3) = {...})
    at framework_lib/src/chromium_ec/portio.rs:242
#4  0x00005555556acecd in framework_lib::chromium_ec::{impl#2}::send_command (
    self=0x7fffffffb7ed, command=15875, command_version=0, data=&[u8](size=3) = {...})
    at framework_lib/src/chromium_ec/mod.rs:1457
#5  0x00005555555fffe0 in framework_lib::chromium_ec::command::EcRequestRaw::send_command_vec_extra<framework_lib::chromium_ec::commands::EcRequestChargeLimitControl, framework_lib::chromium_ec::commands::EcResponseChargeLimitControl> (self=0x555555aeb97e, 
    ec=0x7fffffffb7ed, extra_data=&[u8](size=0))
    at framework_lib/src/chromium_ec/command.rs:156
#6  0x000055555561a1cc in framework_lib::chromium_ec::command::EcRequestRaw::send_command_extra<framework_lib::chromium_ec::commands::EcRequestChargeLimitControl, framework_lib::chromium_ec::commands::EcResponseChargeLimitControl> (self=0x555555aeb97e, 
    ec=0x7fffffffb7ed, extra_data=&[u8](size=0))
    at framework_lib/src/chromium_ec/command.rs:178
#7  0x00005555556159e5 in framework_lib::chromium_ec::command::EcRequestRaw::send_command<framework_lib::chromium_ec::commands::EcRequestChargeLimitControl, framework_lib::chromium_ec::commands::EcResponseChargeLimitControl> (self=0x555555aeb97e, ec=0x7fffffffb7ed)
    at framework_lib/src/chromium_ec/command.rs:170
#8  0x000055555569febe in framework_lib::chromium_ec::CrosEc::get_charge_limit (
    self=0x7fffffffb7ed) at framework_lib/src/chromium_ec/mod.rs:428
#9  0x00005555555d6e78 in framework_lib::commandline::handle_charge_limit (
    ec=0x7fffffffb7ed, maybe_limit=...) at framework_lib/src/commandline/mod.rs:1489
#10 0x00005555555cd954 in framework_lib::commandline::run_with_args (
    args=0x7fffffffdc78, _allupdate=false) at framework_lib/src/commandline/mod.rs:817
#11 0x00005555555c4f83 in framework_tool::main () at framework_tool/src/main.rs:40

I followed the building instructions but if I've done something silly to get here, please let me know. I am unfamiliar with rust and the inner workings of the framework bios so will be of little use fixing this. That said, I can provide additional troubleshooting and testing.

Thank you.

[JohnAZoidberg]

So it's trying to use the portio userspace driver because for Core Ultra you need kernel 6.12 to have it load the proper cros_ec driver.

And then it's failing trying to access it like a Microchip EC, but Core Ultra already have Nuvoton EC.

Do you have secureboot enabled?
Please try if this PR can fail gracefully instead of segfaulting: #154

[JohnAZoidberg]

I tried it on Fedora 42 (kernel 6.14.2) on Core Ultra and it can work okay with or without the new change.
Even if I force --driver portio.

[stuart-nolan]

tl;dr better as it prints a reason it think it fails before seg faulting at the same point

Do you have secureboot enabled?

sudo mokutil --sb-state
SecureBoot enabled

Please try if this PR can fail gracefully instead of segfaulting: #154

Cherry picked both commits in #154 to main:

cargo clean
cargo build
...
sudo ./target/debug/framework_tool -vvvv -t
[DEBUG] Chromium EC Driver: Portio
Self-Test
[TRACE] get_smbios() linux entry
  SMBIOS Platform:     IntelCoreUltra1
  Dump EC memory region
[DEBUG] read_memory(offset=0x0, size=0xFE)
Init MEC
[ERROR] ioperm failed. portio driver is likely block by Linux kernel lockdown mode
[TRACE] transfer_read_mec(address=0x120, size=0x2)
[TRACE]   Reading single byte from end at 0x120
Segmentation fault

sudo ./target/debug/framework_tool -vvvv --charge-limit
[DEBUG] Chromium EC Driver: Portio
[DEBUG] send_command(command=Some(ChargeLimitControl), ver=0, data_len=3)
[TRACE] get_smbios() linux entry
Init MEC
[ERROR] ioperm failed. portio driver is likely block by Linux kernel lockdown mode
[TRACE] transfer_read_mec(address=0x120, size=0x2)
[TRACE]   Reading single byte from end at 0x120
Segmentation fault

it seems to seg fault at the same place

bt

sudo rust-gdb --args ./target/debug/framework_tool -vvvv --charge-limit

...

(gdb) r
Starting program: /home/ul/tmp/framework-system/target/debug/framework_tool -vvvv --charge-limit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcap.so.2
[DEBUG] Chromium EC Driver: Portio
[DEBUG] send_command(command=Some(ChargeLimitControl), ver=0, data_len=3)
[TRACE] get_smbios() linux entry
Init MEC
[ERROR] ioperm failed. portio driver is likely block by Linux kernel lockdown mode
[TRACE] transfer_read_mec(address=0x120, size=0x2)
[TRACE]   Reading single byte from end at 0x120

Program received signal SIGSEGV, Segmentation fault.
0x0000555555680983 in hwio::pio::{impl#2}::write (self=0x7fffffff9a42, value=288)
    at /home/ul/.cargo/git/checkouts/rust-hwio-1ba602c57f8be0b1/9bcff42/src/pio.rs:228
228                 asm!("out dx, ax", in("ax") value, in("dx") self.port, options(nostack));
(gdb) bt
#0  0x0000555555680983 in hwio::pio::{impl#2}::write (self=0x7fffffff9a42, value=288)
    at /home/ul/.cargo/git/checkouts/rust-hwio-1ba602c57f8be0b1/9bcff42/src/pio.rs:228
#1  framework_lib::chromium_ec::portio_mec::transfer_read (address=288, size=2)
    at framework_lib/src/chromium_ec/portio_mec.rs:181
#2  0x0000555555665138 in framework_lib::chromium_ec::portio::init ()
    at framework_lib/src/chromium_ec/portio.rs:104
#3  0x000055555566693f in framework_lib::chromium_ec::portio::send_command (
    command=15875, command_version=0, data=&[u8](size=3) = {...})
    at framework_lib/src/chromium_ec/portio.rs:243
#4  0x00005555556ad05d in framework_lib::chromium_ec::{impl#2}::send_command (
    self=0x7fffffffb7dd, command=15875, command_version=0, data=&[u8](size=3) = {...})
    at framework_lib/src/chromium_ec/mod.rs:1457
#5  0x00005555555fffe0 in framework_lib::chromium_ec::command::EcRequestRaw::send_command_vec_extra<framework_lib::chromium_ec::commands::EcRequestChargeLimitControl, framework_lib::chromium_ec::commands::EcResponseChargeLimitControl> (self=0x555555aeb9d2, 
    ec=0x7fffffffb7dd, extra_data=&[u8](size=0))
    at framework_lib/src/chromium_ec/command.rs:156
#6  0x000055555561a1cc in framework_lib::chromium_ec::command::EcRequestRaw::send_command_extra<framework_lib::chromium_ec::commands::EcRequestChargeLimitControl, framework_lib::chromium_ec::commands::EcResponseChargeLimitControl> (self=0x555555aeb9d2, 
    ec=0x7fffffffb7dd, extra_data=&[u8](size=0))
    at framework_lib/src/chromium_ec/command.rs:178
#7  0x00005555556159e5 in framework_lib::chromium_ec::command::EcRequestRaw::send_command<framework_lib::chromium_ec::commands::EcRequestChargeLimitControl, framework_lib::chromium_ec::commands::EcResponseChargeLimitControl> (self=0x555555aeb9d2, ec=0x7fffffffb7dd)
    at framework_lib/src/chromium_ec/command.rs:170
#8  0x00005555556a004e in framework_lib::chromium_ec::CrosEc::get_charge_limit (
    self=0x7fffffffb7dd) at framework_lib/src/chromium_ec/mod.rs:428
#9  0x00005555555d6e78 in framework_lib::commandline::handle_charge_limit (
    ec=0x7fffffffb7dd, maybe_limit=...) at framework_lib/src/commandline/mod.rs:1489
#10 0x00005555555cd954 in framework_lib::commandline::run_with_args (
    args=0x7fffffffdc68, _allupdate=false) at framework_lib/src/commandline/mod.rs:817
#11 0x00005555555c4f83 in framework_tool::main () at framework_tool/src/main.rs:40

for Core Ultra you need kernel 6.12 to have it load the proper cros_ec driver

You seem to be hinting that the workaround is to try a newer kernel but I'm not sure from your comments if I need to disable secure boot even with a newer kernel. I can try more recent kernel and test with secure boot off, but I wont run without secure boot for daily use.

Thank you for responding so quickly on this.

[JohnAZoidberg]

SecureBoot enabled

With secureboot the kernel enables lockdown mode and disables insecure raw hardware access like portio.
So either you've got to disable secureboot or upgrade to at least kernel 6.12
If you want, you can also compile your own kernel or just the cros_ec_lpc module with this patch: torvalds/linux@62be134

Cherry picked both commits in 154 to main:

But that branch is already based on main - any reason you didn't just check out that branch?

tl;dr better as it prints a reason it think it fails before seg faulting at the same point

Ah, I didn't exit properly, try again and it should print the error but not segfault.
Thanks for checking!

[stuart-nolan]

any reason you didn't just check out that branch?

no reason, it was just the path of least resistance for me

I'll see how difficult it is to upgrade to a 6.14 kernel (apparently available for ubuntu 24.10) on an ubuntu lts release or just build the cros_ec_lpc module as I've done similar before.

Regardless, I comment and close this issue after testing.

Thanks again.

[stuart-nolan]

Upgrading to a signed kernel v6.14.0-17 on 24.04 lts (hence maintaining secure boot and retaining esm updates) is possible and resolves this issue for me.

uname -a
Linux fw13 6.14.0-17-generic #17-Ubuntu SMP PREEMPT_DYNAMIC Thu May  1 11:39:26 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

sudo mokutil --sb-state
SecureBoot enabled

sudo ./target/debug/framework_tool --charge-limit
Minimum 0%, Maximum 60%

sudo ./target/debug/framework_tool --charge-limit 70
Minimum 0%, Maximum 70%

and I observed my battery charging from 60% to 70%.

For the benefit of others that may find their way here, details of what I did are below; however, I do not recommend what I did (one may have to manually update the 6.14 kernels going forward, issues unknown to me may arise later, etc.).

Apparently, 24.04 lts is scheduled to get kernel 6.14 in August with the 24.04.2 -> 24.04.3 update so best wait for that or go through the pain of compiling a patched cros_ec_lpc, DKMS compliant, 6.11 loadable kernel module (and then undoing that when the kernel updates to 6.14).

details

Signed 6.14 kernel image from here. The remaining kernel packages came from here.

sudo dpkg -i ./linux-headers-6.14.0-17_6.14.0-17.17_amd64.deb ./linux-image-6.14.0-17-generic_6.14.0-17.17_amd64.deb ./linux-modules-6.14.0-17-generic_6.14.0-17.17_amd64.deb ./linux-modules-extra-6.14.0-17-generic_6.14.0-17.17_amd64.deb ./linux-tools-6.14.0-17_6.14.0-17.17_amd64.deb

reboot and it "just worked" (including my win11 kvm instance)

Note just after I did the kernel upgrade (and after verifying that framework_tool is now working as expected) some framework firmware updates popped up - not sure if that was related. I installed them and so far no issues. Hope I can roll-back if needed. Another good reason to not do what I did unless you're confident in your choices.

[JohnAZoidberg]

Thanks for confirming and the detailed steps :D