**** BEGIN LOGGING AT Sat Jun 15 02:59:57 2019 Jun 15 08:26:05 cccccchdgggntubkrnekiuurldnfftvkibergjgenggu Jun 15 08:26:19 oops, I really should disable that touch Jun 15 08:27:50 does anyone here have intimate knowledge of hw offloading on mt7621? Jun 15 08:28:37 there's bug report FS#2321 where it crashes 4.14.125, but works fine on 4.14.123 Jun 15 08:29:14 maybe something has changed in the upstream which has broken (again) some of ours kernel patches? Jun 15 08:32:33 I really should source some mt7621 device somewhere, any good tip? Jun 15 08:38:18 ynezz: I've ordered an Xiaomi Mi WiFi R3G on ebay Jun 15 08:38:37 its roughly in the 40 Euro price range Jun 15 08:59:20 jow: thanks, looks nice and can have it for 32E here Jun 15 09:01:23 pepe2k: czesc, jak tam? :) looking around for some mt7621 device I could use for testing, any tips? Jun 15 09:01:54 so far it looks like I'm going to order xiaomi mi r3g Jun 15 09:02:01 cccccchdgggnvevfirlbnigijevblfnnvckchjjcigdc Jun 15 09:06:51 ynezz: ahoj! powoli do przodu ;) Jun 15 09:07:16 ynezz: what's your budget? or better, what exactly do you need on the board? Jun 15 09:08:10 well, just mt7621 for testing/bug reproduction Jun 15 09:08:34 not limited by the bugdet Jun 15 09:09:15 but some other goodies might be good, actually it's quite hard to choose something from this long list of devices Jun 15 09:09:52 that xiaomi r3g seems nice, because it has nand Jun 15 09:10:35 Xiaomi R3G, Netgear R6220 - both with NAND (and boot from it) if you are brave enough (R3G can be switched to boot from SPI NOR, I have some notes somewhere how to do it) Jun 15 09:10:54 KanjiMonster: did you ever end up pushing the kconfig PROVIDES dependency fix? I am hitting a very similar issue here, just with luci-lib-nixio Jun 15 09:12:00 ynezz: considering that the device is going to be used for debugging (many flashings) NAND might not be the best option Jun 15 09:12:07 jow: not yet, noticed my condition was subtly wrong/didn't work as expected in all cases and need to rethink that a bit Jun 15 09:12:29 can you elaborate on whats wrong? Maybe I can think about it some more as well Jun 15 09:13:24 pepe2k: I usually use initramfs/nfsroot anyway Jun 15 09:14:05 pepe2k: that emulator you've showed us, can do both nor/nand? Jun 15 09:14:21 only SPI NOR/NAND Jun 15 09:15:23 there is also UniElec U7621-06 if you want some mPCIe slots Jun 15 09:15:44 and of course, ZBT! Jun 15 09:18:22 ok, thanks Jun 15 09:20:12 KanjiMonster: okay I did a look at the generated kconfig myself Jun 15 09:20:59 KanjiMonster: basically it appears as if the "select CONFIG_dep" condition for a builtin package is mistakingly satisfied if any of the providers happens to be enabled as =m Jun 15 09:21:32 right Jun 15 09:21:39 that is the main issue Jun 15 09:24:08 I believe we could use the '>=' operator. Kconfig treats the values 'n', 'm', 'y' as 0, 1, 2 respectively Jun 15 09:24:48 I tried. produces "syntax error" Jun 15 09:25:00 so something like "select CONFIG_DEP if (CONFIG_prov1 >= CONFIG_pkg || CONFIG_prov2 >= CONFIG_pkg || ...)" Jun 15 09:25:03 it does? hmm Jun 15 09:27:41 ynezz: the mir3g is physically quite small so wiring a serial socket connector can be a challenge - if you don't mind wires hanging out then fine! Jun 15 09:27:44 but maybe our kconfig needs updating anyway Jun 15 09:28:05 for me it appears to work Jun 15 09:28:10 strange Jun 15 09:28:39 http://sprunge.us/uILxmR Jun 15 09:30:02 also the lan/wan switch port combination is a little unusual neither LWWWWW of WWWWWL and required a driver patch Jun 15 09:30:16 s/of/or Jun 15 09:35:06 jow: I have iw_full as =y, but can't set iw to n Jun 15 09:35:39 (I have the full package set in menuconfig, and device-observer or so also selects iw, but is =m) Jun 15 09:40:42 KanjiMonster: true, for me iw turns into {*} but once I select iw-full as builtin, I can at least turn iw into {m} Jun 15 09:40:53 its not ideal but seems better than the current situation Jun 15 09:41:59 jow: maybe we are just missing https://github.com/torvalds/linux/commit/9059a3493efea6492451430c7e2fa0af799a2abb Jun 15 09:42:11 this is appears to be due to the fact that kmod-cfg80211 depends on iw Jun 15 09:42:21 and kmod-cfg80211 is commonly builtin Jun 15 09:42:31 so the alternative provbider has to be builtin as well Jun 15 09:43:14 KanjiMonster: oh yes, this commit makes a whole lot of sense, let me try appliying it locally Jun 15 09:45:37 does not appear to make a difference though Jun 15 09:45:53 also it seems that we do not enforce conflicts among providers Jun 15 09:46:08 right now (with my patch plus the one you linked) I can select both iw and iw-full as builtin Jun 15 09:49:12 yeah, doesn't seem to help :/ Jun 15 09:49:16 one thing at a time Jun 15 09:51:49 current working patch: http://sprunge.us/JtiuZS Jun 15 09:52:04 the provider conflicts are indeet an independant topic Jun 15 09:52:09 *indeed Jun 15 09:52:56 jow: I also noticed that the selected by line shown in help shows some completely different conditions (doesn't use >=/<= at all), maybe that is related to the issue Jun 15 10:00:24 could be, could be not Jun 15 10:00:39 is the patch I linked solving your particular problem? Jun 15 10:00:55 completely missed that line Jun 15 10:02:28 jow: ah, no, it doesn't, if it's just the combination of the linux patch with your previous patch Jun 15 10:04:54 jow: for the conflicts thing, we would need to do something like "depends on m if (PROVIDER2=y||PROVIDER3=y||...)", but I remember some fixes for m-depends in the git log for kconfig we probably don't have Jun 15 10:06:36 ack on the conflicts spec Jun 15 10:06:43 was thinking exactly the same Jun 15 10:08:10 maybe we should rethink scripts/config/ with the current 5.x version Jun 15 10:08:14 erm resync Jun 15 10:09:57 jow: now I remember/found it again, it was the < and > that produced syntax errors .... (just wanted to test if !(foo>=bar) => foo ah, great, the zconf.y was never updated and doesn't match any of the generated _shipped files Jun 15 10:32:26 yeah, we only ever patched the shipped sources Jun 15 10:39:40 jow: okay, got it to work: rm scripts/config/zconf.lex.c*; make -C scripts/config clean; make menuconfig Jun 15 10:44:52 looks like zconf.lex.c_shipped wasn't updated in the last sync, so it never knew about <, <= etc - no idea why '<=' still worked, but forcing it to be regenerated seems to fix the menuconfig issue Jun 15 10:46:04 also it looks like we are generating broken(?) syntax: "depends on TARGET_brcm47xx||@TARGET_bcm53xx||@TARGET_ar71xx||@TARGET_ath79" (for PACKAGE_nvram) Jun 15 10:52:58 okay, let's put that into commits Jun 15 11:11:10 ldir: I'm using some kind of the cheapest 3 pin molex connector I glue on the casing of all the devices Jun 15 11:14:04 https://www.gme.cz/konektor-molex-micro-fit-3-0-3-piny-m-436400300 Jun 15 11:31:25 jow: https://git.openwrt.org/?p=openwrt/staging/jogo.git;a=shortlog;h=refs/heads/metadata-fix-provides-built-in - I'll be gone most of the day, so feel free to push yourself (or reword where you want ;) Jun 15 11:59:50 ynezz: excellent, you won't have a problem then :-) Jun 15 12:11:28 KanjiMonster: thanks! will push it after some more testing Jun 15 12:46:24 KanjiMonster: updating the _shipped files from flex and bison sources also uncovered another bunch of bugs in various package Makefile Jun 15 12:46:54 e.g. DEPENDS:=@i386||@x86_64 must be @(i386||x86_64) Jun 15 14:44:34 Hello! Jun 15 14:45:47 I have a problem with a Tplink w8970 lantiq with the boardconfig partition Jun 15 14:47:30 Anyone to help? Jun 15 15:37:39 I've run firewall restart twice and I assumed that by user include rule would end up inserting my iptables rule twice Jun 15 15:38:19 but it does not to my suprise. How is this possible? Does fw3 delete all rules and flush all chains? I looked around the source-code and did not appear to be doing that. Jun 15 15:39:48 Neighbor11111116: depends. if you rule jumps to an internal chain or is placed in an internal chain then it'll get removed Jun 15 15:40:08 fw3 will remove all rules that reference internal hcains in order to be able to clean these up Jun 15 15:40:26 something like iptables -I INPUT -j ACCEPT will be retained Jun 15 15:40:56 Does internal chain mean chains that come with filter,mangle and nat table? Jun 15 15:41:17 a rule like iptables -I INPUT -j zone_wan_dest_REJECT or iptables -I zone_wan_forward -j ACCEPT will get dropped Jun 15 15:41:50 Neighbor11111116: https://oldwiki.archive.openwrt.org/doc/uci/firewall#packet_flow Jun 15 15:41:54 (Type "internal") Jun 15 15:43:16 Ok got the type thing Jun 15 15:43:17 you also need to differentiate between restart and reload Jun 15 15:43:31 iirc a firewall restart will flush the entire ruleset and rebuild it Jun 15 15:43:46 only a reload will leave things in place (and potentially call firewall.user multiple times) Jun 15 15:43:51 I didn't know that, so firewall restart will delete all rules? Jun 15 15:44:34 Wow, just confiemd that is the case Jun 15 15:45:55 Ok that explains the behaviour perfectly. Thanks as always jow! Jun 15 18:07:33 KanjiMonster: I staged the changes in my staging tree Jun 15 18:07:49 we cannot implement alternatives conflicts due to the kconfig recursive dependency limitations Jun 15 19:15:19 jow, I've noticed that miniupnpd access iptables independently of fw3. Isn't their a risk of race conditions between the two? Jun 15 19:15:22 there* Jun 15 19:30:01 Hauke:ping Jun 15 20:02:57 ynezz: I'm not using mt7621 myself yet, but when I looked into it, https://wikidevi.com/wiki/YouHua_WR1200JS https://wikidevi.com/wiki/ZBT_WE1326 (careful, newer revisions might only ship with 256 MB RAM) and https://wikidevi.com/wiki/ZBT_WG3526 were top on my list Jun 15 20:15:07 Hauke: ping Jun 15 20:35:07 pkgadd I'm using some YouHuas, works great from what I can tell Jun 15 21:45:36 mangix: pong Jun 15 21:46:04 Hauke: mind if I take this package over? https://github.com/openwrt/packages/pull/9236 Jun 15 21:46:46 mangix: no problem, I wasn't aware that I am the maintainer Jun 15 21:46:55 it would be nice if you could take this over Jun 15 21:53:03 Done **** ENDING LOGGING AT Sun Jun 16 02:59:58 2019