07:28 <narmstrong> BlueMatt: can you log the changes between 4.19.57 and 4.19.68 ?

07:30 <narmstrong> f47f68cc9d33 net: stmmac: Re-work the queue selection for TSO packets

07:30 <narmstrong> 41864adfee2e net: stmmac: sun8i: force select external PHY when no internal one

07:30 <narmstrong> df6680de7a20 net: stmmac: dwmac4/5: Clear unused address entries

07:30 <narmstrong> 50331c64f3dd net: stmmac: modify default value of tx-frames

07:30 <narmstrong> 1a0a837afc41 net: stmmac: dwmac4: fix flow control issue

07:30 <narmstrong> d3969670cb5a net: stmmac: dwmac1000: Clear unused address entries

07:30 <narmstrong> 9b7b0aab4750 net: stmmac: set IC bit when transmitting frames with HW timestamp

07:30 <narmstrong> a373bf728188 net: stmmac: fixed new system time seconds value calculation

07:31 <narmstrong> either you test at each commit, or you git bisect from 4.19.57 to 4.19.68

19:12 <BlueMatt> narmstrong: sadly it takes a day or two before I see the timeout :/

19:12 <BlueMatt> I can maybe start the process this weekend on one of my spare odroid-c2s, but its pretty reliable after a few days with maybe 10M/s of traffic it will hang

20:16 <narmstrong> BlueMatt: we used a lot iperf3 to trigger issues in the ethmac, can you try tweaking options to make it more agressive and trigger the timeout ?

20:30 <repk> isn't it weird that pci-meson's way of deasserting PERST is with "gpiod_set_value_cansleep(mp->reset_gpio, 1);" ?

20:36 <sgnut> someone from the #odroid channel has explained me that cpufreq governor is not available for mainline kernel yet. Is this correct? I have just compiled a 5.2.11 for my odroid-c2 soc and I discovered that I haven't any entry in /sys regarding cpufreq

20:56 <xdarklight> repk: it's likely that someone screwed up the GPIO polarity in .dts and "fixed" that by swapping the polarity in the driver again to make it work

20:58 <xdarklight> sgnut: yes, unfortunately Odroid-C2's SCPI (system control processor interface) firmware (which is responsible for frequency CPU scaling) reports frequencies as supported which don't work if all 4 CPU cores are enabled -> this leads to system hangs

20:59 <xdarklight> sgnut: my personal opinion is that it's a bug in the firmware. if I remember correctly there's a setting in boot.ini to set the number of active CPU cores - the firmware should honor that

21:03 <sgnut> xdarklight: yes there is a maxcpus directive. So, is there any plan to port the cpufreq governor to the mainline kernel in the same manner that currently works for other versions (e.g. 3.4). I suppose that such kernel versions use some kind of tricks, like the one of the maxcpus

21:10 <xdarklight> sgnut: I don't know of any plans to add support at the moment because this problem is limited to the SCPI firmware that's shipped in Odroid-C2's u-boot. no other Amlogic board (that I know of) has this firmware issue

21:14 <sgnut> xdarklight: does hardkernel considered any option to upgrade the firmware?

21:16 <xdarklight> sgnut: I think they are the ones who changed the firmware. (it's been a while, but I think early u-boot revisions didn't have this problem, it only appeared after HardKernel tried to do some "overclocking" optimizations)

21:21 <sgnut> xdarklight: mmm so how the current official versions don't suffer such problem? Just by appling some tricks like the one that we commented (maxcpus)?

21:24 <xdarklight> sgnut: I think the official firmware "hardcodes" maxcpus to 4 and so they only report the frequencies which are supported with that core count. I don't know if there's an actual maxcpus check in the firmware or if it's due to them hardcoding maxcpus (so they can also hardcode all other values)

21:44 <xdarklight> sgnut: it's been 2.5 years where Neil disabled DVFS and I even informed the HardKernel guys about this issue: https://patchwork.kernel.org/patch/9500175/ (I didn't ping them again because I don't have an Odroid-C2 myself so I cannot do any testing if they ask for it)

21:44 <xdarklight> sgnut: more information on that topic: https://patchwork.kernel.org/patch/9555763/#20107671

21:45 <xdarklight> sgnut: maybe you ping the HardKernel guys about this again and ask them if they can come up with a solution for mainline Linux? enabling CPU frequency scaling in Linux will then be super easy: just revert the meson-gxbb-odroidc2.dts part from https://patchwork.kernel.org/patch/9500175/

21:53 <sgnut> xdarklight: do you think that it could be possible that users upgrade the firmware. Isn't require some kind of hardware manipulation?

21:55 <xdarklight> sgnut: it's part of the bootloader binary in the first sectors of eMMC / SD card. so it can be upgraded

21:57 <sgnut> xdarklight: ohhh you mean the u-boot that I changed just by using the dd command. So. it seems something easy. I don't understand why hardkernel has not provided a solution

22:11 <xdarklight> sgnut: yep

22:12 <xdarklight> sgnut: (it's a multi-stage boot process though, so the bootloader binary contains more than "just" u-boot, see here for more info about the closed-source parts that are included: https://github.com/u-boot/u-boot/blob/master/board/amlogic/p200/README.odroid-c2 )

22:21 <sgnut> xdarklight: thank you very much for all the information :)

22:43 <sgnut> xdarklight: thank you again :)

22:43 <sgnut> c u