linux-kernel - Re: Intel 82559 NIC corrupted EEPROM

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: <4807377b0611080926x21bd6326xc5e7683100d20948@mail.gmail.com>
Date:	Wed, 8 Nov 2006 09:26:56 -0800
From:	"Jesse Brandeburg" <jesse.brandeburg@...il.com>
To:	John <me@...vacy.net>
Cc:	auke-jan.h.kok@...el.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, hpa@...or.com, saw@....sw.com.sg
Subject: Re: Intel 82559 NIC corrupted EEPROM

On 11/8/06, John <me@...vacy.net> wrote:
> Hello all,
>
> [ E-mail address is a bit-bucket. I *do* monitor the mailing lists. ]
>
> I will try and summarize the problem as I understand it at this point.
>
> I've written two messages so far:
> http://groups.google.com/group/linux.kernel/msg/3a05d819c66474db
> http://groups.google.com/group/linux.kernel/msg/391aebbb3dfd6039
>
> And here is a link to the complete thread:
> http://lkml.org/lkml/fancy/2006/11/3/124
>
> I have a motherboard with three on-board 82559 NICs.
>
>   o eepro100.ko properly initializes all three NICs
>   o e100.ko fails to initialize one of them
>
> NOTE: With kernel 2.6.14, e100.ko fails to initialize the NIC with MAC
> address 00:30:64:04:E6:E4. With kernel 2.6.18 e100.ko fails to
> initialize the NIC with MAC address 00:30:64:04:E6:E5.
>
> The problem is not an incorrect checksum. (Donald Becker's dump utility
> reports a correct checksum for all three NICs.) The problem seems to be
> that e100.ko fails to read the contents of one of the EEPROMs.

<snip>

Thanks for the report, I have some thoughts.
I suspect that one reason beckers code works is that it uses IO based
access (slower, and different method) to the adapter rather than
memory mapped access.

The second thought is that the adapter is in D3, and something about
your kernel or the driver doesn't successfully wake it up to D0.  An
indication of this would be looking at lspci -vv before/after loading
the driver.  Also, after loading/unloading eepro100 does the e100
driver work?

A third idea is look for a master abort in lspci after e100 fails to load.

And a last idea is for us to instrument the reads /writes from/to the
device during init and see if everything is returning 0xffffffff, as
that indicates the I/O and/or memory bar is not enabled, or the
address returned from ioremap is invalid.

Jesse
-
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/