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: <4C09387F.1050403@iki.fi>
Date:	Fri, 04 Jun 2010 20:31:43 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	Phil Sutter <phil@....cc>
CC:	françois romieu <romieu@...zoreil.com>,
	netdev@...r.kernel.org
Subject: Re: still having r8169 woes with XID 18000000

On 06/04/2010 04:43 PM, Phil Sutter wrote:
> On Fri, Jun 04, 2010 at 04:02:11PM +0300, Timo Teräs wrote:
>>> 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.
> 
> Hmm. I actually never looked at the corresponding parts of the
> in-tree-driver, but that would have definitely been the next step in
> order to fix it.
> 
>> 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.
> 
> Surely worth a try. On the other hand, looking at the sheer mass of
> problem reports regarding this driver, making it worse is rather hard to
> do I guess. :)

Ok. The issue is semi-reliably producible with just removing the
kernel driver and reloading it. The problem occurs maybe with 10-20% chance.

So far, it looks like the phy wakeup does not really help. Adding the
_VER_05 check did not help.

However, removing the specific phy config code
(rtl8169scd_hw_phy_config) which was introduced by commit 2e955856ff
seems to solve it. At least I was not able to reproduce the failure with
20-30 module reloads.

One more curiosity: if i do a hard power reset, the NIC has green link
indicator led after power up. When loading the kernel module it goes to
orange/red. I wonder why the difference.

- 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