netdev - Re: network unstable on odroid-c1/meson8b.

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: <fc416bf0-3f3c-72a8-0500-4e487d8f3a27@aplu.fr>
Date:   Thu, 20 Jun 2019 22:54:00 +0200
From:   Aymeric <mulx@...u.fr>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     netdev@...r.kernel.org, linux-amlogic@...ts.infradead.org,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: Re: network unstable on odroid-c1/meson8b.


Le 20/06/2019 à 17:53, Heiner Kallweit a écrit :
> On 20.06.2019 09:55, Aymeric wrote:
>> Hi,
>> On 2019-06-20 00:14, Heiner Kallweit wrote:
>>> On 19.06.2019 22:18, Aymeric wrote:
>>>> Hello all,
>>>>
>>> Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
>>> I assume the genphy driver was used. Do you have a line with
>>> "attached PHY driver" in dmesg output of the vendor kernel?
>> No.
>> Here is the full output of the dmesg from vendor kernel [¹].
>>
>> I've also noticed something strange, it might be linked, but mac address of the board is set to a random value when using mainline kernel and I've to set it manually but not when using vendor kernel.
>>
>>> The dedicated PHY driver takes care of the tx delay, if the genphy
>>> driver is used we have to rely on what uboot configured.
>>> But if we indeed had an issue with a misconfigured delay, I think
>>> the connection shouldn't be fine with just another link partner.
>>> Just to have it tested you could make rtl8211f_config_init() in
>>> drivers/net/phy/realtek.c a no-op (in current kernels).
>>>
>> I'm not an expert here, just adding a "return 0;" here[²] would be enough?
>>
>>> And you could compare at least the basic PHY registers 0x00 - 0x30
>>> with both kernel versions, e.g. with phytool.
>>>
>> They are not the same but I don't know what I'm looking for, so for kernel 3.10 [³] and for kernel 5.1.12 [⁴].
>>
>> Aymeric
>>
>> [¹]: https://paste.aplu.fr/?38ef95b44ebdbfc3#G666/YbhgU+O+tdC/2HaimUCigm8ZTB44qvQip/HJ5A=
>> [²]: https://github.com/torvalds/linux/blob/241e39004581475b2802cd63c111fec43bb0123e/drivers/net/phy/realtek.c#L164
>> [³]: https://paste.aplu.fr/?2dde1c32d5c68f4c#6xIa8MjTm6jpI6citEJAqFTLMMHDjFZRet/M00/EwjU=
>> [⁴]: https://paste.aplu.fr/?32130e9bcb05dde7#N/xdnvb5GklcJtiOxMpTCm+9gsUliRwH8X3dcwSV+ng=
>>
> The vendor kernel has some, but not really much magic:
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/amlogic/ethernet/phy/am_rtl8211f.c
> The write to RTL8211F_PHYCR2 is overwritten later, therefore we don't have to consider it.
>
> The following should make the current Realtek PHY driver behave like in the vendor driver.
> Could you test it?

(sending again for mailing list, sorry, I forgot to force it in plaintext…)

I've applied your patch and tried but it doesn't change anything.

Here is dmesg output and phytool results.

https://paste.aplu.fr/?9735c99907528929#SeCgwR45cgnbDA1tXIVBHCBT8RNct2r41jU6vsguLVc=

-- 
Aymeric