netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Auke Kok <auke-jan.h.kok@intel.com>
To: Charlie Brady <charlieb@budge.apana.org.au>
Cc: NetDev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	molle.bestefich@gmail.com
Subject: Re: [bug] e100: checksum mismatch on 82551ER rev10
Date: Wed, 02 Aug 2006 09:50:18 -0700	[thread overview]
Message-ID: <44D0D7CA.2060001@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0607311653360.24450@e-smith.charlieb.ott.istop.com>

[cc-ing netdev]
[adding original thread authors back, please do not strip CC]

Charlie Brady wrote:
>> Molle Bestefich wrote:
>>> The NICs are working perfectly.
>> 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.
> 
> Let's assume that these things are all true, and the NIC currently does 
> not work perfectly, just imperfectly, but acceptably. With the recent 
> driver change, it now does not work at all. That's surely a bug in the 
> driver.

There is no logic in that sentence at all. You're saying that the driver is 
broken because it doesn't fix an error in the EEPROM?

We're trying extremely hard to fix real errors here (especially when we find 
that hardware resellers send out hardware with EEPROM problems) and you are 
asking for a workaround that will (likely) introduce random errors and failure 
into your kernel. I do not want to accept responsability for that and I also 
do not think any other kernel developer would like me to release such a risk 
into the kernel. I'd probably get whistled back instantly :)

If you want to edit your own kernel then I am fine with it. If you want to 
recalculate the checksum yourself and put it in the EEPROM then I am also fine 
with that. As long as you never ask for support for that NIC. But we can't 
support an option that allows all users to willingly enable a piece of 
non-properly-working hardware. Because that is what it is: Not properly 
configured hardware.

The bottom line is that your problem is that a specific hardware vendor is/was 
selling badly configured hardware, and you buy it from them, even after it's 
End Of Lifed for that vendor. Even though that vendor did buy the units 
properly configured and had all the tools needed to configure them properly. I 
can maybe fix your problem by seeing if we can get you an eeprom update, but I 
can not break everyone elses kernel for that.

Auke




       reply	other threads:[~2006-08-02 16:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.61.0607311653360.24450@e-smith.charlieb.ott.istop.com>
2006-08-02 16:50 ` Auke Kok [this message]
2006-08-02 17:45   ` [bug] e100: checksum mismatch on 82551ER rev10 Charlie Brady
2006-08-02 18:30     ` Auke Kok
2006-08-04 11:04   ` Molle Bestefich
2006-08-04 11:20     ` David Miller
2006-08-04 11:28       ` David Miller
2006-08-05 13:28         ` Molle Bestefich
2006-08-05 17:21         ` Jason Lunz

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=44D0D7CA.2060001@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=charlieb@budge.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=molle.bestefich@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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).