Hi everyone,
I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot.
Is anyone currently working on something similar?
Is anything planned in that regard?
Kind regards
lhochstetter
Hi.
As for HT, there's this patch: https://review.coreboot.org/c/coreboot/+/29669 but it needs polishing and testing. Last time I touched it, it worked good (or so it seemed to me) on X220. If you have an interest and wish help to test, we could finish it.
(We also need to decide, whether to leave it as a CMOS option or turn into a Kconfig option.)
On 15.12.2019 15:57, Lars Hochstetter wrote:
Hi everyone,
I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot.
Is anyone currently working on something similar?
Is anything planned in that regard?
Kind regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hello:
I am also interested and will help test and I think it will be the best to leave it as CMOS option.
Thank you Jose.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 17, 2019 5:12 PM, Evgeny Zinoviev via coreboot coreboot@coreboot.org wrote:
Hi.
As for HT, there's this patch: https://review.coreboot.org/c/coreboot/+/29669 but it needs polishing and testing. Last time I touched it, it worked good (or so it seemed to me) on X220. If you have an interest and wish help to test, we could finish it.
(We also need to decide, whether to leave it as a CMOS option or turn into a Kconfig option.)
On 15.12.2019 15:57, Lars Hochstetter wrote:
Hi everyone, I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot. Is anyone currently working on something similar? Is anything planned in that regard? Kind regards lhochstetter
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
OK, I've just updated the patch.
Use "hyper_threading" CMOS option to switch it on and off. (Don't forget to enable CMOS support.)
On 12/19/19 10:25 AM, Jose Trujillo via coreboot wrote:
Hello:
I am also interested and will help test and I think it will be the best to leave it as CMOS option.
Thank you Jose.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 17, 2019 5:12 PM, Evgeny Zinoviev via coreboot coreboot@coreboot.org wrote:
Hi.
As for HT, there's this patch: https://review.coreboot.org/c/coreboot/+/29669 but it needs polishing and testing. Last time I touched it, it worked good (or so it seemed to me) on X220. If you have an interest and wish help to test, we could finish it.
(We also need to decide, whether to leave it as a CMOS option or turn into a Kconfig option.)
On 15.12.2019 15:57, Lars Hochstetter wrote:
Hi everyone, I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot. Is anyone currently working on something similar? Is anything planned in that regard? Kind regards lhochstetter
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi,
The patch seems to work correctly for me on X230. I get 2 CPUs with hyper_threading set to Disable and 4 with the option set to Enable.
Hi,
I second that - my i7-3840qm shows only 4 of its original 8 threads when hyper_threading is set to Disable and its full 8 threads when I set it to Enable.
I however also noticed severe freezes / crashes (OS Debian 10.2) but I'm unsure if they are related to the patch or something different.
I was considering testing a identical replacement board and another CPU as soon as some additional parts arrive.
I'll come back to you if I know more.
Regards
lhochstetter
On 12/21/19 9:57 AM, mkopec12@gmail.com wrote:
Hi,
The patch seems to work correctly for me on X230. I get 2 CPUs with hyper_threading set to Disable and 4 with the option set to Enable. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I however also noticed severe freezes / crashes (OS Debian 10.2) but I'm unsure if they are related to the patch or something different.
Have you got any logs? Do these crashes/freezes look like https://ticket.coreboot.org/issues/121?
Do these crashes/freezes look like https://ticket.coreboot.org/issues/121?
Sorry for potential thread hijack, did anyone observed vendor's clock generator setup on these models? I remember seeing exactly the same behavior with z61t when I borrowed clock generator setup from neighbor model, everything was fine until OS was booted and idled to C3. Though CPU are quite different, the problem might lie in the same area :)
There are some similarities: the system freezes (i.e. UI is unresponsive, you have to hold down the power button to reset the system) and sometimes it outright crashes into a reboot. The crashes seem to trigger when the CPU is running high loads - take note though: with your HT option patch I could run the stress tests of the CoreFreq (https://github.com/cyring/CoreFreq) tool without crashes / freezes but I only tried for a couple minutes.
I do get crashes sometimes when I compile crossgcc-i386 (CPUS=$(nproc), with and without HT enabled through nosmt in the GRUB config) but more often make runs into some error and simply won't compile the sources (I notice a certain tendency towards the gcc compilation) - I would usually recompile but it now seems to be more persistent. There seems to be also a good chance to crash when the CPU isn't fully loaded but multiple applications are open - most notably Firefox when watching Youtube videos and doing something in another application / Firefox tab.
Originally I was running coreboot v4.6, then changed to v4.8.1 then v4.9, then for some time to master (blobs were based on BIOS v2.79, me disabled and neutered). I'd argue that the issues started appearing after my switch to v4.11. However I can not rule out hardware issues, as I overtightened the screws on the heatsink last time I was working on my T430 - maybe the overtightening caused physical damage to some solder joints on the CPU / socket.
Here are some system stats:
CPU: i7-3840QM, TurboBoost is disabled through the intel_pstate driver to prevent my laptop from melting RAM: HyperX 2x8GB 2133MHz DDR3 1.35V HX321LS11IB2K2/16, it runs at 1600MHz (the "ignore fuses" option isn't set) though as the system would freeze shortly after logging in Mainboard: no dGPU variant OS: Debian 10.2 64bit with the default Gnome3 DE Mods: the 7 row keyboard mod and the FHD screen mod (maybe that is why I didn't see any visual artifacts) coreboot blobs (ifd, me, gbe): based on BIOS v2.81, me is neutered and disabled
I managed to capture following dmesg, when the system soft locked while Firefox was open and I managed to switch to a tty. If I recall correctly there was some audio repetition.
[ 926.163124] ISO 9660 Extensions: RRIP_1991A [ 1094.740789] usb 1-1.2: USB disconnect, device number 8 [ 1267.534956] BUG: unable to handle kernel paging request at fffff60050b36388 [ 1267.534960] PGD 4617e2067 P4D 4617e2067 PUD 0 [ 1267.534964] Oops: 0000 [#1] SMP PTI [ 1267.534966] CPU: 2 PID: 5953 Comm: Compositor Tainted: G OE 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2 [ 1267.534967] Hardware name: LENOVO 2347CM9/2347CM9, BIOS CBET4000 4.11 11/19/2019 [ 1267.534973] RIP: 0010:filemap_map_pages+0x9a/0x3a0 [ 1267.534974] Code: ff 0f 84 65 01 00 00 4c 39 6c 24 20 0f 87 77 01 00 00 49 8b 0f 48 85 c9 0f 84 cc 00 00 00 48 89 c8 83 e0 03 0f 85 cb 02 00 00 <48> 8b 41 08 48 8d 78 ff a8 01 48 0f 44 f9 8b 47 34 85 c0 74 d3 8d [ 1267.534976] RSP: 0000:ffffb032825dfd88 EFLAGS: 00010246 [ 1267.534977] RAX: 0000000000000000 RBX: 0400000000000080 RCX: fffff60050b36380 [ 1267.534978] RDX: 0000000000000001 RSI: 000000000000003b RDI: 000000045d859067 [ 1267.534979] RBP: 0000000000000001 R08: 000000042cd8d000 R09: ffff93eb2bdd1da8 [ 1267.534980] R10: 00000000000001c0 R11: 0000000000000185 R12: ffff93eb580a9518 [ 1267.534981] R13: 000000000000018a R14: ffffb032825dfe18 R15: ffff93eb2bdd1e00 [ 1267.534983] FS: 00007f41b308d700(0000) GS:ffff93eb61280000(0000) knlGS:0000000000000000 [ 1267.534984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1267.534985] CR2: fffff60050b36388 CR3: 00000004584be004 CR4: 00000000001606e0 [ 1267.534986] Call Trace: [ 1267.534992] __handle_mm_fault+0x1030/0x1270 [ 1267.534995] handle_mm_fault+0xd6/0x200 [ 1267.534997] __do_page_fault+0x249/0x4f0 [ 1267.535001] ? page_fault+0x8/0x30 [ 1267.535002] page_fault+0x1e/0x30 [ 1267.535005] RIP: 0033:0x7f41c7abe284 [ 1267.535006] Code: 29 4f 10 0f 29 57 20 0f 29 5f 30 48 83 c7 40 48 83 fa 40 77 d0 0f 11 29 0f 11 71 f0 0f 11 79 e0 44 0f 11 41 d0 41 0f 11 23 c3 <0f> 10 26 0f 10 6e 10 0f 10 76 20 0f 10 7e 30 44 0f 10 44 16 f0 4c [ 1267.535007] RSP: 002b:00007f41b3089788 EFLAGS: 00010202 [ 1267.535009] RAX: 00007f418f9b5600 RBX: 00007f418f9b5600 RCX: 00007f418f9b5600 [ 1267.535010] RDX: 0000000000000194 RSI: 00007f417f8a11c0 RDI: 00007f418f9b5600 [ 1267.535011] RBP: 00007f41b308a150 R08: 0000000000000065 R09: 00007f41c0f50030 [ 1267.535012] R10: 00007f41c0efaa90 R11: 00007f418f9b3984 R12: 0000000000001e00 [ 1267.535013] R13: 0000000000000093 R14: 0000000000000065 R15: 0000000000000000 [ 1267.535014] Modules linked in: isofs uas usb_storage xt_conntrack ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables nfnetlink br_netfilter bridge stp llc ctr ccm fuse aufs(OE) overlay intel_rapl arc4 x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi uvcvideo iwldvm kvm_intel mac80211 snd_hda_codec_realtek kvm snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops irqbypass videobuf2_v4l2 videobuf2_common iwlwifi snd_hda_intel crct10dif_pclmul crc32_pclmul videodev snd_hda_codec joydev ghash_clmulni_intel sg media intel_cstate serio_raw intel_uncore intel_rapl_perf snd_hda_core pcspkr cfg80211 thinkpad_acpi snd_hwdep mei_me iTCO_wdt snd_pcm iTCO_vendor_support [ 1267.535048] mei nvram snd_timer ac snd tpm_tis tpm_tis_core soundcore rfkill tpm battery pcc_cpufreq rng_core evdev coretemp parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb dm_mod sr_mod cdrom sd_mod crc32c_intel ahci libahci i915 libata scsi_mod i2c_i801 aesni_intel aes_x86_64 crypto_simd psmouse cryptd glue_helper lpc_ich xhci_pci ehci_pci i2c_algo_bit ehci_hcd sdhci_pci drm_kms_helper cqhci sdhci xhci_hcd mmc_core drm usbcore e1000e fan usb_common thermal button video [ 1267.535078] CR2: fffff60050b36388 [ 1267.535080] ---[ end trace 19ba3613cfbc34f7 ]--- [ 1267.535082] RIP: 0010:filemap_map_pages+0x9a/0x3a0 [ 1267.535083] Code: ff 0f 84 65 01 00 00 4c 39 6c 24 20 0f 87 77 01 00 00 49 8b 0f 48 85 c9 0f 84 cc 00 00 00 48 89 c8 83 e0 03 0f 85 cb 02 00 00 <48> 8b 41 08 48 8d 78 ff a8 01 48 0f 44 f9 8b 47 34 85 c0 74 d3 8d [ 1267.535084] RSP: 0000:ffffb032825dfd88 EFLAGS: 00010246 [ 1267.535085] RAX: 0000000000000000 RBX: 0400000000000080 RCX: fffff60050b36380 [ 1267.535086] RDX: 0000000000000001 RSI: 000000000000003b RDI: 000000045d859067 [ 1267.535087] RBP: 0000000000000001 R08: 000000042cd8d000 R09: ffff93eb2bdd1da8 [ 1267.535088] R10: 00000000000001c0 R11: 0000000000000185 R12: ffff93eb580a9518 [ 1267.535089] R13: 000000000000018a R14: ffffb032825dfe18 R15: ffff93eb2bdd1e00 [ 1267.535091] FS: 00007f41b308d700(0000) GS:ffff93eb61280000(0000) knlGS:0000000000000000 [ 1267.535092] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1267.535093] CR2: fffff60050b36388 CR3: 00000004584be004 CR4: 00000000001606e0
On 12/23/19 2:16 PM, Evgeny Zinoviev via coreboot wrote:
I however also noticed severe freezes / crashes (OS Debian 10.2) but I'm unsure if they are related to the patch or something different.
Have you got any logs? Do these crashes/freezes look like https://ticket.coreboot.org/issues/121? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Update: I flashed the original Lenovo BIOS v2.81 (with keyboard EC mod) and the issues seem to be gone. Additionally the RAM now runs with 2133MHz without the system freezing and I also can compile crossgcc-i386 with CPUS=8 without issues. Watching videos on YT using Firefox works, too.
The Intel ME is also back. Could there be an issue with the system initialization done by the Intel ME which does not occur if the Intel ME is fully functional?
On 12/24/19 1:14 PM, Lars Hochstetter wrote:
There are some similarities: the system freezes (i.e. UI is unresponsive, you have to hold down the power button to reset the system) and sometimes it outright crashes into a reboot. The crashes seem to trigger when the CPU is running high loads - take note though: with your HT option patch I could run the stress tests of the CoreFreq (https://github.com/cyring/CoreFreq) tool without crashes / freezes but I only tried for a couple minutes.
I do get crashes sometimes when I compile crossgcc-i386 (CPUS=$(nproc), with and without HT enabled through nosmt in the GRUB config) but more often make runs into some error and simply won't compile the sources (I notice a certain tendency towards the gcc compilation) - I would usually recompile but it now seems to be more persistent. There seems to be also a good chance to crash when the CPU isn't fully loaded but multiple applications are open - most notably Firefox when watching Youtube videos and doing something in another application / Firefox tab.
Originally I was running coreboot v4.6, then changed to v4.8.1 then v4.9, then for some time to master (blobs were based on BIOS v2.79, me disabled and neutered). I'd argue that the issues started appearing after my switch to v4.11. However I can not rule out hardware issues, as I overtightened the screws on the heatsink last time I was working on my T430 - maybe the overtightening caused physical damage to some solder joints on the CPU / socket.
Here are some system stats:
CPU: i7-3840QM, TurboBoost is disabled through the intel_pstate driver to prevent my laptop from melting RAM: HyperX 2x8GB 2133MHz DDR3 1.35V HX321LS11IB2K2/16, it runs at 1600MHz (the "ignore fuses" option isn't set) though as the system would freeze shortly after logging in Mainboard: no dGPU variant OS: Debian 10.2 64bit with the default Gnome3 DE Mods: the 7 row keyboard mod and the FHD screen mod (maybe that is why I didn't see any visual artifacts) coreboot blobs (ifd, me, gbe): based on BIOS v2.81, me is neutered and disabled
I managed to capture following dmesg, when the system soft locked while Firefox was open and I managed to switch to a tty. If I recall correctly there was some audio repetition.
[ 926.163124] ISO 9660 Extensions: RRIP_1991A [ 1094.740789] usb 1-1.2: USB disconnect, device number 8 [ 1267.534956] BUG: unable to handle kernel paging request at fffff60050b36388 [ 1267.534960] PGD 4617e2067 P4D 4617e2067 PUD 0 [ 1267.534964] Oops: 0000 [#1] SMP PTI [ 1267.534966] CPU: 2 PID: 5953 Comm: Compositor Tainted: G OE 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2 [ 1267.534967] Hardware name: LENOVO 2347CM9/2347CM9, BIOS CBET4000 4.11 11/19/2019 [ 1267.534973] RIP: 0010:filemap_map_pages+0x9a/0x3a0 [ 1267.534974] Code: ff 0f 84 65 01 00 00 4c 39 6c 24 20 0f 87 77 01 00 00 49 8b 0f 48 85 c9 0f 84 cc 00 00 00 48 89 c8 83 e0 03 0f 85 cb 02 00 00 <48> 8b 41 08 48 8d 78 ff a8 01 48 0f 44 f9 8b 47 34 85 c0 74 d3 8d [ 1267.534976] RSP: 0000:ffffb032825dfd88 EFLAGS: 00010246 [ 1267.534977] RAX: 0000000000000000 RBX: 0400000000000080 RCX: fffff60050b36380 [ 1267.534978] RDX: 0000000000000001 RSI: 000000000000003b RDI: 000000045d859067 [ 1267.534979] RBP: 0000000000000001 R08: 000000042cd8d000 R09: ffff93eb2bdd1da8 [ 1267.534980] R10: 00000000000001c0 R11: 0000000000000185 R12: ffff93eb580a9518 [ 1267.534981] R13: 000000000000018a R14: ffffb032825dfe18 R15: ffff93eb2bdd1e00 [ 1267.534983] FS: 00007f41b308d700(0000) GS:ffff93eb61280000(0000) knlGS:0000000000000000 [ 1267.534984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1267.534985] CR2: fffff60050b36388 CR3: 00000004584be004 CR4: 00000000001606e0 [ 1267.534986] Call Trace: [ 1267.534992] __handle_mm_fault+0x1030/0x1270 [ 1267.534995] handle_mm_fault+0xd6/0x200 [ 1267.534997] __do_page_fault+0x249/0x4f0 [ 1267.535001] ? page_fault+0x8/0x30 [ 1267.535002] page_fault+0x1e/0x30 [ 1267.535005] RIP: 0033:0x7f41c7abe284 [ 1267.535006] Code: 29 4f 10 0f 29 57 20 0f 29 5f 30 48 83 c7 40 48 83 fa 40 77 d0 0f 11 29 0f 11 71 f0 0f 11 79 e0 44 0f 11 41 d0 41 0f 11 23 c3 <0f> 10 26 0f 10 6e 10 0f 10 76 20 0f 10 7e 30 44 0f 10 44 16 f0 4c [ 1267.535007] RSP: 002b:00007f41b3089788 EFLAGS: 00010202 [ 1267.535009] RAX: 00007f418f9b5600 RBX: 00007f418f9b5600 RCX: 00007f418f9b5600 [ 1267.535010] RDX: 0000000000000194 RSI: 00007f417f8a11c0 RDI: 00007f418f9b5600 [ 1267.535011] RBP: 00007f41b308a150 R08: 0000000000000065 R09: 00007f41c0f50030 [ 1267.535012] R10: 00007f41c0efaa90 R11: 00007f418f9b3984 R12: 0000000000001e00 [ 1267.535013] R13: 0000000000000093 R14: 0000000000000065 R15: 0000000000000000 [ 1267.535014] Modules linked in: isofs uas usb_storage xt_conntrack ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables nfnetlink br_netfilter bridge stp llc ctr ccm fuse aufs(OE) overlay intel_rapl arc4 x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi uvcvideo iwldvm kvm_intel mac80211 snd_hda_codec_realtek kvm snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops irqbypass videobuf2_v4l2 videobuf2_common iwlwifi snd_hda_intel crct10dif_pclmul crc32_pclmul videodev snd_hda_codec joydev ghash_clmulni_intel sg media intel_cstate serio_raw intel_uncore intel_rapl_perf snd_hda_core pcspkr cfg80211 thinkpad_acpi snd_hwdep mei_me iTCO_wdt snd_pcm iTCO_vendor_support [ 1267.535048] mei nvram snd_timer ac snd tpm_tis tpm_tis_core soundcore rfkill tpm battery pcc_cpufreq rng_core evdev coretemp parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb dm_mod sr_mod cdrom sd_mod crc32c_intel ahci libahci i915 libata scsi_mod i2c_i801 aesni_intel aes_x86_64 crypto_simd psmouse cryptd glue_helper lpc_ich xhci_pci ehci_pci i2c_algo_bit ehci_hcd sdhci_pci drm_kms_helper cqhci sdhci xhci_hcd mmc_core drm usbcore e1000e fan usb_common thermal button video [ 1267.535078] CR2: fffff60050b36388 [ 1267.535080] ---[ end trace 19ba3613cfbc34f7 ]--- [ 1267.535082] RIP: 0010:filemap_map_pages+0x9a/0x3a0 [ 1267.535083] Code: ff 0f 84 65 01 00 00 4c 39 6c 24 20 0f 87 77 01 00 00 49 8b 0f 48 85 c9 0f 84 cc 00 00 00 48 89 c8 83 e0 03 0f 85 cb 02 00 00 <48> 8b 41 08 48 8d 78 ff a8 01 48 0f 44 f9 8b 47 34 85 c0 74 d3 8d [ 1267.535084] RSP: 0000:ffffb032825dfd88 EFLAGS: 00010246 [ 1267.535085] RAX: 0000000000000000 RBX: 0400000000000080 RCX: fffff60050b36380 [ 1267.535086] RDX: 0000000000000001 RSI: 000000000000003b RDI: 000000045d859067 [ 1267.535087] RBP: 0000000000000001 R08: 000000042cd8d000 R09: ffff93eb2bdd1da8 [ 1267.535088] R10: 00000000000001c0 R11: 0000000000000185 R12: ffff93eb580a9518 [ 1267.535089] R13: 000000000000018a R14: ffffb032825dfe18 R15: ffff93eb2bdd1e00 [ 1267.535091] FS: 00007f41b308d700(0000) GS:ffff93eb61280000(0000) knlGS:0000000000000000 [ 1267.535092] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1267.535093] CR2: fffff60050b36388 CR3: 00000004584be004 CR4: 00000000001606e0
On 12/23/19 2:16 PM, Evgeny Zinoviev via coreboot wrote:
I however also noticed severe freezes / crashes (OS Debian 10.2) but I'm unsure if they are related to the patch or something different.
Have you got any logs? Do these crashes/freezes look like https://ticket.coreboot.org/issues/121? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi, Lars.
Update: I flashed the original Lenovo BIOS v2.81 (with keyboard EC mod) and the issues seem to be gone.
Do you have any freezes/crashes while running latest coreboot (from master) without the HT patch?
Hi Evgeny,
I didn't try the latest coreboot master in a while as I wanted to rule out hardware damage as a possible cause and reflashed the Lenovo OEM BIOS.
From what I recall, the last coreboot master I tried resulted in crashes without your patch.
I intend to run following tests with the latest coreboot master (I'll note the commit hash and use the same commit for all of my tests) and SeaBIOS as payload (blobs will be extracted from the Lenovo OEM BIOS v2.81):
1. fully blob'ed (vgabios, ifd, me, gbe) 2. libgfxinit instead of vgabios 3. fully blob'ed with the me shrinked 4. libgfxinit instead of vgabios with the me shrinked
If all tests pass, I'll try the same tests with your patch. If a test without your patch applied fails I'd argue that something else is to blame.
I'm unsure on how to provide the µCode patches, i.e. integrate them in coreboot or have them patched by Linux.
Since watching videos on Firefox and compiling the coreboot toolchain seem to reliably crash the laptop I'll use those to try and provoke a crash. I'm open to suggestions for other "crash provoking workloads".
I'm also considering reinstalling the OS (Debian Buster 10.2 with Gnome3) to rule out some weird configuration as a possibility.
On 1/17/20 12:37 AM, Evgeny Zinoviev via coreboot wrote:
Hi, Lars.
Update: I flashed the original Lenovo BIOS v2.81 (with keyboard EC mod) and the issues seem to be gone.
Do you have any freezes/crashes while running latest coreboot (from master) without the HT patch? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
From what I recall, the last coreboot master I tried resulted in crashes without your patch.
If it's so, then the HT patch is not to blame... But we'll see after your tests.
I intend to run following tests with the latest coreboot master (I'll note the commit hash and use the same commit for all of my tests) and SeaBIOS as payload (blobs will be extracted from the Lenovo OEM BIOS v2.81):
- fully blob'ed (vgabios, ifd, me, gbe)
- libgfxinit instead of vgabios
- fully blob'ed with the me shrinked
- libgfxinit instead of vgabios with the me shrinked
I personally don't think that libgfxinit instead of vgabios or vice versa will make any difference in this case. I'd recommend to test native raminit vs mrc.bin instead.
I'm unsure on how to provide the µCode patches, i.e. integrate them in coreboot or have them patched by Linux.
If you mean microcode updates, then there's an option in coreboot's config (and you also need to enable use of binary-only repository in the General section).
I personally don't think that libgfxinit instead of vgabios or vice versa will make any difference in this case. I'd recommend to test native raminit vs mrc.bin instead.
Correct me if I'm wrong but isn't the mrc.bin Haswell specific [1]? From what I recall I never saw an option in "make menuconfig" to choose native raminit or mrc.bin on IvyBridge. If there is such an option (now) I'll definitely try it!
If you mean microcode updates, then there's an option in coreboot's config (and you also need to enable use of binary-only repository in the General section).
In terms of microcode updates I'm concerned about "compability", i.e. does Debian use an older / newer version than coreboot and vice versa, is there some specific initialization done by Debian / coreboot which the other one does not perform etc.
[1] https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html
On 1/19/20 12:22 AM, Evgeny Zinoviev via coreboot wrote:
From what I recall, the last coreboot master I tried resulted in crashes without your patch.
If it's so, then the HT patch is not to blame... But we'll see after your tests.
I intend to run following tests with the latest coreboot master (I'll note the commit hash and use the same commit for all of my tests) and SeaBIOS as payload (blobs will be extracted from the Lenovo OEM BIOS v2.81):
- fully blob'ed (vgabios, ifd, me, gbe)
- libgfxinit instead of vgabios
- fully blob'ed with the me shrinked
- libgfxinit instead of vgabios with the me shrinked
I personally don't think that libgfxinit instead of vgabios or vice versa will make any difference in this case. I'd recommend to test native raminit vs mrc.bin instead.
I'm unsure on how to provide the µCode patches, i.e. integrate them in coreboot or have them patched by Linux.
If you mean microcode updates, then there's an option in coreboot's config (and you also need to enable use of binary-only repository in the General section). _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I personally don't think that libgfxinit instead of vgabios or vice versa will make any difference in this case. I'd recommend to test native raminit vs mrc.bin instead.
Correct me if I'm wrong but isn't the mrc.bin Haswell specific [1]? From what I recall I never saw an option in "make menuconfig" to choose native raminit or mrc.bin on IvyBridge. If there is such an option (now) I'll definitely try it!
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Unfortunately I'll be rather busy until mid April this year - here is my plan for the time being:
I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot and run it. I'll report back if it's just bad RAM or something else.
Since my T430 was modified a couple times I'd also suggest we try to find someone with a more stock T430 to see if your HT patch works. The X230 somewhere in this thread worked and I'd argue that it does work properly on unmodified Thinkpads.
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious?
Regards
lhochstetter
I managed to find some time to run memtest86+ v5.01 as a SeaBIOS payload [1].
As it turns out the RAM went bad - I made sure to check with another pair of sticks. I'll replace the RAM and retry the HT patch when my free time allows for it.
Sorry for creating so much noise over something so simple.
Regards
lhochstetter
[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html
On 2/8/20 4:23 PM, Lars Hochstetter wrote:
Unfortunately I'll be rather busy until mid April this year - here is my plan for the time being:
I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot and run it. I'll report back if it's just bad RAM or something else.
Since my T430 was modified a couple times I'd also suggest we try to find someone with a more stock T430 to see if your HT patch works. The X230 somewhere in this thread worked and I'd argue that it does work properly on unmodified Thinkpads.
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious?
Regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Sorry for the long silence - I finally found some time to test the HT patch.
I used coreboot v4.11 as a basis since at this point in time the patch produced merge conflicts with newer commits.
I used memtest86+ v5.01 (forced SMP, RAM: 16GB @ 1600MHz, CPU: Intel i7-3840QM) as mentioned in my last mail. When HT is enabled memtest86+ runs just fine.
When I disable HT it gets reproducibly stuck at test #7 (block move), at 4096M-6144M, with cores 0-2 working, core 3 just switched to "W".
I'll test some other workloads which were problematic in the past (compiling coreboot, watching videos using Firefox).
Shall I provide my .config or any other information?
Regards
lhochstetter
On 11/02/2020 15:23, Lars Hochstetter wrote:
I managed to find some time to run memtest86+ v5.01 as a SeaBIOS payload [1].
As it turns out the RAM went bad - I made sure to check with another pair of sticks. I'll replace the RAM and retry the HT patch when my free time allows for it.
Sorry for creating so much noise over something so simple.
Regards
lhochstetter
[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html
On 2/8/20 4:23 PM, Lars Hochstetter wrote:
Unfortunately I'll be rather busy until mid April this year - here is my plan for the time being:
I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot and run it. I'll report back if it's just bad RAM or something else.
Since my T430 was modified a couple times I'd also suggest we try to find someone with a more stock T430 to see if your HT patch works. The X230 somewhere in this thread worked and I'd argue that it does work properly on unmodified Thinkpads.
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious?
Regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi!
Thank you for the report.
If you're still on it, can you try the latest update? There was seemingly incorrect reset sequence after setting the HT disable bit. I'm not sure if it was the reason of problems, but would be good to test again.
On 6/16/20 12:31 PM, Lars Hochstetter wrote:
Sorry for the long silence - I finally found some time to test the HT patch.
I used coreboot v4.11 as a basis since at this point in time the patch produced merge conflicts with newer commits.
I used memtest86+ v5.01 (forced SMP, RAM: 16GB @ 1600MHz, CPU: Intel i7-3840QM) as mentioned in my last mail. When HT is enabled memtest86+ runs just fine.
When I disable HT it gets reproducibly stuck at test #7 (block move), at 4096M-6144M, with cores 0-2 working, core 3 just switched to "W".
I'll test some other workloads which were problematic in the past (compiling coreboot, watching videos using Firefox).
Shall I provide my .config or any other information?
Regards
lhochstetter
On 11/02/2020 15:23, Lars Hochstetter wrote:
I managed to find some time to run memtest86+ v5.01 as a SeaBIOS payload [1].
As it turns out the RAM went bad - I made sure to check with another pair of sticks. I'll replace the RAM and retry the HT patch when my free time allows for it.
Sorry for creating so much noise over something so simple.
Regards
lhochstetter
[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html
On 2/8/20 4:23 PM, Lars Hochstetter wrote:
Unfortunately I'll be rather busy until mid April this year - here is my plan for the time being:
I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot and run it. I'll report back if it's just bad RAM or something else.
Since my T430 was modified a couple times I'd also suggest we try to find someone with a more stock T430 to see if your HT patch works. The X230 somewhere in this thread worked and I'd argue that it does work properly on unmodified Thinkpads.
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious?
Regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I tried the following:
4.11 + patchset 15 4.12 + patchset 15
In both cases I saw the same behaviour described in my last mail. (without HT -> freeze at test #7, with HT running fine for hours and finishing all tests)
The first run without HT on 4.12 + patchset 15 yielded 400+ errors but continued running to some point, the other two runs did get stuck on the "test #7 mark".
I also tried to get memtest86+ v5.31b to run from a USB stick but it doesn't work - I didn't dig deeper into it, yet.
I'm wondering if I could convert the memtest86+ v5.31b iso into a floppy image and add it just as I did with v5.01.
On 18.06.20 01:05, Evgeny Zinoviev via coreboot wrote:
Hi!
Thank you for the report.
If you're still on it, can you try the latest update? There was seemingly incorrect reset sequence after setting the HT disable bit. I'm not sure if it was the reason of problems, but would be good to test again.
On 6/16/20 12:31 PM, Lars Hochstetter wrote:
Sorry for the long silence - I finally found some time to test the HT patch.
I used coreboot v4.11 as a basis since at this point in time the patch produced merge conflicts with newer commits.
I used memtest86+ v5.01 (forced SMP, RAM: 16GB @ 1600MHz, CPU: Intel i7-3840QM) as mentioned in my last mail. When HT is enabled memtest86+ runs just fine.
When I disable HT it gets reproducibly stuck at test #7 (block move), at 4096M-6144M, with cores 0-2 working, core 3 just switched to "W".
I'll test some other workloads which were problematic in the past (compiling coreboot, watching videos using Firefox).
Shall I provide my .config or any other information?
Regards
lhochstetter
On 11/02/2020 15:23, Lars Hochstetter wrote:
I managed to find some time to run memtest86+ v5.01 as a SeaBIOS payload [1].
As it turns out the RAM went bad - I made sure to check with another pair of sticks. I'll replace the RAM and retry the HT patch when my free time allows for it.
Sorry for creating so much noise over something so simple.
Regards
lhochstetter
[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html
On 2/8/20 4:23 PM, Lars Hochstetter wrote:
Unfortunately I'll be rather busy until mid April this year - here is my plan for the time being:
I'll reinstall Linux Mint Cinnamon, integrate memtest86+ into coreboot and run it. I'll report back if it's just bad RAM or something else.
Since my T430 was modified a couple times I'd also suggest we try to find someone with a more stock T430 to see if your HT patch works. The X230 somewhere in this thread worked and I'd argue that it does work properly on unmodified Thinkpads.
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious?
Regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Update: I managed to get memtest86+ v5.31b running.
I downloaded the .iso.zip and used geteltorito v0.6 to turn the .iso file into a 1.44meg floppy image. I then added the floppy image like the memtest86+ v5.01 floppy image to my coreboot image (4.12 + patchset 15).
Preliminary tests with memtest86+ v5.31b went without an issue (Note: I didn't run all the tests, but test #7 was passed with and without HT).
I'll try to run all tests with and without HT on 4.12 + patchset 15 around the weekend.
On 18/06/2020 20:38, Lars Hochstetter wrote:
I tried the following:
4.11 + patchset 15 4.12 + patchset 15
In both cases I saw the same behaviour described in my last mail. (without HT -> freeze at test #7, with HT running fine for hours and finishing all tests)
The first run without HT on 4.12 + patchset 15 yielded 400+ errors but continued running to some point, the other two runs did get stuck on the "test #7 mark".
I also tried to get memtest86+ v5.31b to run from a USB stick but it doesn't work - I didn't dig deeper into it, yet.
I'm wondering if I could convert the memtest86+ v5.31b iso into a floppy image and add it just as I did with v5.01.
Update II:
All tests passed with and without HT enabled!
I discovered something curious though - if I disable HT memtest86+ finishes a pass in 45ish minutes. If I enable HT it takes 4+ hours.
I don't know if it's due to coreboot or memtest86+ as memtest86+ v5.01 also took around 4+ hours for all tests with HT enabled.
Maybe it is a bug with memtest86+ ?
On 19.06.20 00:58, Lars Hochstetter wrote:
Update: I managed to get memtest86+ v5.31b running.
I downloaded the .iso.zip and used geteltorito v0.6 to turn the .iso file into a 1.44meg floppy image. I then added the floppy image like the memtest86+ v5.01 floppy image to my coreboot image (4.12 + patchset 15).
Preliminary tests with memtest86+ v5.31b went without an issue (Note: I didn't run all the tests, but test #7 was passed with and without HT).
I'll try to run all tests with and without HT on 4.12 + patchset 15 around the weekend.
Could be... Thanks for testing!
I've also put it on some of my daily work machines: a quad-code Ivy and a dual-code Sandy in order to see how it works in a real world... Works so far. So if it doesn't end up crashing in a week or two I'd say it's stable. We'll see.
On 6/20/20 1:42 PM, Lars Hochstetter wrote:
Update II:
All tests passed with and without HT enabled!
I discovered something curious though - if I disable HT memtest86+ finishes a pass in 45ish minutes. If I enable HT it takes 4+ hours.
I don't know if it's due to coreboot or memtest86+ as memtest86+ v5.01 also took around 4+ hours for all tests with HT enabled.
Maybe it is a bug with memtest86+ ?
On 19.06.20 00:58, Lars Hochstetter wrote:
Update: I managed to get memtest86+ v5.31b running.
I downloaded the .iso.zip and used geteltorito v0.6 to turn the .iso file into a 1.44meg floppy image. I then added the floppy image like the memtest86+ v5.01 floppy image to my coreboot image (4.12 + patchset 15).
Preliminary tests with memtest86+ v5.31b went without an issue (Note: I didn't run all the tests, but test #7 was passed with and without HT).
I'll try to run all tests with and without HT on 4.12 + patchset 15 around the weekend.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
s/code/core/, lol.
On 6/20/20 2:46 PM, Evgeny Zinoviev via coreboot wrote:
Could be... Thanks for testing!
I've also put it on some of my daily work machines: a quad-code Ivy and a dual-code Sandy in order to see how it works in a real world... Works so far. So if it doesn't end up crashing in a week or two I'd say it's stable. We'll see.
On 6/20/20 1:42 PM, Lars Hochstetter wrote:
Update II:
All tests passed with and without HT enabled!
I discovered something curious though - if I disable HT memtest86+ finishes a pass in 45ish minutes. If I enable HT it takes 4+ hours.
I don't know if it's due to coreboot or memtest86+ as memtest86+ v5.01 also took around 4+ hours for all tests with HT enabled.
Maybe it is a bug with memtest86+ ?
On 19.06.20 00:58, Lars Hochstetter wrote:
Update: I managed to get memtest86+ v5.31b running.
I downloaded the .iso.zip and used geteltorito v0.6 to turn the .iso file into a 1.44meg floppy image. I then added the floppy image like the memtest86+ v5.01 floppy image to my coreboot image (4.12 + patchset 15).
Preliminary tests with memtest86+ v5.31b went without an issue (Note: I didn't run all the tests, but test #7 was passed with and without HT).
I'll try to run all tests with and without HT on 4.12 + patchset 15 around the weekend.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
So, it's been three weeks, no hangs, no crashes, everything's fine on my W530 (which is my primary working machine) with 5.4.28-gentoo kernel and HT disabled by coreboot patch. CPU is i7-3940XM.
On 20.06.2020 14:46, Evgeny Zinoviev via coreboot wrote:
Could be... Thanks for testing!
I've also put it on some of my daily work machines: a quad-code Ivy and a dual-code Sandy in order to see how it works in a real world... Works so far. So if it doesn't end up crashing in a week or two I'd say it's stable. We'll see.
On 6/20/20 1:42 PM, Lars Hochstetter wrote:
Update II:
All tests passed with and without HT enabled!
I discovered something curious though - if I disable HT memtest86+ finishes a pass in 45ish minutes. If I enable HT it takes 4+ hours.
I don't know if it's due to coreboot or memtest86+ as memtest86+ v5.01 also took around 4+ hours for all tests with HT enabled.
Maybe it is a bug with memtest86+ ?
On 19.06.20 00:58, Lars Hochstetter wrote:
Update: I managed to get memtest86+ v5.31b running.
I downloaded the .iso.zip and used geteltorito v0.6 to turn the .iso file into a 1.44meg floppy image. I then added the floppy image like the memtest86+ v5.01 floppy image to my coreboot image (4.12 + patchset 15).
Preliminary tests with memtest86+ v5.31b went without an issue (Note: I didn't run all the tests, but test #7 was passed with and without HT).
I'll try to run all tests with and without HT on 4.12 + patchset 15 around the weekend.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Sorry for a long reply too. About mrc.bin: no, it's actually possible to use mrc blob on Sandy/Ivy, but as I see it's not supported across all boards. X220 has support, other boards needs patching (or maybe patches are already on gerrit, I'm not sure). It shouldn't be hard to get it working, though.
Can you elaborate on this one? Why does the X220 has support and other Sandy/IvyBridge based laptops are not supported? Wasn't one of the ideas for coreboot to have a more common code base or am I missing something obvious?
Basically, it's just not enabled in other boards' configs. I don't know why exactly it is enabled only in X220, but I can guess it's because the native raminit is preferable, works quite well and nobody needed mrc raminit on other models. You can try this patch https://review.coreboot.org/c/coreboot/+/37153 on your T430.
Sorry for the long wait - I was quite busy.
If it's so, then the HT patch is not to blame... But we'll see after your tests.
I hope I never claimed / implied that! If anything reducing the amount of threads (either through the patch or the nosmt kernel parameter) did improve stability when running Debian.
Onto the tests - I'm rather confused on how to interpret the results.
As stated before, I would test multiple setups with blobs (ifd, me, gbe) based on the Lenovo BIOS v2.81. I have omitted the vgabios test.
1. fully blob'ed with the me intact (CBFS size 0x700000)
2. fully blob'ed with the me shrinked (CBFS size 0xBE5000)
I tested on two different Linux distributions.
(I build and flashed coreboot using a Raspberry Pi at a older master than the master used for testing)
*Debian Buster 10.2, Kernel 4.19.0, "old master"*
I couldn't build the crossgcc-i386 with multiple threads or watch YT
videos using Firefox. I eventually was fed up and decided to install Linux Mint 19.3 Cinnamon to make sure I didn't mess up something on my Debian install.
*Linux Mint 19.3 Cinnamon, Kernel 5.3.0, master @ 1ab6f0c176c1aa6947bf0d3fbe0a213f316e9c67*
I could build the crossgcc-i386 with multiple threads without issues.
I could also watch Youtube videos using Firefox but at some point the system would become more or less randomly unstable or Cinnamon would crash / freeze. Namely when I watched videos in full screen mode. CPU temps seemed fine though. To rule out Cinnamon as an issue, I installed Linux Mint 19.3 XFCE.
*Linux Mint 19.3 XFCE, Kernel 5.0.0, master @ 1ab6f0c176c1aa6947bf0d3fbe0a213f316e9c67*
The first build of the crossgcc-i386 with multiple threads did
produce some issues / the build could not be continued due to an error. After a crossgcc-clean the build completed just fine. I also got freezes when watching YT videos on Firefox namely in full screen mode.
I have attached my .config and a script + systemd unit which I use to reduce power draw of my T430 (all settings were suggested by powertop, aside from deactivating turbo boost).
---
I'm wondering if this is really an issue with coreboot / my Linux distro or rather hardware related ... I'm considering to throw memtest86+ [1] at the RAM and see if the RAM is working properly.
Regards
lhochstetter
[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html
Hi again. There's another patch that fits to the topic that you will probably want to try out: https://review.coreboot.org/c/coreboot/+/42547/
On 12/15/19 3:57 PM, Lars Hochstetter wrote:
Hi everyone,
I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot.
Is anyone currently working on something similar?
Is anything planned in that regard?
Kind regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi, thanks for the pointer!
I only fear that running my CPU at the maximum possible Turbo Ratio will overheat it.
I can give it a try but I'm actually looking for an option to limit the maximum Turbo Ratio the CPU is allowed to reach (hence the disabling of TurboBoost altogether).
On 21/06/2020 00:52, Evgeny Zinoviev via coreboot wrote:
Hi again. There's another patch that fits to the topic that you will probably want to try out: https://review.coreboot.org/c/coreboot/+/42547/
On 12/15/19 3:57 PM, Lars Hochstetter wrote:
Hi everyone,
I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot.
Is anyone currently working on something similar?
Is anything planned in that regard?
Kind regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Update: I tried the https://review.coreboot.org/c/coreboot/+/42547/ on my T430 (i7-3840QM, Debian Buster 4.19.0-9-amd64) using coreboot v4.12 + SeaBIOS as base.
I used s-tui to track the CPU frequency.
Without the patch on coreboot v4.12 the CPU reached its "usual" 3.3 - 3.4 GHz (4C/8T) using the stress function of s-tui.
With the patch the CPU reached at most 3.2GHz (intel_pstate) / 2.8GHz (acpi-cpufreq).
Maybe there is an issue with mobile CPUs?
On 24.06.20 20:00, Lars Hochstetter wrote:
Hi, thanks for the pointer!
I only fear that running my CPU at the maximum possible Turbo Ratio will overheat it.
I can give it a try but I'm actually looking for an option to limit the maximum Turbo Ratio the CPU is allowed to reach (hence the disabling of TurboBoost altogether).
On 21/06/2020 00:52, Evgeny Zinoviev via coreboot wrote:
Hi again. There's another patch that fits to the topic that you will probably want to try out: https://review.coreboot.org/c/coreboot/+/42547/
On 12/15/19 3:57 PM, Lars Hochstetter wrote:
Hi everyone,
I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot.
Is anyone currently working on something similar?
Is anything planned in that regard?
Kind regards
lhochstetter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Lars, list,
On Wed, Jul 15, 2020 at 5:41 PM Lars Hochstetter lars.hochstetter@fu-berlin.de wrote:
Update: I tried the https://review.coreboot.org/c/coreboot/+/42547/ on my T430 (i7-3840QM, Debian Buster 4.19.0-9-amd64) using coreboot v4.12 + SeaBIOS as base.
I used s-tui to track the CPU frequency.
Without the patch on coreboot v4.12 the CPU reached its "usual" 3.3 - 3.4 GHz (4C/8T) using the stress function of s-tui.
With the patch the CPU reached at most 3.2GHz (intel_pstate) / 2.8GHz (acpi-cpufreq).
Thanks for testing! I'm the one who made that change, and I currently only have two CPUs to test it with. I generally check the CPU frequency with: `cat /proc/cpuinfo | grep MHz`
Maybe there is an issue with mobile CPUs?
I'd say the issue is because of how I determine the overclocking headroom that the CPU is capable of. On my CPUs, it happens that the number of OC bins is the same as the number of steps between the base frequency ratio and the maximum turbo ratio. I imagine this isn't the case for other CPUs (which I do not currently have any of nearby) and would explain why the gains aren't as high as expected.
It would be nice if you could provide a few MSR values from that CPU. You can use `rdmsr` from msr-tools: https://github.com/intel/msr-tools
* 0xce (MSR_PLATFORM_INFO) * 0x194 (MSR_FLEX_RATIO) * 0x1ad (MSR_TURBO_RATIO_LIMIT)
On 24.06.20 20:00, Lars Hochstetter wrote:
Hi, thanks for the pointer!
I only fear that running my CPU at the maximum possible Turbo Ratio will overheat it.
I can give it a try but I'm actually looking for an option to limit the maximum Turbo Ratio the CPU is allowed to reach (hence the disabling of TurboBoost altogether).
In its current state, my patch seems to achieve that :P
On 21/06/2020 00:52, Evgeny Zinoviev via coreboot wrote:
Hi again. There's another patch that fits to the topic that you will probably want to try out: https://review.coreboot.org/c/coreboot/+/42547/
On 12/15/19 3:57 PM, Lars Hochstetter wrote:
Hi everyone,
I'm looking for an option to configure my Intel IvyBridge CPU (enable / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, "only virtualization" is configurable and can not be enabled / disabled "in flight" but requires a rebuild of coreboot.
Is anyone currently working on something similar?
Is anything planned in that regard?
Kind regards
lhochstetter
Thanks in advance,
Angel
Hi Angel,
here are the read outs (-X -0) for the MSRs:
0x000000CE -> 00080C10F0011C00
0x00000194 -> 0000000000090000
0x000001AD -> 0000000024242526
I'd say the issue is because of how I determine the overclocking headroom that the CPU is capable of. On my CPUs, it happens that the number of OC bins is the same as the number of steps between the base frequency ratio and the maximum turbo ratio. I imagine this isn't the case for other CPUs (which I do not currently have any of nearby) and would explain why the gains aren't as high as expected.
From what I've heard about Ivy Bridge Mobile CPUs it depends on the TDP (I don't know about the Sandy Bridge or ULV models):
CPUs with 35W TDP should just work as you described.
CPUs with 45W TDP can be "overclocked" by up to 400MHz on top of their maximum turbo ratio. In the case of my i7-3840QM it should reach around 4,2 GHz (without taking additional voltage into consideration).
CPUs with 55W TDP (i.e. the extreme edition "XM") have a unlocked multiplier and may be considered as the equivalent to the "K" CPUs on the desktop.
In its current state, my patch seems to achieve that :P
It certainly does ;) I find it curious though that intel_pstate and acpi-cpufreq exhibit different behaviors in terms of maximum frequency.
Kind regards,
Lars
-
Andrey Korolyov -
Angel Pons -
Evgeny Zinoviev -
Jose Trujillo -
Lars Hochstetter -
mkopec12＠gmail.com