netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Adam Jackson <ajax@redhat.com>,
	linux-kernel@vger.kernel.org, David Miller <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
Date: Tue, 23 Oct 2007 14:01:21 -0700	[thread overview]
Message-ID: <471E6121.9010008@intel.com> (raw)
In-Reply-To: <471E5C21.8030908@garzik.org>

Jeff Garzik wrote:
> Kok, Auke wrote:
>> Adam Jackson wrote:
>>> On Tue, 2007-10-23 at 09:18 -0700, Kok, Auke wrote:
>>>> Adam Jackson wrote:
>>>>> When the EEPROM gets corrupted, you can fix it with ethtool, but
>>>>> only if
>>>>> the module loads and creates a network device.  But, without this
>>>>> option,
>>>>> if the EEPROM is corrupted, the driver will not create a network
>>>>> device.
>>>>>
>>>>> Signed-off-by: Adam Jackson <ajax@redhat.com>
>>>> NAK
>>>>
>>>> wrong list, not sent to me, and while for e100 I was OK with this
>>>> patch, for e1000
>>>> it really does not make sense to 'just allow' a bad checksum - if
>>>> your eeprom is
>>>> randomly messed up then you cannot just fix it like this anyway.
>>> That's strange, I managed to recover an otherwise horked e1000 with it.
>>> What should I have done instead?
>>
>>
>> Dump the eeprom and send us a copy, plus any and all information to
>> the card,
>> system etc.. I realize that you need the patch to actually create it
>> but the
>> danger is that people will start using it *without* troubleshooting
>> the real
>> issue. In various systems the eeprom checksum failure is actually due
>> to a
>> misconfigured powersavings feature and the checksum is really not bad
>> at all, but
>> the card just reports random values.
>>
>> In any case, this patch should not be merged. We often send it around
>> to users to
>> debug their issue in case it involves eeproms, but merging it will
>> just conceal
>> the real issue and all of a sudden a flood of people stop reporting
>> *real* issues
>> to us.
> 
> 
> Sorry, I disagree.  Just as with e100, if there is a clear way the user
> can recover their setup -- and Adam says his was effective -- I don't
> see why we should be denying users the ability to use their own hardware.


That's not even relevant, I already offer the same patch offline to people who
*really* only have a wrong checksum, AFTER we check the contents of their eeprom
for them.

We help everyone out, and if you merge this patch you will prevent users from
getting to us for support in the first place.

I realize that we should probably document the "bad eeprom checksum" case more
decently but I think merging this patch is a bad idea for the *user* in all cases.

You completely bypass the fact that e100 eeproms and e1000 eeproms are completely
different beasts as well, one can be practically empty in all cases (e100), the
other one every bit counts (most e1000's), which is an unfair representation and
falsely tells the user that he can just do this without any information or
disclaimer as to what he may expect afterwards.


Auke

  reply	other threads:[~2007-10-23 21:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <11931515302013-git-send-email-ajax@redhat.com>
     [not found] ` <471E1ECD.80002@intel.com>
     [not found]   ` <1193156487.26974.39.camel@localhost.localdomain>
     [not found]     ` <471E2AD0.1000500@intel.com>
2007-10-23 20:40       ` [PATCH] Add eeprom_bad_csum_allow module option to e1000 Jeff Garzik
2007-10-23 21:01         ` Kok, Auke [this message]
2007-10-23 21:51           ` David Miller
2007-10-23 21:20         ` Dave Jones
2007-10-23 21:38           ` Alan Cox
2007-10-23 21:53           ` David Miller
2007-10-23 23:19             ` Kok, Auke
2007-10-24  0:55             ` [PATCH] e1000, e1000e valid-addr fixes Jeff Garzik
2007-10-24  1:03               ` Jeff Garzik
2007-10-24  1:07                 ` David Miller
2007-10-24  2:20                   ` Jeff Garzik
2007-10-24  2:23                     ` David Miller
2007-11-01 18:04                       ` Kok, Auke
2007-11-01 18:47                         ` Jeff Garzik
2007-11-01 18:11                     ` Stephen Hemminger
2007-11-01 19:31                       ` Jeff Garzik
2007-10-24  1:15               ` Adrian Bunk
2007-10-23 23:03           ` [PATCH] Add eeprom_bad_csum_allow module option to e1000 Kok, Auke
2007-10-23 23:53             ` Stephen Hemminger
2007-10-24  5:38             ` Dave Jones
2007-10-23 21:48         ` David Miller

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=471E6121.9010008@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=ajax@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).