Hello Paul,
mein Configuration is:
1x Opteron 6380
processor : 15
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD Opteron(tm) Processor 6380
and MEM:
root@lain:~# dmidecode -t 17
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x000B, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_C2
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 667 MT/s
Manufacturer: Samsung
Serial Number: 7926BB85
Asset Tag: Not Specified
Part Number: M393B1K70DH0-CH9
Rank: 2
Configured Memory Speed: 667 MT/s
Minimum Voltage: 1.5 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.5 V
Handle 0x000C, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_D2
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 667 MT/s
Manufacturer: Hynix/Hyundai
Serial Number: 393C405F
Asset Tag: Not Specified
Part Number: HMT31GR7BFR4C-H9
Rank: 2
Configured Memory Speed: 667 MT/s
Minimum Voltage: 1.5 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.5 V
I have currently an old microcode from 2016 (PreSpectre) included in
coreboot ROM
and update it via Kernel to 0x6000852.
I did not test the vendor firmware at all with this board.
Also my system does not start with the shipped debian kernel
(4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64)
with used CONFIG_SLUB=y)
protection fault... i wrote an other email about this.
Instead i selfbuild a vanila kernel 4.19.62 with CONFIG_SLAB=y
So my wild guess is that coreboot does not initlize the new OPCODES
coming with the new microcode in a correct way.
best regards
the nekoboi
Am 31.07.19 um 18:17 schrieb Paul Menzel:
Dear Kinky,
On 7/30/19 11:18 AM, Kinky Nekoboi wrote:
loading the microcode via Linux Kernel works.
including it via coreboot causes General Protection Faults.
See included bootlog.
We hit the same issue on our board, and reported it to the
Linux kernel
developers [1].
Unfortunately, we didn’t have more resources to pursue this further.
1. What is your configuration? How many processors, how much RAM?
2. So, loading it from GNU/Linux (initramfs) as Tom asked, seems to
work. I guess it’s the same with the vendor firmware?
3. As Tom tested it on a similar custom AMD board (with supposedly
microcode updates updated in the *vendor firmware*, and it worked
for him, there might be something wrong with how microcode updates
are applied in coreboot.
4. The user *sfs* in #coreboot(a)irc.freenode.net did not have the
problems if I remember correctly.
Anyway, somebody with time and motivation would need to debug this. But
it’d be great if you could check a few things and maybe chime in the
LKML discussion.
Kind regards,
Paul
[1]:
https://lkml.org/lkml/2019/1/3/540
"General protection fault in `switch_mm_irqs_off()`"
_______________________________________________
coreboot mailing list -- coreboot(a)coreboot.org
To unsubscribe send an email to coreboot-leave(a)coreboot.org