Message ID | 20130907231535.GB24530@electric-eye.fr.zoreil.com |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: