Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Jan 2007 15:50:05 -0800
From:      Louis Kowolowski <louisk@cryptomonkeys.com>
To:        Jack Vogel <jfvogel@gmail.com>
Cc:        freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: Lenovo X60 em workaround
Message-ID:  <20070123235004.GF1504@cryptomonkeys.com>
In-Reply-To: <2a41acea0701221034j42fed2a9g3934ef187e3964ca@mail.gmail.com>
References:  <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> <20070122083506.GW4485@FreeBSD.org> <2a41acea0701221030x52dd8821pd858ae7e6740ce92@mail.gmail.com> <2a41acea0701221034j42fed2a9g3934ef187e3964ca@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--1Ow488MNN9B9o/ov
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 22, 2007 at 10:34:48AM -0800, Jack Vogel wrote:
> On 1/22/07, Jack Vogel <jfvogel@gmail.com> wrote:
> >On 1/22/07, Gleb Smirnoff <glebius@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 worki=
ng=20
> >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=
=20
> >KNOWN
> >> J> >> hardware problem, and Intel is working with IBM/Lenovo, a final=
=20
> >'fix' has
> >> J> >> not been decided on yet. Nevertheless, the patch below will work=
,=20
> >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=20
> >problem is?
> >> J> >(I mean, since it's KNOWN and all...) I'm just having a hard time=
=20
> >figuring
> >> J> >out what problem could possibly be fixed by setting the RX interru=
pt
> >> J> >delay timer to a non-zero value (especially since elsewhere in the=
=20
> >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 thi=
s,
> >> J> but we shall see :)
> >>
> >> Good to know that there is progress on this. Thanks! I will try the pa=
tch
> >> 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=20
> >known? I
> >> mean the problem, that em(4) isn't initialized properly on kernel boot=
,=20
> >if
> >> the link is down. I have already reported this to you, and you said th=
at
> >> I probably have bad hardware. Since that time, I've found several simi=
lar
> >> 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,=
=20
> >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
> >
>=20
> 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 :)
>=20
This worked for me.

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

Warning:  Do not point laser at remaining eye!

--1Ow488MNN9B9o/ov
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFFtp8sZk0r6oAkN7YRAt81AJ0aIkaFqp8wVDq2xEMeSR9jyjT66QCfXXoC
4+nUzLdBURjLtxuCOD1FEkM=
=voHN
-----END PGP SIGNATURE-----

--1Ow488MNN9B9o/ov--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070123235004.GF1504>