Re: [coreboot] Broadwell-DE hang in coreboot: mp_init.c

[Jay Talbott]

I've seen this as well on a 12-core Broadwell-DE. I got a few breadcrumbs from a colleague at Intel suggesting that it was some sort of race condition with the ME that I now am questioning and thinking really just steered us off course of finding the actual root cause of the problem since the changes we tried to make along that train of thinking didn't help at all. So after stumbling onto this discussion from February, I'm interested in any new ideas...

So, other than the change below, which impacts all platforms, not just Broadwell-DE, has anybody come up with a better fix to this problem, or an understanding of why it only impacts Broadwell-DE, and yet isn't a problem on the Intel Camelback Mountain reference board? Since it's not reproducible on the Intel reference board, we can't get much support out of Intel on this one...

Thanks,

- Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3057 E. Muirfield St.
Gilbert, AZ 85298
[phone]
[phone] (FAX)
[e-mail]
http://www.sysproconsulting.com
> -----Original Message-----
> From: coreboot [mailto:[e-mail]] On Behalf Of Zeh,
> Werner
> Sent: Monday, February 26, 2018 11:12 PM
> To: [e-mail]
> Cc: mark pleso
> Subject: Re: [coreboot] Broadwell-DE hang in coreboot: mp_init.c
>
> Hi Mark.
>
> I saw a very similar issue (similar because I have not analyzed it in detail due
> to missing time) with a 6 core Broadwell-DE. It hangs as well in SMM
> relocation.
> Same mainboard and coreboot binary with a 4 core Broadwell-DE does not
> have this effect.
>
> Werner
> > Von: coreboot [mailto:[e-mail]] Im Auftrag von
>
> mark pleso via coreboot
> > Gesendet: Montag, 26. Februar 2018 23:40
> > An: [e-mail]
> > Betreff: [coreboot] Broadwell-DE hang in coreboot: mp_init.c
> >
> > Has anyone else seen a hang during coreboot booting on a Broadwell-
>
> DE?  The issue appears to be in mp_init.c, in the function
> smm_do_relocation().  This is coreboot 4.7, but I think the issue exists in 4.6
> > as well.
> >
> > Enabling the printk will stop the hang. Or, just adding a wbinvd() instruction
>
> will stop the hang, and things proceed normally.  Code is below.
> > Any help would be appreciated.
> >
> > btw - This not a commercial motherboard.
> >
> > coreboot/src/cpu/x86/mp_init.c
> > static void asmlinkage smm_do_relocation(void *arg)
> > {
> >        const struct smm_module_params *p;
> >       const struct smm_runtime *runtime;
> >      int cpu;
> >        uintptr_t curr_smbase;
> >        uintptr_t perm_smbase;
> >    p = arg;
> >    runtime = p->runtime;
> >    cpu = p->cpu;
> >    curr_smbase = runtime->smbase;
> >
> >    if (cpu >= CONFIG_MAX_CPUS) {
> >            printk(BIOS_CRIT,
> >                   "Invalid CPU number assigned in SMM stub: %d\n", cpu);
> >            return;
> >    }
> >
> >    /*
> >     * The permanent handler runs with all cpus concurrently. Precalculate
> >     * the location of the new SMBASE. If using SMM modules then this
> >     * calculation needs to match that of the module loader.
> >     */
> >    perm_smbase = mp_state.perm_smbase;
> >    perm_smbase -= cpu * runtime->save_state_size;
> >
> >    printk(BIOS_DEBUG, "New SMBASE 0x%08lx\n", perm_smbase);
> >
> >    /* write cache to DRAM before calling relocation handler */ /* will stop
>
> hang */
> >    wbinvd();  /* <<=== OR NEW INSTRUCTION w/o printk STOPS HANG */
> >
> >    /* Setup code checks this callback for validity. */
> >    mp_state.ops.relocation_handler(cpu, curr_smbase, perm_smbase);
> >
> > }