**** BEGIN LOGGING AT Fri Oct 19 03:00:00 2018 Oct 19 04:35:08 what difference https://downloads.openwrt.org/releases/18.06.1/targets/brcm63xx/{generic,smp}? Oct 19 06:05:09 nbd: whats the deal with package/network/config/netifd/files/etc/hotplug.d/net/20-smp-tune ? It reportedly causes severe throughput regressions on xrx200 Oct 19 07:01:40 luaraneda: thanks for info Oct 19 08:08:29 greearb_: between the nic and the slot? Oct 19 08:08:51 I was considering buying that (the apu4b4 as I need the extra port) Oct 19 08:44:11 hey, is there any OpenWRT support for TP-Link Archer C2 AC900? Oct 19 08:44:18 This thing: https://www.tp-link.com/ro/products/details/cat-9_Archer-C2.html Oct 19 08:44:29 I can't find any openwrt info on this model. Oct 19 08:45:49 There's some info on AC750, but none for AC900 Oct 19 08:55:03 ah bummer, I have travel overlap, not going to make the summit this year :( Oct 19 08:57:55 jow: when i tested it ramips and another platform (on 4.9 back then) it improved routing performance considerably. it seems that there are some platform specific differences there and i need to redo my tests Oct 19 08:59:09 airwind: post wikidevi link or SoC name Oct 19 08:59:26 airwind: number of models mean nothing to support level Oct 19 08:59:42 airwind: the same model can use totally different hardware for V1 and V2 (just an example) Oct 19 08:59:48 stintel: kernel bumps pushed. i've added your tested-by to 18.06 - 4.14 Oct 19 09:03:21 xback: cool Oct 19 09:03:53 didn't get around to testing anything else yet, was late at work yesterday Oct 19 09:04:34 but our 2 firewalls are now running 18.06 with 4.14.77 :) Oct 19 09:14:46 stintel: did it fix your memleak? Oct 19 09:16:19 xback: difficult to tell yet Oct 19 09:16:46 I should really deploy some SNMP monitoring tool here Oct 19 09:17:28 the device from the graph I showed still needs to be updated (it's my device, not related to day job) Oct 19 09:18:24 rmilecki: I believe its this: https://wikidevi.com/wiki/TP-LINK_Archer_C2_v3.x Oct 19 09:19:37 although I'm not sure, I'll have to check the version on the sticker beneath the device Oct 19 09:20:11 airwind: please check because that are totally different hardwares (as I warned) Oct 19 09:20:38 yeah, I see; one of them is mediatek, other is atheros Oct 19 09:20:39 v1.x is MT7620A, v3.x is QCA9563 Oct 19 09:20:48 right Oct 19 09:21:09 are either of those currently supported? Oct 19 09:21:58 mt7620 is supported I believe Oct 19 09:22:02 err wait, I just noticed! Oct 19 09:22:22 TP-LINK Archer C2 v1.x = AC750 according to that page Oct 19 09:22:36 TP-LINK Archer C2 v3.x = AC900 Oct 19 09:22:40 we have ramips subtarget for mt7620 in target/linux/ramips/mt7620/ Oct 19 09:22:42 I definitely have the second one Oct 19 09:23:43 Interesting, it has an atheros chipset, I was confident it was a mediatek device Oct 19 09:24:08 QCA9563 is used by some supported devices it seems: Oct 19 09:24:10 grep -R -i "QCA9563" target/linux/ath79/* Oct 19 09:24:12 I'll verify it later by opening the device when I get back home Oct 19 09:24:25 airwind: do you just need to start hacking on it or find someone willing to hack on that device Oct 19 09:24:55 at least all important drivers should be there it seems Oct 19 09:25:08 hopefully it's just a matter of adding device specific code Oct 19 09:25:14 rmilecki: there's no ruch actually, I was just wondering, if I can install OpenWRT on it. I have this policy where I replace the router firmware on every device as soon as I buy it. Oct 19 09:25:36 but yeah, I might be able to play around with adding support Oct 19 09:25:58 great :) use that grep command I pasted above Oct 19 09:26:05 see how other devices with the same SoC are supported Oct 19 09:26:17 copy code for one of devices, adjust is, test it Oct 19 09:26:27 serial console is really recommended Oct 19 09:26:41 I have USB to uart cable Oct 19 09:26:51 gonna have to solder the pins though Oct 19 09:27:12 good :) Oct 19 09:36:07 so I tried adding CPU_TYPE btver2 to have an optimized build on my APU2, the directories in {build,staging}_dir have btver2 in them, but apparently my CFLAGS don't Oct 19 09:36:12 https://gist.github.com/10890e1f96eb4feaae57a016558ff1ee Oct 19 09:36:16 any idea what I am doing wrong ? Oct 19 10:16:18 Hi, is there any particular reason why there are no ath79 snapshot builds? https://downloads.openwrt.org/snapshots/targets/ Oct 19 10:17:41 russell--: nbd: KanjiMonster: luaraneda: 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up") Oct 19 10:17:48 i'll report it soon Oct 19 10:19:48 stintel: I think CPU_TYPE is only intended for (sub)targets, not profiles Oct 19 10:19:54 rmilecki: great find Oct 19 10:21:07 Never mind, I found the related forum dicussion by myself https://forum.openwrt.org/t/ath79-target-status/18614/19 Oct 19 10:44:39 rmilecki: so reverting that commit gets rid of the corruption issue in current versions? Oct 19 10:44:55 i didn't try reverting it yet Oct 19 10:45:05 I just double tested it (confirmed) Oct 19 10:45:20 and i'm looking for commit that caused one more minor warning Oct 19 10:45:23 probably unimportant Oct 19 10:45:35 but I want to track it now and forget about "git bisect" for a long time Oct 19 10:46:42 KanjiMonster: I see Oct 19 10:47:51 adding -march to CONFIG_EXTRA_OPTIMIZATION is not an option, if I forget to make clean after switching config, it's an invalid opcode fest afterwards Oct 19 10:58:28 nbd: it does not revert cleanly, not even from the 4.12.9 Oct 19 10:58:33 *4.12.14 Oct 19 11:05:05 stintel: on desktop at least, compiling with bdver2 (piledriver) makes negligible difference compared to x86_64 Oct 19 11:05:23 having said that if you see any difference pls share Oct 19 11:05:39 or is your goal enabling some uncommon extensions? Oct 19 11:06:02 abenz: no, just enabling any of the extensions Oct 19 11:06:08 I am playing around with suricata Oct 19 11:06:31 I see Oct 19 11:06:45 --build-info: SIMD support: none Oct 19 11:07:13 and performance is really sad, my APU doesn't handle 200Mbps with suricata and pf_ring Oct 19 11:07:18 apu2* Oct 19 11:07:40 so I want to test if that helps at all Oct 19 11:08:07 apu2 2GB or 4GB variant? Oct 19 11:08:10 4GB Oct 19 11:40:38 KanjiMonster: any idea if it would be easy to allow profiles to override CPU_TYPE ? Oct 19 11:41:03 I've been looking around but it all seems like voodoo and black magic to me lol Oct 19 11:47:01 stintel: I don't think profile should be able to do that - profiles are just for selecting the (default) package set and which images to build, not anything beyong that Oct 19 11:47:50 remember that the imagebuilder also uses these profiles Oct 19 11:50:16 so the only option would be to create a subtarget and duplicate most of x86/64 Oct 19 11:50:19 that's ... ugh Oct 19 11:50:37 then I might have to look into another distro after all Oct 19 11:51:56 since we're never going to accept an x86 subtarget just for CPU optimization Oct 19 11:52:37 surely there has to be a way we can easily make this possible Oct 19 11:52:43 without a subtarget Oct 19 11:55:06 stintel: what is the use case? Oct 19 11:55:26 I mean what kind of optimization do you mean which cannot be enabled by default for x86/64 ? Oct 19 11:55:30 jow: I just want an image for my apu2 with -march=btver2 Oct 19 11:55:50 stintel: devices share kernel and packages (binaries), so you can't have device change such configs Oct 19 11:55:55 and how would another distro (e.g. Debian) solve it? Oct 19 11:56:02 jow: I would just run Gentoo ;) Oct 19 11:56:12 Or do you mean stuff like Gentoo? If you build yourself you can as well build openwrt with a changed cpu type Oct 19 11:56:35 jow: the problem is that I cannot do it in CONFIG_EXTRA_OPTIMIZATION Oct 19 11:56:56 if I do, next time I build for another device and forget make clean it will break badly Oct 19 11:57:26 (been there already) Oct 19 11:57:48 okay Oct 19 11:58:45 now I understand your issue Oct 19 11:59:02 I can maintain a local subtarget that will never be accepted upstream, I just had hoped it would be possible with a profile, and we could add some stuff to include/target.mk, just only build generic Oct 19 11:59:23 maintaining out-of-tree stuff gets annoying fast :) Oct 19 12:00:19 profiles doing global changes is a big no-go, see the headaches we had with the UBI build stuff Oct 19 12:03:37 stintel: a "clean" solution might be a "custom cpu type" select in advanced options, which filters the available values based on the selected (sub)target Oct 19 12:13:51 hmmm Oct 19 12:24:37 huh, I'm being a potato Oct 19 12:24:41 can't find the iproute symbol Oct 19 12:26:03 IP Oct 19 12:26:04 ? Oct 19 12:26:39 stintel: that would also give those people that complain that their 34kc is only running 24kc binaries an option of getting the 34kc shown ;) (or ar71xx/ath79 users a way of building for 74kc without source modifications, with has actual benefits) Oct 19 12:26:54 stintel: yeah I did /ip Oct 19 12:26:56 it wasn't impressed :D Oct 19 12:27:12 dialog just stops working heh Oct 19 12:28:28 oh its under routing anyway found it Oct 19 12:29:23 KanjiMonster: yeah, something we can add with minimal maintenance overhead, and we simply don't use on the buildbots, would be nice Oct 19 12:30:23 so I *think*I figured out my panics Oct 19 12:30:47 its the weekend now at least, so I can turn things on one by one until it crashes again Oct 19 12:32:18 stintel: maybe add a new CPU_TYPES for (sub)targets to use for the available values for the CONFIG_CPU_TYPE select and use the CPU_TYPE as the default value, that way the select doesn't need to be updated for each new (sub)target Oct 19 12:33:57 for now I'm trying something simple like https://gist.github.com/stintel/c32de5130aba87dd6a0dd0370f7d08c0 but it doesn't work, seems I really don't understand all this makefile wizardry Oct 19 12:35:22 stintel: check rules.mk Oct 19 12:37:52 stintel: wouldn't a string option have the same issues as the EXTRA_OPTIMIZATION, i.e. retain the value even when switchting (sub)targets? Oct 19 12:38:40 KanjiMonster: I need to override CONFIG_CPU_TYPE as that is what's added in the directories in {build,staging}_dir Oct 19 12:39:13 but I can't use CONFIG_CPU_TYPE directly in config/* as it will be overwritten based on CPU_TYPE in target/subtarget Oct 19 12:54:01 arch/mips/kernel/machine_kexec.c: In function 'machine_kexec_init_argv': Oct 19 12:54:01 arch/mips/kernel/machine_kexec.c:76:2: error: ignoring return value of 'copy_from_user', declared with attribute warn_unused_result [-Werror=unused-result] Oct 19 12:54:05 copy_from_user(kexec_argv_buf, buf, size); Oct 19 12:54:05 ugh Oct 19 12:54:29 I should really stop being lazy and just changing the arch in menuconfig Oct 19 12:55:13 although that should probably not error Oct 19 13:01:32 stintel: try this instead of your patch: http://sprunge.us/Uls5VV Oct 19 13:01:51 stintel: this will simply make the hidden CONFIG_CPU_TYPE visible for editing when CONFIG_DEVEL is enabled Oct 19 13:02:50 the hidden symbol is predeclared as hidden string option in tmp/.config-target.in and generated by metadata.pl Oct 19 13:06:59 Hi has r71xx bin switched over to k4.14 yet? Oct 19 13:07:17 Still running k4.9 on my c7 Oct 19 13:07:44 Tapper: cat target/linux/ar71xx/Makefile Oct 19 13:08:54 Is that a yes or a know? Was just wanting to know what kernel I will get if i flash a new snapshot! Oct 19 13:09:35 [jwh@aurbuilder nspv2]$ grep KERNEL target/linux/ar71xx/Makefile Oct 19 13:09:35 KERNEL_PATCHVER:=4.14 Oct 19 13:10:37 thats master though, dunno if it got backported to release Oct 19 13:13:01 jow: I think I have tried it like that Oct 19 13:13:06 jow: but will try again, thanks Oct 19 13:19:49 jwh thanks Oct 19 13:21:54 hm, apparently we don't want to build today Oct 19 13:22:03 fresh config it is Oct 19 13:25:11 jow: ah, the problem with that is that make oldconfig overwrites previously set CONFIG_CPU_TYPE then Oct 19 13:25:49 hmm Oct 19 13:27:46 KanjiMonster: jow: thanks for the input/help on this btw, much appreciated Oct 19 13:39:08 jow: I now have this: https://gist.github.com/668b42bec16cc540818c85e0933ca684 and in .config CONFIG_CPU_TYPE="btver2" Oct 19 13:39:38 the build/staging dirs now contain btver2 in the name, but still no -march=btver2 in CFLAGS Oct 19 13:57:07 hi Oct 19 13:57:44 what crackerjack shit is this, opkg failing to install because of an unsatisified dependency on the kernel Oct 19 13:57:47 o___O Oct 19 13:57:51 rmilecki: ping Oct 19 13:58:06 xback: pong Oct 19 13:58:11 just noticed your mail Oct 19 13:58:20 i didnt know what you were talking about here on the channel Oct 19 13:58:27 I had this issue before on my imx6 boards Oct 19 13:58:36 could you test something? Oct 19 13:58:45 after step 5 in your mail, issue command "sync" Oct 19 13:58:54 it solved the issue for me when it happened Oct 19 13:59:36 it does workaround problem indeed Oct 19 13:59:48 russell-- noticed that already Oct 19 14:00:14 jwh: the dependency is failing on a specific kernel version Oct 19 14:00:19 it's the reason why i'm using rootflags=sync in my kernel options on ubi Oct 19 14:00:24 jow: its while building heh Oct 19 14:00:33 something is really out of whack with this tree Oct 19 14:00:50 note to self: use seperate build dirs, don't just change target Oct 19 14:01:52 xback: that will wear out your flash earlier Oct 19 14:02:02 correct, and reduce write speed Oct 19 14:02:04 (wear out? wear off?) Oct 19 14:02:12 ok Oct 19 14:02:13 but it was the only thing that worked to get rid of the issue .. more .. Oct 19 14:02:21 ideally we should have regression fixed and don't need that :) Oct 19 14:02:45 very true. I tought at first it was an issue typical for ubi Oct 19 14:04:20 the same effect was also seen when doing a simple reboot sometimes Oct 19 14:04:29 unless a "sync" was added in the reboot sequence Oct 19 14:41:22 * ldir has fond half memories of typing sync, sync, reboot in the late 1980s on Pyramid OSx... I think T series box. Oct 19 14:42:19 lol Oct 19 14:42:30 I still often do sync after stuff Oct 19 14:42:32 coz habit Oct 19 14:45:02 and the reason for typing sync twice was that by the time you'd run the 2nd sync it had actually flushed the buffers to the disc. Oct 19 14:45:08 ya Oct 19 14:50:06 * ldir goes all misty eyed for the amber glow of his Ampex 230 terminal. Oct 19 14:50:16 lol Oct 19 14:57:02 ADM-3a's rock. Oct 19 14:58:53 big improvement over the Honeywell Rosy-21. Oct 19 14:59:31 they rocked, but do they still? Oct 19 15:00:04 I remember seeing my first VT100, with WHITE CRT… and smart cursor functions so you could actually run Emacs over a 1200 baud modem and it didn't suck so bad… Oct 19 15:00:25 well, I'm willing to make a sentimental adjustment for them. Oct 19 15:06:48 I think we're all exposing our...searches for word... vintage here :-) Oct 19 15:07:28 it's sometimes ince to go back to these old things and re-remember all the reasons they got left there too. Oct 19 15:07:49 ha Oct 19 15:58:11 did somoene just approve a bunch of pending mail today or something? Oct 19 15:58:28 karlp: yes Oct 19 16:03:03 what on earth Oct 19 16:03:19 uci set network.wan.blah, uci delete network.lan, uci commit Oct 19 16:03:26 /etc/config/network remained untouched Oct 19 16:03:40 updated config there, commit, deleted the lan bit but left the wan Oct 19 16:03:44 am I going mad? Oct 19 16:11:20 meh. another package complaining about missing dependencies now (unixodbc): https://gist.github.com/44b87c60431dce124bf273f9ae655897 Oct 19 16:11:41 Package unixodbc is missing dependencies for the following libraries: libc.so.6 libpthread.so.0 Oct 19 16:12:02 DEPENDS:=+libltdl +libpthread Oct 19 16:13:50 stintel: libc.so.6 => was not cross compiled Oct 19 16:15:10 mangix: did you test unixodbc bump ? Oct 19 16:18:01 ugh, it builds when I revert it Oct 19 16:18:27 abenz, apu 4b4 can only do one pcie NIC, seems that is limit of pci lanes on their processor Oct 19 16:18:35 mini-pcie nic that is Oct 19 16:21:30 stintel: i tested building Oct 19 16:21:45 doesn't build for me Oct 19 16:21:48 I'm just going to revert it Oct 19 16:22:11 getting seriously tired of all the random breakage every time I try to build a new image Oct 19 16:22:17 we need better testing Oct 19 16:23:03 greearb_: I see. http://www.pcengines.ch/apu4b4.htm Oct 19 16:23:18 nod Oct 19 16:25:15 J14 (usb only), the middle mpcie, what kind of cards would one put there? Oct 19 16:26:11 msata could go in one, wifi NIC in other, and a usb wlan (mobile data) in the middle? Oct 19 16:26:20 eg the Eucetel lte module (although mcpie interface), requires kmod-usb-cdc-..etc. These cards? Oct 19 16:26:27 ah. I see Oct 19 16:27:13 ah Oct 19 16:27:20 it's an x86 compilation issue Oct 19 16:27:43 I guess travis doesn't build the x86 target Oct 19 16:27:53 no just ar71xx Oct 19 16:28:00 i test on mvebu Oct 19 16:28:16 does x86 use musl? Oct 19 16:28:36 yes Oct 19 16:29:12 lynxis: do you think travis config for the packages feed can be easily modified to also test building for x86 Oct 19 16:29:48 building x86 on x86 is a big risk for host lib leakage, so we should definitely have automated testing for this, imo Oct 19 16:30:03 x86 on x86 is a pain in the ass Oct 19 16:30:04 honestly Oct 19 16:30:07 lol Oct 19 16:30:16 somewhat less terrible if you use an opposing libc on the host though Oct 19 16:33:26 ugh Oct 19 16:33:37 make V=s takes forever on ryzen Oct 19 16:34:06 i think i need to overclock Oct 19 16:34:26 but it has so many cores omg! Oct 19 16:34:59 4.4GHz ftw :) Oct 19 16:35:15 it's somewhat acceptable on my box Oct 19 16:35:22 I'm rocking uh Oct 19 16:35:25 stintel: cannot reproduce a unixodbc build fail on x86 yet Oct 19 16:36:01 model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz Oct 19 16:36:01 cpu MHz : 2411.913 Oct 19 16:36:11 jow: this happened after `make clean` and I had several reliable failures with `make package/unixodbc/{clean,compile}` afterwards Oct 19 16:36:25 jow: additionally reverting the commit made the problem go away here Oct 19 16:37:05 I believe that, diffed the upstream tarballs and 90% is automake/libtool updates Oct 19 16:37:37 the shipped libtool also does things like -rpath /usr/lib again Oct 19 16:37:47 barf :( Oct 19 16:37:56 would be helpful to see a log though Oct 19 16:38:02 a failing one, that is Oct 19 16:39:03 stintel: do you have an "odbc-config" in your PATH? Oct 19 16:39:19 jow: it got overwritten and my wgetpaste was apparently incomplete. I'll try again after my image is built Oct 19 16:39:38 jow: /usr/bin/odbc_config Oct 19 16:39:44 can you invoke it? Oct 19 16:40:38 jow: https://gist.github.com/60c1891d61176caaf324b9eaea8d0eca Oct 19 16:42:33 ok. well I need a log and possible the tarred build_dir/target-*/unixODBC* Oct 19 16:42:39 when you've get to it Oct 19 16:42:52 s/'ve// Oct 19 16:46:06 stintel: recompiled again. compiles successfully Oct 19 16:46:26 on mvebu Oct 19 16:46:40 jow: https://www.linux-ipv6.be/OpenWrt/unixodbc.compile.txt Oct 19 16:47:54 hmmmm Oct 19 16:48:18 one thing that may be throwing off my results is that I enable PKG_ASLR_PIE globally Oct 19 16:48:20 stintel: libtool relink ... -L/usr/lib ... Oct 19 16:48:37 can you try PKG_FIXUP:=autoreconf ? Oct 19 16:50:07 also PKG_REMOVE_FILES:=aclocal.m4 m4/libtool.m4 Oct 19 16:50:57 you should see "OpenWrt-libtool: " instead of "libtool: " in the log then Oct 19 16:51:21 jow: apparently PKG_FIXUP:=autoreconf is enough Oct 19 16:52:18 should I try the other one alone, or combined with PKG_FIXUP? Oct 19 16:52:28 combined Oct 19 16:52:38 but its likely not needed Oct 19 16:52:53 yeah it works fine with just PKG_FIXUP:=autoreconf Oct 19 16:52:59 so once again it was proved; *never trust shipped libtool* Oct 19 16:57:49 I still wonder which problem libtool actually *solves* Oct 19 16:57:55 especially in 2018 Oct 19 16:58:13 jow: thanks a lot Oct 19 16:58:17 the few platforms unable to sane dynamic library linking should be dead by now Oct 19 16:58:21 pushed a fixed bump to packages feed Oct 19 17:01:14 * mangix checks faillogs Oct 19 17:01:20 friends don't let friends develop with autohell. Oct 19 17:01:48 oh cool. everything's broken Oct 19 17:02:11 more than last time. weird. Oct 19 17:07:08 libxml2 is fubar Oct 19 17:11:46 meh, not going to open this can of worms today Oct 19 17:30:43 xback: Linux OpenWrt 4.14.77 #0 SMP Fri Oct 19 16:59:11 2018 aarch64 GNU/Linux Oct 19 17:30:52 xback: looking good I'd say :) Oct 19 17:37:09 god damn kernel bumps Oct 19 17:37:11 can't keep up Oct 19 17:37:26 there, patch series for mesongx sent, looking forward to review/comment Oct 19 17:37:46 I need to start using kexec or something Oct 19 17:38:19 I wish I had more time, I'd kinda like to make an A/B thing for openwrt (like junos/ios etc) Oct 19 17:38:46 flash space permitting ofc, may only be useful on x86 Oct 19 17:39:14 or on platforms where bootloader can be manipulated by userland Oct 19 17:39:35 but.... kexec support doesn't build anyway at least for mips Oct 19 17:42:43 ow Oct 19 17:43:02 700GBP if I stop by the summit on the way home Oct 19 17:45:40 mm, 300 if I go via frankfurt, sounds good Oct 19 17:47:42 rmilecki: i'm sure you noticed this already, but linux git has several commits that mention fixing 3a1e819b4e80 Oct 19 18:33:01 pkgadd: ping Oct 19 18:41:33 since I don't know hoteks in lisbon, where are you guya staying? Oct 19 18:59:24 stintel: do we have already new builder host? I would like to create more CI jobs Oct 19 18:59:42 lynxis: yes we have two new servers Oct 19 19:00:12 jow: did you already do anything with the new servers? Oct 19 19:20:18 russell--: i didn't check for that Oct 19 19:20:46 russell--: are some of them present in torvalds git and not backported to 4.14? Oct 19 20:52:19 russell--: i see following fixes in Linus's tree: Oct 19 20:52:21 72d42504bd7f ("ovl: select EXPORTFS") Oct 19 20:52:22 fbaf94ee3cd5 ("ovl: don't set origin on broken lower hardlink") Oct 19 20:52:24 1a8f8d2a443e ("ovl: fix format of setxattr debug") Oct 19 20:53:53 all of them are in the linux-4.14.x branch of stable Oct 19 21:03:21 who was discussing the filtering of optimisation flags in Makefiles here the other day/week/month? Oct 19 21:03:59 I vaguely remember something and got the impression it wasn't popular. Oct 19 21:10:24 This was with regard to musl - and I didn't have the heart to point out that mbedtls, openssl, zlib had already been tweaked. Oct 19 21:27:52 ldir: you're going to lisbon right? Oct 19 21:28:48 canucks app Oct 19 21:37:17 greearb_: ping Oct 19 21:37:58 huaracheguarache, here Oct 19 21:38:54 greearb_: just had a crash with the newest firmware and I'm not sure what entierly triggered it. which issue should I post the log under? Oct 19 21:39:10 not entierly sure* Oct 19 21:39:11 just email it to me Oct 19 21:39:15 ok Oct 19 21:42:32 greearb_: there Oct 19 21:51:58 greearb_: anyways, I'll be going to sleep now. thanks for taking a look and see you around Oct 19 21:52:11 thanks, I got it Oct 19 22:05:08 huaracheguarache, more rate-ctrl corruption it seems like Oct 19 22:05:23 I'll get a new build to hopefully track this down soon Oct 19 22:12:39 huaracheguarache: pong Oct 19 22:28:26 greearb_: Sounds like you're having exciting PCIe issues with the APUs :) Oct 19 22:29:44 That WLE900VX has found a couple ways to antagonize me the last few days, compliance with standards seems optional Oct 19 22:32:43 well, flights booked, guess I've gotta come to the summit now heh Oct 19 23:47:42 build #141 of mvebu/cortexa72 is complete: Failure [failed sourceupload] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mvebu%2Fcortexa72/builds/141 blamelist: Koen Vandeputte **** ENDING LOGGING AT Sat Oct 20 03:00:00 2018