*> [ 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.hu...@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 > >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot