Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Dec 2020 08:21:28 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 248514] jedec_dimm(4) and imcsmb(4): support of memory controllers in Skylake and newer Intel CPUs
Message-ID:  <bug-248514-227-e2o00Mwb89@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-248514-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-248514-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248514

--- Comment #10 from Ravi Pokala <rpokala@panasas.com> ---
Sorry, this fell off my radar.

The problem here is that the iMC-SMBus controller was not really intended f=
or
use by the OS. During POST, the memory controller uses it to read the SPD
information from the DIMMs and configure itself to use their DRAM; during
normal operation, the system firmware (the Management Engine?) uses it to r=
ead
the TSOD temperature from the DIMMs. The hardware has a BUSY indicator, but=
 it
appears to be advisory, and it's possible that firmware does not honor it,
which could allow firmware-initiated operations to stomp on OS-initiated
operations.

And to top it off, I know Intel board firmware disabled OS access to the
iMC-SMBus controllers on *Well outright, as part of their security-hardening
fixes after Spectre-Meltdown; I suspect other board vendors followed suit. =
It's
possible that for *Lake, they disabled it from the start.

The upshot of all this, is that the controller might not be usable by the O=
S on
*Lake CPUs.

Try adding this line near the start of imcsmb_transfer():

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
        orig_cntl_val =3D pci_read_config(sc->imcsmb_pci,
            sc->regs->smb_cntl, 4);
+       device_printf(sc->dev, "cntl: 0x%08x\n", orig_cntl_val);
        cntl_val =3D orig_cntl_val;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I'm particularly interested in bit 26 (0x04000000), SMB_DIS_WRT; if it is s=
et,
the BIOS has locked the OS out from using the iMC-SMBus controller, and tha=
t's
game over. :-/

While I appreciate your offer of remote access, I don't have any time to dig
into this right now, and probably won't any time in the next few months.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248514-227-e2o00Mwb89>