*> [ 1.611526] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid*
I admit, I missed this one... But I'll improve, since, according to my expectations, my mind "blacklisted" possibility that GbE descriptor is corrupted. I am more on Linux/kernel side, and every day I read somebody's dmesg, which come out of/based upon completely healthy BIOS. Coreboot as BSP asset for ASUS, GIGABYTE and such vendors, in mobile, WS, DT and Servers is not almost at all present?! :-(
Anyway, good catch, I'll add this one to my (growing) rich understanding of dmesg logs! :-)
Thank you, Zoran
On Mon, Mar 27, 2017 at 4:33 PM, Nico Huber nico.huber@secunet.com wrote:
Hello Serdar, Zoran,
On 27.03.2017 16:14, Zoran Stojsavljevic wrote:
[user@localhost projects]$ cat dmesg.txt | grep 00:19.0 [ 0.151652] pci 0000:00:19.0: *[8086:294c*] type 00 class 0x020000 [ 0.151694] pci 0000:00:19.0: reg 0x10: [mem 0xe1600000-0xe161ffff] [ 0.151707] pci 0000:00:19.0: reg 0x14: [mem 0xe1624000-0xe1624fff] [ 0.151721] pci 0000:00:19.0: reg 0x18: [io 0x3000-0x301f] [ 0.151802] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 1.489719] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 1.611526] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid
I can't say for sure, but this looks much like the GbE and/or Firmware Descriptor regions of the BIOS flash are corrupted. If in doubt, you can generate a layout file for flashrom from the backup of the vendor BIOS with `ifdtool -f` (see util/ifdtool/ in the coreboot tree). And flash back these selected regions with `flashrom -l layoutfile -i fd -i gbe ...` from the backup.
*[ 1.635873] e1000e: probe of 0000:00:19.0 failed with error -5* [user@localhost projects]$
Hope that helps, Nico