linux-kernel - Re: e1000: "eeprom checksum is not valid" after kexec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200904231715.44918.rjw@sisk.pl>
Date:	Thu, 23 Apr 2009 17:15:44 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	e1000-devel@...ts.sourceforge.net,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: e1000: "eeprom checksum is not valid" after kexec

On Thursday 23 April 2009, Jiri Slaby wrote:
> Hi,

Hi,

> 4a865905f685eaefaedf6ade362323dc52aa703b
> (PCI PM: Make pci_set_power_state() handle devices with no PM support)
> breaks e1000 after being kexec'ed. These reverts fix the problem:
>     Revert "PCI PM: Make pci_set_power_state() handle devices with no PM
> support"
>     Revert "PCI PM: Introduce __pci_[start|complete]_power_transition()
> (rev. 2)"
> 
> I reverted the second one

I don't think it can be reverted.

> just for an easy revert of the former one, which is actually the culprit.

Can you just try to revert the changes in pci_raw_set_power_state() and check
if that has any effect (it shouldn't)?

> The symptoms:
> e1000 0000:02:01.0: enabling device (0000 -> 0003)
> e1000 0000:02:01.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
> e1000 0000:02:01.0: setting latency timer to 64
> e1000: 0000:02:01.0: e1000_probe: The EEPROM Checksum Is Not Valid
> Switched to high resolution mode on CPU 0
> /*********************/
> Current EEPROM Checksum : 0xffff
> Calculated              : 0xbaf9
> Offset    Values
> ========  ======
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Include this output when contacting your support provider.
> This is not a software error! Something bad happened to your hardware or
> EEPROM image. Ignoring this problem could result in further problems,
> possibly loss of data, corruption or system hangs!
> The MAC Address will be reset to 00:00:00:00:00:00, which is invalid
> and requires you to set the proper MAC address manually before continuing
> to enable this network device.
> Please inspect the EEPROM dump and report the issue to your hardware vendor
> or Intel Customer Support.
> /*********************/
> e1000: 0000:02:01.0: e1000_probe: Invalid MAC Address
> e1000: 0000:02:01.0: e1000_probe: (PCI-X:33MHz:64-bit) 00:00:00:00:00:00

So this is after kexec?

What happens if you remove just the

	/* Check if we're already there */
	if (dev->current_state == state)
		return 0;

part from pci_set_power_state()?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/