Bridge doesn't work, after reconnect

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bridge doesn't work, after reconnect

3,309 Views
lategoodbye
Senior Contributor I

Hi,

i'm using a i.MX28 custom board with 2 different Ethernet interfaces. Both interfaces should be used as bridge by Linux bridge utils. One Ethernet interface is the buildin fec and the other is connect by spi. The board runs under Linux mainline 3.10.

Here is the problem, if i disconnect and reconnect the Ethernet cable on the buildin fec (eth0), the bridge says the port comes up, but it doesn't work. After that any traffic to the fec is okay, but traffic "through" the bridge is lost.

[  124.490653] libphy: 800f0000.etherne:00 - Link is Down

[ 124.547655] br0: port 1(eth0) entered disabled state

[  139.541973] libphy: 800f0000.etherne:00 - Link is Up - 100/Full

[  139.551246] br0: port 1(eth0) entered forwarding state

[  139.556615] br0: port 1(eth0) entered forwarding state

If i reset the board without disconnecting the cables, the bridge works.

If i force the promiscuous mode on the fec (eth0) after the reconnect, the bridge works too.

ifconfig eth0 promisc

It looks like that's a bug in the fec driver. Has anybody experienced the same problem and a useful solution?

BR Stefan

Labels (2)
0 Kudos
8 Replies

1,506 Views
lategoodbye
Senior Contributor I

I've made some research and probably found the cause of the problem.

In the case that the bridge works (link state connected since reboot) the register HW_ENET_MAC_RCR of the MX28 returns 45EE011C (PROM=1).

Then I disconnect the ethernet cable and reconnect it. After that the register returns 45EE0114 (PROM=0) and the bridge doesn't work.

If i force to enable the promiscuous mode than the register returns 45EE011C (PROM=1) and the bridge works again.

0 Kudos

1,506 Views
fabio_estevam
NXP Employee
NXP Employee

Stefan,

Is the problem present on 3.14-rc4 as well?

If so, could you please report it at netdev mailing list?

Regards,

Fabio Estevam

0 Kudos

1,506 Views
lategoodbye
Senior Contributor I

Hello Fabio,

yes the problem is reproducible on mainline 3.14-rc4. I will report the problem at netdev mailing list.

Ciao Stefan

0 Kudos

1,506 Views
lategoodbye
Senior Contributor I

Hello Fabio,

i cannot promise to get the chance testing this scenario with latest kernel release, because it's not my hardware. I will try to create a patch against 3.10 and post it here.

BR Stefan

Edit: Now here is the patch against 3.10 to fix the problem.

0 Kudos

1,506 Views
jamesbone
NXP TechSupport
NXP TechSupport

We are aware that for the official Linux BSP 2.6.35 there is a problem with the PHY ref Clock.

On MX28 EVK board, the PHY REF_CLK is from MX28 ENET_CLK which will be turn off when eth is not used.

So when ENET_CLK is on, we also need reset PHY before ENET controller is reset.

0 Kudos

1,506 Views
lategoodbye
Senior Contributor I

Hi James,

i'm using Kernel 3.10, where the fec issue should be fixed. My problem is that only broadcast packets don't work. All unicast messages work. So i do believe it's a different problem.

0 Kudos

1,506 Views
Alvin
NXP Employee
NXP Employee

Hi Wahren,

I am not sure whether it is the same case with you. Hope it can help.

https://community.freescale.com/docs/DOC-94983

Both Ethernet PHYs on MX28 EVK board share the same GPIO as their reset pin, in software the function name is mx28evk_enet_gpio_init. So any call to pdata->init() in fec.c will reset both PHY at the same time. In order to avoid such problem, you have to use 2 individual GPIO for the PHY reset.

0 Kudos

1,506 Views
lategoodbye
Senior Contributor I

Hi Songhao,

thanks for your advice, but that's a different problem. Any other ideas are welcome.

0 Kudos