Print

[PhilHands]

Hi,

I'm trying to get some OpenRDs to work at a site that has all their ethernet switches fixed at 100FD.  If I leave the OpenRD auto-negotiating it settles on 100 Half-Duplex, with inevitable packet loss due to the two ends not agreeing about duplex.

I've seen mention of a Marvel specific mv_eth_tool but I get the impression that this is tied to a particular kernel, whereas I'm needing to run Debian Squeeze, so could do with something that woks with Debian's recent default kernels -- I'd be happy with even more recent kernels, as they will eventually get into squeeze-backports at least, but tying myself to an obsolete kernel is unsupportable.

Using ethtool, thus:

  ethtool -s eth0 autoneg off speed 100 duplex full advertise 0x008

leaves the switch (set to autoneg=off, fixed 100/full) thinking the link is up and running 100/full while the OpenRD port activity lights flash and ethtool reports 100/full but no link detected. Ping returns Destination Host Unreachable.

Any suggestions gratefully received.

Cheers, Phil.

[Confusticated]

Only one stupid one:
You did remember to un-plug & re-plug the network cable after running the command ?

[PhilHands]

I'd not done that, as in fact the machines exhibiting this problem are in London, while I'm in Berlin ;-)

Having asked someone nearer to the machine to give it a try, it didn't help. He seems to have tried all combinations of autoneg on and off, and speed/duplex settings, to no avail.

Have you had success trying that in this circumstance?  I'd have thought that if the driver is even slightly sensible it would force a renegotiation on changes (although I can imagine that pulling the cable might help if the switch was particularly brain-damaged).

Of course, if pulling cables out were required, it would mean that the machines would be useless, since they'd probably come up in the wrong mode, then get set to the right mode by ethtool, and then be sitting there uselessly waiting for someone to come round and fiddle with the cable.

Cheers, Phil.

[superpat]

Hi Phil,

You do not say which model openrd and which uboot and kernel.

There was a problem with  HD / FD  on the early shipped Utimates  Taken from the Openrd.org forum:-

From: cantanko <[email protected]>
Date: Wed, 2 Jun 2010 15:26:15 -0700 (PDT)
Local: Wed, Jun 2 2010 10:26 pm
Subject: Re: OpenRd Ultimate First impressions.
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Additional - the ethernet adaptors are detected and the MAC addresses
are correct, however the link is misdetected:

MV-643xx 10/100/1000 ethernet driver version
1.4
mv643xx_eth smi:
probed
net eth0: port 0 with MAC address 00:50:43:01:54:a4
eth0: link up, 10Mb/sec, half duplex, flow control disabled

This is interesting as it's connected to a gigabit full duplex
switch :-)

After the updated uBoot image, uBoot also correctly identifies the
network as gigabit and uses it quite happily to load the kernel via
TFTP.

Cheers,
Harry

      
cantanko      
View profile 
OK - managed to fix Ethernet: The PHY addresses in arch/arm/mach-kirkwood/openrd_client-setup.c need changing - new lines are: static struct mv643xx_eth_platform_data openrd_client_ge00_data = {         .phy_addr       = MV643XX_ETH_PHY_ADDR(0), }; static struct mv643xx_eth_platform_data openrd_client_ge01_data = {         .phy_addr       = MV643XX_ETH_PHY_ADDR(1), }; Cheers, Harry
    More options Jun 3 2010, 1:04 am
From: cantanko <[email protected]>
Date: Wed, 2 Jun 2010 18:04:20 -0700 (PDT)
Local: Thurs, Jun 3 2010 1:04 am
Subject: Re: OpenRd Ultimate First impressions.
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
OK - managed to fix Ethernet:

The PHY addresses in arch/arm/mach-kirkwood/openrd_client-setup.c need
changing - new lines are:

static struct mv643xx_eth_platform_data openrd_client_ge00_data = {
        .phy_addr       = MV643XX_ETH_PHY_ADDR(0),

};

static struct mv643xx_eth_platform_data openrd_client_ge01_data = {
        .phy_addr       = MV643XX_ETH_PHY_ADDR(1),

};

Cheers,
Harry

I don't know whether this is applicable to your problem

cheers

P

[Confusticated]

@superpat,
Thanks for your post, I hadn't even considered u-boot.

Date: Wed, 2 Jun 2010 18:04:20 -0700 (PDT)
Local: Thurs, Jun 3 2010 1:04 am
Subject: Re: OpenRd Ultimate First impressions.

Is there any value in checking that the u-boot compile date is later than this ?

@Phil

Have you had success trying that in this circumstance?

Unfortunately not with (any of) the plug specifically.

brain-damaged

I have had a long relationship with networks, and been bitten enough times to now know to trust nothing until it has been proved.
Not even to trust devices to reset themselves properly.

asked someone nearer to the machine

Been there, depended on this, the character of the guy on the other end of the phone is critical.
You are better of with a 'dumb monkey' (no insult intended) than a wannabe 'sysop'.
The monkey will do exactly what you ask him to do (just don't make any assumptions in your instructions), the wannabe will do what he thinks he knows better.
I was very lucky, I had experienced peers I knew personally (I trained some of them) and could trust.

I would take it back to basics, put a tester on the exact same cabling between the switch to plug (incl any patch leads) to prove it sound and not crossed\rolled.
Then take an existing bit of working network kit and hang it off the end, I would want to see that work before I blamed the plug.

Managed switches can be a nightmare (especially when someone else does the management and filters MAC addresses without telling you
Not relevant to the 'link' issue but worth considering, if they manage their switches, they may also be using VLAN's.

Can you find out the make and model of the switch that the plug is being connected to ?
Don't assume anything is the only advice I can give, sorry I cant be any more help than that.

EDIT: been playing with mii-tool & ethtool on a DreamPlug, whenever I disable autonegotiation I cannot get the interface to receive or transmit.
'ifconfig sais the interface is up, mii-tool reports link ok, ethtool reports link down.

[Confusticated]

I have found a bodge to get round the problem

ethtool -s eth1 speed 100 duplex full autoneg off
devmem2 0xf107643c b 3

The 'devmem2' command forces the link up by poking the Port Serial Control0 (PSC0) Register to set the ForceLinkPass bit (bit 1), then everything 'just works'(tm)
For the eth0 port, the register address is 0xf107243c.

NB this is on the DreamPlug

[PhilHands]

Hi Phil,

You do not say which model openrd and which uboot and kernel.

OpenRD-Ultimates as bought in the last 3 months, or so.

The u-boot is a very slightly tweaked version of this:

  http://anonscm.debian.org/gitweb/?p=collab-maint/u-boot.git;a=commit;h=7e11147bc09deb3913297fa9d0df0ddda8441c27

  i.e. Debian's 2011.06-3 packaged version.

the only change being:

Code: [Select]

--- a/drivers/block/mvsata_ide.c
+++ b/drivers/block/mvsata_ide.c
@@ -164,8 +164,8 @@ int ide_preinit(void)
        status = mvsata_ide_initialize_port(
                (struct mvsata_port_registers *)
                (CONFIG_SYS_ATA_BASE_ADDR + CONFIG_SYS_ATA_IDE1_OFFSET));
-       if (status)
-               return status;
+/*     if (status)
+               return status; */
 #endif
        /* return success if all ports initializations succeeded */
        return MVSATA_STATUS_OK;

which seems to be needed to get it to boot from the internal SATA.

The kernel is as shipped by Debian in the linux-image-2.6.32-5-kirkwood package, version 2.6.32-38.

There was a problem with  HD / FD  on the early shipped Utimates  Taken from the Openrd.org forum:-

...

I don't know whether this is applicable to your problem

I don't think three months old counts as "early", sadly.

Cheers, Phil.

[Confusticated]

For those who like patches

Code: [Select]

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 194a031..f614de6 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -1487,6 +1487,8 @@ static int
 mv643xx_eth_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
        struct mv643xx_eth_private *mp = netdev_priv(dev);
+       int ret;
+       __u8 autoneg;

        if (mp->phy == NULL)
                return -EINVAL;
@@ -1496,7 +1498,20 @@ mv643xx_eth_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
         */
        cmd->advertising &= ~ADVERTISED_1000baseT_Half;

-       return phy_ethtool_sset(mp->phy, cmd);
+       autoneg = mp->phy->autoneg;
+       ret = phy_ethtool_sset(mp->phy, cmd);
+       if (autoneg != mp->phy->autoneg && netif_running(mp->dev)) {
+               u32 pscr;
+
+               pscr = rdlp(mp, PORT_SERIAL_CONTROL);
+               if (mp->phy->autoneg == AUTONEG_DISABLE)
+                       pscr |= FORCE_LINK_PASS;
+               else
+                       pscr &= ~FORCE_LINK_PASS;
+               wrlp(mp, PORT_SERIAL_CONTROL, pscr);
+       }
+
+       return ret;
 }

 static void mv643xx_eth_get_drvinfo(struct net_device *dev,
@@ -2227,7 +2242,7 @@ static void port_start(struct mv643xx_eth_private *mp)
        wrlp(mp, PORT_SERIAL_CONTROL, pscr);

        pscr |= DO_NOT_FORCE_LINK_FAIL;
-       if (mp->phy == NULL)
+       if (mp->phy == NULL || mp->phy->autoneg == AUTONEG_DISABLE)
                pscr |= FORCE_LINK_PASS;
        wrlp(mp, PORT_SERIAL_CONTROL, pscr);

@@ -2433,11 +2448,26 @@ static int mv643xx_eth_stop(struct net_device *dev)
 static int mv643xx_eth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 {
        struct mv643xx_eth_private *mp = netdev_priv(dev);
+       int ret;
+       __u8 autoneg;

-       if (mp->phy != NULL)
-               return phy_mii_ioctl(mp->phy, ifr, cmd);
+       if (mp->phy == NULL)
+               return -EOPNOTSUPP;

-       return -EOPNOTSUPP;
+       autoneg = mp->phy->autoneg;
+       ret = phy_mii_ioctl(mp->phy, ifr, cmd);
+       if (autoneg != mp->phy->autoneg && netif_running(mp->dev)) {
+               u32 pscr;
+
+               pscr = rdlp(mp, PORT_SERIAL_CONTROL);
+               if (mp->phy->autoneg == AUTONEG_DISABLE)
+                       pscr |= FORCE_LINK_PASS;
+               else
+                       pscr &= ~FORCE_LINK_PASS;
+               wrlp(mp, PORT_SERIAL_CONTROL, pscr);
+       }
+
+       return ret;
 }

 static int mv643xx_eth_change_mtu(struct net_device *dev, int new_mtu)
--
1.7.6.4

EDIT: Give yourself five brownie points if you can spot the deliberate mistake (like all good puzzles, the answer is given below).

[leighbb]

EDIT: Give yourself five brownie points if you can spot the deliberate mistake

No brownie points for me but does that mean we get a new patch? :-)

[Confusticated]

I wouldn't trust it, I know where it came from

The patch above hasn't been fully tested yet, and as I have no real way to properly test with autonegotiation disabled it is not something I can reasonably do (anyone want to donate a managed switch ?).

Code: [Select]

-       if (mp->phy == NULL)
+       if (mp->phy == NULL || mp->phy->autoneg == AUTONEG_DISABLE)
                pscr |= FORCE_LINK_PASS;
should have added to it

Code: [Select]

         else if (mp->phy->autoneg == AUTONEG_ENABLE)
                pscr &= ~FORCE_LINK_PASS;
to turn off FORCE_LINK_PASS should it unnecessarily be already enabled when the interface is started.
An unlikely situation (eg a phy'less interface suddenly acquires one), but belt'n'braces is always best.

[PhilHands]

Ah, and there was me thinking that the deliberate mistake was not mentioning what the patch is supposed to apply to ;-)

I've had a rummage in both u-boot and linux kernel trees, and the versions I've checked don't appear to have that file, so a hint would be nice.

Cheers, Phil.

[Confusticated]

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c

I did a pull of Linux just before messing with it on

Reply #7 on: 17 November 2011, 01:01:49 am »

but it should still apply cleanly (at the time of this post

[PhilHands]

Ah, fair enough - this is the reason I ask:

Code: [Select]

[email protected]:~/src/openrd/linux-2.6-2.6.32$ ls -l drivers/net/ethernet/marvell/mv643xx_eth.c
ls: cannot access drivers/net/ethernet/marvell/mv643xx_eth.c: No such file or directory
[email protected]:~/src/openrd/linux-2.6-2.6.32$ ls -l drivers/net/ethernet
ls: cannot access drivers/net/ethernet: No such file or directory
[email protected]:~/src/openrd/linux-2.6-2.6.32$ find . -name mv643\*
./include/linux/mv643xx.h
./include/linux/mv643xx_eth.h
./include/linux/mv643xx_i2c.h
./drivers/net/mv643xx_eth.c
[email protected]:~/src/openrd/linux-2.6-2.6.32$ cd drivers/net/
[email protected]:~/src/openrd/linux-2.6-2.6.32/drivers/net$ patch -p5 < ../../../Confusticated.patch
patching file mv643xx_eth.c
Hunk #1 FAILED at 1487.
Hunk #2 FAILED at 1496.
Hunk #3 FAILED at 2227.
Hunk #4 FAILED at 2433.
4 out of 4 hunks FAILED -- saving rejects to file mv643xx_eth.c.rej
[email protected]:~/src/openrd/linux-2.6-2.6.32/drivers/net$

UPDATED:
I notice that most of that patch failing to apply was simply TAB vs. spaces cut&paste breakage -- it actually applied fairly cleanly, so just in case it's of some use to others, here's the patch I now have against the linux-2.6-2.6.32 source (as packaged for Debian):

Code: [Select]

--- xxx/linux-2.6-2.6.32/drivers/net/mv643xx_eth.c 2009-12-03 03:51:21.000000000 +0000
+++ linux-2.6-2.6.32/drivers/net/mv643xx_eth.c 2011-11-29 11:09:44.000000000 +0000
@@ -1477,6 +1477,8 @@
 mv643xx_eth_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
  struct mv643xx_eth_private *mp = netdev_priv(dev);
+ int ret;
+ __u8 autoneg;
 
  if (mp->phy == NULL)
  return -EINVAL;
@@ -1486,7 +1488,20 @@
  */
  cmd->advertising &= ~ADVERTISED_1000baseT_Half;
 
- return phy_ethtool_sset(mp->phy, cmd);
+ autoneg = mp->phy->autoneg;
+ ret = phy_ethtool_sset(mp->phy, cmd);
+ if (autoneg != mp->phy->autoneg && netif_running(mp->dev)) {
+ u32 pscr;
+
+ pscr = rdlp(mp, PORT_SERIAL_CONTROL);
+ if (mp->phy->autoneg == AUTONEG_DISABLE)
+ pscr |= FORCE_LINK_PASS;
+ else
+ pscr &= ~FORCE_LINK_PASS;
+ wrlp(mp, PORT_SERIAL_CONTROL, pscr);
+ }
+
+ return ret;
 }
 
 static void mv643xx_eth_get_drvinfo(struct net_device *dev,
@@ -2240,8 +2255,10 @@
  wrlp(mp, PORT_SERIAL_CONTROL, pscr);
 
  pscr |= DO_NOT_FORCE_LINK_FAIL;
- if (mp->phy == NULL)
+ if (mp->phy == NULL || mp->phy->autoneg == AUTONEG_DISABLE)
  pscr |= FORCE_LINK_PASS;
+ else if (mp->phy->autoneg == AUTONEG_ENABLE)
+ pscr &= ~FORCE_LINK_PASS;
  wrlp(mp, PORT_SERIAL_CONTROL, pscr);
 
  /*
@@ -2446,11 +2463,26 @@
 static int mv643xx_eth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 {
  struct mv643xx_eth_private *mp = netdev_priv(dev);
+ int ret;
+ __u8 autoneg;
 
- if (mp->phy != NULL)
- return phy_mii_ioctl(mp->phy, if_mii(ifr), cmd);
+ if (mp->phy == NULL)
+ return -EOPNOTSUPP;
 
- return -EOPNOTSUPP;
+ autoneg = mp->phy->autoneg;
+ ret = phy_mii_ioctl(mp->phy, if_mii(ifr), cmd);
+ if (autoneg != mp->phy->autoneg && netif_running(mp->dev)) {
+ u32 pscr;
+
+ pscr = rdlp(mp, PORT_SERIAL_CONTROL);
+ if (mp->phy->autoneg == AUTONEG_DISABLE)
+ pscr |= FORCE_LINK_PASS;
+ else
+ pscr &= ~FORCE_LINK_PASS;
+ wrlp(mp, PORT_SERIAL_CONTROL, pscr);
+ }
+
+ return ret;
 }
 
 static int mv643xx_eth_change_mtu(struct net_device *dev, int new_mtu)

which is only different in that it also includes the fix for the "deliberate mistake" and also preserves that version of the source's use of if_mii(ifr),

I'll give that a test now to see if it fixes the problem.

Thanks for the hints so far :-)

[srinivasm2010]

testing here

Hi Phil,

You do not say which model openrd and which uboot and kernel.

There was a problem with  HD / FD  on the early shipped Utimates  Taken from the Openrd.org forum:-

From: cantanko <[email protected]>
Date: Wed, 2 Jun 2010 15:26:15 -0700 (PDT)
Local: Wed, Jun 2 2010 10:26 pm
Subject: Re: OpenRd Ultimate First impressions.
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Additional - the ethernet adaptors are detected and the MAC addresses
are correct, however the link is misdetected:

MV-643xx 10/100/1000 ethernet driver version
1.4
mv643xx_eth smi:
probed
net eth0: port 0 with MAC address 00:50:43:01:54:a4
eth0: link up, 10Mb/sec, half duplex, flow control disabled

This is interesting as it's connected to a gigabit full duplex
switch :-)

After the updated uBoot image, uBoot also correctly identifies the
network as gigabit and uses it quite happily to load the kernel via
TFTP.

Cheers,
Harry

      
cantanko      
View profile  
OK - managed to fix Ethernet: The PHY addresses in arch/arm/mach-kirkwood/openrd_client-setup.c need changing - new lines are: static struct mv643xx_eth_platform_data openrd_client_ge00_data = {         .phy_addr       = MV643XX_ETH_PHY_ADDR(0), }; static struct mv643xx_eth_platform_data openrd_client_ge01_data = {         .phy_addr       = MV643XX_ETH_PHY_ADDR(1), }; Cheers, Harry
    More options Jun 3 2010, 1:04 am
From: cantanko <[email protected]>
Date: Wed, 2 Jun 2010 18:04:20 -0700 (PDT)
Local: Thurs, Jun 3 2010 1:04 am
Subject: Re: OpenRd Ultimate First impressions.
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
OK - managed to fix Ethernet:

The PHY addresses in arch/arm/mach-kirkwood/openrd_client-setup.c need
changing - new lines are:

static struct mv643xx_eth_platform_data openrd_client_ge00_data = {
        .phy_addr       = MV643XX_ETH_PHY_ADDR(0),

};

static struct mv643xx_eth_platform_data openrd_client_ge01_data = {
        .phy_addr       = MV643XX_ETH_PHY_ADDR(1),

};

Cheers,
Harry

I don't know whether this is applicable to your problem

cheers

P

[srinivasm2010]

testing here

Hi Phil,

You do not say which model openrd and which uboot and kernel.

There was a problem with  HD / FD  on the early shipped Utimates  Taken from the Openrd.org forum:-

this is testing message for HD/FD.

From: cantanko <[email protected]>
Date: Wed, 2 Jun 2010 15:26:15 -0700 (PDT)
Local: Wed, Jun 2 2010 10:26 pm
Subject: Re: OpenRd Ultimate First impressions.
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Additional - the ethernet adaptors are detected and the MAC addresses
are correct, however the link is misdetected:

MV-643xx 10/100/1000 ethernet driver version
1.4
mv643xx_eth smi:
probed
net eth0: port 0 with MAC address 00:50:43:01:54:a4
eth0: link up, 10Mb/sec, half duplex, flow control disabled

This is interesting as it's connected to a gigabit full duplex
switch :-)

After the updated uBoot image, uBoot also correctly identifies the
network as gigabit and uses it quite happily to load the kernel via
TFTP.

Cheers,
Harry

      
cantanko      
View profile  
OK - managed to fix Ethernet: The PHY addresses in arch/arm/mach-kirkwood/openrd_client-setup.c need changing - new lines are: static struct mv643xx_eth_platform_data openrd_client_ge00_data = {         .phy_addr       = MV643XX_ETH_PHY_ADDR(0), }; static struct mv643xx_eth_platform_data openrd_client_ge01_data = {         .phy_addr       = MV643XX_ETH_PHY_ADDR(1), }; Cheers, Harry
    More options Jun 3 2010, 1:04 am
From: cantanko <[email protected]>
Date: Wed, 2 Jun 2010 18:04:20 -0700 (PDT)
Local: Thurs, Jun 3 2010 1:04 am
Subject: Re: OpenRd Ultimate First impressions.
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
OK - managed to fix Ethernet:

The PHY addresses in arch/arm/mach-kirkwood/openrd_client-setup.c need
changing - new lines are:

static struct mv643xx_eth_platform_data openrd_client_ge00_data = {
        .phy_addr       = MV643XX_ETH_PHY_ADDR(0),

};

static struct mv643xx_eth_platform_data openrd_client_ge01_data = {
        .phy_addr       = MV643XX_ETH_PHY_ADDR(1),

};

Cheers,
Harry

I don't know whether this is applicable to your problem

cheers

P