**** BEGIN LOGGING AT Sat Jan 02 02:59:56 2021 Jan 02 03:40:00 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 97.0% packages reproducible in our current test framework.) Jan 02 05:22:32 mangix: hey, i was trying to use perl-www tonight and saw it is missing a dependency on Try::Tiny, which does not appear to be available in packages.git. the bump from 6.15 -> 6.39 (https://github.com/openwrt/packages/commit/a9ad795) in 11/2019 broke it. i checked upstream git and it was added in 6.17: https://github.com/libwww-perl/libwww-perl/blob/master/Changes#L177-L181 Jan 02 05:23:07 i will try to package it locally and see if that fixes things. Jan 02 05:24:39 the needed module thankfully is as advertised, tiny, and appears to require no external dependencies. Jan 02 06:23:37 eh, i was going to open a PR, but getting around to testing it, it's still broken at runtime sooo Jan 02 06:24:31 strace shows it's opening a udp conn to localhost 65535, example code does this: 500 Can't connect to search.cpan.org:80 (System error) Jan 02 06:30:29 ah it's just the lack of ipv6 that's making it unhappy. adding BEGIN { $Net::HTTP::SOCKET_CLASS = 'IO::Socket::INET'; require Net::HTTP; } fixed it. i'll open that PR. Jan 02 06:38:17 mangix: btw https://github.com/openwrt/packages/pull/14406 Jan 02 07:56:29 m4t: i don't use perl hence the breakage :) Jan 02 09:40:47 exit Jan 02 09:49:22 i started looking at packaging Net::SSLeay to give it https support, but getting it to cross compile is going to require some doing Jan 02 09:49:44 it Jan 02 09:50:16 's an xs module that links against openssl but makes all sorts of assumptions and does checks like running /usr/bin/openssl to figure out which version it is Jan 02 13:31:53 has anyone built today's or yesterday's master after the wolfssl bump? Jan 02 13:32:08 hostapd still breaks for me on ath79. Jan 02 13:33:06 similar to https://bugs.openwrt.org/index.php?do=details&task_id=3553 Jan 02 13:34:05 issue still persists after hauke's fixup Jan 02 13:34:35 * russell-- doing a build right now Jan 02 13:35:37 i've done multiple make package/hostapd/{clean,compile} runs, same for wolfssl Jan 02 13:36:36 weirdly enough ramips etc all seem ok. seems it's just wpad-full-wolfssl breaking on ath7 Jan 02 13:36:39 * ath79 Jan 02 13:37:34 bug report says mips_24kc as well so maybe he has ath79 as well but not clear at all Jan 02 13:40:16 Borromini: i just pushed a fix for it, please test Jan 02 13:48:08 Borromini: this is a diffeernt problem ;-) Jan 02 13:48:40 Hauke: oh :P Jan 02 13:54:50 nbd: thanks, that fixes it indeed Jan 02 13:59:25 nbd: I updated my pull request with your changes: https://github.com/wolfSSL/wolfssl/pull/3610 Jan 02 15:10:24 build #710 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/710 Jan 02 16:16:51 build #687 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/687 Jan 02 20:05:14 is it ok to open a draft PR (https://github.blog/2019-02-14-introducing-draft-pull-requests/) to packages.git just to test how stuff builds on other archs? Jan 02 20:07:05 (well, with the intention of opening a formal PR later) Jan 02 20:11:00 surprisingly to me, Net::SSLeay compiles by just patching out the hard-coded stuff / /usr/bin/openssl version check, and instead setting the variables in Makefile.PL using `$ENV{PKG_CONFIG} ... openssl` Jan 02 20:15:06 m4t: Why don't you fork the repository and enable Github Actions for your repository? Jan 02 20:15:21 i can try that, thanks Jan 02 20:15:29 that's sufficient ? Jan 02 20:17:31 * m4t tries opening a PR against his own fork Jan 02 20:17:59 oh, well, i guess actions are enabled, but not configured Jan 02 20:18:29 https://imgur.com/a/EdHxuWo Jan 02 20:19:24 i guess i need to import this: https://github.com/tofurky/packages/blob/master/.github/workflows/multi-arch-test-build.yml Jan 02 20:23:03 okay, nevermind, opening a PR against myself did trigger the build test Jan 02 20:25:11 that's pretty slick actually Jan 02 21:03:30 i noticed some weirdness with openssl, where if it's compiled without engine support, things break. commenting out the following in /etc/ssl/openssl.cnf fixes it: engines=engines. i wonder if that should be commented out conditionally on CONFIG_OPENSSL_ENGINE? Jan 02 21:35:21 Hauke: I can reproduce some network hang as described in https://github.com/openwrt/openwrt/pull/3085 Jan 02 21:36:13 Hauke: steps to reproduce: fire up my O2 6431, run "iperf3 -s" on my computer, start iperf3 -c on the board until data transfer stops Jan 02 21:36:41 Hauke: I checked /proc/interrupts, the xrx200_net_rx counter is still increasing but xrx200_net_tx is stuck Jan 02 21:53:08 Hauke: still around? Jan 02 23:00:57 Hauke: hmm, sorry I had an old image laying around which I flashed. the actual problem that I am seeing is that LAN port 2 (which is the same port used on the 7412) does not see any RX. the three other GPHY PHY22F ports are working fine, only this one is defa Jan 02 23:01:03 s/defa/deaf/ Jan 02 23:06:11 Hauke: ethtool -S output which shows that there's indeed no RX: https://pastebin.com/raw/uhPAQ8Wj Jan 02 23:38:06 aparcar[m]: yes Jan 02 23:39:16 xdarklight: which port on the switch is LAN port 2? Jan 02 23:39:31 Hauke: also on port two actually Jan 02 23:40:10 ok let me check if the configuration is correct Jan 02 23:40:54 xdarklight: which dts file is this? Jan 02 23:41:12 Hauke: vr9_arcadyan_vgv7510kw22.dtsi Jan 02 23:44:04 xdarklight: the mac 3 is working fine? Jan 02 23:44:42 Hauke: yep, I've tested all three other LAN ports and these are working fine for me. I have not tested the WAN port though (it uses an external RMII PHY) Jan 02 23:45:47 xdarklight: is the link up when you plug in the cable? Jan 02 23:46:06 there is no mux between the mac and the phy Jan 02 23:46:27 Hauke: yes: gswip 1e108000.switch lan2: Link is Up - 100Mbps/Full - flow control rx/tx Jan 02 23:46:33 if the ethtool counters are not counting anything I assume the PHY has a problem Jan 02 23:47:04 Hauke: for comparison with port 1: gswip 1e108000.switch lan1: Link is Up - 100Mbps/Full - flow control rx/tx Jan 02 23:47:14 (looks identical to me) Jan 02 23:55:47 xdarklight: can you please post the porbing results on the phys Jan 02 23:57:25 Hauke: https://pastebin.com/raw/1DsgRTaH Jan 02 23:59:00 xdarklight: the phy addresses are mixed up Jan 02 23:59:17 0x11 is MAC 3, 0x12 is mac 2 Jan 03 00:02:23 Hauke: that's weird. according to Daniel's u-boot sources EASY220 also uses 0x11 -> 2 and 0x12 -> 3: https://github.com/danielschwierzeck/u-boot-lantiq/blob/openwrt/v2014.07/board/lantiq/easy220/easy220.c#L63 Jan 03 00:03:03 xdarklight: ah sorry I am worng Jan 03 00:06:30 Hauke: I also found this in the out-of-tree driver: https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/patches-5.4/0025-NET-MIPS-lantiq-adds-xrx200-legacy.patch#L1702 - it's always setting MII_CFG_EN which is BIT(14). the upstream driver uses GSWIP_MII_CFG_LDCLKDIS which is BIT(12) instead Jan 03 00:12:52 xdarklight: the GSWIP_MII_CFG_EN is done in the gswip_phylink_mac_link_up() function Jan 03 00:13:33 Hauke: yes, but it's only done for three ports while the out-of-tree driver did it for all ports. I'm not saying that the out-of-tree driver is right though, just that it seems different to me Jan 03 00:13:33 but can you remove the check and do the enable in gswip_phylink_mac_link_up() always Jan 03 00:16:39 we could also set the MII rate explicitly Jan 03 00:22:11 Hauke: hmm, can you please check in the datasheet if GSWIP_MII_CFG0, GSWIP_MII_CFG1 and GSWIP_MII_CFG5 are all available MII_CFG registers? Jan 03 00:22:34 Hauke: from the "old" out-of-tree driver it seems that there's on MII_CFG register for each port Jan 03 00:22:54 (well, every port except the CPU port which is 6. so it seems that there's registers for 0..5) Jan 03 00:24:02 xdarklight: ah yes this is wrong there is a MII_CFG for each port, but only a MII_PCDU register for the 3 Jan 03 00:24:15 Hauke: aah :). let me try to fix that and see if that makes it work Jan 03 00:41:26 xdarklight: could you please try this patch: https://pastebin.com/0J1KQnay Jan 03 00:41:32 I do not know which part is needed Jan 03 00:41:59 the MII rate is always set to 25MHz, this will only work with 100MBit/s PHYs Jan 03 00:42:45 Hauke: https://pastebin.com/627bdDgu is compiling already. after that I'll try the gswip_phylink_mac_link_up hunk from your patch and in a third step I'll try the gswip_phylink_mac_config hunk from your patch Jan 03 00:43:31 xdarklight: good Jan 03 00:46:41 Hauke: also something we can keep in mind: the out-of-tree driver used explicit full duplex/link up settings while we use GSWIP_MDIO_PHY_FDUP_AUTO/GSWIP_MDIO_PHY_LINK_AUTO. again, not saying that there's a problem here, it's just different Jan 03 00:50:45 Hauke: also one more fun fact: the brnboot bootloader on my device lights up the LAN2 LED for some reason. this is also the port which is causing problems. whether it's coincidence or not: the image is flashing currently... so I'll be able to tell in a few minutes whether my patch already fixes it or if more changes are needed Jan 03 00:53:43 Hauke: progress. now all ports are broken ;) Jan 03 00:55:05 xdarklight: your change broke all of them? Jan 03 00:55:17 Hauke: yep Jan 03 01:03:46 xdarklight: in gswip_phylink_mac_link_up() the ports are not activated if they are connected to the internal PHY Jan 03 01:04:13 Hauke: yep, that's why I am now recompiling with the gswip_phylink_mac_link_up hunk from your patch Jan 03 01:04:40 the auto mode for the MII rate should work, the MDIO auto polling should be activated Jan 03 01:05:32 Hauke: I want to test one at at time, that's why I haven't added the GSWIP_MII_CFG_RATE_M25 hunk yet. I am wondering if we could use GSWIP_MII_CFG_RATE_AUTO instead of GSWIP_MII_CFG_RATE_M25 and do that for all modes and ports Jan 03 01:05:59 yes GSWIP_MII_CFG_RATE_AUTO shouold work on all ports Jan 03 01:06:07 it should be the hardware reset valie Jan 03 01:06:19 the MDIO auto polling will select the correct value Jan 03 01:07:27 Hauke: OK, then if GSWIP_MII_CFG_EN doesn't fix it I'll try this: https://pastebin.com/eNiP35FZ Jan 03 01:15:41 Hauke: works even without GSWIP_MII_CFG_RATE_AUTO :) Jan 03 01:15:53 I'll prep patches and send them to -net Jan 03 01:17:30 GSWIP_MII_CFG_RATE_AUTO should be the default Jan 03 01:18:21 thanks Jan 03 01:22:23 I'll send the patches now and let iperf3 run over night and see if anything breaks Jan 03 01:46:04 Hauke: also the LGM team is still upstreaming things. for example the dmaengine driver - which could replace our arch/mips/lantiq/xway/dma.c copy: https://patchwork.kernel.org/project/linux-dmaengine/list/?series=402649 Jan 03 01:48:27 Hauke: also tomorrow I want to try and see if I can make Linux 5.10 (based on nbd's target/linux/generic/ patches) work on the lantiq target. that would allow me to play with the PCIe driver more easily than 5.4 Jan 03 02:01:04 U-boot "LZMA error" is usually due to kernel .img being too big, right? Jan 03 02:02:25 or more precisely phrased -- if I make my kernel uImage big enough, the breaking error will manifest as U-boot crying, "LZMA error," right? Jan 03 02:02:45 often, but not necessarily always (some bootloader lzma implementations are rather fragile, with things like dictionary sizes and similar slight interoperability issues) Jan 03 02:03:52 Alright, whew! I packed a bunch of tools into an initramfs and the person using it to flash Merakis could not get it to boot. Jan 03 02:04:58 so I guess I need to wait for OpenWrt 20.12 RC1 ... Jan 03 02:05:39 I wonder when that will be Jan 03 02:43:49 xdarklight: thanks for the link to the DMA driver, I was not aware of it Jan 03 02:44:56 xdarklight: as far as I know LGM has diffeernt DMA controllers in different versions, some could be similar to the one used in the old chips **** ENDING LOGGING AT Sun Jan 03 02:59:56 2021