**** BEGIN LOGGING AT Tue Dec 18 03:00:00 2018
Dec 18 04:07:03 <gch981213> mamarley: Thanks a lot.
Dec 18 04:18:54 <owrt-snap-builds> build #687 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/687
Dec 18 06:15:58 <jow> morning
Dec 18 07:08:42 <owrt-snap-builds> build #239 of gemini/generic is complete: Failure [failed images]  Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/239  blamelist: Sebastian Kemper <sebastian_ml@gmx.net>, Hans Dedecker <dedeckeh@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Mathias Kresin <dev@kresin.me>, Syrone Wong
Dec 18 07:08:42 <owrt-snap-builds> <wong.syrone@gmail.com>
Dec 18 07:22:38 <owrt-snap-builds> build #1132 of ipq806x/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/1132
Dec 18 08:15:37 <jow> is there any reason to not cherry-pick "ath10k-ct: Update driver to latest" into openwrt-18.06 ?
Dec 18 08:15:49 <jow> (18.06 still uses the non-ct ath10k by default)
Dec 18 08:21:38 <wigyori> morning
Dec 18 08:28:16 <jow> morning wigyori
Dec 18 08:28:17 <jow> ping stintel
Dec 18 08:31:05 <ldir> mornin'
Dec 18 08:31:45 <jow> any rpi users here?
Dec 18 08:32:51 <ldir> not I
Dec 18 08:37:15 <Ycarus> I but a custom 4.14 build ;)
Dec 18 08:47:39 <thagabe> Is 4.19 ready for testing?
Dec 18 08:51:56 <stintel> jow: yes
Dec 18 08:53:06 <stintel> Ycarus: build from my staging tree or something else
Dec 18 08:53:10 <stintel> built*
Dec 18 08:53:24 <jow> stintel: is there any reason to not backport "brcm2708: Update brcm2708-gpu-fw package" ?
Dec 18 08:54:15 <stintel> jow: since master is still on 4.9 and has the newer firmware, and I haven't noticed any problems, I don't think there is
Dec 18 08:54:17 <Ycarus> stintel, build from my staging tree. Where is your staging tree ?
Dec 18 08:54:57 <jow> stintel: thanks, will pick it then
Dec 18 08:57:26 <stintel> Ycarus: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14
Dec 18 08:59:15 <Ycarus> seems to be as dirty as mine :)
Dec 18 08:59:32 <ldir> xback: ping
Dec 18 09:00:03 <stintel> Ycarus: what rpi hardware do you have ?
Dec 18 09:00:41 <Ycarus> RPI 3B+, RPI3, RPI2,...
Dec 18 09:03:09 <stintel> Ycarus: ok. I have a problem with 4.14 on zero w: http://lists.infradead.org/pipermail/openwrt-devel/2018-December/015127.html
Dec 18 09:03:30 <stintel> this is stopping me from pushing what's in my staging tree to master
Dec 18 09:03:48 <stintel> I don't have this problem on rpi3b+
Dec 18 09:03:56 <Ycarus> It's the only RPI that I don't have
Dec 18 09:04:19 <stintel> Ycarus: do you have an rpi1 ?
Dec 18 09:04:42 <stintel> would be interesting to know if it can be reproduced on 1 or 2
Dec 18 09:04:53 <Ycarus> Yes I have one
Dec 18 09:05:04 <xback> stintel: thanks for testing 4.9!
Dec 18 09:05:06 <xback> ldir: pong
Dec 18 09:05:08 <stintel> xback: welcome
Dec 18 09:06:07 <ldir> xback: fyi  dedeckeh did a kernel backport commit yesterday that collides with your bump - it's the 096-* patch
Dec 18 09:06:29 <stintel> the thing is I'm travelling the end of the week, and will be gone until after new year. it would be nice if I can push my work to master so that we will have brcm2708 on 4.14 before branching
Dec 18 09:07:05 <stintel> if only zero w has this problem I would go ahead and push things, figure out that problem later
Dec 18 09:07:20 <Ycarus> This would be great. You want me to test first on RPI 1 or 2 ?
Dec 18 09:07:44 <xback> ldir: thanks for letting me know
Dec 18 09:08:54 <stintel> Ycarus: order doesn't matter to me, but I would be interested in knowing what happens on both
Dec 18 09:09:17 <stintel> Ycarus: enable enough modules to be able to hit the problem
Dec 18 09:09:41 <Ycarus> ok
Dec 18 09:09:45 <stintel> thanks!
Dec 18 09:09:49 <xback> stintel: i'll take a look at the code regarding the issue.  not implying that I can fix it .. but maybe i'm lucky :)
Dec 18 09:10:27 <jow> nbd: any reason to not pick "ramips: improve ethernet driver performance with GRO/TSO" ?
Dec 18 09:12:16 <stintel> xback: I can give you output of /proc/vmallocinfo in both situations
Dec 18 09:12:27 <xback> please do (e-mail)
Dec 18 09:12:28 <stintel> but I'd have to do another build first
Dec 18 09:12:42 <stintel> we don't have that enabled by default
Dec 18 09:12:52 <xback> also a full dmesg would be appreciated in both situations
Dec 18 09:13:00 <stintel> xback: I'll get to it
Dec 18 09:21:16 <stintel> damn, after rebasing some patches no longer apply
Dec 18 09:21:41 <stintel>     kernel: preserve oif of IPv6 link scope packets
Dec 18 09:21:47 <xback> sec
Dec 18 09:22:01 <xback> ill push a patch to staging now (3 way merge)
Dec 18 09:22:19 <xback> done
Dec 18 09:22:27 <stintel> xback: well the 3way merge happened here without issues but still patches don't apply
Dec 18 09:22:31 <stintel> I'll try yours
Dec 18 09:22:59 <xback> in the meantime.  I'm refreshing kernels using todays master state currently
Dec 18 09:23:04 <xback> eta 20 mins
Dec 18 09:23:28 <stintel> xback: I'll just drop the latest bumps from my brcm2708-4_14 branch
Dec 18 09:23:44 <xback> also fine. there's nothing really critical in the latest
Dec 18 09:24:11 <stintel> I'll do dmesg and /proc/vmallocinfo from 4.9 w/ and w/o HDMI attached, and the same on 4.14
Dec 18 09:24:16 <stintel> any other info worth capturing ?
Dec 18 09:24:31 * xback thinks .
Dec 18 09:24:42 <ldir> the 096-* backport introduced by 3f7de917be is already in 4.14.89 -  so the patch can be dropped (reverse applies)
Dec 18 09:24:51 <xback> lspci -v would be nice also
Dec 18 09:25:14 <xback> ldir: thanks. this means i should see it popping up during refresh
Dec 18 09:25:34 <xback> have to refresh anyway to avoid fuzz :)
Dec 18 09:26:11 <stintel> xback: I don't think the target has a PCI bus
Dec 18 09:27:20 <xback> stintel: ok then. (pci stuff tends to malloc a lot for the ranges, hence the question :)  )
Dec 18 09:28:01 <stintel> xback: maybe also meminfo and vmstat ?
Dec 18 09:28:17 <stintel> and iomem
Dec 18 09:28:38 <xback> stintel: no
Dec 18 09:28:55 <stintel> ok so just dmesg and vmallocinfo
Dec 18 09:29:24 <xback> yes please
Dec 18 09:42:20 <xback> ldir: ack on 096* being present in kernel 4.14.89
Dec 18 09:46:11 <ynezz> hm, I'm wondering what is preferred `DEPENDS:=+LINUX_4_14:kmod-hwmon-core +LINUX_4_19:kmod-hwmon-core` or `DEPENDS:=+!(LINUX_3_18||LINUX_4_9):kmod-hwmon-core` ?
Dec 18 09:46:34 <ldir> xback: I suspect the same for 4.19 & 4.9....but I haven't checked.
Dec 18 09:47:08 <ynezz> from my point of view the latter could break some builds which could be using kernel versions < 4.14
Dec 18 09:48:16 <ynezz> hm, nm, it won't break builds, just add dependency
Dec 18 09:48:27 <ynezz> it doesn't hurt
Dec 18 09:51:16 <jow> blogic: is "kernel: add a RPS balancer" eligible for backporting?
Dec 18 09:52:28 <stintel> jow: that was reverted, no ?
Dec 18 09:53:39 <stintel> yeah - b134b3299c99f468a1c0055580dad1aa71b6b63c
Dec 18 09:54:39 <ldir> xback: 4.19 already has the backport, looks like 4.9 doesn't...and it's not in stable-queue either yet.
Dec 18 09:55:37 <xback> ldir: ack on that.  4.9 refresh didnt encounter it
Dec 18 09:56:13 <xback> i'll hold off on bumping 4.19 for now as many patches are queued for it.  Otherwise people would need to rebase continuously ..
Dec 18 09:57:45 <jow> stintel: ah, would've noticed it
Dec 18 09:57:54 <jow> stintel: slowly working through the list atm
Dec 18 09:58:36 <stintel> jow: I vaguely recalled reverting it due to the issue in the revert commit message
Dec 18 09:59:08 <ldir> jow: thanks for your assistance with Tony's iproute et al PRs... I'm well outside my comfort zone on those!
Dec 18 10:00:56 <dedeckeh> xback:it would surprise me that the 096 patch would go in 4.9 as it would require a partial rewrite of the patch
Dec 18 10:03:45 <jow> ldir: "kernel: re-enable MIPS VDSO" should be safe on 18.06 with recent 4.14 I suppose?
Dec 18 10:05:14 <ldir> jow: yes agree.  No one appears to be screaming at the moment in master about it and I'm sure we'd have heard by now.
Dec 18 10:05:41 <ldir> jow: btw good job you fixed the double mailing list email problem ;-)
Dec 18 10:07:11 <ldir> jow: 91a71804f89a238082904ae027fffb52114e3499 is the equivalent for 4.9
Dec 18 10:31:49 <stintel> xback: typical.. now I have build breakage, waiting for make -j1 to show me what's breaking :/
Dec 18 10:33:40 <ynezz> FYI, I've started adding some repeating DTS issues to DTS checklist at https://openwrt.org/submitting-patches#dts_checklist
Dec 18 10:39:27 <stintel> ../depcomp: line 511: exec: g++-uc: not found
Dec 18 10:40:05 <stintel> I get this on iperf (2)
Dec 18 10:41:46 <stintel> just going to disable this now, all this random breakage is really time consuming :(
Dec 18 10:43:38 <karlp> stintel: I find it "faster" to have build logs enabled and just "ack '\*\*\*' logs" to find what went wrong,
Dec 18 10:44:04 <stintel> karlp: probably, I never got used to enabling build logs
Dec 18 10:44:10 <stintel> maybe it's time to do so
Dec 18 10:45:03 <ldir> karlp: just what???
Dec 18 10:45:28 <ynezz> ack = grep
Dec 18 10:47:30 <ynezz> s/grep/grep on stereoids/
Dec 18 10:49:09 <ldir> https://beyondgrep.com   oh!
Dec 18 10:50:59 * ldir runs brew install ack
Dec 18 10:53:11 <karlp> ldir: grep -r '\*\*\*' logs would probalby work too :)  sprinkle a "-C 10" or somehting in for context...
Dec 18 10:54:51 <ldir> as a sound engineer for $dayjob I just like the idea of 'stereoids' :-)
Dec 18 11:12:34 <stintel> so apparently option flow_offloading 1 still crashes my APU2 :(
Dec 18 11:16:30 <stintel> xback: https://www.linux-ipv6.be/OpenWrt/RPi/ - do you prefer I send them to you by mail as well ?
Dec 18 11:16:51 <Ycarus> stintel, Seems to have no problem on RPI1
Dec 18 11:17:25 <Ycarus> (about kernel 4.14 from your branch)
Dec 18 11:19:50 <Hauke> jow: yes we can activate VDSO in 18.06 this was fixed upstream and backported
Dec 18 11:20:05 <stintel> Ycarus: ok, just to check, do you have kmod-video-bcm2835 and kmod-drm-vc4 enabled ?
Dec 18 11:20:11 <Ycarus> yes
Dec 18 11:21:17 <Hauke> I think we should add this to mac80211 in 18.06: https://git.kernel.org/linus/a9911937e7d332761e8c4fcbc7ba0426bdc3956f
Dec 18 11:21:32 <Hauke> it is in master now
Dec 18 11:21:33 <stintel> Ycarus: ok. that device doesn't have wifi, right?
Dec 18 11:21:43 <Hauke> jow: I will create a patch for that
Dec 18 11:22:11 <Ycarus> stintel, if I remember well no wifi
Dec 18 11:22:47 <jow> Hauke: I already picked the relevant commits
Dec 18 11:23:09 <jow> currently fighting repo corruption on git-02
Dec 18 11:23:15 <Hauke> ok
Dec 18 11:26:57 <stintel> xback: it seems that the problem is related to multiple failed modprobe attempts (jitterentropy_rng)
Dec 18 11:27:22 <stintel> still doesn't explain why I don't have it with HDMI plugged in though
Dec 18 11:30:16 <stintel> Ycarus: on your rpi1, do you get this in `dmesg`: Tue Dec 18 11:30:05 2018 kern.info kernel: [  320.786333] jitterentropy: Initialization failed with host not compliant with requirements: 2
Dec 18 11:30:27 <xback> stintel: yes. please also mail them
Dec 18 11:31:18 <stintel> xback: done
Dec 18 11:31:59 <xback> stintel: thanks :) i'll take a look during today
Dec 18 11:32:00 <Ycarus> stintel, no
Dec 18 11:32:11 <stintel> why do we try to load jitterentropy_rng 229 times ?!
Dec 18 11:32:32 <stintel> this seems to use up some vmalloc memory that is never freed (iiuc)
Dec 18 11:32:47 <jow> stintel: my guess would be uevents
Dec 18 11:32:51 <stintel> Ycarus: and is jitterentropy_rng loaded ?
Dec 18 11:33:46 <Ycarus> no
Dec 18 11:34:07 <stintel> Ycarus: do you have kmod-crypto-rng ?
Dec 18 11:34:37 <Ycarus> no ;)
Dec 18 11:34:45 <stintel> ah, can you include it and see what happens ?
Dec 18 11:34:49 <Ycarus> ok
Dec 18 11:35:34 <stintel> if rpi1 floods that message as well, I would exclude that module from the kmod-crypto-rng package on brcm2708/bcm2708
Dec 18 11:37:39 <stintel> and rebase the rpi-4.14.y tree on 4.14.89, update brcm2708/patches-4.14 based on that, and finally push it to master
Dec 18 11:37:53 <stintel> so that we can have this target supported in 19.01 ;-)
Dec 18 11:38:45 <Ycarus> I have the message "jitterentropy: Initialization failed with host not compliant with requirements: 2" multiples times
Dec 18 11:38:58 <stintel> and I can go into holiday mode without having to worry about it anymore :)
Dec 18 11:39:10 <stintel> Ycarus: thanks for testing. do you mind trying the same on rpi2 ?
Dec 18 11:39:20 <Ycarus> ok
Dec 18 11:39:53 <stintel> just to know, I will not exclude it on that target because it can also be used on rpi3 and that does not have the "not compliant with requirements" problem afaik
Dec 18 12:02:08 <Ycarus> stintel, no errors on a RPI2
Dec 18 12:02:14 <stintel> Ycarus: good
Dec 18 12:02:14 <xback> fyi, new kernel bumps for master pushed to my staging
Dec 18 12:02:26 <stintel> Ycarus: thanks for testing
Dec 18 12:02:57 <Ycarus> no pb, I will no have to keep my dirty RPI 4.14 branch then :)
Dec 18 12:03:36 <stintel> Ycarus: I hope to push brcm2708/4.14 to master tonight
Dec 18 12:04:30 <Ycarus> Cool :)
Dec 18 12:04:59 <xback> sintel: I'm aiming to push new kernel this afternoon to master
Dec 18 12:05:06 <xback> stintel: can you rebase on that?
Dec 18 12:05:35 <stintel> xback: I will - rpi-4.14.y has merged 4.14.89
Dec 18 12:07:48 <stintel> dedeckeh: ping
Dec 18 12:15:08 <dedeckeh> stintel:pong
Dec 18 12:16:56 <stintel> dedeckeh: is it possible to override what odhcpd sends in an RA? I would like to force it to send fe80::1 as next-hop
Dec 18 12:17:40 <stintel> (this is a floating IP that is activated when one of my routers keepalived switches to active state)
Dec 18 12:18:21 <stintel> I just had some weird IPv6 issues, caused by having a multipath default route with fe80::1 fe80::20d:b9ff:fe40:820c fe80::618:d6ff:fe83:8b77 as nexthops
Dec 18 12:19:12 <stintel> that was a side-effect of the APU2 rebooting due to a crash when enabling flow_offloading
Dec 18 12:19:52 <dedeckeh> stintel:next hop is not an attribute in a RA message
Dec 18 12:20:08 <stintel> ah, so it just takes the source IP ?
Dec 18 12:20:35 <dedeckeh> stintel:yes based on the fact router lifetime being set
Dec 18 12:20:43 <dedeckeh> in the RA message
Dec 18 12:21:10 <stintel> hmmm, can odhcpd be configured to only send RA from $IP ?
Dec 18 12:23:42 <dedeckeh> no as sending RAs is based on setting ra as server on a logical interface
Dec 18 12:24:14 <stintel> :/
Dec 18 12:24:22 <xback> jow: ping
Dec 18 12:24:47 <stintel> it's weird though, I didn't use to have this problem
Dec 18 12:24:48 <xback> jow: It seems you are still raging on with 18.06.  should I hold off a bit pushing the 18.06 kernel bumps?
Dec 18 12:25:04 <dedeckeh> stintel:how did you end up with these multipath default routes ?
Dec 18 12:25:32 <jow> xback: no, feel free to do your bumps
Dec 18 12:25:43 <jow> xback: I'll focus on userspace fixes in the meanwhile
Dec 18 12:25:44 <stintel> dedeckeh: they had "proto ra"
Dec 18 12:25:53 <xback> jow: noted. thanks
Dec 18 12:26:27 <jow> I somehow managed to completely shred my staging repo
Dec 18 12:26:34 <stintel> dedeckeh: I suspect an RA was sent before the fe80::1 IP was assigned to the lan interface
Dec 18 12:26:38 <jow> missing objects, unreachable packs, invalid refs
Dec 18 12:26:52 <jow> and googling for that revealed far more git internals than I ever wanted to know about
Dec 18 12:27:00 <stintel> dedeckeh: if I could somehow convince odhcpd to only send RA's from IP fe80::1 then that would never be a problem
Dec 18 12:27:13 <jow> ended up just nuking the remote completely and re-pushed my local branches
Dec 18 12:27:30 <stintel> but I guess I should add a sleep before starting odhcpd when keepalived state becomes active
Dec 18 12:27:32 <jow> I hope this was a one-off occurance
Dec 18 12:28:17 <dedeckeh> sintel:so you have multiple link local addresses on an interface ?
Dec 18 12:28:34 <jow> stintel: what about ip6tables SNAT :>
Dec 18 12:28:48 <dedeckeh> brrrr ...........
Dec 18 12:28:55 <jow> or is odhcpd using raw sockets?
Dec 18 12:29:09 <stintel> dedeckeh: yes. fe80::20d:b9ff:fe40:820c/64 (auto based on MAC) and fe80::1 on the active router in my HA Setup
Dec 18 12:29:24 <stintel> jow: :D
Dec 18 12:30:29 <jow> ip6tables -t nat -A OUTPUT ! -s fe80::1 -p icmpv6 --icmpv6-type router-advertisement -j SNAT --to-source fe80::1
Dec 18 12:32:10 <dedeckeh> stintel:odhcpd leaves the selection of the src ip to kernel atm; I could extend this to allow to specify a source IP
Dec 18 12:33:36 <stintel> dedeckeh: I suppose this shouldn't be too hard - I could have a go at it myself
Dec 18 12:35:03 <dedeckeh> stintel:indeed shouldn't be too hard; patch very much welcome
Dec 18 12:36:57 <stintel> dedeckeh: I'll ping you when I have something for review ;-)
Dec 18 12:38:14 <dedeckeh> stintel:fine
Dec 18 12:49:39 <Hauke> jow:  these are a lot of changes to 18.06
Dec 18 12:52:42 <greearb> jow, you have a link to the forum where someone was complaining about new ct 9980 crash?
Dec 18 12:56:12 <jow> greearb: https://forum.openwrt.org/t/why-the-switch-to-unstable-ath10k-ct/27258/3
Dec 18 12:56:31 <jow> Hauke: yes, and I'm only 20% or so through my list
Dec 18 12:56:52 <hexa-> are those backports from master? I was just wondering as well
Dec 18 12:58:05 <jow> hexa-: yes, as noted in each commit message
Dec 18 12:58:12 <hexa-> ah sorry
Dec 18 13:01:36 <KanjiMonster> stintel: the jitterentropy error means that two subsequent calls for kernel time returned the same time (delta is 0), which I guess means no hr timer seems to be available - maybe just a kernel configuration issue?
Dec 18 13:25:53 <xback> kernel bumps pushed to master
Dec 18 13:26:24 <jow> I'm a bit unsure what to do with mac80211 / ath10k-ct / firmware backports
Dec 18 13:26:48 <jow> iirc the firmware stuff was tightly coupled to the ath10k versions in use, so I likely shouldn't pick one without the other
Dec 18 13:27:00 <jow> and I only have one qca9880 test device around here
Dec 18 13:29:44 <stintel> jow: just in case, if you decide to bump mac80211 to the 4.19 snapshot we're using now, please also pick f208f778117d4bdf99da600f281728ce5b61ed3c
Dec 18 13:30:33 <stintel> although that might be a bit too much for a minor release
Dec 18 13:32:20 <jow> I am also not sure about "ramips: improve ethernet driver performance with GRO/TSO"
Dec 18 13:32:28 <jow> it looks like something that should be backported
Dec 18 13:37:11 <KanjiMonster> jow: there is an open bug for it: https://bugs.openwrt.org/index.php?do=details&task_id=1618
Dec 18 13:38:16 <jow> KanjiMonster: looks like we should rather revert it in master, then
Dec 18 13:47:08 <stintel> xback: Linux OpenWrt 4.9.146 #0 Tue Dec 18 12:28:23 2018 armv6l GNU/Linux
Dec 18 13:48:47 <greearb> jow, in general, the ath10k-ct driver has not had any serious changes recently except for moving to a newer kernel (4.19 vs 4.16).  The firmware was a bigger change.  There is not a tight dependency between fw and driver (both should be forwards/backwards compat).
Dec 18 13:51:52 <KanjiMonster> jow: maybe. I don't know the target enough to tell how often it happens, but since the follow up fixup commit it seems to happen less often. I would say nbd should have the final say on revert or not
Dec 18 13:51:55 <xback> stintel: thank you
Dec 18 14:00:49 <stintel> xback: yw
Dec 18 14:15:23 <xback> jow: fyi, bumps are done on 18.06
Dec 18 14:24:27 <movi> jow: ath10k is slow but stable, ath10k-ct is fast but likes to crash, unless we're talking about 10.4b-12, then PHY rate slows down with time. this is on 9980
Dec 18 14:27:25 <movi> jow: hoever, it sure seems like guys using 9984 have it much better
Dec 18 14:30:16 <rmilecki> ynezz: thanks for the DTS checkup list!
Dec 18 14:30:24 <rmilecki> ynezz: maybe replace “ with "
Dec 18 14:30:34 <rmilecki> or i can do that later too probably
Dec 18 14:30:45 <rmilecki> just too busy right now fixing the USB regression
Dec 18 15:01:47 <stintel> xback: not sure if you followed the stuff about jitterentropy_rng on bcm2708, but what do you think of https://git.openwrt.org/f7f6e4bf ?
Dec 18 15:06:54 <xback> stintel: I followed it a bit
Dec 18 15:07:14 <xback> Did you test the hypothesis of KanjiMonster regarding the potential lack of a HR timer?
Dec 18 15:07:44 <jow> excluding a .ko on a specific subtarget because it has load issues there feels a bit hackish
Dec 18 15:08:11 <xback> jow: my thoughts exactly
Dec 18 15:08:13 <jow> personally I'd prefer a subtarget specific kernel patch either fixing the module or making it return with something like -ENOSYS
Dec 18 15:08:16 <stintel> jow: it does, but it silences 229 lines in dmesg, improves boot time, and works around the problem
Dec 18 15:08:42 <stintel> I would prefer to find the actual cause of the issue with headless vs hdmi connected, but that's over my head
Dec 18 15:09:04 <xback> the module load failure should at least free it's memory usage
Dec 18 15:09:08 <stintel> jow: the module is not broken
Dec 18 15:09:14 <stintel> https://lkml.org/lkml/2017/5/10/630
Dec 18 15:10:28 <jow> still feels odd for production code
Dec 18 15:11:00 <jow> I mean if it takes 5s to assert the (un)fitness of the timer as prnd source and then also burning memory and not releasing it in the process then its clearly broken imho
Dec 18 15:11:42 <jow> anyhow, isn't there any cmdline knob for it to silence that part of the code?
Dec 18 15:11:51 <stintel> jow: it doesn't take 5s, the fact that it's trying to be loaded 229 times does
Dec 18 15:12:41 <KanjiMonster> whatever is causing it to be loaded 229 times should be fixed
Dec 18 15:12:44 <stintel> we should probably also look into that
Dec 18 15:13:22 * xback is building brcm2708
Dec 18 15:13:29 <KanjiMonster> this might be causing memory fragmentation, and thus the vmalloc failure later
Dec 18 15:14:34 <russell--> 229 times, it is good to be sure.
Dec 18 15:15:33 <KanjiMonster> definition of insanity etc etc
Dec 18 15:15:54 <russell--> lol
Dec 18 15:15:56 <xback> it probably contains a +1 bug somewhere which prevents it from loading a round 230 times ..
Dec 18 15:15:58 <jow> stintel: I guess the 229 times are caused by request_module() in the kernel which calls our modprobe through /proc/sys/kernel/modprobe which is slow due to the lack of a cache file (depmod on normal systems)
Dec 18 15:16:40 <jow> "our modprobe" the ubox recursive module loader (kmodloader)
Dec 18 15:18:02 <jow> our module loadin infrastructure is not well prepared for the case that a kmod is requested over and over and subsequently failing to load
Dec 18 15:18:45 <jow> either the kmod does not exist, then its cheap or it loads successfully, so the whole dependency resolving machinery is only run once
Dec 18 15:20:01 <jow> I guess what we would need is a kind of "blacklist jitterentropy_rng" somewhere in /etc/modules.d/ which instructs kmodloader to not bother
Dec 18 15:20:18 <jow> the blacklist partial can then be shipped by any subtarget
Dec 18 15:22:16 <jow> problem is that kmodloader does not yet understand blacklist entries
Dec 18 15:23:05 <stintel> can anyone explain why this isn't a problem with HDMI attached?
Dec 18 15:23:41 <jow> maybe attaching hdmi introduces timer jitter?
Dec 18 15:23:43 <xback> It could be that HDMI triggers another timer to be used which is sufficient
Dec 18 15:24:08 <karlp> how do you use a timer as a prng source anyway?
Dec 18 15:24:15 <stintel> no, https://www.linux-ipv6.be/OpenWrt/RPi/dmesg-4_14.txt is with hdmi attached
Dec 18 15:24:21 <karlp> maybe I shouldn't open rabbitholes
Dec 18 15:24:24 <stintel> karlp: ask the kernel guys :)
Dec 18 15:24:37 <jow> karlp: by trying to load a kmod 229 times
Dec 18 15:24:44 <stintel> LOL
Dec 18 15:25:01 <KanjiMonster> or outputting on hdmi causes enough jitter for the cause to not run into the loop issue
Dec 18 15:25:18 <stintel> KanjiMonster: no, see https://www.linux-ipv6.be/OpenWrt/RPi/dmesg-4_14.txt
Dec 18 15:25:22 <stintel> that's with HDMI attached,
Dec 18 15:25:29 <stintel> the module doesn't load either
Dec 18 15:25:31 <owrt-1806-builds> build #161 of ramips/mt76x8 is complete: Failure [failed pkgbuild]  Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Fmt76x8/builds/161  blamelist: Magnus Kroken <mkroken@gmail.com>, Rosen Penev <rosenp@gmail.com>, Paul Wassi <p.wassi@gmx.at>, Thibaut VAR?NE <hacks@slashdirt.org>, Tony Ambardar <itugrok@yahoo.com>,
Dec 18 15:25:31 <owrt-1806-builds> Peter Wagner <tripolar@gmx.at>, Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>, Ted Hess <thess@kitschensync.net>, Timo Sigurdsson <public_timo.s@silentcreek.de>, Denton Gentry <denny@geekhold.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Christo Nedev <christo.nedev@gmail.com>, Konstantin Demin <rockdrilla@gmail.com>, Martin
Dec 18 15:25:31 <owrt-1806-builds> Schiller <ms@dev.tdt.de>, Rodolfo Giometti <giometti@linux.it>, Hannu Nyman <hannu.nyman@iki.fi>, Daniel Golle <daniel@makrotopia.org>, Yousong Zhou <yszhou4tech@gmail.com>, Paul Spooren <mail@aparcar.org>, Rafa? Mi?ecki <rafal@milecki.pl>, Hans Dedecker <dedeckeh@gmail.com>, Andreas Ziegler <dev@andreas-ziegler.de>, Thomas Langer <thomas.langer@intel.com>,
Dec 18 15:25:31 <owrt-1806-builds> Eneas U de Queiroz <cote2004-github@yahoo.com>, Marko Ratkaj <marko.ratkaj@sartura.hr>, David Yang <mmyangfl@gmail.com>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Alin Nastac <alin.nastac@gmail.com>, Brett Mastbergen <bmastbergen@untangle.com>, Alexandru Ardelean <ardeleanalex@gmail.com>, Lev <leventelist@gmail.com>, Stijn Tintel <stijn@linux-
Dec 18 15:25:31 <owrt-1806-builds> ipv6.be>, Koen Vandeputte <koen.vandeputte@ncentric.com>, Jason A. Donenfeld <Jason@zx2c4.com>, Ivan Shapovalov <intelfx@intelfx.name>, Dmitry Tunin <hanipouspilot@gmail.com>, Chen Minqiang <ptpt52@gmail.com>, Mathias Kresin <dev@kresin.me>, Jonathan Lancett <j.lancett@ntlworld.com>, Felix Fietkau <nbd@nbd.name>, Luiz Angelo Daros de Luca
Dec 18 15:25:31 <owrt-1806-builds> <luizluca@gmail.com>, Jo-Philipp Wich <jo@mein.io>, Alexander Couzens <lynxis@fe80.eu>, ?? <uxgood.org@gmail.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, Florian Eckert <fe@dev.tdt.de>, Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>, Alex Maclean <monkeh@monkeh.net>, Rosy Song <rosysong@rosinson.com>, Hauke Mehrtens <hauke@hauke-m.de>, Keith Wong
Dec 18 15:25:31 <owrt-1806-builds> <keithwky@gmail.com>, Andy Walsh <andy.walsh44+github@gmail.com>
Dec 18 15:25:49 <jow> f*
Dec 18 15:25:51 <stintel> :D
Dec 18 15:26:07 <owrt-snap-builds> build #319 of mediatek/mt7623 is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7623/builds/319
Dec 18 15:26:17 <jow> Package kmod-gpio-mcp23s08 is missing dependencies for the following libraries:
Dec 18 15:26:20 <jow> regmap-i2c.ko
Dec 18 15:26:25 <jow> hah, wasn't me
Dec 18 15:26:48 <jow> xback: I guess this is due to the bumps
Dec 18 15:26:52 * ldir grins
Dec 18 15:27:08 <xback> wth?
Dec 18 15:27:18 <xback> checking ..
Dec 18 15:27:23 <xback> f*
Dec 18 15:30:39 <KanjiMonster> stintel: jow: I wonder if this is actually kmodloader that tries that often, as the tries stop at the same time as kmodloader says that 1 module failed to probe, and not something from the kernel
Dec 18 15:32:43 <jow> KanjiMonster: yes, indeed. could be that the module is re-probed with every dependency resolution cycle
Dec 18 15:35:32 <KanjiMonster> probably this loop https://git.openwrt.org/?p=project/ubox.git;a=blob;f=kmodloader.c;h=1b6488f0ff4b8f28f4039346660d01afac58c12d;hb=HEAD#l633
Dec 18 15:35:59 <jow> I think I see the problem
Dec 18 15:36:36 <jow> it does not check m->error
Dec 18 15:36:58 <jow> so it will try over and over again in case insert_module() failed and something else got successfully loaded
Dec 18 15:37:13 <KanjiMonster> yeah
Dec 18 15:37:52 <jow> stintel: can you give this patch a try? http://sprunge.us/1TujyO
Dec 18 15:38:04 <karlp> hrm.  my usb port on my ar9331 device worked when I initially submitted the dts to ath79.
Dec 18 15:38:22 <karlp> I've now been away, and it doesn't detect it.  is there aythign that's likely to have changed?
Dec 18 15:38:42 <jow> must be applied to ubox.git (or as package/system/ubox/patches/999-foo.patch)
Dec 18 15:38:46 <KanjiMonster> jow: might be intentional though, else setting error to 0 on successful load would be pointless
Dec 18 15:38:55 <karlp> I'm suspecting missing vbus-supply nodes? but would that have come in from a kernel change? vbus-supply = <&reg_usb_vbus>; ?
Dec 18 15:39:49 <jow> KanjiMonster: right, maybe it should loop while todo > 0, not while loaded > 0
Dec 18 15:41:05 <karlp> hrm, or just missing chipidea kmod.
Dec 18 15:41:08 <karlp> how does that happen though.
Dec 18 15:45:05 <KanjiMonster> jow: https://git.openwrt.org/?p=project/ubox.git;a=commit;h=6efea338b33c265aca21e6826b81d332bcee9280 is the commit that changed it from try once to try every time
Dec 18 15:45:58 <jow> yeah, the problem is the brute force approach
Dec 18 15:46:41 <jow> we do not really build and walk a dependency graph but repeatedly throw all kmods against the wall until everything fits (or failed to load)
Dec 18 15:49:20 <jow> I see no reason why we should ever retry on m->error
Dec 18 15:49:46 <jow> I guess the intention was to retry in case of unmet indirect dependencies
Dec 18 15:49:56 <jow> or implicit ones, rather
Dec 18 15:51:30 <xback> jow: just compile-tested 18.06 for mt76x8 and it builds as expected?
Dec 18 15:52:32 <xback> jow: hold on. ill check for that specific package
Dec 18 15:54:04 <KanjiMonster> jow: external modules had broken dependencies until recently, that should be now fixed and retrying *should* not be needed anymore
Dec 18 15:54:08 <stintel> jow: so I still try that patch ? (http://sprunge.us/1TujyO)
Dec 18 15:54:52 <jow> stintel: yes please
Dec 18 15:55:36 <jow> KanjiMonster: that explains it, maybe we can implement a middle way, retry one again on m->error and simply print an error / warning if it fails again on the 2nd try
Dec 18 15:56:22 <KanjiMonster> jow: yeah, just increment error until max_tries is reached ;)
Dec 18 15:59:29 <jow> was thinking about something like this: http://sprunge.us/sTBjq6
Dec 18 16:00:37 <xback> jow: it's a backport by you ;)   https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8ec7ad033efd68b609591cca0584772d95f78d8e
Dec 18 16:01:02 * xback throws the hot potato back
Dec 18 16:01:11 <jow> damn
Dec 18 16:01:32 * ldir ducks under the hot potatos
Dec 18 16:03:05 <jow> xback: I'll revert it for now
Dec 18 16:03:09 <jow> thanks for looking
Dec 18 16:03:13 <xback> hold on
Dec 18 16:03:19 <xback> just reverted it and compile-testing atm
Dec 18 16:03:28 <xback> but it's the only one suspectible
Dec 18 16:04:08 <jow> I guess the fixed pacakagaing exposed the dependency error
Dec 18 16:04:21 <jow> before that commit the kmod likely was empty
Dec 18 16:04:50 <xback> I still want to figure out why it doesnt occur on master (i think?)
Dec 18 16:06:25 <jow> xback: master has "kernel: add missing dependency to regmap to kmod-gpio-mcp23s08" which I forgot to pick along
Dec 18 16:07:39 <jow> I failed to properly check the "Fixes:" tags to find commits related to the cherry-picked ones
Dec 18 16:07:53 <xback> jow: good find
Dec 18 16:13:28 <stintel> is there actually a way to have that "Fixes: " tag added automatically to a commit message ?
Dec 18 16:13:44 <stintel> by specifying a hash to "git commit .."?
Dec 18 16:14:02 <stintel> I looked at the man page before but can't recall finding anything
Dec 18 16:15:01 <jow> stintel: no, I think you need to write a git alias for it
Dec 18 16:15:19 <Hauke> I add the Fixes manually
Dec 18 16:17:00 <stintel> jow: that ubox patch seems to work
Dec 18 16:17:07 <stintel> once: [   10.625777] jitterentropy: Initialization failed with host not compliant with requirements: 2
Dec 18 16:17:26 <stintel> no vmalloc failures when loading brcmfmac later
Dec 18 16:17:32 <stintel> and ~5s faster boot time
Dec 18 16:17:46 <stintel> from ~30 to ~25s
Dec 18 16:18:07 <stintel> actually it's much less, those times are when wlan0 is connected
Dec 18 16:20:59 <Monkeh> I didn't break it this time, I swear
Dec 18 16:24:01 <jow> stintel: can you try the 2nd variant as well? http://sprunge.us/sTBjq6
Dec 18 16:24:27 <stintel> jow: avec plaisir
Dec 18 16:30:55 <karlp> right. hrm, kmod-chipidea was missing. bizarro.
Dec 18 16:32:25 <xback> stintel: I found a rpi b+ here
Dec 18 16:32:40 <xback> will take a look at the deeper issue maybe tomorrow
Dec 18 16:33:52 <stintel> xback: cool!
Dec 18 16:34:09 <stintel> xback: or I can order you a zero w and have it shipped to your place
Dec 18 16:34:27 <stintel> jow: now twice "jitterentropy: Initialization failed with host not compliant with requirements: 2"
Dec 18 16:34:36 <stintel> and no vmalloc issues when loading later modules
Dec 18 16:34:59 <xback> found this one in a box here:  https://openwrt.org/_media/media/raspberry_pi_foundation/rpi1b.jpg
Dec 18 16:35:22 <stintel> jow: actually that might silence the gpio-nct5104d flood as well
Dec 18 16:35:47 <stintel> so http://patchwork.ozlabs.org/patch/1015366/ would not be needed
Dec 18 16:36:06 <stintel> ynezz: fyi ^
Dec 18 16:36:26 * stintel tests 
Dec 18 16:36:38 <stintel> tmpfs                     4,0G  4,0G     0 100% /tmp
Dec 18 16:36:39 <stintel> derp
Dec 18 16:36:47 <karlp> (why did ynezz have the module in their image without having appropriate hardware?)
Dec 18 16:37:21 <stintel> karlp: I have it too when testing my apu image in qemu
Dec 18 16:37:42 <stintel> building multiple images just for debugging consumes more time
Dec 18 16:38:05 <stintel> lol perf top coredumped a 4GB file
Dec 18 16:38:17 <karlp> how did you get perf to compile?!
Dec 18 16:38:28 <stintel> karlp: it's on my workstation :P
Dec 18 16:38:34 <stintel> perf is a major pita
Dec 18 16:38:49 <stintel> can't get it to build on my Gentoo hardened musl systems either
Dec 18 16:39:12 <karlp> year, I tried again the other day to turn it on, failed. got lost in them trying to do a hsot build, and screwing up all the paths somewhere.
Dec 18 16:39:25 <karlp> and I don't need the tool it builds, but there's no option to turn it off
Dec 18 16:42:04 <stintel> it's frustrating how some software keeps causing issues on (almost) every new version
Dec 18 16:42:18 <stintel> gdb, strace, perf, to name a few
Dec 18 17:00:20 <jow> I'll let openwrt-18.06 settle until tomorrow to see if further build errors pop up
Dec 18 17:00:49 <jow> down from ~1200 to ~780 commits to review
Dec 18 17:01:55 <stintel> jow: cool. about that ubox patch, do you plan to commit it or do you want other opinions still ?
Dec 18 17:01:58 <xback> not bad for a point release :)
Dec 18 17:02:36 <xback> stintel: at first glance it looks like the pi model B here is dead.  No uart currently.  will check again tomorrow
Dec 18 17:02:41 <jow> stintel: hm
Dec 18 17:02:51 <stintel> I guess I should take my RPi3B+ and Zero W with me to Belgium
Dec 18 17:02:56 <jow> stintel: I'm still unsure if we need the retry logic at all
Dec 18 17:03:06 <stintel> or I'll be unable to do any proper testing for 2 weeks
Dec 18 17:03:39 <xback> maybe ill order a few as cheap "stress" devices for our local mesh app ;-)
Dec 18 17:03:51 <xback> anyways. im off for today. cya tomorrow xx
Dec 18 17:03:54 <stintel> the zero w is painful to get
Dec 18 17:03:55 <jow> bye
Dec 18 17:04:03 <stintel> xback: bye and thanks
Dec 18 17:04:16 <xback> likewise :)
Dec 18 17:04:24 <stintel> I have 4 now, but at most shops you can only order 1 per order
Dec 18 17:04:44 <stintel> maybe I should order a 5th one that can stay in Belgium
Dec 18 17:05:11 <stintel> and another 3B+ as well. planning to use one as my workstation when I'm there
Dec 18 17:05:43 <stintel> PXE booted with NFS root, on one of my monitors I still have there. 24" 1920x1200 beats a 13" laptop
Dec 18 17:05:44 <karlp> the zero w would be an interesting product if it was actually available.
Dec 18 17:06:32 <stintel> just having the laptop there usually results in me not doing any openwrt stuff while I'm in Belgium
Dec 18 17:07:35 <jow> you must not spend your spare time without doing any openwrt stuff!
Dec 18 17:08:03 <stintel> it's not spare time really, when I'm in Belgium I go to the office, when I'm in Bulgaria I work remotely
Dec 18 17:08:03 <ynezz> stintel: ah, great! I was wondering why the hell it's being probed 246 times :)
Dec 18 17:09:27 <stintel> jow: what about starting with the 2nd iteration of your patch, and rethink/discuss removing the retry logic entirely afterwards ?
Dec 18 17:11:09 <jow> stintel: yeah, will take care of it later
Dec 18 17:11:16 <jow> have to buy some groceries first
Dec 18 17:11:38 <stintel> maybe the patch will expose some issues that were overlooked
Dec 18 17:12:09 <stintel> jow: ah, I'm ordering out and finishing what I still have until Friday to not have stuff go bad while I'm away :)
Dec 18 17:12:49 <stintel> I'm going to start on updating brcm2708/4.14 to what's currently in rpi-4.14.y soon
Dec 18 17:26:41 <stintel> ynezz: I marked your patch for gpio-nct.. superseded
Dec 18 17:27:14 <stintel> ynezz: with jow's patch to ubox (http://sprunge.us/sTBjq6), this is what I get in Qemu: https://pastebin.com/rtKAFiPw
Dec 18 17:28:26 <stintel> should I reply to your post on the ML to mention we're looking into changing ubox instead?
Dec 18 17:28:35 <stintel> or is the info here enough for you
Dec 18 18:15:53 <zorgx> hey :) can you guess add support for inteno eg400 ? it think the drivers\ kernel patches and stuff is up to date from inteno
Dec 18 18:16:13 <zorgx> http://iopsys.inteno.se/iopsys/consumer/
Dec 18 18:16:40 <zorgx> http://iopsys.inteno.se/iopsys/packages/iopsys-brcm63xx-arm/
Dec 18 18:19:11 <stintel> zorgx: send a patch, or ask iopsys to do so
Dec 18 18:19:25 <stintel> s/iopsys/inteno/
Dec 18 18:19:33 <zorgx> a patch for ?
Dec 18 18:19:38 <stintel> to add support
Dec 18 18:20:21 <zorgx> like iop-cc/target/linux/iopsys-brcm63xx-arm
Dec 18 18:21:33 <zorgx> ?
Dec 18 18:21:53 <stintel> https://openwrt.org/submitting-patches
Dec 18 18:30:36 <Hauke> I would like to merge the layerscape pull request is that ok?
Dec 18 18:38:36 <danitool> but brcm63xx-arm isnt't still supported in openwrt, is it?
Dec 18 18:43:50 <KanjiMonster> it isn't
Dec 18 18:45:41 <KanjiMonster> danitool: zorgx: also the inteno buildchain is a mix of openwrt and the broadcom sdk; there is no easy way of integrating it into standard OpenWrt
Dec 18 18:47:22 <zorgx> are you sure ? then i just added the feeds from openwrt to the iop builder i think most of the stuff work
Dec 18 18:49:07 <KanjiMonster> zorgx: that way works, but the iop builder is heavily modified, and you can't just take its parts and put them into OpenWrt
Dec 18 18:49:14 <Hauke> ynezz: I can not reproduce the problems you saw with the layerscape pul request
Dec 18 18:49:40 <danitool> stuff like packages are easy to make it work with other sdks
Dec 18 18:51:06 <Hauke> ynezz: what did you do with kernel 4.19 and the layerscape target?
Dec 18 18:51:13 <zorgx> the problem i have is that most of the packages from iop is outdated with like a yr or 2, most are updated in the openwrt builder, and i want to just "copy -past" but that only make a mess.. i need a "copy folder, del old folder and replace it with new folder"
Dec 18 18:52:06 <danitool> and probably the kernel is also outdated
Dec 18 18:52:14 <KanjiMonster> 4.1
Dec 18 18:52:15 <danitool> which version does it use?
Dec 18 18:52:39 <KanjiMonster> 4.1.38 to be precise
Dec 18 18:57:03 <zorgx> it say it is 4.1.38
Dec 18 18:57:16 <zorgx> Kernel Version 	 4.1.38
Dec 18 18:57:37 <zorgx> do you have the ssh commando to "that is my kernel" ?
Dec 18 18:58:11 <danitool> uname -a ?
Dec 18 18:58:20 <danitool> not sure whata a ssh comando is :P
Dec 18 18:58:24 <Hauke> 4.1.38 is only 23 months old
Dec 18 19:00:50 <zorgx> Linux iopsys 4.1.38 #1 SMP PREEMPT Thu Dec 13 22:36:07 CET 2018 armv7l GNU/Linux
Dec 18 19:01:07 <danitool> I bet in 10 years the 4.1.38 version will remain in new brcm63xx-arm devices
Dec 18 19:01:39 <zorgx> is it posible to use a later verson of it ?
Dec 18 19:17:25 <stintel> alrighty, brcm2708/4.14 based on 4.14.89 ready
Dec 18 19:17:41 <stintel> jow: just waiting for your decision about kmodloader / ubox, and I can push
Dec 18 19:18:06 <jow> stintel: I am fine with using the 2nd iteration for now
Dec 18 19:18:28 <jow> will you take care of it? I probably can't commit it before tomorrow
Dec 18 19:19:02 <stintel> jow: I will take care of it then, and add your SoB
Dec 18 19:19:13 <jow> thanks!
Dec 18 19:19:19 <stintel> jow: thank you! :)
Dec 18 19:26:12 <zorgx> can i just edit a make file ?
Dec 18 19:44:14 <zorgx> there is the busybox startpage ?
Dec 18 19:46:31 <ynezz> Hauke: nothing special, just enabled all targets and all kmods, then built with verbose V=s (otherwise you don't see the kernel config stuff/missing symbols)
Dec 18 19:48:31 <zorgx> lol https://pastebin.com/A31Msp5g
Dec 18 19:50:03 <ynezz> stintel: it's ok, I wanted to do the same and noticed, that you was faster, thanks
Dec 18 19:52:19 <ynezz> anyway, I still think, that this pr_info is useless and maybe it should be printed only if the device != 0xffff
Dec 18 19:52:56 <ynezz> but that module is going to be deprecated soon (let's hope) so it makes no sense to touch it
Dec 18 19:56:43 <zorgx> and that is gcc ? is it any point to have gcc 8.x ?
Dec 18 20:03:52 <stintel> jow: https://gist.github.com/cdad9747d30313332a9eb5b9e6ef1865
Dec 18 20:04:47 <zorgx> make[5]: Entering directory '/home/zorgx/iop-cc1/build_dir/target-arm_xscale_musl_eabi/linux-iopsys-brcm63xx-arm/linux-4.14.28' Makefile:657: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler make[5]: arm-openwrt-linux-muslgnueabi-gcc: Command not found scripts/kconfig/conf  --silentoldconfig Kconfig net/sched/Kconfig:44: warning: menuconfig statement without prompt
Dec 18 20:04:53 <stintel> fixed some typos: https://gist.github.com/c2d2c7a269bd2c7b1823d2071e28bca1
Dec 18 20:05:04 <stintel> jow: if that's OK with you I'd like to push it
Dec 18 20:31:16 <zorgx> help, can somebody tak a look on this ? https://pastebin.com/9FCr32Yw
Dec 18 21:07:47 <stintel> ok I'm gonna go ahead and push this, I'll take the flame tomorrow :P
Dec 18 21:23:15 * stintel waits for owrt-snap-builds to blame him
Dec 18 21:32:17 <karlp> nice, sqlite changelog doesn't evenmention it being a security fix. https://www.sqlite.org/releaselog/3_26_0.html
Dec 18 21:32:37 <mangix> nope
Dec 18 23:12:09 <blogic> foo ?! https://wavecomp.ai/mipsopen
Dec 18 23:12:19 <blogic> pretty mind blowing
Dec 18 23:12:40 <blogic> small step for man ...
Dec 18 23:13:05 <blogic> even the ASE stuff
Dec 18 23:20:50 <Hauke> blogic: ASE?
Dec 18 23:25:20 <pkgadd> Hauke, jow: regarding the WDS/ 4addr issue with e.g. ath10k{,-ct} in 4.18/ 4.19 based backports (https://github.com/openwrt/openwrt/pull/1640), would you prefer reverting the offending commit or taking v1 (not merged in mac80211-next) of the proposed fix that's pending a v2 some time in the future?
Dec 18 23:29:03 <blogic> Hauke: the extensions like dsp, mt, ...
Dec 18 23:29:17 <blogic> Application Specific Extensions
Dec 18 23:29:23 <blogic> like xrx200 has the MT ase
Dec 18 23:29:34 <blogic> cpuinfo will list the ones your silicon has
Dec 18 23:29:41 <Hauke> yes, but this does not include the cores itself, only when you build your own cores as far as I understood
Dec 18 23:30:09 <blogic> my understnding is that R6 + mt/dsp will go open for 32/64
Dec 18 23:30:36 <Hauke> I understood this only covers the ISA description, but not the implementation
Dec 18 23:30:47 <blogic> ah ok
Dec 18 23:30:54 <blogic> that would nake it useless
Dec 18 23:32:05 <Hauke> something like this Lexra core would be ok (https://www.linux-mips.org/wiki/Lexra )
Dec 18 23:33:07 <Hauke> they are not talking about their Warrior core
Dec 18 23:35:19 <Hauke> If a vendor is just building a SoC and the CPU is not so improtant, vendors would still buy just an existing and proven core instead of makeing their own, at least for the complex stuff like running Linux more or less fast
Dec 18 23:40:18 <Hauke> SiFive also sells their RISC-V cores for about $500K and they are open source ;-)
Dec 19 00:19:39 <ArthurMLago> Hi guys, I am new to the project, but am very interested in trying to help, is it okay if I ask some questions on adding platform/devices here?
Dec 19 00:35:36 <zorgx> how do i start ssh from luci ? or telnet
Dec 19 00:41:40 <mangix> ArthurMLago: go ahead
Dec 19 00:42:15 <mangix> zorgx: System > Startup
Dec 19 00:51:11 <zorgx> that site dosent load
Dec 19 00:54:39 <zorgx> can i make a commando to start it ?
Dec 19 00:54:52 <zorgx> from http://192.168.1.1/cgi-bin/luci/admin/system/commands/config
Dec 19 01:00:02 <ArthurMLago> So, as I understand it from the tutorial in the website, adding a new platform is basically porting the linux kernel to the routers CPU. So if a CPU is already supported in kernel, this step is basically done?
Dec 19 01:01:09 <ArthurMLago> Oh, but may still require the (binary)drivers for additional hardware in the board? which I would think is easier than porting the kernel?
Dec 19 01:04:24 <pkgadd> if a SOC (not just the CPU) is fully supported in the mainline kernel (taking x86 as an example), you end up with a rather simple task of providing a kernel config, some sysupgrade support and some configuration defaults. for less desktop'ish systems you also have to invest more or less time on the image generation aspects, bootloaders, etc.
Dec 19 01:05:42 <pkgadd> but given that most real-world devices need a lot more than just that, your tasks will be bigger than that
Dec 19 01:06:18 <pkgadd> as in DTS, GPIO/ LED configuration, providing calibration data, setting MAC addresses, etc. pp
Dec 19 01:06:50 <Hauke> ArthurMLago: binary only driver are anyway a no go for OpenWrt, binary only FW is ok
Dec 19 01:07:14 <Hauke> pkgadd: I will have a look at the wifi patch tomorrow, but I favor the backport
Dec 19 01:08:00 <pkgadd> Hauke: o.k., the provided patch works as is - if there's anything else I can provide/ do any further testing, give me a hint
Dec 19 01:09:36 <ArthurMLago> pkgadd: You used x86 as an example, but for SOCs, having support for the architecture isn't enough right? I'm still a beginner in kernel development too, but when go into the kernel's arch/mips/ for example, there are still a bunch of manufacturer dependent stuff still
Dec 19 01:10:23 <zorgx> any ides ? ssh just stop after udating beardrop
Dec 19 01:10:33 <ArthurMLago> Hauke: binary drivers are no go for OpenWRT? in the adding a platform it is mentioned that we should send a message asking for sources, but that the drivers could be binary
Dec 19 01:11:33 <ArthurMLago> In this case, we must get drivers through reverse engineering? Isn't this a little time consuming? or is there an easier way?
Dec 19 01:11:36 <pkgadd> ArthurMLago: no, a SOC is more specific than just a generic arch or ISA. what use would be support for the tiny CPU, if you have no way of getting to it (I/O IP cores)
Dec 19 01:12:51 <pkgadd> or to re-use x86 as example, what use would be CPU support, if you're missing support for north- and southbridge of the mainboard
Dec 19 01:13:30 <pkgadd> ...and that's already an easy(ier) example, due to UEFI, ACPI, SMM and friends
Dec 19 01:19:44 <ArthurMLago> pkgadd: ok, I get it. but still, assuming full the SoC is fully supported in kernel, there are still other chips in the board that would need drivers, right? so it becomes a hard task again?
Dec 19 01:23:27 <pkgadd> it depends
Dec 19 01:28:47 <ArthurMLago> on what? if the other chips already have open source drivers?
Dec 19 01:32:16 <pkgadd> in that case your work is easier (as in hopefully just having to set it up via Kconfig and DTS)
Dec 19 01:33:48 <ArthurMLago> if there aren't, is it still possible? and in an acceptable amount of time? where should I go to learn about this? is it reverse engineering device drivers?
Dec 19 01:34:18 <pkgadd> probably
Dec 19 01:34:38 <pkgadd> there is no generic answer for hypotheticals
Dec 19 01:36:10 <pkgadd> basically, you have to get it working - at the very least to some kind of usable and useful degree. and for practical reasons all you need in order to accomplish that must be opensource and GPLv2 compatible and not too far away from mainline mergable
Dec 19 01:39:02 <mangix> zorgx: sounds like it's crashing. verify by running ps
Dec 19 01:47:02 <zorgx> ps ?
Dec 19 02:46:21 <jwh> hm
Dec 19 02:46:29 <jwh> me tries to figure out how to auto tune conntrack max
Dec 19 02:48:28 <jwh> ugh
Dec 19 02:48:34 <jwh> prefixed with a /
Dec 19 02:48:34 <jwh> :D
**** ENDING LOGGING AT Wed Dec 19 03:00:01 2018