[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKmKYaAWhTwucTP1joMcywv61ugi9gHNDGS3KaJjn6SLhvL5Dw@mail.gmail.com>
Date: Thu, 27 Sep 2012 08:45:20 +0200
From: Dirkjan Ochtman <dirkjan@...tman.nl>
To: Nithin Nayak Sujir <nsujir@...adcom.com>
Cc: netdev@...r.kernel.org
Subject: Re: Problems with tg3 on BCM5720
On Wed, Sep 26, 2012 at 11:13 PM, Nithin Nayak Sujir
<nsujir@...adcom.com> wrote:
> 1. Can you tell me the last patch that is included in the tg3 driver in
> 3.4.9 on your distro?
There are no tg3-specific patches in my distro's 3.4.9 package.
> 2. Can you give more info about the working setup?
The working setup is a simple small VLAN with a 192.168.1.0/24 subnet
and a few other Linux boxes on it (some of them also have BCM5720,
others have BCM5722 or BCM5709 networking). Not sure what other
information you'd want about this?
> 3. Was there any system reset or driver reload between the working and not
> working setups? Or was it just a cable switch?
Just a cable switch suffices to reproduce the problem we're seeing.
> 4. Please give the output of
> ethtool eth0
> ethtool -i eth0
> ethtool -k eth0
djc@...sky ~ $ sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
djc@...sky ~ $ sudo ethtool -i eth0
driver: tg3
version: 3.124
firmware-version: FFV7.2.14 bc 5720-v1.25
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
djc@...sky ~ $ sudo ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
(Note that this is with my hacked up driver from the 3.6 tree, taken
from 185d4c8bf579322e1c2835d70729bc30f6f80f55, with
8d4057a938481351dc690fbe23e8c72af08d5890,
d3836f21b0af5513ef55701dd3f50b8c42e44c7a,
a1e8b307986ab27b7608f107aec71d3569650f46,
118008784965003307ea164370094c7d0810546e,
3f84749004925dd1e94025292fed5c76ce418516 reverted to make it compile
on 3.4.9.)
> 5. Can you run ethtool --test in the working setup?
Here's the ethtool --test result from eth1, which is currently plugged
into the VLAN (eth0 was plugged into it before; we also tried plugging
the external network into eth1, but that gave the same results as
plugging it into eth0).
djc@...sky ~ $ sudo ethtool --test eth1
The test result is PASS
The test extra info:
nvram test (online) 0
link test (online) 0
register test (offline) 0
memory test (offline) 0
mac loopback test (offline) 0
phy loopback test (offline) 0
ext loopback test (offline) 0
interrupt test (offline) 0
> 6. I noticed in the syslog, the link is coming up at 100 Mbps. Is this
> expected?
No, I don't think so, it should be a Gbit line.
> 7. Does it fail immediately on connect to the data center switch? Or is it
> after some traffic goes through?
The vendor whose switch we're connecting to says they see that the
link is up, but they don't see a MAC attached. One of the things that
look weird to me is the ifconfig output saying "RX packets:513
errors:0 dropped:0 overruns:0 frame:0" but also "TX packets:0 errors:0
dropped:0 overruns:0 carrier:0".
On Wed, Sep 26, 2012 at 11:40 PM, Michael Chan <mchan@...adcom.com> wrote:
> It is most likely that the device eth0 is down. The device needs to be
> up in order to perform all the tests that failed. Please bring up the
> device and run the test again. Thanks.
Right, sorry about that. Here's the results again, with the interface up:
djc@...sky ~ $ sudo ethtool --test eth0
The test result is FAIL
The test extra info:
nvram test (online) 0
link test (online) 0
register test (offline) 0
memory test (offline) 0
mac loopback test (offline) 0
phy loopback test (offline) 5
ext loopback test (offline) 0
interrupt test (offline) 0
Hope that helps,
Dirkjan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists