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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 23 Jun 2019 20:16:59 +0200
From:   Aymeric <>
To:     Heiner Kallweit <>
Cc:     Martin Blumenstingl <>,,
Subject: Re: network unstable on odroid-c1/meson8b.

Le 20/06/2019 à 22:54, Aymeric a écrit :
> 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
>>> [¹]:
>>> [²]:
>>> [³]:
>>> [⁴]:
>> The vendor kernel has some, but not really much magic:
>> 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.
Hello all,

I had some news from a friend who have the same issue than me, his board
is connected to an "intelligent" switch a Ubiquiti EdgeSwitch.

Also, when he force the link to 100 it is stable.



Powered by blists - more mailing lists