Re: Lenovo X60 em workaround
Hi Jack, On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: saying its known to be a problem doesnt mean its cause is known :) They discovered that setting this eliminated the problem, but we immediately pointed out that this is, as you pointed out, a Bad Thing on other hardware, so the investigation continues, there is always a communication lag on these kind of things, so I dont know if it has been resolved yet or not. I can confirm this patch solves the latency problem with em(4) on my IBM/Lenovo ThinkPad X60s. Any news about a proper solution to this issue? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpycVejfgBuZ.pgp Description: PGP signature
Re: Lenovo X60 em workaround
Hi,
On Mon, Jan 22, 2007 at 10:30:48AM -0800, Jack Vogel wrote:
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...
I can confirm that the above patch fixes the frequent initialization
problems with em(4) on my IBM/Lenovo ThinkPad X60s. Without the patch,
I often see the following on boot when there is no link on the em(4)
interface:
Apr 17 22:05:12 lothlorien kernel: em0: The EEPROM Checksum Is Not Valid
Apr 17 22:05:12 lothlorien kernel: em0: Unable to initialize the hardware
With the patch, I can not reproduce the invalid checksum errors - the
second call to e1000_validate_nvm_checksum() succeeds.
Any chance of this patch hitting CURRENT anytime soon? :)
Regards,
Brix
--
Henrik Brix Andersen [EMAIL PROTECTED]
pgp4LeHzR3WOj.pgp
Description: PGP signature
Re: Lenovo X60 em workaround
On 4/17/07, Henrik Brix Andersen [EMAIL PROTECTED] wrote:
Hi,
On Mon, Jan 22, 2007 at 10:30:48AM -0800, Jack Vogel wrote:
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...
I can confirm that the above patch fixes the frequent initialization
problems with em(4) on my IBM/Lenovo ThinkPad X60s. Without the patch,
I often see the following on boot when there is no link on the em(4)
interface:
Apr 17 22:05:12 lothlorien kernel: em0: The EEPROM Checksum Is Not Valid
Apr 17 22:05:12 lothlorien kernel: em0: Unable to initialize the hardware
With the patch, I can not reproduce the invalid checksum errors - the
second call to e1000_validate_nvm_checksum() succeeds.
Any chance of this patch hitting CURRENT anytime soon? :)
Yes, the reason I have been delaying is that I need to merge the
latest driver I've released from Intel into CURRENT, and this is going
to be a sizeable task, we have a new shared code base that is more
modular than before, it means each family of NIC now gets a seperate
file and functions, with function pointers that are set up at runtime.
All new drivers, Windows, Linux, and FreeBSD are using this code,
its going to be a bit of work to make sure that CURRENT loses no
fixes in this merge, I also had another project internally that needed
my cycles, but starting tomorrow I will begin the task, I would hope
to get something checked in by the weekend.
Anyone that wishes to see the new driver structure can download
it now from the Intel site, downloadfinder.intel.com, its driver version
6.3.9.
Cheers,
Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On 1/23/07, Jack Vogel [EMAIL PROTECTED] wrote:
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...
I accidentally found this :
http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovolndocid=MIGR-67166
which patches the eeprom. And it solves by problem.
Regards,
Rong-En Fan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel wrote:
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] 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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On 1/24/07, Gavin Atkinson [EMAIL PROTECTED] wrote:
On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel wrote:
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] 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.
Nice to know its fixing more than expected.
Let me know about the last issue when you verify it.
Crises have me consumed at work right now, will try to get time to
commit by this weekend.
Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On Mon, Jan 22, 2007 at 10:34:48AM -0800, Jack Vogel wrote:
On 1/22/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] 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 KowolowskiKE7BAX [EMAIL PROTECTED]
Cryptomonkeys: http://www.cryptomonkeys.com/~louisk
Warning: Do not point laser at remaining eye!
pgpZryTGMMOyC.pgp
Description: PGP signature
Re: Lenovo X60 em workaround
On 1/23/07, Louis Kowolowski [EMAIL PROTECTED] wrote:
On Mon, Jan 22, 2007 at 10:34:48AM -0800, Jack Vogel wrote:
On 1/22/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] 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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
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. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] 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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On 1/22/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] 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 :)
Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On 1/19/07, Bill Paul [EMAIL PROTECTED] wrote: Since this was just seen, and the patch below validated as working I wanted to send general email to capture this: The Lenovo X60 can have issues with long ping times, this is a KNOWN hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has not been decided on yet. Nevertheless, the patch below will work, but I do not want to check it in as its still temporary. Address questions to me, Okay, I have a question. Could you elaborate on just what the problem is? (I mean, since it's KNOWN and all...) I'm just having a hard time figuring out what problem could possibly be fixed by setting the RX interrupt delay timer to a non-zero value (especially since elsewhere in the em(4) source it says that doing so is a Bad Thing (tm)). saying its known to be a problem doesnt mean its cause is known :) They discovered that setting this eliminated the problem, but we immediately pointed out that this is, as you pointed out, a Bad Thing on other hardware, so the investigation continues, there is always a communication lag on these kind of things, so I dont know if it has been resolved yet or not. I just dont think this patch will become the final way to solve this, but we shall see :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
Since this was just seen, and the patch below validated as working I wanted to send general email to capture this: The Lenovo X60 can have issues with long ping times, this is a KNOWN hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has not been decided on yet. Nevertheless, the patch below will work, but I do not want to check it in as its still temporary. Address questions to me, Okay, I have a question. Could you elaborate on just what the problem is? (I mean, since it's KNOWN and all...) I'm just having a hard time figuring out what problem could possibly be fixed by setting the RX interrupt delay timer to a non-zero value (especially since elsewhere in the em(4) source it says that doing so is a Bad Thing (tm)). -Bill Jack PS This is based on 6.2, but is needed for CURRENT as well. --- if_em.dist.cWed Jan 17 17:59:46 2007 +++ if_em.c Wed Jan 17 18:03:13 2007 @@ -3348,6 +3348,10 @@ E1000_WRITE_REG(adapter-hw, RXCSUM, reg_rxcsum); } + /* TEMPORARY WORKAROUND for X60 */ + if (adapter-hw.mac_type == em_82573) + E1000_WRITE_REG(adapter-hw, RDTR, 32); + /* Enable Receives */ E1000_WRITE_REG(adapter-hw, RCTL, reg_rctl); /* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Lenovo X60 em workaround
Since this was just seen, and the patch below validated as working I wanted to send general email to capture this: The Lenovo X60 can have issues with long ping times, this is a KNOWN hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has not been decided on yet. Nevertheless, the patch below will work, but I do not want to check it in as its still temporary. Address questions to me, Jack PS This is based on 6.2, but is needed for CURRENT as well. --- if_em.dist.cWed Jan 17 17:59:46 2007 +++ if_em.c Wed Jan 17 18:03:13 2007 @@ -3348,6 +3348,10 @@ E1000_WRITE_REG(adapter-hw, RXCSUM, reg_rxcsum); } + /* TEMPORARY WORKAROUND for X60 */ + if (adapter-hw.mac_type == em_82573) + E1000_WRITE_REG(adapter-hw, RDTR, 32); + /* Enable Receives */ E1000_WRITE_REG(adapter-hw, RCTL, reg_rctl); /* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
