[coreboot] Memory frequency issue with the T430 and 2133MHz RAM
Hi everyone, I’m having an issue with the option “Ignore vendor programmed fuses that limit max. DRAM frequency”. When I enable said option my laptop will turn on but the screen stays black and “nothing” happens. The only option to recover the laptop is to install a 1600MHz stick, that will limit the other 2133MHz stick to 1600MHz and to reflash a coreboot build with above mentioned option turned off. My laptop is a Lenovo Thinkpad T430 without a dGPU (i.e. only Intel HD4000 iGPU). As far as I can recall the memory worked at its maximum frequency (2133MHz) fine when using the Lenovo OEM BIOS. I’m using coreboot v4.12 with SeaBIOS v1.13.0 and use libgfxinit. I also tried using the VGA option ROM but to no avail. I've appended the output of /dmidecode -t memory/ and /dmidecode -t processor/ and /uname -r/ below. Does anyone else has this issue? How do I debug this issue? Evgeny Zinoviev pointed me some time ago to the optional use of the mrc.bin for the X220 [1] and someone trying to use the mrc.bin for the T430 [2]. Could I somehow use the mrc.bin approach for the X220 in [2] in conjunction with [1] and [3] to allow the optional use of the mrc.bin for the T430? Kind regards lhochstetter [1] https://review.coreboot.org/c/coreboot/+/37153 [2] https://review.coreboot.org/c/coreboot/+/23489 [3] https://review.coreboot.org/c/coreboot/+/32500 --- /uname -r: /4.19.0-11-amd64 (Debian 4.19.146-1) // Here is the output of /dmidecode -t memory/ and /dmidecode -t processor/: # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x000A, DMI type 17, 40 bytes Memory Device Array Handle: 0x Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: Channel-0-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 800 MT/s Manufacturer: Kingston Serial Number: 4a2d6e3a Asset Tag: Not Specified Part Number: KHX2133C11S3L/8G Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x000B, DMI type 17, 40 bytes Memory Device Array Handle: 0x Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: Channel-1-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 800 MT/s Manufacturer: Kingston Serial Number: 4b2d703a Asset Tag: Not Specified Part Number: KHX2133C11S3L/8G Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: Not Specified Type: Central Processor Family: Pentium Pro Manufacturer: GenuineIntel ID: A9 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 58, Stepping 9 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz Voltage: Unknown External Clock: Unknown Max Speed: Unknown Current Speed: Unknown Status: Unpopulated Upgrade: Unknown L1 Cache Handle: 0x0006 L2 Cache Handle: 0x0007 L3 Cache Handle: 0x0008 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not
[coreboot] Re: Support for enterprise class server hardware?
Hi David, checkout these links: https://coreboot.org/status/board-status.html https://doc.coreboot.org/mainboard/index.html They provide an overview on supported hardware. Regards lhochstetter On 06/09/2020 16:29, David West wrote: I am interested in whether coreboot works with server hardware like PowerEdge servers, Proliant servers, etc. If so, is there a support matrix? Sent from my iPhone ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
Hi Angel, here are the read outs (-X -0) for the MSRs: 0x00CE -> 00080C10F0011C00 0x0194 -> 0009 0x01AD -> 24242526 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memtest86+ stuck
Hi Max, check out this "workaround" [1]: It seems that Memtest86+ is buggy when directly integrated as a part of the coreboot configuration but works fine when you use the Memtest86+ floppy in conjunction with SeaBIOS. Unfortunately I do not know any reason why it is that way or if there is a plan to fix it just that the above mentioned workaround exists and works (on my T430 that is). Kind regards lhochstetter [1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html On 22.04.20 23:11, Max Zim wrote: Hello, I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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 0x70) 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 # # Automatically generated file; DO NOT EDIT. # coreboot configuration # # # General setup # CONFIG_COREBOOT_BUILD=y CONFIG_LOCALVERSION="" CONFIG_CBFS_PREFIX="fallback" CONFIG_COMPILER_GCC=y # CONFIG_COMPILER_LLVM_CLANG is not set # CONFIG_ANY_TOOLCHAIN is not set CONFIG_CCACHE=y # CONFIG_FMD_GENPARSER is not set # CONFIG_UTIL_GENPARSER is not set CONFIG_USE_OPTION_TABLE=y # CONFIG_STATIC_OPTION_TABLE is not set CONFIG_COMPRESS_RAMSTAGE=y CONFIG_INCLUDE_CONFIG_FILE=y CONFIG_COLLECT_TIMESTAMPS=y # CONFIG_TIMESTAMPS_ON_CONSOLE is not set CONFIG_USE_BLOBS=y # CONFIG_USE_AMD_BLOBS is not set # CONFIG_COVERAGE is not set # CONFIG_UBSAN is not set CONFIG_RELOCATABLE_RAMSTAGE=y # CONFIG_NO_STAGE_CACHE is not set CONFIG_TSEG_STAGE_CACHE=y # CONFIG_UPDATE_IMAGE is not set # CONFIG_BOOTSPLASH_IMAGE is not set # # Mainboard # # # Important: Run 'make distclean' before switching boards # # CONFIG_VENDOR_ADLINK is not set # CONFIG_VENDOR_AMD is not set # CONFIG_VENDOR_AOPEN is not set # CONFIG_VENDOR_APPLE is not set # CONFIG_VENDOR_ASROCK is not set # CONFIG_VENDOR_ASUS is not set # CONFIG_VENDOR_BAP is not set # CONFIG_VENDOR_BIOSTAR is not set # CONFIG_VENDOR_CAVIUM is not set # CONFIG_VENDOR_COMPULAB is not set # CONFIG_VENDOR_ELMEX is not set # CONFIG_VENDOR_EMULATION is not set # CONFIG_VENDOR_FACEBOOK is not set # CONFIG_VENDOR_FOXCONN is not set # CONFIG_VENDOR_GETAC is not set # CONFIG_VENDOR_GIGABYTE is not set # CONFIG_VENDOR_GIZMOSPHERE is not set # CONFIG_VENDOR_GOOGLE is not set # CONFIG_VENDOR_HP is not set # CONFIG_VENDOR_IBASE is not set # CONFIG_VENDOR_INTEL is not set # CONFIG_VENDOR_JETWAY is not set # CONFIG_VENDOR_KONTRON is not set CONFIG_VENDOR_LENOVO=y # CONFIG_VENDOR_LIPPERT is not set # CONFIG_VENDOR_MSI is not set # CONFIG_VENDOR_OPENCELLULAR is not set # CONFIG_VENDOR_PACKARDBELL is not set # CONFIG_VENDOR_PCENGINES is not set # CONFIG_VENDOR_PORTWELL is not set # CONFIG_VENDOR_PURISM is not set # CONFIG_VENDOR_RAZER is not set # CONFIG_VENDOR_RODA is not set # CONFIG_VENDOR_SAMSUNG is not set # CONFIG_VENDOR_SAPPHIRE is not set # CONFIG_VENDOR_SCALEWAY is not set # CONFIG_VENDOR_SIEMENS is not set # CONFIG_VENDOR_SIFIVE is not set # CONFIG_VENDOR_SUPERMICRO is not set # CONFIG_VENDOR_TI is not set # CONFIG_VENDOR_UP is not set CONFIG_MAINBOARD_VENDOR="LENOVO" CONFIG_BOARD_SPECIFIC_OPTIONS=y CONFIG_MAINBOARD_DIR="lenovo/t430" CONFIG_MAINBOARD_PART_NUMBER="ThinkPad T430" CONFIG_MAX_CPUS=8 CONFIG_ONBOARD_VGA_IS_PRIMARY=y CONFIG_DIMM_SPD_SIZE=256 # CONFIG_VGA_BIOS is not set CONFIG_VGA_BIOS_ID="8086,0166"
[coreboot] Re: Extended IvyBridge CPU configuration
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): 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 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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Extended IvyBridge CPU configuration
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 f60050b36388 [ 1267.534960] PGD 4617e2067 P4D 4617e2067 PUD 0 [ 1267.534964] Oops: [#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: :b032825dfd88 EFLAGS: 00010246 [ 1267.534977] RAX: RBX: 0480 RCX: f60050b36380 [ 1267.534978] RDX: 0001 RSI: 003b RDI: 00045d859067 [ 1267.534979] RBP: 0001 R08: 00042cd8d000 R09: 93eb2bdd1da8 [ 1267.534980] R10: 01c0 R11: 0185 R12: 93eb580a9518 [ 1267.534981] R13: 018a R14: b032825dfe18 R15: 93eb2bdd1e00 [ 1267.534983] FS: 7f41b308d700() GS:93eb6128() knlGS: [ 1267.534984] CS: 0010 DS: ES: CR0: 80050033 [ 1267.534985] CR2: f60050b36388 CR3: 0004584be004 CR4: 001606e0 [ 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:7f41b3089788 EFLAGS: 00010202 [ 1267.535009] RAX: 7f418f9b5600 RBX: 7f418f9b5600 RCX: 7f418f9b5600 [ 1267.535010] RDX: 0194 RSI: 7f417f8a11c0 RDI: 7f418f9b5600 [ 1267.535011] RBP: 7f41b308a150 R08
[coreboot] Re: Extended IvyBridge CPU configuration
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 f60050b36388 [ 1267.534960] PGD 4617e2067 P4D 4617e2067 PUD 0 [ 1267.534964] Oops: [#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: :b032825dfd88 EFLAGS: 00010246 [ 1267.534977] RAX: RBX: 0480 RCX: f60050b36380 [ 1267.534978] RDX: 0001 RSI: 003b RDI: 00045d859067 [ 1267.534979] RBP: 0001 R08: 00042cd8d000 R09: 93eb2bdd1da8 [ 1267.534980] R10: 01c0 R11: 0185 R12: 93eb580a9518 [ 1267.534981] R13: 018a R14: b032825dfe18 R15: 93eb2bdd1e00 [ 1267.534983] FS: 7f41b308d700() GS:93eb6128() knlGS: [ 1267.534984] CS: 0010 DS: ES: CR0: 80050033 [ 1267.534985] CR2: f60050b36388 CR3: 0004584be004 CR4: 001606e0 [ 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:7f41b3089788 EFLAGS: 00010202 [ 1267.535009] RAX: 7f418f9b5600 RBX: 7f418f9b5600 RCX: 7f418f9b5600 [ 1267.535010] RDX: 0194 RSI: 7f417f8a11c0 RDI: 7f418f9b5600 [ 1267.535011] RBP: 7f41b308a150 R08: 0065 R09: 7f41c0f50030 [ 1267.535012] R10: 7f41c0efaa90 R11: 7f418f9b3984 R12: 1e00 [ 1267.535013] R13: 0093 R14: 0065 R15: [ 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)
[coreboot] Re: Extended IvyBridge CPU configuration
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, mkope...@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-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Extended IvyBridge CPU configuration
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-le...@coreboot.org
