* [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
@ 2013-09-07 23:15 Francois Romieu
2013-09-08 8:45 ` Daniel Borkmann
2013-09-09 3:25 ` hayeswang
0 siblings, 2 replies; 9+ messages in thread
From: Francois Romieu @ 2013-09-07 23:15 UTC (permalink / raw)
To: netdev; +Cc: David Miller, David R, Frédéric Leroy, Hayes Wang
Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
hack for the 8168evl.") regarding AMD IOMMU errors.
RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
same.
Tested-by: David R <david@unsolicited.net>
Tested-by: Frédéric Leroy <fredo@starox.org>
Cc: Hayes Wang <hayeswang@realtek.com>
---
Hayes, a ack would be welcome.
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f87f2c..3397cee 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4231,6 +4231,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
case RTL_GIGA_MAC_VER_40:
--
1.8.3.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-07 23:15 [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f Francois Romieu
@ 2013-09-08 8:45 ` Daniel Borkmann
2013-09-11 20:16 ` David Miller
2013-09-09 3:25 ` hayeswang
1 sibling, 1 reply; 9+ messages in thread
From: Daniel Borkmann @ 2013-09-08 8:45 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev, David Miller, David R, Frédéric Leroy,
Hayes Wang
On 09/08/2013 01:15 AM, Francois Romieu wrote:
> Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
> hack for the 8168evl.") regarding AMD IOMMU errors.
>
> RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
> same.
>
> Tested-by: David R <david@unsolicited.net>
> Tested-by: Frédéric Leroy <fredo@starox.org>
> Cc: Hayes Wang <hayeswang@realtek.com>
> ---
Your signed-off-by is missing.
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-07 23:15 [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f Francois Romieu
2013-09-08 8:45 ` Daniel Borkmann
@ 2013-09-09 3:25 ` hayeswang
2013-09-09 4:13 ` David Miller
2013-09-09 22:50 ` Francois Romieu
1 sibling, 2 replies; 9+ messages in thread
From: hayeswang @ 2013-09-09 3:25 UTC (permalink / raw)
To: 'Francois Romieu', netdev
Cc: 'David Miller', 'David R',
'Frédéric Leroy', 'nic_swsd'
Hi,
For RTL8111D and the later chips, the RxConfig (IO 0x44) bit 14 = 0 means
fetching multi-descriptor once. Note that, the meaning is different from
the RTL8111C. Therefore, the hw would only fetch one descriptor each time
when you set that bit.
I don't have any issue reported about the fetching numbers, so I have no
idea about why it could fix you problem.
Best Regards,
Hayes
-----Original Message-----
From: Francois Romieu [mailto:romieu@fr.zoreil.com]
Sent: Sunday, September 08, 2013 7:16 AM
To: netdev@vger.kernel.org
Cc: David Miller; David R; Frédéric Leroy; Hayeswang
Subject: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
hack for the 8168evl.") regarding AMD IOMMU errors.
RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
same.
Tested-by: David R <david@unsolicited.net>
Tested-by: Frédéric Leroy <fredo@starox.org>
Cc: Hayes Wang <hayeswang@realtek.com>
---
Hayes, a ack would be welcome.
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f87f2c..3397cee 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4231,6 +4231,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
case RTL_GIGA_MAC_VER_40:
--
1.8.3.1
------Please consider the environment before printing this e-mail.
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-09 3:25 ` hayeswang
@ 2013-09-09 4:13 ` David Miller
2013-09-09 22:50 ` Francois Romieu
1 sibling, 0 replies; 9+ messages in thread
From: David Miller @ 2013-09-09 4:13 UTC (permalink / raw)
To: hayeswang; +Cc: romieu, netdev, david, fredo, nic_swsd
Please do not quote a patch this way, to our automated systems it makes
it look like another submission of the patch which makes more work for me.
Quoting must use some kind of reasonable prefix on the quoted content
such as "> ", as is common in mailers, to delimit new content from
quoted content.
Thank you.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-09 3:25 ` hayeswang
2013-09-09 4:13 ` David Miller
@ 2013-09-09 22:50 ` Francois Romieu
2013-09-10 8:08 ` Frédéric Leroy
1 sibling, 1 reply; 9+ messages in thread
From: Francois Romieu @ 2013-09-09 22:50 UTC (permalink / raw)
To: hayeswang
Cc: netdev, 'David Miller', 'David R',
'Frédéric Leroy', 'nic_swsd'
hayeswang <hayeswang@realtek.com> :
[...]
> I don't have any issue reported about the fetching numbers, so I have no
> idea about why it could fix you problem.
Thanks Hayes.
Frédéric, David (R not M), do your systems include some Marvell SATA controller ?
--
Ueimor
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-09 22:50 ` Francois Romieu
@ 2013-09-10 8:08 ` Frédéric Leroy
0 siblings, 0 replies; 9+ messages in thread
From: Frédéric Leroy @ 2013-09-10 8:08 UTC (permalink / raw)
To: Francois Romieu
Cc: hayeswang, netdev, 'David Miller', 'David R',
'nic_swsd'
Le 10/09/2013 00:50, Francois Romieu a écrit :
> hayeswang <hayeswang@realtek.com> :
> [...]
> > I don't have any issue reported about the fetching numbers, so I have no
> > idea about why it could fix you problem.
>
> Thanks Hayes.
>
> Frédéric, David (R not M), do your systems include some Marvell SATA controller ?
>
I have an amd one :
[fredo:~] $ lspci | grep SATA
00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)
But I know I have sata ncq errors and stability problems with kernels >=
3.11
from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
I don't try to debug it for the moment because it is on my main computer
and have valuable data on my ssd.
For completeness, here is the full list of pci devices on my pc :
[fredo:~] $ lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI
to PCI bridge (external gfx0 port B) (rev 02)
00:00.2 IOMMU: Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory
Management Unit (IOMMU)
00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI
to PCI bridge (PCI express gpp port B)
00:04.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI
to PCI bridge (PCI express gpp port D)
00:05.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI
to PCI bridge (PCI express gpp port E)
00:07.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI
to PCI bridge (PCI express gpp port G)
00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus
Controller (rev 42)
00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00
Azalia (Intel HDA) (rev 40)
00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 LPC host controller (rev 40)
00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI
to PCI Bridge (rev 40)
00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:16.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:16.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 15h
Processor Function 0
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 15h
Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 15h
Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 15h
Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 15h
Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices [AMD] Family 15h
Processor Function 5
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI Caicos [Radeon HD 6450]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Caicos
HDMI Audio [Radeon HD 6400 Series]
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 09)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed
USB Host Controller
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed
USB Host Controller
05:05.0 Ethernet controller: 3Com Corporation 3c940
10/100/1000Base-T [Marvell] (rev 10)
[fredo:~] $
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-08 8:45 ` Daniel Borkmann
@ 2013-09-11 20:16 ` David Miller
2013-09-11 23:15 ` Francois Romieu
0 siblings, 1 reply; 9+ messages in thread
From: David Miller @ 2013-09-11 20:16 UTC (permalink / raw)
To: dborkman; +Cc: romieu, netdev, david, fredo, hayeswang
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sun, 08 Sep 2013 10:45:14 +0200
> On 09/08/2013 01:15 AM, Francois Romieu wrote:
>> Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169:
>> RxConfig
>> hack for the 8168evl.") regarding AMD IOMMU errors.
>>
>> RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave
>> the
>> same.
>>
>> Tested-by: David R <david@unsolicited.net>
>> Tested-by: Frédéric Leroy <fredo@starox.org>
>> Cc: Hayes Wang <hayeswang@realtek.com>
>> ---
>
> Your signed-off-by is missing.
Francois, if you reply to this thread with your signoff, all will
be well and I will apply this.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-11 20:16 ` David Miller
@ 2013-09-11 23:15 ` Francois Romieu
2013-09-12 6:40 ` David Miller
0 siblings, 1 reply; 9+ messages in thread
From: Francois Romieu @ 2013-09-11 23:15 UTC (permalink / raw)
To: David Miller; +Cc: dborkman, netdev, david, fredo, hayeswang
David Miller <davem@davemloft.net> :
[...]
> Francois, if you reply to this thread with your signoff, all will
> be well and I will apply this.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
I slowly built an AMD IOMMU + 8168{e/f} problem report pattern but
the picture got blurred:
- Hayes has not heard of anything like this
- the oracle suggests it could be an "AMD IOMMU + whatever" problem
- "iommu=pt" seems quite effective (hardly surprizing :o/ )
I still have a pile of iommu mailing-list messages to search through.
Let aside the AMD-Vi error log message, I haven't done a thorough analysis.
It's lame.
--
Ueimor
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
2013-09-11 23:15 ` Francois Romieu
@ 2013-09-12 6:40 ` David Miller
0 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2013-09-12 6:40 UTC (permalink / raw)
To: romieu; +Cc: dborkman, netdev, david, fredo, hayeswang
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 12 Sep 2013 01:15:43 +0200
> David Miller <davem@davemloft.net> :
> [...]
>> Francois, if you reply to this thread with your signoff, all will
>> be well and I will apply this.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>
> I slowly built an AMD IOMMU + 8168{e/f} problem report pattern but
> the picture got blurred:
> - Hayes has not heard of anything like this
> - the oracle suggests it could be an "AMD IOMMU + whatever" problem
> - "iommu=pt" seems quite effective (hardly surprizing :o/ )
>
> I still have a pile of iommu mailing-list messages to search through.
> Let aside the AMD-Vi error log message, I haven't done a thorough analysis.
>
> It's lame.
Understood. There were always IOMMU chips that sometimes prefetch one
cacheline too far (and thus potentially to the next page, which is
potentially unmapped) in certain circumstances. Maybe these settings
trigger that kind of thing.
Applied and queued up for -stable, thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-09-12 6:40 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-07 23:15 [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f Francois Romieu
2013-09-08 8:45 ` Daniel Borkmann
2013-09-11 20:16 ` David Miller
2013-09-11 23:15 ` Francois Romieu
2013-09-12 6:40 ` David Miller
2013-09-09 3:25 ` hayeswang
2013-09-09 4:13 ` David Miller
2013-09-09 22:50 ` Francois Romieu
2013-09-10 8:08 ` Frédéric Leroy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).