Re: Lenovo X60 em workaround

On Mon, Jan 22, 2007 at 10:34:48AM -0800, Jack Vogel wrote:
> On 1/22/07, Jack Vogel <jfvogel_at_gmail.com> wrote:
> >On 1/22/07, Gleb Smirnoff <glebius_at_freebsd.org> wrote:
> >>   Jack,
> >>
> >> On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote:
> >> J> >> Since this was just seen, and the patch below validated as working 
> >I
> >> J> >wanted
> >> J> >> to send general email to capture this:
> >> J> >>
> >> J> >> The Lenovo X60 can have issues with long ping times, this is a 
> >KNOWN
> >> J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 
> >'fix' has
> >> J> >> not been decided on yet. Nevertheless, the patch below will work, 
> >but
> >> J> >> I do not want to check it in as its still temporary.
> >> J> >>
> >> J> >> Address questions to me,
> >> J> >
> >> J> >Okay, I have a question. Could you elaborate on just what the 
> >problem is?
> >> J> >(I mean, since it's KNOWN and all...) I'm just having a hard time 
> >figuring
> >> J> >out what problem could possibly be fixed by setting the RX interrupt
> >> J> >delay timer to a non-zero value (especially since elsewhere in the 
> >em(4)
> >> J> >source it says that doing so is a Bad Thing (tm)).
> >> J>
> >> J> saying its known to be a problem doesnt mean its cause is known :)
> >> J> They discovered that setting this eliminated the problem, but we
> >> J> immediately pointed out that this is, as you pointed out, a Bad
> >> J> Thing on other hardware, so the investigation continues, there is
> >> J> always a communication lag on these kind of things, so I dont know
> >> J> if it has been resolved yet or not.
> >> J>
> >> J> I just dont think this patch will become the final way to solve this,
> >> J> but we shall see :)
> >>
> >> Good to know that there is progress on this. Thanks! I will try the patch
> >> on my Lenovo T60 notebook, where the problem is also present. AFAIK, it
> >> is present on any Lenovo notebook with 82573 NIC.
> >>
> >> Can you please acknowledge that another bug with Lenovo + em(4) is 
> >known? I
> >> mean the problem, that em(4) isn't initialized properly on kernel boot, 
> >if
> >> the link is down. I have already reported this to you, and you said that
> >> I probably have bad hardware. Since that time, I've found several similar
> >> reports about Lenovo notebooks and em(4) driver in FreeBSD.
> >
> >Hey Gleb,
> >
> >Acknowledge... I can do better than that, I have a fix for this problem, 
> >and
> >its not temporary. Here is the code change (not a patch, I'm very busy),
> >its in hardware_init, should be obvious how to patch:
> >
> >       /* Make sure we have a good EEPROM before we read from it */
> >        if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
> >                /*
> >                ** Some PCI-E parts fail the first check due to
> >                ** the link being in sleep state, call it again,
> >                ** if it fails a second time its a real issue.
> >                */
> >                if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
> >                        device_printf(dev,
> >                            "The EEPROM Checksum Is Not Valid\n");
> >                        return (EIO);
> >                }
> >        }
> >
> >This is already checked into my code base at Intel, I've just been too
> >busy to do anything with it, be my guest if you wish to check it in after
> >testing...
> >
> >Cheers,
> >
> >Jack
> >
> 
> LOL, opps, I just realized, this code reflects the new shared code
> that I am in the process of releasing, in order for this to work in
> 6.2 change 'e1000_validate_nvm_checksum' to
> 'em_validate_eeprom_checksum' and all should be clear :)
> 
This worked for me.

(hoping it will get committed to -STABLE soonish)
-- 
Louis Kowolowski	KE7BAX			louisk_at_cryptomonkeys.com
Cryptomonkeys:                      http://www.cryptomonkeys.com/~louisk

Warning:  Do not point laser at remaining eye!