imq_stream_disable_stream() messages are logged when the router is unable to drain a queue within a specific period of time. This message is usually an indication of recovery from an issue, rather than an issue in and of itself.
The problem related to this syslog message is described in the following sections:
The imq_stream_disable_stream message is logged when an internal part of the I-chip is unable to clear data to make room for new data streams. The message indicates that the queue was not drained within 200ms, so the software stopped trying to disable the queue.
The error message will look similar to this:
feb1 ICHIP(0) imq_stream_disable_stream() failed to disable physical queue 0 in stream 3
This particular message can be misleading; because, while it does indicate that an error occurred, this error usually only appears when an I-chip wedge condition has been recovered.
An I-chip wedge condition occurs when the I-chip is unable or is limited in its ability to pass traffic. A variety of different conditions can cause this state. Prior to Junos 9.3, such a condition was only recoverable by resetting the FEB on an M-120, or the FPC on an MX series router. After Junos 9.3, recovery mechanisms were built into the software.
There are times other than when a wedge condition is cleared that you may encounter this message. When CoS scheduling parameter changes are made on an interface, it will try to disable the corresponding streams first before making the changes. If a scenario exists where the streams cannot be disabled, then this error will appear.
When the error message imq_stream_disable_stream() failed to disable physical queue is seen after the reset of the FEB or FPC, its presence is a marker indicating that the recovery was successful. Even after Junos 9.3 you will still see this message after a wedge condition has been recovered, even though the software will recover automatically if possible. Also, when the message appears in a non-wedge scenario (configuration being removed from an interface, for example), the message is considered to be non-impacting.
Because this message is non-impacting and is often an indicator of recovery, rather than indicating a problem, it has been suggested that the message be changed from an error to an informational message. As of this writing, it is still seen as an error in syslog messages.
If you are seeing this message, monitor the router to see if the message continues to appear when no changes are being made. Monitor the interfaces affected by the corresponding fpcs to see if packet drops are incrementing while the message is present. If they are, this may indicate an undiscovered issue.
No action is necessary for this message. It is informational and indicates that a problem has been averted, rather than that a problem exists.