This article explains the troubleshooting steps that has to be followed when we see PSM, PDM alarms on the MX2K chassis.

We might encounter the PSM & PDM on the MX2K chassis, is in CHECK state and the module is not online on the MX2K chassis.

> show chassis environment 
Class Item                           Status     Measurement
Temp  
<SNIP>
      PSM 15                         OK         25 degrees C / 77 degrees F
      PSM 16                         OK         25 degrees C / 77 degrees F
      PSM 17                         Check     
      PDM 0                          OK        
      PDM 1                          OK        
      PDM 2                          Check     
      PDM 3                          OK   

Feb 12 01:42:29 2025 MX2K alarmd[12364]: %DAEMON-4: Alarm set: PSM id=318770826, color=RED, class=CHASSIS, reason=PSM 17 INP1 Failure

This issue could have occurred, when we replace/reseat the PSM module or when the hardware goes faulty or when the inputs of the PSM were not been able to read by the PDMs and communication with the control boards are broken. 

Components & its Responsibilities:

• Power Supply Modules (PSMs): Converts input power (AC/DC) to required voltage levels.
• Power Distribution Modules (PDMs): Manage and distribute power from PSMs to system components.
• Control Board (CB): Monitors power status and communicates with PDMs for power management.

To isolate the issue is with PSM or problem on the communication to the chassis, we might follow the below steps:

1. Check the input feeds & try reseating the PSM module which is in CHECK state.

2. If the alarms persists after reseating the PSM, try connecting any other working/spare PSM module to confirm the part is faulty. 

• When the newer PSM connected is online, then the older PSM connected is faulty.
• When the newer/working PSM also in CHECK state, then the problem is not on the PSM module (We should check if the communication of the PSM is readable by the PDM and those information is passed to the control boards for power monitoring status). 

3. To confirm, if the communication of the control board is proper with its system components, we shall try RE switchover and see if the PSM is online and their communication is proper with the other control board. 

   > request chassis routing-engine master switch check (if ready, perform the switchover)

   > request chassis routing-engine master switch 

   To check the status of the PSM's execute the below commands:

   >show chassis environment | no-more

   >show chassis environment psm

   >show chassis power

•  If the PSM is online and then the alarms are cleared after performing RE switchover, then you can confirm the other CB has an issue and you shall try restarting the CB and if issue persists, replace the module with a spare.
•  If the alarms are not cleared yet, and the alarm appearing from both the CB’s, then the communication is broken between the chassisd and to the CB, which made CB to not read the PSM voltages and diagnostic results.

4. Also, cross check if the other modules on the chassis and the switch fabric have any issues by collecting the below command outputs:

>show chassis alarms

>show system alarms

>show chassis craft-interface

>show chassis fabric summary

>show chassis fabric fpcs

>show chassis fabric destinations

>show chassis fabric degradation

>show chassis fabric plane

>show chassis fabric plane-location

>show chassis sfb

>show chassis spmb

5. If no issues are found from the above outputs, then the communication between the CB and to the chassisd subsystem are to be checked. Because, the Control Board is responsible for overall chassis management, while chassisd is the software daemon that monitors and controls hardware components.

• In the 'show log messages' output, find if you see any I2C communication errors related to CB/chassisd alarms errors. 
• And when you confirm the 'chassisd process is not responding or the chassisd susbystem is not running', then you may need to 'restart chassis-control gracefully'. 

Note: 

• Restarting chassis-control could cause unexpected events on the chassis, and we might see the other FRU communication is also broken.
• Restarting chassisd control is not the recommended troubleshooting step, until you have full confirmation of the 'chassisd subsystem is not responding'.
• Also read the KB87723 [juniper.net]: https://supportportal.juniper.net/s/article/How-does-restart-chassis-control-can-impact-the-router

So at this point, we would strongly recommend you to engage JTAC on the call for confirmation and troubleshooting, before you restart the 'chassis-control' on the MX2K chassis.

KB87723 [juniper.net]: https://supportportal.juniper.net/s/article/How-does-restart-chassis-control-can-impact-the-router

KB22413 [juniper.net]: https://supportportal.juniper.net/s/article/M-MX-T-What-are-the-different-CLI-knobs-available-to-restart-chassis-control