Re: e1000 driver problems

Re: e1000 driver problems

[Kok, Auke]

[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

Re: e1000 driver problems

[Lukas Hejtmanek]

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

Re: e1000 driver problems

[Kok, Auke]

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 <auke-jan.h.kok@intel.com>

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;
                        }

Re: e1000 driver problems

[Lukas Hejtmanek]

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

Re: e1000 driver problems

[Kok, Auke]

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

Re: e1000 driver problems

[Lukas Hejtmanek]

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

Re: e1000 driver problems

[Lukas Hejtmanek]

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

Re: e1000 driver problems

[Matt Mathis]

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).
>

Re: e1000 driver problems

[Lukas Hejtmanek]

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: 0x00000007 (7)
        Link detected: yes


-- 
Lukáš Hejtmánek

Re: e1000 driver problems

[Kok, Auke]

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

Re: e1000 driver problems

[Rick Jones]

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

    Auto        Happiness   Lucky      Sorrow

    Half        Lucky       Happiness  Sorrow

    Full        Sorrow      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

Re: e1000 driver problems

[Lukas Hejtmanek]

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 tips&tricks related to the network. I turned off autonegotiation
according to that web.

-- 
Lukáš Hejtmánek

Re: e1000 driver problems

[Kok, Auke]

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 tips&tricks 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

Re: e1000 driver problems

[Lukas Hejtmanek]

Hello,

the problem seems to be gone in 2.6.24-rc kernels.

-- 
Lukáš Hejtmánek