From: "Michael S. Zick" <lkml@morethan.org>
To: linux-kernel@vger.kernel.org
Cc: Michael Riepe <michael.riepe@googlemail.com>
Subject: Re: 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too
Date: Sun, 10 May 2009 10:01:38 -0500 [thread overview]
Message-ID: <200905101001.40455.lkml@morethan.org> (raw)
In-Reply-To: <4A06D8D2.4010505@googlemail.com>
On Sun May 10 2009, Michael Riepe wrote:
>
> Michael Buesch wrote:
>
> > I'm currently testing 2.6.29.1 without any additional patches but
> > with the pci=nomsi boot option.
> >
> > I didn't notice any hickups, yet. I'm running a stresstest on a GBit link for quite
> > some time now. Earlier tests with older kernels and MSI burped earlier.
> >
I can confirm greater through-put and reduced cpu usage with pci=nomsi
on different hardware.
Machine: Everex Cloudbook (ce1200v)
HICS: Via CX700
PCI-to-PCIe bridge, Via 1106:324B
(only) Downstream device: HD Audio Controller, Via 1106:3288
Kernel: 2.6.30-rc5 (git repo)
No extensive benchmarking required here - you can hear the difference!
00:13.1 PCI bridge [0604]: VIA Technologies, Inc. CX700/VX700 PCI to PCI Bridge [1106:324a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00005000-00005fff
Memory behind bridge: d1100000-d11fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
02:01.0 Audio device [0403]: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller) [1106:3288] (rev 10)
Subsystem: FIRST INTERNATIONAL Computer Inc Device [1509:2f07]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at d1000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend+
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: HDA Intel
Mike
> > I will do more testing. If it turns out this is stable I will test the same kernel
> > with Message Signaled Interrupts to see if that causes some breakage.
>
> I've had this problem up to and including 2.6.29.2. Currently, I'm
> trying 2.6.29.2 with pci=nomsi, and it's stable so far. With MSI
> enabled, a single high-speed TCP transfer will stop after a few seconds,
> but without MSI, I can run four simultaneous transfers to two different
> hosts without a single hickup.
>
> It seems to me that this particular chip really doesn't like MSI.
>
> Kernel: 2.6.29.2 (x86_64)
> Board: Intel D945GCLF2
> BIOS version: LF94510J.86A.0099.2008.0731.0303
>
> lspci -vv:
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
> Subsystem: Intel Corporation Device 0001
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 16
> Region 0: I/O ports at 1000 [size=256]
> Region 2: Memory at 90100000 (64-bit, non-prefetchable) [size=4K]
> Region 4: Memory at 90000000 (64-bit, prefetchable) [size=64K]
> Expansion ROM at 90020000 [disabled] [size=128K]
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [50] MSI: Mask- 64bit+ Count=1/1 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [70] Express (v1) Endpoint, MSI 01
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
> <512ns, L1 <64us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 4096 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+
> TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <512ns, L1 <64us
> ClockPM+ Suprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
> Vector table: BAR=4 offset=00000000
> PBA: BAR=4 offset=00000800
> Capabilities: [d0] Vital Product Data <?>
> Kernel driver in use: r8169
> Kernel modules: r8169
>
next prev parent reply other threads:[~2009-05-10 15:01 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 17:28 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too Michael Büker
2009-03-04 22:43 ` Francois Romieu
2009-03-06 0:17 ` Michael Büker
2009-03-08 10:27 ` Tom Weber
2009-03-10 5:42 ` Tom Weber
2009-03-09 12:07 ` Rui Santos
2009-03-13 18:29 ` Rui Santos
2009-03-16 13:07 ` Rui Santos
2009-03-22 21:12 ` Francois Romieu
2009-03-22 21:19 ` Michael Buesch
2009-03-22 22:00 ` Francois Romieu
2009-03-22 22:09 ` Michael Buesch
2009-03-22 22:27 ` Francois Romieu
2009-03-22 22:38 ` Michael Buesch
2009-03-23 11:47 ` Michael Buesch
2009-03-23 12:47 ` Michael Buesch
2009-03-23 23:47 ` Francois Romieu
2009-03-24 9:43 ` Michael Buesch
2009-03-23 14:29 ` Michael Büker
2009-03-23 14:57 ` Rui Santos
2009-03-23 15:04 ` Michael Büker
2009-03-25 11:40 ` Rui Santos
2009-04-04 17:50 ` Michael Buesch
2009-05-10 13:38 ` Michael Riepe
2009-05-10 15:01 ` Michael S. Zick [this message]
2009-05-10 15:10 ` Michael S. Zick
2009-05-10 15:53 ` Michael Buesch
2009-05-10 16:27 ` Michael Riepe
2009-05-10 17:09 ` Michael S. Zick
2009-05-11 0:29 ` David Dillow
2009-05-11 20:48 ` Michael Buesch
2009-05-11 21:10 ` Michael Buesch
2009-05-11 21:29 ` David Dillow
2009-05-11 21:59 ` Michael Buesch
2009-05-12 20:29 ` Michael Riepe
2009-05-14 2:38 ` David Dillow
2009-05-14 18:37 ` Michael Riepe
2009-05-14 19:14 ` David Dillow
2009-05-14 19:42 ` Michael Riepe
2009-05-23 1:29 ` [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts David Dillow
2009-05-23 9:24 ` Michael Buesch
2009-05-23 14:35 ` Michael Riepe
2009-05-23 14:44 ` Michael Buesch
2009-05-23 15:01 ` Michael Riepe
2009-05-23 16:40 ` Michael Buesch
2009-05-23 14:51 ` David Dillow
2009-05-23 16:12 ` Michael Riepe
2009-05-23 16:45 ` Michael Buesch
2009-05-23 16:46 ` David Dillow
2009-05-23 16:50 ` Michael Buesch
2009-05-23 16:53 ` Michael Riepe
2009-05-23 17:03 ` David Dillow
2009-05-24 21:15 ` Francois Romieu
2009-05-24 22:55 ` David Dillow
2009-05-26 5:55 ` David Miller
2009-05-26 18:22 ` Michael Buesch
2009-05-26 21:52 ` David Miller
2009-05-26 22:14 ` David Miller
2009-05-26 22:40 ` Michael Riepe
2009-05-26 22:43 ` David Miller
2009-05-26 23:10 ` David Miller
2009-05-27 16:19 ` Michael Buesch
2009-06-16 19:32 ` Rui Santos
2009-08-21 20:57 ` Eric W. Biederman
2009-08-21 21:22 ` Michael Riepe
2009-08-21 22:59 ` David Dillow
2009-08-21 23:34 ` David Dillow
2009-08-22 0:24 ` Eric W. Biederman
2009-08-22 11:48 ` Eric W. Biederman
2009-08-22 12:07 ` Eric W. Biederman
2009-08-22 20:43 ` David Dillow
2009-08-23 17:17 ` Jarek Poplawski
2009-08-23 17:43 ` Michal Soltys
2009-08-23 17:54 ` Jarek Poplawski
2009-08-24 2:37 ` Eric W. Biederman
2009-08-25 0:51 ` Eric W. Biederman
2009-08-25 2:59 ` David Dillow
2009-08-25 20:22 ` Eric W. Biederman
2009-08-25 20:40 ` David Dillow
2009-08-25 21:24 ` Eric W. Biederman
2009-08-25 21:46 ` David Dillow
2009-08-25 22:19 ` Francois Romieu
2009-08-26 3:47 ` Eric W. Biederman
2009-08-26 7:58 ` [PATCH] r8169: Reduce looping in the interrupt handler Eric W. Biederman
2009-08-26 13:56 ` David Dillow
2009-08-26 13:59 ` David Dillow
2009-08-26 20:02 ` Eric W. Biederman
2009-08-26 21:30 ` Francois Romieu
2009-08-26 21:40 ` Eric W. Biederman
2009-08-27 5:24 ` Francois Romieu
2009-08-27 5:38 ` Eric W. Biederman
2009-08-27 23:20 ` Francois Romieu
2009-08-28 1:17 ` Eric W. Biederman
2009-08-28 1:29 ` David Dillow
2009-08-30 20:37 ` Francois Romieu
2009-08-30 20:53 ` Eric W. Biederman
2009-09-01 3:33 ` David Dillow
2009-09-01 9:20 ` Francois Romieu
2009-08-25 21:37 ` [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts Eric W. Biederman
2009-08-25 21:54 ` David Dillow
2009-08-25 23:11 ` Francois Romieu
2009-05-12 11:10 ` 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too Krzysztof Halasa
2009-05-12 21:45 ` Michael Riepe
2009-05-13 6:11 ` Francois Romieu
2009-05-13 6:27 ` Michael Riepe
2009-05-13 19:34 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200905101001.40455.lkml@morethan.org \
--to=lkml@morethan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.riepe@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.