Date: Wed, 24 Jan 2007 12:14:57 +0000 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: Jack Vogel <jfvogel@gmail.com> Cc: Bill Paul <wpaul@freebsd.org>, jon.otterholm@ide.resurscentrum.se, Gleb Smirnoff <glebius@freebsd.org>, freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Lenovo X60 em workaround Message-ID: <1169640897.59181.20.camel@buffy.york.ac.uk> In-Reply-To: <2a41acea0701221030x52dd8821pd858ae7e6740ce92@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel 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 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...
Just to add another datapoint - and for the archives - this also appears
to fix an issue with the Toshiba Tecra M5L. The "EEPROM Checksum Is Not
Valid" message would appear on boot if there was no link on the
interface, although the interface would appear to work fine from then
on. With this patch, the message no longer appears.
I also have problems with connections to networks (only seen when
connected to 10 meg half duplex hubs) with long delays on some packets
(which I'm assuming is the issue that started this thread) - I haven't
been able to verify yet that either patch fixes that, though.
Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1169640897.59181.20.camel>