netdev - Re: still having r8169 woes with XID 18000000

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C08F953.1050800@iki.fi>
Date:	Fri, 04 Jun 2010 16:02:11 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	phil@....cc
CC:	netdev@...r.kernel.org,
	françois romieu <romieu@...zoreil.com>
Subject: Re: still having r8169 woes with XID 18000000

On 06/04/2010 03:36 PM, Phil Sutter wrote:
> 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.

Sounds very similar to the problem I have. Thanks for the pointers!

It looks like the r8169 driver does have phy power up code in it, but
it's only executed for specific versions of the chip. Realtek driver
seems to do it unconditionally.

The check seems to be:
                if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
                    (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
                    (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {

I wonder if I should just add my mac version there (_VER_05) and test if
it'll make it better.

- Timo
--
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