Red Hat Bugzilla – Bug 119664
Hard lock with r8169 NIC module.
Last modified: 2013-07-02 22:18:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
A hard lock occurs when using the r8169 NIC module and high outbound
traffic exists. No lock is observed with other NICs or when all
traffic is inbound. Same behavior observed in kernel-2.6.4-1.298.
A patch was recently applied to this module:
Perhaps this is the source of the problem?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Any process that triggers a high amount of outbound traffic will
trigger the problem. For instance:
2. cd /usr/src/
3. scp -r linux-2.6.4-1.300/ othermachine:/tmp
Actual Results: Hard lock occurs shortly after the copying starts.
Expected Results: Normal transfer of files.
Mar 31 22:49:38 xx kernel: r8169 Gigabit Ethernet driver 1.2 loaded
Mar 31 22:49:39 xx kernel: eth1: RealTek RTL8169 Gigabit Ethernet at
0x4284a800, 00:90:f5:27:01:e1, IRQ 217
Mar 31 22:49:39 xx kernel: eth1: Auto-negotiation Enabled.
Mar 31 22:49:39 xx kernel: eth1: 100Mbps Full-duplex operation.
Further testing shows that the problem happens on the SMP kernels only.
The single-processor kernels apparently are not affected by it.
Francois Romieu provided a patch that when applied to
kernel-source-2.6.5-1.319 solves the problem. The link to this patch is:
I too have a Realtek RTL-8169 and it bugs out every 2-4 days (Fedora
Core 2, kernel 2.6.8-1.521). When it happens, I once saw the console
flooded with the message:
eth0: Too much work on interrupt
The kernel appears to be locked up completely when this happens.
Network traffic has not been very high.
Should I open a new ticket for this?
I had this problem too on a Pentium 4 HT machine, running SMP kernels.
I solved it by adding the noapic option to the kernel at boot time.
Since I did this the problem stopped. I never experienced this bug
when running UP kernels.
Please use the patch referred below to sync your kernel with a
recent vanilla kernel. Amongst many things, napi could make a
difference. If the symptoms do not disappear, consider opening
a new ticket and Ccing me.
Btw, assuming people are not hit by r8169 unrelated issues, the
driver has already shown to be quite stable on real SMP systems.
Patch available at: