Re: e1000 driver problems
Hello, the problem seems to be gone in 2.6.24-rc kernels. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
On Mon, Dec 03, 2007 at 07:20:48AM -0800, Kok, Auke wrote: can you open up a ticket on e1000.sf.net and fill in a full bugreport including output of all of these? : - ethttool -i eth0 - ethtool -e eth0 - lspci -vv - full dmesg (not just the driver parts) - dmidecode - cat /proc/interrupts I'd like to see if maybe we can reproduce this in our lab. I'll try but it may take some time. Meanwhile, I found that hung card transmits but does not receive anything including ARP. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
Another problem at my own machine. If I force speed to 100Mb on 1GE network, I can reach 95Mbps bidirectional using UDP (0.34% loses) but only 1.2Mbps using TCP. A bug? If I enable autonegotiation and run at 1GE, I can got 95Mb on TCP to the target machine (the target machine has only 100Mb connection). -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
This is probably not an e1000 problem, but a general Ethernet feature. If you defeat auto-negotiation to force the data rate, you implicitly defeat duplex negotiation as well. You need to explicitly set the duplex mode. In full duplex mode, send and receive are are fully independent, and packets can flow concurrently in both directions. In half duplex mode the receiver assumes it is hearing its own transmission, and ignores (or errors) frames that are partially overlapped by it's own transmission. See for example: S. Shalunov and R. Carlson. Detecting Duplex Mismatch on Ethernet http://www.springerlink.com/content/vapet12x584e6wyn/ Best regards, --MM-- On Tue, 4 Dec 2007, Lukas Hejtmanek wrote: Another problem at my own machine. If I force speed to 100Mb on 1GE network, I can reach 95Mbps bidirectional using UDP (0.34% loses) but only 1.2Mbps using TCP. A bug? If I enable autonegotiation and run at 1GE, I can got 95Mb on TCP to the target machine (the target machine has only 100Mb connection). -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
On Tue, Dec 04, 2007 at 11:02:23AM -0500, Matt Mathis wrote: This is probably not an e1000 problem, but a general Ethernet feature. If you defeat auto-negotiation to force the data rate, you implicitly defeat duplex negotiation as well. You need to explicitly set the duplex mode. ethtool reports, that I have full duplex line: ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: Not reported Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: umbg Wake-on: d Current message level: 0x0007 (7) Link detected: yes -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
Lukas Hejtmanek wrote: On Tue, Dec 04, 2007 at 11:02:23AM -0500, Matt Mathis wrote: This is probably not an e1000 problem, but a general Ethernet feature. If you defeat auto-negotiation to force the data rate, you implicitly defeat duplex negotiation as well. You need to explicitly set the duplex mode. ethtool reports, that I have full duplex line: Matt was almost right - the link partner however might be working in half duplex mode. in case you force speed/duplex, you are *required* to force the exact same setting on the link partner, otherwise things like this can happen. if you just want to disable gigabit speed, get the latest ethtool and run: ethtool -s eth0 advertise 0x0f which keeps autonegotiation enabled but tells the e1000 card to _not_ advertise gigabit speed capability to the link partner. The link partner and the e1000 can then decide with autonegotiation whether to use 10half 10duplex 100half or 100full. Auke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
Here is some boilerplate on autoneg which I've been using in other forums for a number of years when questions about autoneg vs hardcoding and duplex-mismatch arise: How 100Base-T Autoneg is supposed to work: When both sides of the link are set to autoneg, they will negotiate the duplex setting and select full-duplex if both sides can do full-duplex. If one side is hardcoded and not using autoneg, the autoneg process will fail and the side trying to autoneg is required by spec to use half-duplex mode. If one side is using half-duplex, and the other is using full-duplex, sorrow and woe is the usual result. So, the following table shows what will happen given various settings on each side: Auto Half Full AutoHappiness Lucky Sorrow HalfLucky Happiness Sorrow FullSorrow Sorrow Happiness Happiness means that there is a good shot of everything going well. Lucky means that things will likely go well, but not because you did anything correctly :) Sorrow means that there _will_ be a duplex mis-match. When there is a duplex mismatch, on the side running half-duplex you will see various errors and probably a number of _LATE_ collisions (normal collisions don't count here). On the side running full-duplex you will see things like FCS errors. Note that those errors are not necessarily conclusive, they are simply indicators. Further, it is important to keep in mind that a clean ping (or the like - eg linkloop or default netperf TCP_RR) test result is inconclusive here - a duplex mismatch causes lost traffic _only_ when both sides of the link try to speak at the same time. A typical ping test, being synchronous, one at a time request/response, never tries to have both sides talking at the same time. Finally, when/if you migrate to 1000Base-T, everything has to be set to auto-neg anyway. rick jones -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
On Tue, Dec 04, 2007 at 09:19:11AM -0800, Kok, Auke wrote: if you just want to disable gigabit speed, get the latest ethtool and run: ethtool -s eth0 advertise 0x0f thanks. You may then let know people behind http://www.lesswatts.org/ to change tipstricks related to the network. I turned off autonegotiation according to that web. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
Lukas Hejtmanek wrote: On Tue, Dec 04, 2007 at 09:19:11AM -0800, Kok, Auke wrote: if you just want to disable gigabit speed, get the latest ethtool and run: ethtool -s eth0 advertise 0x0f thanks. You may then let know people behind http://www.lesswatts.org/ to change tipstricks related to the network. I turned off autonegotiation according to that web. I have sent this out to them recently. This feature however is not available in all drivers, they explicitly need to be able to handle the advertise mask flag, and it requires a newer ethtool. Cheers, Auke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
On Tue, Nov 27, 2007 at 10:23:00AM -0800, Kok, Auke wrote: can you see if your problem goes away with this patch? I cannot test it right now but friend of mine has the same card with 2.6.23.1 kernel. it does not. he also tried module 7.6.12 from source fourge, your patch did not help. Moreover, it just hangs network connections after while. No message in dmesg about hangup. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
Lukas Hejtmanek wrote: On Tue, Nov 27, 2007 at 10:23:00AM -0800, Kok, Auke wrote: can you see if your problem goes away with this patch? I cannot test it right now but friend of mine has the same card with 2.6.23.1 kernel. it does not. he also tried module 7.6.12 from source fourge, your patch did not help. Moreover, it just hangs network connections after while. No message in dmesg about hangup. can you open up a ticket on e1000.sf.net and fill in a full bugreport including output of all of these? : - ethttool -i eth0 - ethtool -e eth0 - lspci -vv - full dmesg (not just the driver parts) - dmidecode - cat /proc/interrupts I'd like to see if maybe we can reproduce this in our lab. Thanks, Auke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
[moving this discussion to netdev, dropping lkml] Lukas Hejtmanek wrote: On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote: unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2 kernel due to compilation errors. but the in-kernel version of e1000 supports the ich8 lan device just fine and can be builtin. also this kernel has the first release of e1000e which supports the ich9 onboard lan device. I'm afraid, I'm missing the point as you have stated that in-kernel drivers have problem with suspicious board hang... my mistake, sorry for that confusion. the fake hangs on 82562/6 devices occur on 10mbit link only. You can check in the code for a line that says: adapter-tx_timeout_factor = 8; change that number to 16 to cope with the problem on 10mbit link partners. However this won't fix the issue on 100mbit partners and we need to investigate that if that is the case. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
On Tue, Nov 27, 2007 at 09:40:08AM -0800, Kok, Auke wrote: I'm afraid, I'm missing the point as you have stated that in-kernel drivers have problem with suspicious board hang... my mistake, sorry for that confusion. the fake hangs on 82562/6 devices occur on 10mbit link only. You can check in the code for a line that says: adapter-tx_timeout_factor = 8; change that number to 16 to cope with the problem on 10mbit link partners. However this won't fix the issue on 100mbit partners and we need to investigate that if that is the case. 100mbit is the issue in my case. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 driver problems
Lukas Hejtmanek wrote: On Tue, Nov 27, 2007 at 09:40:08AM -0800, Kok, Auke wrote: I'm afraid, I'm missing the point as you have stated that in-kernel drivers have problem with suspicious board hang... my mistake, sorry for that confusion. the fake hangs on 82562/6 devices occur on 10mbit link only. You can check in the code for a line that says: adapter-tx_timeout_factor = 8; change that number to 16 to cope with the problem on 10mbit link partners. However this won't fix the issue on 100mbit partners and we need to investigate that if that is the case. 100mbit is the issue in my case. can you see if your problem goes away with this patch? --- e1000: increase tx timeout factor for 100mbit speeds Signed-off-by: Auke Kok [EMAIL PROTECTED] diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index b7c3070..2e46a15 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -2601,7 +2601,7 @@ e1000_watchdog(unsigned long data) case SPEED_100: txb2b = 0; netdev-tx_queue_len = 100; - /* maybe add some timeout factor ? */ + adapter-tx_timeout_factor = 4; break; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
