**** BEGIN LOGGING AT Sat Nov 24 02:59:59 2018 Nov 24 03:18:41 rmilecki: working ... Nov 24 03:41:58 rmilecki: it boots, what should i be looking for? Nov 24 05:01:44 russell--: probably re: https://git.openwrt.org/?p=openwrt/staging/rmilecki.git;a=patch;h=3f3aa0d47401e0e19949a59f8eb5e54792a76a2f Nov 24 05:07:09 igel: i'm testing the wndr3800, but yeah. i'm not sure what behavior i'm testing. it boots. Nov 24 05:09:07 # dmesg | grep split Nov 24 05:09:07 [ 0.713153] 1 squashfs-split partitions found on MTD device rootfs Nov 24 05:10:14 full dmesg: http://sprunge.us/FLYca4 Nov 24 07:25:02 russell--: i wanted to know if you still see 2 netgear-fw partitions found on MTD device firmware Nov 24 07:25:37 russell--: if "it boots" I guess kernel and rootfs partitions got created for you :) Nov 24 08:02:22 rmilecki: yes, it did, afaict Nov 24 08:11:02 [ 0.685273] 2 netgear-fw partitions found on MTD device firmware Nov 24 08:53:40 russell--: thanks, i've already pushed those changes Nov 24 09:05:47 ldir: hey, with your TP-LINK info, I've added required code for it Nov 24 09:05:58 ldir: and I've modified DTS file for your device in my branch Nov 24 09:06:06 ldir: could you compile/test https://git.openwrt.org/?p=openwrt/staging/rmilecki.git;a=summary please? Nov 24 09:06:36 ldir: i'd like to know if you still get "2 tplink-fw partitions found on MTD device firmware" and if it still boots Nov 24 10:27:40 rmilecki: building now...... Nov 24 10:29:41 ldir: wow, that's quick, thanks! Nov 24 10:33:45 I'm working on an ath79 dts for dlink dir-825-c1 Nov 24 10:33:58 I have a little problem with the wan led Nov 24 10:35:06 In the ar71xx mach file there is this call: gpio_request_one(20,GPIOF_OUT_INIT_LOW, "WAN LED enable"); Nov 24 10:35:28 And that would cause the SOC to control the led, which was nice Nov 24 10:35:45 But I'm having issues translating that to ath79 Nov 24 10:36:45 I tried with gpio-export, but neither GPIOF_OUT_INIT_LOW nor GPIOF_OUT_INIT_HIGH does anything Nov 24 10:37:06 And when I try GPIOF_OUT_INIT_LOW I get a compile failure/dts error Nov 24 10:37:13 Any idea how this could be done? Nov 24 10:37:29 I can define it as an extra led and have it active by default Nov 24 10:37:41 That actually works, but doesn't seem like the right way to do it Nov 24 10:38:05 micmac1: i'm not sure what the gpio-export is Nov 24 10:38:16 maybe post your DTS on pastebin or something Nov 24 10:38:38 gpio-export exports the gpio to /sys/class/gpio Nov 24 10:38:55 when I then manually go in there and activate it it works fine Nov 24 10:39:01 normally for LEDs using GPIOs you use GPIO_ACTIVE_LOW or GPIO_ACTIVE_HIGH Nov 24 10:39:20 But I haven't found a script to activate it on boot Nov 24 10:39:24 Let me pastebin this Nov 24 10:40:50 https://pastebin.com/Dnc7J9Sg Nov 24 10:41:33 The pastebin has gpio 20 crammed into the led define Nov 24 10:41:39 But that didn't work either Nov 24 10:51:53 micmac1: i'm not sure what you want it to do Nov 24 10:52:35 :) Nov 24 10:52:44 GPIO 18 controls the wan led Nov 24 10:52:54 okay Nov 24 10:52:55 So you can switch it on/off, add a trigger Nov 24 10:52:59 sure Nov 24 10:53:26 But if you leave 18 off, and instead "activate" 20, then the SOC will control is, just like it controls the LAN leds Nov 24 10:53:35 *it Nov 24 10:54:09 what does 20 do? Nov 24 10:56:09 oh, you want to force gpio 20 on? Nov 24 10:57:17 Yes Nov 24 10:57:32 I mean I can export it in the dts with gpio-export Nov 24 10:57:39 But that doesn't activate it the way I want Nov 24 10:57:48 i don't think you want to call it an LED Nov 24 10:58:05 right Nov 24 10:58:23 In ar71xx this was done with GPIOF_OUT_INIT_LOW Nov 24 10:58:37 which is defined as (GPIOF_DIR_OUT | GPIOF_INIT_LOW) Nov 24 10:59:15 (0 << 0) | (0 << 1) Nov 24 11:01:03 micmac1: let me re-ask Nov 24 11:01:31 micmac1: do you need GPIO 20 set to LOW in order to have GPIO 18 work correctly and control LED? Nov 24 11:02:14 No, you can use 18 and get a normal, working led. Nov 24 11:02:49 I see where you're going with this :) Nov 24 11:03:01 i'm just a bit confused Nov 24 11:03:03 You mean then I can just use 18 and control it with netdev Nov 24 11:03:04 not sure what's the problem Nov 24 11:03:40 I just like it that the SOC takes care of the wan led when 20 is used :) Nov 24 11:04:33 OK, let's say GPIO 20 is LOW, what happens to the WAN LED then? Nov 24 11:04:37 micmac1: what happens when you uncomment the gpio-export part? Nov 24 11:05:43 I get the gpio exported to /sys/class/gpio Nov 24 11:05:54 but anyway, if You want to export this gpio, You should use GPIO_ACTIVE_LOW instead of GPIOF_OUT_INIT_LOW for example look at qca9558_tplink_archer-c7.dtsi Nov 24 11:06:11 tmn505: yeah Nov 24 11:06:49 I tried. That would export it. But it doesn't make the led blink like gpio_request_one(20,GPIOF_OUT_INIT_LOW, "WAN LED enable") in ar71xx Nov 24 11:07:13 Anyway, I'll stop bothering you with this :) I'll just tinker around a bit more. Nov 24 11:07:16 Thanks! Nov 24 11:08:55 micmac1: try GPIO_ACTIVE_HIGH instead, maybe? Nov 24 11:09:28 Tried that, not blinking Nov 24 11:10:02 micmac1: please kindly check http://lists.infradead.org/pipermail/openwrt-devel/2018-November/014706.html Nov 24 11:10:10 micmac1: it's a very new thing Nov 24 11:11:43 what's available for d-link/firmare? Nov 24 11:11:57 micmac1: oh, I didn't add that yet Nov 24 11:12:02 what parser does that device use? Nov 24 11:12:07 micmac1: from userspace, can you toggle the gpio? Nov 24 11:12:25 yes Nov 24 11:12:28 micmac1: what your "partitions found on MTD device firmware" line like? Nov 24 11:13:29 2 uimage-fw partitions found on MTD device firmware Nov 24 11:14:03 then please use the Nov 24 11:14:04 "If you see: Nov 24 11:14:06 2 uimage-fw partitions found on MTD device firmware" Nov 24 11:14:07 part Nov 24 11:14:14 oh :) thanks Nov 24 11:14:33 Will do, thanks! Nov 24 11:14:38 thank you Nov 24 11:19:57 micmac1: and do you see something sensible with: cat /sys/kernel/debug/gpio Nov 24 11:20:58 Let me check, it'll take a few mins Nov 24 11:25:14 rmilecki: for the partition thing, do I need a fresh trunk checkout or will that work with the one I have from a week or two ago? Nov 24 11:25:48 micmac1: if you have old branch checkouted, adding "compatible" won't change anything Nov 24 11:25:58 micmac1: so to make sure it works as expected ,you need the latest source Nov 24 11:26:04 ok Nov 24 11:26:09 Will do that later Nov 24 11:26:21 sure Nov 24 11:26:53 two commits that matter for your case (uimage) are: Nov 24 11:26:55 934edb764dfd ("kernel: don't auto-split "firmware" if it has "compatible" DT property") Nov 24 11:26:57 a22311e6a6d4 ("kernel: add DT binding support to the uimage parsers") Nov 24 11:28:15 Don't have those yet Nov 24 11:28:19 Thank you! Nov 24 11:29:39 I'd have never believed back when I bought the damn thing that I'd be using it this long. Never mind that I'll be using it for even longer than this :-) Nov 24 11:35:05 :) Nov 24 11:37:38 russell--: in /sys/kernel/debug/gpio I get this for 20: Nov 24 11:37:49 gpio-20 ( |d-link:wan:autoled ) out hi Nov 24 11:38:20 In the dts I have it currently defined as "gpios = <&gpio 20 GPIO_ACTIVE_LOW>;" Nov 24 11:39:19 In "d-link:wan:autoled" value is currently 0 Nov 24 11:39:33 try echo'ing a 1 in there Nov 24 11:39:42 When I change it to 1 it starts blinking Nov 24 11:39:44 :) Nov 24 11:39:58 you may need to add something to target/linux/ath79/base-files/etc/board.d/03_gpio_switches Nov 24 11:40:00 I wonder how I can get it to value=1 automatically Nov 24 11:42:17 Maybe ucidef_add_gpio_switch "wan led auto" "WAN LED Auto" "20" "1"? Nov 24 11:42:34 yeah Nov 24 11:42:40 something like that, anyway Nov 24 12:26:11 now it works. Without any gpio export. 03_gpio_switches is enough. Nov 24 12:26:15 Thanks russell-- ! Nov 24 12:39:52 micmac1: yw Nov 24 13:41:01 there are way too many patches pending in patchwork and on giuthub Nov 24 13:47:45 people getting busy before the new year :) Nov 24 14:26:48 Bye guys Nov 24 14:26:52 Thanks again! Nov 24 17:08:45 Hauke: thanks for your review of mesongx target Nov 24 17:09:23 stintel: looks good Nov 24 17:09:42 jow: if it happens again I will send you the contents of nf_conntrack - dmesg was empty afaict Nov 24 17:10:01 Hauke: I will probably wait until we have 4.19 in master though Nov 24 17:10:40 Hauke: mainline u-boot isn't supposed to be used with kernel <4.16 according to http://www.linux-meson.com/doku.php#u-boot_development_status Nov 24 17:11:05 and I've been looking at backporting patches but they caused stuff to break on my odroid c2 Nov 24 17:11:57 and with 4.19 I should be able to test if HDMI actually works on that device, and by then I should have my Libre Computer La Frite which can work with the same target Nov 24 17:13:20 I hope I get the kernel 4.19 patches into some state that I can send them to tzhe mainling list soon Nov 24 17:15:18 I'm looking forward to that. if you do, please let me know (cc or here), I will be happy to test them Nov 24 17:16:02 I should probably handle the feedback I got on brcm2708/4.14 Nov 24 17:16:19 so we can finally get this target on 4.14 and ready for 19.01 ;) Nov 24 17:17:27 Hi! I'm planning on add DSPI/QSPI support for mt7621/mt7628. I now have two choices: 1. backport spi-mem to linux 4.14 2. use mainline kernel with OpenWrt. Which one do you think is easier? Nov 24 17:25:35 gch981213[w]: if it's in 4.19 I would wait until that hits master, and spare yourself the effort of backporting Nov 24 17:33:22 stintel: please let me know if you saw my testing request Nov 24 17:33:36 if you need more time, no problem, just let me know Nov 24 17:33:44 sight the forum today... Nov 24 17:33:45 i'm just not sure if you saw my message at all Nov 24 17:33:47 *sigh Nov 24 17:33:47 stintel: it's available in 4.19. I'd probably starts playing around with hauke's staging tree :) Nov 24 17:34:31 rmilecki: let me get to it Nov 24 17:36:14 rmilecki: If you mean a test for using denx, uimage in ath79 I've tested it with my ar9344 router and updated my GitHub PR#1517 Nov 24 17:37:44 gch981213[w]: looks good, thanks Nov 24 17:51:35 hi Nov 24 17:51:57 what is the max ipv4 mtu on a dslite link? Nov 24 17:55:09 rmilecki: flashin image to my Unifi AP AC Pro Nov 24 17:55:28 shm0: trasnsport-ipip Nov 24 17:55:59 stintel: ok! let me know if you still get "2 uimage-fw partitions found on MTD device firmware" Nov 24 17:56:01 so -40, iirc Nov 24 17:56:02 ? Nov 24 17:57:32 rmilecki: [ 0.412512] 2 uimage-fw partitions found on MTD device firmware Nov 24 17:57:42 stintel: great! I guess it booted OK? Nov 24 17:58:13 rmilecki: it booted ok, but there seems to be something wrong Nov 24 17:58:24 as in, not the image it should be Nov 24 17:58:28 OpenWrt SNAPSHOT, r8477+19-d3381b5a64 Nov 24 17:58:43 stintel: ok, I guess whatever is wrong, it should be unrelated Nov 24 17:58:54 online mtu analyzer gives me 1412 Nov 24 17:59:02 seems too low for me Nov 24 17:59:44 rmilecki: although that's also what I get when I run getver.sh Nov 24 17:59:47 stintel: did it actually upgrade the firmware? I still get intermittent flash failures which end up just being reboots Nov 24 18:00:11 ldir: the kernel build timestamp is today so can't be wrong Nov 24 18:00:31 curious :-) Nov 24 18:00:41 maybe kernel got updated but rootfs did not? Nov 24 18:00:46 rmilecki: so yes, looks good, no issues, just getver.sh is not liking my build branch Nov 24 18:00:50 ldir: huh? is that described somewhere?! Nov 24 18:00:59 got an isp router today. holy crap that interface is limited. and guess what wifi power also not adjustable Lol Nov 24 18:01:17 rmilecki: no, r8477+19-d3381b5a64 is what getver.sh shows, even though my top commit in git log is 72729c9c98b90f2b96e8621fa6ccf9ea4e33dd90 Nov 24 18:01:24 absolutely cancerous Nov 24 18:01:39 getver.sh should use git describe Nov 24 18:02:07 shm0: can't tell if its right without describing access method and such Nov 24 18:02:15 but, #openwrt anyway :D Nov 24 18:02:29 rmilecki: and if only kernel was updated I wouldn't have wifi on the thing coz modules wouldn't match ? Nov 24 18:02:33 access method? Nov 24 18:03:03 rmilecki: any other info you need? Nov 24 18:03:17 and of course no bridge mode Nov 24 18:03:17 stintel: hm, possibly Nov 24 18:03:20 what a pity Nov 24 18:03:26 stintel: no, thanks for testing Nov 24 18:03:43 rmilecki: anecdotally yes, can't point you at where. I believe it to be killall not being able to kill a (wireless) process at sysupgrade time, so it gives up. Nov 24 18:03:43 rmilecki: rootfs timestamps seem now -20m too Nov 24 18:03:47 and no modems available here in this country Nov 24 18:03:49 rmilecki: you're welcome, sorry for the delay Nov 24 18:03:51 straight ethernet? pppoe? limited transport mtu? what? Nov 24 18:04:00 at least supply *something* to go on... Nov 24 18:04:04 stintel: no problem! Nov 24 18:04:08 s/sorry for the delay/thanks for reminding me/ Nov 24 18:04:22 * stintel trying to keep it positive - excuses aren't that :P Nov 24 18:04:23 thanks :) Nov 24 18:04:46 heading out now, getting some meat for dinner Nov 24 18:04:54 also don't use nonsense online "tools", figure it out properly Nov 24 18:07:54 https://www.speedguide.net/analyzer.php ? Nov 24 18:09:37 yeah that is entirely garbage, like I said Nov 24 18:09:51 actually in an older firmware the router had an info box that displayed the mtu Nov 24 18:10:00 but of course they removed that also Nov 24 18:10:09 what else Nov 24 18:12:55 hmm using the ping trick i get an mtu of 1460 Nov 24 18:14:47 makes sense cause the ipv6 header is 40bytes? Nov 24 18:18:07 i think the 1412 mtu is the mtu used by the atfr gateway Nov 24 18:42:39 hmm, having issues with uclient Nov 24 18:42:54 was attempting to debug issues with proxy use on http redirects Nov 24 18:43:04 but it seems that http redirects are completely broken to begin with Nov 24 18:44:39 nvm, that brokeness stems from proxy interaction Nov 24 19:34:19 anyone here expierence with Marvell DSA switches? Nov 24 19:35:00 https://github.com/openwrt/openwrt/pull/1561/files Nov 24 19:35:12 this loogs legit imho and will likely cause a lot of hard-to-debug issues Nov 24 19:35:15 *lloks Nov 24 19:35:18 **looks Nov 24 19:35:26 really can't type at all today Nov 24 19:48:22 jow: looks like a change that should go through upstream first Nov 24 19:50:49 KanjiMonster: how to approach that? just send the patch using a sob and reported-by to the lkml? Nov 24 19:52:14 I could imagine that upstream does not like disabling this hw capability Nov 24 19:52:25 jow: ideally the person doing the PR does that, with a better explanation what the issue is, and what the symptoms are Nov 24 19:54:15 they might not like this change, but they likely have a better understanding what is happening and maybe have a different workaround/knob without disabling learning entirely Nov 24 19:55:59 disabling learning will likely mean the switch works like a hub and floods all traffic to all other ports Nov 24 19:59:57 he implied some kernel based mac learning Nov 24 20:00:28 what was that process to figure out the related maintainers for a given .c file? Nov 24 20:00:44 Wasn't there some magic which somehow uses the MAINTAINERS etc. files? Nov 24 20:01:12 ./scripts/get_maintainer.pl or so Nov 24 20:01:17 KanjiMonster: got a present for you :) https://github.com/openwrt/packages/pull/7507 Nov 24 20:01:25 thanks! Nov 24 20:02:32 mangix: already saw it and started looking at it (the CPEID thingy could have been a separate commit because its unrelated, but not worth a respin) Nov 24 20:03:38 jow: this good? https://github.com/openwrt/packages/pull/6621 Nov 24 20:10:36 jow: KanjiMonster: In the lantiq switches you can fix a mac address to a port, so that the switch will not "learn" it on any other port, it could be that the marvell switch also has such an option Nov 24 20:12:44 mangix: hmm, I wonder if we could shrink that no docs/tests patch by using PKG_REMOVE_FILES:=doc/local.mk man/local.mk tests/local.mk Nov 24 20:13:39 Hauke: that sounds like it would cause roaming issues because the switch wouldn't be able to update its ARL table if da device moved from port a to port b Nov 24 20:15:18 KanjiMonster: yes by default this is deactivated in the lantiq switches, but you can switch a feature on to make the switch not learn a mac address on a different port when it was already learned somewhere else Nov 24 20:15:41 it could be that this is also configurable in the marvell switches and the other side is the default option Nov 24 20:15:51 this problem should be raised to the maintainers Nov 24 20:16:06 mangix: try with just this. If make aborts due to these missing include files, you could do something like define Build/Prepare \n $(call Build/Prepare/Default) \n \t touch doc/local.mk man/local.mk tests/local.mk \n endef Nov 24 20:20:09 KanjiMonster: commented on that pr and told the guy who to approach Nov 24 20:21:39 ah, there is actually some description of the issue, but its in the pr message, which would be lost once its accepted Nov 24 20:27:55 hmm... who pushed 2ac1a57677ce4e21513dca2a8efab1eb6e0a9c58 ("base-files: fix unkillable processes after restart") ? Nov 24 20:28:13 it shows a committer not in our allowed accounts Nov 24 20:28:44 it was likely rewritten but I want to know for sure Nov 24 20:37:39 Package kmod-nf-conntrack is missing dependencies for the following libraries: nf_defrag_ipv6.ko ??? Current git master but with external linux-4.14.61 kernel. Nov 24 20:39:50 seems the external kernel introduces objects not present in master Nov 24 20:40:18 jow: https://github.com/openwrt/openwrt/pull/1557 would suggest you but clearly that isn't the case. Nov 24 20:41:40 ldir: uhm actually I did, but from a new machine, have to check my git settings there Nov 24 20:43:20 jow: ok. Nov 24 20:43:52 ldir: really need to work on my attention span... I guess I shouldn't do stuff in a minute between two other tasks ;) Nov 24 20:45:45 ldir: now I recall, I used the usual git pr script of mine but somehow the PR branch didn't cleanly rebase against master so I fiddled around, rebasing manually etc. until eventually ff merging the branch, I guess this is when the committer got rewritten Nov 24 20:46:58 lol Nov 24 20:47:38 Rene__: nf_defrag_ipv6.ko should be part of kmod-nf-conntrack6 Nov 24 20:47:56 Rene__: in theory it should be as simple as letting kmod-nf-conntrack depend on kmod-nf-conntrack6 Nov 24 20:48:21 Rene__: but I see in the current sources that kmod-nf-conntrack6 already depends kmod-nf-conntrack, so apparently we havbe some sort of circular dependency here Nov 24 20:48:41 Rene__: didn't really look in detail though Nov 24 20:49:42 Rene__: maybe its also finally not possible anymore to cleanly separate ipv4 and ipv6 conntrack and we should lump them together into one common kmod Nov 24 20:49:57 *common kmod package Nov 24 20:51:49 Rene__: I see this problem with kernel 4.19, but I am not aware that the changes are already in 4.14 Nov 24 20:55:39 Hauke: so there's indeed a circular dep? Nov 24 21:05:43 jow: for kernel 4.19 I moved nf_defrag_ipv6.ko to kmod-nf-conntrack Nov 24 21:05:59 but I think this was introduces after 4.14 Nov 24 21:11:30 jow: blogic what is the status of ath79, should we remove the source only flag: https://github.com/openwrt/openwrt/pull/1546 Nov 24 21:24:01 jow: thanks for the info. Nov 24 21:25:21 I was hoping that I could take openwrt buildroot and use external linux kernel net-next source to do some developements for MT7621 ethernet driver Nov 24 21:28:04 Rene__: did you get the problem with nf_defrag_ipv6.ko when using net-next ? Nov 24 21:30:42 Hauke: Not sure. Nov 24 21:31:07 Currently getting t/mediatek/mt7530.c:959: undefined reference to `register_switch' Nov 24 21:31:10 make[5]: *** [Makefile:1020: vmlinux] Error 1 Nov 24 21:31:46 This is with the "internal" linux-4.14.82 kernel Nov 24 21:37:07 Hauke: copied the buildroot env and now compiling it again with external source linux kernel net-next. Nov 24 21:43:53 Hauke: yes please Nov 24 21:53:25 Hauke: Yes Nov 24 21:55:05 Rene__: net-next is based on top of kernel 4.21 so you should probably look at the code adding support for kernel 4.19 Nov 24 21:55:42 https://paste.debian.net/1053121/ Nov 24 21:56:13 jow: I would like to merge the openssl update to version 1.1.1, this changes the ABI Nov 24 21:56:17 Rene__: try this: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/kernel-4.19 Nov 24 21:57:01 jow: will the packages in the feeds be automatically rebuild and if not should we do anything about that? Nov 24 22:04:12 Hauke: I check it out thanks. My current goal is/was, Add support for MT7621 ethernet to mainline kernel driver. Nov 24 22:04:50 I do have a working version in 4.14. Nov 24 22:07:26 But to make SFP port more useful I need PHYLINK and convert all the driver to PHYLINK. So that means I need convert MT7621 ethernet driver, MT7530 DSA switch driver and the external phy driver at8033 to PHYLINK. Nov 24 23:21:32 Hauke: how urgent is the update? ideally I'd like to review the situation in closer detail tomorrow or monday Nov 24 23:22:13 Hauke: theoretically the ABI_VERSION tag should take care of the rebuilds but since packages using openssl will see no version bumps, there won't be opkg update notification Nov 24 23:22:58 Hauke: basically we'd need to bump all packages using openssl in some way or another Nov 24 23:23:35 bbl Nov 24 23:26:51 jow: this is not urgend, but I would like to get this in before the release Nov 24 23:27:17 jow: here is the pull request: https://github.com/openwrt/openwrt/pull/965 Nov 24 23:54:05 any chance for "[PATCH v3 0/4] base-files: add new backup options" (http://lists.infradead.org/pipermail/openwrt-devel/2018-August/013633.html) getting merged? it's not my patch series, but I've been using it and its predecessors for well over a year with good results (makes config deltas much more obvious and smaller) **** ENDING LOGGING AT Sun Nov 25 03:00:00 2018