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 #[email protected] 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 -- [email protected] > To unsubscribe send an email to [email protected]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
