netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Auke Kok <auke-jan.h.kok@intel.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Auke Kok <auke-jan.h.kok@intel.com>,
	cramerj@intel.com, john.ronciak@intel.com,
	jesse.brandeburg@intel.com, jeffrey.t.kirsher@intel.com,
	kernel list <linux-kernel@vger.kernel.org>,
	NetDev <netdev@vger.kernel.org>
Subject: Re: e1000: "fix" it on thinkpad x60 / eeprom checksum read fails
Date: Thu, 20 Jul 2006 10:34:23 -0700	[thread overview]
Message-ID: <44BFBE9F.7070600@intel.com> (raw)
In-Reply-To: <20060720170758.GA9938@atrey.karlin.mff.cuni.cz>

Pavel Machek wrote:
> Hi!
> 
>>> e1000 in thinkpad x60 fails without this dirty hack. What to do with
>>> it?
>>>
>>> Signed-off-by: Pavel Machek <pavel@suse.cz>
>> NAK, certainly this should never be merged in any tree...
>>
>> this is a known issue that we're tracking here:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1474679&group_id=42302&atid=447449
>>
>> Summary of the issue:
>>
>> Lenovo has used certain BIOS versions where ASPD/DSPD was turned on which 
>> turns the PHY off when no cable is inserted to save power. The e1000 driver 
>> already turns off this feature but can't do this until the driver is 
>> loaded. It seems that turning this feature on causes the MAC to give read 
>> errors.
>>
>> Lenovo seems to have the feature turned off in their latest BIOS versions, 
>> we encourage all people to upgrade their BIOS with the latest version from 
>> Lenovo (available from their website). It seems that for at least 2 people, 
>> this has fixed the problem.
>>
>> Inserting a cable obviously might also work :)
> 
> Hehe.
> 
>> We did reproduce the problem initially with the old BIOS (1.01-1.03) on a 
>> T60 system, but unfortunately the bug disappeared into nothingness.
>>
>> Bypassing the checksum leaves the NIC in an uncertain state and is not 
>> recommended.
> 
> Okay, perhaps this should be inserted as a comment into the driver,
> and printk should be fixed to point at this explanation?
> 
> Can't we enable the driver with the bad checksum, then read the _real_
> data?

no.

We're working on a solution where we make sure that the PHY is physically 
turned on properly before we read the EEPROM, which would be the proper fix. 
It's completely not acceptable to run when the EEPROM checksum fails - you 
might even be running with the wrong MAC address, or worse. Lets fix this the 
right way instead.

Auke

PS: adding netdev to the CC...

       reply	other threads:[~2006-07-20 17:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060721005832.GA1889@elf.ucw.cz>
     [not found] ` <44BFADA6.6090909@intel.com>
     [not found]   ` <20060720170758.GA9938@atrey.karlin.mff.cuni.cz>
2006-07-20 17:34     ` Auke Kok [this message]
2006-07-21 13:41       ` e1000: "fix" it on thinkpad x60 / eeprom checksum read fails Andrew Morton
2006-07-21 15:12         ` Theodore Tso
2006-07-21 15:22           ` Auke Kok
2006-07-22  0:21             ` Andrew Morton

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=44BFBE9F.7070600@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=cramerj@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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).