**** BEGIN LOGGING AT Thu May 02 02:59:57 2019 May 02 04:42:47 toolchain breaks on arch because of the python dependency May 02 04:43:54 It took me longer than i would like to admit but finally figured just having python2 (package name) is not enough and I need the buildroot to KNOW that when it calls python it should use python2 May 02 04:47:17 some distros see it differently, but /usr/bin/python being anything other than python 2 is the problem and mistake here. just like python 3 can't be anything other than /usr/bin/python3, as they're effectively different language May 02 04:55:09 isnt python 2 being phased out May 02 04:55:15 and near deprecation ? May 02 05:13:07 jeffsf: https://images-na.ssl-images-amazon.com/images/I/61UnKS2I-0L._SL1000_.jpg May 02 05:13:33 do you reckon replacing those internal antennas with external ones would improve range? May 02 05:13:47 also that big heatsink is nowhere to be found (I opened up my unit) May 02 05:14:52 thagabe: yes, but that doesn't change that all python2 applications written in the past use the /usr/bin/python shebang and expect that interpreter to be python2 May 02 05:15:16 just like all python3 applications written so far expect their interpreter to be /usr/bin/python3 May 02 05:16:00 touche May 02 05:16:04 when python2 is being phased out, /usr/bin/python ought to disappear. with /usr/bin/python3 remaining as such 'for all eternity' May 02 05:16:29 in the end these decisions are up to the individual distributions May 02 05:16:30 So what's openwrt roadmap? getting the offending packages to update to python3? May 02 05:16:58 but trying to redefine /usr/bin/python as python3 is painful, providing the maximum amount of breakage at best May 02 05:17:28 I think arch is symlinking /usr/bin/python to python3 May 02 05:17:32 afaik most of OpenWrt can already use python3 (via /usr/bin/python3), with the remaining bits and pieces being purged May 02 05:19:17 but I still have both on my system and not that much of a snake charmer May 02 05:20:36 so im about to jump off a bridge jk but still May 02 05:20:55 make download then make -j1 V=99 looks like it might complete the build May 02 05:21:16 make -jX(any number) V=s leads to build error May 02 05:21:19 REEEEEE May 02 05:21:44 the only difference is I enabled logging May 02 05:25:58 those issues are a race condition of building at high concurrencies, basically a missing dependendency. what happens is that enabling loggins can change the timing every so slightly already - and -j1 is the brute force approach of avoiding all concurrenceny, making the build nicely predictable and slow (sidestepping many of the dependency issues); same goes if you continue a previously failed build, May 02 05:26:04 as it will continue where you left it, rather than starting all over again May 02 05:28:15 annnnnnd it built May 02 05:28:18 sigh May 02 05:31:34 I just dont understand how it reaches a race condition on arch in baremetal with the same number of cores allocated vs my virtual machine with the same amount of cores May 02 05:32:17 because virtualized cores are slower (even if ever so slightly, albeit in practice the delta is significant) than baremetal ones May 02 05:32:55 im still using amd-vt May 02 05:55:13 blogic: i sent a small procd patch, can you review it, please? May 02 05:55:59 https://patchwork.ozlabs.org/patch/1093590/ procd: add procd_running() helper for checking running state May 02 06:02:36 rmilecki: looks good please consider jow's comment May 02 06:03:21 procd already has the filter capability inside itself May 02 06:03:45 blogic: i think Jo missed one line of my patch May 02 06:03:51 json_add_string name "$service" May 02 06:04:10 it's how _procd_ubus_call() works - it uses JSON that was built before calling it May 02 06:04:23 ah ok, missed it aswell May 02 06:04:29 :) May 02 06:29:30 nbd: how does the swconfig code in OpenWRT relate to the switchdev support that's now in upstream kernels? May 02 06:29:33 asking you since you touched it last :) May 02 06:30:39 ot at all May 02 06:31:00 dwmw2_HFA: swconfig is more a switch vlan trunking setup feature May 02 06:31:15 while DSA tends to use the magic tags that most switches offer May 02 06:31:23 dwmw2_HFA: if possible dsa should be used May 02 06:32:07 dwmw2_HFA: i have considered in the past to write a vlan based dsa driver for switches without magic tag support that would hide the vlan carnage away inside dsa and provide switchdevs even for those fabrics May 02 06:32:58 aha, thanks May 02 06:33:07 DSA is probably what I was looking for, and it even has documentation :) May 02 06:34:20 blogic:ping May 02 07:01:40 dwmw2_HFA: hi May 02 07:01:47 dwmw2_HFA: it is May 02 07:04:13 'lo May 02 07:27:03 Realtek Contributes New "RTW88" 802.11ac WiFi Driver To The Linux Kernel May 02 07:27:07 https://www.phoronix.com/scan.php?page=news_item&px=Realtek-RTW88-WiFi-Linux-Driver May 02 07:27:53 RTW88 is the successor to the long-in-standing RTLWIFI driver. May 02 07:28:55 what about rtlwifi? May 02 07:29:05 rtlwifi-supported devices? May 02 07:29:55 another driver nuked from staging May 02 07:29:55 cool May 02 07:45:40 The new driver will replace rtlwifi- they say. It will be a wile before we know if it's any good. May 02 07:46:16 The new driver is 14000 lines of code and the rtlwifi driver is about 122000 lines. May 02 07:47:28 as the new driver only works with 2 chipsets so far OpenWrt mite have to use both drivers for a wile. May 02 07:48:12 OpenWrt will onley have to use it when we moov to kernel 5.2 I think May 02 07:51:19 Tapper: do we use staging wireless drivers from kernel or backports? May 02 08:11:17 nbd: blogic: https://patchwork.ozlabs.org/patch/1092248/#2163750 do you still remember why there was mtd-mac-address node added to the DT, so it could be accessed from sysfs/userspace? I can't find any use of this in the current OpenWrt tree, so I don't know exactly what to put in the reply to Rob May 02 08:12:31 nbd: blogic: From my understanding of all this so far, it seems, that it was simply put there in order to stay consistent with currently supported address, mac-address and local-mac-address DT properties May 02 08:47:51 rmilecki: no, none of the staging realtek drivers is AP capable (that is technically incorrect, but those need a custom realtek hostaod driver backend, which in turn requires a custom hostapd 0.4.8 fork to work, so non-functionabblel May 02 08:48:15 ok, thanks May 02 08:49:56 Tapper (in his absence): rtw88 doesn't replace any staging driver, it just covers new USB devices, all existing staging drivers are for older hardware and need to remain (probably indefinatelyl May 02 08:53:29 only two realtek staging drivers have ever made it out of staging so far, rtl7187se (aka rtl8185b) --> rtl8180l and rtl8192eu --> rtl8xxxu May 02 08:54:11 pkgadd: ah, I was wondering if stuff like the RTL8327BE would get dropped May 02 08:54:51 and rtl8xxxu would be a more logical choice for the existing (USB) staging drivers (but I don't see anyone wirking on that) May 02 09:00:27 I heard realtek code used to be write-only, does this apply? May 02 09:07:49 Any hints as to getting /dev/spi* to appear (ath79)? May 02 09:08:12 I've added &spi nodes for spidev0: device@0 and 1, but nothing in /dev/ May 02 09:08:45 spidev kmod is loaded May 02 09:09:34 check dmesg May 02 09:15:12 NOR and NAND chips seen, as before, but now have `ath79-spi 1f000000.spi: chipselect 0 already in use` `spi_master spi0: spi_device register error /ahb/spi@1f000000/device@0` May 02 09:15:41 which I am assuming is that the device an the chip can't coexist the way I've set up the DTS May 02 09:16:00 I'm hoping to poke at the chip with SPI tools May 02 09:16:14 but wasn't seeing /dev/spi* prior May 02 09:16:42 then boot from net/ramfs May 02 09:17:50 Device boots from NOR OK, detects NAND (including chip MID/DID), just need to be able to poke at it to figure out why it isn't providing the data I'd expect May 02 09:21:34 apparently you can't have two devices/drivers sharing same CS, so you need to solve this, so either use that CS for spidev or for mtd, but you can't have both at the same time May 02 09:23:01 OK, thanks -- appreciate the time May 02 11:03:09 i may need help with net subsystem May 02 11:03:25 i'm running OpenWrt with net(filter) improvements/hacks/backports reverted May 02 11:03:55 applying 274-flow_dissector-Parse-batman-adv-unicast-headers.patch lowers my NAT performance by 55 Mb/s May 02 11:04:56 it seems to be rather trivial patch May 02 11:05:04 and I DON'T use batman at all May 02 11:05:06 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/backport-4.14/274-flow_dissector-Parse-batman-adv-unicast-headers.patch;h=b0b2823cc9ef3acb1e17299ae5f33d33250fe638;hb=HEAD May 02 11:05:18 i never hit the "case htons(ETH_P_BATMAN)" case May 02 11:05:30 any hint what's going on there? nbd? jow? May 02 11:36:26 rmilecki: wild guess: function grows over some cpu caching boundary? Have you tried comparing the generated assembly? May 02 11:36:41 KanjiMonster: that's my guess to May 02 11:36:51 i have no much experience with such low level stuff May 02 11:38:05 or the additional case triggers some different/inefficient code generation. maybe gcc decided to inline the function (in that case you could try to set it to noinline or so) May 02 13:33:29 nice commit message in 450d44a8ead2217f8acf541a4eaa4ad560b3e5ac :) May 02 13:35:57 we went ahead with engine on, no need for packages to support engine off right? May 02 13:36:12 engine off is now only for people doing their own thing? May 02 13:39:48 good morning May 02 13:43:45 karlp: the problem with turning engine support off by default is thta packages will not compile differently depending on engine support. libp11 does not compile without engine support at all, and was selecting OPENSSL_ENGINE May 02 13:45:06 So in practice, it was always on for the buildbots. Many people then were compiling their own images without engine support, but encountered errors when installing packages from the official feeds build. May 02 13:47:26 Removing libp11 would apparently be a fix, but downloading packages from the bot-built feeds would not be sufficient to use the engines. So, in practice, if you want a different engine configuration, you have to compile and install everything yourself anyway. May 02 13:48:57 openssl is already a beast, so adding a few kb for engine support is not that relevant for most people. Those who care, can build and install their own packages. May 02 13:51:41 The problem never showed up before, because the option to turn engines off is no-engine, and we were using no-engines in plural, so it was never off before. May 02 13:54:05 As for packages, I would recommend to allow a build without engines, as we still give that option to the users. May 02 14:09:04 last nfs-server update is not working May 02 14:09:18 showmount -e 192.168.0.99 May 02 14:09:20 clnt_create: RPC: Unable to receive May 02 14:09:33 hsp: report it on github May 02 14:09:45 url? May 02 14:29:52 * jeffsf fighting with mtd and losing May 02 14:30:51 Though I am learning more than I ever wanted to do about Linux drivers May 02 14:41:53 * ldir has been coding kernel module stuff again, along with userspace updates. This actually means 'typing semi-random stuff, slapping head at silly mistakes and editing till the compiler shuts up' May 02 14:42:49 now we see if it works - If I'm not back soon you'll know that I can't code May 02 14:49:46 http://www.524wifi.com/index.php/compexwrt May 02 14:54:26 * ldir manages an in-place module & user space upgrade - and it didn't crash May 02 14:54:55 :P May 02 14:55:00 ldir: It's never your code, just that the stupid compiler didn't understand what your eloquent code really ment May 02 14:55:24 jeffsf: no, honestly... it's my code :-) May 02 14:57:31 * ldir discovers a silly in userspace - printing a packet count in hex probably isn't the most user friendly form of output :-) May 02 14:58:36 depends from context... often times it is way better than base10 May 02 14:58:55 but ought it represent other than numbers, then. no :D May 02 15:26:31 have a good evening guys! :) May 02 15:50:31 cotequeiroz: specifically, I've got a package upgrade that has added support for engines, but isn't compiling when engine support is off. May 02 15:50:53 I'm trying to figure out whether I care about supporting that usecase or not. May 02 16:31:58 If you give me an URL, then I maybe I can help you with it. If not, go ahead and depend on OPENSSL_ENGINE. It should not be hard. It is usually some unnecessary initialization calls that get added, and they are easy enough. May 02 16:32:58 libp11's case is more complicated as it adds an engine, so it is a real requirement. May 02 16:36:30 I've mentioned it upstream, as they fixed a case of it nbot building with engine support for a few releases back, but they've since expanded it and didnt' cover all bases. **** BEGIN LOGGING AT Thu May 02 20:00:20 2019 May 02 21:39:59 changing the cpufreq governer on ipq40xx makes a big difference in wifi performance May 02 21:41:01 abenz: From what to what and which is better? May 02 21:41:02 I will permanently run the router with max freq May 02 21:41:15 heh, someone in linux-sunxi reports that changing governors results in crashhhing/not crashing too :) May 02 21:41:40 jeffsf: with performance governer, I consistently get 550mbps+ iperf results May 02 21:42:09 thanks May 02 21:42:14 remember the other day we were discussing speeds and I mentioned how I get 400ish and sometimes random peaks May 02 21:42:37 Yeah, that might explain some of that May 02 21:42:40 was thinking about swapping the internal antennas with something better, but the inconsistent behavior was due to CPU freq scaling May 02 21:44:15 with it set to performance, wifi speed almost feels like it surpasses stock firmware (ie with qca wlan drivers) May 02 21:44:48 Where is the governor exposed these days? May 02 21:45:08 cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor May 02 21:45:28 echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor May 02 21:46:01 Yeah, mine's running ondemand -- which could explain why the iperf runs are slower at start May 02 21:46:10 I did the test with irqbalance running as well May 02 21:46:14 do you use it? May 02 21:47:30 I have another ipq40xx, I'm setting up a wireless bridge between them and will do a run, just to see how fast they can push May 02 21:48:03 Haven't really tuned it at all -- spent my time making sure the wireless range was reasonable for the FCC and EU board files May 02 21:48:51 You're dusting off old memories of trying to balance phone performance against battery life and tweaking those parameters seemingly endlessly May 02 21:49:10 hah May 02 21:49:38 Waiting on chunkeey's next round of feedback before I dive back into the EA8300. May 02 21:50:14 Staring at SPI NAND data sheets "for fun" trying to get spi-nand on ath79 on 4.19 running for my GL.iNet AR750S May 02 21:51:59 I'm following your progress on dsa! May 02 21:52:48 results of two ipq40xx iperf: https://pastebin.com/pmnQ6ZWj May 02 21:52:52 I'm following its progress upstream! ;) May 02 21:53:09 iperf3 -c -P5 May 02 21:53:34 the -P5 is important to really get the full speed, with a single stream, I get about 420 May 02 21:53:49 with 5, I get 550, peaking at 560mbps. Not bad! May 02 21:54:23 Cool, that seems similar to what I was getting with the MacBook to a wired Debian box May 02 21:54:25 about 4m distance between the units May 02 21:57:42 Ok, time for me to sleep here -- thanks for the info! **** ENDING LOGGING AT Fri May 03 02:59:57 2019