#60 speedstep is broken on gm45 platforms

Open
opened 1 week ago by vimuser · 2 comments
Leah Rowe commented 1 week ago

see: #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.

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.
Leah Rowe commented 1 week ago
Owner

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.
Leah Rowe commented 3 days ago
Owner

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 ````
Sign in to join this conversation.
No Label
No Milestone
No assignee
1 Participants
Loading...
Cancel
Save
There is no content yet.