Re: Lenovo X60 em workaround

On 1/23/07, Louis Kowolowski <louisk_at_cryptomonkeys.com> wrote:
> 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)

OK, hint taken, I'll try and get that committed asap.

Jack