**** BEGIN LOGGING AT Mon Apr 01 02:59:57 2019 Apr 01 05:13:12 philipp64: just rebase it? Apr 01 05:47:13 jow: no, that didn't work. see my email. Apr 01 05:47:55 tmn505: ping Apr 01 05:51:53 philipp64: why didn't it work? Apr 01 05:53:03 only found a mail from 20th or so showing some conflicts Apr 01 06:06:37 Yeah, that was the one. Apr 01 06:07:38 jow: Well, and again today as "Rebasing "Generate EFI grub images for x86 platforms" (resend)" Apr 01 06:08:26 Are the EFI patches ever going to get merged? I've been using them for over a year and they seem solid. Apr 01 06:09:58 well I rebased my staging tree a few days ago and had no problems resolving the conflicts, so not sure what the problem is Apr 01 06:10:05 as for merging, the build is not solid for me Apr 01 06:10:16 the grub efi vs. non-efi seems to not work well Apr 01 06:10:31 keep overriding each others stamp fles, spurious rebuilds etc. Apr 01 06:10:47 no idea about sysupgrade compatibility and so on Apr 01 06:11:44 I thought Golle had the sysupgrade stuff working. worked for me, anyway. Apr 01 06:22:31 from non-efi to efi? Apr 01 06:42:22 mangix: I've implemented netif_receive_skb_list for ag71xx and only saw slight improvement on iperf result (around 2Mbits/sec). Apr 01 06:47:37 Here's the commit if someone wants to try it: https://github.com/981213/openwrt/commit/24c14dcf4f9e1a633dd4657a4b2063a5ea1fd724 Apr 01 07:13:23 gch981213: wow. more elaborate than my attempt Apr 01 07:14:23 https://github.com/neheb/source/commit/b24342a5bda88a869ffe5a2e6cafc672d566732e Apr 01 07:16:19 I tried implementing it a different way but it ended up leaking memory. On the bright side, I measured a 120-130mbps improvement Apr 01 07:16:39 mangix: I think your implementation made skb->protocol field broken Apr 01 07:17:20 hmm maybe Apr 01 07:17:48 mangix: How you tested that? I only have an single-port ar9344 AP with me and I run iperf on my router directly. Apr 01 07:18:42 I tested on an Archer C7v2. iperf directly Apr 01 07:19:00 erm actually nvm Apr 01 07:19:05 iperf server on router Apr 01 07:19:12 iperf client on laptop Apr 01 07:23:28 mangix: I did the same thing and didn't saw that significant improvement. I guess the low cpu performance is the bottleneck in my case. Apr 01 07:23:40 ah Apr 01 07:23:59 the c7 is overclocked to 1ghz Apr 01 07:24:20 speed goes from ~350 to ~370 with my patch. Will test yours soon. Apr 01 07:30:53 I'm wondering what is the preference with wifi MAC addresses, should they always be incremented if they're derived from WAN MAC address? Apr 01 07:31:45 I was living in impression, that it's always safer (but not required) to use unique MAC address for every interface Apr 01 07:32:39 asking specifically about this case https://github.com/openwrt/openwrt/pull/1495#issuecomment-478372123 Apr 01 07:33:17 ynezz: The preference is to use what the manufacturer used, I think. Apr 01 07:44:01 gch981213: 2-3mbps faster Apr 01 07:44:31 erm compared to my patch Apr 01 07:46:58 there's probably a performance bottleneck somewhere else Apr 01 07:50:45 gch981213: in this case the vendor is using openwrt, where it's probably broken as stated in the commit message Apr 01 07:51:25 gch981213: openwrt used previously `mtd_get_mac_ascii nvram wlan1_mac` so probably unique MAC address Apr 01 07:53:32 since it's broken, no way to check it now Apr 01 08:35:33 i'm trying to compile OpenWrt with kernel 4.15 (for debugging purposes) and I'm getting this: Apr 01 08:35:40 /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /home/rmilecki/openwrt/openwrt-master-bcm53xx/staging_dir/host/lib/libcrypto.a(libcrypto_la-eng_all.o): in function `ENGINE_load_builtin_engines': Apr 01 08:35:42 eng_all.c:(.text+0x30): undefined reference to `pthread_once' Apr 01 08:36:02 (...) Apr 01 08:36:04 make[6]: *** [scripts/Makefile.host:90: scripts/extract-cert] Error 1 Apr 01 08:36:08 any advise? Apr 01 08:38:19 I would try to clean/build openssl package and try again Apr 01 08:49:08 i already did rm -fR build_dir staging_dir Apr 01 08:49:49 jow: buildbot got such a problem and it seems you solved it: https://bugs.openwrt.org/index.php?do=details&task_id=1558 Apr 01 08:49:57 jow: do you remember what was the solution? Apr 01 09:08:56 rmilecki: I was never able to reproduce the problem Apr 01 09:09:08 oh, interesting ;) Apr 01 09:09:16 rmilecki: I'm also not even sure if this is related to the target openssl or host libresll Apr 01 09:09:35 or some mixture of both Apr 01 09:10:00 ah right, libressl (.../staging_dir/host/lib/...) Apr 01 09:10:15 right Apr 01 09:10:20 it could be a host toolchain incompatibility thing Apr 01 09:10:36 undefined reference to `pthread_once' sounds like missing -pthread or -lpthread during the build of libressl Apr 01 09:11:05 is this really gcc 8 on your host? might be too new Apr 01 09:11:34 maybe different pthread semantics, linkage, new goat sacraficing ritual required to link posix threads Apr 01 09:11:39 gcc version 8.3.1 20190226 [gcc-8-branch revision 269204] (SUSE Linux) Apr 01 09:11:40 or wahtever Apr 01 09:12:01 jow: it only happens after switching KERNEL_PATCHVER:=4.14 to the 4.15 Apr 01 09:12:23 https://github.com/libressl-portable/portable/issues/446 Apr 01 09:12:32 rmilecki: I doubt that this is related Apr 01 09:12:40 probably just coincidence Apr 01 09:12:54 or some random util unblocked by the kernel version switch Apr 01 09:13:15 ok Apr 01 09:13:16 e.g. some DEPENDS:=@!LINUX_4_14 Apr 01 09:13:29 ok, i see Apr 01 09:14:19 this PR supposedly fixes the link error: https://github.com/libressl-portable/portable/pull/447/files Apr 01 09:14:38 i noticed that, thanks :) Apr 01 09:14:45 you could try throwing it as patch into tools/libressl/patches/ Apr 01 09:18:22 i can't reproduce it now... oh my Apr 01 09:18:35 (before backporting that libressl patch!) Apr 01 09:19:16 rmilecki: that matches my experience as well :) Apr 01 09:19:24 ;) Apr 01 09:27:35 ok, I just reproduced it, I think i should be able to bisect that quickly... out of curiousity at least Apr 01 09:34:00 ack, it's not a kernel change related Apr 01 09:40:29 hrm, I'm getting wallys spam too Apr 01 09:40:54 I guess they got a new marketing person. Apr 01 09:44:38 oh crap, what an annoying issue... Apr 01 09:44:55 jow: i put both patches there, called make tools/libressl/compile V=s Apr 01 09:44:59 didn't help Apr 01 09:45:04 now i also can't compile 4.14 Apr 01 09:45:06 wtf Apr 01 09:45:24 rmilecki: not sure if tools/libressl/compile cleans, patches and builds the sources again Apr 01 09:45:33 did you do make tools/libressl/clean before? Apr 01 09:45:41 i think it recopmiled Apr 01 09:45:47 will do anyway, just i ncase Apr 01 09:46:27 Applying ./patches/001-f819a2bce7a708147df16b5bef21ccaadf7b9913.patch using plaintext: Apr 01 09:46:29 Applying ./patches/002-0b8343ace3a854fcb2d7bed850847db54841d6cf.patch using plaintext: Apr 01 09:49:33 what a CRAP aaargh Apr 01 09:51:26 rmilecki: and you simply add something like HOST_LDFLAGS += -lpthread ? Apr 01 09:51:40 jow: whete? :/ Apr 01 09:52:52 in tools/libressl/Makefile Apr 01 09:53:52 recmompiling Apr 01 09:56:40 jow: nope, still failing Apr 01 09:57:41 jow: a more complete log if that helps https://pastebin.com/FhJTs31S Apr 01 10:00:28 ah Apr 01 10:00:39 all the time I thought its libressl failing to link its own tools or something Apr 01 10:00:44 but this is some random kernel tool Apr 01 10:03:06 oops :( sorry for a false lead Apr 01 10:05:53 rmilecki: could you try something like export HOSTLDLIBS_extract-cert="-lcrypto -lpthread"; make ? Apr 01 10:07:15 is that expected? export HOSTLDLIBS_extract-cert="-lcrypto -lpthread" Apr 01 10:07:17 bash: export: `HOSTLDLIBS_extract-cert=-lcrypto -lpthread': not a valid identifier Apr 01 10:07:41 yeah, brainfart Apr 01 10:08:16 i guess "-" is not allowed in variable name? maybe? Apr 01 10:12:36 rmilecki: http://sprunge.us/u5KkfC Apr 01 10:12:45 try this Apr 01 10:13:02 mangix: IMO accepting PRs that introduce less reliable shell code is a bad idea. Apr 01 10:13:23 using the new functions is one thing, but blanket replacing ${} with $ "just because" seems like laying mines for people Apr 01 10:13:43 jow: didn't help :( Apr 01 10:14:56 rmilecki: then you need to patch upstream kernel scripts/Makefile or disable CONFIG_SYSTEM_TRUSTED_KEYRING Apr 01 10:16:13 CONFIG_SYSTEM_TRUSTED_KEYRING is selected by SYSTEM_DATA_VERIFICATION Apr 01 10:16:22 SYSTEM_DATA_VERIFICATION is selected by e.g. MODULES [=y] Apr 01 10:16:27 no way to disable that I'm afraid Apr 01 10:17:39 karlp: noted Apr 01 10:17:51 i added HOSTLDLIBS_extract-cert="-lcrypto -lpthread" to the scripts/Makefile but it didn\t help Apr 01 10:18:17 oh, it should be HOSTLOADLIBES_extract-cert Apr 01 10:18:21 HOSTLOADLIBES_extract-cert did that trick... Apr 01 10:18:22 omg Apr 01 10:18:27 what a mess Apr 01 10:18:29 thank you jow Apr 01 10:18:44 * rmilecki is getting a tea Apr 01 10:22:01 rmilecki: ah great. Seems the variables got renamed in upstream Apr 01 10:24:35 rmilecki: SYSTEM_DATA_VERIFICATION is selected by MODULE_SIG, not MODULES; and that should be disabled by default Apr 01 10:30:32 KanjiMonster: # CONFIG_MODULE_SIG is not set Apr 01 10:31:16 KanjiMonster: ahh, i see MODULE_SIG [=n] && MODULES [=y] Apr 01 10:31:24 so it's sth else selecting that for me... let me check again Apr 01 10:31:40 CFG80211_REQUIRE_SIGNED_REGDB [=y] && NET [=y] && WIRELESS [=y] Apr 01 10:31:57 apparently I have cfg80211 enabled at kernel level Apr 01 10:34:03 rmilecki: regardless of whether that keyring stuff happens to be enabled or not, adding th flags to include/kernel.mk might be a good idea anyway Apr 01 10:34:31 jow: i'll try to check later why it happens with 4.15 Apr 01 10:34:36 i can compile 4.14 and 4.19 just fine Apr 01 10:45:45 jow: this problem doesn't occur with 4.16, but i don't have CONFIG_SYSTEM_TRUSTED_KEYRING in my .config there Apr 01 10:46:42 are you still looking at this performance regression? Apr 01 10:47:33 karlp: yes, yesterday I found a commit that *improved* performance in the 4.4.35 Apr 01 10:47:43 today I'm looking at performance drop on 4.14 -> 4.19 switch Apr 01 10:47:50 4.14 and 4.15 are both fast Apr 01 10:48:28 jow: in 4.16 SYSTEM_DATA_VERIFICATION it's CFG80211_REQUIRE_SIGNED_REGDB [=n] && NET [=y] && WIRELESS [=y] && CFG80211 [=n] Apr 01 10:48:51 jow: condition of CFG80211 was added, so it's working again (and that's why it was broken for me in 4.15) Apr 01 10:49:05 jow: in any case, thanks a lot for looking at that with me!!! Apr 01 10:49:52 karlp: to make it more fun, one of OpenWrt downstream patches lowers LAN to WAN performance for me (doesn't affect WAN to LAN) Apr 01 10:50:00 i don't know which one yet Apr 01 10:50:12 I dropped 90% of patches and noticed my LAN to WAN going faster Apr 01 10:50:44 rmilecki: you're welcome Apr 01 10:52:59 rmilecki: which commit in 4.4.35 improved performance? (curious about this one) Apr 01 10:53:17 xback: 225a24ae9733 ("tcp: take care of truncations done by sk_filter()") Apr 01 10:53:32 it increased performance by 10 Mb/s for me Apr 01 10:54:02 it was really hard to bisect as 10 Mb/s is very easy to miss Apr 01 10:56:59 oh crap Apr 01 10:57:01 FATAL ERROR: Unrecognized check name "avoid_unnecessary_addr_size" Apr 01 10:57:02 make[4]: *** [Makefile:393: /home/rmilecki/openwrt/openwrt-master-bcm53xx/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx/image-bcm4708-asus-rt-ac68u.dtb] Error 1 Apr 01 10:57:10 there's always something.... Apr 01 11:03:08 ok, it's a broken check in the include/image.mk Apr 01 11:03:17 kernel_patchver_ge,4.16.0 vs. kernel_patchver_ge,4.17.0 Apr 01 11:03:39 please send patches for all these little things Apr 01 11:03:49 its unlikely someone will ever encounter them again Apr 01 11:37:59 rmilecki: sorry, I've checked changes in cbbef976e2b with kernels 4.14 and 4.19 only Apr 01 11:39:17 that avoid_unnecessary_addr_size option was introduced in 4.16-rc3, so kernel_patchver_ge,4.16 seems ok to me Apr 01 11:40:51 yanosz: it was not Apr 01 11:40:56 ynezz: it was not Apr 01 11:41:09 ynezz: it was added in a branch based on then 4.16-rc3 Apr 01 11:41:20 but it wasn't merged into Linus's tree until 4.17 merge window Apr 01 11:41:35 so the first Linus's release with that code is 4.17 Apr 01 11:42:05 i see how you got confused about that though Apr 01 11:42:26 ah, thanks for clarification, so probably all the checks needs to be fixed :( Apr 01 11:43:30 yeah, that one also failed for me: kernel_patchver_ge,4.17.0 Apr 01 11:47:51 ynezz: to find out which releases include a certain commit you can use "git tag --contains " on linus' tree Apr 01 11:49:18 KanjiMonster: yeah, noted, that I shouldn't use `git describe ` for that Apr 01 11:51:54 rmilecki: are you going to fix those or should I do it? Apr 01 11:52:07 ynezz: if you can handle that, it would be great Apr 01 11:52:19 i'm fighting with too many issues right now Apr 01 11:52:45 net/netfilter/nf_conntrack_rtcache.c:82:11: error: 'const struct rt6_info' has no member named 'rt6i_node'; did you mean 'rt6i_idev'? Apr 01 11:53:01 020-backport_netfilter_rtcache.patch seems broken unless I'm missing something Apr 01 11:53:30 it seems we never compile with CONFIG_NF_CONNTRACK_IPV6=y Apr 01 11:53:43 that would be quite unlikely Apr 01 11:53:47 or =m Apr 01 11:53:53 right, we build it as =m Apr 01 11:54:07 so we're lucky that the code is Apr 01 11:54:08 #if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6) Apr 01 11:54:32 wait... Apr 01 11:54:37 it should fail with =m as well Apr 01 11:54:43 wtf is going on there... Apr 01 11:54:56 i'm going to explode soon Apr 01 11:55:37 my brain anyway Apr 01 11:55:48 nbd: ping Apr 01 11:57:24 jow: so 020-backport_netfilter_rtcache.patch adds following code: Apr 01 11:57:26 #if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6) Apr 01 11:57:27 const struct rt6_info *rt = (const struct rt6_info *)dst; Apr 01 11:57:29 if (rt->rt6i_node) Apr 01 11:58:03 https://elixir.bootlin.com/linux/v4.19.32/source/include/net/ip6_fib.h#L180 there is no "rt6i_node" Apr 01 11:58:10 how... how... Apr 01 12:00:05 nbd: im checking the 4.19 bump again, specifically flow offload Apr 01 12:00:27 regarding commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.32&id=6d26c375a48383681a70e4ad5b0c129ced7ee255, would you agree it invalidates your patch? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/backport-4.19/366-netfilter-nf_flow_table-clean-up-and-fix-dst-handlin.patch;h=624602dabe549a43035ac00915f2b940c2ff0339;hb=HEAD Apr 01 12:06:57 rmilecki: maybe its fixed in another unrelated patch? Apr 01 12:07:07 or rather supposed to be fixed Apr 01 12:07:17 jow: i don't believe so, I tried grepping Apr 01 12:07:41 try that: grep -R "rt6i_node" target/linux/generic/* Apr 01 12:08:24 rmilecki: https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=6027e490930a2a5ade1c7056303ebc18740ec6f1 Apr 01 12:08:41 jow: are you sure we ever compile with CONFIG_NF_CONNTRACK_IPV6=m ? Apr 01 12:09:01 ynezz: oh my,thanks a lot, one less thing to worry for me Apr 01 12:09:39 regarding NAT performance drop, it seems there is at least one regression between 4.15 and 4.16, another one (or more) in 4.17 and then something in 4.18 OR 4.19 Apr 01 12:10:34 xback: doesn't look that way to me Apr 01 12:11:45 ynezz: if it's any consolation, I did this mistake at first for a while as well (and was confused when I found out it didn't work/was wrong) Apr 01 12:15:32 nbd: ok, thank you. ill try to incorporate the patch then Apr 01 12:31:17 KanjiMonster: and I bet, I'm not the last one :) Apr 01 12:52:23 nbd: was your offload patch mentioned above sent to upstream? Apr 01 12:53:41 seems like i probably forgot to submit it Apr 01 13:33:03 philipp64: pong Apr 01 13:37:56 jow:ping Apr 01 13:40:25 dedeckeh: pong Apr 01 13:41:09 jow:any objection if I apply patch http://patchwork.ozlabs.org/patch/1070262/ ? Apr 01 13:44:55 dedeckeh: I requested a v2 Apr 01 13:45:07 rename tty to dialout and restore the lost hunk Apr 01 13:45:57 I also do not like the "^tty[A-Za-z]+[0-9]+" pattern as it is overly specific, out of line with the style of all other cases and likely prone to failure when encountering unusual tty node names Apr 01 13:48:09 ah indeed this is not the requested v2 version Apr 01 14:03:18 greearb_: not tested that yet Apr 01 14:03:28 building an image with htop right now Apr 01 14:04:11 looks like udps dropage goes down a little but no exact numbers yet, i'll update the thread in the next day with some more detailed data Apr 01 14:39:35 * ldir bashes head against wall Apr 01 14:48:21 don't! the wall might break Apr 01 14:56:51 blogic, I wonder if you are purely seeing crap related to the TCP buffer limitations that have plagued ath10k for years? Apr 01 14:57:58 Also, are you testing with the TCP endpoint on the system with the ath10k radio, or is the ath10k in bridge/router pass-through mode? Apr 01 14:58:14 If the latter, then the TCP stack issue should not be a problem I'd guess. Apr 01 15:36:33 greearb_: bridged eth/ap with 2 thinkpads Apr 01 15:36:48 no nat, routing or locall generated/terminated traffic Apr 01 15:37:02 greearb_: i am running the setup i used when we made hw flow offloading Apr 01 15:37:07 so the test results are real Apr 01 15:37:27 i know the "i am teting the ring size of my network stack" scenario :-) Apr 01 15:37:43 blogic, ok, no everyone has paid that price yet :) Apr 01 15:37:51 greearb_: :-D Apr 01 15:38:15 in pass through mode though, I have a hard time seeing why UDP would have different behaviour than TCP Apr 01 15:38:20 greearb_: measuring throughput it actually not that obvious Apr 01 15:38:31 my testbed Apr 01 15:38:37 just not setup properly Apr 01 15:39:00 one thing that i noticed with wire vs wifi is that dropping framesize make near to no diff Apr 01 15:39:25 on wire i test with 256byte udp frames, see how far i can stretch it before it start dropping Apr 01 15:39:45 on wifi i tested 1000, 512, 256 frames with no apparent diff Apr 01 15:39:51 so you get significantly better pps with your change? Apr 01 15:40:00 i guess that is the ampdu offloading of the 802.3 frames in action right there Apr 01 15:40:22 tcp, 20 interleaved flows with 512 byte frames Apr 01 15:40:33 without the ethernetmoade it caps at around 400 Apr 01 15:40:41 with encap mode at around 465 Apr 01 15:40:45 400Mbps? Apr 01 15:40:49 reproducable and stable Apr 01 15:40:55 yes Apr 01 15:41:00 using base config Apr 01 15:41:14 i think this was vht80 Apr 01 15:41:23 you are using tcp-mss to force 512 byte tcp frames on the wire from the traffic-generator? Apr 01 15:41:25 using 5ghz on a frequency that is pretty free Apr 01 15:41:40 iperf3 -c ... -l 256 -P 20 Apr 01 15:42:01 iperf3 does interleaving unlike iperf which is bursting Apr 01 15:42:24 interleaving will cause more cache misses Apr 01 15:42:30 so worste case scenario Apr 01 15:42:50 but as i said, i wanted to get the patch out the door, i'll do proper testing with htop et-al tomorrow Apr 01 15:43:04 -l is not going to force on-the-wire packet size afaik, did you sniff to verify that packet size? Apr 01 15:43:08 i am actually curious to see what exactly the issue is Apr 01 15:43:16 nope Apr 01 15:43:26 I tested wire alot Apr 01 15:43:34 there it would do 256byte frames Apr 01 15:43:47 as i said, tomorrow i'll do more on depth testing Apr 01 15:44:27 ok, try -M option to set mss, then leave traffic generator writing large frames. That should force small on-the-wire frames but CPU efficient Apr 01 15:44:41 (writing larger frames, maybe not super large) Apr 01 15:44:58 ok Apr 01 15:45:05 so like 16-32k ones ? Apr 01 15:45:07 that at least works if tool is implemented properly, we do that trick in our traffic generator Apr 01 15:45:16 fine Apr 01 15:45:19 thanks for the pointer Apr 01 15:45:42 sure, but depending on lots of things, that might make your interleave slightly more clumpy. Really, you do not have deterministic control over that though afaik. Apr 01 15:45:53 yes Apr 01 15:45:56 correct Apr 01 15:46:04 its a best effort thing Apr 01 15:46:20 i used that on mediatek HW offload, which has an internal 256 slot sram Apr 01 15:46:41 so i was using 400 flows to be heavy on the internal cache of that sram on the flow offloading silicon Apr 01 15:46:48 its still part of my tooling Apr 01 15:47:23 greearb_: sooo Apr 01 15:47:34 the T2H_ADD/DEL_BA calls Apr 01 15:47:39 when will they be generated Apr 01 15:47:44 no bad phrasing Apr 01 15:48:08 do i need to enable summin in the fw to get those generated or will they auto happen when sessions opn/close ? Apr 01 15:49:29 blogic, er, you talking about CT specific sw decrypt of blockack thing, or something else? Apr 01 15:50:41 ath10/11k generic HTT_T2H events Apr 01 15:51:34 the firmware handles the block-ack state machine, and it sends events to driver when something interesting happens like BA is enabled or not. Apr 01 15:51:44 works fine in wave1/wave2 afaik Apr 01 15:52:06 yep Apr 01 18:42:55 hmm, luci still give a warning from the time we had telnet enabled, when a password is not set: "There is no password set on this router. Please configure a root password to protect the web interface and enable SSH." Apr 01 20:30:10 text is wrong about "enabling ssh" but otherwise sitll good Apr 01 20:30:29 it still protects the web and the ssh, just doesn't "enable" ssh anymore Apr 01 21:07:00 hrm, "boxes" will happily run an openwrt x86/64 img, but doesn't seem to have anything about adding a net device to it. Apr 01 21:07:10 so much for trying "the" gnome way Apr 01 21:07:44 and with such a horrific generic name you can't google it anyway Apr 01 21:08:31 guess it's not as popular as systemd. that used to be a complete disaster to google Apr 01 21:08:36 much better nwo Apr 01 21:08:52 "did you mean system?" Apr 01 21:31:15 * russell-- tried to google device tree overlays for a beagle bone black, unfortunately 95% of the results point at cape manager which has been abandoned and unsupported for years Apr 01 22:27:04 karlp: I don't know if I understand your rant, but take a look at scripts/qemustart for some examples of networking qemu setup Apr 01 22:29:36 karlp: it might be little bit outdated, so far I'm using it with --no-network option https://github.com/ynezz/openwrt/commit/59b0cfb9ddc8ae28ce77eff4c66118b91b31a6d0 with x86/armvirt/malta but I plan to test/update networking once I get squashfs filesystem with usable overlay (so I can store settings) Apr 01 23:13:30 eh, just was hoping to quick start by just opening up the image in virt-manager or similar, but it's just there with no interfaces. and I really do want the networking to work. Apr 01 23:14:11 I'll look at qemustart, it's not listed on https://openwrt.org/docs/guide-user/virtualization/qemu though, which is where I was loking first Apr 01 23:20:16 yeah, wiki, outdated by the definition :) Apr 01 23:26:12 * karlp glares at ynezz Apr 01 23:26:30 cos reading pages of someones bash scripting are so much more useful. Apr 01 23:30:51 $ qemu-system-x86_64 -M q35 -drive file=/home/karlp/Downloads/openwrt-x86-64-combined-ext4.img,id=d0,if=none,bus=0,unit=0 -device ide-hd,drive=d0,bus=ide.0 from the wiki page actually works just fine. Apr 01 23:33:12 though I've got some natted setup that I can't reach from the host. Apr 01 23:33:19 * karlp giggles at how many options there are. Apr 01 23:38:19 you probably want -enable-kvm Apr 01 23:38:38 eh, just importing in virt-manager system instead of boxes worked too. Apr 01 23:41:14 good, then I don't need to overwhelm you with http://paste.debian.net/hidden/177f7795/ ;) to be fair, "qemu-system-x86_64 -enable-kvm -m 256 -hda openwrt-x86-64-combined-ext4.img" should be all you (strictly) need, getting the virtual networking set up is a bit more of a hassle for actual usage Apr 01 23:43:40 (only mentioning -m 256, because qemu defaults to 128 MB RAM in the absence of an explicit configuration) Apr 02 01:23:18 russell--: There is an old patch that was never upstreamed I think about an configfs interface to apply device-tree overlays from userspace Apr 02 01:24:16 russell--: I took it from the raspberrypi linux repository Apr 02 01:25:12 * luaraneda sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/nxdMlFZiVPAcSQsknKyKdSqd > Apr 02 01:25:39 (for k4.14) Apr 02 02:47:32 luaraneda: i eventually figured it out **** ENDING LOGGING AT Tue Apr 02 02:59:57 2019