DP83867IR: phy link error while autonegotiation finished

Hi Min,

I agree this is strange behavior. Could you confirm what kernel version of Linux is being used? The command 'uname -r' will display it on the terminal. 

Questions:

1. Does this issue only occur if left on for a few days, is it reproduceable?
   1. If we can recreate the issue, could we try setting Reg 0x0 = 1340? This will restart auto-negotiation.
2. I understand the recovery method, but was plugging/unplugging the cable not resolving the issue? 
3. How many boards are affected by this issue?

Regards,

Alvaro

Hi Alvaro,

thanks for your reply.The kernel version is 5.10.72

1,yes, I only found it occur when left running with ethernet wire disconnected for a few days. I think it is reproducible, it occurred 3 times. 

setting the Reg 0x0 = 1340 won't help

2, plug/unplug could not resolve this issue

3, This is a prototype board, we only have two boards here and all of them are affected by this issue.

4,I have tried to write 0x4000 and 0x8000 to register 0x1f, they all did not work.  However, at the normal scenario when link is established, after I wrote 0x8000 to register 0x1f , the phy did not restart autonegotiation progress and stop work. I have to ifconfig eth0 down and up to recover, is this the normal behaviour?

Hi Min,

How are you determining link up or down? Are we checking ethtool or expecting a terminal message? I want to check if Reg 0x1 matches what the terminal says. If ethtool says link is down but Reg 0x1 = 796D, then it is likely a software issue. If both eth tool and Reg 0x1 = 7949, then it is probably a hardware issue. 

Regards,

Alvaro

yes, we first determin it by the kernel driver log, the kernel did not run into phy interrupt, then we use ethtool and phytool, they all show that the link is down.

the reg 0x1 is 7969 while we can see the link led is on and data led is blinking. 

Hi Min,

Thank you for confirming. Can we do a register dump during a working and non-working case?

Read Registers 0x0-0x1F, 6E & 6F in the following cases:

1. Board boot-up with ethernet cable disconnected
2. Ethernet cable connected 
3. When the board is not functional

If you could collect this data in an excel file, this would make it easier for me to review.

Note that Reg 0x6e & 0x6F are extended registers, please see this FAQ for how to access them.

Regards,

Alvaro

Hi Alvaro,

I have found the reason, It is not related to the strap configuration. For the phy auto negotiation has been finished  but  wait for our device to read and clear the negotiation complete interrupt.  So the phy is in negotiation completed but link not eastablished status.  The interrupt is gpio edge-trigger and once there is a trigger that  is not dealt by the cpu, then the interrupt line would keep the level and never trigger interrupt. So I remove the ethernet gpio interrupt and turn to polling method. Then it is fixed. What do you suggest?

Hi Min,

I'm glad that you found the issue! Please confirm if I'm understanding correctly.

You are using Pin 44 as Interrupt. This is done by enabling the interrupts in Register 0x12 (MICR). You have enabled the Auto-Neg Complete Interrupt (Reg 0x12 = 0800). When the cable gets connected, the PHY completes auto-negotiation and hence bit 11 of Register 0x13 (ISR) goes high. This means the PHY asserts a Low signal on Pin 44, which is connected to your CPU. You believe that the CPU doesn't do anything with this signal, and hence gets stuck? 

If you were to configure the interrupt method again, would reading Reg 0x13 (this would clear the interrupt) fix the issue?

Do you require the interrupt? If you are okay with the polling method, why was interrupt used in the first place?

Regards,

Alvaro 

Hi Alvaro,

yes,  reading Reg 0x13 would fix this issue. after measuring the interrup signal, there is once the signal slew rate is not fast, with another incoming interrupt, the  cpu would  miss this interrupt and then  the problem occurs.

Because from our initial design, using the interrupt to tell cpu to deal with ethernet thing would be better than always asking cpu to schedule and poll the register status. 

Hi Min,

Understood, using an interrupt is always more desirable than polling. Right now it seems to me that the PHY is behaving as expected and that the issue is with the processor. Are you saying that there interrupt signal, coming from the PHY, has a slow slew rate and that this causes an issue with the processor?

Regards,

Alvaro