DSP_TIMEOUT messages indicate that the chassis CPU lost contact with a Digital Signal Processor (DSP) channel, and it reset the DSP in order to clear the problem. Generally, this reset is sufficient to resolve the problem, and no further action should be taken. If there are repeated messages that affect the same DSP IDs or similar DSP IDs, perform these steps:
Make sure you have the correct version of VCware and DSPware that matches the Cisco IOS Software version on the AS5300 Access Server. A mismatch on the Cisco IOS Software and VCware could cause the problem, so it must be ruled out first. You can verify this information by issuing the show vfc [slot number] version vcware and show version commands.
Reset the DSPs on the VFC, and check to see if the status is back to active and that there are no DSPs "asleep" on the board.
After you reset the DSPs on the VFC board, or reset the entire VFC board, make sure that the status of the DSPs is correct. You can issue the test dsp command, and then issue the show pool command to show you the status of all the DSPs. The DSPs should all be in the Free queue.
After you have reset, monitor the values of the DSP IDs over time for the AS5300 Access Server which exhibit the problem.
Analyze the DSP_TIMEOUT messages. If they re-appear nearly instantly, reseat the VFC by a power-down of the AS5300 Access Server.
Note: The AS5300 Access Server modules are not hot-swappable, and it is highly recommended that you shut down the router and restart it promptly, or go through a warm reboot through the Command-Line Interface (CLI).
If the problem continues, identify patterns in the DSP IDs found. For example, you may observe that all DSP IDs start with the same digits. Typically the first two or three digits do not change over time. If the DSP IDs follow such a pattern, you may experience a hardware failure. To verify if this is a hardware failure, swap the VFCs from slot one to slot two, and confirm that the DSP_TIMEOUT messages reference the new location of the hardware. Determine whether the problem follows the new VFC slot number or if it stays the same.
There may be more than one DSP module failure on a VFC. It is best to compile a list of DSP IDs that appear in the messages and sort it by ascending order to easily identify patterns.
If the DSP_TIMEOUT messages re-appear once you reset the VFC and reload the access server, you are likely to experience a software problem. You should escalate the case for proper debugging.
Hello everyone,We are upgrading our CUCM cluster to version 11.6 and would need to replace about 10000 phones. The phone replacement is going to happen before the upgrade of CUCM. We have more than 20 phone services configured in our CUCM cluster. Each ph...
I have IMP 11.5 in my organisation. We want to Lunach Jabber but the management is insiting of having a two factor authentication in place before we launch it. Is there any possibility of having it? Thanking for your response. regard...
I have followed the installation guide(QM all in one solution) . I have Windows Server 2012 R2 with SQL Server 2014. When I run the setup_MonRec_1151, I get "Windows cannot find 'bin\7za.exe'. Make sure you typed the name correctly, and then try again." e...