**** BEGIN LOGGING AT Wed Jun 10 02:59:57 2020 Jun 10 03:30:33 build #322 of layerscape/armv7 is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/322 blamelist: Petr ?tetiar , Perry Melange , Daniel Golle , Joseph C. Lehner , Jun 10 03:30:33 Christian Lamparter Jun 10 04:24:52 lmore377, several devices with qca8337 exist in DTS for ath79 - maybe you find some useful information there - they use mdio node there i think Jun 10 04:25:01 look in dir target/linux/ath79/dts/ Jun 10 05:22:26 most (all?) ipq806x devices use qca8337 as well Jun 10 05:55:32 do we use this in hostapd: http://lists.infradead.org/pipermail/hostap/2020-June/041778.html ? Jun 10 05:56:23 apparently not, good Jun 10 05:58:59 pkgadd that's the weird thing. The R7500 has the same switch but whenever I boot I get 4 lines that say "Failed to connect to the switch. Use the "list" command to see which switches are available." I also see a lot of "mdio-gpio soc:mdio: ignoring dependency for device, assuming no driver" in various parts of the kernel log Jun 10 06:01:14 lmore377: there have been quite a few DTS changes between 17.07.x/ kernel 4.4 and current master kernel 5.4 - there will be even more changes necessary between QSDK (the basis for the DTS you salvaged from your running OEM firmware) and OpenWrt Jun 10 06:02:22 (but I don't consider myself to be overly fluent in device tree details myself) Jun 10 06:05:12 pkgadd alright I'll just keep messing around with things to see if I can get anywhere. Also, I'm building openwrt with the 4.19 kernel because there was a patch in 5.4 that broke pci if you were using initramfs which is what I've been using because the mtd partition layout is a bit confusing and I don't want to mess up the router. Jun 10 06:07:02 this is what I'm talking about: https://forum.openwrt.org/t/askey-rac2v1k-support/15830/23 Jun 10 06:09:35 nevermind about the mdio errors. I went back to a older version of the dts I'm making and they're gone. Jun 10 07:40:17 so the router I'm porting to has a single external led that can be red and/or blue and do different things like blink or pulse. It's controlled by 3 gpio pins based on how you turn them off (Example: 0 is off, 1 is on; 011 = solid blue ; 010 = blue pulse ; 100 = red pulse). How would I define something like that in the dts file? I tried this but the end result was that /sys/class/leds was empty: https://pastebin.com/VaKkC7y0 Jun 10 08:21:08 How do I *hide* a pkgconfig package that might happen to be in the staging dir (if it happens to have been built), so that my own package doesn't automatically pick up a dependency on it? Jun 10 08:38:23 dwmw2_gone: you can't Jun 10 08:39:12 if your package is autoconf based, you can try setting magic cache variables (ac_cv_*) to prevent it from picking up pkg-config values Jun 10 08:39:32 it's cmake Jun 10 08:39:46 I tried -DLIBBSD_FOUND=OFF Jun 10 08:40:11 I'll just submit a patch upstream for disabling Jun 10 08:40:22 Figured we might have a standard way to achieve it. Jun 10 08:51:22 stintel: df6a33a8d411 Jun 10 08:53:12 ynezz: cool, but seems it's not relevant as we don't use CONFIG_WDS_UPNP or what was it Jun 10 08:54:15 anyway, safer to have it patched before new drama arrives :P Jun 10 09:32:32 lmore377: can you try all 8 combinations please? That might provide more insight into how the leds are really connected. Jun 10 09:49:38 nick[m]: any thoughts on the dawn updates? I can push those if you're happy. Jun 10 09:59:14 lmore377: i think you may need dedicated driver for that Jun 10 09:59:45 lmore377: plus dedicated DT binding Jun 10 10:01:18 lmore377: after thinking about it, it doesn't seem to fit LEDs subsystem :| Jun 10 10:01:44 lmore377: i'd suggest posting e-mail to linux-leds@ Jun 10 10:01:48 dwmw2_gone: sry. I had no time yesterday Jun 10 10:01:52 I will look into this Jun 10 10:03:25 lmore377: probably 101 will give solid red and so you can just define the right bit to be always 1 and expose them like two normal leds? Jun 10 10:07:44 sigh, that mvebu subtarget discussion is still going on Jun 10 10:08:06 what about simply dropping these old mvebu devices and go with neon / d32 Jun 10 10:09:03 since the same crows usually does not care about less capable targets anyway it should be fine to drop first gen 1900ac and that weird linkstation (litestation?) thing Jun 10 10:09:08 *crowds Jun 10 10:11:14 dwmw2_gone: looks awesome Jun 10 10:11:15 https://github.com/openwrt/luci/pull/4147 Jun 10 10:11:17 thank u! Jun 10 10:12:25 want to pull https://github.com/berlin-open-wireless-lab/DAWN/pull/98 too and I'll update the openwrt package? Jun 10 10:12:27 (of dawn) Jun 10 10:12:36 for luci we have to rely on others still. Jun 10 10:13:35 dwmw2_gone: would be great, but could u change your commit message? :) Jun 10 10:14:08 then I directly merge that into master Jun 10 10:14:59 better ? Jun 10 10:17:44 yeah! sry, but I prefer this "module: commit message" style, so the git history looks somekind of okay :) Jun 10 10:18:09 yeah, sorry for missing that. Jun 10 10:18:58 I already merged. thanks for taking care of updating the package :) Jun 10 10:20:31 dawn-2020-06-10-bd35961d.tar.xz: Download from https://github.com/berlin-open-wireless-lab/DAWN.git failed Jun 10 10:20:32 dawn-2020-06-10-bd35961d.tar.xz: Wrong hash (probably caused by .gitattributes), expecting c85ff741ce29c11394ef0ccf37694d0e8e13fa1af8dcb30a92edbe10e38099c9, got bba0758b0906db4af1e6ee8884946747c1e728bf6a51c5fcbaf09e1f1b7e0bdc Jun 10 10:20:36 but it builds anyway. Jun 10 10:20:54 You just said thanks, so kind of redundant but: You're OK with me updating the package to bd35961d ? Jun 10 10:22:38 yep. Jun 10 10:22:39 bd35961d Jun 10 10:30:51 jow: patches welcome! :D Jun 10 10:45:00 nick[m]: pushed Jun 10 10:46:09 dwmw2_gone: can u push the luci package too? :D Jun 10 10:46:26 oh man, I'm trying to build xfrm on 19.07.3 Jun 10 10:46:28 I can't. Want to drop your pull request and comment on mine that you ack it? Jun 10 10:46:38 however, it looks like I can't Jun 10 10:46:38 or just update yours with my version and I'll drop mine; whatever. Jun 10 10:46:48 then we can get someone to pull that into luci.git Jun 10 10:46:51 Depends on: IPV6 [=y] && PACKAGE_kmod-ipsec [=m] && !LINUX_4_14 [=y] Jun 10 10:46:56 it appears to be blocked on 4.14 Jun 10 10:47:04 if I read this right? Jun 10 10:50:40 ynezz: I'm just annoyed by that pointless micro optimization crap Jun 10 10:51:31 johnf: you're reading that wrong. xfrm does not exist on 4.14 Jun 10 10:51:41 that's why it depends on *not* kernel 4.14 Jun 10 10:51:43 a subtarget here, a subtarget there Jun 10 10:52:20 while we're at it, why not introduce a dozen x86 subtargets to optimally support any intel and amd cpu architecture since 686 Jun 10 10:53:06 I still think we should find a way to offer this to people who want it, but without us building it Jun 10 10:53:45 and without them having to maintain it out of tree Jun 10 10:53:56 head to menuconfig, adjust target optimization Jun 10 10:54:03 that's what I was abaout to suggest. Jun 10 10:54:27 local builders have always been able to tweak it Jun 10 10:54:33 its not about local builders Jun 10 10:54:42 they actuaslly want to offload this optimization work to us Jun 10 10:55:11 throwing -march= in EXTRA_OPTIMIZATION can break nastily because changes to it do not rebuild everything Jun 10 10:55:14 the main driver is that they want a complete binary package reposository tailored for such minor cpu optimizaitons Jun 10 10:55:35 so you can end up with -march=ivybridge binaries on an AMD jaguar Jun 10 10:55:39 *poof* Jun 10 10:56:29 jow: ask them if they can offer some extra permanent build slaves and extra mirror storage. it'll silence them :) Jun 10 10:56:42 no, it will not Jun 10 10:57:27 they will run around and shout about how openwrt is intentionally crippling their hardware, that its not the best choice anymore, that we intentionally raise contribution hurdles, that we're incompetent, arrogant, clueless Jun 10 10:57:53 does anyone take such drama queens serious? Jun 10 11:00:34 stintel: hmm, interesting, I think it was backported though Jun 10 11:01:30 oh, no, you are quite right Jun 10 11:01:36 stintel: unfortunately, yes. Jun 10 11:02:05 disproving claims takes far more work than making them, even though of course the burden of proof should be on the claimant Jun 10 11:02:17 it is present in 4.19 Jun 10 11:02:19 hmm Jun 10 11:04:11 jow: we now have ca9, they want to add ca9_neon and likely ca9_tiny and ca9_neon_tiny... Jun 10 11:04:29 yes Jun 10 11:04:45 and maybe we even restart the mips 24kc vs 74kc discussion Jun 10 11:07:46 can people build for these sub architectures if they want to? Jun 10 11:07:56 yes, but they can't use opkg then Jun 10 11:08:19 lol, yes, I know all about not being able to use opkg Jun 10 11:08:30 except if they provide their own package repository Jun 10 11:08:44 thats not correct Jun 10 11:09:04 ca9_neon packages are available Jun 10 11:09:14 what is the problem thne actually? Jun 10 11:09:21 they could simply change opkg.conf Jun 10 11:09:37 or is it about having a fine tuned kernel? Jun 10 11:09:42 speeeed! Jun 10 11:09:55 with gold plated power plugs for better wireless singal quality Jun 10 11:10:00 smoother radio waves Jun 10 11:10:32 well but the discussion is about FP registers, right? Jun 10 11:10:50 afaik there isn't any FP code in the kernel, so the amount of FP registers shouldn't matter for kernel perofmance Jun 10 11:11:00 hey, count yourself lucky. In the Cygnus days we used to insist on giving them a new version of GCC tuned for each CPU :) Jun 10 11:11:37 dwmw2_gone: done. sry, I hope I don't miss important infromation. sometimes this irc chat is very busy. ;) Jun 10 11:13:33 nick[m]: no problem. I'm capable of repeating myself when I need to... and certainly rely on others to do the same :) Jun 10 11:14:20 nick[m]: Did you see I mostly got the MAC vendor lookup working? Jun 10 11:14:39 makes a ubus call to a 'macvendor' service with a list of MACs to look up, then adds them in the UI Jun 10 11:15:08 speaking of the UI, as a user I really do like what we see on the 'Associated Stations' section in the main luci overview page. Can we make the DAWN network map look similar? Jun 10 11:15:10 dwmw2_gone: no. where is the code? :) Jun 10 11:15:50 yes of course Jun 10 11:16:01 emacs /root@garden.infradead.org:/usr/lib/lua/luci/model/cbi/dawn/dawn_network.lua :) Jun 10 11:17:11 we have to think about the update frequency of the data we provide Jun 10 11:18:10 sry, what does the emacs cmd do? Jun 10 11:18:41 it logs into my test AP as root and just edits the file in-place there :) Jun 10 11:19:01 http://david.woodhou.se/dawn-show-mac-vendor.patch is (roughly; I think I fixed it since) the dawn_network patch Jun 10 11:19:31 Needs http://david.woodhou.se/macvendor to be completed to actually do the lookups and then put in /usr/libexec/rpcd Jun 10 11:19:36 I'll need to make a separate package for that. Jun 10 11:19:40 and it can be optional. Jun 10 11:19:45 the emacs cmd does nto work for me :/ but the patchfile Jun 10 11:19:50 (which is one of the things I fixed in the dawn_network.lua patch) Jun 10 11:20:03 don't apply that yet; it's just a proof of concept Jun 10 11:20:58 k. Jun 10 11:22:02 So actually, I will get Signal / Noise, RX Rate / TX Rate from clients and distribute them Jun 10 11:22:40 '866.7 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 2, Short GI Jun 10 11:22:40 780.0 Mbit/s, 80 MHz, VHT-MCS 8, VHT-NSS 2, Short GI' Jun 10 11:23:40 well I guess I am glad I don't frequent the forum Jun 10 11:23:44 is what it says for... I think that's my laptop. The main luci overview also manages to show me that it's 'dyn-225.woodhou.se (90.155.92.225)' Jun 10 11:24:17 yeah Jun 10 11:24:18 that is a luci plugin Jun 10 11:24:37 I had this already in my luci-app years ago Jun 10 11:24:44 I mean luci library Jun 10 11:24:54 does not work all the time Jun 10 11:25:10 Is there a reason we shouldn't aim for dawn to be able to replace the standard 'Associated Stations' view in the main page, when dawn is running? Jun 10 11:26:23 it only works when running on the box which has the DHCP server, I think. Jun 10 11:26:42 So it's only reporting Legacy IP and DHCPv6 not IPv6 addresses learned by RA. Jun 10 11:27:18 in fact not even dhcp67 Jun 10 11:29:38 you mean the luci app should override the "associated stations" sector? I think this is fine. Jun 10 11:29:49 yeah Jun 10 11:30:02 At least, I think we should aim to be able to propose this with a straight face. Then it's a little bit up to others. Jun 10 11:30:11 but I think it's reasonable. Jun 10 11:30:19 would be fine* Jun 10 11:31:44 in fact I wonder if we could do it behind the scenes without even changing the luci UI code. Just provide additional data? Jun 10 11:32:16 Some might need to lack the 'Disconnect' button, perhaps. Jun 10 11:32:29 unless we make that a link to the right AP, since we know the hostname :) Jun 10 11:32:35 they'd still need to authenticate Jun 10 12:01:38 Package perf is missing dependencies for the following libraries: Jun 10 12:01:38 libzstd.so.1 Jun 10 12:09:41 jow: arch cortexa9_neon already exists, so I just wanna reuse it Jun 10 13:51:53 if I want the stability of 19.07 Jun 10 13:52:04 but I need a newer kernel Jun 10 13:52:23 do I have an option other than building from the current snapshot? Jun 10 13:54:23 no Jun 10 13:55:19 thanks jow Jun 10 13:55:25 dengqf6: yeah, I understand that - but the more I think about it, the more it seems to me that it is more a matter of being able to use neon-compiled packages. The kernel itself and the entire core userland will likely not benefit at all Jun 10 13:55:57 blogic: In 19.07 there is a target/linux/mediatek/patches-4.14/0027-net-next-mediatek-fix-DQL-support.patch which I don't see having been merged upstream Jun 10 13:56:01 dengqf6: as I understand it, we essentially introduce a completely different subtarget with all the associated bloat etc. just so that opkg.conf points to a vfp-d32 repo by default Jun 10 13:56:07 And the Banana Pi R2 patches *remove* it, blaming it for TX stalls Jun 10 13:57:13 i have major problems with an rtl8812au based wifi usb stick. kmod-rtl8812au-ct is loaded and 'iw phy' shows the device as 'phy0'. but 'iw dev' shows not device 'phy#0'. just phy#1 and phy#2 are present. Jun 10 13:58:04 try adding an virtual device with "iw phy0 interface add wlan0 type managed" fails with "command failed: No such device (-19)" Jun 10 14:10:55 seems the source for kmod-rtl8812au-ct is this > https://github.com/greearb/rtl8812AU_8821AU_linux . and the version/commit is from november 2018 Jun 10 14:11:44 does anyone own an rtl8812au device and could test is the problem is reproduceable? Jun 10 14:16:49 how much pain/time would you expect trying a more recent version or even this? > https://github.com/aircrack-ng/rtl8812au Jun 10 14:17:35 someone seems to have added Openwrt build compatibility https://github.com/aircrack-ng/rtl8812au/commit/28a8d26f11918b18871cb7ee6ba0cff329f1b7ee Jun 10 14:40:27 hmm, +@DRIVER_11AX_SUPPORT is wrong, isn't it? either + or @ ...? Jun 10 14:55:31 + and @ can be combined Jun 10 14:55:46 (and they are combined for other features like that in the same file) Jun 10 15:02:19 i also thought about some dependency missing. there is also no error in the kernel log. Jun 10 15:03:40 should i try setting PACKAGE_RTLWIFI_DEBUG ? what/where does it debug stuff? Jun 10 15:06:34 this seems to be only for rtlwifi, which is a driver for older rtl devices? Jun 10 15:19:56 nbd: thanks and sorry. Wasn't aware that it was possible to actually set a config symbol this way Jun 10 15:21:02 it is also discouraged for non-core, non-kmod packages Jun 10 15:21:59 okay, that's most probably also the reason why it's not mentioned in https://openwrt.org/docs/guide-developer/packages#dependency_types Jun 10 15:27:14 the problem is the resulting conditional compilation. In case of kmods it is acceptable since we build with all kmods enabled in buildbot, causing the complete optional feature set in the kernel hostapd etc. to be enabled Jun 10 15:27:53 and it makes sense to not e.g. include ax support in, say, hostapd for ar23xx Jun 10 15:30:01 hmm, so that implies it could be a problem if only some kmods would be built in a custom setup? Jun 10 15:30:19 (just asking for a better understanding) Jun 10 15:31:53 yes Jun 10 15:32:10 well for kmods, your custom, feature-reduced kernel will be incompatible with the repo kmods anyway Jun 10 15:32:46 but one common example was mdadm iirc. It some point, async IO support was made optional in the kernel and disabled by default Jun 10 15:33:09 then mdadm was changed to DEPENDS:=+@KERNEL_ASYNC_IO (or however that symbol is called) Jun 10 15:33:41 when people built custom images without mdadm built in or enabled as during the build, then resulting kernel had no async IO support Jun 10 15:33:50 if we don't want to include ax support in some targets, i think we should simply not build the ax kmod packages there by default Jun 10 15:34:05 when they then later installed mdadm from the repo and trying to run it, it failed with ENOSYS errors Jun 10 15:34:27 * hell__ suggests bundling a literal ax as well, just in case Jun 10 15:34:50 tl;dr - kmods enabling kernel features is tolerable since there is a tight coupling between kmod and kernel version anyway Jun 10 15:35:09 userspace packages enabling kernel features is usually not okay, except on a few rare occasions Jun 10 15:35:52 likewise kmods enabling userspace package features can be problematic but usually it works fine since the official images and binary repos are built with all kmods enabled anyway Jun 10 15:37:48 I see. So, for an image built from a custom set of kmods and packages, this would only become relevant when I want to install packages from the repo afterwards. But the building itself and the integrity of the image as-is wouldn't be affected ... Jun 10 15:38:01 right Jun 10 15:38:06 okay, thanks Jun 10 15:39:15 the same considerations also apply to userspace packages enabling features in other userspace pacakges Jun 10 15:39:41 e.g. attempting to select-enable certain busybox applets Jun 10 15:42:58 PaulFertser: looking at the board closer, it looks like they're connected to a microcontroller. They go directly to a small black chip labelled T6BP9A16 which doesn't show up on Google search at all. https://photos.app.goo.gl/bjuy6QLMTarNrQZ79 Jun 10 15:43:36 lmore377: interesting. But 3 GPIOs is still 8 combinations Jun 10 15:43:37 rmilecki: Jun 10 15:47:59 Yeah I already figured out what combinations do what. https://pastebin.com/2qYUGnfy Jun 10 15:49:34 lmore377: I would treat it as two regular LEDs then, solid blue and solid red. The middle bit would be set to 1 always. Jun 10 15:50:02 Oh, it'll pulse blue then when both are turned off. Jun 10 15:51:39 PaulFertser: I think I'll just deal with the LEDs later. I think I'm close to getting Ethernet working Jun 10 15:55:46 lmore377: the problem is that led subsystem assumes every LED can be turned on/off at any time (at least I believe so) Jun 10 15:56:52 lmore377: got a board picture at all? Jun 10 15:57:37 Give me a minute. I'll upload some Jun 10 15:58:27 jow: dengqf6: introduction of new subtarget = additional build resources (~1h build time, disk space), maintenance (kernel bumps etc.), support (possibly different bug reports) Jun 10 15:59:27 jow: dengqf6: what do we get in exchange? (false) feeling, that the OS is tightly optimized for that CPU? Jun 10 16:02:49 one subject are ca9_neon packages (available), another is mvebu_ca9_neon subtarget (new), likely growing to mvebu_ca9, mvebu_ca9_neon, mvebu_ca9_tiny, mvebu_ca9_neon_tiny in the future due to 3M kernel partition on some devices Jun 10 16:03:12 karlp: https://photos.app.goo.gl/bjuy6QLMTarNrQZ79 Jun 10 16:06:37 Do you want pictures of the pcie Wi-Fi card too? Jun 10 16:07:20 nah, just curious Jun 10 16:07:32 does it have both slots populated with wifi cards by default or just one? Jun 10 16:15:44 it's actually one giant wifi card that you can problably split into 2 with a saw. I uploaded a picture to that same link so you can see how weird it is Jun 10 16:16:57 and yes I literally mean you can cut it in half. I dont know how many layers the pcb is but the only thing visibly shared between the two is the ground plane Jun 10 16:35:57 nice looking unit Jun 10 17:02:19 alright so I finally got ethernet working, but I don't know how to configure the switch. the wan port is a lan port and the last lan port is the wan port. also the dhcp server is only handing out ipv6 adressess so I don't know what's up with that Jun 10 17:23:14 lmore377: you can do "swconfig dev switch0 show" and plug in cables in different ports and that will allow you to see the switch ports to physical ports mapping. Jun 10 17:34:33 dwmw2_gone: yes, MTK is working on it Jun 10 17:34:52 dwmw2_gone: they are very good citizens and are actively pushing stuff upstream Jun 10 17:35:09 dwmw2_gone: they send some of the fixes to me as backports prior to them going upstream Jun 10 17:35:45 dwmw2_gone: currently getting their hw offload upstream with pablo@netfilter, MTK is actively supporting is with testing and feeding of inside register info Jun 10 17:36:02 dwmw2_gone: they are actually an example of how to do it right Jun 10 17:36:21 i also pressured them to send V2 of the DSA series Jun 10 17:36:40 and they will push the EIP97 code i merged in the coming week (TM) Jun 10 17:38:45 https://pastebin.com/WXxpNuW9 Jun 10 17:38:55 bdfiles and caldata script missing from rootfs Jun 10 17:39:06 BUT its finally happening :-D Jun 10 17:39:23 got the hapd script all ready for AX. to be continued Jun 10 17:39:55 making the Q6 hexagon boot was a flippin pita Jun 10 17:40:16 802.11ax? Jun 10 17:40:21 yup Jun 10 17:40:22 vanilla Jun 10 17:40:23 neat Jun 10 17:40:30 5.4 kernel with 5.7 wifi Jun 10 17:40:48 :) Jun 10 17:41:00 and a mediatek platform? Jun 10 17:41:13 ... coming soon :-D Jun 10 17:41:25 MTK is also looking into the possibility of not building a proprietary driver for future chipset generations Jun 10 17:41:33 nbd: AND Jun 10 17:41:43 7915 and the 6G chip are pin compatible Jun 10 17:41:58 so ODMs can simple swap the chip on the PCBs Jun 10 17:42:02 nice Jun 10 17:42:05 yes Jun 10 17:42:10 they are smart as a fox Jun 10 17:42:33 i'm currently working on code to allow manufacturers to start calibrating their devices with mt76 Jun 10 17:42:47 yup Jun 10 17:42:51 nbd: wow. Jun 10 17:42:52 are you using FTM ? Jun 10 17:43:02 i was thinking that we can build a uftm tool Jun 10 17:43:11 not yet. first step is continuous tx Jun 10 17:43:13 i already know the WMI calls for FTM on 1th11k Jun 10 17:43:22 and some rx/tx calibration steps Jun 10 17:43:31 but you need to kick it somehow so might aswell use FTM ? Jun 10 17:43:41 or am I missing summin here ? Jun 10 17:43:52 FTM is just nl80211 calls Jun 10 17:44:04 s/is/are/ Jun 10 17:44:35 anyhow, need to take the annoyance to bed and hit the sack myself, started at 4:30 if a call with a fab in TW Jun 10 17:46:04 :) Jun 10 17:54:23 blogic: nice to see Mediatek getting it right Jun 10 17:54:44 I have some patches here to add a mt7623n-preloader and then make sdcard/emmc images Jun 10 18:31:34 dwmw2_gone: send them Jun 10 18:33:29 dwmw2_gone: and thanks for the mdns fix for ipv6 Jun 10 19:37:33 hi Jun 10 19:38:37 anyone some idea how to debug sysupgrade failing to upgrade my Zyxel NBG6817 from 5.4.43 to 5.4.45 ? Jun 10 19:59:25 does ubus have any boot time debugging functionality? I appear to have a regression (either procd or ubus) in my latest x86_64 build from head.....it fails to boot Jun 10 19:59:40 no Jun 10 19:59:49 apart from whats in the system log Jun 10 19:59:57 did you try a dirclean already? Jun 10 20:00:02 procd is giving me some not very helpful debug output that Instance ubus::instance1 exit with error code 65280 after 0 seconds Jun 10 20:00:07 yes i did a dirclean Jun 10 20:00:09 twice Jun 10 20:00:29 nothing in the logs as it fails to even get past the procd - init - state change Jun 10 20:00:35 boot failure Jun 10 20:00:41 so ubusd is crashing during early boot Jun 10 20:00:45 yes Jun 10 20:01:59 i maxed out the procd debug level, but it just gets to the point where it repeatedly respawns ubusd in a loop and spews out this error code of 65280 Jun 10 20:02:48 so that likely means the process exited with -1 Jun 10 20:03:14 ok. looks like i need to instrument ubusd with some debug messages Jun 10 20:03:45 to me it looks like ubusd is not starting at all Jun 10 20:03:55 missing library, miscompilation, segfault etc. Jun 10 20:04:12 ah, yes perhaps Jun 10 20:04:36 i did not notice any segfault during the boot though, although it may not display anything if that's happening anyway Jun 10 20:05:15 the build i'm using is the same as one from two weeks ago with no changes to the config, so i don't think i've introduced any new functionality that should cause a failure Jun 10 20:05:30 just did a merge of the latest commits and a rebuild Jun 10 20:05:56 did you run "make defconfig" ? Jun 10 20:06:27 i did....i think i'll try a default build next just to see if it boots Jun 10 20:07:31 there's some suspicious commits Jun 10 20:07:36 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a765b063ee3e1dd6519f6a4a9e4d4f72214b33b8 for example Jun 10 20:07:45 that is directly related to the code in question Jun 10 20:08:06 and my previous build was the day before that commit... Jun 10 20:08:26 also this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f47aeac9b9d836b265eb10fa89c7411e6ed39f93 Jun 10 20:09:10 i don't think it's procd - i reverted procd to the same version as my previous build and still got the error Jun 10 20:09:39 i'll try revert that libubox commit and see if it makes any difference Jun 10 20:11:02 thanks jo Jun 10 22:36:17 Hi people what are the down sides of this https://github.com/openwrt/openwrt/pull/3079#issuecomment-642289268 Jun 10 22:40:53 Tapper: typical bureaucracy Jun 10 22:42:18 mangix diizzy wanted to do the same thing in 2019 and there was push back then I don't get it. If some just said what was rong with it people would stop asking about it. Jun 10 22:44:07 Original reason AFAIK was the introduction of a new target. Today, that target is present. Jun 10 22:44:59 again, typical bureaucracy. I have dozens of patches that never got merged. Jun 10 22:46:35 ROFL I was looking for a specific link and found this https://news.ycombinator.com/item?id=7964486 Jun 10 22:46:51 I think he has Mediatek and Allwinner reversed **** ENDING LOGGING AT Thu Jun 11 02:59:59 2020