**** BEGIN LOGGING AT Thu Aug 09 02:59:59 2018 Aug 09 03:10:44 luaraneda: hm Aug 09 03:10:48 i don't think its applying the patch Aug 09 03:12:36 jwh: That's odd, I just tested them on two separated, freshly cloned, buids. One for zynq, and another for ipq40xx Aug 09 03:12:44 builds* Aug 09 03:13:53 Maybe you have to run: Aug 09 03:13:54 # make tools/m4 clean Aug 09 03:13:55 # make tools/findutils clean Aug 09 03:14:13 Sorry, these ones:/ Aug 09 03:14:25 # make tools/m4/clean Aug 09 03:14:25 # make tools/findutils/clean Aug 09 03:14:45 to force a clean first Aug 09 03:17:20 I always nuke everything before building Aug 09 03:17:22 weird though Aug 09 03:17:45 theres nothing in the log about applying patches, not even the one that already exists in m4/patches Aug 09 03:22:02 I just flashed an image to my router, literally 3 minutes ago, made with those patches (on Arch with glibc 2.28-1) Aug 09 03:23:36 the patches aren't the problem since they aren't being applied (not even the one that is already in there) Aug 09 03:24:05 hm Aug 09 03:25:08 oh, the existing one does Aug 09 03:25:13 missed that bit, but... Aug 09 03:26:08 oh, wrong build :D Aug 09 04:20:51 build #76 of armvirt/64 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/armvirt%2F64/builds/76 Aug 09 04:26:44 is there a way to provide my own wpa_supplicant.conf file, rather than use the autogenerated ones? Aug 09 04:46:06 build #77 of mxs/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mxs%2Fgeneric/builds/77 Aug 09 04:48:08 build #75 of brcm47xx/legacy is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Flegacy/builds/75 Aug 09 05:10:09 build #75 of omap/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/omap%2Fgeneric/builds/75 Aug 09 06:29:16 *** buffer overflow detected ***: /home/mkresin/build/embedded/openwrt/push/staging_dir/host/bin/ucert terminated Aug 09 06:29:34 is this already known? Aug 09 06:32:59 mkresin: seems there an array of ucert issues the past day, even with building images Aug 09 06:35:18 morning Aug 09 06:35:37 speaking of ucert, had some error regaring libjson today with that... Aug 09 06:37:22 mkresin: updated my PR on github for the r6120 - https://github.com/openwrt/openwrt/pull/1087 Aug 09 06:37:32 if you could, please have a look :) Aug 09 06:39:50 Brother_Lal: I'm quite sure your wifi will not work if you rebase to latest master Aug 09 06:40:10 Brother_Lal: if webinterface flash doesn'T work, don't build a factory image Aug 09 06:40:13 :/ Aug 09 06:40:21 its required for the nmrpflash Aug 09 06:40:24 same format Aug 09 06:40:31 and there it works ... Aug 09 06:40:46 Brother_Lal: I might should check the commit message again. sorry Aug 09 06:41:06 :D too early in the morning, and to hot these weeks Aug 09 06:41:18 at least in germany Aug 09 06:42:01 Brother_Lal: both is true. later the day I will get back to you to apply the latest changes to your dts as well Aug 09 06:42:19 ok, thanks! Aug 09 06:42:54 the buffer overflow seems to be fixed with a recent commit. forgot to pull in the latest changes Aug 09 06:56:18 Hello Aug 09 06:57:21 weirdness, i am finding several (i.e. not one-offs) of meraki mr24's where /etc/config/dropbear (in the overlay) is the correct number of bytes, but all 0x00. Restoring from /rom/etc/config/dropbear seems to fix it, but not sure why its happening. Aug 09 06:59:26 when that happens, dropbear understandably isn't excited about starting, and so i lose remote access (or any access at all, other than booting the recovery partition or serial console) Aug 09 07:02:30 totally bizarre Aug 09 07:11:41 russell--: What happens if I have RA server, and DHCPv6 Server too ? Aug 09 07:15:54 i give up, what happens? Aug 09 07:18:26 mkresin: if i nuke the key-build* in $TOPDIR, a new one is created and everything seems to work fine Aug 09 07:20:31 russell--: I'm just asking that is there any order between them? Aug 09 07:24:35 xcoom:no Aug 09 07:24:47 xcoom:RA server will send periodic RAs Aug 09 07:25:13 xcoom:DHCPv6 server will answer on DHCPv6 messages sent by clients Aug 09 07:25:56 dedeckeh: IP address conflict is not possible when both of them are enabled? So same address can't be assigned? Aug 09 07:26:45 xcoom:event hen if addres conflict arises duplicate address detection is in place Aug 09 07:28:10 russell--: I've seen that on lantiq/ NAND (bt hh5a) after powering off a couple of months back (mostly breaking /etc/shadow), but that seems to be fixed (after a kernel change mentioning NAND fixes) Aug 09 07:28:34 I haven't seen it anymore recently (as in the last 2-3 months) Aug 09 07:29:48 xcoom:the chances are very slim this will happen as DHCPv6 gives out random IPv6 addresses to clients will devices picking up a RA use mostly their mac address as hostid Aug 09 07:29:49 I think the breakage lasted for revisions within 2-5 week window at most Aug 09 07:31:11 there's an ordering of sorts: clients are told whether or not to do DHCPv6 by flags in the RAs Aug 09 07:31:51 (also technically RAs don't set addresses. there's a flag in the RA which tells clients to invent their own addresses -- and that mechanism is called SLAAC) Aug 09 07:32:03 pkgadd: i saw it on two different devices compiled a couple days ago 7763-g9537c1a153 Aug 09 07:32:45 an address conflict probably is _possible_, but DHCPv6 is configured by default to give out addresses which correspond to locally-assigned EUI-64s Aug 09 07:33:08 I haven't done a build quite that recently Aug 09 07:33:39 i'd seen it on images build as long ago as february Aug 09 07:33:51 so basically the only way to get a conflict is a) to be running an L2 that uses EUI-64s, not MACs, and b) to locally assign a very carefully selected EUI-64 that begins with 02:00:00:00:00:00 or so Aug 09 07:34:28 and conflicts with locally-assigned EUI-64 addresses are your own responsibility to avoid. that's what local assignment *means* Aug 09 07:34:32 * russell-- wonders if a power cycle is necessary to trigger it Aug 09 07:34:49 rather than a relatively graceful reboot Aug 09 07:34:49 in that case I can't really help, my issue on lantiq seem to be fixed for a couple of months now and I haven't seen it elsewhere (although I'm mostly using spi-nor and eMMC on my other devices) Aug 09 07:35:04 in my case it was a full power cycle Aug 09 07:35:10 this is nand flash Aug 09 07:35:49 Hi, I am trying to build ledtrig-netdev module by selecting from menuconfig but it is not making .ko but making .o file in linux4.4.6/drivers/leds/ Aug 09 07:36:00 Dagger:the DHCPv6 address assignment is at the discretion of the DHCPv6 server implementation Aug 09 07:36:14 daager:there's no general rule in place for that Aug 09 07:36:21 Can anyone please suggest what I am missing since i am selecting leds-gpio module and it is making .ko and .o file both Aug 09 07:37:06 I am using CC15.05 of openwrt Aug 09 07:37:15 dedeckeh: I meant DHCPv6 in OpenWRT, which I believe is configured for something like "::1000 to ::2000" by default, or something along those lines Aug 09 07:39:10 interesting, /etc/config/batman-adv and /etc/config/horst got the same treatment Aug 09 07:39:38 * russell-- just scanning /overlay/upper for examples Aug 09 07:41:50 Dagger:from ::0000 till ::0FFF slecting a random addresses seeded by the duid Aug 09 07:42:16 raheel_: no, you aren't - CC had only kernel 3.18, kernel 4.4 was only released in january of 2016. you are using some kind of vendor SDK loosely based on CC, probably with quite significant changes, particularly for the kernel - so no one but the vendor providing the SDK to you can help you Aug 09 07:44:29 it seems to happen after first boot, i use a uci-defaults script to record original values with uci show > /etc/uci-firstboot, and the correct values are present there Aug 09 07:45:13 * russell-- wonders if the data aren't flushed out the flash Aug 09 07:45:19 to* flash Aug 09 07:49:54 yeah, that did it Aug 09 07:50:32 if i jffs2reset -y && reboot -f, let it boot, then yank power, some set of my files are null'd out Aug 09 07:51:14 whisky tango foxtrot Aug 09 07:58:07 pkgadd: yes I am using vendor sdk but it is compiling the module c file and making object file not sure why it is not making module .ko file Aug 09 07:58:26 /dev/ubi0_4 on /overlay type ubifs (rw,noatime,ubi=0,vol=4) Aug 09 08:23:32 dedeckeh: Do you know, that neither Wifi Clients in Europe can use the channel 14 in 2,4 ghz ? Aug 09 08:24:00 14 is japan only, and only for 802.11b Aug 09 08:24:44 If I go to Japan with my Iphone, then it will be able to use channel 14 in 802.11b? Aug 09 08:25:08 DonkeyHotei: Is it HW or location dependend? Aug 09 08:25:10 t Aug 09 08:25:18 both? Aug 09 08:53:43 issuing a sync from a shell flushes writes to persistent store on ubifs, in such a way as the data survives yanking power Aug 09 09:01:44 xcoom: 802.11b is horribly slow (11 mbit max), most likely it will still be faster with 11n on any other channel, regardless how crowded it is Aug 09 09:07:35 https://bugs.openwrt.org/index.php?do=details&task_id=1755 Aug 09 09:09:47 sounds like there needs to be some shorter "commit to flash" intervakl Aug 09 09:16:29 one of the builds (the february one) had been up for months before i lost contact, which i can only explain if the data didn't get flushed at all, ever, and then the power was cycled. Aug 09 09:16:52 it was flashed around feb 22, then disappeared between april 24 and april 27 Aug 09 09:17:07 I've seen frequent reports about files getting trashed recently Aug 09 09:17:10 also in the forum Aug 09 09:17:27 sync helps a lot, afaict Aug 09 09:18:22 i'm doing an experiment right now, i did a factory reset about 20 minutes ago, i'll wait until i wake up in 8 hours or so, yank power and see if i get the same thing Aug 09 09:19:24 can you paste these: (cd /proc/sys/vm; cat dirty_writeback_centisecs dirty_expire_centisecs dirty_writeback_centisecs dirty_background_ratio dirty_ratio) Aug 09 09:20:37 500 3000 500 10 20 Aug 09 09:21:14 looks normal Aug 09 09:22:12 same as on my laptop Aug 09 09:22:46 kernel 4.14.60 Aug 09 09:23:00 (on the mr24) Aug 09 09:23:40 the internet seems to suggest mounting with -o sync Aug 09 09:29:52 russell--: I've seen (only once so far) that my "first boot" things were happening on second boot too, as if first boot never managed to actually write to disk. Aug 09 09:31:43 karlp: that could just be because the script didn't return 0 Aug 09 09:33:20 russell--: what's the output of sysctl vm.dirty_writeback_centisecs Aug 09 09:33:34 Has anyone reported issues with ath79 archer c7 v2 network ports on recent (post a692e4e3de) builds? Aug 09 09:33:38 oh, wait, i see jow asked that alredy Aug 09 09:33:54 500 looks just like in my case Aug 09 09:33:55 yeah Aug 09 09:35:15 even in failsafe mode. Aug 09 09:35:37 russell--: no, that would jsut leave the script in place, it' Aug 09 09:35:46 s more like it jsut didn't save. Aug 09 09:36:15 maybe it is related to the overlay whiteout Aug 09 09:36:17 also, my script _running_ again would be from that sort of thing, but it checks for things that it wrote, (to detect first install vs sysupgrade) Aug 09 09:36:45 I had a gut feeling it was from startup being faster than normal, and the jff2 overlay finished message being much later than normal. Aug 09 09:37:12 but I've not reproduced it or seen it more than once yet, so I just put it down to my desk Aug 09 09:37:29 i'm a little confused why /etc/config is getting rewritten to the /overlay even if it hasn't changed from /rom Aug 09 09:38:18 in particular dropbear doesn't seem to change at all Aug 09 09:38:49 and yet, there's a file /overlay/upper/etc/config/dropbear Aug 09 09:40:05 * russell-- assumes this is an artifact of a uci commit or something Aug 09 09:42:42 i got impatient, 15 minutes wasn't enough to flush the files Aug 09 09:44:48 UBIFS (ubi0:4): media format: w4/r0 (latest is w5/r0), UUID 3E0627AF-7BE4-40BD-9D33-1420E9639155, small LPT model Aug 09 09:45:23 jow: were there libuci changes required too, or are these rpcd changes all that's needed? Aug 09 09:46:06 karlp: the rpcd changes will solve the issue Aug 09 09:46:26 karlp: the libuci changes are intended to further harden uci, so that it does not segfault when prcessing invalid delta files Aug 09 09:47:09 due to the rpcd changes there's a slight behaviour change now Aug 09 09:48:07 complex batch operations like :section("conf", "type", { option1 = "foo" }) will now get rejected completely if any of the values is invalid Aug 09 09:48:38 previously you could throw a table with invalid keys at it and it did simply set those keys that were valid Aug 09 09:53:05 seems like a perfectly reasonable change. Aug 09 09:53:42 values being invalid just means, "wasn't a string/bool/number" right? Aug 09 09:54:10 - the type can be invalid ([^a-zA-Z0-9_]) Aug 09 09:54:24 - the name can be invalid ([^a-zA-Z0-9_]) Aug 09 09:54:39 - the option names can be invalid ([^a-zA-Z0-9_]) Aug 09 09:55:05 - the option values can be invalid (typeof(v) not a number, boolean, string or array Aug 09 09:55:19 - if array then it must be an array of number, boolean or string Aug 09 09:55:44 array of array or array of objects or objects are invalid values Aug 09 09:56:30 type can actually be [a-zA-Z0-9_-] Aug 09 09:56:38 so anyhow, all these are checked now Aug 09 09:57:10 similar checks are performed for uci set, uci delete, uci order Aug 09 09:58:59 and this is currently just in rpcd's interface. so we don't have a good place to hook up documentation for this really do we. Aug 09 09:59:35 well I tried to make the code comments and commit messages informative Aug 09 09:59:41 yeah, that's enough I guess. Aug 09 09:59:54 maybe we could put the constraints into the luci.model.uci luadoc too Aug 09 10:00:13 never hurts. Aug 09 10:00:47 so basically there's three uci value "types" which are legal, depending on the context Aug 09 10:01:11 1) "name", this is a shell variable compatible name used for section and option names Aug 09 10:01:23 2) "type", this is like name but additionally allows "-" Aug 09 10:01:49 there's https://openwrt.org/docs/guide-developer/ubus/uci too, not sure if that's usd much Aug 09 10:01:58 3) "section", this is either a "name" or extended notation in the form "@" "[" "]" Aug 09 10:02:16 and https://openwrt.org/docs/techref/uci which is ~similar but different. Aug 09 10:02:29 where is validated like "type" and needs to be a positive or negative integer Aug 09 10:05:49 man, the "ubuntu/raspbian" instructions there are pretty poor, would anyone be upset if I just drop them all? Aug 09 10:06:10 why do we have raspian instructions in the wiki? Aug 09 10:07:00 I'll remove it, and expand a little on ldconfig/LD_LIBRARY_PATH which is the only real difference. Aug 09 11:03:50 Anybody can help in C programming syntax ? Aug 09 11:05:06 BIT(15) means the integer 15 ? Aug 09 11:07:18 it is usually a CPP macro in the form (1U << (n)), means BIT(15) will return an integer with only the 15th bit set to 1 and all other set to 0 Aug 09 11:07:54 BIT(15) = 32768 = 0x8000 = 1000000000000000b Aug 09 11:13:32 jow: whao, In Excel =BIN2DEC(100000000000000) doesn't even work Aug 09 11:13:41 1 + 14 Zeros, right? Aug 09 11:14:28 what's the actual question that led to this? Aug 09 11:14:53 karlp: Just checking C syntax Aug 09 11:21:39 xcoom: 1 + 15 zeroes; the bits are 0-indexed Aug 09 11:29:03 russell--: you'll probably have to add some debugging into ubifs Aug 09 11:31:00 russell--: probbly somewhere around wbuf_timer_callback_nolock Aug 09 12:03:43 so anyone have any ideas on this yet ?/home/dingo/archer-c7-v4/staging_dir/host/bin/ucert: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory Aug 09 12:03:43 Makefile:204: recipe for target '/home/dingo/archer-c7-v4/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/base-files/.configured_f8a7ef425d28326c27dae6762b223070_8e081b74cf069e1e6800a5bbcbb282f0' failed Aug 09 12:07:05 OutBackDingo_: you removed or upgrade libjson-c on your host machine Aug 09 12:09:49 try make package/ucert/host/clean Aug 09 12:11:03 stintel: nope it is installed Aug 09 12:11:09 ill try the make package Aug 09 12:15:18 hmm, not sure if that does what I expect it does Aug 09 12:16:49 stintel: its still failing... Aug 09 12:17:00 i dont think this is a host issue Aug 09 12:17:11 i think its a WRT commit / build issue Aug 09 12:21:59 OutBackDingo_: you may need to rebuild the host-build of libubox and libjson-c. ie. rm -rf build_dir/host/libjson-c build_dir/host/libubox Aug 09 12:22:28 OutBackDingo_: because it was moved from STAGING_DIR_HOSTPKG to STAGING_DIR_HOST which is also where the rpath of ucert points to... Aug 09 12:23:49 fresh built ucert works fine here: Aug 09 12:23:50 $ ./staging_dir/host/bin/ucert Aug 09 12:23:51 Usage: ./staging_dir/host/bin/ucert Aug 09 12:24:17 dangole: why isn't this happening automaticly? how did they get moved exactly? By changing the InstallDev recipe? Aug 09 12:24:20 anybody having issues with ath79 target today (specifically archer c7)? Aug 09 12:25:18 "issues"? Aug 09 12:25:42 jow: by commit 73100024d3 ("libubox: set HOST_BUILD_PREFIX") Aug 09 12:25:53 I can't connect to my router with the latest snapshot flashed Aug 09 12:26:00 it doesn't respond Aug 09 12:26:19 I recovered to oem and tried to reflash, but still no dice Aug 09 12:26:23 wait, there are ath79 snapshots? Aug 09 12:26:30 oops Aug 09 12:26:34 or are you referring to ar71xx ? Aug 09 12:26:37 i mean latest build Aug 09 12:26:43 i compiled locally Aug 09 12:28:11 jow: thats nice, but im telling you from a fresh checkout, it doesnt Aug 09 12:28:38 OutBackDingo_: buildbots disagree Aug 09 12:28:42 my local builds too Aug 09 12:28:58 at least I am unable to reproduce any of these issues so far Aug 09 12:29:43 so fresh clone, pick random target and CONFIG_SIGNED_PACKAGES? Aug 09 12:29:44 OutBackDingo_: i also noticed that host packages don't always get rebuild if the recipe changes, so it can really be that your libjson-c is still lurking in STAGING_DIR_HOSTPKG instead of STAGING_DIR_HOST where ucert expects to find it Aug 09 12:29:53 I'll try dirclean to see if that might help Aug 09 12:29:57 will try on a complete new clone Aug 09 12:30:40 OutBackDingo_: ldd staging_dir/host/bin/ucert Aug 09 12:31:06 mine says: libjson-c.so.2 => /home/stijn/Development/LEDE/source/staging_dir/host/lib/libjson-c.so.2 (0x00007fa4d321c000) Aug 09 12:31:41 maybe you need make package/libjson-c/host/{clean,compile} instead Aug 09 12:37:45 stintel: tried that Aug 09 12:37:51 no joy Aug 09 12:40:10 you also need to clean libubox/host Aug 09 12:40:35 which is the lib actually pulling in json-c Aug 09 12:41:21 ldd should look like this: https://pastebin.com/iEk3FNJJ Aug 09 12:43:01 which actually was the wrong one because I do have host libs installed elsewhere. I meant this: https://pastebin.com/wNvLhbvg Aug 09 13:07:48 huaracheguarache: revert 4b9680f138 Aug 09 13:08:25 archer c7 v2 ethernet ports broken with that commit in place. Aug 09 13:13:33 ldir: that break ethernet ? Aug 09 13:13:50 blocktrron: ^^^ Aug 09 13:14:28 sorry - I have migraine at moment. Fell into trap last night with latest build - ports come up (or appear) to but won't handle traffic Aug 09 13:14:47 blogic: might be as it will now apply default pll settings for this board Aug 09 13:14:48 think RX packet count stays 0. Aug 09 13:15:20 blocktrron: we need to revert it if it breaks archer c7 Aug 09 13:15:21 ldir: yeah, I ran tcpdump and got no traffic from my archer c7 Aug 09 13:15:29 I'll test it now Aug 09 13:15:32 blogic: wait a moment Aug 09 13:15:35 sure Aug 09 13:15:43 had to go into recovery vai boot loader to get an old image in. Aug 09 13:16:07 now just built new image with the pll commit reverted and all appears well. Aug 09 13:16:18 we will need to add pll settings to the c7 dts. Aug 09 13:16:47 Ahh, someone already figured it out (and wrote a patch for it) https://github.com/openwrt/openwrt/pull/1260 Aug 09 13:19:02 we will also need to do this for the qca9558 based 1043, i will prepare a patch for this device. So this commit doesn't ned to be reverted Aug 09 13:20:41 anyone else having problems building libevent2? I get patch failure with ./patches/0002-Makefile.am-omit-building-sample-and-test.patch which was backported from master, Aug 09 13:21:00 this is on 1806 branch, and the backport commit message is full of dmarc wrapping text, which is pretty bogus Aug 09 13:23:58 oh, this is because master got libevent2 turned into the still beta libevent2.1 and kept the same name Aug 09 13:24:06 I did say that was not the same thing... Aug 09 13:24:12 so of course the backport doesn't work properly. Aug 09 13:24:44 ldir: I wanted to ask you something about cake, but I'll do that later since you have a migraine. I also sometimes get migraines and getting some sleep usually helps a lot for me. Aug 09 13:24:52 they did declare 2.1.8 as stable, but it's still not the same as 2.0.x Aug 09 13:27:55 karlp: "libevent2: Don't build tests and samples" ? Aug 09 13:28:15 yeah Aug 09 13:28:24 that patch only applies to libevent 2.1 Aug 09 13:28:44 and master has libevent2.1 calling itself libevent2, while 1806 still has libevent2 Aug 09 13:28:56 so the backport isn't applicable. Aug 09 13:30:33 thanks fir the heads up, reverted it Aug 09 13:31:25 that still leaves the bump of libevent2 to be 2.1, which is not the same thing. I objected to that here: http://lists.infradead.org/pipermail/openwrt-devel/2018-May/012367.html Aug 09 13:31:35 and then someone else submitted it and it got merged anyway here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=025688794d516d5b020abfdaabf47fe341e37da6 Aug 09 13:32:02 at least that one changed all the titles, Aug 09 13:32:14 so maybe that's just the way forward, and we keep it. Aug 09 13:33:04 but they are different apis, and libevent2.0 is now no longer available Aug 09 13:37:57 jow thanks, building well now. Aug 09 13:53:41 so 'Ive got no feedback from davic, probably on vacation or something Aug 09 13:53:56 anyone else here experience with mwlwifi / linksys ac series? Aug 09 13:54:20 had a little, all bad Aug 09 13:54:25 ;) Aug 09 13:54:41 its all crap after ath9k Aug 09 13:55:21 there have been scattered reports in #openwrt of ath9k problems too Aug 09 13:57:44 haven't heard about those since nbd tracked down the bug on wr1043nd v1 or so Aug 09 13:58:20 somebody had a unifi that blocked arp packets too Aug 09 13:59:14 For a while I had multicast problems with ath9k, but that has been fixed for quite some time. Aug 09 14:00:10 the blocked arp thing seems to be related to bridge hairpinning and forced wifi isolation Aug 09 14:00:30 which apparently is quite broken on kernel 4.4, yet forcibly enabled by default Aug 09 14:01:10 asked on the forum https://forum.openwrt.org/t/update-mwlwifi-for-18-06-1/18651 Aug 09 14:02:00 jow: https://github.com/kaloz/mwlwifi/issues might give an idea about the state of things Aug 09 14:11:16 blogic: i've just sugmitted a patch which fixes it for the OM5P AC v2 and ther 1043, i've tested my patch in conjunction with the linked fix for the v2 and they seem to work. Aug 09 14:11:41 I only have a C7 v2 here but now the PLL settings match the one the devices get applied on ar71xx so they should be all working now Aug 09 14:12:21 huaracheguarache: first one in the list " Aug 09 14:12:23 [wrt1200ac] 2.4ghz connection very unstable " Aug 09 14:12:26 :( Aug 09 14:13:25 For what it is worth, my brother has a WRT1200AC that I think is still on 17.01.x (I haven't bugged him to upgrade yet) and he doesn't have any trouble with the WiFi. Aug 09 14:42:34 blocktrron: ok Aug 09 15:09:53 jow: any joy ? Aug 09 15:23:15 Brother_Lal: ping Aug 09 15:35:54 mkresin: ping Aug 09 15:37:44 ldir: pong Aug 09 15:38:43 seeing as though c7 v2 is broken at the moment... I was curious as to what the led tweaks in https://github.com/openwrt/openwrt/pull/1260 are for Aug 09 15:38:54 and whether they should be a split commit. Aug 09 15:41:58 ldir: following a common standard I would say Aug 09 15:42:16 ldir: yes, would be better if they where a distinct commit Aug 09 15:43:45 ldir: but this guy performs like a machine and does a really good job. And I don't like to "scare" him with my usual change requests Aug 09 15:44:34 if you won't now, when would you? Aug 09 15:44:41 why different standards? :) Aug 09 15:46:17 different standards, yes. performs like a machine and I fix minor issues on my own before pushing Aug 09 15:50:10 ok, as c7 is broken at the moment, I'll grab the tweaks to fix the pll settings and push that after testing, basically to get c7 back and working in master Aug 09 15:50:47 the other changes can then be thought about as required. Aug 09 15:54:27 ldir: just let me know if it works for you. it is already in my push queue Aug 09 15:54:42 ldir: I only ran out of time this morning Aug 09 15:54:46 I would respectuflly ask that you make the same requirements of them as anyone else. if they're performing like a machine, it won't be a problem for them to make improvements. Aug 09 15:55:00 this also shows _other_ people what the problems are so they can get them right instead Aug 09 15:55:39 some people getting their patches fixed up for them and others getting them rejected until they fix themselves is, IMO, more unwelcoming than you wanting to welcome new people. Aug 09 16:00:08 karlp: on github? I lost any hope that github users check old PRs to not do the same mistakes over and over again. I'm doing reviews to long now. Aug 09 16:00:20 karlp: you are welcome to help with github reviews of course Aug 09 16:04:02 if this doesn't cover your requirements and things you need people to change, then update it: https://openwrt.org/submitting-patches Aug 09 16:04:11 if it does, then just refer to it. Aug 09 16:04:21 again, if this person is a machine and fast, they can follow it. Aug 09 16:06:01 karlp: you are aware that the submitting patches guideline is shown every time someone creates a PR? And guess what, they don't read it. Aug 09 16:07:05 karlp: please do me the favour and review github PR to see what I'm talking about Aug 09 16:10:52 mkresin: ah, sorry, just read scroll back after testing - just pushed the pll only fix - the original PR should still merge cleanly though. Aug 09 16:11:03 yes, I'm saying are you aware of the inequality you're creating by saying that _some_ people (randomly) don't hve to follow those rules? but others do? Aug 09 16:11:17 what's the poitn of rules if you won't follow them? Aug 09 16:11:31 ldir: no problem Aug 09 16:13:05 karlp: I considers his contributions as that valuable that I'm fine to stretch the rules. It isn't that the PR is total garbage. Aug 09 16:14:20 yet somehow they're not competent enough to make any changes? Aug 09 16:14:56 ideally the pll and the led tweak should be individual commits.... so at least I've forced that issue now :-) Aug 09 16:16:29 what ldir says. ideally... Aug 09 16:23:45 * f00b4r0 notes with great interest that it is now plainly admitted that different standards apply to different contributions/contributors ;P Aug 09 16:25:04 * Monkeh quickly closes the curtains Aug 09 16:25:57 ;) Aug 09 16:31:54 it can't get much worse than this PR https://github.com/openwrt/openwrt/pull/915 regarding commit split ups I guess Aug 09 16:32:30 event than the person in question is surprised I won't merge it as is ... Aug 09 16:34:36 if you need to make a list for your changes this is a clear sign you should split it up ;) Aug 09 16:35:28 absolutely agree on this Aug 09 16:35:49 well, ldir told them too.... "Wow a lot of hard work gone into this, much appreciated. I'm pretty sure you'll need to squash this into a single commit for it to be merged..... that will be the easy bit " Aug 09 16:35:58 https://github.com/openwrt/openwrt/pull/915#issuecomment-386547248 Aug 09 16:36:24 well that's wrong ... Aug 09 16:36:30 because AFAICT it needs to be an 'atomic' change - it's a package bump. Aug 09 16:37:28 they're changes in it not related to the dropbear bump Aug 09 16:37:59 like the ECC host key stuff Aug 09 16:38:00 so... unrelated, opkg compare-versions "2a" '>' "2a" && echo "seems to o equals or greater than" Aug 09 16:38:16 that should only pass for 2a ">=" 2a surely.. Aug 09 16:38:45 In which I shall apologise for giving wrong advice - I didn't/don't understand the rules Aug 09 16:40:25 they could bump pkg_release each time they add functionality to the package, doesn't all have to be rolled into one. Aug 09 16:41:27 ldir:np; it could be even that the ECC host key stuff was added after your comments Aug 09 16:41:33 well I've apologised. But that comment was back in May Aug 09 16:42:01 somebody complained that pr introduces a double free() too Aug 09 16:42:36 ldir: don't worry, there seem to be a lot people who don't know about it Aug 09 16:42:48 you should read the kernel contribution guidlines probably Aug 09 16:43:49 it would be great if upstream dropbear actually did a service release so that all the back ported patches that rockdrilla did were included. Aug 09 16:45:44 lidr:agree on that; all those patches are a bit awkward Aug 09 16:46:52 * f00b4r0 notes his wifi patch is wrong Aug 09 16:46:54 ldir: https://www.mjmwired.net/kernel/Documentation/process/submitting-patches.rst#199 Aug 09 16:47:21 what's wrong and who can we blame for it? Aug 09 16:49:25 * f00b4r0 sends fixed patch Aug 09 16:49:47 * f00b4r0 notes not to cook patches when it's over 35C ;P Aug 09 16:51:02 I still think that largely the dropbear change is a big enough 'crash thump bang wallop' change to do in one commit 'cos I very much doubt you'd revert individual commits if someone found something wrong. Aug 09 16:52:14 it would still be useful for bisecting Aug 09 16:52:21 and it makes it easier to review Aug 09 16:55:14 * ldir loves how he's getting the blame for this Aug 09 16:55:28 it's say there for f*ing months Aug 09 16:55:49 numerous people trying it and saying ok.... and not a lot happens. Aug 09 16:56:30 s/say/sat Aug 09 16:57:04 ldir: how is routing performance? Aug 09 16:57:18 no idea Aug 09 17:00:45 I has ethernet improving patches. No interest from anyone. Oh well. Aug 09 17:01:10 what does? Aug 09 17:01:13 *yawn* Aug 09 17:03:28 ldir: https://forum.openwrt.org/t/is-anybody-working-on-linux-4-14-for-ar71xx-platform-porting-guide-to-ath79/13013/397 Aug 09 17:04:00 performance is better on a v2. Aug 09 17:04:27 * ldir doesn't understand, doesn't have time, needs to go back to paid job involving audio. Aug 09 17:05:12 no worriea Aug 09 17:05:55 in any case, I should probably test the v3 I have. I have it overclocked as well... Aug 09 17:06:28 ldir: not blaming you for anything, just trying to show you why splitting changes matters ;) Aug 09 17:07:15 hrm anyone know what impact flow offloading has on bufferbloat? Aug 09 17:07:30 weird. suricata with PF_RING support links libpfring.so.1 Aug 09 17:07:34 ehr .0 Aug 09 17:07:39 mangix: just the reordering of the struct gives the perf boost? Aug 09 17:07:40 but that doesn't even exist anywhere on my system Aug 09 17:09:30 aha Aug 09 17:10:11 f00b4r0: yeah. fewer cache misses Aug 09 17:10:24 mangix: makes sense. Especially if the struct is packed Aug 09 17:10:46 mangix: don't see why it'd be reject tbh Aug 09 17:10:53 ah because libpfring.so's SONAME is libpfring.so.1 Aug 09 17:11:07 I asked felix. He said it made no sense to him. Aug 09 17:12:01 I think it's the comments that make no sense. Qualcomm's driver works a bit differwntly Aug 09 17:12:20 but the improvement is there Aug 09 17:31:05 mangix: all i know is that offloading doesn't work with sqm Aug 09 17:55:58 huaracheguarache: not the question I asked :) Aug 09 17:56:25 from my preliminary testing, bufferbloat gets worse with flow offload Aug 09 17:56:39 more specifically, latency goes up under load Aug 09 18:10:32 rmilecki: what would you suggest? Aug 09 18:11:07 russell--: maybe start with pr_info("%s executed\n", __func__); Aug 09 18:15:24 fwiw, i confirmed that even aftere 8 hours, data didn't make it to persistent storage ... looks at adding the debugging info Aug 09 18:19:27 mkresin: pong, if only just for a short time Aug 09 18:32:20 meh, that libmosquittopp missing dep for libmosquitto.so.1 is biting me again, sigh Aug 09 18:41:03 mkresin: afk again, saw you assigne the r6120 pr to yourself, if there is anything to do, comment on the pr please - and thanks for the work! **** ENDING LOGGING AT Fri Aug 10 03:00:01 2018