# Network TX drops now non-zero after update to RL9.6

**URL:** <https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592>\
**Category:** Rocky Linux Help & Support\
**Tags:** rocky-linux-9\
**Created:** [September 10, 2025, 12:52am UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592 "2025-09-10T00:52:32Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![onthebeatenpath](https://avatars.discourse-cdn.com/v4/letter/o/898d66/32.png) [@onthebeatenpath](https://forums.rockylinux.org/u/onthebeatenpath)\
**Post date:** [September 10, 2025, 12:52am UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/1 "2025-09-10T00:52:32Z")

</div>

On multiple production systems with 5 network interfaces (Intel i210 NICs and also some systems with older Intel 82574 NICs), we are now seeing the output of `netstat -in` and `ip -s link show`indicating TX drops, like so:

```
$ netstat -in
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
e0 1150 2814 0 0 0 41 0 2 0 BMRU
e1 1500 400066 0 0 0 1263352 0 2 0 BMRU
e2 1500 1654728 0 0 0 1556547 0 3 0 BMRU
e3 1500 8938718 0 0 0 231107 0 68 0 BMRU
e4 1500 0 0 0 0 0 0 77844 0 BMU
```

e4 is not connected (`ip addr` shows `NO-CARRIER`). The other interfaces are all connected. e3 has an embedded device which has powered off and on a few times, and the TX drops increment when that happens.  
e0 and e1 are connected to COTS switches.  
e2 is connected to a FreeBSD host (which shows no drops, errors or collisions in its netstat output).

The small number of TX drops for e0, e1, e2 appeared early at some point during the time the interface was being initialized.

In RL9.5, these TX drops on the same physical hosts are consistently at 0 on all the systems (a dozen or so) where RL9.6 is showing drops.

I suspect this is just an accounting change, but I’d like to pin down what part of the stack changed (or what setting changed) that would trigger these drops.

`ethtool -S <ifname>` does not show any TX drops for i210, but tx\_dropped values that match the `netstat -in` numbers for the older 82574 NIC.

kernel is 5.14.0-570.30.1.el9\_6.x86\_64  
igb driver in use - all interfaces 1 Gbps.

First question… have anyone else here seen this issue firsthand (zero TX drops on 9.5, non-zero drops on 9.6)?

Next question… Does anyone have an inkling about what has changed in the network stack that could trigger this?

---

<div class="post-metadata">

**Author:** ![R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/r_o_c_k_y_l_i_n_u_x/32/5594_2.png) [@R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](https://forums.rockylinux.org/u/R_O_C_K_Y_L_I_N_U_X)\
**Post date:** [September 10, 2025, 2:47pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/2 "2025-09-10T14:47:45Z")

</div>

This is from Microsoft Copilot A.I. to dig a bit deeper into TX-DRP:

**“Check interface stats** with `ifconfig e3` or `ip -s link show e3` to see errors, collisions, or queue drops.”

because TX-DRP can be due to these four causes:

1. Network congestion
2. Interface misconfiguration
3. Hardware limitations
4. Driver or firmware issues

Hope this helps,

Tony

---

<div class="post-metadata">

**Author:** ![gerry666uk](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@gerry666uk](https://forums.rockylinux.org/u/gerry666uk)\
**Post date:** [September 10, 2025, 8:14pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/3 "2025-09-10T20:14:59Z")

</div>

Looking at the last column where it says ‘TX-DR’, I only see numbers for e3 and e4 (you already explained why those two are dropping), but I only see a blank column for e0, e1, e2 so where are the drops?

---

<div class="post-metadata">

**Author:** ![onthebeatenpath](https://avatars.discourse-cdn.com/v4/letter/o/898d66/32.png) [@onthebeatenpath](https://forums.rockylinux.org/u/onthebeatenpath)\
**Post date:** [September 11, 2025, 9:50pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/5 "2025-09-11T21:50:23Z")

</div>

> [@gerry666uk](#):
>
> Looking at the last column … I only see numbers for e3 and e4… I only see a blank column for e0, e1, e2 so where are the drops?

I didn’t notice that netstat output in the original post was truncated. Not sure how that happened. Let me try again…

```auto
$ netstat -in
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
e0 1150 2814 0 0 0 41 0 2 0 BMRU
e1 1500 400066 0 0 0 1263352 0 2 0 BMRU
e2 1500 1654728 0 0 0 1556547 0 3 0 BMRU
e3 1500 8938718 0 0 0 231107 0 68 0 BMRU
e4 1500 0 0 0 0 0 0 77845 0 BMU

```

---

<div class="post-metadata">

**Author:** ![onthebeatenpath](https://avatars.discourse-cdn.com/v4/letter/o/898d66/32.png) [@onthebeatenpath](https://forums.rockylinux.org/u/onthebeatenpath)\
**Post date:** [September 11, 2025, 10:02pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/6 "2025-09-11T22:02:49Z")

</div>

> [@R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](#):
>
> … TX-DRP can be due to these four causes:
> 
> 1. Network congestion
> 2. Interface misconfiguration
> 3. Hardware limitations
> 4. Driver or firmware issues

It’s not 1 or 3. Same hardware (inside and outside the box). Switching between RL9.5 and RL9.6 is ALWAYS 0 TX drops for RL9.5 and non-zero for RL9.6.

If it’s 2 (interface misconfig), it is a change in the underlying code (network stack) somehow. /etc files are the same.

It could certainly be 4 (but I’ll add: changes to kernel network code and/or userland tools like netstat(8) or ip(8)).

So I’m mainly leaning towards 4 and trying to figure out what changed between 9.5 and 9.6 that could be implicated. Hence the post here for help (and corroborating stories - positive or negative - from people that are using RL9.5 and RL9.6).

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [September 12, 2025, 7:26am UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/7 "2025-09-12T07:26:38Z")

</div>

I have an old Proliant DL380e with 9.6 kernels it crashes, and I’m stuck using 5.14.0-503.40.1.el9\_5 on it which was the last 9.5 kernel release. So my situation is far worse than yours.

I expect if you still have a 9.5 kernel installed like the version above, you’ll probably find it also works fine, but as soon as you boot into a 9.6 kernel, the problems start. In the end I just use kernel-lt from elrepo instead - I get a 6.x kernel and much more hardware support than the default kernel in 9.x.

Obviously RHEL changed hardware support causing issues in 9.6.

Maybe try installing elrepo kernel-lt as well on yours and see if the problems go away:

```auto
dnf install epel-release
dnf config-manager --set-enabled elrepo-kernel
dnf install kernel-lt

```

---

<div class="post-metadata">

**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\
**Post date:** [September 12, 2025, 12:58pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/8 "2025-09-12T12:58:38Z")

</div>

> [@iwalker](#):
>
> Obviously RHEL changed hardware support causing issues in 9.6.

That is something that one would not expect from _Enterprise Linux_.

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [September 12, 2025, 1:13pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/9 "2025-09-12T13:13:44Z")

</div>

> [@jlehtone](#):
>
> That is something that one would not expect from _Enterprise Linux_.

Yep, I tried three or four of the subsequent kernels that came out after and the effect was still the same. I gave up trying further ones after that, since the elrepo one worked. I could of course raise a bug report for it, but I’m not that entirely bothered about it. Either it wasn’t meant to happen and thus a regression, or it was intentional. I would have expected it to work at least until the EOL of EL9.

Since the server doesn’t support x86\_64-v3, I’ll be retiring it in 2032 anyway assuming it doesn’t break before then.

---

<div class="post-metadata">

**Author:** ![R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/r_o_c_k_y_l_i_n_u_x/32/5594_2.png) [@R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](https://forums.rockylinux.org/u/R_O_C_K_Y_L_I_N_U_X)\
**Post date:** [September 12, 2025, 7:29pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/10 "2025-09-12T19:29:57Z")

</div>

> [@onthebeatenpath](#):
>
> I didn’t notice that netstat output in the original post was truncated.

In my earlier reply, I had suggested doing `“`ip -s link show e3`”` which might help you to obtain more information.

In my (fully up to date) Rocky 9.6 running on a Dell PowerEdge server, my “netstat-in” shows 21 RX-DRP (out of 549,188,830) but “ifconfig eno3” has more detail, and shows those 21 as actually “MISSED”.

Google Gemini states that “The missed statistic in the Linux command **`ip`** refers to packets that a network interface driver failed to process and dropped before they could be passed up the networking stack. This typically indicates a performance bottleneck where the system, often the CPU, isn’t fast enough to handle the incoming packet rate.”

You mention your computer is an old Proliant DL380e, which Gemini tells me was released circa 2012, could your “dropped” packets actually be “missed” packets due to CPU?

---

<div class="post-metadata">

**Author:** ![gerry666uk](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@gerry666uk](https://forums.rockylinux.org/u/gerry666uk)\
**Post date:** [September 12, 2025, 7:44pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/11 "2025-09-12T19:44:28Z")

</div>

> [@onthebeatenpath](#):
>
> Switching between RL9.5 and RL9.6 is ALWAYS 0 TX drops for RL9.5 and non-zero for RL9.6.

One possibility is that 9.5 is giving inaccurate results, and 9.6 is showing the real situation (unlikely but possible), so maybe try using something other than netstat, first on 9.5 and then on 9.6, some raw kernel counter or /proc filesystem, or some other tool.

---

<div class="post-metadata">

**Author:** ![sotrlm](https://avatars.discourse-cdn.com/v4/letter/s/43a26b/32.png) [@sotrlm](https://forums.rockylinux.org/u/sotrlm)\
**Post date:** [September 16, 2025, 5:31pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/12 "2025-09-16T17:31:58Z")

</div>

Had a similar issue with Rocky Linux 9.6 default / builtin kernel module for E810, very high rx\_dropped rate after upgrading to 9.6 version. Downloaded vendor supplied rpm from [https://www.intel.com/content/www/us/en/download/19630/intel-network-adapter-driver-for-e810-series-devices-under-linux.html](https://www.intel.com/content/www/us/en/download/19630/intel-network-adapter-driver-for-e810-series-devices-under-linux.html) issue has disappeared

 ![image](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/2X/9/904ae51c5521680dbbf45c90a4c3e11d7b6cd6e5.png)

---

<div class="post-metadata">

**Author:** ![gerry666uk](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@gerry666uk](https://forums.rockylinux.org/u/gerry666uk)\
**Post date:** [September 17, 2025, 7:33pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/13 "2025-09-17T19:33:19Z")

</div>

The original poster was also using Intel, so could it be there was a change to the Intel driver in the 9.6 kernel?

---

<div class="post-metadata">

**Author:** ![R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/r_o_c_k_y_l_i_n_u_x/32/5594_2.png) [@R\_O\_C\_K\_Y\_L\_I\_N\_U\_X](https://forums.rockylinux.org/u/R_O_C_K_Y_L_I_N_U_X)\
**Post date:** [September 18, 2025, 2:59pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/14 "2025-09-18T14:59:15Z")

</div>

> [@sotrlm](#):
>
> Had a similar issue with Rocky Linux 9.6 default / builtin kernel module for E810, very high rx\_dropped rate after upgrading to 9.6 version. Downloaded vendor supplied rpm from [https://www.intel.com/content/www/us/en/download/19630/intel-network-adapter-driver-for-e810-series-devices-under-linux.html](https://www.intel.com/content/www/us/en/download/19630/intel-network-adapter-driver-for-e810-series-devices-under-linux.html) issue has disappeared

Really interesting to see your charts, the y-axis labels are cut-off, is the typical throughput a constant 1,000 Mbits/second? Google Gemini lists these three reasons for input discard, and I’d guess it is the first reason, since the problem went away with the new RPM:

- **A full receive buffer** : The NIC’s internal buffer is full and cannot store the incoming packet.

- **Invalid packet format** : The packet is malformed and the NIC cannot properly read it.

- **Hardware limitations** : The card is unable to process packets as fast as they are arriving due to hardware constraints.

So, maybe the new RPM is just faster at processing the receive buffers?  
(and that would be helpful for the OP too, who stated having a circa 2012 laptop)

---

<div class="post-metadata">

**Author:** ![plaidcat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/plaidcat/32/5363_2.png) [@plaidcat](https://forums.rockylinux.org/u/plaidcat)\
**Post date:** [September 19, 2025, 7:46pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/15 "2025-09-19T19:46:46Z")

</div>

Ok there are a lot of things going on in this thread, let me see what I can do to help with willing community members for bisecting (I’m waiting on hardware procurement).

- There is an issues with various versions of Intel NICs (i210, 82574, E810) where on Rocky 9.6 which didn’t happen on 9.5.

- Iwalker has a kernel panic on boot, I’m not going to chalk this up to the above specific issue but the ELRepo kernel-lt is 6.1 and is both ahead and behind 9.6 depending on subsystems.

So digging around a little bit in this the ICE driver in the 9.6 kernel was synced to Linus 6.12 on Dec 11th 2024 [https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge\_requests/5841#note\_65103814ea8888e03a4ad04bc49c303d18519230](https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/5841#note_65103814ea8888e03a4ad04bc49c303d18519230) . Since then there have been 40 additional commits to the ICE driver. CIQ maintains a git tree best effort reconstruction of the rocky9.6 kernel git history here: [https://github.com/ctrliq/kernel-src-tree/tree/rocky9\_6](https://github.com/ctrliq/kernel-src-tree/tree/rocky9_6)

```bash
[jmaple@devbox ice]$ git log --oneline f9bd69b20328..HEAD . | wc -l
36

[jmaple@devbox ice]$ cat ../../../../../ciq/ciq_backports/kernel-5.14.0-570.16.1.el9_6/rebuild.details.txt | grep ice: | wc -l
5

```

(yes this totals 41 but some changes we could not be cleanly cherry-picked from stream so they get basically glomed together in a “final patch” that is the actual `rpmbuild -bp` of the `src.rpm` (this commit [https://github.com/ctrliq/kernel-src-tree/commit/171ceb527773dcc959c7cf4884f64cf77c0722d5](https://github.com/ctrliq/kernel-src-tree/commit/171ceb527773dcc959c7cf4884f64cf77c0722d5) )

We know that the Intel OOT solves the the RX issue (or at least appears to do so), one of the issues is the OOT driver is is just blob dumps, and its hard to validate what is in that OOT driver versus what is in Linus’s tree, still on the LKML, or just not even yet pushed to the LKML. But its a good data point.  
However to look at the code deeper, I need to understand what starts to work when and narrowing down the possible change sets. Grepping through the upstream change log there wasn’t something SUPER obvious with RX errors / drops that was net new changes (ie things without a FIXES line in the commit).

## For those with this issue that can have resources for testing.

Since I don’t have access to this hardware yet, I’m needing to lean on those that have time and non-prod resources.

- Can we try the latest of the following:

Thanks, Look forward to being able to help out where I can.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\
**Post date:** [November 18, 2025, 7:47pm UTC](https://forums.rockylinux.org/t/network-tx-drops-now-non-zero-after-update-to-rl9-6/19592/16 "2025-11-18T19:47:22Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
