Bug 947005 - Disabling IRQ (for second network card), nobody cared (except me); slow network performance afterwards.
Summary: Disabling IRQ (for second network card), nobody cared (except me); slow netwo...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-01 07:36 UTC by Mikko Laaksonen
Modified: 2013-04-01 19:38 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-04-01 19:38:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg (71.36 KB, text/plain)
2013-04-01 14:48 UTC, Mikko Laaksonen
no flags Details
lsmod (2.79 KB, text/plain)
2013-04-01 14:49 UTC, Mikko Laaksonen
no flags Details
/proc/interrupts (2.43 KB, text/plain)
2013-04-01 14:50 UTC, Mikko Laaksonen
no flags Details
lspci -nnvv (34.16 KB, text/plain)
2013-04-01 18:29 UTC, Mikko Laaksonen
no flags Details

Description Mikko Laaksonen 2013-04-01 07:36:34 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build Identifier: 

I have an Asus P8P67LE motherboard with integrated gigabit network interface and an additional PCI network card. Some time after the boot, the kernel will report that it is disabling IRQ XX (where XX is the IRQ of the second card, varies depending on physical slot) and that nobody cared. Suggestion was to boot with irqpoll option, but irqpoll is already on and does not help. When the IRQ is disabled, a single http connection on that card is reduced to maximum 5Mbps speed, although parallel connections will achieve up to 10Mbps. Before the disabling, the speed is 23Mbps, which is the speed of the DSL line.

Happens both with e1000 and the new card (I was assuming the Intel driver is to blame), Asus NX1101. Does not affect the integrated network interface.

Reproducible: Always

Steps to Reproduce:
1. Turn on the computer.
2. Wait for approximately 50 minutes.
Actual Results:  
Network performance as expected for the first 50 minutes.

Expected Results:  
Network performance as expected until further notice.

Comment 1 Josh Boyer 2013-04-01 13:54:33 UTC
Can you attach the output of:

1) dmesg

2) lsmod

3) cat /proc/interrupts

Comment 2 Mikko Laaksonen 2013-04-01 14:48:53 UTC
Created attachment 730285 [details]
dmesg

Comment 3 Mikko Laaksonen 2013-04-01 14:49:41 UTC
Created attachment 730286 [details]
lsmod

Comment 4 Mikko Laaksonen 2013-04-01 14:50:43 UTC
Created attachment 730287 [details]
/proc/interrupts

Comment 5 Josh Boyer 2013-04-01 18:26:45 UTC
Can you please provide the output of lspci -nnvv?

You appear to have an ASMedia PCIe to PCI bridge (1b21:1080) in this machine, and those bridges are known to have broken interrupt handling at the PCI bus level.  There's really nothing we can do to fix the issue in the code, so the only suggestion we have is to not put any devices behind that bridge.

Comment 6 Mikko Laaksonen 2013-04-01 18:29:23 UTC
Created attachment 730369 [details]
lspci -nnvv

Comment 7 Josh Boyer 2013-04-01 19:38:40 UTC
Thank you.  Unfortunately, we have no solutions other than the one mentioned in comment #5 already.  We tried patching in some work arounds for this device and it wound up making the problems worse for several users.  Upstream solutions failed to produce anything as well.

There's nothing we can do in this particular case.


Note You need to log in before you can comment on or make changes to this bug.