Description

With QFX5100, you may see the log messages indicating multiple daemons such as overlayd, dot1xd and vccpd running into JTASK_SCHED_SLIP_KEVENT error. However customer is not running any of these protocols and hence there is no service impact.

 

Aug 16 04:25:46 qfx5100-lab dot1xd[12082]: %DAEMON-3-JTASK_SCHED_SLIP_KEVENT: 5 sec 82989 usec kevent block

Aug 16 04:25:47 qfx5100-lab vccpd[11841]: %DAEMON-3-JTASK_SCHED_SLIP_KEVENT: 5 sec 82980 usec kevent block

Aug 16 04:25:49 qfx5100-lab overlayd[12093]: %DAEMON-3-JTASK_SCHED_SLIP_KEVENT: 5 sec 88332 usec kevent block

Symptoms

Unusual CPU spikes on the device causes overlayd, vccpd and dot1xd processes to have scheduler slips.

Solution



These scheduler slips are seen in high CPU conditions. Since the customer is not running these protocols (Virtual-chassis or dot1x), there is no service impact reported. However knowing which process is causing the CPU spike around the time of these scheduler slip logs would help us understand more around this and work towards the root cause.

 

To capture the output of the system processes periodically, run the below script on the qfx5100 device. The script will let us know which process is consuming high CPU. We can let the script run for at least 15 mins in high CPU instances. This wouldn't have any additional impact on the device and will just capture the output of processes consuming highest amount of CPU. Once the script is stopped, share the file with JTAC

 

Create a bash script file with the below script.

#!/bin/bash

while true

do

  date; top -S -b -m cpu

  sleep 1

done

 

-- Copy the script file to /var/tmp/ directory.

-- Start logging the terminal session.
 

>start shell user root

root% cd /var/tmp/

root% sh top.sh


From the output file, figure out which process is spiking the CPU which in turn causes scheduler slips and work towards RCA.

There are no known triggers yet for the issue. Share the script output file to JTAC.

However a reboot or a power drain of the device, fixes the issue and is the only known workaround at the moment. After the reboot, the scheduler slip logs are no longer seen on the device.

Modification History

2023-08-30 - Initial Publication
2024-07-31 - Visibility modified