**** BEGIN LOGGING AT Mon Dec 17 03:00:00 2018 Dec 17 06:30:35 Monkeh: ping Dec 17 06:30:46 got the HG6XX pic link again ? Dec 17 07:11:07 Hauke: i have taken the liberty to set the patches you merged as accepted in patchwork. hope thats fine ;) Dec 17 07:17:45 http://patchwork.ozlabs.org/patch/1010177/ maybe i am crosseyed but this patch changes the logic ?! Dec 17 07:38:30 blogic:I think the patch is fine; handler->cb was called irrespective of handler->multi; only if multi is not set it breaks out of the for loop Dec 17 08:31:56 hi Dec 17 08:32:07 i tried to push a new commit but i get Dec 17 08:32:11 remote: error: GH006: Protected branch update failed for refs/heads/master. Dec 17 08:32:14 remote: error: Required status check "DCO" is expected. Dec 17 08:32:17 what do i have to change? Dec 17 08:34:25 Checks that will be required are DCO (signature check) i sstated in the email from Ted Dec 17 08:34:49 arent DCO checks the "Signed-off-by:" lines? Dec 17 08:44:17 can some one push it https://github.com/openwrt/openwrt/pull/1590 ? Dec 17 08:44:45 I m waiting more than 2 weeks Dec 17 08:52:49 ping nbd Hauke Dec 17 08:57:36 puchu: which repo are you pushing to ? Dec 17 08:57:46 master Dec 17 08:58:01 that is a branch name Dec 17 08:58:26 origin/master Dec 17 08:58:30 remotes/origin/HEAD -> origin/master Dec 17 08:58:51 git.openwrt.org ? Dec 17 08:58:55 github Dec 17 08:59:01 packages on github Dec 17 08:59:23 so you want to say a sentence like "I am trying to push a patch to the packages feed on github and i get a DCO error" ? Dec 17 08:59:53 yes i guess so as this DCO crap is only on github yes Dec 17 09:00:46 remote: error: GH006: Protected branch update failed for refs/heads/master. Dec 17 09:00:49 remote: error: Required status check "DCO" is expected. Dec 17 09:00:49 ! [remote rejected] master -> master (protected branch hook declined) Dec 17 09:00:49 puchu: does the author field match the SoB line ? Dec 17 09:01:09 what is the "author field"? Dec 17 09:01:34 have you opend the patch file and looked inside for Author before asking ? Dec 17 09:01:57 patch file? i changed some code and tried to push my commit Dec 17 09:02:01 there is no patch file Dec 17 09:02:16 Signed-off-by: Peter Wagner Dec 17 09:02:20 oh you used that broken code editor Dec 17 09:02:28 the same SoB as i use it since years Dec 17 09:02:36 cant help sorry Dec 17 09:02:52 blogic: oh you used that broken code editor ? Dec 17 09:03:01 i never used github editing foo as it does not work Dec 17 09:03:12 i just use git on a commandline Dec 17 09:03:17 me too Dec 17 09:03:20 sorry :/ Dec 17 09:03:24 i use the cmdline Dec 17 09:03:30 then you have a patch Dec 17 09:03:35 git show or format + vi Dec 17 09:03:51 Author: Petr Štetiar Dec 17 09:03:55 Signed-off-by: Petr Štetiar Dec 17 09:04:00 those 2 need to match Dec 17 09:04:19 that is the most common error why pushing fails Dec 17 09:04:33 and if it still fails, mail me the patch so i can have a look john@phrozen.org Dec 17 09:05:09 okay thanks Dec 17 09:09:55 SQOTD (silly question of the day) if I add a kernel patch, without bumping kernel version, how does the build system/buildbots know how to rebuild the kernel 'cos there's no 'package version' to bump. Confused. Dec 17 09:55:56 KanjiMonster: your bcm6348-pinctrl driver is broken, it apparently makes nothing in my device Dec 17 09:56:14 root@OpenWrt:~# devmem 0xfffe0418 Dec 17 09:56:21 0x00000000 Dec 17 09:57:19 Hauke: the zip issue is known and was communicated to Jow. It seems it's not always possible to add this separate dependency as we dont always have full control of the buildslave. Dec 17 09:58:33 jow: But I think is should be possible to add the zip utility to the new buildslave dockers? Dec 17 10:00:05 hackpascal: the new 4366b firmware has regressed 5 GHz for me, but I guess my devices has corrupted NVRAM Dec 17 10:00:11 Hauke: the new 4366b firmware has regressed 5 GHz for me, but I guess my devices has corrupted NVRAM Dec 17 10:00:21 hackpascal: i mean to write Hauke, sorry Dec 17 10:07:09 could someone have a quick nose at https://patchwork.ozlabs.org/patch/1014373/ - it works....the thing I'm most bothered by....the patch numbering Dec 17 10:13:49 ldir: I think 600* numbering is more appropriate (https://oldwiki.archive.openwrt.org/doc/devel/patches#naming_patches) Dec 17 10:14:18 or even 095 would suit it better Dec 17 10:15:06 xback: good shout - 095 it is :-) Dec 17 10:15:15 I think I understand the issue .. we basically got 2 things mixed now these days .. In the past there was no "backports" folder (which is why the 000 series exist) Dec 17 10:15:50 some patches seem to disregard the numbering, while others still oblige to it (even while in the backports folders) Dec 17 10:16:02 indeed, it's the source of my confusion. Dec 17 10:16:05 can also check https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/PATCHES ;-) Dec 17 10:16:56 actually I'm going to combine the two.... 695 :-) Dec 17 10:17:02 stintel: it doesn't solve the confusion :) Dec 17 10:17:15 I know. but oldwiki .. ;-) Dec 17 10:17:24 true true :) Dec 17 10:17:26 we have a backports directory and a backports 'type' :-) Dec 17 10:17:43 in your link, it should be named in the 1xx series? Dec 17 10:18:42 no, 'cos it's come from upstream Dec 17 10:19:03 oh I see what you're saying Dec 17 10:19:24 hmm, the 100 series is open to (mis)interpretation Dec 17 10:19:34 ldir: is that patch already accepted? Dec 17 10:19:56 if yes, it's a backport .. if no, it's awaiting upstream merge .. Dec 17 10:20:11 I believe so, it's in dave miller's net tree Dec 17 10:20:18 then it's a backport Dec 17 10:20:54 https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf Dec 17 10:22:54 * ldir gives in and goes with 095 again Dec 17 10:23:24 imho, 095 is good enough here. it will be deleted within 1 .. or weeks anyways during a bump Dec 17 10:23:37 ldir: speaking of .. im running the bumps currently Dec 17 10:24:17 lets ensure we don't enter a race condition here ;-) Dec 17 10:28:25 just sent a v2 - do you want me to wait for your bump? Dec 17 10:30:24 please go ahead. i'll refresh if required Dec 17 10:31:52 ldir: is this patch also valid for 3.18? Dec 17 10:33:11 As this is a new feature rather than bug fix I'm more inclined to think 'current targets' only. Dec 17 10:33:18 I didn't think 3.18 was current? Dec 17 10:33:50 true. but I dont have a clue at the scope of this patch towards kernels currently Dec 17 10:34:25 leave it then :) Dec 17 10:34:48 I'm happy with 4.9-4.19 and if Dave Taht wants it for 3.18 then he can do the patch :-) Dec 17 10:35:24 I'm doing this to help out..... and praying I haven't been suckered into a nightmare...again. Dec 17 10:36:34 ldir:I'm also currently backporting an upstream patch with as prefix 095 Dec 17 10:37:25 greearb: ping Dec 17 10:37:26 lol - I'll move to 096 Dec 17 10:38:12 ldir:I was also preparing to make that offer :) Dec 17 10:38:15 * ldir puts an auto delete on emails containing 'I didn't know you had commit privs to openwrt' Dec 17 10:38:53 ldir:do you have to resend the patch for another reason than the prefix switch ? Dec 17 10:39:03 otherwie I gladly switch to 096 Dec 17 10:39:15 no, just the prefix switch Dec 17 10:39:57 dedeckeh: ok I'll push this as is :-) Dec 17 10:40:06 Ok I will switch Dec 17 10:40:51 thank you :-) & thanks to all Dec 17 10:43:32 pushed Dec 17 10:43:42 and patchwork updated Dec 17 10:50:28 blogic: yes fine with me, I just forgot to update patchwork again Dec 17 10:56:05 rmilecki: hopefully we do not have to wait an other 2 years for the fix ;-) Dec 17 11:13:16 first gcc 7.4.0 regresssion https://paste.ubuntu.com/p/yy7gsgYWrM/ ? Dec 17 11:37:41 ynezz: could you please submitt a bug report to gcc Dec 17 11:49:46 Hauke: well, it's a result of my build testing for https://github.com/openwrt/openwrt/pull/1556 so I hope, that this NXP guy can confirm it as well and that he is going to handle it Dec 17 11:53:07 xback, Hauke: what do you think about that 4.14 support for layerscape, once he fixes all the build bugs and @mcbridematt it could be merged, right? Or did I missed any other issues with that PR ? Dec 17 11:53:32 s/@mcbridematt/@mcbridematt run test it/ Dec 17 12:00:01 ynezz: I'll let Hauke make the call regarding the merge, but another rebase will probably be needed by tomorrow as I'm currently upgrading all kernels. Dec 17 12:00:24 poor guy :) Dec 17 12:01:29 I tried to hold off a bit while this PR was running some time ago .. but the longer I wait, the more difficult it can get to bump them. Dec 17 12:02:01 yes, I understand it, it's fast moving target Dec 17 12:07:40 hrm, I'm having the same problem trying to push to github packages now too. author definitely matches SoB, any other ideas? https://zerobin.net/?27cc298926a817b2#Oq1vcWnetRWFQ3X/nB8bakpQCUTRhzx+8T7aU751npg= Dec 17 12:08:07 this is the "Required status check "DCO" is expected." error Dec 17 12:10:10 can't push to master packages either, so it's not 18.06 protection or anything Dec 17 12:11:44 danitool: I'll look into it Dec 17 12:12:11 karlp: please note in https://github.com/openwrt/packages/issues/7624 Dec 17 12:13:17 that just says "dco turned on", not "dco not being recognised" ? Dec 17 12:13:49 see my paste, author == sob, so what's the fail from? Dec 17 12:15:40 git log --pretty=fuller says that author==committer==SoB too. Dec 17 12:18:21 KanjiMonster: is that perhaps something that is only picking up from PRs? so anyone working with git directly can't get the circle ci to "approve" anything? Dec 17 12:26:41 ldir: stintel: kernel bumps for master pushed. Dec 17 12:26:54 stintel: can I request you once again for testing 4.9 on bcm2708? Dec 17 12:27:54 hauke: i'll wait a bit bumping 4.19 as there are no targets present currently (probably until after the branch) and it should avoid people having to rebase multiple times. agreed? Dec 17 12:30:37 is branching going to happen soon ? Dec 17 12:31:19 xback: currently doing a round of gentoo updates on my build box, I can test after that Dec 17 12:36:30 stintel: much appreciated :) Dec 17 12:37:29 should have started those updates before leaving for the weekend :/ Dec 17 12:40:55 * ldir builds :-) Dec 17 13:05:39 blogic: pong Dec 17 13:06:03 blogic: https://cyhour.com/wp-content/uploads/2018/06/777-hc5661a.png Dec 17 14:10:01 ynezz: I want to have an additional look at the layerscape pull request Dec 17 14:10:09 I was bussy with uther stuff lately Dec 17 14:10:52 xback: fine with me if you leave out 4.19 for now Dec 17 14:12:39 * mamarley tried to build ath79 with 4.19 a while back and was able to update all the patches and get them to apply, but ran into an issue with the kernel timer API in ag71xx that he couldn't resolve. Dec 17 14:39:54 Checkout this :D https://github.com/openwrt/openwrt/pull/1635 Dec 17 14:41:00 gch981213: You've tested that? Dec 17 14:41:01 Hauke: Ok, thanks, I'll ping you via GitHub once it passes all build tests and hopefuly at least one independent run test Dec 17 14:41:29 mamarley: I'm going to build test it now, and run test it later today Dec 17 14:42:03 BTW why is that name show as a star in my IRC client? I don't know how to type that :( Dec 17 14:42:42 it's caused by /me command Dec 17 14:42:45 * ynezz too Dec 17 14:44:40 mamarley: Yes. Build & runtime tested on my AR9344. Dec 17 14:45:20 But as the to-do said, there is one patch that I haven't bumped yet. Dec 17 14:45:51 Cool, I'll give it a shot on my QCA9563. I actually did bump that patch in my previous attempt. Dec 17 14:46:21 (However, I don't have serial on this device, so if it does brick, I can recover it with TFTP, but I won't be able to tell exactly what happened.) Dec 17 14:49:04 movi, here Dec 17 14:49:30 ynezz: Ah. I thought that star was someone's nickname :D Dec 17 14:49:45 greearb: hey, any idea why 2.4Ghz would crash periodically on ct-full ? 9980 Dec 17 14:50:28 this is on -11. I see you've uploaded -12, but see no changelog Dec 17 14:50:30 is this with the new firmware, or older stuff? Dec 17 14:50:35 this is 10.4b Dec 17 14:51:00 ok, that is the new stuff...please grab the dmesg log of the crash and open a bug for me. Dec 17 14:51:04 i left a bug on github, but that was one wonky client, i since got rid of it, but there are still crashes and i didn't save them :/ Dec 17 14:51:21 greearb: yeah i will :) Dec 17 14:51:25 unless -12 fixed it Dec 17 14:52:13 greearb: i'll add it to this one https://github.com/greearb/ath10k-ct/issues/45 Dec 17 14:52:22 in general, -12 (b) fw seems slightly less stable in our testing, but it fixes other bug reports, and it is the way forward I think. Dec 17 14:52:58 :F Dec 17 14:58:40 gch981213: FYI while compiling your 4.19 for ath79 (all kmods) with current master I need to configure some ULPI mods in Kconfig Dec 17 15:01:04 USB_DWC3_ULPI, PHY_QCOM_USB_HS, PHY_QCOM_USB_HSIC, PHY_TUSB1210 to be exact Dec 17 15:05:40 * gch981213 took some notes on his to-do list :) Dec 17 15:38:54 gch981213: Seems to work on my UAP-AC-PRO, along with the updated unaligned access patch from me. I will get that to you later so you can include it. Dec 17 15:42:20 (Oh, and also bumped to 4.19.10.) Dec 17 15:48:39 what's the image size difference between 4.14 and 4.19 ? Dec 17 15:49:55 ynezz: I didn't calculate it exactly, but somewhere between 100KiB and 200KiB. It wasn't problem for my 16MB device. Dec 17 15:53:12 ynezz: It seems that those kconfig needs to be handled by package/kernel/linux instead. Dec 17 15:58:18 mamarley: Would you mind to create a mbox patch for unaligned_access_hacks.patch so that I could apply it to my PR with git am? Dec 17 15:59:00 How about I just send you the file and you can drop it in? Dec 17 16:05:49 mamarley: That's OK, too. and I'll include your name in commit message :) Dec 17 16:45:38 build #1131 of ipq806x/generic is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/1131 blamelist: Karl-Felix Glatzer , Petr ?tetiar , Yousong Zhou , Christian Lamparter , Rafa? Mi?ecki Dec 17 16:45:38 , Kevin Darbyshire-Bryant Dec 17 16:46:31 I can't be blamed for upload failures surely :-) Dec 17 16:50:08 so is ath10k still a minefield of terribleness? Dec 17 16:50:25 I was looking at something like... https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wpa8630 Dec 17 16:50:31 suggestions welcome Dec 17 16:50:50 obviously a powerline adapter with POE and passthrough AC would be better, but they don't exist Dec 17 16:51:24 jwh, ath10k-ct is working pretty good for lots of folks I think, but there are still bugs to fix. Dec 17 16:51:56 hm Dec 17 16:53:28 *p0 Dec 17 16:53:31 oops Dec 17 16:53:33 'lo Dec 17 16:53:51 are there any powerline devics (non wifi even) that can run openwrt? Dec 17 16:54:01 would be nice so I can do sensible tagging and stuff Dec 17 16:54:57 jow: hi Dec 17 17:10:54 xback: Linux OpenWrt 4.9.146 #0 Mon Dec 17 16:42:19 2018 armv6l GNU/Linux Dec 17 17:21:01 jwh: there's at least one device, devolo something or other iirc, that's in the hardware builds now, it has the openplc utils package selected in it's default buildout. no experience with it. Dec 17 17:21:15 sigh, another (in)securtiy hype Dec 17 17:21:23 karlp: hmmmm Dec 17 17:21:28 this time we're all gonna die because mips Dec 17 17:21:32 jow: oh? Dec 17 17:21:33 https://openwrt.org/toh/devolo/devolo_dlan_pro_wireless_500_plus Dec 17 17:21:55 this one caught my eye Dec 17 17:21:56 https://openwrt.org/toh/devolo/devolo_dlan_pro_1200_wifi_ac Dec 17 17:22:03 I'm unsure if thats the right photo, though Dec 17 17:22:11 yeah, no experience whatosever with them though sorry Dec 17 17:22:21 so far i haven't found one with pasthrough *and* wifi, they're usually one or the other Dec 17 17:22:35 I want some non-wifi ones too, but gotta have openwrt on :D Dec 17 17:22:54 these ones I just had delivered are the Gigle based ones, not qualcomm (so crappy interop anyway with my existing ones) Dec 17 17:23:07 even though the Gigle (broadcom now) ones are *fast* Dec 17 17:23:14 jow: referencing the security paper? Dec 17 17:23:14 always been better than the atheros ones Dec 17 17:23:34 karlp: thanks though Dec 17 17:24:09 they all look pretty similar design, so maybe reference? powerline phy on switch port, some sort of bus to talk to the chip Dec 17 17:24:20 but only on the wifi ones, the non-wifi ones seem to run braindead firmware Dec 17 17:24:22 mangix: https://cyber-itl.org/assets/papers/2018/Linux_MIPS_missing_foundations.pdf Dec 17 17:26:07 i went through readelf and /proc/self/maps and found similar results Dec 17 17:26:49 this can only be a good thing. I know several people that have fun with OEM firmware Dec 17 17:27:00 hmmm Dec 17 17:27:02 I don't expect it to have any conequence Dec 17 17:27:15 it'll maybe accellerate the shift to arm a bit Dec 17 17:27:44 is it of any real consequence for embedded devices with no user access? doesn't seem to be from a skim of the paper Dec 17 17:27:56 jwh: no Dec 17 17:28:12 thought not Dec 17 17:28:27 aslr / dep are weaker than they could be (or have no effect at all) due to the predictable location of an executable stack segment Dec 17 17:28:36 yeah Dec 17 17:28:43 it still requires an exploit / overflow / ... Dec 17 17:28:47 yup Dec 17 17:29:00 I thought I may have missed something obvious but guess not Dec 17 17:29:07 have alsr realllly been "standard" on desxktop linux for 15+ years like they claim too? Dec 17 17:29:37 karlp: it's been available for that long Dec 17 17:29:37 hasn't been that long, surely? Dec 17 17:29:55 karlp: marketing. it has to be shocking, groundbreaking, astonishing and utterly surprising Dec 17 17:30:06 why do they call it DEP instead of NX like everyone else too? Dec 17 17:30:10 still waiting for the name Dec 17 17:30:15 cause windows Dec 17 17:30:16 probably coz MS called it DEP Dec 17 17:30:16 like mipsgeddon.org Dec 17 17:30:22 jow: haha I was just about to say that Dec 17 17:30:25 its missing a buzzword name Dec 17 17:30:31 actually NX is intel specific Dec 17 17:30:36 domain, tshirts, mugs Dec 17 17:30:42 all the merchandise Dec 17 17:30:51 heh, "-20 points for not being 64 bit" Dec 17 17:30:56 just because. Dec 17 17:31:02 amd calls it XD. others...who knows Dec 17 17:31:04 it says that? Dec 17 17:31:21 https://cyber-itl.org/about/methodology/#safety-features has that they assign -20 points to each missing item form the list Dec 17 17:31:27 and one of the the items is being 64 bit. Dec 17 17:31:34 due to the larger adress space I guess Dec 17 17:31:57 because the properties of alsr on an 32bit address space are debatable to begin with Dec 17 17:32:23 well, more relevantly to our own project, is anyone interested in bumping openssl? :) Dec 17 17:32:46 karlp: Hauke wanted to look into it Dec 17 17:33:16 it will break all installed binary packages in the process unless we somehow mass-bump the pkg-release of all openssl simulatneously Dec 17 17:33:24 *all openssl users Dec 17 17:33:33 np, the cve doesn't look very interesting anyway, just with the amount of packages that we manage to keep on the bleeding edge, it was a little odd to see how "old" the last version of openssl was. Dec 17 17:35:41 I wonder if we should add a separate openssl package Dec 17 17:36:18 like libopenssl1.1, then make packages that are prepared for it depend on +libopenssl1.1 instead of +libopenssl Dec 17 17:36:40 then eventually drop the old libopenssl Dec 17 17:38:00 pretty much what other distros did Dec 17 17:38:03 makes sense Dec 17 17:38:55 most annoying part will be avoiding (dev-)header conflicts Dec 17 17:39:24 would have to build either the 1.1 or the 1.0 packages against a seperate include dir Dec 17 17:39:47 sucks either way heh Dec 17 17:40:03 the other idea I had was to start building .ipk control files with a version constraint along with the library dependency Dec 17 17:40:59 like pegging the e.g. +libopenssl dependency to the ABI_VERSION tag used at the time of building Dec 17 17:41:39 then have each library also provide a virtual libxxx-$(ABI_VERSION) packages can depend on Dec 17 18:39:31 jwh: about ath10k. when it works, it's alright, but there's always a gotcha. like the chip crashing. and it's not ben's fault, his firmware actually works better than stock, but the whole thing is still f*cking frustrating Dec 17 18:39:49 is it just crappy hardware? Dec 17 18:40:10 or do the vendors who shell out for NDAs etc get better firmware? Dec 17 18:40:38 jwh: i wou;dn't know. ask ben. but i'm so frustrated at this point i'm thinking about throwing it out the window and getting some closed-source piece of crap like a ubnt. The problem is there's no other thing that has the speed and works stable Dec 17 18:40:52 MTK's go only up to 867MBps Dec 17 18:42:38 everything was fine when ath9k was the standard and you couldn't get faster than .n Dec 17 18:42:45 heh Dec 17 18:43:09 honestly I'm not even bothered about the throughput, I still use a unifi UAP (11n) Dec 17 18:43:22 but newer devices seem to have ath10k Dec 17 18:43:28 or MT, but I'm not touching that Dec 17 18:44:02 well, what else is there to shill that's supposed to be good? Broadcom? Marvell? Dec 17 18:44:25 I'm sure all 4 vendors are just fine with their special sauce drivers Dec 17 18:44:34 seems like with .ac you can either go bad or worse Dec 17 18:44:40 as evidenced by all the devices that work fine on stock firmware Dec 17 18:44:46 The UAP-AC-PRO actually works quite well with OpenWRT if you use ath10k-ct. Dec 17 18:45:02 what about the lite? Dec 17 18:45:08 it's still ath10k Dec 17 18:45:09 or is that not qca? Dec 17 18:45:57 jwh: I haven't tried that one, but the chipset is similar, so I imagine it would probably work about the same. Dec 17 18:46:10 ah cool Dec 17 18:46:12 i could reflash both my ac2600, but one is used as a DVB tuner, and the other does ipv6 to he.net Dec 17 18:46:36 I'm still debating whether I bother with replacing my unifi aps or not Dec 17 18:46:48 or just get one of those tp link powerline adapters with wifi and chuck openwrt on them Dec 17 18:47:03 powerline is crap, barely above 100mbps Dec 17 18:47:07 if even that Dec 17 18:47:11 ^ Dec 17 18:47:15 its only as good as your wiring, yeah Dec 17 18:47:35 but the broadcom chipsets are actually pretty good (no surprise there, they're good at dsl too) Dec 17 18:47:38 And the throughput can drop significantly if the adapters aren't connected to the first outlet in the daisy-chain. Dec 17 18:47:49 was Gigle, then broadcom bought them Dec 17 18:48:04 I originally bought a pair of their first 1G adapters because the name was funny Dec 17 18:48:13 :D Dec 17 18:49:07 but uh, they were several times as fast and reliable as the atheros of the time Dec 17 18:49:13 AR6400 I think then Dec 17 18:49:26 and they did relaying/mesh stuff Dec 17 18:50:05 can some one push it https://github.com/openwrt/openwrt/pull/1590 ? Dec 17 18:50:06 I m waiting more than 2 weeks Dec 17 18:59:14 jwh: sadly vendors still don't use ath10k, so it's not just the firmware which differs between OEM and OpenWrt, but also the driver (closed source ath_pci) Dec 17 18:59:41 and that won't change with the ax stuff either Dec 17 18:59:50 yeah Dec 17 19:00:06 it's just pure idiocy Dec 17 19:00:28 if they don't wanna disclose their secret sauce (what secret sauce?) then they could just do fullmac like broadcom :D Dec 17 19:00:33 I'm pretty happy with QCA9984 and ath10k (and newest QCA firmware) though Dec 17 19:00:49 don't they run complete linuxes on some radios nowadays and communicate with them using an http rpc api? At least I think this was the case for quantenna Dec 17 19:00:57 ath10k is pretty fullmac'ish anyways (and so is mwlwifi) Dec 17 19:01:06 ah Dec 17 19:01:11 I still dislike the idea of fullma Dec 17 19:01:12 c Dec 17 19:01:16 maybe I'll stick with ath9k Dec 17 19:01:33 jwh: range and throughput are undeniably better with ac Dec 17 19:01:42 yeah of course Dec 17 19:01:52 but I don't really need either Dec 17 19:02:06 smaller apartment now, still don't use much on wifi Dec 17 19:02:25 if I need decent connectivity I cable it, call me old fashioned or something Dec 17 19:03:49 hm, ftdis webshop is kinda expensive Dec 17 19:03:52 my last usb uart died Dec 17 19:03:59 I wired my house with Ethernet for that reason. In fact, the only reason I upgraded from the UAP to the UAP-AC-PRO is because my parents are building a new house and I didn't want to install obsolete WAPs in a brand-new house, so I upgraded my own first to make sure it wouldn't be too crashy. Dec 17 19:04:24 well I don't particularly like wifi anyway, it's a convenience but I don't rely on it really Dec 17 19:04:58 * mamarley neither; mine is used only for my phone. Dec 17 19:05:09 pretty much Dec 17 19:05:13 phone and laptop, thats it Dec 17 19:05:48 but uh, ssh and web browsing doesn't tax wifi so much... I only moved from 11g a couple of years ago at most Dec 17 19:06:04 DG834GT :D Dec 17 19:06:26 special kind of witchcraft to install things in the right order so the ath5k drivers fit on the flash Dec 17 19:09:11 so that's 2 nights in a row I've been stuffed by trusting commits Dec 17 19:10:50 :( Dec 17 19:14:47 Hello ynezz Dec 17 19:15:03 Regarding gpio pinctrl and the mail to mailing list Dec 17 19:15:23 I dunno about documentation Dec 17 19:15:43 That was just what I gathered during testing. It was the only way to get it to work. Dec 17 19:16:40 ldir: what did you broke this time? :D Dec 17 19:17:23 I'll be back in a minute after a flash/reboot and prove the fix is a fix - but for clues....look at netifd repo ;-) Dec 17 19:18:16 nasty one Dec 17 19:18:17 did I do it? Dec 17 19:18:25 jwh: dave taht did Dec 17 19:18:31 oh, excellent Dec 17 19:18:34 :) Dec 17 19:18:34 :D Dec 17 19:19:39 greearb: are you interested in firmware crash dumps? Dec 17 19:20:06 greearb: a user on the forum complained about ath10k-ct being way unstabler compared to ath10k and provided these logs: http://sprunge.us/IXXDs7 Dec 17 19:20:38 greearb: I wonder how much of this is due to increased debugging prints compared to vanilla 10k Dec 17 19:21:04 * ldir is back Dec 17 19:21:25 And? Dec 17 19:21:31 Is the fix a fix? Dec 17 19:21:45 nothing has obviously exploded :-) Dec 17 19:21:54 heh Dec 17 19:22:13 and I have ipv6 still Dec 17 19:23:04 and today's lesson is.... don't trust a single line of anyone's commit, no matter who it is! Dec 17 19:26:15 * Borromini starts going through ldir's commits Dec 17 19:26:34 Well, didn't jow say yesterday it's ok if a commit blows up in your face, fix it after? Dec 17 19:27:07 Checking every line of every commit can be exhausting I reckon Dec 17 19:27:33 i reckon it's tongue in cheek micmac1 Dec 17 19:28:02 I didn't take it totally serious Dec 17 19:28:04 it's embarrassing and suggests that inadequate testing done by either provider or me as the committer. Dec 17 19:28:44 so it was not tongue in cheek after all ;-) Dec 17 19:28:59 and it's always the simplest commits that do silly things. Dec 17 19:30:55 still, in the end, no harm done....but we could have had a simpler path to that point :-) Dec 17 19:38:41 i still think offenders should be hanged though Dec 17 19:38:44 or quartered, at least Dec 17 19:39:14 Then there wouldn't be any developers left because you would have killed them all! Dec 17 19:40:11 fair point. Dec 17 19:40:36 * Borromini withdraws the motion Dec 17 19:44:09 lol Dec 17 19:46:54 going to bisect the performance regression I'm seeing since some months with sqm-scripts Dec 17 19:46:58 ldir: git log --oneline | grep -i revert | wc -l == 480 Dec 17 19:47:12 ldir: no worries, happens to all of us Dec 17 19:49:12 greearb_: I spotted a small bug in ath10k-ct 4.19. On https://github.com/greearb/ath10k-ct/blob/master/ath10k-4.19/pci.c#L3824, it says 4.16 but it should say 4.19. Dec 17 19:58:45 micmac1: since everything is moving to dts (even u-boot) Dec 17 19:59:06 yeah? Dec 17 19:59:17 it should be working as described in the docs and if not, it should be fixed (sorry pressed enter too fast) Dec 17 19:59:56 anyone here running OpenWRT in a VirtualBox VM with ipv6 enabled? Dec 17 20:04:49 ynezz: honestly for me it was just trial and error Dec 17 20:05:11 ynezz: but maybe you can use pinctrl-0 and pinctrl-1 together Dec 17 20:05:35 ynezz: see /usr/src/linux/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt Dec 17 20:06:05 yeah, that's what I was trying to express in that email Dec 17 20:06:41 ynezz: looks like pinctrl-names is a list, and if you specify more than just "default" (n list entries), you might be able to get away with n pinctrl-x entries. Dec 17 20:07:29 But I didn't try (I didn't now back then that pinctrl-names could be important) Dec 17 20:07:37 *know Dec 17 20:07:42 https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/dra7-evm.dts#L367 Dec 17 20:08:05 Exactly Dec 17 20:08:23 pinctrl-names is mandatory property, so you've to use it Dec 17 20:08:42 Yes, but I didn't know until 4 mins ago that it's a list :) Dec 17 20:09:18 Luckily for my dts I needed only pinctrl-0 :-) Dec 17 20:09:42 Maybe we should let Roger now? Dec 17 20:10:20 *know Dec 17 20:10:42 I'm gonna ping him via the list Dec 17 20:11:06 oh, it wasn't clear from my email? Dec 17 20:11:49 Not to me :) Let me read it agian. Dec 17 20:13:20 Yes, now I see it. But the fact that you didn't explicitly wrote about pinctrl-names made be overlook that you had two items in there. Dec 17 20:13:55 You think it's OK if I reply to make that clear? Don't know if Roger saw it. Dec 17 20:14:38 Ah, forget about it, I'm too tired rn Dec 17 20:14:42 :) Dec 17 20:15:29 well, I've had crossed eyes as well Dec 17 20:15:42 pincrtl-names is not mandatory property Dec 17 20:20:46 Well it seems optional in case you don't want to use pinctrl-x Dec 17 20:21:06 Might was well read that as mandatory, then, in the opposite case :) Dec 17 20:21:10 I'll ping him Dec 17 20:25:08 micmac1: no, it will just use pinctrl-x as the name Dec 17 20:25:18 https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/devicetree.c#L236 Dec 17 20:25:53 if the pinctrl-names for index X isn't found, just use pinctrl-X as statename Dec 17 20:26:24 so using pinctrl-0, pinctrl-1 without pinctrl-names is valid usage Dec 17 20:27:00 you just always need to start from index 0, pinctrl-0 and then you can add more if needed, but you can't start from index 1, pinctrl-1 Dec 17 20:28:31 documentation written by developers always sucks :) Dec 17 20:30:32 mamarley, thanks, I'll fix that Dec 17 20:31:43 jow, those are firmware crashes, and logs should not cause it. I'll have to check to see if that is recent FW or not....you think it is just from this latest FW update? Dec 17 20:33:16 yeah, that is recent one...I'll attempt to decode the crash Dec 17 20:36:29 micmac1: ynezz: these pinctrl states are exclusive; you can switch between them, but not have more than one active at the same time: https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/core.c#L1224 Dec 17 20:40:36 KanjiMonster: thanks, good to know Dec 17 20:41:33 I've hopefully provided a valid advice and example to him https://github.com/openwrt/openwrt/pull/1623#issuecomment-447180644 Dec 17 20:41:51 anyway it seems like he has sorted it out Dec 17 20:43:15 So in case you have multiple phandles (like &jtag_disable_pins and &enable_gpio_11) that you want activated on boot, you need to list them in pinctrl-0? Dec 17 20:46:09 yes Dec 17 20:46:28 ok Dec 17 20:46:36 Let's leave it at that :-) Dec 17 21:25:04 when trying to build 4.19 with all kmods for ath79 in verbose mode, I'm being asked about new module/symbols not being found in kernel config files so I've added those modules to generic config and now it seems to be going https://paste.ubuntu.com/p/kxJRh4w2G2/ Dec 17 21:25:27 how do I refresh that generic kernel config to get the symbols in proper order? Dec 17 21:31:18 ynezz: scripts/kconfig.pl Dec 17 21:33:20 thanks Dec 17 21:34:43 np Dec 17 21:35:11 jow: Hauke: I noticed you were discussing 18.02.x release Dec 17 21:35:26 jow: Hauke: i've noticed regression in USB 2.0 support on bcm53xx Dec 17 21:35:48 jow: Hauke: i'd like to fix that, I spen half day on that today Dec 17 21:40:17 rmilecki: I haven't started to look at 18.06.2 yet ;-) Dec 17 21:40:27 good :P Dec 17 21:40:28 ynezz: have a ook at 42e62a8a10c8276ba09434f88dc08f0967ba7bb1 Dec 17 21:40:33 *look Dec 17 21:44:23 thanks, that's what I did after I got strange parse error :) Dec 17 21:47:35 Hauke: http://paste.ubuntu.com/p/pV9gkd7Hw6/ Dec 17 21:47:43 wondering if that's ok Dec 17 21:54:28 I would prefix the subject with kernel rather than generic Dec 17 21:55:40 danitool: found the issue, will push a fix tomorrow or so Dec 17 21:55:56 and write what the patch does, not "that it fixes it for your" Dec 17 21:56:10 like "Add missing symbols to the generic 4.19 config to fix this" Dec 17 21:56:35 but you could call that nitpicking Dec 17 21:58:16 hm, that's what the subject says Dec 17 21:59:06 ynezz: search `git log` for "missing symbols" Dec 17 21:59:14 and do something similar ;-) Dec 17 21:59:53 hm, I did git log target/linux/generic/config* Dec 17 21:59:59 in this case, subject might as well be "kernel: add missing symbols for 4.19" without further commit message :) Dec 17 22:00:40 yes, like that commit from you :) Dec 17 22:01:12 if I'm not sure I tend to look at previous commits Dec 17 22:01:46 yes, doing same, but just couldn't find similar example fast Dec 17 22:02:00 pffft, bisecting the sqm-scripts issue I'm having is giving me a headache Dec 17 22:02:56 in general, keep subject as short as possible Dec 17 22:03:13 so you could drop the word "few" which doesn't add any value to the subject Dec 17 22:03:54 if needed, elaborate in the rest of the commit message, but for this one you might as well just have the subject Dec 17 22:03:57 jow, where is the link to the forum post for that crash link you put in IRC? I think I have a fix for one of the crashes. Dec 17 22:04:11 in general, we know the "missing symbols" problem ;-) Dec 17 22:07:44 hi Dec 17 22:07:58 so what is the current way to push to the master packages repo? Dec 17 22:08:01 i still get Dec 17 22:08:02 ! [remote rejected] master -> master (protected branch hook declined) Dec 17 22:08:48 @ nbd Hauke Dec 17 22:09:03 wigyori Dec 17 22:10:09 how about switching to signed commits instead of this "security by obscurity protection" Dec 17 22:13:58 tripolar: yeah, thess opened up 1806, but master is still "locked" Dec 17 22:15:48 no updates on https://github.com/openwrt/packages/issues/7624 Dec 17 22:18:16 karlp: best idea, let's lock out the people that update the apps ;) Dec 17 22:27:48 I have complete faith that thess will fix this, Dec 17 22:27:58 clearly no-ones intent was to lock out package maintainers Dec 17 22:30:28 karlp i know :) Dec 17 22:34:59 i would still prefer to host only mirrors on github Dec 17 22:35:50 with mandatory signed commits Dec 17 22:50:02 stintel: seems ok http://paste.ubuntu.com/p/tPY2w4BR2R/ ? Dec 17 22:50:24 ynezz: just ent you an email Dec 17 22:50:28 *sent Dec 17 22:56:39 ynezz: looks good Dec 17 22:58:50 tripolar: which URL are you using? I use this one: git@git.openwrt.org:openwrt/openwrt.git Dec 17 22:59:17 MIPS r6 ISA will be open sourced: https://wavecomp.ai/mipsopen Dec 17 22:59:55 mips probably would like to compete with RISC-V ;-) Dec 17 22:59:59 Hauke: r6 is interaptiv > Dec 17 23:00:06 ? Dec 17 23:00:10 no it is 2 generation later Dec 17 23:00:19 r3 is interaptiv Dec 17 23:00:54 MIPS r6 is also not fully backwards compatible as far as I know Dec 17 23:01:41 Hauke: i use git@github.com:openwrt/packages.git Dec 17 23:02:19 tripolar: I think you have to push the packages to github and then they get mirrord to git.openwrt.org Dec 17 23:03:08 pushing to github shows Dec 17 23:03:10 remote: error: GH006: Protected branch update failed for refs/heads/master. Dec 17 23:03:13 remote: error: Required status check "DCO" is expected. Dec 17 23:03:14 ! [remote rejected] master -> master (protected branch hook declined) Dec 17 23:03:38 tripolar: do you have a Signed-off-by line? Dec 17 23:03:44 yes Dec 17 23:14:36 i did a new checkout and now it worked Dec 17 23:16:47 @Hauke Dec 17 23:19:24 tripolar: hmm strange Dec 17 23:48:33 WARNING: Image file linux-ipq40xx/netgear_ex6100v2-fit-uImage.itb is too big (4.19) miss fatty! Dec 17 23:57:05 anyone testing the new ath10k-ct firmware for 9984, please consider trying the binary I attached to this bug: Dec 17 23:57:09 https://github.com/greearb/ath10k-ct/issues/46 Dec 18 00:07:03 ynezz: it fails there? Dec 18 00:08:37 yep, 3MB is not enough :) Dec 18 00:08:41 I can take a look if we need the pad-to kernel-size at all. It was a leftover which we might be able to kill. Dec 18 00:09:04 had some troubles with the DNI image validation from the stock firmware iirc. need to recheck those. Dec 18 00:09:40 blocktrron: nice, please check https://github.com/openwrt/openwrt/pull/1643 Dec 18 00:49:58 gch981213: Here's a link to unaligned access patch that I updated: https://michaelmarley.com/downloads/misc/910-unaligned_access_hacks.patch Dec 18 01:03:19 oh. MIPS going open source: https://wavecomp.ai/wave-computing-launches-the-mips-open-initiative Dec 18 01:04:54 that looks promising Dec 18 01:12:29 ynezz: cleaned up the dni image generation code. Does not seem to perform a check about kernel size or the current present filesystem fakeheader (atleast on the current netgear firmware) Dec 18 01:12:42 Same story with the pushbutton tftp Dec 18 01:15:15 sparc has been open source (GPL, down to the VHDL) for years now, hasn't really kept it alive either. mips has missed real development for at least 10 years (and I'm generous, more like over 15) Dec 18 01:23:10 One potential difference is that MIPS processors are commonly used in embedded devices like routers while SPARC processors are not commonly used. Dec 18 01:25:10 I'm not so sure about that, even for its common use case today, they are hard at the edge of their capabilities (respectively that of the existing silicon) Dec 18 01:25:51 keep in mind that mips was a highend workstation architecture until ~2000 Dec 18 01:26:02 with (predominantly) SGI Dec 18 01:26:13 so not too different from sparc at all Dec 18 01:27:37 the I/O abilities mips inherited from those times lasted them a long time - but given that there has been close to zero ISA development since then (other than downscaling, making it cheaper and moderate bus updates), there might not be too much use left (without serious investment) Dec 18 01:27:58 nope Dec 18 02:04:45 build #318 of mediatek/mt7623 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7623/builds/318 blamelist: Sebastian Kemper , Mathias Kresin , Hans Dedecker , Kevin Darbyshire-Bryant , Dec 18 02:04:45 Christian Lamparter , Syrone Wong **** ENDING LOGGING AT Tue Dec 18 03:00:00 2018