09:40 <micken> anarsoul: is it possible to make el1 aarch32 secure from aarch64?

09:41 <micken> anarsoul: I need neon on aarch32 , and it seems disabled and I can't enable it

20:02 <sphalerite> Hi folks. I've got a nanopi m4 and its networking seems to drop out in mysterious ways. Unloading and reloading the dwmac_rk module makes it work again, but I'd prefer for it to just stay reachable. The symptoms are somewhat odd as well — ping works just fine, but TCP connections just seem to hang.

20:03 <sphalerite> Any ideas?

20:24 <stikonas> sphalerite: IPv6?

20:25 <sphalerite> both I think, I'll need to try again next time it happens

20:27 <stikonas> sphalerite: well, on rockpro64 I disable tx offloading

20:27 <stikonas> then IPv6 starts working again

20:28 <sphalerite> aah, good to know

20:28 <stikonas> https://stikonas.eu/files/gentoo-sources/0002-Disable-tx-checksuming.patch

20:29 <stikonas> maybe if you patch your dts file, it will also work

20:29 <stikonas> although you need ot patch the one for nanopi, not rockpro

21:48 <anarsoul> stikonas: why not to submit it usptream? I have the same issue on my rockpro64 with ipv6

21:54 <stikonas> anarsoul: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/636614.html

21:56 <anarsoul> mmind00: ^^ it's been sitting there since march

21:56 <stikonas> but I think I got it from somewhere else too

21:56 <stikonas> well, there are many patches like this, even in commit, a similar patch for other board is mentioned

21:57 <stikonas> I probably should have sent that patch to more lists

21:57 <anarsoul> I think it'd be better to disable it for all the rk3399 boards in rk3399.dtsi

21:57 <anarsoul> stikonas: did you use get_maintainer.pl? :)

21:57 <stikonas> probably not then

21:57 <stikonas> later I started using it

21:57 <stikonas> well, feel free to steal patch

21:57 <stikonas> and do this in dtsi

21:58 <anarsoul> I'd better spend some time on lima this weekend

21:58 <anarsoul> :)

21:58 <mmind00> In any case, we had also had a big number of gmac-related stability patches that overlayed each other and caused long discussions ... I think at least for rk3328 also there was another better solution discovered in a later iteration

22:00 <mmind00> for example https://patchwork.kernel.org/patch/10906137/

22:01 <mmind00> stikonas anarsoul: in this case it might be worth to also look at, as that txpbl is a smaller hammer compared to force_thresh_dma_mode

22:03 <stikonas> I think I saw some of that discussion, that's why I didn't resubmit my patch

22:04 <anarsoul> but that's for rk3328

22:04 <anarsoul> not rk3399

22:05 <stikonas> anarsoul: this weekend I'm also doing some packaging work... Creating gentoo overlay to bootstrap OpenJDK from C++

22:05 <stikonas> hmm, is txpbl rk3328 specific?

23:29 <robmur01_> nanopi M4 almost certainly needs the rx-delay/tx-delay tweaking

23:30 <robmur01_> since that depends on the board layout, and the upstream DT is based purely on the schematics ;)

23:34 <robmur01_> micken: a lot of system registers have traps to EL2 - you'll want to make sure those are disabled