**** BEGIN LOGGING AT Wed Mar 25 02:59:57 2020 Mar 25 03:00:36 found my answer. deprecated functionality. Mar 25 07:08:16 ynezz: fixed via https://patchwork.ozlabs.org/patch/1261130/ Mar 25 07:09:00 maybe this could also be refactored as it now has the same code in x86, armvirt and malta Mar 25 07:39:05 *yawn* Mar 25 07:51:04 homework contingency plan in operation Mar 25 07:51:34 we setup a skype group call for school home work :-) Mar 25 07:52:04 one less thing to worry about Mar 25 08:09:42 mangix: it sets the kernel timezone and it worked when I implemented it Mar 25 08:10:53 those musl time64 fixes looks weird https://patchwork.ozlabs.org/patch/1261137/ Mar 25 08:11:21 whats the reason to use syscall instead of direct clock_gettime call? Mar 25 08:11:37 flash space microoptimization? Mar 25 08:12:15 its not consistent across the codebase anyway, so I would rather remove those syscalls Mar 25 08:15:04 err, not remove, replace :) Mar 25 08:15:27 then it should compile probably fine as this is handled internaly in the libcs Mar 25 08:19:00 ynezz: it may be a legacy artifact from pre-musl times when uClibc was in use Mar 25 08:19:25 I agree that we should simply replace it with the libc wrapper Mar 25 08:19:38 mangix: ^ thanks! Mar 25 08:54:12 * russell-- is bisecting the wdr3600 DSP panic Mar 25 09:19:16 jow: May I ask for some help fixing https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=36b8a4f8a3b1bde47abe4bf1846531dd7c10a1e5 please Mar 25 09:20:18 menuconfig appears to lose the title "nftables packet filtering userspace utility" for one of the options... and I don't understand why. Mar 25 09:21:39 similarly, as soon as involve a 'PROVIDES' statement I get dependency issues... it's not the first time PROVIDES has defeated me (CAKE out of tree springs to mind) Mar 25 09:22:29 I'm aware of the 'out of base' jansson lib issue... but this is trying to get the framework in place. Mar 25 09:23:26 I've taken libs/ustream-ssl/Makefile as the (copy/paste/tweak) inspiration :-) Mar 25 09:23:49 will take a look after my video conference Mar 25 09:27:34 Thank you - no rush at all - am going on a pharmacy/vet/essential shopping expedition soon and that could take hours :-) Mar 25 09:34:25 ldir: are people lining up outside there too? Mar 25 09:34:54 f00b4r0: you're in france right? Mar 25 09:34:59 aye Mar 25 09:35:36 i'm venturing outside as well in a few. my mom has been diagnosed with 'light covid-19' (belgium doesn't have enough kits to actually test of course) so she needs to stay at home and she has a very specific shopping list for me Mar 25 09:36:04 f00b4r0: yes Mar 25 09:36:22 crazy times Mar 25 09:38:46 crazy times indeed Mar 25 09:39:05 instead of begging for money, the local punks are now selling flowers in front of the super market Mar 25 09:40:00 :-/ Mar 25 09:40:13 o_O Mar 25 10:07:53 jow: wouldnt it be better selling toilet paper? Mar 25 10:09:53 step aside bitcoin, toilet paper is the new currency Mar 25 10:13:33 starting to look like my wdr3600 problem is due to the gcc-8.3 -> gcc-8.4 transition Mar 25 10:19:28 12645 good, 12649 bad Mar 25 10:35:54 rubberduck: one would think so :) Mar 25 10:36:58 some supermarkets have a deal: if you bring back your empty bottles for recycling you get a role of toilet-paper Mar 25 10:48:28 12647 also bad, so that seems like the clincher, since ath79/wdr3600 uses gcc8 Mar 25 10:52:28 russell--: could you try to rebuild with -mno-dspr2 added to the toolchain flags? Mar 25 10:52:44 russell--: and if that still fails, retry with -mno-dsp Mar 25 10:57:47 jow: yes, but tomorrow! sleepytime Mar 25 11:18:48 configure: error: unrecognized option: `-mno-dspr2' Mar 25 11:19:24 with: CONFIG_EXTRA_GCC_CONFIG_OPTIONS="-mno-dspr2" Mar 25 11:20:53 that's probably the wrong CONFIG Mar 25 11:21:36 that sounds like an option passwed to configuring the gcc build? Mar 25 11:22:00 yes, indeed Mar 25 11:22:17 jow: where should -mno-dspr2 go? Mar 25 11:23:23 CONFIG_EXTRA_OPTIMIZATION ? Mar 25 11:29:20 russell--: sec... Mar 25 11:30:01 russell--: I'd probably hack CPU_CFLAGS_74kc in include/target.mk for now Mar 25 11:30:29 russell--: might be CPU_CFLAGS_24kc for the 3600 instead Mar 25 11:30:32 I don't know offhand Mar 25 11:30:42 try adding it to both Mar 25 12:08:58 -mno-dspr2 didn't do the trick Mar 25 12:09:40 starting a build, going to sleep Mar 25 13:29:38 * ldir hmmmms Mar 25 14:22:27 jow: ping Mar 25 14:38:46 Hello guys!! I just sent a mail on the ML for this issue - but was wondering if you could help me out; last time jow I guess you helped me - it was a problem with ill_acc (illegal access) driver Mar 25 14:38:58 My WL-330n3G won't boot Mar 25 14:39:14 with a snapshot image; it booted fine on 4.14.101. Sorry for the many small messages. Mar 25 14:49:09 sorry, blogic it was you who helped me actually, i guess it had something to do with commit 302a9f8982f3ca717856add355b3406b99100c2e at the time Mar 25 14:53:29 my other wl330n3g runs at commit ca13820d13 Mar 25 15:24:10 oh lord - apple have an xcode update. make dirclean; make -j4; take dog for walk, await carnage on return Mar 25 16:21:35 trinh 19.07.2 Mar 25 16:23:21 oh - actually device responded to some ping packets, then stopped again Mar 25 16:24:43 no, it runs fine now - 4.14.171 kernel Mar 25 16:46:42 but won't boot reliably - after a reboot the device seems not coming up Mar 25 16:46:47 uhm Mar 25 17:12:20 ldir: didn't forget about you. I'm doing a frresh build nwo Mar 25 17:16:58 jow: I'll believe you, others wouldn't ;-) Mar 25 17:19:48 jow, -mno-dsp didn't fix it either Mar 25 17:20:16 + CPU_CFLAGS_24kc = -mips32r2 -mtune=24kc -mno-dsp Mar 25 17:20:49 did a make dirclean world Mar 25 17:22:50 russell--: hm okay. I took a quick look at the gcc changelog but didn't spot anything imediately obvious (no hits for "dsp" or "mips") Mar 25 17:23:23 russell--: so out of ideas right now Mar 25 17:38:08 * ldir throws caution to the wind and decides to update to 10.15.4 - I may be some time Mar 25 18:18:41 * ldir appears to be back Mar 25 18:20:33 I think our GCC does not generate any dsp instructions Mar 25 18:21:41 russell--: what error mesage you you get? Mar 25 18:26:27 Hauke: [ 0.107073] Kernel panic - not syncing: Unexpected DSP exceptio Mar 25 18:28:20 Hauke: details here: https://bugs.openwrt.org/index.php?do=details&task_id=2928&order=id&sort=desc Mar 25 18:30:08 jow: russell-- Is this really related to the GCC change? Mar 25 18:30:27 I would expect that we execute something which is not code Mar 25 18:30:48 but data and this then matches an DSP extension instruction Mar 25 18:45:08 Hauke: that might be an explanation... question is why it bisacts to the gcc bump though Mar 25 18:45:17 maybe a firmware image util gets miscompiled? Mar 25 18:45:43 ldir: was there any other particular problem about your nftables variant thing besides the missing title? Mar 25 18:46:14 ldir: the missing title for the JSON variant is ecause the final string is too long Mar 25 18:46:34 I changed "nftables packet filtering userspace utility" to "nftables packet filtering utility" Mar 25 18:46:37 and it works Mar 25 18:57:06 jow: ha, oh that's amusing! I'm also getting some recursive dep warnings too. Mar 25 18:58:16 https://paste.ubuntu.com/p/gsVCRV4ntf/ Mar 25 18:58:22 ldir: hm, I don't see any Mar 25 18:58:39 ah Mar 25 19:05:09 Hauke: i bisected it to that change Mar 25 19:05:50 and the gcc change is fine with the 4.19 kernel Mar 25 19:19:46 tmn505: thanks for the patch Mar 25 19:42:23 hi, I'm trying to find which commit introduced a bug (https://bugs.openwrt.org/index.php?do=details&task_id=2848), the bug is in 19.x but not int 18x, so I'm trying to find the commit start and end to start the search. I don't know what is the *first* and *last* commit of each branch, is it the previous commit before tag v18.06.0-rc1 and v19.07.0-rc1 ? thanks! Mar 25 19:45:16 guifipedro[m]: I think you're looking for "OpenWrt v18.06: set branch defaults" (f93c029395182228) Mar 25 19:45:34 this is the first commit on the 18.06 branch, so the previous one is common between master and 18.06 Mar 25 19:45:44 Out of curiosity - as some point I flashed a master build to my Zbtlink ZBT-WG3526 device, but due to commit 15a0701cdde8eeae2a54880b813cdb8cdc09a384 device started behaving like flash was damaged (e.g.: JFFS2 complained LOUDLY). the commit got reverted by fdfca33350150644481096f1c7a80db2b670cdec and all runs fine now. My question is - what are the chances of things like those to damage the flash Mar 25 19:45:50 chip? And - what is one supposed to do if some problems happen with NAND flash and e.g.: a block is marked as bad even if it isn't? Mar 25 19:46:50 zorun: but I have a doubt, for example 19.x release, had so much time spare between commits. 19.07.0 is from year ~2020, but its RCs are from november 2019. Then, we have a common master branch and from there, there are selected commits. Maybe it is better to take the -1 commit before the first RC ? Mar 25 19:46:50 I posted this question on ML, but got no answer - but was curious Mar 25 19:47:41 guifipedro[m]: the first RC often happens long after the branching Mar 25 19:48:03 Hi any one know when mvebu: will be bumped to 5.4? Mar 25 19:48:54 I'm confused. I don't know what is the moment that the branch starts. because from there, only specific commits are included, right? Mar 25 19:49:09 anyway, I think git bisect handles branches fine, so you can tell it that v18.06.0 is good / v19.07.2 is bad Mar 25 19:49:15 it will just take longer Mar 25 19:49:34 guifipedro[m]: unfortunately you cannot really bisect between 18.x and 19.x releases since there's no continuous history between them Mar 25 19:49:39 guifipedro[m]: look at the history with a tool like "gitg", you will understand the branching Mar 25 19:50:15 russell--: Is this happening always at the same place? Could you add some printks into the code to find wheer it happens Mar 25 19:50:50 russell--: did you try a clean build or is your host system somehow specail? Mar 25 19:51:34 guifipedro[m]: to see releases + branching points, have a look at "git log feeds.conf.default" from various branches Mar 25 19:52:07 jow: yes, I know, that's why I'm moving to master to have the continuous history. I'm just thinking what are the edges in the master Mar 25 19:52:21 Tapper: I only know there is a pull requst in process Mar 25 19:52:30 zorun: thanks for recommending me a new tool. with gitk I could not understand the branching Mar 25 19:53:11 mrkiko Yeah I have seen that, but it was a wile ago now. Mar 25 19:53:35 Tapper: I don't have an ETA Mar 25 19:53:55 I was just thinking if there was any testing I could do, but I don't know how to do it untill the testing kernel is put in to makemenuconfig Mar 25 19:54:16 Tapper: for that I can help you :D Mar 25 19:54:29 mrkiko Thats ok mate it takes as long as it takes. Mar 25 19:55:09 mrkiko does it boot? Mar 25 19:55:57 Tapper: well I don't know, I don't have any mvebu device to test with; your mileage may vary depending on your device. Mar 25 19:56:05 I don't mind doing a bit of testing, but I would like to have it boot atlest. Mar 25 19:56:19 ol I will wate a bit! lol Mar 25 19:56:48 you know, it's a massive change, so your device may boot or not, I can't guarantee that of course Mar 25 19:57:49 so, the process should go along these lines: 1) cloen the git openwrt repo, master; clean build is betterI think. 2) wget https://github.com/openwrt/openwrt/pull/2804.patch; 3) apply the patch and try a make oldconfig ; make menuconfig; and build; and hope Mar 25 20:00:48 ah - in make menuconfig you should enable "testing kernel" otherwise it will build with the current one and not the 5.4 oone Mar 25 20:00:59 Tapper: sorry, forgot to mention Mar 25 20:02:27 jow: the last thing I have from you is "Ah" - did I miss something? Mar 25 20:02:29 All good I will see how board i get tomorrow Mar 25 20:05:52 Tapper: eheh I would like to test with some rampis hw as well but don't know Mar 25 20:12:50 ldir: well, I got lost following the dependency tree Mar 25 20:13:36 Tie a piece of string to something before you go next time, then you can find your way back :-) Mar 25 20:14:10 no pieces of bread? Mar 25 20:14:35 Hauke: yes Mar 25 20:15:09 i did a make dirclean world Mar 25 20:15:24 so pretty clean, the build box is archlinux Mar 25 20:16:12 adrianschmutzler: that wouldn't work with my spaniel 'helping' me :-) Mar 25 20:17:33 ldir: that's the idea Mar 25 20:19:12 adrianschmutzler: good to see you! Mar 25 20:20:25 adrianschmutzler: I am enrico Mar 25 20:20:45 ah, I suspected, but wasn't sure Mar 25 20:21:40 adrianschmutzler: ahaha yes it's me, to make you even more sure - the guy who tried to port TP-Link TL-MR6400 to ath79 Mar 25 20:21:53 though I'm doing something else, so my participation has been limited to stupid brother's grimm jokes Mar 25 20:22:54 adrianschmutzler: no problems - just wanted to say hello and thank you for your help... Mar 25 20:23:32 well, I only picked up the crumbs (to stay in the image) Mar 25 20:24:15 but I'm glad that it's working for you Mar 25 20:25:27 eheh yes - I would like to have link events even in ath79 but haven't got the motivation to try to implement the missing part Mar 25 20:26:41 can't help you with that anyway Mar 25 20:51:30 * russell-- is inserting a dump_stack() to see if i can tell where the panic is actually coming from Mar 25 21:13:46 lol. well, heisenbug. add the dump_stack() patch, boots fine, remove dump_stack(), panics again. Mar 25 21:37:37 Hi what is this new thing in openwrt Enable packet steering across all CPUs. May help or hinder network speed. Mar 25 21:38:16 Tapper: distributes packets processing across systems cPUs Mar 25 21:38:28 Tapper: rts / xps - never tried as well Mar 25 21:38:50 rts / xps ? Mar 25 21:39:17 Can it be used with sqm? Mar 25 21:40:38 don't know, sorry Mar 25 21:41:07 Ok I will tick it and see if it blows up! lol Mar 25 21:46:30 That tick box drops my BufferBloat from A to C Mar 25 22:01:59 russell--: good luck with finding more details Mar 25 22:32:07 lol Mar 25 22:32:35 it is the TESTING kernel ;-) Mar 25 22:35:56 Tapper: so in your case it hinders ;) Mar 25 22:43:03 ynezz: I provided more information in one of my patches Mar 25 22:44:15 jow: the date -k patch causes problems with musl 1.2.0 since the syscall got renamed Mar 25 22:45:09 what's more, the kernel developer involved with this says setting the kernel timezone is mostly pointless: https://github.com/systemd/systemd/issues/13305#issuecomment-520463236 Mar 25 22:47:45 anyone looked at this zig cc thing? Mar 25 22:47:48 my reading is that it's for kmod-fs/fat/udf/hfs Mar 25 22:48:08 aparcar: a PR stunt for zig. move along... Mar 25 22:48:35 mangix: kthx Mar 25 22:50:50 to add more detail, it's an alternative language to C. The OpenWrt tools will move to rust before zig. Mar 25 22:51:46 why not nim?! Mar 25 22:52:13 because everyone and their dog is on the rust hypetrain Mar 25 22:52:15 zig can do pr can't it? Mar 25 22:52:23 is it a hypetrain or a good train? :) Mar 25 22:52:40 I'd be inclinded to agree, rust certainly appears to have better momentum that ~every other c replacement :) Mar 25 22:52:42 maybe both. I've never programmed in rust Mar 25 22:53:30 wher eis this zig pr? Mar 25 22:53:35 The little I've seen on rust implies that it's for C++ programmers Mar 25 22:54:15 * karlp suspects his isn't getting email right now... Mar 25 22:54:24 jow: also note that util-linux has the same problem that date -k used to have: https://github.com/karelzak/util-linux/issues/995 Mar 25 22:54:47 * karlp discovers that his root filesystem has filled up on his mailserver Mar 25 22:56:48 karlp: you're welcome ;) Mar 25 22:57:10 * karlp laughs Mar 25 22:59:53 * karlp finds a 4 gig access log. Mar 25 23:06:51 mangix: the clock_gettime man page says: "Link with -lrt (only for glibc versions before 2.17)." Mar 25 23:07:15 I think we do not haev to care about glibc older than 2.17 Mar 25 23:10:00 didn't know that Mar 25 23:10:03 i will resent Mar 25 23:10:07 *resend Mar 26 00:14:53 aparcar: moin Mar 26 00:21:08 mwarning: hallo Mar 26 00:50:19 hi, I was thinking of doing the 64MiB RAM mod on https://openwrt.org/toh/alpha/asl26555. This router currently has 16/32 of flash/ram. Support will end for 32mb ram devices, would I be able to make builds for my upgraded 64mb device? Mar 26 01:31:33 lynxis: ping Mar 26 01:35:53 aparcar: pong **** ENDING LOGGING AT Thu Mar 26 03:04:23 2020