**** BEGIN LOGGING AT Wed May 30 03:00:02 2018 May 30 03:56:37 morning May 30 03:56:49 moin May 30 04:00:20 y0 May 30 04:42:04 Monkeh: series is good May 30 04:42:12 please fix the usb led trigger inside 4/5 May 30 04:42:20 and resend a V2, i'll merge it no probs May 30 04:51:58 morning May 30 05:51:16 blogic: wifi issue also affects 18.06 as the pci driver updates are there as well May 30 06:06:02 mangix: please write that into the description in future May 30 06:06:15 just a simple "please also apply to 18.06" beneath the tear line May 30 06:06:22 ok May 30 06:07:26 thx ! May 30 06:30:34 oh interesting. my device_type = "pci" removal actually has a side benefit May 30 06:31:31 apparently it means the device is a pci bridge, which in the case of mt76 is bogus May 30 06:34:39 alright, time to post patches and go to bed May 30 06:41:38 hey, what's the ml address for openwrt now? May 30 06:44:39 https://lists.openwrt.org/mailman/listinfo/openwrt-devel May 30 06:53:47 hanetzer:openwrt-devel@lists.openwrt.org **** BEGIN LOGGING AT Wed May 30 07:24:24 2018 May 30 07:41:45 Monkeh: blogic: what series & USB LED trigger you're talking about? May 30 07:41:47 can I get a link? May 30 07:41:56 or e-mail subject? May 30 08:10:55 rmilecki: should be this one: https://patchwork.ozlabs.org/project/openwrt/list/?series=47327&state=* May 30 08:14:52 adding the phy0/phy1* trigger to the dts seams odd to me, as we rely on driver (?) load order to get the correct one. a phandle to the wireless node - similar to the usb trigger binding - seem to me the right way (tm) May 30 08:18:21 rmilecki: would you mind to have a look at https://patchwork.ozlabs.org/patch/922188/. It looks similar to the broadcom partition parser you send upstream May 30 08:25:45 mkresin: will do, thanks for pointing it May 30 09:09:01 suspect it needs an ndb but is anyone else getting ACS failures on MT7603 2.4 wifi ? May 30 09:09:20 interface won't come up unless channel manually selected. May 30 09:10:51 https://pastebin.com/P3k7v7YF May 30 09:17:35 ldir: ath9k? May 30 09:17:39 oh no May 30 09:18:01 no, mt7603e May 30 09:26:51 _lore_: ^ May 30 10:19:26 <_lore_> ldir: I will take a look later today May 30 10:20:09 _lore_: thank you - give me a ping if there's info/stuff you'd like me to check/test May 30 10:20:10 mkresin: imho that part parser patch is bad May 30 10:20:42 <_lore_> ack May 30 10:21:28 <_lore_> ldir: have you tested mt76x2? May 30 10:22:44 mt76x2e is ok for me May 30 10:23:22 this is a MIR3G - mt7603e for 2.4 mt76x2e for 5 May 30 10:24:11 <_lore_> I mean, does ACS work? May 30 10:24:25 yes ACS on 5G is fine. May 30 10:24:39 brbr May 30 10:24:41 brb May 30 10:26:09 <_lore_> ok, thx May 30 10:27:30 Mangix: i am against merging any of your mt7621 backports May 30 10:27:39 anything you posted so far caued huge fallout May 30 10:27:44 i'll mark them as rejected May 30 10:28:16 if you want them merged, post a RFC, get test coverage, document it and then send a new series including the test reports May 30 10:28:28 sorry, the fallout of your recent patches was just too big May 30 10:28:45 and the ath10k fallout shows that you dont even compile test patches at times May 30 10:28:51 :/ May 30 10:29:16 thanks for th dts cleanup though, been on my todo list for a while to do that May 30 10:29:21 need to do the same for ath79 May 30 10:33:37 blogic: fair enough. I'll do testing once I get power back. May 30 10:34:01 cool, thanks May 30 10:34:12 not meant badly, just we need to assure that fallout stays small May 30 10:34:36 and although i try to test as much as i can i cant verify very patch to the last detail May 30 10:34:59 and each of the mt7621 backport patches caused some sort of fallout May 30 10:35:08 i guess it was just unlucky May 30 10:36:28 Right. The MMC stuff was an oddball though since staging removed any non mt7621. May 30 10:37:06 yes, agreed May 30 10:37:16 I'll post again in 5 days May 30 10:37:20 you know my take on it i think its the wrong way to merge the drivers May 30 10:37:28 why is you power gone ? May 30 10:37:57 No idea. As bunch of the WiFi networks around my place are gone too May 30 10:38:10 ok, so on battery now ? May 30 10:38:16 Phone May 30 10:52:37 Blogic: can you cherry pick 9685f39 ? It doesn't make sense for it to be trunk only since it would break sysupgrade May 30 11:03:53 Mangix: done May 30 11:04:34 :) May 30 11:05:19 * ldir is back May 30 11:07:11 Welcome back. May 30 11:08:14 Mangix: so bearing in mind the recent changes/discussion.... how broken should I expect the MIR3G to be ? May 30 11:08:42 * Mangix looks May 30 11:10:10 5ghz shouldn't be working. May 30 11:10:47 Instead of mt76 DTS specifies it as wifi. Oh boy. May 30 11:11:07 and the fact that both 2.4 & 5g are shouldn't deter me or persuade you otherwise ? May 30 11:12:04 hopefully you can understand my confusion :-) May 30 11:12:38 I'm getting mixed reports about this. dissent1's unit has both working, yours has both broken. May 30 11:13:09 no, my unit has both working May 30 11:13:36 2.4G ACS appears to have issues...but I'm thinking/hoping that's a different issue May 30 11:13:58 What was ACS again? May 30 11:14:15 Automatic channel selection? May 30 11:14:20 yes May 30 11:14:29 ¯\_(ツ)_/¯ May 30 11:15:03 ignoring the acs 'maybe' problem - what from a DTS perspective is wrong ? May 30 11:16:17 what can I change & test? May 30 11:16:37 My fix for the others was to get rid of the reg settings since they're already set in mt7621 May 30 11:17:03 The pcie1 is set to 0x0800, not 0x0000 May 30 11:18:04 Those values used to be hardcoded in the driver until the relevant commit May 30 11:18:15 Now they are taken from DTS files May 30 11:18:46 But the fact that it's working for you, ¯\_(ツ)_/¯ May 30 11:19:46 and the bonus fun is that I removed both 'reg = <0x0000 0 0 0 0>;' lines for both pci definitions and ended up with a very unhappy unit. May 30 11:20:29 :). I gtg for now. May 30 11:30:31 mkresin: ping May 30 11:36:41 actually...anyone who can offer some DTS interepretation assistance on https://pastebin.com/xHTBYpca May 30 11:37:50 don't be shy - they're idiot questions honest. May 30 11:48:19 blogic: USB? May 30 11:49:12 * ldir proffers a banana to Monkeh May 30 11:51:41 blogic: oh - the double setting of the wlan LED trigger? That one slipped by. Which do you want, dts or userspace? May 30 11:51:51 Definitely no USB on that board.. :) May 30 11:55:41 dammit. can't even bribe monkeh to have a go at my DTS question May 30 11:57:05 ldir: Oh, I glanced at it - I need to do some heavy duty reading on how the pci sections work - and iirc the documentation is a bit light duty. May 30 11:57:33 ahh, I see May 30 12:55:41 Monkeh: dts May 30 12:55:53 it was wifi not usb, too many patches that i look at, i got confused May 30 12:56:29 ldir: what about that ? May 30 12:56:45 looks like mt76 dts foo May 30 12:56:56 i would guess on a mt7621 SoC May 30 13:02:33 blogic: Trying to figure out what the mt7621 wifi apocalypse was all about May 30 13:05:48 blogic: Errant line removed, dts already had the default trigger set, will resubmit shortly May 30 13:14:16 Monkeh: :-) May 30 13:14:19 its a long story May 30 13:14:27 someone started to upstream the remains of mt7621 May 30 13:14:32 mangix is backporting that May 30 13:14:41 but its not aligned with pending $crap in our tree May 30 13:14:43 thus breaking May 30 13:14:49 blogic: It's a long story but somewhere along the line, mangix. :D May 30 13:14:57 and in this case we did not do proper irq via OF probing May 30 13:15:08 and the pcie driver was 50% of May 30 13:15:23 to make the kernel load we basically gave it all nulled out irq settings May 30 13:15:34 Oh, that reminds me, the usb-phy thing May 30 13:15:43 and then the driver wasfixed and the all null lines needed to be nuked May 30 13:15:49 Keep in mind I know absolutely nothing about the flow of data for kernel drivers May 30 13:15:54 yes, will look into that the next couplke of days May 30 13:16:00 need to do real work today May 30 13:16:05 But with the information coming from OF - shouldn't it be using of_ functions to get the resets, not devm_? May 30 13:16:09 * Monkeh knows nothing May 30 13:16:33 devm_* uses the pdev, populated by the fdt parser base on OF May 30 13:16:41 Okay May 30 13:16:57 pdev->dev.of_node is the OF device node of the platform device May 30 13:17:50 Is there a good reference to these multitudes of functions and structs or is it dig in and try to figure it out? May 30 13:18:12 Just a nice overview of how everything connects would be fantastic May 30 13:19:25 Right, pasty swallowed, launching v2 into the harsh void May 30 13:20:34 Also a couple more May 30 13:25:12 Monkeh: I think disabling CONFIG_SWAP will break the kmod-zram build May 30 13:25:31 jow: Hmm, possible, hadn't looked at that May 30 13:25:35 Monkeh: so you should guard kmod-zram too (maybe with DEPENDS:=@KERNEL_SWAP) May 30 13:25:38 This is why I split that out May 30 13:25:48 I shall test May 30 13:26:15 the rest looks sane to me May 30 13:26:57 I wanted to take sysrq out too but I think that may need more testing, blogic mentioned dark history of possibly fixing some crashes May 30 13:27:06 wonder when we reach the point where disabling printk becomes viable :) May 30 13:27:25 At that point I'll replace the device or at least the flash ;) May 30 13:27:50 iirc sysupgrade used to invoke sysrq as last resort when it was still alive 30s after invoking "reboot" May 30 13:27:58 This is just life support for some still usable little devices May 30 13:28:01 not sure if this is still the case with the modern two stage sysupgrade May 30 13:28:23 I don't expect them to last all that much longer, but I've already put the velcro on the back of this one, I don't want to buy more velcro! May 30 13:29:39 jow: :-) May 30 13:29:40 The block size is a bit harsh on RAM, but I'll take 64K of freed flash for 2M RAM.. May 30 13:30:05 (I think that's about what it came to anyway) May 30 13:31:56 Just me or is the ML reeeaaallllyyy slow at pushing new mail through? May 30 13:33:28 its a high traffic server May 30 13:34:46 jow: It.. did actually build the module May 30 13:35:47 Probably won't work, though May 30 13:36:48 jow: Looks like zram does not actually depend on swap at all May 30 13:38:07 hmm, I know that zram did fail to build on a target that accidentally had "# CONFIG_SWAP is not set" in its config May 30 13:38:26 or rather not fail to build (kbuild simply skipped it) but fail to package May 30 13:38:35 package/linux failed because zram.ko was no there May 30 13:39:12 I have a bin/targets/ath79/tiny/packages/kmod-zram_4.14.44-1_mips_24kc.ipk freshly built May 30 13:39:24 In the mainline kernel it does not have any swap dependency May 30 13:40:26 zram-swap should probably have that dep added, though. May 30 13:46:09 blogic: sorry was AFK - question is reg = <0x0000 0 0 0 0>; in the example case definiing the registers for that device on that pci bus (which is what I'd expect) or defining the register of the pci bus itself? May 30 13:47:05 background is that there's been a certain amount of recommending to nuke reg DTS lines..... without a lot of context. I'm trying to understand the context May 30 13:49:39 jow: Yes, looks like sysrq is still used as a last ditch May 30 13:50:32 Shame, that's another ~2K.. :P May 30 13:56:33 So while we're on the subject of saving bytes, is anything other than zabbix using CONFIG_PACKAGE_MAC80211_DEBUGFS quietly? May 30 13:56:39 Because that's a fat one, too. May 30 13:57:32 ath9k / ath10k depnd on debugfs stuff iirc May 30 13:58:55 That's unfortunate. May 30 14:02:36 isn't it ath10k_ct ? May 30 14:03:25 Looks like it optionally uses it, doesn't seem to depend on it May 30 14:04:34 It's a good space saving, and I can't say I care about zabbix on a 4/32 device, but I'm not sure if anyone is abusing debugfs without depending on it May 30 14:04:40 build #848 of rb532/generic is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/rb532%2Fgeneric/builds/848 blamelist: Hans Dedecker , Rosen Penev May 30 14:40:17 As long as stuff gets fixed, I'm happy :) May 30 14:40:51 Power at my house came back, brb May 30 14:41:47 apparently some guy hif a pole in my neighborhood and took out the power May 30 14:41:53 *hit May 30 14:50:54 build #844 of mpc85xx/p1020 is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/mpc85xx%2Fp1020/builds/844 blamelist: Hans Dedecker , Rosen Penev May 30 15:01:01 ldir: its the dummy regs that break pcie May 30 15:01:05 just drop the line May 30 15:01:55 what would it take to update to a still-maintained version of lua ? May 30 15:02:07 dwmw2_gone: rewriting LuCI May 30 15:02:19 it's changed that much? May 30 15:02:21 yes May 30 15:02:24 joy May 30 15:02:33 5.2, 5.3 etc. are incompatible to 5.1 May 30 15:02:43 jow: Oh, so it's python all over again. May 30 15:02:50 they changed fundamental things like block scoping May 30 15:03:03 and function environment May 30 15:03:05 ...s May 30 15:03:40 so most of LuCIs sandboxing would fail if Lua is bumped from 5.1 May 30 15:04:05 it needs to be rewritten to use the hideous new block env syntax (or take tha lazy way out and map setfenv() to debug.setfenv()) May 30 15:04:16 but relying on debug apis for production code feels wrong May 30 15:05:18 in any case this is a larger endeavour... something in the 4..8 weeks ballpark May 30 15:11:56 blogic: erm, except if I remove those then both wifi stop working May 30 15:24:24 * ldir tries something...well will do when the build finishes May 30 15:26:55 still 17.01.4? May 30 15:26:58 :-) May 30 15:31:38 pelight has a stfenv wrapper thing, but its a fairly large dependency :) May 30 15:33:17 karlp: the thing is there is no working setfenv replacement that does not use the debug api in one way or another May 30 15:33:26 its just different amounts of sugar coating on top May 30 15:34:03 the way I understood it the entire setfenv using code needs to be restructured, probably using a function factory pattern May 30 15:38:22 build #873 of ar71xx/nand is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Fnand/builds/873 blamelist: Hans Dedecker , Rosen Penev May 30 15:40:23 * ldir pulls the trigger on that test ADSL line. May 30 15:40:36 does anybody here use igmpproxy? May 30 15:42:43 I get this error in the logs, but I don't know what it means: MC-Router API already in use May 30 15:43:09 jow yar iwasnt really serious. i know how nuts it is trying to þulti lua env stuff May 30 15:43:39 i have enough pain with 5.1+lnum vs 5.1 vs 5.3 withiut anybfenv stuff :) May 30 16:32:12 * ldir gets frustrated again with the mir3g May 30 16:38:38 ldir: totally horrible idea: swap the values May 30 16:38:55 also horrible idea, shift by 2 May 30 16:38:58 *1 May 30 16:39:20 ldir: Take video of the swearing 'engineers' May 30 16:39:55 well here's the thing - if I make no changes to the DTS then it all works. May 30 16:40:57 but if I remove the reg parameters then the unit hangs just after the mt7603e firmware init done. May 30 16:41:16 and what really disturbs me about that is....... where's the watchdog? May 30 16:41:50 :D May 30 16:42:07 so it's going in the bin. I have no time for this crappy hardware anymore. May 30 16:42:43 ...what's wrong with it? May 30 16:44:08 well no watchdog is a bad move - it'll never reboot. May 30 16:45:06 I suspect the W2914NSV2 & ZBT-WG3526 are similarly shit May 30 16:45:23 just do a grep 7603 in the dts dir. May 30 16:45:24 ummmm May 30 16:45:51 so you're saying if you run halt, thr router will reboot? May 30 16:46:05 I've no idea May 30 16:46:33 what I'm saying is that the system has hung on doing a wireless init and hasn't rebooted due to watchdog timeout. May 30 16:46:59 oh that's the problem? May 30 16:47:11 that's A problem. May 30 16:47:53 but that's caused by a few people saying take the reg parameter out of DTS for the wifi. May 30 16:49:15 ok so the DTS for the MIR3G is different than the patched DTS files May 30 16:49:50 it uses wifi instead of mt76. i don't know what the implication is May 30 16:52:35 are you sure that the reg parameters are supposed to be removed? May 30 16:52:47 the way I understand it they got removed where faulty May 30 16:52:57 any way. if you're really going to toss it, toss it my way :) May 30 16:53:13 if they are defined but non-zero then probably for a reason May 30 16:54:18 jow: i maintain copy/paste error May 30 16:55:54 well, more like someone had a hard timr differentiating between 8 and 0 May 30 17:00:02 https://pastebin.com/099z9f9m May 30 17:04:48 'cos the regs mentioned under the wifi@14c3, 7603 node strike me as being a completely different set of regs as mentioned in the pcie0 device node.. They are a sub-device shirley? May 30 17:14:32 ldir: they are. i still don't get why you're changing them May 30 17:16:18 right, okay, so there is no copy paste error here. May 30 17:33:12 Hello! Anybody can tell me if it is possible to merge branches https://github.com/garywangcn/bpi-r2_lede and Lede to support BPI-P2? May 30 17:37:39 build #883 of brcm2708/bcm2710 is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2710/builds/883 blamelist: Hans Dedecker , Rosen Penev May 30 17:53:13 Anybody alive? :) May 30 18:08:46 blogic: ping May 30 18:08:57 build #865 of mpc85xx/generic is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/mpc85xx%2Fgeneric/builds/865 blamelist: Hans Dedecker , Rosen Penev May 30 18:11:40 hello May 30 18:11:53 Have you tried to SSH from Windows 10 to Dropbear? May 30 18:12:02 or nobody here use Win10 ?: ) May 30 18:13:16 xcom: nobody May 30 18:13:26 xcom: Yes, I have. It works fine May 30 18:13:36 It´s a version of OpenSSH May 30 18:13:53 using putty with a smartcard. Works great on Win10 May 30 18:14:03 For me C:\Users\Bélabá>ssh root@openwrt.lan Unable to negotiate with 2a02:XXXX:X01:5c00::1 port 22: no matching host key type found. Their offer: ssh-rsa May 30 18:14:06 I have this error May 30 18:14:20 Do you know how to mitigate it? May 30 18:14:22 A lot of peopla has Wirus 10, terrible May 30 18:14:44 The .ssh directory is on ¨C:\Users\\.ssh¨ May 30 18:15:04 ah, I only tested for IPv4 May 30 18:15:18 luaraneda: Same error on ipv4 May 30 18:15:33 luaraneda: Do you have the latest updatE? May 30 18:15:35 18.04 May 30 18:15:39 or 05 May 30 18:16:18 there is not any ubuntu 18.05, it's only 18.04 :-) May 30 18:16:37 ultito: Lot of things are still not working on Linux May 30 18:16:54 i am flashing my smartphone on 'wirus' 10 as we speak. May 30 18:17:01 then it will be back to teh leenucks May 30 18:17:11 cuz we all know linux is l33t amirite. May 30 18:17:19 you might try e.g. ssh -vv root@openwrt.lan and see which ciphers/kex algorithms are supported May 30 18:17:36 then create a .ssh/config file with openwrt.lan specifying the parameters May 30 18:17:48 reason being is newer ssh has deprecated at lot of stuff for being "insecure" May 30 18:18:03 Hello! Anybody can tell me if it is possible to merge branches https://github.com/garywangcn/bpi-r2_lede and Lede to support BPI-P2? May 30 18:18:13 xcom: I´m running a custom build OpenWRT from may 28. And my windows 10 is insider 1803 May 30 18:19:35 actually it wouldn't be ciphers/kex (though it might be those too). it would be HostKeyAlgorithms that you need to specify i think. May 30 18:19:58 m4t: https://paste.debian.net/1027309/ May 30 18:20:24 m4t: Thanks for the hints. I might try something May 30 18:20:54 xcom: I just testes with IPv6 and it´s working fine May 30 18:21:03 looks like windows10 openssh only does ecc May 30 18:21:20 luaraneda: Thanks! May 30 18:21:37 something about it not linking against libressl https://blogs.msdn.microsoft.com/powershell/2017/12/15/using-the-openssh-beta-in-windows-10-fall-creators-update-and-windows-server-1709/ May 30 18:21:44 (in the comments someone from MSFT responds) May 30 18:22:08 m4t: Yes, it's some kind of SSH 'light' version May 30 18:22:27 OpenSSH without OpenSSL ( maybe it was too hard to crack for NSA ) May 30 18:22:53 lol May 30 18:23:09 did you build openwrt from source? May 30 18:23:25 m4t: No, I'm using the daily build May 30 18:23:30 ah May 30 18:23:47 well, if you want to use windows built-in ssh then you might need to replace dropbear with openssh on the router May 30 18:24:00 OR put a build of dropbear on there with ed25519 support May 30 18:24:38 m4t: but, I´m using dropbear and it´s working for me May 30 18:25:05 luaraneda: Maybe your built in ssh is newer? Could you please send us ssh -vv command? May 30 18:25:11 verbose mode May 30 18:26:01 that microsoft.com link was referencing fall creator's, maybe they fixed it in spring/april May 30 18:26:27 Because I'm using older Fall version May 30 18:26:50 m4t: # ssh -V --> May 30 18:26:50 OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4 May 30 18:27:01 yep May 30 18:27:05 Looks like my build has LibreSSL May 30 18:27:20 luaraneda: C:\Users\Bélabá>ssh -V OpenSSH_7.5p1, without OpenSSL May 30 18:27:37 Your built seems newer, better May 30 18:27:44 faster, stronger May 30 18:27:52 :D May 30 18:27:53 haha, yep May 30 18:27:59 they're going to force you to update to april's update eventually anyhow May 30 18:28:22 m4t: Yes, M$ is naughty May 30 18:29:26 m4t: But they provided a lot of Linux goodies recently. Ubuntu inside of Windows ( not VM ), SSH client/server, git, cat, grub May 30 18:29:30 lot of stuff May 30 18:29:43 grub? May 30 18:29:52 Not Grub sorry May 30 18:29:53 typo May 30 18:29:57 grep May 30 18:30:21 yeah i've used WSL, it's pretty cool May 30 18:31:28 I currently compile openwrt inside WSL! :D May 30 18:34:13 build #852 of ar7/generic is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fgeneric/builds/852 blamelist: Hans Dedecker , Rosen Penev May 30 18:37:09 blogic: hi, how is qca8k coming along? I remember that the original plan was to push the kernel expansion patch and qca8k in short succession to minimise the inconvenience for people May 30 18:38:43 for luci/lua, what about using qdecoder(cgi/factcgi lib), it's harder to use but it will never have lua-version-upgrade problem May 30 18:39:19 and it is very light-weighted May 30 18:42:01 rewrite all of the lua in c++? May 30 18:42:15 :( May 30 18:49:01 huaracheguarache: almost done, got side tracked with NSS May 30 18:49:37 i am stripping the NSS SDK code to its bare minimal right now only leaving ipv4/6 tcp/udp functionality in it, refactoring it and then merging it into stmac May 30 18:49:46 i was on a flow :-) May 30 18:50:11 huaracheguarache: qca8k patches are done for all but 2 board including dual gmac support, i'll push my staging tree tomorrow for testing May 30 18:51:13 blogic: great news! :) May 30 18:51:33 NSS SDK code is really fucking insane May 30 18:51:45 QCA is really good at over engineering and May 30 18:51:58 NSS code is not as broekn as the SSDK code but still insane May 30 18:52:20 and there are features inside the codebase that i am sure no customer has ever or will ever need and or use May 30 18:52:55 there is quad mac link aggregation support May 30 18:53:11 or OAM offloading support May 30 18:53:26 WTF would you want to offload your 10k / day OAM packets May 30 18:53:40 and the list goes on and on and on May 30 18:58:04 blogic: Are you still connected? May 30 19:01:19 luaraneda: to what ? May 30 19:02:00 To the IRC channel (that´s a yes xD) May 30 19:02:13 blogic: on commit f6a067a you marked the zynq target as source-only because it's on kernel 4.4 May 30 19:02:24 I made a PR for over two weeks to fix a booting problem and update it to k4.14 May 30 19:02:27 https://github.com/openwrt/openwrt/pull/942 May 30 19:02:38 It also was run-tested by another user May 30 19:03:02 I've asked on the PR to mkresin if he could merge it or if we need more reviews, but he hasn't answered yet May 30 19:03:17 Can you take a look at it? please May 30 19:03:33 Or should I send the patches to the ML for more reviews? May 30 19:04:38 luaraneda: i'll look tomorrow, if you see no activity remind me May 30 19:04:51 blogic: Thanks :) May 30 19:04:57 did not have it on my todo list but its on there now May 30 19:07:26 blogic: great stuff! looking forward to try it out =) May 30 19:16:23 lol wirus 10 May 30 19:21:20 pci brokenness continues. argh May 30 19:28:28 build #874 of ar71xx/mikrotik is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Fmikrotik/builds/874 blamelist: Hans Dedecker , Rosen Penev May 30 19:41:44 ok, this is new May 30 19:41:46 [ 68.039500] Unable to handle kernel NULL pointer dereference at virtual address 00000000 May 30 19:41:50 [ 68.155907] LR is at dev_hard_start_xmit+0x9c/0x118 May 30 19:42:03 [ 68.459850] Backtrace: May 30 19:42:05 [ 68.462313] [] (dev_hard_start_xmit) from [] (sch_direct_xmit+0xb4/0x1b4) May 30 19:42:07 this is with brcmfmac May 30 19:42:11 and looks like sth new May 30 19:43:18 ok stupid question of the day - luci->system->mount points-> option Check filesystems before mount (y/n) May 30 19:43:49 but each mount point has its own run filesystem check option. May 30 19:44:07 So err, what's the difference ? May 30 19:48:55 ldir: the global option serves as a default, also for automount'ed filesystems without a config section afaik May 30 19:51:41 oh, nevermind, it's caused by my brcmfmac patch May 30 19:52:00 at the moment I can't find anything referencing 'option enabled_fsck '1'' May 30 19:54:26 ldir: if you don’t enable global check then per mount checks won’t work, it’s like a general switch May 30 19:54:53 At least this what happens in my experience May 30 19:57:56 as yet I cannot find anything that actually references 'enabled_fsck' which is the per mount fsck enable/disable flag. May 30 19:58:40 I can find blockd referencing 'check_fs' which is the 'global' switch. May 30 20:30:40 build #785 of ar71xx/generic is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/785 blamelist: Hans Dedecker , Rosen Penev May 30 20:35:41 ldir: probably it belongs to the old block-mount May 30 20:36:36 so at some point it could be removed May 30 20:45:41 * blogic gets triggered by block-mount May 30 20:46:07 oh luci, i have no idea, sorry May 30 20:46:10 ldir: afaik the whole of the luci-based filesystem management is kinda tailored to block-mount... May 30 20:47:38 ldir: for most of /etc/config/fstab it shouldn't make any difference, but we should review all that and advise users to use blockd from fstools instead of any of the prior ((semi-)auto-)mounting approaches May 30 20:48:29 dangole: correct May 30 20:48:35 blockd makes the whole thing stateful May 30 20:48:43 anything prior was very fragile May 30 20:49:09 anything that relies on hotplug triggers and so on is not serialised in its event execution May 30 20:49:21 and can cause plenty of race and therwise awkward situations May 30 20:49:45 ...not even talking about stale mounts in case of device removal May 30 20:50:01 yep May 30 20:51:41 blogic: talking about blockd, it'd still really be nice to have a way for triggering service start/stop/reload by mount-point state. just like it works in procd for network interfaces... May 30 20:55:10 blogic: in that way, service depending on any sort of data storage could be triggered after mounting upon occurance of the uuid configured to hold its data (think: databases, file-servers/transfer-services, ...) May 30 20:55:41 ldir: sorry to drift off the original discussion... May 30 20:58:29 dangole: yes, long story short i have a lot more time now than 6 months ago May 30 20:58:40 Hello! Anyone online? :) May 30 20:59:04 i am offline on vacation for 1,5 weeks starting next wednesday May 30 20:59:14 blogic: where to? May 30 20:59:17 not to stalk you :) May 30 20:59:24 or is it a staycation May 30 20:59:31 ping me on this one when i return, there are a few other things that procd lacks so i'll spend a week on them in july May 30 20:59:45 Borromini: small island on the east coast May 30 20:59:56 blogic: german east coast? May 30 21:00:01 yeah May 30 21:00:02