This article explains how to resolve a read‑error–related failure that generates an excessive number of logs for a port.
The device began flooding the logs with repeated error messages for a read failure on ge-0/0/2 without a detectable initiating factor:
Mar 24 12:30:03 user fpc0 DCBCM[ge-0/0/2]: dcbcm_xcvr_phy_mdio_sgmii_lnk_op - Failed to MDIO read: ifd = 663 ge-0/0/2 phy_addr = 2 phy_reg = 17
Mar 24 12:30:03 user fpc0 ala88e1111_reg_read: Failed (1000) to read register phy_addr 0x2, reg 0x11
Mar 24 12:30:03 user fpc0 Fails in function ala88e1111_get_link_status
Mar 24 12:30:03 user fpc0 DCBCM [ge-0/0/2]: Failed to get phy layer link status, err(1000)
Mar 24 12:30:03 user fpc0 DCBCM[ge-0/0/2]: Link information get failed
Mar 24 12:30:04 user fpc0 TVP_READ_PHY_PORT_FAILURE: FAILED to read the phy for port: 2 length: 2
Mar 24 12:30:04 user last message repeated 8 times
Mar 24 12:30:04 user fpc0 DCBCM[ge-0/0/2]: Failed to read XCVR phy at i2c_dev:2 reg:11 failed... giving up!
Mar 24 12:30:04 user fpc0 DCBCM[ge-0/0/2]: dcbcm_xcvr_phy_mdio_sgmii_lnk_op - Failed to MDIO read: ifd = 663 ge-0/0/2 phy_addr = 2 phy_reg = 17
Mar 24 12:30:04 user fpc0 ala88e1111_reg_read: Failed (1000) to read register phy_addr 0x2, reg 0x11
Mar 24 12:30:04 user fpc0 Fails in function ala88e1111_get_link_status
Mar 24 12:30:04 user fpc0 DCBCM [ge-0/0/2]: Failed to get phy layer link status, err(1000)
Mar 24 12:30:04 user fpc0 DCBCM[ge-0/0/2]: Link information get failed
Mar 24 12:30:05 user fpc0 TVP_READ_PHY_PORT_FAILURE: FAILED to read the phy for port: 2 length: 2
Mar 24 12:30:05 user last message repeated 8 times
Mar 24 12:30:05 user fpc0 DCBCM[ge-0/0/2]: Failed to read XCVR phy at i2c_dev:2 reg:11 failed... giving up!
Mar 24 12:30:05 user fpc0 DCBCM[ge-0/0/2]: dcbcm_xcvr_phy_mdio_sgmii_lnk_op - Failed to MDIO read: ifd = 663 ge-0/0/2 phy_addr = 2 phy_reg = 17
Mar 24 12:30:05 user fpc0 ala88e1111_reg_read: Failed (1000) to read register phy_addr 0x2, reg 0x11
Mar 24 12:30:05 user fpc0 Fails in function ala88e1111_get_link_status
Mar 24 12:30:05 user fpc0 DCBCM [ge-0/0/2]: Failed to get phy layer link status, err(1000)
Mar 24 12:30:05 user fpc0 DCBCM[ge-0/0/2]: Link information get failed
Mar 24 12:30:06 user fpc0 TVP_READ_PHY_PORT_FAILURE: FAILED to read the phy for port: 2 length: 2
Mar 24 12:30:06 user last message repeated 8 times
Mar 24 12:30:06 user fpc0 DCBCM[ge-0/0/2]: Failed to read XCVR phy at i2c_dev:2 reg:11 failed... giving up!
In this scenario, the device is generating logs on a port that has nothing connected—only the optic is inserted without any cable and the chassis is recognizing the optic under the "> show chassis hardware":
root@user> show chassis hardware detail no-forwarding
Hardware inventory:
Item Version Part number Serial number Description
Chassis XXXXXXXXXXXX Virtual Chassis
Routing Engine 0 BUILTIN BUILTIN RE-QFX5120-48Y-8C
FPC 0 REV 16 650-083242 XXXXXXXXXXXX JNP48Y8C-CHAS
CPU BUILTIN BUILTIN FPC CPU
PIC 0 BUILTIN BUILTIN 48x25G-8x100G
Xcvr 2 REV 01 740-013111 XXXXXXXXXXXX SFP-T
The interface remains both Administratively and Physically down:
Physical interface: ge-0/0/2, Administratively down, Physical link is Down
First, We need to rule out any potential hardware issues between the transceiver that remains plugged in and the chassis itself or any cosmetic errors. On this scenario, even though there is no cable connected and the interface is both Administratively and Physically down, the PFE still has to perform some programming to recognize the transceiver and be listed under "> show chassis hardware" before it can be fully operational. Please follow this steps:
1.Try logically disabling the optic from the chassis. This prevents the system from attempting to program it. Then, check whether the logs stop. To perform this actions, you can run the following commands using the affected port number:
root@user> start shell
% vty fpc0
TFXPC0(user vty)# set cmqfx xcvr remove pic 0 port 2 > Remove port ge-0/0/2 from cmqfx
TFXPC0(user vty)# set cmqfx xcvr insert pic 0 port 2 > Insert port ge-0/0/2 on cmqfx
2.If possible, you can also Physically remove the transceiver from the chassis and check whether the logs stop.
3.If the logs persist, insert another optic into the chassis and verify whether the logs are absent with the spare optic. If the messages disappear, this points to the optic itself as the source of the problem.
4.If the issue remains even after these steps, try rebooting the device to see if the logs clear.