8139 Dropping Packets

Home » CentOS » 8139 Dropping Packets
CentOS 12 Comments

I have a CentOS 5.8 box that is dropping packets (just from ping). The network is 8139 RTL-8139/8139C/8139C+ Rev 10

Adding the parameters “pci=noacpi acpi=off ”
has helped but it still happens.

Is there something else that helps the network not drop packets?



12 thoughts on - 8139 Dropping Packets

  • This probably won’t be helpful, but whenever someone inquires about trouble with a Realtek network chipset someone ALWAYS responds that Realtek network hardware is junk and that you should replace it with something good, such as an intel e100 or e1000 or some such.

    Me, I’ve never had trouble with a realtek card, myself.

  • with the newest intel desktop CPUs at least, the first ethernet controller is built into the southbridge (H77, Z77, etc), and if there’s a realtek chip on there its just the ‘PHY” physical interface.

  • Is there any chances you can send in the stats of the interface? Just show if the driver says why it’s being dropped.


  • Upgrade to CentOS 6. I have approx 20 jetway mini-itx boxes with a built in 8139. I recently had all but 2 experience large packet loss problems. Some of them were happily running C-5 for over 2 years. Upgrading them to C-6
    solved it but I do not know why. I too would really like to understand what is going on here.

    In addition, I would like to know why I still have 2 boxes that are happily running c-5.

    I suspect that this is some kind of driver issue but I even tried upgrading the drivers using those supplied by EL-Repo. The only thing that improved the situation was upgrading to C-6.

    FWIW, I use them as router/firewalls. They have a 3 port daughter board for a total of 4 Ethernet ports on them that I have recently switched to using an Intel based chipset just as a precaution.


  • Banyan,

    RX packets:2944544 errors:45 dropped:21 overruns:4

    dmesg shows no errors tail /var/log/messages shows no errors.



  • Check your duplex. I have had two recent problems with duplex:

    One, with a Cisco router – it auto-negotiated every time to half duplex, even though it really -was- full. Use mii-tool to find out.

    Two, with a RR modem – the speed was forced to 10mb half duplex instead of
    100mb full duplex. All sorts of strange loss. Once I put it back, all was well.

    I have used TONs of 8139s, and while I do see where they are not the fastest kid on the block, I cannot say I’ve seen packet loss.


  • Am 28.10.2012 18:30, schrieb Bob Puff:

    That’s the typical effect when one side is configured to “full duplex” and the other side to “auto negotiate”. The side with the fixed configuration will not reply to the negotiation packets, whereupon the other side will fall back to half duplex.

  • Just a note, auto-negotiation of 10/100 links will not work reliably unless both sides of the link are set to auto-negotiate.

    If one side is set to 100/full, and the other side is set to auto negotiate, then it will try to negotiate, the side that is hard coded
    100/full will _NOT_ negotiate and negotiation will fail, the side that was set to auto negotiate will fail back to a ‘fail-safe’ 10/half duplex link.

    My rule of thumb, static link (e.g. those to servers, inter switch links, switch to router links etc…) should just be hard coded. Links that might have a variety of devices connected to them, e.g. the access layer ports – set them to auto-negotiate.

  • The devices dropping packets each reside on their own managed 8 port switch 10/100/1000. We have had issues with 10/100 Ethernet to RS232 adapters and 10/100/1000 switches in regards to auto negotiation.