Reported this earlier as a 3c509 card in error, should
have been 3c900 (3c59x driver).
FYI:
Single 3c900 card, UP i386
Lost networking with .16-git12, message
ADDRCONF(NETDEV_UP): eth0: link is not ready
Had several of these with git11
NETDEV WATCHDOG: eth0: transmit timed out
No problems observed git1-git10
--
Pete Clements
On Sun, Mar 26, 2006 at 09:12:30PM -0500, Pete Clements wrote:
> Reported this earlier as a 3c509 card in error, should
> have been 3c900 (3c59x driver).
>
> FYI:
> Single 3c900 card, UP i386
> Lost networking with .16-git12, message
> ADDRCONF(NETDEV_UP): eth0: link is not ready
This could be due to the recent driver update.
I can not reproduce this with a 3c900B-Combo,
so I need some more information to track it down.
> Had several of these with git11
> NETDEV WATCHDOG: eth0: transmit timed out
Is this for sure that these messages occured first time with git11?
There were no changes in the 3c59x driver between git10 and git11.
>
> No problems observed git1-git10
>
If you are willing to provide me with some information
you can send the following:
1. output of lspci -vvv (just the ethernet controller related part)
2. your Kernel configuration
3. modprobe the driver with debug=4 and send
the 3c59x related lines of your logs for both, git11 and git12.
(From driver startup about 15 seconds should be sufficiant for now)
4. the output of "vortex-diag -aem" and "mii-diag".
You can find these tools at http://www.scyld.com/ethercard_diag.html
Steffen
Quoting Steffen Klassert
> >
> > FYI:
> > Single 3c900 card, UP i386
> > Lost networking with .16-git12, message
> > ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> This could be due to the recent driver update.
> I can not reproduce this with a 3c900B-Combo,
> so I need some more information to track it down.
Data attached. Note:
1) Using coax 10base2.
2) Driver is compiled in, not a module. If you need I'll
recompile with debug set.
>
> > Had several of these with git11
> > NETDEV WATCHDOG: eth0: transmit timed out
>
> Is this for sure that these messages occured first time with git11?
> There were no changes in the 3c59x driver between git10 and git11.
Only occurrance in git11, 4 hits during a local net ftp. Low network
load system.
>
> >
> > No problems observed git1-git10
> >
>
> If you are willing to provide me with some information
> you can send the following:
>
> 1. output of lspci -vvv (just the ethernet controller related part)
>
> 2. your Kernel configuration
>
> 3. modprobe the driver with debug=4 and send
> the 3c59x related lines of your logs for both, git11 and git12.
> (From driver startup about 15 seconds should be sufficiant for now)
>
> 4. the output of "vortex-diag -aem" and "mii-diag".
> You can find these tools at http://www.scyld.com/ethercard_diag.html
>
>
> Steffen
> -
--
Pete Clements
Quoting Pete Clements
> From linux-kernel-owner+clem=40clem.clem-digital.net-S1751558AbWC0CMb@vger.kernel.org Sun Mar 26 21:12:57 2006
> Return-Path: <linux-kernel-owner+clem=40clem.clem-digital.net-S1751558AbWC0CMb@vger.kernel.org>
> Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
> by clem.clem-digital.net (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k2R2Cuso003676
> for <[email protected]>; Sun, 26 Mar 2006 21:12:56 -0500
> Received: ([email protected]) by vger.kernel.org via listexpand
> id S1751558AbWC0CMb (ORCPT <rfc822;[email protected]>);
> Sun, 26 Mar 2006 21:12:31 -0500
> Received: ([email protected]) by vger.kernel.org id S1751560AbWC0CMb
> (ORCPT <rfc822;linux-kernel-outgoing>);
> Sun, 26 Mar 2006 21:12:31 -0500
> Received: from clem.clem-digital.net ([68.16.168.10]:47329 "EHLO
> clem.clem-digital.net") by vger.kernel.org with ESMTP
> id S1751547AbWC0CMb (ORCPT <rfc822;[email protected]>);
> Sun, 26 Mar 2006 21:12:31 -0500
> Received: from clem.clem-digital.net (clem@localhost [127.0.0.1])
> by clem.clem-digital.net (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k2R2CUJe003656
> for <[email protected]>; Sun, 26 Mar 2006 21:12:30 -0500
> Received: (from clem@localhost)
> by clem.clem-digital.net (8.13.4/8.13.4/Submit) id k2R2CUki003654
> for [email protected]; Sun, 26 Mar 2006 21:12:30 -0500
> From: Pete Clements <[email protected]>
> Message-Id: <[email protected]>
> Subject: Correction: 2.6.16-git12 killed networking -- 3c900 card
> To: [email protected] (linux-kernel)
> Date: Sun, 26 Mar 2006 21:12:30 -0500 (EST)
> X-Mailer: ELM [version 2.5 PL7]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Sender: [email protected]
> Precedence: bulk
> X-Mailing-List: [email protected]
>
> Reported this earlier as a 3c509 card in error, should
> have been 3c900 (3c59x driver).
>
> FYI:
> Single 3c900 card, UP i386
> Lost networking with .16-git12, message
> ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> Had several of these with git11
> NETDEV WATCHDOG: eth0: transmit timed out
>
> No problems observed git1-git10
>
> --
> Pete Clements
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Pete Clements
Quoting Steffen Klassert
> > Had several of these with git11
> > NETDEV WATCHDOG: eth0: transmit timed out
>
> Is this for sure that these messages occured first time with git11?
> There were no changes in the 3c59x driver between git10 and git11.
>
Tried the the same ftp with a 2.6.16 and get the time out. I'll try 2.6.15
to see what happens.
--
Pete Clements
Quoting Steffen Klassert
> > Had several of these with git11
> > NETDEV WATCHDOG: eth0: transmit timed out
>
> Is this for sure that these messages occured first time with git11?
> There were no changes in the 3c59x driver between git10 and git11.
>
Tried 2.6.15 and could not get a timed out condition. Looks like
that defect is between 15 and 16 in my case.
Be glad to do any testing that I can.
--
Pete Clements
Pete Clements <[email protected]> wrote:
>
> Quoting Steffen Klassert
> > > Had several of these with git11
> > > NETDEV WATCHDOG: eth0: transmit timed out
> >
> > Is this for sure that these messages occured first time with git11?
> > There were no changes in the 3c59x driver between git10 and git11.
> >
> Tried 2.6.15 and could not get a timed out condition. Looks like
> that defect is between 15 and 16 in my case.
>
> Be glad to do any testing that I can.
>
Well here's one. Steffen, please confirm.
From: Andrew Morton <[email protected]>
The pre-2.6.16 patch "3c59x collision statistics fix" accidentally caused
vortex_error() to not run iowrite16(TxEnable, ioaddr + EL3_CMD) if we got a
maxCollisions interrupt but MAX_COLLISION_RESET is not set.
Cc: Steffen Klassert <[email protected]>
Cc: Pete Clements <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
drivers/net/3c59x.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff -puN drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix drivers/net/3c59x.c
--- devel/drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix 2006-03-28 22:36:48.000000000 -0800
+++ devel-akpm/drivers/net/3c59x.c 2006-03-28 22:40:01.000000000 -0800
@@ -2085,16 +2085,14 @@ vortex_error(struct net_device *dev, int
}
if (tx_status & 0x14) vp->stats.tx_fifo_errors++;
if (tx_status & 0x38) vp->stats.tx_aborted_errors++;
+ if (tx_status & 0x08) vp->xstats.tx_max_collisions++;
iowrite8(0, ioaddr + TxStatus);
if (tx_status & 0x30) { /* txJabber or txUnderrun */
do_tx_reset = 1;
- } else if (tx_status & 0x08) { /* maxCollisions */
- vp->xstats.tx_max_collisions++;
- if (vp->drv_flags & MAX_COLLISION_RESET) {
- do_tx_reset = 1;
- reset_mask = 0x0108; /* Reset interface logic, but not download logic */
- }
- } else { /* Merely re-enable the transmitter. */
+ } else if ((tx_status & 0x08) && (vp->drv_flags & MAX_COLLISION_RESET)) { /* maxCollisions */
+ do_tx_reset = 1;
+ reset_mask = 0x0108; /* Reset interface logic, but not download logic */
+ } else { /* Merely re-enable the transmitter. */
iowrite16(TxEnable, ioaddr + EL3_CMD);
}
}
_
Pete Clements <[email protected]> wrote:
>
> Quoting Steffen Klassert
> > > Had several of these with git11
> > > NETDEV WATCHDOG: eth0: transmit timed out
> >
> > Is this for sure that these messages occured first time with git11?
> > There were no changes in the 3c59x driver between git10 and git11.
> >
> Tried 2.6.15 and could not get a timed out condition. Looks like
> that defect is between 15 and 16 in my case.
>
> Be glad to do any testing that I can.
>
Please try adding the 3c59x module parameter `global_enable_wol=0', see if
that helps.
Pete Clements <[email protected]> wrote:
>
> Quoting Steffen Klassert
> > > Had several of these with git11
> > > NETDEV WATCHDOG: eth0: transmit timed out
> >
> > Is this for sure that these messages occured first time with git11?
> > There were no changes in the 3c59x driver between git10 and git11.
> >
> Tried 2.6.15 and could not get a timed out condition. Looks like
> that defect is between 15 and 16 in my case.
>
> Be glad to do any testing that I can.
If it's noether of those then I'd expect the problem relates to the
conversion to use the standard mii layer. Possibly we need to re-port some
mdo reading oddity into 3c59x.c:mdio_read(), but it would take some effort
to work out which one.
You could try this shot-in-the-dark:
diff -puN drivers/net/3c59x.c~revert-3c59x-avoid-blindly-reading-link-status-twice drivers/net/3c59x.c
--- devel/drivers/net/3c59x.c~revert-3c59x-avoid-blindly-reading-link-status-twice 2006-03-28 22:51:52.000000000 -0800
+++ devel-akpm/drivers/net/3c59x.c 2006-03-28 23:00:47.000000000 -0800
@@ -3196,7 +3196,7 @@ static void mdio_sync(void __iomem *ioad
}
}
-static int mdio_read(struct net_device *dev, int phy_id, int location)
+static int __mdio_read(struct net_device *dev, int phy_id, int location)
{
int i;
struct vortex_private *vp = netdev_priv(dev);
@@ -3227,6 +3227,13 @@ static int mdio_read(struct net_device *
return retval & 0x20000 ? 0xffff : retval>>1 & 0xffff;
}
+static int mdio_read(struct net_device *dev, int phy_id, int location)
+{
+ if (location == MII_BMSR)
+ __mdio_read(dev, phy_id, location);
+ return __mdio_read(dev, phy_id, location);
+}
+
static void mdio_write(struct net_device *dev, int phy_id, int location, int value)
{
struct vortex_private *vp = netdev_priv(dev);
_
On Tue, Mar 28, 2006 at 10:43:08PM -0800, Andrew Morton wrote:
> Pete Clements <[email protected]> wrote:
> >
> > Quoting Steffen Klassert
> > > > Had several of these with git11
> > > > NETDEV WATCHDOG: eth0: transmit timed out
> > >
> > > Is this for sure that these messages occured first time with git11?
> > > There were no changes in the 3c59x driver between git10 and git11.
> > >
> > Tried 2.6.15 and could not get a timed out condition. Looks like
> > that defect is between 15 and 16 in my case.
> >
> > Be glad to do any testing that I can.
> >
I will try to borrow a coax cable and see whats up with 10base2.
>
> Well here's one. Steffen, please confirm.
>
>
> From: Andrew Morton <[email protected]>
>
> The pre-2.6.16 patch "3c59x collision statistics fix" accidentally caused
> vortex_error() to not run iowrite16(TxEnable, ioaddr + EL3_CMD) if we got a
> maxCollisions interrupt but MAX_COLLISION_RESET is not set.
True, this can explain the transmit timed out messages.
Acked-by: Steffen Klassert <[email protected]>
>
> Cc: Steffen Klassert <[email protected]>
> Cc: Pete Clements <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> drivers/net/3c59x.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff -puN drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix drivers/net/3c59x.c
> --- devel/drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix 2006-03-28 22:36:48.000000000 -0800
> +++ devel-akpm/drivers/net/3c59x.c 2006-03-28 22:40:01.000000000 -0800
> @@ -2085,16 +2085,14 @@ vortex_error(struct net_device *dev, int
> }
> if (tx_status & 0x14) vp->stats.tx_fifo_errors++;
> if (tx_status & 0x38) vp->stats.tx_aborted_errors++;
> + if (tx_status & 0x08) vp->xstats.tx_max_collisions++;
> iowrite8(0, ioaddr + TxStatus);
> if (tx_status & 0x30) { /* txJabber or txUnderrun */
> do_tx_reset = 1;
> - } else if (tx_status & 0x08) { /* maxCollisions */
> - vp->xstats.tx_max_collisions++;
> - if (vp->drv_flags & MAX_COLLISION_RESET) {
> - do_tx_reset = 1;
> - reset_mask = 0x0108; /* Reset interface logic, but not download logic */
> - }
> - } else { /* Merely re-enable the transmitter. */
> + } else if ((tx_status & 0x08) && (vp->drv_flags & MAX_COLLISION_RESET)) { /* maxCollisions */
> + do_tx_reset = 1;
> + reset_mask = 0x0108; /* Reset interface logic, but not download logic */
> + } else { /* Merely re-enable the transmitter. */
> iowrite16(TxEnable, ioaddr + EL3_CMD);
> }
> }
> _
On Tue, Mar 28, 2006 at 11:44:54AM -0500, Pete Clements wrote:
> Quoting Steffen Klassert
> > >
> > > FYI:
> > > Single 3c900 card, UP i386
> > > Lost networking with .16-git12, message
> > > ADDRCONF(NETDEV_UP): eth0: link is not ready
> >
> > This could be due to the recent driver update.
> > I can not reproduce this with a 3c900B-Combo,
> > so I need some more information to track it down.
>
> Data attached. Note:
> 1) Using coax 10base2.
Somehow 10base2 does not like a netif_carrier_off.
Please try the pach below. It makes 10base2 work again for me.
Steffen
--- linux-2.6.16-git12/drivers/net/3c59x.c 2006-03-29 11:23:48.000000000 +0200
+++ linux-2.6.16-git12-sk/drivers/net/3c59x.c 2006-03-29 13:40:28.000000000 +0200
@@ -1723,7 +1723,6 @@
printk(KERN_DEBUG "vortex_up(): writing 0x%x to InternalConfig\n", config);
iowrite32(config, ioaddr + Wn3_Config);
- netif_carrier_off(dev);
if (dev->if_port == XCVR_MII || dev->if_port == XCVR_NWAY) {
EL3WINDOW(4);
vortex_check_media(dev, 1);
Patch gives me the network back (applied to git16).
Timeout problem remains, trying Andrews patches.
> > > > FYI:
> > > > Single 3c900 card, UP i386
> > > > Lost networking with .16-git12, message
> > > > ADDRCONF(NETDEV_UP): eth0: link is not ready
> > >
> > > This could be due to the recent driver update.
> > > I can not reproduce this with a 3c900B-Combo,
> > > so I need some more information to track it down.
> >
> > Data attached. Note:
> > 1) Using coax 10base2.
>
> Somehow 10base2 does not like a netif_carrier_off.
>
> Please try the pach below. It makes 10base2 work again for me.
>
> Steffen
>
> --- linux-2.6.16-git12/drivers/net/3c59x.c 2006-03-29 11:23:48.000000000 +0200
> +++ linux-2.6.16-git12-sk/drivers/net/3c59x.c 2006-03-29 13:40:28.000000000 +0200
> @@ -1723,7 +1723,6 @@
> printk(KERN_DEBUG "vortex_up(): writing 0x%x to InternalConfig\n", config);
> iowrite32(config, ioaddr + Wn3_Config);
>
> - netif_carrier_off(dev);
> if (dev->if_port == XCVR_MII || dev->if_port == XCVR_NWAY) {
> EL3WINDOW(4);
> vortex_check_media(dev, 1);
>
--
Pete Clements
Quoting Andrew Morton
Patch applied to 2.6.16, timeouts remain. Will try the other also.
> Pete Clements <[email protected]> wrote:
> >
> > Quoting Steffen Klassert
> > > > Had several of these with git11
> > > > NETDEV WATCHDOG: eth0: transmit timed out
> > >
> > > Is this for sure that these messages occured first time with git11?
> > > There were no changes in the 3c59x driver between git10 and git11.
> > >
> > Tried 2.6.15 and could not get a timed out condition. Looks like
> > that defect is between 15 and 16 in my case.
> >
> > Be glad to do any testing that I can.
> >
>
> Well here's one. Steffen, please confirm.
>
>
> From: Andrew Morton <[email protected]>
>
> The pre-2.6.16 patch "3c59x collision statistics fix" accidentally caused
> vortex_error() to not run iowrite16(TxEnable, ioaddr + EL3_CMD) if we got a
> maxCollisions interrupt but MAX_COLLISION_RESET is not set.
>
> Cc: Steffen Klassert <[email protected]>
> Cc: Pete Clements <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> drivers/net/3c59x.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff -puN drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix drivers/net/3c59x.c
> --- devel/drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix 2006-03-28 22:36:48.000000000 -0800
> +++ devel-akpm/drivers/net/3c59x.c 2006-03-28 22:40:01.000000000 -0800
> @@ -2085,16 +2085,14 @@ vortex_error(struct net_device *dev, int
> }
> if (tx_status & 0x14) vp->stats.tx_fifo_errors++;
> if (tx_status & 0x38) vp->stats.tx_aborted_errors++;
> + if (tx_status & 0x08) vp->xstats.tx_max_collisions++;
> iowrite8(0, ioaddr + TxStatus);
> if (tx_status & 0x30) { /* txJabber or txUnderrun */
> do_tx_reset = 1;
> - } else if (tx_status & 0x08) { /* maxCollisions */
> - vp->xstats.tx_max_collisions++;
> - if (vp->drv_flags & MAX_COLLISION_RESET) {
> - do_tx_reset = 1;
> - reset_mask = 0x0108; /* Reset interface logic, but not download logic */
> - }
> - } else { /* Merely re-enable the transmitter. */
> + } else if ((tx_status & 0x08) && (vp->drv_flags & MAX_COLLISION_RESET)) { /* maxCollisions */
> + do_tx_reset = 1;
> + reset_mask = 0x0108; /* Reset interface logic, but not download logic */
> + } else { /* Merely re-enable the transmitter. */
> iowrite16(TxEnable, ioaddr + EL3_CMD);
> }
> }
> _
>
--
Pete Clements
Quoting Andrew Morton
> > Quoting Steffen Klassert
> > > > Had several of these with git11
> > > > NETDEV WATCHDOG: eth0: transmit timed out
> > >
> > > Is this for sure that these messages occured first time with git11?
> > > There were no changes in the 3c59x driver between git10 and git11.
> > >
> > Tried 2.6.15 and could not get a timed out condition. Looks like
> > that defect is between 15 and 16 in my case.
> >
> > Be glad to do any testing that I can.
> >
>
> Please try adding the 3c59x module parameter `global_enable_wol=0', see if
> that helps.
>
Driver is compiled in, not module.
--
Pete Clements
Patch applied on top of previous patch to 2.6.16, no longer
seeing the timeouts.
> Pete Clements <[email protected]> wrote:
> >
> > Quoting Steffen Klassert
> > > > Had several of these with git11
> > > > NETDEV WATCHDOG: eth0: transmit timed out
> > >
> > > Is this for sure that these messages occured first time with git11?
> > > There were no changes in the 3c59x driver between git10 and git11.
> > >
> > Tried 2.6.15 and could not get a timed out condition. Looks like
> > that defect is between 15 and 16 in my case.
> >
> > Be glad to do any testing that I can.
>
> If it's noether of those then I'd expect the problem relates to the
> conversion to use the standard mii layer. Possibly we need to re-port some
> mdo reading oddity into 3c59x.c:mdio_read(), but it would take some effort
> to work out which one.
>
> You could try this shot-in-the-dark:
>
>
> diff -puN drivers/net/3c59x.c~revert-3c59x-avoid-blindly-reading-link-status-twice drivers/net/3c59x.c
> --- devel/drivers/net/3c59x.c~revert-3c59x-avoid-blindly-reading-link-status-twice 2006-03-28 22:51:52.000000000 -0800
> +++ devel-akpm/drivers/net/3c59x.c 2006-03-28 23:00:47.000000000 -0800
> @@ -3196,7 +3196,7 @@ static void mdio_sync(void __iomem *ioad
> }
> }
>
> -static int mdio_read(struct net_device *dev, int phy_id, int location)
> +static int __mdio_read(struct net_device *dev, int phy_id, int location)
> {
> int i;
> struct vortex_private *vp = netdev_priv(dev);
> @@ -3227,6 +3227,13 @@ static int mdio_read(struct net_device *
> return retval & 0x20000 ? 0xffff : retval>>1 & 0xffff;
> }
>
> +static int mdio_read(struct net_device *dev, int phy_id, int location)
> +{
> + if (location == MII_BMSR)
> + __mdio_read(dev, phy_id, location);
> + return __mdio_read(dev, phy_id, location);
> +}
> +
> static void mdio_write(struct net_device *dev, int phy_id, int location, int value)
> {
> struct vortex_private *vp = netdev_priv(dev);
> _
>
--
Pete Clements
Pete Clements <[email protected]> wrote:
>
> Quoting Andrew Morton
> > > Quoting Steffen Klassert
> > > > > Had several of these with git11
> > > > > NETDEV WATCHDOG: eth0: transmit timed out
> > > >
> > > > Is this for sure that these messages occured first time with git11?
> > > > There were no changes in the 3c59x driver between git10 and git11.
> > > >
> > > Tried 2.6.15 and could not get a timed out condition. Looks like
> > > that defect is between 15 and 16 in my case.
> > >
> > > Be glad to do any testing that I can.
> > >
> >
> > Please try adding the 3c59x module parameter `global_enable_wol=0', see if
> > that helps.
> >
> Driver is compiled in, not module.
>
Boot with 3c59x.global_enable_wol=0 on the kernel command line.
Quoting Andrew Morton
>
> Pete Clements <[email protected]> wrote:
> >
> > Quoting Andrew Morton
> > > > Quoting Steffen Klassert
> > > > > > Had several of these with git11
> > > > > > NETDEV WATCHDOG: eth0: transmit timed out
> > > > >
> > > > > Is this for sure that these messages occured first time with git11?
> > > > > There were no changes in the 3c59x driver between git10 and git11.
> > > > >
> > > > Tried 2.6.15 and could not get a timed out condition. Looks like
> > > > that defect is between 15 and 16 in my case.
> > > >
> > > > Be glad to do any testing that I can.
> > > >
> > >
> > > Please try adding the 3c59x module parameter `global_enable_wol=0', see if
> > > that helps.
> > >
> > Driver is compiled in, not module.
> >
>
> Boot with 3c59x.global_enable_wol=0 on the kernel command line.
>
Backed out your second patch and booted with the parameter. Not
seeing the time outs.
--
Pete Clements
Pete Clements <[email protected]> wrote:
>
> Quoting Andrew Morton
> >
> > Pete Clements <[email protected]> wrote:
> > >
> > > Quoting Andrew Morton
> > > > > Quoting Steffen Klassert
> > > > > > > Had several of these with git11
> > > > > > > NETDEV WATCHDOG: eth0: transmit timed out
> > > > > >
> > > > > > Is this for sure that these messages occured first time with git11?
> > > > > > There were no changes in the 3c59x driver between git10 and git11.
> > > > > >
> > > > > Tried 2.6.15 and could not get a timed out condition. Looks like
> > > > > that defect is between 15 and 16 in my case.
> > > > >
> > > > > Be glad to do any testing that I can.
> > > > >
> > > >
> > > > Please try adding the 3c59x module parameter `global_enable_wol=0', see if
> > > > that helps.
> > > >
> > > Driver is compiled in, not module.
> > >
> >
> > Boot with 3c59x.global_enable_wol=0 on the kernel command line.
> >
> Backed out your second patch and booted with the parameter. Not
> seeing the time outs.
>
Oh damn. So you're sure that 3c59x.global_enable_wol=0 actually makes the
driver behave better?
For years the driver required a special module parameter to enable WOL,
because there was some problem with some hardware. It's all lost in the
mists of time.
So the situation as I understand it now is:
- We need to apply the "vortex_error() to not run iowrite16" fix
- The "do mdio_read() twice if we're reading MII_BMSR" patch does indeed
fix something (what did it fix, again?) but we don't recall why the
driver was reading it twice in the first place.
Both patches are appended below.
If we do both of those things, does the driver still require
3c59x.global_enable_wol=0 to function properly?
(This driver supports a huge number of cards spread across 15 or more years
and it has large amounts of tricky trial-and-error knowledge in it. It's
generally best not to touch it).
From: Andrew Morton <[email protected]>
The pre-2.6.16 patch "3c59x collision statistics fix" accidentally caused
vortex_error() to not run iowrite16(TxEnable, ioaddr + EL3_CMD) if we got a
maxCollisions interrupt but MAX_COLLISION_RESET is not set.
Cc: Steffen Klassert <[email protected]>
Cc: Pete Clements <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
drivers/net/3c59x.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff -puN drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix drivers/net/3c59x.c
--- devel/drivers/net/3c59x.c~3c59x-collision-statistics-fix-fix 2006-03-28 22:36:48.000000000 -0800
+++ devel-akpm/drivers/net/3c59x.c 2006-03-28 22:40:01.000000000 -0800
@@ -2085,16 +2085,14 @@ vortex_error(struct net_device *dev, int
}
if (tx_status & 0x14) vp->stats.tx_fifo_errors++;
if (tx_status & 0x38) vp->stats.tx_aborted_errors++;
+ if (tx_status & 0x08) vp->xstats.tx_max_collisions++;
iowrite8(0, ioaddr + TxStatus);
if (tx_status & 0x30) { /* txJabber or txUnderrun */
do_tx_reset = 1;
- } else if (tx_status & 0x08) { /* maxCollisions */
- vp->xstats.tx_max_collisions++;
- if (vp->drv_flags & MAX_COLLISION_RESET) {
- do_tx_reset = 1;
- reset_mask = 0x0108; /* Reset interface logic, but not download logic */
- }
- } else { /* Merely re-enable the transmitter. */
+ } else if ((tx_status & 0x08) && (vp->drv_flags & MAX_COLLISION_RESET)) { /* maxCollisions */
+ do_tx_reset = 1;
+ reset_mask = 0x0108; /* Reset interface logic, but not download logic */
+ } else { /* Merely re-enable the transmitter. */
iowrite16(TxEnable, ioaddr + EL3_CMD);
}
}
_
From: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
drivers/net/3c59x.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletion(-)
diff -puN drivers/net/3c59x.c~revert-3c59x-avoid-blindly-reading-link-status-twice drivers/net/3c59x.c
--- devel/drivers/net/3c59x.c~revert-3c59x-avoid-blindly-reading-link-status-twice 2006-03-28 22:51:52.000000000 -0800
+++ devel-akpm/drivers/net/3c59x.c 2006-03-28 23:00:47.000000000 -0800
@@ -3196,7 +3196,7 @@ static void mdio_sync(void __iomem *ioad
}
}
-static int mdio_read(struct net_device *dev, int phy_id, int location)
+static int __mdio_read(struct net_device *dev, int phy_id, int location)
{
int i;
struct vortex_private *vp = netdev_priv(dev);
@@ -3227,6 +3227,13 @@ static int mdio_read(struct net_device *
return retval & 0x20000 ? 0xffff : retval>>1 & 0xffff;
}
+static int mdio_read(struct net_device *dev, int phy_id, int location)
+{
+ if (location == MII_BMSR)
+ __mdio_read(dev, phy_id, location);
+ return __mdio_read(dev, phy_id, location);
+}
+
static void mdio_write(struct net_device *dev, int phy_id, int location, int value)
{
struct vortex_private *vp = netdev_priv(dev);
_
Quoting Andrew Morton
>
> Oh damn. So you're sure that 3c59x.global_enable_wol=0 actually makes the
> driver behave better?
>
I seem to have lost the ability to time out. Let me get back to a fresh 16
build and work forward again.
--
Pete Clements
Quoting Andrew Morton
>
> Oh damn. So you're sure that 3c59x.global_enable_wol=0 actually makes the
> driver behave better?
>
Ok, new results.
Built a new virgin 2.6.16.
1) able to stimulate a tx time out message
2) rebooted with 3c59x.global_enable_wol=0 on command line,
able to stimulate a tx time out message
Applied the collision statistics fix fix. Changed the extraversion
in the top Makefile to preserve my baseline, also make does more
work than previous.
1) Booted and unable to stimulate a tx time out message
Rebooted to virgin 2.6.16
1) able to stimulate a tx time out message
2) rebooted with 3c59x.global_enable_wol=0 on command line,
able to stimulate a tx time out message
Rebooted to the patched driver kernel (collision statistics fix fix)
1) unable to stimulate a tx time out message.
Rebooted to virgin 2.6.16
1) able to stimulate a tx time out message
Appears that earlier results were tainted.
--
Pete Clements
Pete Clements <[email protected]> wrote:
>
> Quoting Andrew Morton
> >
> > Oh damn. So you're sure that 3c59x.global_enable_wol=0 actually makes the
> > driver behave better?
> >
> Ok, new results.
> Built a new virgin 2.6.16.
> 1) able to stimulate a tx time out message
> 2) rebooted with 3c59x.global_enable_wol=0 on command line,
> able to stimulate a tx time out message
>
> Applied the collision statistics fix fix. Changed the extraversion
> in the top Makefile to preserve my baseline, also make does more
> work than previous.
> 1) Booted and unable to stimulate a tx time out message
>
> Rebooted to virgin 2.6.16
> 1) able to stimulate a tx time out message
> 2) rebooted with 3c59x.global_enable_wol=0 on command line,
> able to stimulate a tx time out message
>
> Rebooted to the patched driver kernel (collision statistics fix fix)
> 1) unable to stimulate a tx time out message.
>
> Rebooted to virgin 2.6.16
> 1) able to stimulate a tx time out message
>
> Appears that earlier results were tainted.
>
OK, thanks. So it looks like 3c59x-collision-statistics-fix-fix.patch is
the only patch which we need to return your machine to working condition?
Quoting Andrew Morton
> Pete Clements <[email protected]> wrote:
> >
> > Quoting Andrew Morton
> > >
> > > Oh damn. So you're sure that 3c59x.global_enable_wol=0 actually makes the
> > > driver behave better?
> > >
> > Ok, new results.
> > Built a new virgin 2.6.16.
> > 1) able to stimulate a tx time out message
> > 2) rebooted with 3c59x.global_enable_wol=0 on command line,
> > able to stimulate a tx time out message
> >
> > Applied the collision statistics fix fix. Changed the extraversion
> > in the top Makefile to preserve my baseline, also make does more
> > work than previous.
> > 1) Booted and unable to stimulate a tx time out message
> >
> > Rebooted to virgin 2.6.16
> > 1) able to stimulate a tx time out message
> > 2) rebooted with 3c59x.global_enable_wol=0 on command line,
> > able to stimulate a tx time out message
> >
> > Rebooted to the patched driver kernel (collision statistics fix fix)
> > 1) unable to stimulate a tx time out message.
> >
> > Rebooted to virgin 2.6.16
> > 1) able to stimulate a tx time out message
> >
> > Appears that earlier results were tainted.
> >
>
> OK, thanks. So it looks like 3c59x-collision-statistics-fix-fix.patch is
> the only patch which we need to return your machine to working condition?
>
Looks like that is the case until -git12, which Steffen has identified.
Tested on git18 (with git12 fix) and looks good.
--
Pete Clements
On Thu, Mar 30, 2006 at 08:46:54AM -0500, Pete Clements wrote:
>
> Looks like that is the case until -git12, which Steffen has identified.
> Tested on git18 (with git12 fix) and looks good.
This Patch is a candidate for the final fix to make 10base2 work again.
Could you please try this together with Andrews
3c59x-collision-statistics-fix-fix.patch?
Steffen
--- linux-2.6.16-git12/drivers/net/3c59x.c 2006-03-30 14:16:23.000000000 +0200
+++ linux-2.6.16-git12-sk/drivers/net/3c59x.c 2006-03-30 15:27:13.000000000 +0200
@@ -788,7 +788,7 @@
int options; /* User-settable misc. driver options. */
unsigned int media_override:4, /* Passed-in media type. */
default_media:4, /* Read from the EEPROM/Wn3_Config. */
- full_duplex:1, force_fd:1, autoselect:1,
+ full_duplex:1, autoselect:1,
bus_master:1, /* Vortex can only do a fragment bus-m. */
full_bus_master_tx:1, full_bus_master_rx:2, /* Boomerang */
flow_ctrl:1, /* Use 802.3x flow control (PAUSE only) */
@@ -1633,12 +1633,6 @@
((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ?
0x100 : 0),
ioaddr + Wn3_MAC_Ctrl);
-
- issue_and_wait(dev, TxReset);
- /*
- * Don't reset the PHY - that upsets autonegotiation during DHCP operations.
- */
- issue_and_wait(dev, RxReset|0x04);
}
static void vortex_check_media(struct net_device *dev, unsigned int init)
@@ -1663,7 +1657,7 @@
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp->ioaddr;
unsigned int config;
- int i;
+ int i, mii_reg1, mii_reg5;
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */
@@ -1723,14 +1717,23 @@
printk(KERN_DEBUG "vortex_up(): writing 0x%x to InternalConfig\n", config);
iowrite32(config, ioaddr + Wn3_Config);
- netif_carrier_off(dev);
if (dev->if_port == XCVR_MII || dev->if_port == XCVR_NWAY) {
EL3WINDOW(4);
+ mii_reg1 = mdio_read(dev, vp->phys[0], MII_BMSR);
+ mii_reg5 = mdio_read(dev, vp->phys[0], MII_LPA);
+ vp->partner_flow_ctrl = ((mii_reg5 & 0x0400) != 0);
+
vortex_check_media(dev, 1);
}
else
vortex_set_duplex(dev);
+ issue_and_wait(dev, TxReset);
+ /*
+ * Don't reset the PHY - that upsets autonegotiation during DHCP operations.
+ */
+ issue_and_wait(dev, RxReset|0x04);
+
iowrite16(SetStatusEnb | 0x00, ioaddr + EL3_CMD);
Quoting Steffen Klassert
>
> On Thu, Mar 30, 2006 at 08:46:54AM -0500, Pete Clements wrote:
> >
> > Looks like that is the case until -git12, which Steffen has identified.
> > Tested on git18 (with git12 fix) and looks good.
>
> This Patch is a candidate for the final fix to make 10base2 work again.
> Could you please try this together with Andrews
> 3c59x-collision-statistics-fix-fix.patch?
>
> Steffen
>
> --- linux-2.6.16-git12/drivers/net/3c59x.c 2006-03-30 14:16:23.000000000 +0200
> +++ linux-2.6.16-git12-sk/drivers/net/3c59x.c 2006-03-30 15:27:13.000000000 +0200
> @@ -788,7 +788,7 @@
> int options; /* User-settable misc. driver options. */
> unsigned int media_override:4, /* Passed-in media type. */
> default_media:4, /* Read from the EEPROM/Wn3_Config. */
> - full_duplex:1, force_fd:1, autoselect:1,
> + full_duplex:1, autoselect:1,
> bus_master:1, /* Vortex can only do a fragment bus-m. */
> full_bus_master_tx:1, full_bus_master_rx:2, /* Boomerang */
> flow_ctrl:1, /* Use 802.3x flow control (PAUSE only) */
> @@ -1633,12 +1633,6 @@
> ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ?
> 0x100 : 0),
> ioaddr + Wn3_MAC_Ctrl);
> -
> - issue_and_wait(dev, TxReset);
> - /*
> - * Don't reset the PHY - that upsets autonegotiation during DHCP operations.
> - */
> - issue_and_wait(dev, RxReset|0x04);
> }
>
> static void vortex_check_media(struct net_device *dev, unsigned int init)
> @@ -1663,7 +1657,7 @@
> struct vortex_private *vp = netdev_priv(dev);
> void __iomem *ioaddr = vp->ioaddr;
> unsigned int config;
> - int i;
> + int i, mii_reg1, mii_reg5;
>
> if (VORTEX_PCI(vp)) {
> pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */
> @@ -1723,14 +1717,23 @@
> printk(KERN_DEBUG "vortex_up(): writing 0x%x to InternalConfig\n", config);
> iowrite32(config, ioaddr + Wn3_Config);
>
> - netif_carrier_off(dev);
> if (dev->if_port == XCVR_MII || dev->if_port == XCVR_NWAY) {
> EL3WINDOW(4);
> + mii_reg1 = mdio_read(dev, vp->phys[0], MII_BMSR);
> + mii_reg5 = mdio_read(dev, vp->phys[0], MII_LPA);
> + vp->partner_flow_ctrl = ((mii_reg5 & 0x0400) != 0);
> +
> vortex_check_media(dev, 1);
> }
> else
> vortex_set_duplex(dev);
>
> + issue_and_wait(dev, TxReset);
> + /*
> + * Don't reset the PHY - that upsets autonegotiation during DHCP operations.
> + */
> + issue_and_wait(dev, RxReset|0x04);
> +
>
> iowrite16(SetStatusEnb | 0x00, ioaddr + EL3_CMD);
>
>
Applied to a fresh git18, all looks good.
--
Pete Clements