**** BEGIN LOGGING AT Mon Mar 18 03:00:21 2019 Mar 18 08:07:16 ynezz: the bug is indeed ccache related Mar 18 08:11:42 ynezz: can also be triggered with g++-4.9 -save-temps Mar 18 08:13:13 ynezz: it boils down to the fact that g++, under circumstances, produces preprocessed source which it is unable to read Mar 18 08:13:20 or to compile, rather Mar 18 08:13:34 this bug is exposed by ccache Mar 18 08:13:58 its not simple to reproduce because a naive CXX="ccache g++" ./configure in cmake will strip the ccache ivoncation Mar 18 08:14:06 you need to use a wrapper script, like the buildroot does Mar 18 08:15:15 e.g. echo -e "#!/bin/sh\nexec ccache /usr/bin/g++-4.9 \"\$@\"" > /tmp/g++.sh && chmod +x /tmp/g++.sh && CXX=/tmp/g++.sh ./configure && make Mar 18 08:15:26 but that alone is not enough to trigger the error Mar 18 08:15:41 you'll also need to build once, then build *another* time with ccache, only then you see the error Mar 18 08:19:17 thanks for looking into this, honestly I was never been able to use ccache reliably so I always disable it Mar 18 08:21:56 a similar bug report in debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784681 Mar 18 08:22:15 was not able to find a matching bug report in upstream gcc/g++ Mar 18 08:22:23 currently testing whether g++6 is affected as well Mar 18 08:32:00 seems fine on g++6 Mar 18 09:11:13 olmari: I see you as a member on https://scan.coverity.com/projects/openwrt?tab=members and I'm wondering if you're able to see the details for the defects Mar 18 09:14:51 well.. not even... "It may take a few minutes before you can view your defects, when you change your email or password or sign-in with Github for the first time." Mar 18 09:15:13 I signed with github, so far no defects list for me either, which is sad, but dunno where the fault Mar 18 09:18:24 ok, so it doesn't work for you either, I've reported this issue to scan-admin@coverity.com like week ago, so we've probably to wait little bit more :) Mar 18 11:56:29 stintel: ping Mar 18 11:57:59 jow: pong Mar 18 11:58:38 stintel: I wonder if you could test http://lists.infradead.org/pipermail/openwrt-devel/2019-March/016303.html whenever you find time Mar 18 11:58:59 since it reworks the commit we did a while ago do address that jitterentropy kmod load issue Mar 18 12:01:00 jow: next Tuesday at the earliest Mar 18 12:07:05 did anybody work with that meson build stuff yet? Mar 18 12:15:13 jow: I've added a reminder in my calendar next Tuesday for testing that patch Mar 18 12:15:20 I remember seeing some PR for it Mar 18 12:15:34 how close are we to branching 19.03? Mar 18 12:16:05 jow: https://github.com/openwrt/openwrt/pull/1871 Mar 18 12:16:21 ah this is for Ninja, nm Mar 18 12:17:14 ynezz: I don't grok it form spending 5 minutes on the topic Mar 18 12:17:24 what is meson, what is ninja, why does it require changes to cmake? Mar 18 12:17:46 is it something like automake for hipsters? Mar 18 12:18:45 😂 Mar 18 12:20:03 so it /seems/ that meson is some kind of high level generator language which produces low level ninja which in turn wants to be a gnu make replacement Mar 18 12:20:20 and that generator language only happens to be implemented by some python processor Mar 18 12:20:34 while it can theoretically implemented by other things like C or Perl Mar 18 12:21:30 the one question I'd still ahve for al lthis: why? Mar 18 12:21:52 ninja was allegedly invented because make is slow Mar 18 12:22:24 but ninja syntax is human unfriednly, hence meson was invented to produce ninja (nad implement some ellegedly simple, zero-effort dependency tracking strategies etc.) Mar 18 12:22:40 well, cmake could output ninja as well Mar 18 12:22:56 yeah but nih, so we have to support ninja, cmake *and* meson now Mar 18 12:24:02 I have no desire to works with this stack. I'm burnt for life after spending a year fixing libtool / autoconf / automake fallout Mar 18 12:24:12 :) Mar 18 12:24:19 "haveto"? Mar 18 12:24:25 I fully expect this stack to fail in similar, completely new ways Mar 18 12:24:58 these build systems are all beautiful when you comply want to mangle a bunch of *.c files through CC + CFLAGS Mar 18 12:25:03 *simply Mar 18 12:25:20 maybe we could skip that meson part and use somehow pregenerated {ninja,make}files ? Mar 18 12:26:05 do the newer routers where wifi is integrated into the CPU die also have their flash memory integrated? Mar 18 12:27:28 charolastra: no, iirc the flash chips are usually separate Mar 18 12:29:26 ynezz: not sure this would work. The meson scripts in the wild will probably use host information to produce different ninja files like configure produces makefiles Mar 18 12:30:01 so you probably have to run the meson "script" whenever config flags or other build details change Mar 18 12:30:43 hm, correct Mar 18 12:31:08 anyway it seems like NIC.CZ might upstream the support for ninja/meson https://github.com/openwrt/packages/issues/8315 (last comment) Mar 18 12:33:07 I think buildroot should be moved from python 2.7 build prereq to python 3 Mar 18 12:33:20 then we can add a meson.mk Mar 18 12:33:33 which does whetever magic stuff is needed Mar 18 12:35:41 and to read out the flash content one would have to unsolder the chip or is it accessible through JTAG or patching into the traces? Mar 18 12:41:18 Guys I have a odd question, how can I make a blob? I'm making a driver but a part of it is a library fro BSP and I cannot release it... so I have to create a blob :( Mar 18 12:41:49 hitech95: just treat it as static file which you copy into your package Mar 18 12:42:09 e.g. ship it as package/myblobdriver/files/firmware.blob Mar 18 12:42:23 or make your package download the blob data from somewhere Mar 18 12:42:42 jow: just to see how it goes, I'm going to build test few targets with Python 3, is this change enough https://github.com/ynezz/openwrt/commit/91011688876c934429f9e3bc9670eeb8f94d69c5 ? Mar 18 12:43:36 jow, thanks for the quick reply. Not a huge expert of C. I have to extern a fiew functions from that blob. (it is a bunch of c files.) Mar 18 12:44:36 I need them at compile time to make the kernel module work. Not sure if there is a better way! Mar 18 12:45:49 ynezz: right, that plus maybe rgrep'ing for python2 in scripts/ and package/ Mar 18 12:46:27 iirc some effort was spent a few years back to make the stuff in scripts/ forward compatible with python 3 but maybe some new firmware image tool scripts crept back in or so Mar 18 12:47:35 tools/scons/files/pywrap.sh seems to rely on Python2, but I can't find any package in core using scons Mar 18 12:48:16 ntpd from the package feed requires scons iirc Mar 18 12:49:59 makes me wonder why it's in core and not in packages repo Mar 18 12:50:29 you mean the scons support? Mar 18 12:50:32 yeah Mar 18 12:50:56 the policy / desire / decision was that buildroot should support build systems natively Mar 18 12:51:05 ok then Mar 18 12:51:09 so that the SDK can provide build support ootb Mar 18 12:52:56 "Versions 3.0 and above are not supported at this time" from https://bitbucket.org/scons/scons/wiki/FrequentlyAskedQuestions#markdown-header-what-version-of-python-do-i-need Mar 18 12:53:24 yay! Mar 18 12:53:31 so we would probably need both pythons in order to support scons and meson Mar 18 12:53:55 newfangled crap Mar 18 12:54:26 I'm no openwrt core developer.. but.. no.. no.. NO... Mar 18 13:24:11 Does you guys know a simple SPI slave device driver that i can use to start making my own? Mar 18 13:28:18 cd linux.git; git grep spi_probe ? Mar 18 13:30:29 ynezz, Yup but I was looking for a dummy or something to start with... Mar 18 13:32:16 Well i'm using the max310x.... Mar 18 13:32:53 well just take a look at number of source code lines in those files Mar 18 13:33:24 1489 drivers/tty/serial/max310x.c Vs 79 drivers/staging/iio/adc/ad7606_spi.c Mar 18 13:34:32 ynezz, ha ha ha, unfortunatly I know that max chip. I have emulated it on a uC :( Mar 18 14:00:36 What is the purpose of the spi_device_id struct? I have never seen that before! Mar 18 14:46:36 Dummy question, this is commented due to the fact that there is no clock souce for thoose socs? https://github.com/openwrt/openwrt/blob/34e22653ac18b6ac7fd368ca47625f665808067f/target/linux/brcm63xx/dts/bcm6358.dtsi#L201 Mar 18 15:32:14 Is there a "reference implementation" of DSA that, for example, runs in an x86 VM? Trying to figure out if it's my config, or my device that isn't behaving as I would expect Mar 18 15:34:43 From the off-gurd: what is DSA that keeps popping up occasionally? :P Mar 18 15:37:23 Distributed Switch Architecture -- "upstream's" choice of how to handle a class of Ethernet interfaces and phys, including things like switch chips in consumer routers Mar 18 15:37:44 https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt Mar 18 15:38:01 https://netdevconf.org/2.1/papers/distributed-switch-architecture.pdf Mar 18 15:38:52 "There are a number of other of solutions, none of which should get anywhere near mainline" Mar 18 15:39:33 "Vendor specific and proprietary switch SDKs run in userspace, with a small kernel driver to export register access." Mar 18 15:40:10 So, at least as I understand it, mowing away from `swconfig` and toward a more "acceptable" approach. Mar 18 15:41:15 ah, that explains alot :thaks Mar 18 15:41:27 I have seen the term occasionally, mainly here and mailinglist, but for any reason whole term has eluded me :D Mar 18 15:41:30 until now Mar 18 15:41:50 "Exhaustively well documented", of cource ;) Mar 18 15:42:34 olmari: the idea is also that switch ports become actual netdevs, so that you can bridge them, put vlan tags on top etc. Mar 18 15:43:17 so its transparent to the normal network userland utils and there's no need anymore for a separate hardware config through eg. swconfig or other proprietary means Mar 18 15:43:45 so far for the theory. In practise its harder ofc Mar 18 15:44:21 mm, I see.. both the idea and it bveing hard.. Mar 18 15:44:43 does they still generally behave as fast as "current" method? as in hardware L2 etc Mar 18 15:44:59 bugs aside, I wouldn't want it's perforance to woe Mar 18 15:45:32 it is supposed to be fast yes. So if you bridge two ports in software, the hardware backplane is implicitely reconfigured to bridge them in hardware Mar 18 15:46:08 in practise there do seem to be performance regressions though, I once heard it has something to do with the fact that dsa does not support multiple cpu connections yet but I might be wrong or misinfomred Mar 18 15:46:54 jow: hey, you got an advice how to run a javascript snipped just after logging in? spoiler: it's to search for firmware upgrades checking Mar 18 15:47:11 jow: I don't know it affects the performance but DSA supported only 1 cpu port. Mar 18 15:47:54 I'm working on an IPQ4019 device with commits from staging trees; and there is some complexity in dealing with the "tagging" of the packet for the phy on transmit Mar 18 15:48:00 mm well.. like said, there ought to be bugs, regressions and whatnot.. but in perfect world DSA shouldn't be permanent performance degrader, but this is purely opinion and not even very educated on the issue Mar 18 15:48:04 openwrt has a patch on the mediatek platform to support 2nd cpu port Mar 18 15:48:55 aparcar[m]: there is no real post-login hook where you could put that. Maybe hack the js into the generic header template and make it use a cookie or local storage to not run it once dismissed/checked by the user Mar 18 15:50:14 jow could you please elaborate on the "hack into generic header"? Mar 18 15:50:23 so DSA ought to be sofwtare only thing+ magics then would map the hardware in hardware, should there be real hardware supporting that (ie most embeddeds in this context) Mar 18 15:50:40 ..crap the text I'm producing... just read what I meant ;P Mar 18 15:50:50 aparcar[m]: edit /usr/lib/lua/luci/view/header.htm Mar 18 15:51:16 thank you! Mar 18 15:55:16 olmari: That seems to be the goal -- config a VLAN, config the ports with VLANs and/or PVID, config a bridge, the kernel and drivers "auto-magically" optimize without the end user needing to kknow the underlying architecture Mar 18 15:55:50 How to read a value by key from DTS as string? Mar 18 15:56:17 Runtime? C or sh? Mar 18 15:56:42 jeffsf, kernel module side. Or better, is there a way to define a enum for dts parameters? Mar 18 15:57:01 jeffsf: Then I kinda wholeheartedly agree on DSA being good goal :) Mar 18 15:57:35 hitech95: Can't comment on "enum" -- haven't read of anything like that Mar 18 15:58:23 I'm Implementing the SIP side on brcm 63XX Doh... and the SLIC chip accept different modes... IFIK switch in C doesn't support string compare Mar 18 15:58:55 https://elinux.org/Device_Tree_Linux#phandle_access_in_kernel_.28by_drivers.29 Mar 18 16:00:57 jow: btw the THANKYOU file is somewhat outdated, should it be replaced by something like `git log --pretty=%an | sort | uniq -c | sort -n -r`? Mar 18 16:01:41 or dropped entirely Mar 18 16:07:06 jow: https://github.com/openwrt/luci/pull/2630 Mar 18 16:07:24 thanks Mar 18 16:08:06 you're welcome Mar 18 16:24:42 AFIK the linux kernel doesn't has SLIC related stuff. Siif I have a PCM SLIC driver i dont have to register as a ASOC right? Mar 18 17:06:35 Is there any "functional" difference in an init script between boot(), start(), and start_service() for a one-shot script? Mar 18 17:07:14 on boot, no Mar 18 17:07:37 on /e/i/whatever start, only start() but not boot() is invoked Mar 18 17:08:18 Am I right in assuming that *_service() is intended for procd-supervised tasks? Mar 18 17:08:28 yep, correct Mar 18 17:08:35 thanks Mar 18 17:08:47 if you neither use supervision nor triggers, then best is to not USE_PROCD=1 Mar 18 17:09:14 and to simply rely on start() [or boot() if you do not intend to to be startable later] Mar 18 17:09:25 Right now I'll be happy to get the DSA configured *once* and worry about reconfiguring it latyer! Mar 18 17:18:07 Guys what are mutex? O.o Mar 18 17:19:10 Real question, or some bizarre use of one? Mar 18 17:19:34 jeffsf, real question. I'm tring to understand if I have to use them or not Mar 18 17:19:53 MUTually EXclusive (lock) Mar 18 17:20:19 Used to prevent two processes or threads from accessing the same "thing" at the same time Mar 18 17:20:56 jeffsf, Uhm... Ok. Now I have to think if I need them for read and write the SPI device.... Mar 18 17:21:41 As I recall, SPI sends an address, then a command Mar 18 17:22:08 so if another thread started writing or reading in the middle of your transaction, "that would be bad" Mar 18 17:22:15 jeffsf, Yup, but in this case cmmands are for VOIP so.... Mar 18 17:22:42 IDK, i'm looking at the BSP from a vendor and they dont use the mutex, another is using it. Mar 18 17:23:18 If there's only a single device there, and you know "your" thread is the only user, then probably don't need a mutex Mar 18 17:23:30 jeffsf, nop up to 8 devices Mar 18 17:23:43 so I think that the mutex is mandatory Mar 18 17:25:04 I still don't understand why vendors don't make drivers with a common sense... Mar 18 17:25:23 because they lack common sense, most likely :) Mar 18 17:25:41 or rather refuse to pay money to hire people having it Mar 18 17:25:49 My vote with #2 Mar 18 17:26:13 Much easier to copy somebody else's code blindly Mar 18 17:26:18 "It worked for me" Mar 18 17:26:28 jow, They have really huge problems. I'm looking at some broadcom source. They make no sense, they have created their own apis and call instead of using the one from linux with lots of wrappers. Mar 18 17:27:39 Broadcom has little, if any, financial incentive to make their SoCs "Linux friendly" Mar 18 17:28:03 I have a real dumb question: how the hell the brcm63xx-spi know the CS of a device? Mar 18 17:28:29 I only know broadcom code from their wl driver Mar 18 17:28:30 The engineer that drew the schematic Mar 18 17:28:47 and it felt like the proprietary nvidia driver for grafic. entirely custom stack Mar 18 17:28:49 jeffsf, yup! Looks like that they got worse year after year Mar 18 17:29:16 own supplicant, own wext api using private ioctls and iovars Mar 18 17:29:21 jow, no idea of the nvidia driver. :D Mar 18 17:29:32 It's either hard-coded in the driver, buried in a mach file, or in the DTS/DTB Mar 18 17:29:33 no cfg80211, mac80211 or even wext Mar 18 17:30:08 I think this is mainly due to the fact that the core code predates Linux or is shared among many targets, so they do not bother to adhere to each OS'ses APIs Mar 18 17:30:30 only enough to make it run, even if the code is redundant Mar 18 17:31:07 jow, I would show you the mess but the code has been "taken" from "somewhere" and now is on github and is not opensource licensed so.... I don't know if I can post it here... Mar 18 17:31:18 better not :) Mar 18 17:32:16 jow, yea... i know. I'm rewriting it ... to a more linux fiendly way but lots of custom libraries from Microsemi and SiLabs unfortunatly... Mar 18 17:33:38 would be cool to have thoose libraries available as blobs ... Mar 18 17:34:31 Not really in grand scheme of things... while I hear your pain Mar 18 17:35:11 Too many "blobs" dealing with Android phones. The kernel clicks ahead and the world implodes Mar 18 17:38:04 jeffsf, never worked on kernel side of Android. Only Apps... Mar 18 17:38:41 Samsung makes Broadcom look like an angel, by comparison Mar 18 17:38:53 Is't only me or i cannot find the dahdi-linux documentation? Mar 18 17:39:30 Oh, really? I remember that they released all the drivers ... back then... I had a S2... Mar 18 17:40:20 Also some Exynos dev board we have at university have the mainline kernel Mar 18 18:05:10 ynezz: https://github.com/tmn505/openwrt/tree/epg5k, sorry for the delay, got distracted by RL. Mar 18 18:08:37 nbd: ping Mar 18 18:08:57 nbd: i'm checking imx6 on kernel 4.19. (which uses a DWC pcie controller) Mar 18 18:09:34 it seems that a dwc host these days seem to depend on MSI, which ath9k doesnt support .. Mar 18 18:10:01 disabling it using bootarg "pci=nomsi" doesnt work as ath9k still provides error on missing IRQ's Mar 18 18:10:12 do you have any knowledge how to proceed here? Mar 18 18:11:29 I notice some upstream patches trying to add support for it .. but most hardware zero out the lower 2 bits of the msg ID, so they are not picked up by MSI logic Mar 18 18:14:19 I'm also a bit sceptical towards performance of MSI interrupts vs legacy hardware interrupts regarding performance/latency .. but benchmarking will reveal that .. Mar 18 18:38:49 `bridge vlan add dev br-lan vid 1010` RTNETLINK answers: Not supported -- (ath8k) is there a config param I'm missing somewhere? Mar 18 18:42:24 (same "Not supported" adding to phy w/ "self") Mar 18 18:44:47 s/ath8k/qca8k/ Mar 18 18:48:30 OK, `fgrep -r port_vlan files-4.19/drivers/net/dsa` returns nothing, so apparently "Not supported" at this time Mar 18 19:25:56 Dummy question: calloc vs devm_kzalloc, can make some problems? Mar 18 20:21:06 tmn505: no problem, thanks for taking care of this - I would prefer to rather stay conservative and do not touch current ar71xx/lantiq LED migration code until 19.03 branch is made, so I would just use new the new /lib/functions/migrations.sh for ath79 migrations (and test it), and we can switch ar71xx/lantiq to this new shared file later, after 19.03 branch Mar 18 20:22:44 tmn505: sorry for the confusion, I've added ar71xx/lantiq as an example, that we really should avoid this code copy&paste duplication and rather continue sharing common code across platforms, like with diag.sh for example Mar 18 20:41:01 looking through the recent git log, i see a lot of code fixups specific to ar71xx Mar 18 20:43:35 Continuum to that would be: "One are supposed to mat all future fixes for ath79, which is same platforms but woth DTS, and ar71xx is going to be deprecated Mar 18 20:43:39 +" Mar 18 20:47:27 jow: https://github.com/SCons/scons/issues/3299 for Python 3 support. Apparently 2 of the three issues have been fixed. Mar 19 02:54:05 WOW. did not know the archer c7 v3 is an improved version Mar 19 02:57:17 the minipcie card is even bigger and has all of the antenna connectors on it **** ENDING LOGGING AT Tue Mar 19 02:59:57 2019