From: Auke Kok <auke-jan.h.kok@intel.com>
To: John <me@privacy.net>
Cc: Auke Kok <auke-jan.h.kok@intel.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
hpa@zytor.com, saw@saw.sw.com.sg
Subject: Re: Intel 82559 NIC corrupted EEPROM
Date: Thu, 09 Nov 2006 09:03:34 -0800 [thread overview]
Message-ID: <45535F66.8010803@intel.com> (raw)
In-Reply-To: <45531C42.3070503@privacy.net>
John wrote:
> Auke Kok wrote:
>
>> This is what I was afraid of: even though the code allows you to
>> bypass the EEPROM checksum, the probe fails on a further check to see
>> if the MAC address is valid.
>>
>> Since something with this NIC specifically made the EEPROM return all
>> 0xff's, the MAC address is automatically invalid, and thus probe fails.
>
> I don't understand why you think there is something wrong with a
> specific NIC?
that was completely not my point - I was merely trying to point out that the original
problem causes a cascade of error events later on, and bypassing the eeprom check in
this case didn't help you at all. Something is wrong in the driver, but I don't
understand yet why it only affects one of the 3 nics in your system.
> In 2.6.14.7, e100.ko fails to read the EEPROM on 0000:00:08.0 (eth0)
> In 2.6.18.1, e100.ko fails to read the EEPROM on 0000:00:09.0 (eth1)
almost sounds like a bug got fixed and it introduced a regression. this wouldn't be the
right time to pull out git-bisect would it? even loading 2.6.15, 2.6.16, 2.6.17 on it
would give us some good information.
Cheers,
Auke
next prev parent reply other threads:[~2006-11-09 17:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <454B7C3A.3000308@privacy.net>
[not found] ` <454BF0F1.5050700@zytor.com>
[not found] ` <45506C9A.5010009@privacy.net>
2006-11-08 10:55 ` Intel 82559 NIC corrupted EEPROM John
2006-11-08 16:17 ` Auke Kok
2006-11-09 12:17 ` John
2006-11-09 17:03 ` Auke Kok [this message]
2006-11-08 17:26 ` Jesse Brandeburg
2006-11-09 14:15 ` John
2006-11-10 0:19 ` Jesse Brandeburg
2006-11-10 12:03 ` John
2006-11-15 8:34 ` John
2006-11-27 14:17 ` John
2006-11-27 20:34 ` Jesse Brandeburg
2006-11-29 11:26 ` John
2006-11-29 18:55 ` Jesse Brandeburg
[not found] ` <45704001.9040108@privacy.net>
2006-12-04 23:26 ` Jesse Brandeburg
[not found] <fa.FcMVUlqOXU3cAnxsPEN6d8T0wxU@ifi.uio.no>
[not found] ` <fa.0FC8eT8GQaLxmNQTrsqyNFjRK4E@ifi.uio.no>
[not found] ` <fa.nds0CFkNbotWh4VNM05EixY68wE@ifi.uio.no>
[not found] ` <fa.K3Gpuu7oYQv+4q85Ziy3ljV6u+E@ifi.uio.no>
[not found] ` <fa./RNOPU0DwWMrnKJSqlMaY+Y16JM@ifi.uio.no>
[not found] ` <fa.yV32AYzot0OkvPVCY7VTCvd6rJw@ifi.uio.no>
2007-02-07 11:06 ` John
2007-02-13 19:45 ` Brandeburg, Jesse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45535F66.8010803@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@privacy.net \
--cc=netdev@vger.kernel.org \
--cc=saw@saw.sw.com.sg \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).