From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@ozlabs.org, Li Yang <leoli@freescale.com>,
Andy Fleming <afleming@freescale.com>,
netdev@vger.kernel.org
Subject: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
Date: Wed, 24 Jun 2009 22:27:34 +0400 [thread overview]
Message-ID: <20090624182734.GA14306@oksana.dev.rtsoft.ru> (raw)
It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[...]
Sending DHCP requests .
PHY: mdio@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/gianfar.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
+ phy_interface_t phyi = phydev->interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII))
+ tempval &= ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Miller <davem@davemloft.net>
Cc: Kumar Gala <galak@kernel.crashing.org>,
Andy Fleming <afleming@freescale.com>,
Li Yang <leoli@freescale.com>,
linuxppc-dev@ozlabs.org, netdev@vger.kernel.org
Subject: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
Date: Wed, 24 Jun 2009 22:27:34 +0400 [thread overview]
Message-ID: <20090624182734.GA14306@oksana.dev.rtsoft.ru> (raw)
It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[...]
Sending DHCP requests .
PHY: mdio@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/gianfar.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
+ phy_interface_t phyi = phydev->interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII))
+ tempval &= ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
next reply other threads:[~2009-06-24 18:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 18:27 Anton Vorontsov [this message]
2009-06-24 18:27 ` [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces Anton Vorontsov
2009-06-24 20:18 ` Andy Fleming
2009-06-24 21:10 ` Anton Vorontsov
2009-06-24 21:10 ` Anton Vorontsov
2009-06-24 21:25 ` Andy Fleming
2009-06-24 21:25 ` Andy Fleming
2009-06-24 21:39 ` Anton Vorontsov
2009-06-24 21:39 ` Anton Vorontsov
2009-06-24 21:50 ` Anton Vorontsov
2009-06-24 21:50 ` Anton Vorontsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090624182734.GA14306@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=afleming@freescale.com \
--cc=davem@davemloft.net \
--cc=leoli@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.