**** BEGIN LOGGING AT Mon Apr 08 02:59:57 2019 Apr 08 06:30:20 rise and shine Apr 08 06:50:49 blogic:ping Apr 08 09:30:43 Hi all, I know this is a very estoeric question. Why does my desktop (Ubuntu) ldconfig not work with one of my OpenWRTs. This one is a little old and uses uClibc. When I run ldconfig on this OpenWRT root directory the cache ends up storing 0 libraries. Apr 08 09:31:00 Is there something weird about uClibc that normal ldconfig can not be applied to it? Thanks in advance Apr 08 09:35:36 dedeckeh: hey Apr 08 10:03:25 nbd: ping Apr 08 10:03:48 nbd: can you please provide me your thoughts on this one Apr 08 10:04:22 nbd: kernel 4.19.26 contains a commits which fixes slave checking and thus deletes ifindex: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.26&id=6d26c375a48383681a70e4ad5b0c129ced7ee255 Apr 08 10:04:42 nbd: is it correct in this case to also delete it from your caching? : https://git.openwrt.org/?p=openwrt/staging/xback.git;a=blobdiff;f=target/linux/generic/hack-4.19/650-netfilter-add-xt_OFFLOAD-target.patch;h=8ebea32a822d7b7e25d6fd2572b6fcb34565cbfe;hp=ab1bb6aa817f04fd4099e035ad391183bb30a807;hb=a1bccee1511af50bf38d0e32f18dbc70f419d18d;hpb=af95baa5174fa774bb0250a29f7e30316d44c4c5 Apr 08 10:04:54 or should it still be retained? Apr 08 10:05:30 this is the last part holindg me from submitting a 4.19 bump :) Apr 08 10:07:18 ack Apr 08 10:07:42 :q Apr 08 10:07:43 oops Apr 08 10:08:43 nbd: ack as in "your approach is correctly in deleting this" ? (just to be sure) Apr 08 10:11:19 yes Apr 08 10:11:40 should probably run some tests to be sure Apr 08 10:11:44 but it looks right to me Apr 08 10:13:41 nbd: thanks. will do Apr 08 10:36:04 continues to damage a wall with his head - 'that's very nice, can you re-write it using the rcu mechanism' 1 week later I may be back at working code again...maybe. Apr 08 10:39:39 KevinDB: You could have replied "no" .. ;-) Apr 08 10:40:54 But look at the bright side ... If I ever run into RCU issues .. i'll be able to consult you :-) Apr 08 10:40:54 and they say 'we will not accept your code' Apr 08 10:41:32 and I'll copy/paste you my reply, which is what I'm doing with the code :-) Apr 08 10:42:58 my HDD is too small Apr 08 10:45:43 nbd: did you ever try or managed to get profiling work on Broadcom MIPS CPUs? Apr 08 10:45:52 BCM4706 etc. Apr 08 10:50:15 hm, it looks like it should works... Apr 08 10:50:17 [ 0.071947] Performance counters: mips/74K PMU enabled, 4 32-bit counters available to each CPU, irq 5 Apr 08 10:50:38 but it seems I'm not getting any profiling data Apr 08 10:50:39 [ perf record: Woken up 1 times to write data ] Apr 08 10:50:45 Hauke: any idea about that? Apr 08 10:51:31 rmilecki: if you're bored ;-) you could try to work out why ath79 perf doesn't work (lack of interrupt type error) but works ok on ar71xx for the same board - archer c7 v2 Apr 08 10:52:01 KevinDB: I can't even imagine when I could find time for that ;) Apr 08 10:52:08 KevinDB: is there a DTS entry for PMU? Apr 08 10:52:08 lol Apr 08 10:52:31 you need something like: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1ff80363524cf78e2894b1c6fdd5b7b03ea41994 Apr 08 10:53:03 dunno, a good first thing to look at :-) Apr 08 10:54:12 or maybe MIPS works differently... Apr 08 10:54:43 https://elixir.bootlin.com/linux/latest/source/arch/mips/kernel/perf_event_mipsxx.c it seems on MIPS PMU is registered based on CPU type, it doesn't require PMU info in .dts Apr 08 10:55:33 KevinDB: compare "Performance counters:" dmesg line betwen ar71xx and ath79 Apr 08 10:56:02 I'm busy breaking/fixing something else at the moment - some useful pointers though for when I finish :-) Apr 08 11:40:34 rmilecki: maybe the irq number is wrong Apr 08 11:40:51 nbd: i tried IRQs 2, 5, 6, no luck Apr 08 11:41:13 2 is used by gpio & TTY, 4 by bgmac, 7 by timer Apr 08 11:41:41 s/tried IRQs 2/tried IRQs 3/ Apr 08 11:42:13 I have in the back of my mind that the perf interrupt internally is irq 13 Apr 08 11:42:46 i just found it... this minute Apr 08 11:42:49 -e cpu-clock does the trick Apr 08 11:48:15 ping mangix Apr 08 11:56:19 nbd: could you look at my NAT performance with BCM4706 (MIPS), please? Apr 08 11:56:21 nbd: https://pastebin.com/2MjHWcak Apr 08 11:57:10 nbd: disabling GRO results in not calculating checksums AND lower NAT speed... i don't understand it Apr 08 11:57:38 it's the opposite of what I saw on BCM47094 (dual core ARM) Apr 08 12:00:59 there is no easy solution to this Apr 08 12:01:24 there's some ongoing work that could solve this Apr 08 12:02:00 nbd: but can you explain the reason for that? Apr 08 12:02:08 nbd: also can you reveal what work is that? Apr 08 12:02:08 as far as i know, people are working on a reduced variant of GRO, which simply puts packets in a list that is easy to split Apr 08 12:02:18 i've seen some patches for UDP on the list Apr 08 12:02:25 ok, nice to know Apr 08 12:02:28 that could potentially be extended to tcp routed traffic in the future Apr 08 12:03:01 GRO itself improves performance by making sure that fewer packets travel through the network stack Apr 08 12:03:12 nbd: what about this MIPS situation... it seems disabling GRO results in lower CPU load AND lower NAT performance... any idea what si that? Apr 08 12:03:12 but the checksum overhead is significant as well Apr 08 12:03:25 so it varies by platform, which part produces or saves more CPU overhead Apr 08 12:03:33 or memory bus overhead Apr 08 12:03:42 nbd: or in other words: why i'm getting diferent results on MIPS vs. ARM? Apr 08 12:03:55 hm, memory access can be quite different for MIPS vs. ARM Apr 08 12:04:33 when the cpu is not able to handle the full load, the latency of network stack processing could impact TCP a lot Apr 08 12:04:58 that is also strongly affected by GRO Apr 08 12:06:26 nbd: thanks for explanation, i appreciate it Apr 08 12:07:54 dumping firmware over serial: i used hexdump, without "-v", so repeating lines are replaced with '*'. apparently xxd -r doesn't handle this. does anyone know if there exists a tool to reverse hexdump with repeating line grouping? Apr 08 12:12:34 donn_: why over serial? Apr 08 12:12:37 donn_: even with -a? Apr 08 12:13:08 and i would use base64 for this, not hexdump Apr 08 12:13:44 over serial because i can't get network up (yet) Apr 08 12:14:29 xxd -a -r seems to be what i want, but it fills with zeros instead of the last line of bytes Apr 08 12:14:38 lol Apr 08 12:14:50 so obviously if you have a lot of FF's repeating, they'll end up being 00s Apr 08 12:15:38 have you considered an external spi programmer? Apr 08 12:15:39 yeah, i'll do base64 the next time, hexdump usually works fine but i forgot the -v this time, and it took about 12 hours so... Apr 08 12:16:04 russell--: it's a nand chip and i don't have a reader for that Apr 08 12:17:26 i wrote a bash script to fix the dump, but wondered whether i was re-inventing the wheel Apr 08 12:18:58 whenever i've dumped flash over serial it's been from the bootloader, and never had anything so fancy has hexdump Apr 08 12:19:30 russell--: yeah, i'm running from an initramfs Apr 08 12:19:48 usually you can get a hexdump from the bootloader using the memory read though Apr 08 12:20:03 yes, but without all the fancy options ;-) Apr 08 12:20:33 in this case it's the fancy options which screwed me Apr 08 12:20:39 lol Apr 08 12:21:10 well, there is always starting it off again and finding something else to do, like sleep Apr 08 12:21:30 true :) Apr 08 12:36:22 So is calling "make install" just not a thing in OpenWRT? Apr 08 12:36:47 dansan: what do you expect that to do? Apr 08 12:37:06 russell-- You know autotools, right? Apr 08 12:37:11 I expect it to do make install Apr 08 12:37:17 of what? Apr 08 12:37:24 my package Apr 08 12:37:28 that is autotools based Apr 08 12:37:34 that I configured with a --prefix Apr 08 12:38:02 I guess I shouldn't have expected it to make sense Apr 08 12:38:03 have you looked at other package makefiles? Apr 08 12:38:10 yes and I'm stunned Apr 08 12:38:34 gch981213: https://bugs.openwrt.org/index.php?do=details&task_id=2216 does it ring the bell? Apr 08 12:38:35 they seem to all be doing $(INSTALL_DIR) $(1)/something and then a bunch of $(CP) Apr 08 12:39:39 A brave man once said "sometimes all of the birds can be flying in the wrong direction." Then he was killed Apr 08 12:40:21 ok, I made that up Apr 08 12:41:29 wife: "be careful, they say on the news some idiot is driving the wrong way!" husband: "one? there are hundreds of them!" Apr 08 12:41:59 Oh, I see! Your Package/something/install is supposed to take that you put in $(PKG_INSTALL_DIR) and copy it to $(1) perhaps Apr 08 12:42:21 LMAO!!! Apr 08 12:42:34 I remember that joke, wonderful! :) Apr 08 12:43:45 I had to bypass the standard configure and Build/Compile/Default and Build/Configure/Default because this package is UUUGGGLLLYYY! Apr 08 12:43:57 dansan: generally you don't want everything that the package "installs" for space reasons Apr 08 12:44:05 I had to get OpenJDK 8 working and it's such a fragile build Apr 08 12:44:21 ahh, gotcha! Apr 08 12:44:42 That does make sense, thank you russell-- Apr 08 12:44:46 manpages etc Apr 08 12:45:20 I guess I can working on stripping those out later Apr 08 12:46:16 I never actually isolated what OpenWRT was passing to the build that broke it, but I'm about to crest the 16 hour mark and I've finally got it working Apr 08 12:49:07 last week was really funny, I was trying to get the test running, but I didn't want to try to run it on my little board, so I managed to get them to run under qemu. Apr 08 12:51:07 So has anybody made any serious proposals to migrate the main build system, (or harness?) away from Make and into something robust that's maybe portage/apt/dpkg/rpm/abuild-like? Apr 08 12:52:01 There's so much cool stuff in OpenWRT, but it feels like a root-bound plant that needs more room to grow. Apr 08 12:53:42 ooh nice! I tried to cheat and I just got this message: "Package OpenJDK is missing dependencies for the following libraries"... Apr 08 12:57:03 kernel bumps pushed to master Apr 08 13:00:30 thanks, I've just built the previous bumps :) Apr 08 13:01:09 so far 4.14.110 boots on imx6 Apr 08 13:01:35 finally got some time today to catch up that work Apr 08 14:10:04 ynezz: Unfortunately I currently don't have any ar9341 router with me and can't do any actual tests. Comparing driver code doesn't show me any clue so far. Apr 08 14:13:19 WR841ND v9 is a QCA953x router and I don't have that one with me either :( Apr 08 14:13:32 i've seen stuff like that happen when the pll info is incorrect Apr 08 14:22:12 DonkeyHotei: Incorrect PLL will cause packet drop but shouldn't cause the link to go down. Link status is gathered from PHY through mdio bus, not the MII interface. Apr 08 14:22:51 and yet, when i had the pll wrong on the qca9558, it did exactly thay Apr 08 14:22:54 *that Apr 08 14:42:32 DonkeyHotei: PLL isn't changed in my patchset. But thanks for suggestions anyway :) Apr 08 15:46:31 gch981213: no problem at all, just in case you could spot something from the code, I'll try to find some time to dig something with ar9341 and test it as well Apr 08 16:58:02 cotequeiroz: pong Apr 08 17:01:45 I have looked at openssl. Even though their build system has -fPIC hardcoded, we append $(FPIC) to the end of CFLAGS, and the last one is applied. Apr 08 17:02:10 Unless for some reason $(FPIC) is undefined/empty. Apr 08 17:04:55 hrm ok. Apr 08 17:05:01 Note that FPIC is set by rules.mk. Someone would have to unset it. Apr 08 17:06:31 I'm just wondering if -fPIC and -fpic are mutually inclusive Apr 08 17:06:59 that is, fPIC taking precedence even if -fpic is set Apr 08 17:07:27 quick google search says the former implies -mlarge-data and the latter -msmall-data Apr 08 17:09:21 -fpic sets __PIC__=__pic__=1; -fPIC sets them to 2. You may compile something that print them out and check yourself. Apr 08 17:10:40 I've done that before I came back with the answer, btw. Apr 08 17:10:42 wait a minute... it says here -mexplicit-relocs also has to be set. no wonder i see no size difference Apr 08 17:10:59 It only makes a difference in ppc. Apr 08 17:11:38 i thought the reason for using -fPIC in PPC is cause -fpic is broken Apr 08 17:12:34 It's about a limitation to the global offset table (GOT). Apr 08 17:12:44 fPIC works around that limitation. Apr 08 17:13:15 Aarch64 is also affected, not only PPC, but it is set to fpic nonetheless. Apr 08 17:15:18 My source for this, btw is gcc info, 3.16. Apr 08 17:21:17 fair enough Apr 08 17:23:46 Did you have time to check my latest (yesterday) proposed fix to the python recursive dependencies? Apr 08 17:25:36 * mangix looks Apr 08 17:27:02 https://github.com/openwrt/packages/issues/8535#issuecomment-480555092 Apr 08 17:29:02 I'm still testing it, to make sure I'm not missing anything, so I haven't opened a PR yet. Apr 08 17:29:05 on first glance, it seems sound. Apr 08 17:30:41 Now that I think about it, bluetooth devices are almost all bluetooth based. Even the minipcie ones Apr 08 17:30:56 *USB based Apr 08 17:31:38 They're _all_ USB based, and that's why they have that dependency. Apr 08 17:31:41 rmilecki: I have never used perf Apr 08 17:32:39 rmilecki: do you have some good tutorial for perf? Apr 08 17:32:44 on MIPS ;-) Apr 08 17:34:50 not really a tutorial, but this could be helpful: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html Apr 08 17:36:12 I'm trying to make the default for openssl engine support to be target-dependent. Targets with hw crypto should enable it by default. I'm tring to find a symbol to use for it. Does anyone have any suggestion? Apr 08 17:40:37 cotequeiroz: there is CONFIG_CRYPTO_HW for the kernel. Apr 08 17:41:14 I've seen that, but it does not make it into the global .config Apr 08 17:46:40 Is there a way to use it from the package Config.in, or how to add it to .config? Apr 08 17:49:17 I know USB_SUPPORT is in both kernel and top .config files. Apr 08 18:16:06 cotequeiroz: currently the build bots are building openssl only for each cpu architekture and not for each target Apr 08 18:16:21 e.g. the lantiq and the ar71xx target use the same packages Apr 08 18:17:04 but you can mark them openssl package non shared then it is build for each target Apr 08 18:22:23 Any hints as to how to keep LimeChat from constantly disconnecting? pong of 20 seconds already set Apr 08 18:22:40 Or a better macOS client? Apr 08 18:27:29 Unless there is specificly something wrong with your openwrt device, answer would be generally also no Apr 08 18:40:18 DTS "style" -- Is it preferred to refer to a node in an upstream DTS by label, `&blsp1_uart1`, or by node, `serial@78af000` when both are present upstream `blsp1_uart1: serial@78af000` ? Apr 08 18:41:50 Thanks Hauke. I will try that. How can I read the kernel CONFIG_CRYPTO_HW symbol from the package? Apr 08 18:45:47 I won't be able to make this non-shared, unless ALL dependents are also non-shared. See https://github.com/openwrt/packages/pull/8602#issuecomment-480516972 Apr 08 18:59:41 Hauke: i didn't really use any tutorial Apr 08 19:00:19 Hauke: on ARM I do "perf record -a -g -- sleep 5", on MIPS I do "perf record -a -g -e cpu-clock -- sleep 5" - those commands capture CPU load for 5 seconds and create perf.data Apr 08 19:00:44 Hauke: then I copy perf.data to my host, as "ash" doesn't handle perf output nicely Apr 08 19:01:30 Hauke: on host I do "perf report --no-child -k build_dir/target-*/linux-*/vmlinux.debug" Apr 08 19:01:51 Hauke: and I check for high/outstanding percentage values Apr 08 19:06:48 rmilecki: thanks Apr 08 19:16:16 rmilecki: i can recommend the FlameGraph scripts Apr 08 19:16:29 they make the whole thing much easier to digest Apr 08 19:16:53 i skipped that part as stintel already suggested it to Hauke:) Apr 08 19:17:17 Hauke: demo: http://www.brendangregg.com/FlameGraphs/cpu-mysql-updated.svg Apr 08 19:35:16 cotequeiroz: I know dell used to ship bluetooth as a separate minipcie module on their laptops. would be surprised if that uses usb Apr 08 19:36:10 would or wouldn't? Apr 08 19:36:25 would Apr 08 19:37:07 I'd be more surprised if it was pcie :) Apr 08 19:37:52 cotequeiroz: I'm considering eliminating all +@OPENSSL dependencies in the packages repo based on jow's suggestion. Thoughts? Apr 08 19:38:44 I should have said that differently back then. Currrently, USB_SUPPORT must be on to build kmod-bluetooth; that's all I know :) Apr 08 19:41:29 jeffsf: did you try to find out why your IRC client misbehaves that way, e.g. I could also imagine that it isn't really the client's fault, but aggressive power saving on the OS side. but temporarily trying a different IRC client (quassel, hexchat, irssi, etc., there should be hundreds of options) might also be worth a try Apr 08 19:44:36 looked up dell's minipcie bluetooth card. looks like it's USB. Apr 08 19:44:44 :) Apr 08 19:45:09 well, minipcie to USB. more accurately, minipcie has USB pins Apr 08 19:45:38 how did this come up? is someone upset at not having one of their uart connected bt modules not workign without turning on usb? Apr 08 19:46:01 I mean, yeah, you _shouldn't_ need usb support to build bluetooth, but the chances of having a system that has bt but no usb seems vanishingly small Apr 08 19:47:02 pkgadd: Strangely it works on my macOS laptop, but not on my desktop! So, for now, I pop open the laptop. Cleaning up DTS files and tracing down packets are both sooooo high on my list of things I love to do Apr 08 19:47:52 karlp: more like impossible Apr 08 19:48:01 (moved EA8300 back to 4.14, and ordered two more yesterday as Amazon US had them for $115 each -- gives me Archer C7v2 replacements and one to mess around with) Apr 08 19:48:33 I'm sure I could build one, but yeah, I don't see it ever being a practical problem that bluetooth needs usb for anyone in reality Apr 08 19:49:27 jeffsf: why replace archer c7v2? Apr 08 19:50:26 mangix: Because (a) someday they're going to die on me, and (b) EA8300 has 2x 5 GHz radios, so I can use one for backhaul and one for clients Apr 08 19:51:10 No real complaints with the five I've got, with four in active serrvice Apr 08 19:52:13 ah ok Apr 08 19:56:49 yep, the ea8300 looks like a really nice device (the 6350v3 as well) Apr 08 19:57:33 ugh I hate ubuntu kernels Apr 08 19:57:46 don't follow upstream and love crashing Apr 08 19:57:59 I mean panicking Apr 08 19:58:18 If you're blue and you don't know where to go to Apr 08 19:58:18 Why don't you go where fashion sits? Apr 08 19:58:42 I'm using an ubuntu derivative and love it Apr 08 19:59:03 I should probably just compile my own Apr 08 19:59:22 I ran 5.0 a while back. Apr 08 20:00:17 ah stanislaw's iommu fix made it in 4.19. Looks like it's time :) Apr 08 20:02:03 rmilecki: re our earlier perf https://pastebin.com/VvDraB1H Apr 08 20:02:38 ldir: is that ath79 target? Apr 08 20:02:44 yep Apr 08 20:03:06 ldir: ok, now check the ar71xx, you may also provid cat /proc/interrupt Apr 08 20:03:16 /proc/interrupts Apr 08 20:04:41 Have to build ar71xx again :-). interrupts https://pastebin.com/YCZ3QCtv Apr 08 20:11:48 wow. openwrt make menuconfig is simple. kernel make menuconfig is alien Apr 08 20:12:37 mangix: is this the first time you're opening menuconfig? :-P Apr 08 20:13:08 pretty much Apr 08 20:13:20 following this guide: https://www.maketecheasier.com/build-custom-kernel-ubuntu/ Apr 08 20:13:29 heh. with all you've tinkered with openwrt Apr 08 20:13:58 hehe kernel config. years ago. Apr 08 20:14:58 I just realized I submitted a patch that claims no size increase. change is for kernel 4.19. I tested the size of kernel 4.14. Apr 08 20:15:20 back to the drawing board Apr 08 20:17:14 Borromini: not sure if it was you that I saw a package checksum fix up go through for - if so, you might find 'make package/foo/check FIXUP=1' useful for auto updating the package download hash for you Apr 08 20:18:00 and 'make package/foo/download PKG_HASH=skip' for downloading the updated source in the first place Apr 08 20:18:12 ldir: thanks, it was i indeed :-) Apr 08 20:40:57 blocktrron: thanks for your work on mpc85xx regarding the wdr4900 Apr 08 21:17:20 blogic john@phrozen.org is your latest mail address right? Apr 08 21:35:13 rmilecki: and a working one on ar71xx (same hardware) https://pastebin.com/NJiUASVm Apr 08 21:42:01 aparcar[m]: yes that is blogic's mail Apr 09 02:35:17 ping mangix **** ENDING LOGGING AT Tue Apr 09 03:00:03 2019