Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753899AbXJWVCU (ORCPT ); Tue, 23 Oct 2007 17:02:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752602AbXJWVCI (ORCPT ); Tue, 23 Oct 2007 17:02:08 -0400 Received: from mga11.intel.com ([192.55.52.93]:23862 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752439AbXJWVCG (ORCPT ); Tue, 23 Oct 2007 17:02:06 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.21,320,1188802800"; d="scan'208";a="183960151" Message-ID: <471E6121.9010008@intel.com> Date: Tue, 23 Oct 2007 14:01:21 -0700 From: "Kok, Auke" User-Agent: Thunderbird 2.0.0.6 (X11/20070911) MIME-Version: 1.0 To: Jeff Garzik CC: Adam Jackson , linux-kernel@vger.kernel.org, David Miller , netdev Subject: Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000. References: <11931515302013-git-send-email-ajax@redhat.com> <471E1ECD.80002@intel.com> <1193156487.26974.39.camel@localhost.localdomain> <471E2AD0.1000500@intel.com> <471E5C21.8030908@garzik.org> In-Reply-To: <471E5C21.8030908@garzik.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2883 Lines: 73 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 >>>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/