Merge pull request #3226 from CumulusNetworks/create-pull-request/patch

Changes by create-pull-request action

Author: mergify[bot]

content/cumulus-linux-516/Whats-New/rn.md

@@ -18,11 +18,11 @@ pdfhidden: True
 | 4992204 | Cumulus Linux does not support the NVUE <code>nv set nve vxlan port <udp-port></code> command; you do not see the configured UDP port in the outer VXLAN packet header. | 5.14.0-5.16.4 | |
 | 4989386 | In rare cases, where a gNMI client terminates without cleaning up its gNMI gRPCs, the gNMI server might continue to buffer notifications for the client, resulting in an increase in gNMI server memory usage and potentially leading to a gNMI server restart. | 5.15.1-5.16.4 | |
 | 4989352, 4989413 | GNMI subscriptions might not return interface counter metrics when there is an active, low-rate (1 second) subscription to transceiver data. | 5.16.0-5.16.4 | |
-| 4988339 | Sxd-kernel errors about late completion and "new maximum time between iterations detected"  reported<br /><br />kernel: &#91;875348.575113&#93; sxd_kernel: dev_id=1: Receive late completion for dqn (0) idx (65)<br />kernel: &#91;899873.236610&#93; sxd_kernel: dev_id=1: Health-Check: New maximum time between iterations detected: 7224 msecs (jiffies_now=4519869758, last_work_launch_jiffies=4519867952, HZ=250) | 5.16.1-5.16.4 | |
+| 4988339 | You see the following Sxd-kernel errors about late completion and new maximum time between iterations detected.<br><pre>kernel: &#91;875348.575113&#93; sxd_kernel: dev_id=1: Receive late completion for dqn (0) idx (65)<br>kernel: &#91;899873.236610&#93; sxd_kernel: dev_id=1: Health-Check: New maximum time between iterations detected: 7224 msecs (jiffies_now=4519869758, last_work_launch_jiffies=4519867952, HZ=250)</pre> | 5.16.1-5.16.4 | |
 | 4986343 | PTM does not refresh certain entries and the PTM's neighbor status command (ptmctl -d) continues to show a neighbor that is already gone. This condition clears when the expected neighbor gets discovered. | 5.15.1-5.16.4 | |
 | 4983561 | When interfaces are constantly flapping and the same BGP neighbor comes up on a different interface, routes might not be reprogrammed in the kernel after the kernel deletes them during interface down events. To work around this issue, restart the FRR service. | 5.16.1-5.16.4 | |
 | 4983375 | Upgrading Cumulus Linux to 5.16.x causes a long boot delay and the <code>nvued</code> service remains in an activating state. To work around this issue, run <code>nvue-git-manual-recovery.sh</code> as a root user during maintenance on each node before upgrade, or on any node that has this issue. When successful, upgrade Cumulus Linux. If the script exits non-zero or reports time exceeded, follow the on-screen steps before continuing the upgrade.  | 5.16.1-5.16.4 | |
-| 4983144 | If the nginx <code>nvue.conf </code> file is updated (for example, with package update) and the NVUE git database is corrupt, the startup configuration might fail and the <code>nvue.conf</code> file might come from the debian package instead of the NVUE configuration that you create. To work around this issue, you can force the nginx <code>nvue.conf</code> file to update by making a basic change to system API, applying the change, then backing it out; for example:<br><pre>nv set system api compression gzip<br>nv config apply -y<br>nv unset system api compression gzip<br>nv config apply -y<pre> | 5.16.1-5.16.4 | |
+| 4983144 | If the nginx <code>nvue.conf</code> file is updated (for example, with package update) and the NVUE git database is corrupt, the startup configuration might fail and the <code>nvue.conf</code> file might come from the debian package instead of the NVUE configuration that you create. To work around this issue, you can force the nginx <code>nvue.conf</code> file to update by making a basic change to system API, applying the change, then backing it out; for example:<br><pre>nv set system api compression gzip<br>nv config apply -y<br>nv unset system api compression gzip<br>nv config apply -y</pre> | 5.16.1-5.16.4 | |
 | 4980055 | With very large configurations, <code>nv config apply</code> command performance might be slow. | 5.15.0-5.16.4 | |
 | 4977145 | In rare cases, when an 802.1x enabled port is flapped, it can cause 802.1x to lock up. As a result, the show status commands on 802.1x do not work, no new sessions are authorized and there are no re-authorizations. To work around this issue and recover from the blocked state, restart the <code>hostapd.service</code>. | 5.16.1-5.16.4 | |
 | 4968081 | During switch boot, a race condition between Docker container restoration and LLDP daemon startup might cause <code>/var/run/lldpd.socket</code> to be created as a directory instead of a socket file. When this occurs, the LLDP daemon is unable to clean up the path and fails to start permanently, requiring a reboot to recover. | 5.14.0-5.16.4 | |
@@ -219,7 +219,7 @@ pdfhidden: True
 ### Fixed Issues in 5.16.4
 |  Issue ID 	|   Description	|   Affects	|
 |---	        |---	        |---	    |
-| 5030199 | The <code>rsyslog</code> event logger configuration file (<code>12-event-logger.conf</code>) defines a <code>$outchannel</code> with a 1MB size limit and rotation command. However, the <code>omfile</code> action that writes to <code>/var/log/event_logger</code> does not reference the outchannel and lacks inline rotation directives. As a result, <code>rsyslog</code> does not invoke <code>rotate_now</code> to trigger <code>logrotate</code> when the file exceeds 1MB. | 5.16.1-5.16.3 | |
+| 5030199 | The <code>/var/log/event_logger</code> file does not rotate when the file size exceeds 1MB, which might unexpectedly fill the <code>/var</code> partition. | 5.16.1-5.16.3 | |
 | 5027908 | RADIUS Access-Request and Accounting-Request packets carry the loopback address 127.0.1.1 in the NAS-IP-Address attribute instead of the management interface address. RADIUS servers that authorize or log requests based on the NAS-IP-Address reject or fail the authentication requests. | 5.15.0-5.16.3 | |
 
 ## 5.16.3 Release Notes

content/cumulus-linux-516/rn.xml

@@ -32,14 +32,9 @@
 </tr>
 <tr>
 <td>4988339</td>
-<td>Sxd-kernel errors about late completion and "new maximum time between iterations detected"  reported.
-
-
- kernel: [875348.575113] sxd_kernel: dev_id=1: Receive late completion for dqn (0) idx (65)
-
- kernel: [899873.236610] sxd_kernel: dev_id=1: Health-Check: New maximum time between iterations detected: 7224 msecs (jiffies_now=4519869758, last_work_launch_jiffies=4519867952, HZ=250)
-
-</td>
+<td>You see the following Sxd-kernel errors about late completion and new maximum time between iterations detected.
+kernel: [875348.575113] sxd_kernel: dev_id=1: Receive late completion for dqn (0) idx (65)
+kernel: [899873.236610] sxd_kernel: dev_id=1: Health-Check: New maximum time between iterations detected: 7224 msecs (jiffies_now=4519869758, last_work_launch_jiffies=4519867952, HZ=250)</td>
 <td>5.16.1-5.16.4</td>
 <td></td>
 </tr>
@@ -63,7 +58,7 @@
 </tr>
 <tr>
 <td>4983144</td>
-<td>If the nginx {{nvue.conf }} file is updated (for example, with package update) and the NVUE git database is corrupt, the startup configuration might fail and the {{nvue.conf}} file might come from the debian package instead of the NVUE configuration that you create. To work around this issue, you can force the nginx {{nvue.conf}} file to update by making a basic change to system API, applying the change, then backing it out; for example:
+<td>If the nginx {{nvue.conf}} file is updated (for example, with package update) and the NVUE git database is corrupt, the startup configuration might fail and the {{nvue.conf}} file might come from the debian package instead of the NVUE configuration that you create. To work around this issue, you can force the nginx {{nvue.conf}} file to update by making a basic change to system API, applying the change, then backing it out; for example:
 nv set system api compression gzip
 nv config apply -y
 nv unset system api compression gzip
@@ -1296,7 +1291,7 @@ cumulus@switch:~$ sudo ethtool -s swp1 speed 100000 autoneg off lanes 2
 </tr>
 <tr>
 <td>5030199</td>
-<td>The {{rsyslog}} event logger configuration file ({{12-event-logger.conf}}) defines a {{$outchannel}} with a 1MB size limit and rotation command. However, the {{omfile}} action that writes to {{/var/log/event_logger}} does not reference the outchannel and lacks inline rotation directives. As a result, {{rsyslog}} does not invoke {{rotate_now}} to trigger {{logrotate}} when the file exceeds 1MB.</td>
+<td>The {{/var/log/event_logger}} file does not rotate when the file size exceeds 1MB, which might unexpectedly fill the {{/var}} partition.</td>
 <td>5.16.1-5.16.3</td>
 </tr>
 <tr>