**** BEGIN LOGGING AT Fri May 03 02:59:57 2019 May 03 11:44:25 jeffsf: you need to send your patch again as a new mail, since your patch is already broken in patchwork and patchwork probably can't fixit https://patchwork.ozlabs.org/patch/1088433/ May 03 11:45:47 Yes, I saw that -- I tried once and it cut it short again. I'll try to config git send-email here as patchwork has it our for me ;) May 03 11:45:55 Thanks May 03 11:56:02 ynezz: Reference prior or just try "fresh"? May 03 11:56:47 xback: maybe some kernel bump http://phase1.builds.openwrt.org/builders/brcm2708%2Fbcm2709/builds/1306/steps/images/logs/stdio also FS#2265 ? May 03 11:57:15 jeffsf: just send it again May 03 12:00:33 :+1: May 03 12:03:26 Sent with git send-email this time May 03 12:06:16 (and still looks broken -- withdrawing) May 03 12:07:07 (and giving up on patchwork) May 03 12:11:07 no it was fine https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=2929e2ce4b9c27b003e788c2350af8d1bb734f97 May 03 12:21:15 ynezz: Thanks! May 03 12:33:49 jeffsf: why are you creating the PR for this? May 03 12:34:11 I didn't know that the patch was good -- looked garbled on Patchwork May 03 12:34:25 Will pull the PR May 03 12:36:02 Patchwork has messed up so many of my patches I figured it was my sending error again May 03 12:39:45 jeffsf: don't blame patchwork; it already received them that way - it is/was you mail program that tried to be "helpful" and "fix" things up automatically May 03 12:41:10 I understand, though I can't say that `git send-email` has been any better, especially with associating updates with existing patchwork entries May 03 12:42:32 Using `--in-reply-to=` didn't seem to work May 03 12:45:59 it doesn't work that way, you can't update the patch like that, you need to send it out as a new mail with [PATCH v2] prefix May 03 12:58:07 mangix: could you please handle this https://patchwork.ozlabs.org/patch/1056222/ as a backport of e3c36e483b4806a6bf28db411f79ea9aad61ec78 ? May 03 13:00:20 jeffsf: usually it's discouraged to send new versions as replies to previous ones; threaded view in email clients can "hide" these patches May 03 13:02:40 So if changes are requested on a patchwork-captured submission, send a new one that supersedes the previous? May 03 13:03:02 OK -- I see ynezz's comment there May 03 13:03:03 right May 03 13:03:08 Thanks May 03 13:03:37 Most of the rest of `git send-email` I figured out, thanks for clarifying the process there May 03 13:05:11 like a midget at a urinal, i was going to have to stay on my toes. May 03 13:13:14 gch981213: what do you think about this one https://github.com/openwrt/openwrt/pull/1700#issuecomment-480459509 ? May 03 14:05:00 OpenWRT 18.06.2 / Asus RT-N66U / 4g modem LTE + OpenVPN / connects successfully after reboot, but then it crashes and the Internet disappears / May 03 14:05:04 kern.notice kernel: [ 111.922494] random: crng init done May 03 14:05:13 kern.notice kernel: [ 111.926027] random: 3 urandom warning(s) missed due to ratelimitin May 03 14:05:22 sorry i translate google / i russian May 03 14:05:35 I just try to check the speed of the Internet connection through whoer.net and this error pops up. Sometimes it does not pop up quickly and you can see yotube and other pages. but in the end all the same the Internet disappears. I ran "wrt" simultaneously on the router and on the laptop connected to the router. packets are lost at the same time. It works first on the router and on the laptop and then disappears simultaneously everywhere. May 03 14:13:59 ynezz: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=5b4ea9ab33a45bcbf3a1a3d577ca44d691c86671 May 03 14:17:45 wbddwokl: More people to help you at https://forum.openwrt.org/ May 03 14:18:18 Google Translate is OK -- most people use English there but understand many use Google Translate May 03 14:21:28 https://forum.openwrt.org/t/openwrt-18-06-rc2-dmesg-message-urandom-lack-of-entropy/17130 I do not understand anything)) similar errors. and ... entropy)))) May 03 14:21:47 xback: that was quick, thanks! :) May 03 14:22:20 I think to try to put the old firmware May 03 14:23:11 wbddwokl: "entropy" is for random number generation, usually for wireless or SSH encryption. It is seldom a reason for a crash. May 03 14:24:10 If, on the forum, not here, you post the output of dmesg using the button so it is easy to read, people can help you find the problem May 03 14:28:56 It may be necessary to put a certain stable firmware. somebody will tell me the most stable firmware for Asus RT-N66U. i wait activation mail forum.openwrt.org May 03 14:29:55 nbd: I've just noticed, that you've still @openwrt.org in kernel's MAINTAINERS file (got bounced email) May 03 14:40:02 ynezz: fix pushed to master May 03 14:41:14 ynezz: i'll check 18.06 too May 03 14:42:51 18.06 does not contain the bug for brcm2708 (y) May 03 14:44:06 great, thanks for checking it May 03 14:44:47 spi-nand on ath79 looks like it works with patches to enable GigaDevice gd5f1gq4ufxxg (newer 1 Gb chip) May 03 14:45:28 Now to unwind this mess into some clear patches (and thank again for the confidence to try submitting by mailing list) May 03 14:48:12 ath79: QCA9563 short of the .dtsi limitation, can the SPI there go faster than 25 MHz? May 03 14:58:15 What is the proper way to identify upstream Linux patches when submitting to OpenWrt (in the "backports" directory)? May 03 14:59:01 Is the Linux commit message from the Linux development branch sufficient? May 03 15:07:39 yes, and don't forget to put the linux version to the filename as well May 03 15:08:10 in other words, follow the already estabilished backporting examples May 03 15:10:37 Great, thanks! Not looking forward to going through the ringer at linux-mtd, but definitely appreciate the rigor you all review things with here May 03 16:12:19 ynezz: nbd: I already have a patch locally fixing that, that I'll send after dinner (MAINTAINERS; and other's addresses as well) May 03 16:53:16 KanjiMonster: nice, thanks May 03 17:19:18 Hey May 03 17:56:26 ynezz: you want me to change the description to that? May 03 18:04:27 jeffsf_: last i remember it can go up to 40MHz May 03 18:04:53 but the driver needs love to get faster speeds May 03 18:24:04 Time to upgrade? https://ibb.co/cy6N5yJ May 03 18:30:36 .15 May 03 18:30:37 wow May 03 18:54:33 Thanks mangix -- Might poke at that after linux-mtd finishes poking at my patch and I get the AR750S NAND port wrapped May 03 19:07:04 Any word on the LTS Linux after 4.19? May 03 19:07:49 6.2 I would say May 03 19:07:51 :) May 03 19:08:34 LOL, yeah -- get those monkeys typing! May 03 19:09:20 Just in time to support 802.11xxx May 03 19:12:38 don't you know? It's WiFi 6 now ;) May 03 19:13:23 Like THAT's more descriptive... May 03 19:14:48 Upstream submissions based on kernel/git/torvalds/linux.git rather than a branch? May 03 19:15:26 mangix: well, sorry for the noise, I wasn't aware that OpenWrt uses it's own version of drivers/net/ethernet/mediatek/mtk_eth_soc.c May 03 19:15:30 I hate the new wifi names! May 03 19:23:48 probably they will do the wifi marking naming similar to USB 3 later on. May 03 19:29:54 Hauke, Oh god, that one is even worse! At least Wifi make more or less sense! May 03 19:30:45 ynezz: allegedly will migrate once ramips moves to 4.19 May 03 19:31:05 having said that, initial results are disappointing (slow) May 03 19:32:45 ynezz: thanks for merging the lantiq initramfs patch :) May 03 19:37:03 mangix, Ramips is slow on 4.19? May 03 19:37:30 hitech95: if using the mainline mtk_eth_soc driver May 03 19:38:40 mangix, oh ok the throughput is low. I'm interested on the asoc driver and (i2c manual mode) no idea if it will get merged and fixed. May 03 19:39:07 Pepe: http://lists.infradead.org/pipermail/openwrt-devel/2019-April/016769.html does it mean, that you've actually tested it? May 03 19:40:06 * mangix looks May 03 19:40:07 Hauke, at the end you ported the Lantiq Switch Driver to Mainline! https://github.com/torvalds/linux/blob/master/drivers/net/dsa/lantiq_gswip.c May 03 19:41:23 hitech95: https://github.com/neheb/source/commit/625f051ee70bbd184ba3f59a4e217b64aa3e4f8d May 03 19:42:07 requires DTS and /etc/board.d/02_network changes May 03 19:42:22 I had no real time to finish this. May 03 19:43:53 Dumb question, is swconfig able to manage DSA and switchdev drivers? May 03 19:44:00 nope May 03 19:46:38 mangix, I was talking about this: https://github.com/openwrt/openwrt/pull/831 May 03 19:47:28 My last comment there still applies May 03 19:48:31 mangix, good to know. Someone should pathc that into mainline. Unfortunatly the auto mode is "bugged" in hardware and some chips don't work with it! May 03 19:53:26 hitech95: the current mainline version of the lantiq gswip driver does not support bridge offloading, this is currently pending on the netdev mailling list May 03 19:54:40 Hauke, Oh, ok no problem. Coll to see that you ported the driver from swconfig to DSA. (I remember like 3 years ago that is was having lots of issues) May 03 19:55:35 any objections to removing support for kernel 3.18, I would like to merge this: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/remove-3.18 May 03 19:56:04 hitech95: the dsa driver is probbaly also not error free, if you see any problems please report them to me and I will try to fix them May 03 19:58:32 It would be very nice if someone could work on a script which converts the swconfig based switch configuration into a dsa configuration to migrate old configurations May 03 19:59:01 this is currently blocking switching to DSA for existing targets May 03 19:59:12 and we will never get swconfig merged into mainline Linux May 03 20:07:17 Hauke: I've been thinking about UCI for DSA that is clear for users and experts with their unique needs both. I'll keep thinking on that as well as an upgrade script. May 03 20:08:44 "Wire the yellow ports to my LAN and the blue port to my WAN, don't ask me about stinkin' VLANs" to "My ISP needs VLAN NNN for it to work" as well as more advanced VLAN trunking May 03 20:11:34 jeffsf: with DSA the configuration is getting easier May 03 20:11:59 for the easy use cases, you just add the lan ports into one bridge and use the wan port directly, thats it May 03 20:12:10 you can even name the lan ports lan1 to lan4 May 03 20:12:54 when you want to do vlan handling it is getting more compliacted May 03 20:13:00 Yes, played around with it for a bit on IPQ4019. Need a couple tricks under the covers so users don't have to know that eth0.1 and eth0.2 even exist for one-armed routers May 03 20:15:26 Hauke: does it look ok to you https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=2339d5cb89a4d3991eab5b6615d7ddfff7fe3da1 ? May 03 20:16:07 * jeffsf crosses fingers that patch also applies cleanly to mainline Linux May 03 20:16:30 Hauke: that 3.18 removal seems ok to me May 03 20:17:24 ynezz: "default n" is redundant, it's the ... default ;p May 03 20:17:50 ok, good point May 03 20:18:16 ynezz: shouldn't the commit message be the other way around though? May 03 20:18:35 i thought the default was mentioned in uppercase (which is no) yet your message says Y/n and not y/N May 03 20:19:24 ynezz: if you fix the sugegstion from KanjiMonster and Borromini it looks good May 03 20:19:58 also is there any good reason why you wouldn't want these? i.e. any reason to expose these as options, and not just enable them when enabling KERNEL_KPROBES? May 03 20:20:12 but this Y/n is copy&paste of the output from kconfig, I swear, I didn't modified it :) May 03 20:20:46 naughty kconfig :P May 03 20:21:14 this is my current config http://paste.ubuntu.com/p/5KdWTsM77H/ May 03 20:21:33 without this patch I get the build breakage with V=s May 03 20:23:11 KanjiMonster: isn't it fullfiled with `depends on KERNEL_KPROBES` and `depends on KERNEL_PERF_EVENTS` ? May 03 20:27:42 ynezz: I mean why have a prompt at all - the KERNEL_KPROBE_EVENT at the bottom doesn't have one and just defaults to y when enabling KERNEL_KPROBES May 03 20:29:45 ynezz: which btw is one of the two symbols you added which was renamed upstream in 4.11 -> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b0b7551428e4caae1e2c023a529465a9a9ae2d4 May 03 20:30:26 ah! thanks for tracking it down May 03 20:31:34 now I wonder how to fix it properly so it works for all kernel version, just set both symbols and pray, that kconfig can handle it? May 03 20:31:44 s/version/versions/ May 03 20:32:38 both versions should be fine May 03 20:34:17 we can drop the singular versions when we drop 4.11- May 03 20:38:04 ynezz: tracking down the commit was the easy part, the hard part was finding a web link for the commit I can throw at you ;) May 03 20:45:58 Hauke: as a counter example to migration scripts, the R7800 can't be upgraded from 17.01 to 18.06 May 03 20:50:24 would have been an ideal time to switch to qca8k... that being said, I remember some issue with PPPoE May 03 20:59:24 Hauke: KanjiMonster: so in the end it has resulted in the following commits https://git.openwrt.org/ed1aa8b2d4e4 and https://git.openwrt.org/f7bedb328ee1b0a May 03 21:00:40 ynezz: LGTM May 03 21:01:48 ynezz: in the description you are missing an "S": renamed UPROBE_EVENT to UPROBE_EVENT May 03 21:02:04 yeah, fixed already, thanks May 03 21:02:32 looks good May 03 21:09:20 Hauke: Re: kmod-i2c-mux-pca954x, I've thought, that you just need to provide the needed package and that the dependencies are automagically resolved May 03 21:12:06 ynezz: it works like this when it is a select in kconfig, but not when it is a depends May 03 21:12:41 ah, ok, thanks for clarification May 03 21:20:17 "0001-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UFxxG.patch has no obvious style problems and is ready for submission." May 03 21:20:32 linux-mtd first, yes? May 03 21:23:25 http://www.marcusfolkesson.se/blog/get_maintainers-and-git-send-email/ May 03 21:23:55 Thank you! May 03 21:28:59 oooh that looks useful! May 03 21:29:18 Comes up with 6 maintainer/reviewers, 5 other authors, and linux-mtd and linux-kernel May 03 21:29:40 CC the individuals all?? May 03 21:29:48 you missed the point May 03 21:30:22 Which was that "Yes, this tool shows that linux-mtd is the right place"? May 03 21:30:37 --to-cmd and --cc-cmd automate it all for you, you don't need to do anything manually May 03 21:30:44 Ah, OK May 03 21:33:39 you just need to be careful on which branch you run this, because there is no check, so you could be using old emails if for example hacking on 2.6 :) May 03 21:35:43 well, even 4.14 is going to provide some unreachable maintainer email for mtd stuff May 03 21:45:59 ynezz: Patch is against mainline, so hopefully reasonably correct. Thanks for the pointers, will config it when I'm more awake May 03 21:46:27 Good news is that spi-nand works against OpenWrt ath79 on 4.19 May 03 23:51:15 mangix: the bigger problem with qca8k (PPPoE was raised as an issue over 2 years ago, I don't think anyone has tried it ever since) is that it doesn't cover devices which store the primary MAC in ubootenv (ASCII vs binary) so far (this affects at least ea8500 and nbg6817) May 04 00:49:05 well, i'm specifically talking about the r7800. May 04 00:49:42 yep, understood - but that still is an issue for deploying it to all ipq806x devices May 04 00:49:57 (and yes, PPPoE stability would need new testing) May 04 00:51:23 i didn't say all. mvebu uses a mix of DSA and swconfig May 04 00:51:51 DSA for Turris Omnia and swconfig for everything else May 04 00:52:56 that's mostly because of avoiding the need for a migration switch, to keep sysupgrades working (and turris omnia was a new device, so no need to retain backwards/ sysupgrade compatibility), it's different for ipq806x May 04 00:53:46 if you break one of them (as all currently supported ones are swconfig based), you could just break all of them and do away with swconfig May 04 01:55:27 as I said, you cannot sysupgrade between 17.01 and 18.03. May 04 01:55:43 compatibility was already broken May 04 01:57:08 and actually the Turris Omnia situation was to avoid carrying a problematic swconfig patch that had the potential of breaking other setups May 04 02:01:05 do not get me wrong, I don't really see a way to write an idiot proof migration script - meaning I personally wouldn't bother too much about it and the breakage switching entails. but qca8k missed 18.06, so we're looking at another/ new breaking point (at which point it would be nicer to switch all ipq806x devices at once) May 04 02:11:13 What if we encode something like an ABI version on sysupgrade images so that an update that preserve the current configuration could only be performed if the running system has the same "ABI version", and a reset to defaults is required otherwise? Granted, it does not solve all scenarios and the same problems as migration scripts, but it could be a safety measure to stop users updating and getting a non-working May 04 02:11:14 configuration May 04 02:12:44 It also won't work immediately, as the feature that checks the "ABI version" would have to be the running version, but it could help solve future problems May 04 02:13:06 you kind of have that already, with SUPPORTED_DEVICES May 04 02:13:39 (albeit --force|-F is more dangerous than a less invasive ABI check) May 04 02:16:11 pkgadd: Yeah, but SUPPORTED_DEVICED it's not the same, because you would have to add/change the device name each time you make a change that breaks sysupgrade compatibility. It's not the same as an integer value that can be easily incremented and compared May 04 02:17:11 yep, sure May 04 02:17:34 Additionally, if I remember correctly, SUPPORTED_DEVICES ideally has the same value as the compatible string of the corresponding device tree May 04 02:17:58 yep May 04 02:18:29 ideally it doesn't exist (implicitly dervived from the dts name) May 04 02:21:04 Thay was it then, the dts file name. I was confused but remembered now. Thanks for the clarification :) **** ENDING LOGGING AT Sat May 04 02:59:57 2019