help about fec problem

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

help about fec problem

9,662 Views
mehmet
Contributor I

Hi all,

I have a big problem that I couldn't understand. I have i.mx28 evk. I use default sb linux with sd card. I want to up eth0 and mount my host pc with nfs. 

 

 

ifconfig eth0 122.122.122.149 netmask 255.255.255.0

eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
root@freescale ~$ PHY: 0:00 - Link is Up - 100/Full

 

mount -t nfs -o nolock 122.122.122.141:/srv/nfs/share /mnt

 

Sometimes mounting is ok, sometimes it lates, but sometimes it cannot be mounted. 

Mostly I see act led flashes very fast but there is no activity. I check with ifconfig, there is no increase on any packets and on ethernet switch act. led doesn't flash.

 

When I couldn't mount nfs, I tried down up like below and got error response;

ifconfig eth0 down

ifconfig eth0 up

FEC: MDIO read timeout

eth0: could not attach to PHY

ifconfig: SIOCSIFFLAGS: Connection timeout

 

 

Thanks.

Mehmet

Tags (1)
0 Kudos
Reply
19 Replies

4,864 Views
PauliM
Contributor I

Thanks. On a quick test commenting the two lines seems to work. Sad to see there is no official fix for this.

 

Regards

Pauli 

0 Kudos
Reply

4,864 Views
DanieleDall_Acq
NXP Employee
NXP Employee

The patch :)

4,864 Views
CraigMcQueen
Contributor III

Daniele Dall'Acqua wrote:

The patch

Can anyone point me to documentation of how to integrate this patch into LTIB kernel builds?

0 Kudos
Reply

4,864 Views
DanieleDall_Acq
NXP Employee
NXP Employee

HI

Actually I've fixed the "Led Blinking"  problem (which occurs just on some networks) using the attached patch. For my understanding the PHY was continuosly processing speed auto negotiation packets, preventing it to work properly.

I've implemented this on top of the above mentioned patch.

Ciao 

  --daniele

4,864 Views
Michael_McTerna
Contributor I

Pauli M said:

Hi, Just experienced this on a MX28EVK board running 2.6.35 kernel from freescale. What is the preferred way to fix or get around this problem?

Does the patch mentioned earlier work and if yes, how should it be applied?

I'm not sure what the preferred way is, but I removed the following lines from drivers/net/fec.c in fec_stop(), and this allows me to ifup/ifdown the net device repeatedly without problem on my i.MX28 with linux 2.6.38:

  /* Whack a reset.  We should wait for this. */
  writel(1, fep->hwp + FEC_ECNTRL);
  udelay(10);

0 Kudos
Reply

4,864 Views
PauliM
Contributor I

Hi, Just experienced this on a MX28EVK board running 2.6.35 kernel from freescale. What is the preferred way to fix or get around this problem?

Does the patch mentioned earlier work and if yes, how should it be applied?

 

Thanks

Pauli 

0 Kudos
Reply

4,864 Views
PeterKardos
Contributor I

I don't what's the current status of this issue...

Please also make sure you have a MAC address assigned to your interface. I've had a similar experience with our project with i.mx253 + LAN8700(RMII). No other "tweaks" were necessary, everything runs out-of-box, with kernel 2.6.39.4...

0 Kudos
Reply

4,864 Views
jackyliu
NXP Employee
NXP Employee

NFS use UDP as its default protocol.
UDP is not stable.
You can use "-o tcp" when mount, so it will use tcp to make connection. TCP is a stable connection.

0 Kudos
Reply

4,864 Views
Michael_McTerna
Contributor I

Rogerio Pimentel said:

I got the same problem when testing another i.MX platform. It was solved by increasing the MDIO timeout on file linux/drivers/fec.c (The patch was already submitted on Freescale and Mainline repositories).

On this file, change the line:

#define FEC_MII_TIMEOUT        1000

to

#define FEC_MII_TIMEOUT        40000

Doesn't make sense to leave the timeout in 1000 usecs because the time resolution is 10ms. On my tests 40ms seems to work fine with the PHY I have used.

Let us know about your results.

I tested the timeout change on my MX28 and it doesn't fix the original problem, which I think is actually caused because the MII interface doesn't get sufficiently re-initialised after the reset in fec_stop() since fec_enet_interrupt() then never gets the FEC_ENET_MII & hence the similar but different timeout.


I also checked and FEC_MII_TIMEOUT is passed through usecs_to_jiffies().  I tested this and found it sensibly rounds up to 1 jiffy = 10ms on my board which seems plenty long enough in normal operation.

I haven't checked again, so maybe the problem's already been fixed by Freescale.  It's certainly been around on the MX28 for long enough:

http://forums.freescale.com/t5/i-MX-Microprocessors/iMX28-eth0-Could-not-attach-to-PHY/m-p/65649

0 Kudos
Reply

4,863 Views
rogerio_silva
NXP Employee
NXP Employee

I got the same problem when testing another i.MX platform. It was solved by increasing the MDIO timeout on file linux/drivers/fec.c (The patch was already submitted on Freescale and Mainline repositories).

On this file, change the line:

#define FEC_MII_TIMEOUT        1000

to

#define FEC_MII_TIMEOUT        40000

Doesn't make sense to leave the timeout in 1000 usecs because the time resolution is 10ms. On my tests 40ms seems to work fine with the PHY I have used.

Let us know about your results.

Rgds,

Rogerio Pimentel

0 Kudos
Reply

4,864 Views
Michael_McTerna
Contributor I

Actually on a Karo TX28 module.

0 Kudos
Reply

4,864 Views
YiLi
Contributor I

Which revision of i.mx28 EVK board are you seeing this issue?

0 Kudos
Reply

4,864 Views
Michael_McTerna
Contributor I

I took a look in the Freescale git tree on Friday, and it seemed that the bug was still there...

 

As pointed out elsewhere the 'fix' is a one liner in drivers/net/fec.c in fec_stop() - just remove the following lines:

  /* Whack a reset.  We should wait for this. */
  writel(1, fep->hwp + FEC_ECNTRL);
  udelay(10);

 

It would be nice if this could get fixed on mainline as the bug has been around for a long time now.

0 Kudos
Reply

4,864 Views
SamGandhi
Contributor II

Has this problem being fixed. We are running 3.1.0-rc5 kernel and see this often.

 

if one does if down eth0 and then if up eth0 then you see message:

FEC: MDIO read timeout
eth0: could not attach to PHY
ifconfig: SIOCSIFFLAGS: Connection timed out

 

Also when nfs booting sometimes the TX LED on the connector flashes really fast but actually board doesn't seem to be do rx/tx any packets.

 

[ BTW are freescale folks on imxcommunity.org? ]

0 Kudos
Reply

4,864 Views
BryanJI
Contributor I

I also use nfs, it just fine. Maybe you need to check your working network.

 

For later problem, the fec has this problem. Check the solution on freescale forum.

0 Kudos
Reply

4,864 Views
wgeho
Contributor I

Hi Tim,

Thanks for your reply.

The described problem is not exactly the same.

Well, there are two problems:

  -  stopping ethernet is not working.

  -  the activity led flashes very fast but there is no activity (only happens sometimes).

 

The patch is a workaround for the first one, but there remains the second one.

However, for me it seems they are related. After calling the function fec_restart, there are no more interrupts.

0 Kudos
Reply

4,865 Views
TimWoodham
Contributor I

there is a patch for the ethernet on the 2.6.35 BSP from freescale,

check out the thread on the freescale page,

http://forums.freescale.com/t5/i-MX-Microprocessors/i-mx28-evk-network-plug-unplug-problem/m-p/75101...

0 Kudos
Reply

4,865 Views
wgeho
Contributor I

Hi all,

 

I have exactly the same problem (with or whithout nfs).  Activity led flashes very fast but there is no activity.

I was not able to get any useful information from the freescale support team.

0 Kudos
Reply

4,865 Views
mehmet
Contributor I

Hi all,

Someone should get same error. It is default images and evk. 

 

Thanks.

Mehmet

0 Kudos
Reply