[coreboot] Re: KGPE-D16 maintainership
Can you start with a memtest run with the hardware configuration that causes the kernel bug to trigger? - Original Message - > From: "Kinky Nekoboi" > To: "Vikings GmbH" > Cc: "Piotr Król" , "coreboot" , > "insurgo" > Sent: Wednesday, October 2, 2019 2:44:22 AM > Subject: [coreboot] Re: KGPE-D16 maintainership > let me correct, you have to have modules installed on both NUMA nodes. > (For example when you have an 16 core opteron, i guess the 8 core > version have only one numa node inside ? > > Am 02.10.19 um 09:00 schrieb Vikings GmbH: >> On Wed, 2 Oct 2019 00:58:43 +0200 >> Kinky Nekoboi wrote: >>> I finally have found the problem: >>> >>> This BUG appears when you only have memory in the Orange Slots >>> >>> yikes this boathert me for such a long time >>> >>> any idea how i could debug this further ? >>> >>> Am 18.09.19 um 14:22 schrieb Kinky Nekoboi: Highly appreciating that afford. Would like to mention Problems with Current Linux kernel with this Board. ( The SLUB Allocator is causing panics at boot for my builds) Pls see: https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html >> Not sure if that helps at all, but I'm getting reports that >> >> CONFIG_SLAB=y >> CONFIG_SLAB_MERGE_DEFAULT=y >> CONFIG_SLAB_FREELIST_RANDOM=y >> >> instead of >> >> CONFIG_SLUB=y >> CONFIG_SLUB_CPU_PARTIAL=y >> >> "fixes" the issues. >> > Hi all, > we see a lot of attention around KGPE-D16 maintainership problems. > After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb > decided to help in maintaining that platform by organizing crowd > founding campaign or getting founds in other ways (direct > sponsors). > > Since we are based in Poland there is chance that even with small > contribution from community we would be able to cover the costs. > > Ideal plan would be to have structure similar to what we maintain > for PC Engines: > https://pcengines.github.io/ > Where we providing signed and reproducible binaries every month and > keep as close to mainline as possible. Of course if development > will be active, then there always would be delta of patches held > in review. > > Unfortunately we don't have hardware. During OSFC 2019 Stefan left > one board, but it was too late (and probably too expensive) for us > to organize any shipment to Poland. We looking to have 2 > mainboards one for development and one in our automated regression > testing environment. Of course we will start even with just one. > > If anyone is willing to help in founding, sponsoring hardware or by > code development and testing we would be very grateful. > > Please copy other people and share this post wherever is necessary > to keep this platform alive. Positive feedback will help things > rolling. > > Best Regards, > ___ > 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: General protection fault in `switch_mm_irqs_off()`
[CC: +affected coreboot folks, +coreboot mailing list]
Dear Thomas,
More affected people discussed this issue on the coreboot mailing list [1].
On 2019-01-14 18:37, Lendacky, Thomas wrote:
> On 1/14/19 11:09 AM, Paul Menzel wrote:
>> On 01/14/19 18:00, Lendacky, Thomas wrote:
>>> On 1/10/19 12:34 PM, Lendacky, Thomas wrote:
On 1/10/19 10:49 AM, Paul Menzel wrote:
> Dear Boris, dear Thomas,
>
>
> On 01/10/19 17:00, Borislav Petkov wrote:
>> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
>>> Thank you very much. Indeed, the machine does not crash. I used Linus’
>>> master branch for testing, and applied your patch on top. Please find
>>> the full log attached.
>>
>>> 80.649: [3.197107] Spectre V2 : spectre_v2_user_select_mitigation:
>>> set X86_FEATURE_USE_IBPB
>>
>> This is amazing.
>>
>> Ok, next diff, same exercise. Thx.>
>> ---
>> diff --git a/arch/x86/include/asm/nospec-branch.h
>> b/arch/x86/include/asm/nospec-branch.h
>> index dad12b767ba0..528ef8336f5f 100644
>> --- a/arch/x86/include/asm/nospec-branch.h
>> +++ b/arch/x86/include/asm/nospec-branch.h
>> @@ -284,6 +284,12 @@ static inline void
>> indirect_branch_prediction_barrier(void)
>> {
>> u64 val = PRED_CMD_IBPB;
>>
>> +if (WARN_ON(boot_cpu_has(X86_FEATURE_USE_IBPB))) {
>> +pr_info("%s: c: %px, array: 0x%x\n",
>> +__func__, _cpu_data,
>> boot_cpu_data.x86_capability[7]);
>> +return;
>> +}
>> +
>> alternative_msr_write(MSR_IA32_PRED_CMD, val,
>> X86_FEATURE_USE_IBPB);
>> }
>>
>> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
>> index 8654b8b0c848..e818e5abe611 100644
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -371,6 +371,9 @@ spectre_v2_user_select_mitigation(enum
>> spectre_v2_mitigation_cmd v2_cmd)
>> if (boot_cpu_has(X86_FEATURE_IBPB)) {
>> setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
>>
>> +pr_err("%s: set X86_FEATURE_USE_IBPB, c: %px, array:
>> 0x%x\n",
>> +__func__, _cpu_data,
>> boot_cpu_data.x86_capability[7]);
>> +
>> switch (cmd) {
>> case SPECTRE_V2_USER_CMD_FORCE:
>> case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index cb28e98a0659..8566737fa500 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -765,6 +765,9 @@ static void apply_forced_caps(struct cpuinfo_x86 *c)
>> c->x86_capability[i] &= ~cpu_caps_cleared[i];
>> c->x86_capability[i] |= cpu_caps_set[i];
>> }
>> +
>> +if (c == _cpu_data)
>> +pr_info("%s: c: %px, array: 0x%x\n", __func__, c,
>> c->x86_capability[7]);
>> }
>>
>> static void init_speculation_control(struct cpuinfo_x86 *c)
>> @@ -778,6 +781,10 @@ static void init_speculation_control(struct
>> cpuinfo_x86 *c)
>> if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) {
>> set_cpu_cap(c, X86_FEATURE_IBRS);
>> set_cpu_cap(c, X86_FEATURE_IBPB);
>> +
>> +pr_info("%s: X86_FEATURE_SPEC_CTRL: c: %px, array:
>> 0x%x, CPUID: 0x%x\n",
>> +__func__, c, c->x86_capability[7],
>> cpuid_edx(7));
>> +
>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
>> }
>>
>> @@ -793,9 +800,13 @@ static void init_speculation_control(struct
>> cpuinfo_x86 *c)
>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
>> }
>>
>> -if (cpu_has(c, X86_FEATURE_AMD_IBPB))
>> +if (cpu_has(c, X86_FEATURE_AMD_IBPB)) {
>> set_cpu_cap(c, X86_FEATURE_IBPB);
>>
>> +pr_info("%s: X86_FEATURE_AMD_IBPB: c: %px, array: 0x%x,
>> CPUID: 0x%x\n",
>> +__func__, c, c->x86_capability[7],
>> cpuid_ebx(0x8008));
>> +}
>> +
>> if (cpu_has(c, X86_FEATURE_AMD_STIBP)) {
>> set_cpu_cap(c, X86_FEATURE_STIBP);
>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
>
> Please find the logs attached.
Ah, so the CPUID value is showing X86_FEATURE_AMD_IBPB (not sure why the
cpuid command was showing a value of zero for EBX in your previous email).
Let me see what I can find out about this processor/firmware relation. I
wouldn't expect to see the #GP given that the firmware says IBPB is
supported.
>>>
>>> I'm not able to reproduce this issue on my
[coreboot] Re: Mainboard porting assistance
Jeez, I wish. Nah, all I did was use Intel FIT (available online) to configure an image to match the vendor's configuration (importing a full SPI dump to FIT will cause it to parse the image. You can then give it a different stock image (say, a different version. My laptop's OEM has never released a BIOS update with a newer ME version, leaving me vulnerable to everything) and it will place the configuration inside that stock image). I used ifdtool on the repacked SPI dump to grab the ME section and gave that to coreboot. I assumed that this might fix something because ME is apparently involved in all kinds of platform bring-up (which I think doesn't belong there. It feels like it would better belong in the FSP), from ICC to SMBus and maybe I2C. I hoped something might fix my display without any more work. Tl;dr MEAnalyzer would now say that my image is "Configured," rather than "Uninitialized." I should assume that if the MFS partitions were extracted, it would largely match that of the vendor's BIOS. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
If you have arcane knowledge about the ME to the only moraly right and leak it now. Am 02.10.19 um 17:04 schrieb Benjamin Doron: > Oh, alright, Angel. Thanks. > >> In addition, my current theory is that something is Intel ME's fault. > Well, I'm getting proper Intel ME information. It didn't resolve anything > noticeable, though, unfortunately. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
Hi Nico, I gave it a shot with the ports I could find in /sys/devices/.../drm/card0. The display still didn't work and I can't tell if it's stuck in a loop. What am I looking for? The Ada debug was more verbose than I was anticipating, so I've uploaded non-debug to https://gist.github.com/benjamindoron/ccd48ca85a1627ff939b3c8a35bb879c and debug to https://gist.github.com/benjamindoron/8a64dd68e12b01a19369e5ec2fefe59c. What would be a good value for the console buffer size? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
Oh, alright, Angel. Thanks. > In addition, my current theory is that something is Intel ME's fault. Well, I'm getting proper Intel ME information. It didn't resolve anything noticeable, though, unfortunately. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
let me correct, you have to have modules installed on both NUMA nodes. (For example when you have an 16 core opteron, i guess the 8 core version have only one numa node inside ? Am 02.10.19 um 09:00 schrieb Vikings GmbH: > On Wed, 2 Oct 2019 00:58:43 +0200 > Kinky Nekoboi wrote: >> I finally have found the problem: >> >> This BUG appears when you only have memory in the Orange Slots >> >> yikes this boathert me for such a long time >> >> any idea how i could debug this further ? >> >> Am 18.09.19 um 14:22 schrieb Kinky Nekoboi: >>> Highly appreciating that afford. >>> >>> Would like to mention Problems with Current Linux kernel with this >>> Board. >>> >>> ( The SLUB Allocator is causing panics at boot for my builds) >>> >>> Pls see: >>> >>> https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html > Not sure if that helps at all, but I'm getting reports that > > CONFIG_SLAB=y > CONFIG_SLAB_MERGE_DEFAULT=y > CONFIG_SLAB_FREELIST_RANDOM=y > > instead of > > CONFIG_SLUB=y > CONFIG_SLUB_CPU_PARTIAL=y > > "fixes" the issues. > Hi all, we see a lot of attention around KGPE-D16 maintainership problems. After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb decided to help in maintaining that platform by organizing crowd founding campaign or getting founds in other ways (direct sponsors). Since we are based in Poland there is chance that even with small contribution from community we would be able to cover the costs. Ideal plan would be to have structure similar to what we maintain for PC Engines: https://pcengines.github.io/ Where we providing signed and reproducible binaries every month and keep as close to mainline as possible. Of course if development will be active, then there always would be delta of patches held in review. Unfortunately we don't have hardware. During OSFC 2019 Stefan left one board, but it was too late (and probably too expensive) for us to organize any shipment to Poland. We looking to have 2 mainboards one for development and one in our automated regression testing environment. Of course we will start even with just one. If anyone is willing to help in founding, sponsoring hardware or by code development and testing we would be very grateful. Please copy other people and share this post wherever is necessary to keep this platform alive. Positive feedback will help things rolling. Best Regards, ___ > 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 > > signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
