Answering myself: in order to update the retimers I used the USB key.
It happens that the startup script starts quite fast so the FW upgrade operation ran again.
I had after two reboots and two times the Please wait while we install a system update message, then back to GRUB at the third restart.
I guess this time I’m done with the whole package with CSME and retimers.
And it went flawlessly again, thanks FW team! 
Another BIOS update release and another failure. None of the >1000 PCs spanning multiple generations (including 12th gen Intel) we manage at work have had any issues updating firmware. I’m glad we don’t buy Framework PCs there. Just did another flawless update to Libreboot on my 2009 ThinkPad T400 without issue.
Framework should fix these updates, exchange my motherboard for a working model, or refund my money.
Still stuck on 3.08. Seeing the following errors:
Target Version "03.18" Comparing BIOS version "310" Comparison Result: 1 Updating bios Target Version "310" Comparing RTM23 version "310" Comparison Result: 0 Target Version "310" Comparing RTM23 version "310" Comparison Result: 0 Comparing RTM01 version "207" Comparison Result: 1 Need to update Retimer 01 Error 331: Full FW update using same version is not allowed Get Boot Next Data Fail. Status = Not Found CapsuleApp: cannot find a valid file system on boot devices. Status = Not Found CapsuleApp: Failed to update capsule - Not Found
Green screen:
UEFI BIOS
Version 3.08
Release Date: 12/25/23
EC firmware
Build version: hx30_v0.0.1-4ea1c89 2023-12-11 14:15:35 runner@fv-az1124-221
Current image: R0
PD Controllers
Right (01): 0.1.2C (MainFw)
Left: (23): 0.1.2C (MainFw)
Retimers
Left: 0x136 (310)
Right: 0xCF (207)
I always wondered what was up with my computer… I thought it was just bad software, but this thread prompted me to dig a little…
I just updated to the latest firmware, but it hasn’t made any difference?
Looks like official communication has all but dried up?
1 Like
This mainly is a user forum.
Yes, FW reps are hanging around and answering questions here and there, but you should not expect a lot of official communication here.
The community is happy to help though 
That being said, i think you need to give more information about whats wrong with your machine.
Just saying “bad software” is way to vague.
So, what exactly is your issue?
1 Like
Sorry, I thought the topic running through was the 400mhz bug that still persists.
I don’t think “clean your heatsink” being the only official communication in the last 2 months is really the support we should be expecting from FW 
1 Like
This is not a support forum. File a ticket with support, then feel free to create a thread to beef about it. A lot of people track these BIOS threads for real information about BIOS updates or particular BIOS versions. They don’t need to get spammed by the 1 in a 1000 users who have an issue that quite honestly is most likely a case of PEBCAK. If they can’t reproduce the issue they simply can’t fix it. If you want help form the community create a fresh thread, and ask for help. There are plenty of users here that would gladly help, but for that you have to ask, and then be open to directions, and offering up what is actually asked. I have yet to see 400mhz thread that followed an effective troubleshooting regimen and mostly because the users who have asked so far have been evasive, or done things they were not asked to do forcing everyone back to square one.
So yeah open a ticket or create a new thread.
2 Likes
@Lauren_Thomas Please contact support so we can gather information.
1 Like
@Piefke Do you have an active support ticket for this issue? If not, please create one so we can investigate.
1 Like
Are support going to comment on what the FW team is going to do to regarding this situation going forward?
Support will gather the information we need to help resolve the issue. As far as what the FW team comments on, we’re usually pretty good at sharing solutions once they are discovered / implemented.
2 Likes
now, a couple of months after my first tests, I’m a little disappointed by the performance.
i can’t reproduce the above benchmark of i7z reaching 2-3GHz, i’m always stuck below 2GHz, and performance is not great.
here’s the fan profile, again:
sensor warn high halt fan_off fan_max name
0 0 361 371 324 342 F75303_Local
1 0 361 371 324 342 F75303_CPU
2 0 360 370 313 342 F75303_DDR
3 0 323 333 313 323 Battery
4 388 393 400 376 378 PECI
5 0 361 371 324 342 F75397_VCCGT
here’s a screenshot of stress-ng running on all cores without i7z ever reaching above 1.7Ghz or so.
so i think there’s still something wrong with the fan profile: it’s not agressive enough.
1 Like
By resolve, do you mean “tell me to buy a new board”? Cause that seems to be the consensus so far…
But you were able to archive the previous numbers with 3.18, right?
So the bios has not changed since then.
Therefore this to me this rather looks like a kernel regression or some other software related issue, besides bios.
Maybe the latest test was run on battery, while the first was run plugged in?
Looking at your screenshot, your CPU temps are fine.
Why would you want a more agressive fan curve?
Maybe i am missing something?
1 Like
That’s quite a claim!
I doubt this is a kernel regression, such a huge performance regression would be widely noticed and flagged…
But yes, I was able to reproduce the numbers, once, with 3.18, but as I mentioned earlier, it wasn’t
reliable:
I’m not sure what’s happening. From my perspective, the 3.17 update changed the fan profile which improved performance, and 3.18, at first, didn’t seem to break it, but ultimately did. Maybe it’s something that breaks after sleep or something, I don’t know. I doubt it’s the kernel, but I’m happy to run some more tests.
This test was just ran on AC power.
My (implied) theory here is that CPUs are being throttled to avoid the CPUs from heating up too much.
Otherwise why wouldn’t stress-ng not be able to load up the CPUs to 4GHz? Am i holding it wrong?
1 Like
Looks to me like you are doing a full worker load stress test. i.e. across all cores. You will never hit the 4ghz range with that. The 4.7 ghz in the specs is for a single core turbo max freq. If you run stress-ng with 1 worker you will see it hit that 4.7. With an all worker load i.e. using 16 workers you will generally sit at ~2.7ghz after the initial turbo range. So the behavior is as expected. If you cant hit the 4+ rnage running a single core then, and only then might you have a problem.
1 Like
also, for the record, those benchmarks now run at the abysmal 16 seconds again:
anarcat@angela:~/s/asncounter> hyperfine -i -w 3 --input test/data/sample-10m.ips "./asncounter.py --cache-dir=test/cache"
Benchmark 1: ./asncounter.py --cache-dir=test/cache
Time (mean ± σ): 16.666 s ± 0.103 s [User: 16.392 s, System: 0.270 s]
Range (min … max): 16.512 s … 16.800 s 10 runs
the fan doesn’t spin up at all in all those tests, including the stress-ng hog.
in fact, all those benchmarks do precisely nothing to change the i7z output. i’m always roughly at that 22x turbo factor, around 2GHz.
Yeah, except I am getting the same results…and completely different results with s-tui. Out of curiosity try it with s-tui which can simultaneously monitor everything.
s-tui doesn’t give me very different results. fans don’t really budge, and cores don’t go above 2GHz.
looking at the EC configurations again, i noticed this:
sensor warn high halt fan_off fan_max name
1 0 361 371 324 342 F75303_CPU
see that fan_off/fan_max setting? it’s the same! isn’t that weird? that’s 68C for those who are not fluent in kelvin, and essentially keeps the fan off until it goes to max, when the CPU hits 68C. my theory is the CPU is always throttled before that.
update: bah. nevermind that, i confused 324 and 342, those are obviously not the same numbers (although quite close). as it turns out, my problem might be with the kernel (sorry!) governor module. it seems like it was capped at 1.2GHz. with:
cpupower frequency-set -u 4.40GHz
i could again peak the CPUs (and hit the fans). it’s really odd for me because it’s not something i have explicitly configured, i didn’t even know about cpupower until I read this Arch wiki article.
The fans do spin up now as well, here’s what it looks like in s-tui:
and i7z:
Cpu speed from cpuinfo 2111.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 2111 MHz
CPU Multiplier 21x || Bus clock frequency (BCLK) 100.52 MHz
Socket [0] - [physical cores=12, logical cores=16, max online cores ever=12]
TURBO ENABLED on 12 Cores, Hyper Threading ON
Max Frequency without considering Turbo 2211.52 MHz (100.52 x [22])
Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is 44x/44x/37x/35x/35x/35x
Real Current Frequency 4300.58 MHz [100.52 x 42.78] (Max of below)
Core [core-id] :Actual Freq (Mult.) C0% Halt(C1)% C3 % C6 % Temp VCore
Core 1 [0]: 2794.68 (27.80x) 5.37 91 0 1.9 58 1.1266
Core 2 [2]: 3149.49 (31.33x) 4.2 92.7 0 1 68 1.0016
Core 3 [4]: 3342.07 (33.25x) 6.23 89.1 0 1 55 0.9916
Core 4 [6]: 4300.58 (42.78x) 100 0 0 0 78 1.0066
Core 5 [8]: 2572.33 (25.59x) 2.74 4.25 0 92.4 53 1.0817
Core 6 [9]: 2864.57 (28.50x) 2.11 3.45 0 93.7 53 1.0667
Core 7 [10]: 2709.97 (26.96x) 1.88 2.7 0 94.9 53 1.0767
Core 8 [11]: 2707.33 (26.93x) 1.72 2.71 0 95.1 53 1.0767
Core 9 [12]: 2448.53 (24.36x) 1 4 0 94.9 58 1.0835
Core 10 [13]: 2376.23 (23.64x) 1 1.7 0 97.5 58 1.0835
Core 11 [14]: 2479.69 (24.67x) 1 2.05 0 97.1 58 1.0984
Core 12 [15]: 2568.56 (25.55x) 1.19 1.3 0 97.3 58 1.0785
[core-id] refers to core-id number in /proc/cpuinfo
'Garbage Values' message printed when garbage values are read
Ctrl+C to exit
i had to wait a couple seconds to capture that Real Current Frequency 4300.58 MHz, it’s not constant.
i also feel the fans are less reactive than they were before. the spin up/down time seems really slow, and I feel this might be hurting performance.
but there you go, maybe you were right, @Simon_F, in the sense that this is somewhat a kernel thing: not a regression, of course, but a configuration issue.
3 Likes
Glad you found it
1 Like