**** BEGIN LOGGING AT Sat Sep 26 02:59:57 2020 Sep 26 03:01:33 jow: https://bugs.openwrt.org/index.php?do=details&task_id=3363&order=dateopened&sort=desc Sep 26 03:05:39 Anyone got experience with gdb? Long-short, but hey, maybe :) Sep 26 03:09:20 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.) Sep 26 04:59:46 Hey Grommish . You have to be more specific. Sep 26 05:36:58 PaulFertser: :D I know.. I've been trying to dig Sep 26 05:38:18 I did find this, which looks.. odd.. Also, I'm not a programmer, so.. the file point returns a i/1fw as 0xffffffd7a0: 3.57331108e-43 Sep 26 05:38:25 which seems.. wrong.. for a float Sep 26 05:38:55 but a x/1dw returns 0xffffffd7a0: 255 Sep 26 05:39:03 so, i'm not sure what to think Sep 26 05:43:13 Grommish: what exactly are you checking? Sep 26 05:43:32 Grommish: is that the same SIGILL? Sep 26 05:43:40 Yes Sep 26 05:43:52 Grommish: so what does my command print once you stop there? Sep 26 05:45:23 => 0x120ea19cc : sdc1 $f24,8376(sp) Sep 26 05:45:49 the file pointer seems to be the issue Sep 26 05:46:34 I am in seriously deep over the head water with all of this, just so you probably already know :D Sep 26 05:46:38 What do you mean by "file pointer"? Sep 26 05:46:50 static long double decfloat(FILE *f, int c, int bits, int emin, int sign, int pok) Sep 26 05:47:05 decfloat (f=0xffffffd7a0, c=49, bits=53, emin=-1074, sign=1, pok=1) at src/internal/floatscan.c:67 Sep 26 05:47:24 that 0xffffffd7a0 returns the wierd float Sep 26 05:47:55 but i couldn't find another way to access the address other than x/1dw and x/1fw Sep 26 05:48:01 Grommish: does your target CPU have FPU? Sep 26 05:48:12 No.. it's software based and enabled Sep 26 05:49:06 I get 6 point precision on the time (as an example).. [ 44.620710] Sep 26 05:49:28 Grommish: there shouldn't be any need to enable FPU emulation in kernel as properly compiled (with softfloat) software will have all floating point operations handled by libgcc functions. Sep 26 05:50:02 CONFIG_SOFT_FLOAT is y and I put -S0 for testing along with the package debug Sep 26 05:50:15 err -O0 Sep 26 05:50:18 not S0 Sep 26 05:50:29 Grommish: what's special about your target? is this something already supported by OpenWrt upstream? Sep 26 05:51:00 Nothing special, and yes, I got the device included into the repo Sep 26 05:51:08 its an Octeon3 mips64 Sep 26 05:51:25 Question Sep 26 05:51:43 Could it be it needs an -mabi=o32? Sep 26 05:51:52 or whatever Sep 26 05:52:10 coudl it be that it can't handle the address length? Sep 26 05:52:12 Grommish: do you mean you have CONFIG_SOFT_FLOAT in package makefile? Asking because the problem is with system library, not package code. Sep 26 05:52:21 It's in the .config Sep 26 05:53:04 Grommish: with proper softfloat configuration no FPU instructions should end up in the code ever. Sep 26 05:53:37 Ok, well.. i just know that suricata throws an SIGILL on the decfloat.. I'm not even sure exactly WHAT that means, mind you Sep 26 05:53:55 "LDC1 loads a 64-bit double word from the memory subsystem into the FPC general registers." Sep 26 05:53:56 but I've been frustrating the suricata devs at the same time over it. Sep 26 05:54:02 yes, but Sep 26 05:54:09 If you say your target has no FPU at all then it means LDC1 can't work. Sep 26 05:54:23 => 0x120d7d87c : sdc1 $f24,8376(sp) Sep 26 05:54:29 sdc1 is what is beign called, under mips32 Sep 26 05:54:55 to register 24, if I understand that right Sep 26 05:54:58 I'm not sure what the rest is Sep 26 05:55:09 probably copy lengt and offset Sep 26 05:55:30 userland is n64 by default Sep 26 05:55:54 But does your CPU really have an FPU or not? Sep 26 05:56:25 https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-multi-core-mips64-processors/octeon-iii-cn7xxx.html Sep 26 05:56:36 it's a cn7020 AAP 1.2 Sep 26 05:57:08 but, as far as I've ever heard, it doesn't have a fpu because it's mips64 Sep 26 05:57:20 See, I just tried ~/openwrt/staging_dir/toolchain-mips_24kc_gcc-8.4.0_musl/bin/mips-openwrt-linux-objdump -d obj/src/internal/floatscan.o and guess what, decfloat function doesn't contain sdc1 instruction. Sep 26 05:57:21 Never said it was right :) Just that it works Sep 26 05:57:56 Ok.. So, is it abandonable as a project then? Sep 26 05:58:10 I'm just out of my depth with all of it Sep 26 05:58:52 I can always build without soft float Sep 26 05:58:55 and see if it bricks Sep 26 05:59:08 Grommish: we're like talking about different things Sep 26 05:59:24 Grommish: I'm building with softfloat and I'm not getting floating point instructions (as expected!) Sep 26 05:59:29 That's because I don't know what I'm actually referring to, and I appreciate your patience with me on it Sep 26 05:59:34 Grommish: but according to what you show you're getting floating point instructions. Sep 26 06:00:22 And I would first try to figure out if the target CPU should be able to support any of those or not. Sep 26 06:00:49 Ok.. Would it be a flag in my suricata makefile? my Makefile.. https://pastebin.com/njzvzPN0 Sep 26 06:01:54 Grommish: no, my point is that it looks like your musl is compiled with hardfloat and probably your target doesn't support it. Sep 26 06:03:36 Well.. if CONFIG_SOFT_FLOAT doesn't do it.. maybe a force -msoft-float? Sep 26 06:04:13 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ath97.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.) Sep 26 06:04:38 Grommish: are you building for octeontx target? Sep 26 06:05:09 No.. octeon because er/erlite are already there and no one wanted to approve spinning off an octeon3 target Sep 26 06:05:38 octeon target doesn't enable hard float Sep 26 06:05:56 Right.. it defaults to CONFIG_SOFT_FLOAT Sep 26 06:06:02 err =y Sep 26 06:06:55 So, as to why Suricata is calling that, since I didn't specify a float in it *shrug* Sep 26 06:07:42 Grommish: so what I'd do next would be to clean the toolchain, and rebuild while saving V=sc output to see what compile options exactly are used for that floatscan.o file. Sep 26 06:07:55 Easy enough Sep 26 06:07:58 Grommish: then I would inspect it with objdump to see if the offending instructions is there Sep 26 06:08:09 let me finish this CONFIG_SOFT_FLOAT=n build Sep 26 06:08:57 See if it fails spectacularly Sep 26 06:08:59 Grommish: and if it's indeed there I'd start compiling just it manually trying to see why/how soft-float might be getting ignored, probably it's a gcc bug. Sep 26 06:09:18 Grommish: suricata has nothing to do with it most likely, it's just calling a system library function. Sep 26 06:09:23 I'm using 10.2 Sep 26 06:09:27 Ok Sep 26 06:09:37 So this is waaay bigger than I know how to handle Sep 26 06:09:50 but, it was fun :) Sep 26 06:10:24 It might be a problematic bug that really affects many users, not suricata specific. Sep 26 06:10:53 Honestly, I don't mind doing the work, but I don't have the knowledge Sep 26 06:11:24 Also, i can't find an answer spec sheet about the FPU.. so, I'll try it without soft and then turn it back on if/when it fails Sep 26 06:11:44 I did see where they have a DPI engine in the SoC that I probably should see if it's enabled or not Sep 26 06:12:15 "Integrated fourth-generation Deep Packet Inspection (DPI) and security acceleration engines without additional memory requirements" Sep 26 06:35:37 It can't be just enabled. Either you have special drivers and userspace support for it or not. And I guess it's not in the free software case. Sep 26 06:38:31 Well, the drivers would be somewhere in their 4.14 kernel ;/ Sep 26 06:38:41 they GPL all of it, just not very well Sep 26 06:40:12 PaulFertser: I turned off CONFIG_SOFT_FLOAT, did a make clean, built out.. boots.. Sep 26 06:40:55 Should I do a rm -rf bin/ build_dir/ staging_dir/ tmp/ just to make sure everything is cleaned out? Sep 26 06:42:01 Grommish: you can. But even if your target has no FPU it'll seem to work till you run anything that requires float. Sep 26 06:43:08 Any suggestions on how to test? Sep 26 06:44:25 Run suricata :) Sep 26 06:45:28 Same error Sep 26 06:45:33 exactly the same in fact Sep 26 06:45:45 let me set a -msoft-float CFLAG in the package Sep 26 06:49:25 Grommish: flags in package do not matter Sep 26 06:50:02 Would putting it as a gcc option be something worth doing? Sep 26 06:50:13 Grommish: I've already outlined what I'd do. Sep 26 06:50:25 Grommish: I'd be checking how exactly that musl file is getting compiled. Sep 26 06:50:33 And would be verifying the results with objdump -D Sep 26 06:52:03 Ok.. Although, I will be testing the floatscan.o file, correct? After I build out -j1 V=sc | tee build.log so i can find floatscan's build text Sep 26 06:52:26 i removed the toolchain to force the rebuild Sep 26 06:52:36 Grommish: yes, the floatscan.o file Sep 26 06:53:00 Ok.. it'll be a bit at -j1, thank you so much for the help and hints you've provided me Sep 26 06:53:07 Hoepfully, i'm not too much of a PITA Sep 26 06:53:27 :) Sep 26 06:54:25 So, it shouldn't be calling ANY float register calls, right? like.. sdc1 shouldn't ever get called Sep 26 06:55:00 With default target/octeon/ yes Sep 26 06:55:27 interesting.. I specifically have a target option of -O0 Sep 26 06:55:33 but ccache gcc is calling -O2 Sep 26 06:55:54 Oh, TARGET options Sep 26 06:55:55 On my build it's ./build_dir/toolchain-mips_24kc_gcc-8.4.0_musl/musl-1.1.24/obj/src/internal/floatscan.o Sep 26 06:56:26 I get the core/toolchain don't follow the target options Sep 26 06:56:29 eer bet Sep 26 06:56:41 yes, I've seen it, but I didn't know what to DO with it Sep 26 06:56:54 i'll run the objdump -D on it once it finishes building Sep 26 08:33:24 Is there a big difference between open and closed source mt7615 drivers? Sep 26 08:55:51 the sdk one has txbf I think Sep 26 09:02:16 aparcar[m]: The proprietary one doesn't use nl80211. It needs a lot of efforts to get it work properly in OpenWrt. Sep 26 09:18:33 gch9812137: thanks. I asked over at https://github.com/project-openwrt/ and they said they maintains their own fork because they want that proprietary bits. Strange... Sep 26 09:32:17 the throughput might have been better on them at some point Sep 26 09:32:24 not sure if that's still the case Sep 26 10:03:33 aparcar[m]: It seems that mtk doesn't care too much about hiding their crappy proprietary driver. Search mt7615 on github if you'd like to take a look at it :) Sep 26 10:17:59 PaulFertset: Finished building out, and there is no floatscan.o, but there is a ./musl-1.1.24/obj/src/internal/floatscan.lo Sep 26 10:18:08 bleh, PaulFertser Sep 26 10:19:22 Ah, objdump doesn't support mips. I'll have to look for an alternative Sep 26 10:19:43 doesn't support mips? since when? Sep 26 10:20:52 Since I need to use the one in the toolchain directory :) Sep 26 10:21:46 Because I'm cross-compiling Sep 26 10:22:01 So, i'll try the mips64 version the toolchain made Sep 26 10:22:34 And, that worked :) Told ya all, I'm still learning Sep 26 10:22:41 Grommish: cool :) Sep 26 10:22:54 and Sep 26 10:23:00 sdc1 is all throughout Sep 26 10:23:30 https://pastebin.com/3N4vEXwR Sep 26 10:23:37 Grommish: so I guess it's built without -msoft-float Sep 26 10:23:51 I FORCED -msoft-float on this build though Sep 26 10:23:59 I specifically set it in my target options Sep 26 10:24:32 Let me load the build log and see what it says Sep 26 10:25:06 Grommish: you should be looking at specific function disassembly, not grepping the whole file. Because debugging and other binary data might be parsed in any way. Sep 26 10:26:33 Ok.. any hints on what I can man to do that? Sep 26 10:28:02 Grommish: I just pipe objdump to less and / to decfloat Sep 26 10:28:36 Ah, i just dumped it to a file and loaded it in atom Sep 26 11:13:24 hi? Sep 26 11:13:56 lo Sep 26 11:17:26 Ansuel Please can I ask, who is the best reviewer to contact for any proposed hostapd shell script changes? I would like to get this merged if possible: https://github.com/openwrt/openwrt/pull/3434/commits/c81f0f097b57c9d5f4c6da6a6d1e9fcdafac82e1 Sep 26 11:20:06 I would git send-email it to openwrt-devel@lists.openwrt.org Sep 26 13:11:46 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 99.7% packages reproducible in our current test framework.) Sep 26 15:10:03 stintel Thank you, I have closed the pull request in GitHub and have sent a patch to the mailing list instead. Sep 26 16:34:53 Grommish: any news wrt the FPU instructions? Sep 26 17:01:45 PaulFertser: I just installed the initramfs Sep 26 17:02:07 PaulFertser: and I'm going to wipe out my mmcblk1p4 partition to ensure anything on there is gone Sep 26 17:02:28 but, running it from initramfs gave the same SIGILL, and it isn't using anything on storage at that point Sep 26 17:02:43 Grommish: so no need to wipe anything I'd say Sep 26 17:02:50 I'd start inspecting libc.so Sep 26 17:16:53 Well, it's wiped each sysupgrade anyway, so no loss I was just going to run a mkf2fs on it, but you're right, probably no need Sep 26 18:42:46 hello Sep 26 19:15:01 Grommish: ping Sep 26 19:23:15 jow: did you see the opkg bug ticket I opened? Sep 26 19:23:21 yes Sep 26 19:23:27 thoughts? Sep 26 19:23:38 no Sep 26 19:24:25 🙏 Sep 26 20:00:40 aparcar[m]: pong.. What's up? Sep 26 20:01:24 Grommish: I'm still struggling with building the full SELinux thing. Can you please have a look at the buildlogs? Sep 26 20:01:56 I'm not sure what help I'd be, but always willing to look Sep 26 20:06:11 Grommish: https://github.com/aparcar/openwrt/runs/1169605282?check_suite_focus=true Sep 26 20:07:43 Oh.. I don't even remember what file it was in.. One sec.. i redid my tree. Sep 26 20:09:50 aparcar[m] Give me a hint.. I know I solved it by doing the PKG_HOST_ONLY check around where you needed to exclude the core files Sep 26 20:10:42 https://pastebin.com/JVai3bNL Sep 26 20:10:43 Ah ha Sep 26 20:10:56 Although I can't tell you where I put that Sep 26 20:12:35 scripts/ipkg-build Sep 26 20:13:30 aparcar[m]: scripts/ipkg-build#184 Sep 26 20:18:05 PaulFertser: glibc failed hard, I'll investigate in the future, but for now, I'll switch back to musl and see if I can't figure out why it's buggy Sep 26 20:20:39 Grommish: It's a slightly different problem, this is with the unmodified ipkg-build script Sep 26 20:21:02 I reverted this changes for now and use the plain master branch. However even then refpolicy and policycoreutils fail Sep 26 20:21:05 Did the core team get itchy about it? Sep 26 20:21:19 make[4]: msgfmt: Command not found Sep 26 20:21:24 they don't seem to like touching the scripts and includes :c) Sep 26 20:21:49 No I reverted things in the CI build, it's now the same as in master branch Sep 26 20:22:41 Did you try PKG_FIXUP:=gettext-version in your package? Sep 26 20:22:50 msgfmt is a gettext tool Sep 26 20:24:31 I've never gotten Github actions to actually build my OpenWrt Sep 26 20:24:48 it either takes to long and times out after 6 hours, or fails and it's buried in the log so I can't find it Sep 26 20:25:11 Grommish: The same action also builds OpenWrt with Full Language Support - which works fine Sep 26 20:25:35 Oh, I'm not saying it can't work, just that I've never gotten to to work :) I could just clone your tree Sep 26 20:26:12 the github-ci-build branch? Sep 26 20:26:52 github-ci-nls Sep 26 20:26:57 Ok Sep 26 20:27:33 it adds the folder .ci with custom configuration. This is not meant to be upstreamed Sep 26 20:27:54 it's merely to test special configurations and offer binaries Sep 26 20:27:59 Gotcha.. I just want to see if I can get it to build Sep 26 20:29:32 What device can i build this for? What are you testing? Sep 26 20:29:58 currently just ath79 and x86 Sep 26 20:30:13 but if you feel fancy you can just build all targets. But ideally don't until we have a sources CDN Sep 26 20:30:18 ath79/generic? Sep 26 20:30:25 ya Sep 26 20:30:29 I use CONFIG_ALL in my .config :D Sep 26 20:30:40 Takes almost 6 hours:( So I can imagine Sep 26 20:31:22 enable rootfs and NSA tags again? Sep 26 20:32:35 look at .ci/selinux.config Sep 26 20:34:17 Got it Sep 26 20:34:56 I'm just doing the defconfig with the added selinux.config flags Sep 26 20:35:03 I'll check back in a bit on it Sep 26 20:53:27 Grommish: lmk Sep 26 21:25:32 anyone familiar with Meson? Sep 26 21:26:11 I’m not able to build various stock packages like glib2 on Ubuntu18 for a while now, and it’s not clear what’s wrong with my environment or setup. Sep 26 21:35:20 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Sep 26 21:43:11 adrianschmutzler: even with the deprecated label property upstream, it doesn't deprecate leds having names, just the _label_ property. Sep 26 21:43:25 dhewg: got a couple of minutes to answer some Meson questions? Sep 26 21:44:40 aparcar[m]: Which one do you want? https://pastebin.com/E5z0B5fd Sep 26 21:47:21 Be aware I cloned your repo into a seperate directory tree.. I ran make menuconfig, set the devices, saves, clean the .config (removed any empty/commented lines, =m lines or =n lines) and cat'd the selinux.config to the end of the .config file.. re-ran make menuconfig to set the defaults on everything not defined, and ran it make -j9 Sep 26 21:48:12 karlp: yes, but it makes it a little easier for me to get rid of that modelname Sep 26 21:49:12 adrianschmutzler: oh, I totally agrtee on getting rid of model Sep 26 21:49:24 it's something that has annoyed me from the beginning, because it's so entirely useless Sep 26 21:49:28 the model was, aiui, never require dupstream, but was a miscommunication and badly worded idea from 10 years aog Sep 26 21:49:43 I don't know why we stuck with it so long, but that's not really interesting :) Sep 26 21:50:02 just don't think that led "names" are going away... Sep 26 21:50:04 that's actually what I suspect. somebody just misinterpreted the "device" in the documentation and then everybody just followed that example Sep 26 21:50:21 what are led "names" for you? Sep 26 21:50:44 well, the node name of the dts node is _already_ the name used in sysfs, if you don't specify a label. (as in many places) Sep 26 21:50:50 so you still have a led name, Sep 26 21:51:00 I just think you were making too much of a deal of "label is deprecatted!" Sep 26 21:51:33 actually, I have been looking for a chance to get rid of that model name for a long time Sep 26 21:51:48 and then I thought the color/function properties might grant me that opportunity Sep 26 21:51:52 I don't think "remove sysfs name" is a good function name though Sep 26 21:52:04 you're really just "stripping first portion of three portion names from uci configs" Sep 26 21:52:18 unfortunately, they make it more complicated instead Sep 26 21:52:25 and I think it wouldn't hurt to have a better description of what you're doing there. Sep 26 21:52:34 karlp: I'm open to any better name Sep 26 21:52:57 actually, the migration will be much less fun on targets where we use upstream mixed with local DTS files Sep 26 21:53:26 generally agree on both points Sep 26 21:54:05 I did this part quickly for the RFC, there is a lot of room for improvement there Sep 26 21:54:49 But I wanted to get this out so somebody can say: "No, that's inacceptable" before I invest additional time Sep 26 21:56:07 And BTW I also considered using the node name and dropping label entirely ... Sep 26 21:56:28 Unfortunately, the node name is less standardized and the function/color order is inverted typically Sep 26 21:57:32 So, it wouldn't be nice to 01_leds and migration in ath79/ramips at least Sep 26 21:58:18 BTW if you are interested, there is a lot of further info here: https://github.com/openwrt/openwrt/pull/3437 Sep 26 21:58:20 Grommish: were you able to compile it withouth the FIXUP patch? Sep 26 21:58:51 i didn't change anything with your code Sep 26 21:59:04 eventually I'd probably make the changes to package/baselfiles a separate patch anyway Sep 26 21:59:05 Literally nothing Sep 26 21:59:30 Grommish: so SELinux is enabled or not? Sep 26 22:00:04 Should be Sep 26 22:00:10 I can't test ath79 Sep 26 22:01:18 Grommish: okay exciting, that would mean that the msgfmt cause the issue after all Sep 26 22:01:20 Want to test? Sep 26 22:02:32 I can load up a initramfs for you pull if you tell me which one Sep 26 22:02:48 Like I said, I did not change anything of your -nls branch Sep 26 22:03:20 i cloned, pulled down the standard feeds, installed them. I can send you my .config if it'll help Sep 26 22:04:22 karlp: if there was a straightforward way to just drop label and use the node name, I'd take that; but I don't see one Sep 26 22:12:10 because no-one ever had a policy on node names before ;) Sep 26 22:12:29 or worse, they had the same cargo culting for them too... Sep 27 00:14:41 mangix: ping Sep 27 00:58:15 grift: ping Sep 27 00:58:28 do you plan to create a OpenWrt package based on you policy? **** ENDING LOGGING AT Sun Sep 27 03:02:40 2020