lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 4 Jun 2010 14:36:34 +0200 From: Phil Sutter <phil@....cc> To: Timo Teräs <timo.teras@....fi> Cc: françois romieu <romieu@...zoreil.com>, netdev@...r.kernel.org Subject: Re: still having r8169 woes with XID 18000000 Hi, On Fri, Jun 04, 2010 at 03:10:47PM +0300, Timo Teräs wrote: > After fixing the MAC issues earlier, I'm still seeing some weird trouble > with my RTL8169sc/8110sc / XID 18000000 boards. > > The box(es) were originally running 2.6.30.x kernel and everything > worked without major problems. But after upgrading to 2.6.32.x (and even > with most of the newer fixes included too), it seems that the sometimes > (not too often) some of the interfaces just won't work after reboot > (cold or hard). It's a 3-in-1 board, and usually when this happens one > of the interfaces won't work but the other two do work. > > Whenever an interface is "broken", the following conditions are true: > - forcing it to 10mbit/s and disabling autoneg will make it work > - when it's not working ethtool -S reports rx_errors and align_errors > increasing > - when autoneg is on, ethtool says that "Link Detected: no" This (your last point) is about what we were experiencing at work using PCI-based Gigabit Realtek NICs. Our solution to the problem was to switch to a different NIC (Intel e1000), which obviously solves any problems. ;) But I've done some tests before, mainly being inspired by these mails: http://permalink.gmane.org/gmane.linux.network/160136 http://permalink.gmane.org/gmane.linux.network/160280 and after some feedback from the mainboard manufacturer I've tested the out-of-tree driver Realtek provides (version 6.013.00), which seems to not have this issue. Very interesting results show up when comparing 6.013 with 6.012 (citing myself): Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly enabled function rtl8169_phy_power_up() as well as some more invocations of rtl8169_phy_power_down(). This is probably the solution to these (at least in our case) very sporadic, but highly annoying, problems. In fact, when our NIC didn't detect any link, it needed a full power-cycle (no success with reset-button), so almost not workaroundable. HTH, Phil -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists