Issue 12 is marked closed, but it's still problematic.
20:18 <juanflux> Hello, I recently upgraded to the newest rom for the T400 and it seems that IEST/SpeedStep isn't being properly recognized in OpenBSD dmesg. I'm stuck at 1600MHz/core
20:18 <juanflux> This line that should exist:
20:18 <juanflux> >cpu0: Enhanced SpeedStep 1600 MHz: speeds: 2534, 2533, 1600, 800 MHz
20:18 <juanflux> Does not
investigate.
i cancelled the 20211115/20211116 release. this is a release-blocking bug and should be fixed as soon as possible
either there is a regression somewhere or i overlooked a build-time option. does it work upstream?
i can test this myself later to find out.
see: <https://notabug.org/libreboot/lbmk/issues/12>
Issue 12 is marked closed, but it's still problematic.
````
20:18 <juanflux> Hello, I recently upgraded to the newest rom for the T400 and it seems that IEST/SpeedStep isn't being properly recognized in OpenBSD dmesg. I'm stuck at 1600MHz/core
20:18 <juanflux> This line that should exist:
20:18 <juanflux> >cpu0: Enhanced SpeedStep 1600 MHz: speeds: 2534, 2533, 1600, 800 MHz
20:18 <juanflux> Does not
````
investigate.
i cancelled the 20211115/20211116 release. this is a release-blocking bug and should be fixed as soon as possible
either there is a regression somewhere or i overlooked a build-time option. does it work upstream?
i can test this myself later to find out.
I've decided to abandon the stable release that was planned for November 2021, and do a new testing release (one that is more or less stable in practise) once this bug is fixed. The new testing release will have a newer coreboot release, from November 2021, for all boards.
Stable releases must not be rushed.
The reason why is I believe that this bug may already be fixed in coreboot master. When it was last reported, it was reported that master worked.
So I've decided to work on a testing release for Libreboot, instead of astable release. This was decided today, November 16th, 2021. I'll do a stable release in December at the earliest, if not later.
So I suggest:
Try coreboot master. Or wait, because I will soon update to the latest coreboot on all boards in lbmk.git. Then we can re-test this bug.
I've decided to abandon the stable release that was planned for November 2021, and do a new testing release (one that is more or less stable in practise) once this bug is fixed. The new testing release will have a newer coreboot release, from November 2021, for all boards.
Stable releases must not be rushed.
The reason why is I believe that this bug may already be fixed in coreboot master. When it was last reported, it was reported that master worked.
So I've decided to work on a testing release for Libreboot, instead of astable release. This was decided today, November 16th, 2021. I'll do a stable release in December at the earliest, if not later.
So I suggest:
Try coreboot master. Or wait, because I will soon update to the latest coreboot on all boards in lbmk.git. Then we can re-test this bug.
ok, the speedstep bug is a regression. Can someone bisect? coreboot 4.4 should work. coreboot 4.15 is broken.
any gm45 machine, but i tested x200. speedstep is broken in libreboot 20211122 which uses coreboot 4.15. i believe libreboot 20160907 used coreboot 4.4
tested on my x200:
20160907 no-microcode: speedstep works
20211122 no-microcode: steepstep broken, cpu stuck at 1600mhz
20211122 with microcode added in cbfs: speedstep works
works means: on idle my x200 was like, 1ghz. on stress, it went up to 2.4ghz
watch grep cpu\ MHz /proc/cpuinfo
and do stuff with the cpu, including stress, and idle. watch the cpu speed go up and down. that's how you know speedstep is working. it's broken in the latest coreboot(when not using microcode), but worked in libreboot 20160907(without microcode also)
21:36 <leah> confirmed!
21:36 <leah> 20211122 speedstep is broken on gm45
21:36 <leah> but
21:36 <leah> i add microcode: works perfect
21:36 <leah> speedstep works in 20160907 without microcode
21:37 <leah> i regard lack of microcode as a bug. it is a fact that libreboot is technically deficient
21:37 <leah> however
21:37 <leah> this is still a libreboot regression. and worth fixing
21:37 <leah> my hunch is probably coreboot fixed some actually technically incorrect code, and made something work according to intel specs
21:38 <leah> tl;dr we got lucky in 2016
21:38 <leah> but it's probably an easy hack like the reset bug
21:38 <leah> i will bisect this myself when i get time, if nobody else does
21:38 <leah> but
21:39 <leah> biovoid: belgin whistler can you bisect?
21:39 <leah> coreboot... version 4.4 i think was used on 2016 libreboot, for gm45 machines
21:39 <leah> coreboot 4.4 and coreboot 4.15
21:39 <leah> between those
21:39 <leah> bisect to find what commit in coreboot broke speedstep
21:39 <leah> how to test:
21:40 <leah> watch grep cpu\ MHz /proc/cpuinfo
21:40 <penaiple> sorry i was busy im here now
21:40 <leah> you see cpu at like. maybe 1GHz on idle
21:40 <leah> when you do stuff, or stress test, it shoots up
21:40 <leah> stress -c $(nproc)
21:40 <leah> this shoots it up to 100% cpu usage, and should result in cpuinfo showing the cpu speed going to max
ok, the speedstep bug is a regression. Can someone bisect? coreboot 4.4 should work. coreboot 4.15 is broken.
any gm45 machine, but i tested x200. speedstep is broken in libreboot 20211122 which uses coreboot 4.15. i believe libreboot 20160907 used coreboot 4.4
tested on my x200:
* 20160907 no-microcode: speedstep works
* 20211122 no-microcode: steepstep broken, cpu stuck at 1600mhz
* 20211122 with microcode added in cbfs: speedstep works
works means: on idle my x200 was like, 1ghz. on stress, it went up to 2.4ghz
`watch grep cpu\ MHz /proc/cpuinfo`
and do stuff with the cpu, including stress, and idle. watch the cpu speed go up and down. that's how you know speedstep is working. it's broken in the latest coreboot(when not using microcode), but worked in libreboot 20160907(without microcode also)
````
21:36 <leah> confirmed!
21:36 <leah> 20211122 speedstep is broken on gm45
21:36 <leah> but
21:36 <leah> i add microcode: works perfect
21:36 <leah> speedstep works in 20160907 without microcode
21:37 <leah> i regard lack of microcode as a bug. it is a fact that libreboot is technically deficient
21:37 <leah> however
21:37 <leah> this is still a libreboot regression. and worth fixing
21:37 <leah> my hunch is probably coreboot fixed some actually technically incorrect code, and made something work according to intel specs
21:38 <leah> tl;dr we got lucky in 2016
21:38 <leah> but it's probably an easy hack like the reset bug
21:38 <leah> i will bisect this myself when i get time, if nobody else does
21:38 <leah> but
21:39 <leah> biovoid: belgin whistler can you bisect?
21:39 <leah> coreboot... version 4.4 i think was used on 2016 libreboot, for gm45 machines
21:39 <leah> coreboot 4.4 and coreboot 4.15
21:39 <leah> between those
21:39 <leah> bisect to find what commit in coreboot broke speedstep
21:39 <leah> how to test:
21:40 <leah> watch grep cpu\ MHz /proc/cpuinfo
21:40 <penaiple> sorry i was busy im here now
21:40 <leah> you see cpu at like. maybe 1GHz on idle
21:40 <leah> when you do stuff, or stress test, it shoots up
21:40 <leah> stress -c $(nproc)
21:40 <leah> this shoots it up to 100% cpu usage, and should result in cpuinfo showing the cpu speed going to max
````
see: #12
Issue 12 is marked closed, but it's still problematic.
investigate.
i cancelled the 20211115/20211116 release. this is a release-blocking bug and should be fixed as soon as possible
either there is a regression somewhere or i overlooked a build-time option. does it work upstream?
i can test this myself later to find out.
I've decided to abandon the stable release that was planned for November 2021, and do a new testing release (one that is more or less stable in practise) once this bug is fixed. The new testing release will have a newer coreboot release, from November 2021, for all boards.
Stable releases must not be rushed.
The reason why is I believe that this bug may already be fixed in coreboot master. When it was last reported, it was reported that master worked.
So I've decided to work on a testing release for Libreboot, instead of astable release. This was decided today, November 16th, 2021. I'll do a stable release in December at the earliest, if not later.
So I suggest:
Try coreboot master. Or wait, because I will soon update to the latest coreboot on all boards in lbmk.git. Then we can re-test this bug.
ok, the speedstep bug is a regression. Can someone bisect? coreboot 4.4 should work. coreboot 4.15 is broken.
any gm45 machine, but i tested x200. speedstep is broken in libreboot 20211122 which uses coreboot 4.15. i believe libreboot 20160907 used coreboot 4.4
tested on my x200:
works means: on idle my x200 was like, 1ghz. on stress, it went up to 2.4ghz
watch grep cpu\ MHz /proc/cpuinfo
and do stuff with the cpu, including stress, and idle. watch the cpu speed go up and down. that's how you know speedstep is working. it's broken in the latest coreboot(when not using microcode), but worked in libreboot 20160907(without microcode also)
according to belgin on IRC, who bisected it, it's coreboot commit
70fea013c7
fixed
fixed in
9938fa14b1
someone on IRC reported it on GA-G41M-ES2L
test lbmk.git on that one and see if it occurs
probably don't need to test anything else
no longer relevant, due to osboot merger