I did confirm with dmidecode 4.7-Purisim-3.
I dont currently have any other systems to work with as I’m on the road for work for the next couple months.
I reran the build this morning, did seem to take much longer than I remember last time.
I’m running watch -n 1 sensors | tee temps.log for now. That should capture the last temp on shutdown unless I’m missing something right?
weird then! But if you managed to build it on the machine without having it shutdown, that’s already pretty good…
Yeah, it should save the last temps to file but that’s assuming the ‘tee’ will write/flush to disc and that the write to disc doesn’t corrupt the file if it happens during the shutdown. I’d personally avoid writing to disc if you know the machine is about to shutdown.
I don’t have any hard data for you, but anecdotally even with 4.7-Purism-3 my 15v3 battery doesn’t last as long, I have to be careful about random power-offs, and I can’t rely on it to sleep for very long without depleting the battery.
If there are particular logs that’d be helpful lmk, will try to provide.
Thanks for all the hard work, this is a great project to be a part of!
@daehawc is not the only one with this problem. I mentioned this earlier in the thread but perhaps did not make it clear that I am also running 4.7-Purisim-3, confirmed with dmidecode, and have experienced several hard shutdowns since the update, usually when on battery.
@hazybluedot: Your only other comment in this thread was from before the Purism-3 update was released.
Ok, so that’s problematic, do you have any way to reproduce this crash? I’ve been testing with the command ‘stress -c 4’ so far, but is there something in particular that could increase the temperature higher than what the stress test would do ? Could it be related to when the CPU and the GPU are stressed together ?
Woops, looks like I was thinking of a different thread. The crash has not be 100% reproducible but I also haven’t spent a ton of time looking into it. I do not think it is limited to times both the CPU and GPU are stressed together though because it has happened when I’m doing non-GPU intensive tasks, for example running two instances of a deduplication backup utility at the same time while doing some analysis in Rstudio (though it is possible R is offloading computation to the GPU?). It also seems to only occur when running on battery power with Intel turbo boost enabled though I have not done a systematic turbo boost on/off comparison yet.
I’ve only had a few moments to do any testing so far but I i have noticed about a 15-20 degree drop since re-running the 4.7-Purisim-3 build. Like I mentioned, I installed the -3 build right after it was released but it did seem to take significantly longer to build this time around. Not sure if something got skipped last time or not. dmidecode did show -3. My resting temps are currently sitting in the 37 range and when launching vlc for an mp4 video I now only spike to about 65 instead of 80-90 plus or immediate poweroff. I almost exclusively had the poweroff when streaming Amazon Video or loading VLC for a movie. Maybe tied with the GPU and CPU.
So far, I’m hesitant to say but I think deleting my build folder and rebuilding again seems to have improved things. I’ll let you know if I have any more issues.
Thanks.
This might be silly, but it suggest that flashing the coreboot, rebooting then flashing again is the way to go, for some strange reason…
So… good news! I figured it out yesterday and we’ve tested it on a few machines and it seems that the bug is fixed. It was indeed a problem with the FSP 2.0 which had a new ‘Loadline’ setting that wasn’t there in FSP 1.1, and since it wasn’t getting set, it was setting the load line to the default of 0 Ohm which is wrong. I don’t really understand much of it to be honest but I think this and that explains it in more detail.
Either way, the important thing is that if you update the build script and update your coreboot to 4.7-Purism-4, it should work much much better now, the temperature rises smoothly, it stabilizes around 80C to 85C instead of the previous 95C, the frequency remains at 2.9GHz or 3GHz (it used to drop from 3GHz to 400MHz as soon as the high temperature was reached, then jump up and down), and the fan doesn’t go full speed until needed, etc… Hopefully, this should also fix battery issues as I suspect the unregulated AC and DC load lines to the CPU were causing the battery to drain faster than normal.
@daehawc, @mpc, @hazybluedot, @all, Please update and let me know if you still notice any issues.
@daehawc, @Dwaff: the hashes are verified and the flash is also verified after flashing and the version numbers are unique, so flashing or building more than once will not make any difference. If you deleted the coreboot directory though, then the build will take an hour or so because it will rebuild the cross compiler (gcc and its dependencies) which takes time, and that only happens on the first build. The build script itself will do a ‘make clean’ though so running the script will always ensure it’s a clean build either way. If you deleted the coreboot directory though that explains why the build took much longer to finish, it was because the cross compiler got re-built. And that would still have had no effect since, like I said, the final binary’s hash is verified by the build script, so the coreboot images are always identical.
Great work!!
Initial testing here is very promising: temperatures seem to have significantly stabilized upon initial testing (both inside and outside of the Turbo-range). The threshold for which fans will start to spin now has to be exceeded for a longer period of time (a single peak crossing the 50C mark will no longer set off the fans; the temperature should be above 50C for several seconds now, according to the temperature graphs).
Note: testing is done on Arch Linux right now, still utilizing power management tools (such as Thermald).
Assuming this paper is still relevant, I’m guessing that some of the stabilisation is due to (voltage) overshoot stabilisation, or is this not the case?
TLDR: temperature is proportional to voltage^2, so the applying kakaroto’s loadline information, the code might either 1) stabilize voltage (overshoot) by resistive loading (akin to the input impedance of amplifiers) 2) apply (additionally) more complex mechanisms to regulate voltage.
On a seemingly related note, when the laptop is charging (and in use), the top-right corner does not seem to emit as much noise as it did after the last update. I’ll keep testing this for a while to see if this holds up, but for now I’ll regard it as a promising step in (for lack of a better word) power management.
Unfortunately with 4.7-Purism-4 I think I had a temp-induced unscheduled shutdown shortly after starting a demanding video task. I’ve set no_turbo to 1 for now.
@mpc: Could it be something else? did you have a terminal showing sensor data or something to confirm ?
@kakaroto it’s entirely possible it’s something else, but based on my priors here I’m leaning toward it being 4.7-Purism-4. In the interim I’ve noticed I wake up and the machine has powered off and the battery is dead (presumably either not sleeping properly or using too much power in sleep)
Are there particular logs I can capture that would help you?
Hey! I’ve got a few questions regarding the coreboot port:
Now my question is, how big is the security risk when I do this? And can I somehow generate a ‘correct’ checksum for my version, that compensates for the different bootsplash picture?
Also since the newest version of your script I am not able to flash my bootsplash anymore, the image flashes correctly, but on bootup I just get a “text version” of a bootsplash and no actual bootsplash. Any guesses on why it doesn’t work on the new version? I’d be happy to have my bootsplash back xD
Is there a possibility to set a BIOS password for coreboot? And how would I do it?
Are there any settings I can change in coreboot or is all fixed? Haven’t seen any settings yet``
But anyways, you are doing great work @kakaroto!!
You ahave effectively turned off any image verification. The script can’t differentiate wheather the checksums differ due to replaced bootsplash or corrupted some other part. It happily will flash whatever you feed it, be it working image with diffrenet bootsplash or some broken build. You might brick your laptop and it would come without any warning.
There, first symptom of imminent bricking. Damaged image - since bootsplash does not work - but flashed without any warning. You will also get no warning if the part that does the boot gets damaged.
That’s the way to go, but details are beyond me. Untill you figure this out, I’d recommend to live with the standard bootsplash.
Another unscheduled power off. Some data:
–When I restarted, battery was showing 59%. Last time this happened it was showing 58%. I think coincidence.
–I was a few minutes into playing a video file (computationally demanding, sort-of?). Last time this happened I was also playing a video file.
–The computer did not feel particularly warm immediately after the random power off
–dmesg did not show anything I thought noteworthy, but I’m not an expert. Happy to set up whatever logging might be helpful
I didn’t experience this with older versions of coreboot, and I don’t think I’ve made any significant changes, so I’m inclined to think it’s something with chip power management.
I’ve recognized that there are issues with Qubes RC5 and Evo 960. Firmware Version 3 was kind of awful. Version 4 has reduced the whining noise, but I am unsure about the performance. The main problem is the fan noise. It’s horrible between 80 or 90°C. There is a (beep-beep-like chirp) noise, when booting, but not when charging. If I set CPU governors to powersave the noise will be reduced, but also the performance.
With Qubes 4 my OS keep freezing as soon I do to much. Can this be the result of the coreboot firmware?
Are you talking about latest coreboot?
In my post above I described how yum install curl in a qube reproducibly caused overheat in some previous (factory) coreboot version:
All is working fine for me after updating coreboot using the script provided in this forum.