**** BEGIN LOGGING AT Sun Apr 05 02:59:58 2020 Apr 05 03:27:04 build #266 of rb532/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/rb532%2Fgeneric/builds/266 Apr 05 05:51:53 build #277 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/277 Apr 05 07:31:29 I've submitted the umdns patch that is fixing the compile error. I just added that to debug output, otherwise I could just remove that from the whole 2 functions. Apr 05 07:31:29 Is that okay? Apr 05 07:37:01 gch981213: so in the end we aren't using the upstream mtk mmc driver, right? Was wondering why, and if stbility issues with own mtk mmc driver where somehow fixed... Thanks! Apr 05 07:43:17 mrkiko: they are not Apr 05 07:44:27 mangix: thanks! Apr 05 07:45:00 I heard some discussion about switching to upstream one at some point, wonder what's happening, even tough I know the answer is in the code :D Apr 05 07:45:59 mrkiko: pinctrl driver need some fix. Apr 05 07:46:37 basically, it doesn't work with all devices Apr 05 07:46:59 gch981213: thanks!! Apr 05 07:47:30 gch981213: when you'll do MT7620 porting I may be able to help more - have a device with serial console for thatp latform Apr 05 07:47:50 mangix: thanks! Yeah, I remember something about this thing on a Huwei router supported by openwrt Apr 05 08:07:27 ldir: hey :) do you want me to send the umdns patch to the ML or will you handle it? Apr 05 08:08:05 PaulFertser: I've just pushed it Apr 05 08:08:30 and am working on a package bump to pick it up Apr 05 08:08:59 ldir: I've just barely compile-tested it, so no promises :) Thank you for taking care about the issue. Apr 05 08:10:28 It makes sense to me, can be reverted if it blows up :-) I'm running it and it appears to a) stay running b) answer some queries Apr 05 08:15:59 ldir: did you get mt DM? Apr 05 08:25:29 build #52 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/52 Apr 05 08:41:12 PaulFertser: oh and tapper built it and ran it, no screaming so far :-) Apr 05 09:28:03 pkgadd: thanks, very useful, only thing I found is most preinit scripts relay on MTD to fetch information such as CAL data Apr 05 09:45:04 build #358 of ath25/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/358 Apr 05 10:12:30 ldir Apr 05 10:12:30 PaulFertser: Hi yes that patch is running fine on my box. thanks. Apr 05 10:15:23 Tapper: thanks for testing. I usually trust compilers more than people (including myself). Apr 05 10:16:09 lol Apr 05 10:16:28 Happy to help to test. Apr 05 10:29:36 ldir: i just ran a build with your dropbear patch Apr 05 10:29:49 yes? Apr 05 10:29:59 should I run? Apr 05 10:30:14 i don't know if it's related, but just double checking. factory image, flashed through u-boot recovery. Apr 05 10:30:20 dropbear asks me for a pw Apr 05 10:30:27 on a clean install? Apr 05 10:31:26 The patch changes how it reports IP addresses on authentication failure.. it doesn't affect password/key handling at all. Apr 05 10:31:48 either way, this is a clean master build Apr 05 10:32:00 and Enter obviously doesn't cut it Apr 05 10:33:04 I don't know. The obvious thing to do is revert that commit and try without. Apr 05 10:33:33 smart thinking. i should have thought of that. i've just been tinkering with that effing ramips 5.4 bump for so long my head is gone Apr 05 10:34:15 I've had that commit in my tree for 6+ months... but then I use key auth, not password auth. Apr 05 10:37:57 and it's backported from upstream, now that it got accepted to upstream, so if it's b0rken, it's b0rken upstream and Matt won't be very happy :-) Apr 05 10:38:20 especially for a commit where he said "I like this" Apr 05 10:47:31 reflashing Apr 05 10:53:40 ldir: i was being a moron. had my test router still connected to the main network so i was still talking to my actual router instead of the testing one it turns out Apr 05 10:53:45 so nevermind me :-/ Apr 05 10:57:44 * ldir ignores Borromini Apr 05 11:16:29 :( Apr 05 11:32:04 not really! :-) Apr 05 12:07:31 * russell-- just flashed my two mt7621 devices (erx and dir860l) with 5.4.x, so far so good Apr 05 12:20:32 Hi what is the theme that openwrt ships with? Apr 05 12:20:47 I have bootstrap in my make menuconfig Apr 05 12:24:26 I am checking the openwrt-19.07.2-mvebu-cortexa9.manifest Apr 05 12:25:01 a OK it is bootstrap. Apr 05 12:27:27 build #56 of bcm63xx/smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/56 Apr 05 12:49:03 is it known that to build 5.4 toolchain /kernel for lantiq I need rsync? Apr 05 12:53:26 Tapper: You've got mail! Apr 05 12:57:41 ldir thanks. Apr 05 13:02:54 ldir Kicking off a build now. Will let you know! Apr 05 13:04:53 I don't know why it messed up like that After testing out that patch I did git am revert patch-file-name Apr 05 13:27:04 You could have done 'git reset --hard HEAD~' to lose the test commit Apr 05 13:29:25 ldir build is ok thanks. Apr 05 13:31:25 ldir I am going to do that now just encase lol Apr 05 13:33:30 no you don't need to now Apr 05 13:34:01 'cos the instruction I gave you in the email reset everything anyway Apr 05 13:46:36 anyone else having issues with dnsmasq on master since about two days ago? Apr 05 14:18:49 hello guys!! So i turned back to my effort to port a lantiq device - ar10 based AVM fritz3272 Apr 05 14:18:55 h198 Apr 05 14:27:06 *hw198* Apr 05 14:27:42 My question is - I am having problems with gphy gate clock not being found in ghpy.c; anyone can point me in where to look at? Apr 05 14:40:24 mrkiko: the clock defined in arch/mips/lantiq/xway/sysctrl.c has to match the device name of the gphy Apr 05 14:41:15 mrkiko: curently this is defined for ar10: clkdev_add_pmu("1e108000.gswip", "gphy0", 0, 0, PMU_GPHY); Apr 05 14:41:21 and this clkdev_add_pmu("1e108000.gswip", "gphy1", 0, 0, PMU_GPHY); Apr 05 14:42:35 the lantiq clock handling should be improved Apr 05 14:54:37 Hauke: thank you very very much ... Apr 05 14:56:04 Hauke: thank you; I'll look back at the dtsi Apr 05 14:56:24 Hauke: is this error enough to prevent ethernet from being started at all? Apr 05 14:56:34 Hauke: I think the answer is - yes - but just in case... Apr 05 15:00:01 yes, but there could be more problems ;-) Apr 05 15:01:01 Hauke: ok... i am going blind here, and I am very lucky martin fixed / read my DTSI at the time Apr 05 15:06:06 Hauke: ok, now I remember more when I got stuck; now I am at sysctrl.c, around line 544. last question - then I won't stress you again. In my dtsi file I can see some expectations of sysctrl.c are not matched. I don't know what the truth is so I should test and see... do you have suggestions for a general approach? My arx300.dtsi is at http://ix.io/2gK5 - the device DTS is at http://ix.io/2gK7 Apr 05 15:07:02 current status = device boots to an openwrt shell and tries to load gphy firmware, apparently it succeeds, but nothing more Apr 05 15:14:43 mrkiko: I would update the sysctrl.c Apr 05 15:15:52 I think the dts strcuture changed a bit in kernel 5.4 Apr 05 15:16:03 at least I moved the gphy driver in the upstream kernel again Apr 05 15:16:17 I haven#t looked how this is now done in OpenWrt in detail Apr 05 15:18:00 Hauke: yeah, I noticed. Infact I am doing this on 4.19 since when I tried to compile for 5.4 I saw other DTS files generated errors, like they wheren't ready yet. I am trying to focus on understanding, then I guess I'll be ableto face the transition. Apr 05 15:30:24 can't find the gpl blob for this device - I downloaded it once, but not on this PC Apr 05 15:54:54 mrkiko: I haven't looked at the kernel 5.4 integartion in OpenWrt yet Apr 05 16:07:13 Hauke: thank you. I'll keep trying to work on 4.19 for now, trying to make sense of the vendor gpl code Apr 05 17:04:21 Does OpenWRT have a test framework for the LTS kernels? That is, if there's a new kernel release, are there any automatic tests that make sure that the kernel didn't break anything? Apr 05 18:03:03 sashal: no Apr 05 18:39:53 gch981213: IIRC, that revert f0f35fdac19b4d3e40aa03928cbbac15a83837bf is going to make one ipq40xx device unbootable Apr 05 18:41:58 gch981213: and it was send upstream as you can guess from the filename 464-v5.6-mtd-spi-nor-Add-4B_OPCODES-flag-to-w25q256.patch and "patch backports the upstream patch" Apr 05 18:44:16 gch981213: so probably more work is needed to make everyone happy? :) Apr 05 18:44:53 sorry if this was discussed on the list and I've missed, but AFAIK there was no such prior discussion Apr 05 18:45:03 s/missed/missed it/ Apr 05 18:49:55 ynezz: He said w25q256fv and w25q256jv share the same JEDEC ID, and the former does not support 4B write op while the latter does Apr 05 18:51:08 whatever, revert is not solution in this case, it's just flipping the state of working devices Apr 05 18:51:23 ynezz: we need a hack to distinguish them, like mx25l25635e and mx25l25635f Apr 05 18:51:59 ynezz: using 3B will just break rebooting Apr 05 18:53:09 well, my 2nd point is, that it would be nice to let the commit author at least know, that something is happening Apr 05 18:53:51 otherwise if he's not following the commits closely, he's going to waste his time, figuring it out some time later when he finds it's broken Apr 05 18:54:58 from my point of view it wasnt properly communicated out as it should be, ideally this should be send out as a patch for discussion via mailing list and Cc: the commit author Apr 05 18:55:23 (but maybe it was done, I've just missed it) Apr 05 19:04:47 ynezz: https://patchwork.ozlabs.org/patch/1266406/ Apr 05 19:10:06 dengqf6: ok, seeing Robert in Cc: Apr 05 19:12:22 Rober Marco? Apr 05 19:21:19 Not this again?!? Apr 05 19:21:21 root@OpenWrt:~# opkg install luci-sslInstalling luci-ssl (git-20.094.46635-de52000-1) to root...Downloading http://downloads.openwrt.org/snapshots/packages/x86_64/luci/luci-ssl_git-20.094.46635-de52000-1_all.ipkCollected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-ssl: * libiwinfo20181126 * Apr 05 19:21:21 opkg_install_cmd: Cannot install package luci-ssl.root@OpenWrt:~# opkg install libiwinfoInstalling libiwinfo20200105 (2020-03-22-9f5a7c4f-1) to root...Downloading http://downloads.openwrt.org/snapshots/targets/x86/64/packages/libiwinfo20200105_2020-03-22-9f5a7c4f-1_x86_64.ipkConfiguring libiwinfo20200105. Apr 05 19:22:31 x64 snapshot Apr 05 19:22:34 root@OpenWrt:~# opkg install luci-sslInstalling luci-ssl (git-20.094.46635-de52000-1) to root...Downloading http://downloads.openwrt.org/snapshots/packages/x86_64/luci/luci-ssl_git-20.094.46635-de52000-1_all.ipkCollected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-ssl: * libiwinfo20181126 * Apr 05 19:22:34 opkg_install_cmd: Cannot install package luci-ssl. Apr 05 19:22:52 root@OpenWrt:~# opkg install luci-sslInstalling luci-ssl (git-20.094.46635-de52000-1) to root...Downloading http://downloads.openwrt.org/snapshots/packages/x86_64/luci/luci-ssl_git-20.094.46635-de52000-1_all.ipkCollected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-ssl: * libiwinfo20181126 * Apr 05 19:22:52 opkg_install_cmd: Cannot install package luci-ssl. Apr 05 19:23:24 Luci ssl wants to install 20181125 version Apr 05 19:23:24 root@OpenWrt:~# opkg install luci-sslInstalling luci-ssl (git-20.094.46635-de52000-1) to root...Downloading http://downloads.openwrt.org/snapshots/packages/x86_64/luci/luci-ssl_git-20.094.46635-de52000-1_all.ipkCollected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-ssl: * libiwinfo20181126 * Apr 05 19:23:25 opkg_install_cmd: Cannot install package luci-ssl. Apr 05 19:24:15 but available version is 2020-03-22 version Apr 05 19:24:15 root@OpenWrt:~# opkg install libiwinfoInstalling libiwinfo20200105 (2020-03-22-9f5a7c4f-1) to root...Downloading http://downloads.openwrt.org/snapshots/targets/x86/64/packages/libiwinfo20200105_2020-03-22-9f5a7c4f-1_x86_64.ipkConfiguring libiwinfo20200105. Apr 05 19:24:25 where can I place an init script only for one device? Apr 05 19:25:17 you mean for one peripheral for your device? Apr 05 19:26:35 acalvo: probably /etc/rc.d. Never done it. Apr 05 19:27:07 maybe /etc/board.d Apr 05 19:30:13 jmv2000: any advice would be great: have a device that only has eMMC (GPT) therefore most of the scripts to get data from MTD fail (uboot env, devinfo, ART...) Apr 05 19:30:55 hence the reason to add a dependency to block2mtd and send mtdparts as cmdline, and modprobe + set the mmcblk0 device to load from Apr 05 19:31:05 openwrt/target/linux/x86/base-files/.. Apr 05 19:31:09 (for some reason building the module into the kernel does not work) Apr 05 19:31:23 it's a IPQ40xx device Apr 05 19:31:45 ARM based Apr 05 19:32:42 openwrt/target/ipq40xx/base-files/etc/ Apr 05 19:32:52 ok, will try that Apr 05 19:34:11 not sure how exactly board.d hotplug.d and init.d and inittab work together. Apr 05 19:34:46 I'll try to use the preinit scripts in lib/preinit Apr 05 19:35:27 the other option was to patch the block2mtd package and set it to autoload at boot time.. but seems it will never get accepted in a PR for too dangerous Apr 05 19:40:06 would suggest to try to copy from other devices Apr 05 20:16:19 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Apr 06 00:04:25 build #254 of ramips/mt7621 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/254 Apr 06 02:02:52 ynezz: I'm porting the solution by nbd in ramips target. Apr 06 02:04:12 ynezz: W25Q256FV is read-only with that commit meaning users are forced to recovery their devices via u-boot. Apr 06 02:05:02 The result of reverting that commit is just devices with w25q256 got hang on reboot. **** ENDING LOGGING AT Mon Apr 06 02:59:58 2020