**** BEGIN LOGGING AT Tue Aug 06 02:59:57 2019 Aug 06 05:06:56 ynezz: what target suffers from that fonfxc issue? Aug 06 05:48:51 well, you've the details in the commit message Aug 06 05:49:13 was the revert necessary? we've talked about it just yesterday Aug 06 05:51:03 I've prepared the revert in my staging tree https://git.openwrt.org/ef276f44b2735b63e0b444aaa21bff5b9766461e already Aug 06 05:51:31 and asked the author to rework it as needed https://github.com/openwrt/openwrt/pull/2294#issuecomment-518138653 (gave you that link yesterday) Aug 06 05:59:13 I understand, that you might be somehow angry at me, that I've commited something suboptimal to the part of the tree you care about, but at least it was somehow working, now it's back to the broken state, so it would make sense to make it working again... Aug 06 06:04:49 BTW that original PR https://github.com/openwrt/openwrt/pull/1832 was lingering there since February 2019 and reviewed by at least two people several times Aug 06 06:10:10 PR#1834 has added that mtdsplit support for fonfxc in February 2019 as well, as separate commit, but Christian has requested author to merge the changes in to the PR#1832, which I found quite suboptimal (due to the bisecting), but not a big deal, which would prevent me to merge it Aug 06 06:20:39 rmilecki: ^ Aug 06 07:05:12 oh, prpl sent a mail regarding a donation Aug 06 07:05:31 nice, I already knew this might happen, but god to see it actually happening Aug 06 07:05:43 :-) Aug 06 07:24:33 nice work, btw :) Aug 06 07:37:29 ynezz: ah, I knew I saw that link somewhere, that's what I was looking for: https://bugs.openwrt.org/index.php?do=details&task_id=2413 Aug 06 07:38:15 ynezz: i found revert applicable in this case, the alternative fix if really needed can be prepared easily Aug 06 07:38:59 ynezz: even if that fixed some issue, I think we should care about code quality (e.g. don't push wrong code even if that fixes some problem) Aug 06 07:39:05 ynezz: i'm not angry at you ;) Aug 06 07:39:22 ynezz: i just started looking at ramips to see if we can have a proper DT code used there Aug 06 07:39:52 ynezz: since you also got revert queued (sorry I didn't check your staging tree), I guess it wasn't so bad? ;) Aug 06 07:41:00 so the only reason is code quality? Aug 06 07:42:20 I can understand that, but what I don't understand is, that you're reverting my commits, without actually discussing it with me Aug 06 07:42:51 well, we did discussed it yesterday, but my impression was, that it could be fixed by improving the affected suboptimal code Aug 06 07:43:23 so now you've reverted the fix and left the code broken again :) Aug 06 07:44:42 code quality + unoptimal solution Aug 06 07:44:48 i'm aware it's broken Aug 06 07:45:02 you can blame me for that, I take it Aug 06 07:45:05 and I don't get this obsession with reverts, this is not a Linux kernel, this is development branch, not a stable release Aug 06 07:45:37 so it can be broken for some devices from time to time? Aug 06 07:45:58 we've admitted, that it's unoptimal yesterday, the guy has already started working on the improved solution as you can see in that PR link Aug 06 07:46:17 that's one way of solving that Aug 06 07:46:24 adding more hacks to make auto-discovery works Aug 06 07:46:41 I provided that link to you yesterday, you've said 'thank you' so I've assumed, that you've read it and it's fine with you Aug 06 07:47:02 rmilecki: so you can chime in that PR and propose the better solution Aug 06 07:47:15 ynezz: working on it *right* now Aug 06 07:47:49 nice Aug 06 07:48:42 maybe it would be nice to tell it to that author at the PR as well, because maybe he's already preparing or testing his improved solution Aug 06 07:49:15 ynezz: i'm doing just a research only right now Aug 06 07:50:23 ok, but you can just say "hey, this proposed solution still doesn't look optimal to me, I've have some time on hand so I'll try to came up with a better solution, so you don't need to waste your time" Aug 06 07:51:04 and then commit revert + your better solution at once Aug 06 07:57:28 "so it can be broken for some devices from time to time" -> indeed, it's development, it happens (even in the "elite" Linux kernel) and I believe, that nobody is breaking it (or introducing suboptimal code) intentionaly Aug 06 07:58:56 anyway, thanks a lot for taking care of this! Aug 06 08:01:31 Hello, I'm compiling OpenWRT (both master and openwrt-19.07 branches) on Arch Linux and the build seems to hang on 'make[3] -C tools/xz compile' forever. Verbose make shows it stuck here: . /home/aorth/src/git/openwrt/include/shell.sh; bzcat /home/aorth/src/git/openwrt/dl/xz-5.2.4.tar.bz2 | tar -C /home/aorth/src/git/openwrt/build Aug 06 08:05:15 stickyboy: that command looks truncated Aug 06 08:08:45 jow: Yah it was, my irssi was gonna paste a few extra lines so I decided not to spam. :P Aug 06 08:09:01 Here it is: . /home/aorth/src/git/openwrt/include/shell.sh; bzcat /home/aorth/src/git/openwrt/dl/xz-5.2.4.tar.bz2 | tar -C /home/aorth/src/git/openwrt/build_dir/host/xz-5.2.4/.. -xf - Aug 06 08:16:18 blogic: can you pastebin boot log from any "mediatek" target device? Aug 06 08:16:25 blogic: i wanted to look at mtd part of it Aug 06 08:21:52 stickyboy: does it work if you execute it manually? (bzcat /home/aorth/src/git/openwrt/dl/xz-5.2.4.tar.bz2 | tar -C /home/aorth/src/git/openwrt/build_dir/host/xz-5.2.4/.. -xf -) Aug 06 08:23:52 rmilecki: you mean the arm one ? Aug 06 08:24:01 blogic: target/linux/mediatek/ Aug 06 08:24:13 rmilecki: ok, will need a moment, i am downstairs Aug 06 08:24:17 no rush Aug 06 08:30:53 jow: Yeah it executes properly if I run it manually (and exit code is 0). Aug 06 08:32:16 Strange to hang on simply unzipping a tarball. Aug 06 08:34:50 https://blade.tencent.com/en/advisories/qualpwn/ Aug 06 08:34:54 ownage Aug 06 08:35:05 i wonder if this will also effect the qsdk driver version Aug 06 08:35:19 that would a new epic level of failage Aug 06 08:36:49 looks like a memory overflow inside the IE parser Aug 06 08:37:16 so it would be stack based overflow inside the kernel that can be triggered by simply sending a pre-auth frame Aug 06 08:37:22 oh boy diz gonna be fun Aug 06 08:45:06 stickyboy: to debug this, try the following Aug 06 08:45:35 1) edit include/unpack.mk and change `DECOMPRESS_CMD:=bzcat ...` to `DECOMPRESS_CMD:=strace -o /tmp/bzcat.trace bzcat ...` Aug 06 08:46:49 2) in the same file, change `TAR_CMD=$(HOST_TAR) ...` to `TAR_CMD=strace -o /tmp/tar.trace $(HOST_TAR) ...` Aug 06 08:47:13 then reproduce the hang and look into /tmp/bzcat.trace and /tmp/tar.trace Aug 06 08:47:33 see what it is hanging at Aug 06 08:47:47 if possible, trys to upload the files somewhere Aug 06 08:47:52 i have a tp-link archer c7 v1 question: is it possible to get 5 GHz working if using another 5 GHz miniPCIe WiFi Card? Aug 06 08:48:02 rubberduck: should be possible Aug 06 08:48:30 thx Aug 06 08:49:47 you probably should watch out for power consumtion, so maybe not stick something significantly beefier in there Aug 06 08:52:34 blogic: didn't both marvell and broadcom already have similar pwns? a) firmware doesn't validate certain invalid frames, passes on to driver b) driver doesn't validate frames c) hilarity ensues Aug 06 08:53:07 KanjiMonster: and ralink Aug 06 08:53:16 but they silently fixed it without anyone noticing Aug 06 08:58:07 jow: OK, building again with strace in there now. Lotttts of output in tar.trace... seems busy despite showing no progress in CLI. Aug 06 08:58:12 Let me monitor it a bit... Aug 06 09:01:46 jow: Oh, I had tar symlinked to toolsched.d (schedtool idle mode, see: http://ck.kolivas.org/apps/toolsched/toolsched-0.17/readme.txt). After removing the symlink the build works again. Aug 06 09:06:03 ah - great :) Aug 06 09:06:30 wonder what went wrong there though Aug 06 09:06:57 maybe a bug in toolsched.d, looks as if it does not relay stdin Aug 06 09:10:51 jow: yeah strange. I've had it aliased for months and never noticed any other issues. I think I'll get rid of toolsched for now, or perhaps only leave it on for setting multimedia stuff to interactive (ISO). Aug 06 09:13:09 fun, initramfs on an ipq40xx device works fine, installing the image causes some error with mdio :/ Aug 06 09:16:16 initramfs boots via uboot which brings up network Aug 06 09:16:23 and that will init the phy Aug 06 09:16:37 best guess, the bootloader triggers a phy reset via gpio Aug 06 09:17:19 thanks Aug 06 09:17:22 time to start digging :) Aug 06 09:17:45 learning something new every day Aug 06 09:18:32 kristrev: try dumping the gpio state Aug 06 09:18:42 cat /sys/kernel/debug/gpio Aug 06 09:19:15 blogic: Thanks again, will try that now Aug 06 09:19:24 Also asked for vendor firmware, to take a look Aug 06 09:21:56 blogic: I forgot to let you know, but I kept trying to generate a 4.19 config for m7623 without success. I will keep on trying when I have some spare time again, but any pointers would be greatly appreciated Aug 06 10:01:03 \q Aug 06 10:02:16 blogic: Thanks, that was it. There is some things missing in the mdio driver for ipq40xx vs. SDK Aug 06 10:03:04 I will ask Christian what is right way forward with the required changes to the driver Aug 06 10:15:22 kristrev: mikrotik board? (ipq40xx) Aug 06 10:41:02 KanjiMonster: No, from Unielec Aug 06 10:41:44 I was working on a Mikrotik-board some time ago, but it was based on mt7621 and I gave up. I was not able to figure out the structure of the ath9 caldata Aug 06 10:43:26 ath9k on a 7621 board?? Aug 06 10:44:53 indeed Aug 06 10:45:03 what model was this? Aug 06 10:45:19 https://mikrotik.com/product/ltap Aug 06 10:52:27 everything is working except the buil-in wifi, so I havent submitted my patch Aug 06 10:52:37 kristrev: any luck with vendor gpl source? Aug 06 10:53:11 only thing i can find on the matter is https://forum.openwrt.org/t/mikrotik-gpl-source/6750 Aug 06 10:53:14 it is always possible to insert another wifi card in the spare pcie/usb slot, but I dont think tht is a very nice solution Aug 06 10:53:17 no, not really Aug 06 10:54:30 I also extracted the latest routeros npk and took a look. Found some files names ar93*fwf, but I was not able to make sense of them Aug 06 10:57:54 got a routeros bootlog from it? Aug 06 11:00:13 Hm, I think I didn't find out how to extract the logs from the device (I am not very good with routeros). If you can tell me the command, then I can recover routeros and extract the log Aug 06 11:00:31 i meant via serial console Aug 06 11:01:20 ah, ok Aug 06 11:01:38 No, I didnt save it for some reason, but I will try to find some time, recover the device and let you know Aug 06 11:03:56 nvm, according to this, routeros doesn't really have those: https://openwrt.org/toh/mikrotik/rb941_2nd Aug 06 11:05:38 did you ever get a linux shell on routeros on the device? Aug 06 11:06:13 No, I didn't manage. Since routeros is so little verbose, I focused on getting OpenWRT up and running :) Aug 06 11:09:02 My main use-case for device was as a poe-powered, outdoor AP. However, devices does not support 802.3af and doesn't work with the switch I already have Aug 06 11:13:58 kristrev: worst case there is always the option of reversing the ath9k/madwifi/whatever driver to check how it parses the ar93*fwf, or what it expects Aug 06 11:18:57 kristrev: ugh, https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/routerboot.c#L181 Aug 06 11:19:20 probably something similar to that Aug 06 11:24:15 Great find, thanks. I will port it to my device and see what comes out of it Aug 06 11:28:45 kristrev: you might wanna cross-reference with https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_mikrotik_rb750gr3.dts#L81 Aug 06 11:37:03 thanks, that dts was the starting point for the device, together with 33g (?) Aug 06 11:43:08 kristrev: maybe talk to zorun also? Aug 06 11:55:58 will do Aug 06 13:04:27 kristrev: I'm interested, with David Hutchison we've been trying hard to decode ath10k calibration data on a recent mikrotik device, with no luck so far Aug 06 13:05:24 kristrev: older models seemed to use either LZO or Run-Length encoding Aug 06 13:08:35 kristrev: can you dump the hard_config partition (see /proc/mtd) and send it to me? along with the MAC address of your device Aug 06 13:21:05 zorun: Sure, will do Aug 06 13:21:38 My attempt at solving this has been to pass the hard_config (starting with 0202) to a tool I found that can parse the eeprom for different arxxxx wifi chipsets Aug 06 13:21:53 It gives a sane output for for example a TP-Link router I have, but not the Mikrotik Aug 06 13:22:07 I dont have access to the device now, but I will extract the content tonight or tomorrow Aug 06 13:22:40 yes, on most devices the calibration data is just dumped somewhere on flash, but mikrotik decided to compress it instead Aug 06 13:22:46 ok! Aug 06 13:23:36 kristrev: interesting, which tool did you use for parsing? Aug 06 13:24:57 it is called atheepmgr Aug 06 13:25:20 https://github.com/rsa9000/atheepmgr Aug 06 13:28:49 thanks Aug 06 13:53:00 hmm, this tool seems to happily eat whatever I throw at it, and then spew out nonsensical radio data Aug 06 14:30:57 seems we found a bug in usign Aug 06 14:31:46 it currently fails to verify the x86_64 18.06 signature of the luci feed while signify-openbsd deems the signature to be correct Aug 06 14:50:16 does anyone have eny experience with ipsec performance on ipq4019? I have just made some tests and are getting absymal performance, <4Mbit/s Aug 06 14:50:27 *some tests on my device Aug 06 14:51:14 I see that there is very little CPU load, so there is omething else that causes performance to be bad Aug 06 15:43:02 Any news about ath79 17.06 builds. Last week it looked like there were no serious objections on reverting "source-only" flag. But it's still there. Aug 06 15:58:26 pilot6: you mean 19.07, i think Aug 06 15:58:43 Oops. Sure 19.07. Aug 06 15:59:23 ask ynezz, because the flag was his doing Aug 06 16:53:48 Found out that I am not alone at least: https://bugs.openwrt.org/index.php?do=details&task_id=2355 Aug 06 23:21:21 Question: How does one go about finding more info on the packages that are in the build system without info on the packages ('H' for more info) Aug 06 23:22:30 What is the current elliptic key standard? Aug 06 23:22:41 I remember the one of them was compromised Aug 07 02:19:35 rmilecki: https://downloads.openwrt.org/snapshots/faillogs/powerpc_464fp/base/b43legacy-firmware/compile.txt **** ENDING LOGGING AT Wed Aug 07 03:02:32 2019