From: Auke Kok <auke-jan.h.kok@intel.com>
To: Molle Bestefich <molle.bestefich@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [bug] e100 bug: checksum mismatch on 82551ER rev10
Date: Mon, 10 Jul 2006 10:58:02 -0700 [thread overview]
Message-ID: <44B2952A.5030403@intel.com> (raw)
In-Reply-To: <62b0912f0607101041w69bd2a19t635a438f378e0e24@mail.gmail.com>
Molle Bestefich wrote:
> Auke Kok wrote:
>> > Every single IP130 I've had my hands on has had an EEPROM that the
>> > Linux driver declared bad.
>>
>> that means that whoever is selling you the IP130's is consistently
>> putting on
>> bad EEPROMs, which is *very* bad. Which vendor is that? They can fix this
>> problem for you and for *everyone* else they have sold and will sell
>> IP130's
>> to in the future.
>
> Nokia.
>
> Maybe they've changed the BABA magic, or the checksum logic entirely,
> to prevent other software than their own OS from running.
in almost all cases where a bad EEPROM checksum is found on a board the vendor
has changed settings in the EEPROM image without recalculating the checksum.
>> > I'm afraid that it's not the board that's at fault, it's the driver.
>>
>> No it is not. The NIC is supported (you can even call Intel for first
>> line
>> support) but if your vendor put a bad EEPROM image on it then all bets
>> are
>> off. Intel provides the vendors with the proper tools to make valid
>> EEPROMs,
>> the driver checks them for a very good reason.
>
> You're completely sure that the EEPROM check is correct for this
> particular revision of this particular chip?
It's valid for every piece of network silicon that has an EEPROM ever made.
> (Do you happen to know where the EEPROM is located, by the way?
it's in the NIC itself. In your case, where you have 3 separate chips, there
will be 3 different EEPROM images total.
>> How can you tell? Do you know if jumbo frames work correctly? Is the
>> device
>> properly checksumming? is flow control working properly? These and
>> many, many
>> more settings are determined by the EEPROM. Seemingly it may work
>> correctly,
>> but there is no guarantee whatsoever that it will work correctly at
>> all if the
>> checksum is bad. Again, you can lose data, or worse, you could
>> corrupt memory
>> in the system causing massive failure (DMA timings, etc). Unlikely?
>> sure, but
>> not impossible.
>
> They've been used in production environments for years.
all the more reason to suggest that Nokia is forgetting to update the checksums :)
Cheers,
Auke
next prev parent reply other threads:[~2006-07-10 18:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-09 11:34 [bug] e100 bug: checksum mismatch on 82551ER rev10 Molle Bestefich
2006-07-10 15:25 ` Auke Kok
2006-07-10 16:45 ` Molle Bestefich
2006-07-10 17:20 ` Auke Kok
2006-07-10 17:41 ` Molle Bestefich
2006-07-10 17:58 ` Auke Kok [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-07-31 21:07 Charlie Brady
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=44B2952A.5030403@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=molle.bestefich@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.