**** BEGIN LOGGING AT Sat Dec 29 02:59:58 2018
Dec 29 03:53:31 <owrt-snap-builds> build #57 of ath79/nand is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/57  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>
Dec 29 12:26:35 <rmilecki> ArthurMLago: ping me during the week during Europe working hours please ;)
Dec 29 12:26:55 <rmilecki> ArthurMLago: also provide me SoC model & boot log from the original firmware (pastebin it)
Dec 29 12:49:42 <owrt-snap-builds> build #58 of ath79/nand is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/58
Dec 29 16:00:05 <Justanick> Hi, is there a way to get commits from master openwrt/packages merged back to openwrt-18.06?
Dec 29 16:01:05 <jow> Justanick: yes, ask any committer to cherry-pick the given shas to openwrt-18.06
Dec 29 16:01:17 <jow> or cherry pick yourself and open a pull request
Dec 29 16:01:28 <jow> just against openwrt-18.06 instead of master
Dec 29 16:02:07 <Justanick> jow: the pull req is on the way. :)
Dec 29 16:05:06 <jow> if you use git-cherry-pick thne best with the -x flag, this will add an automatic note "(cherry picked from commit ...)" to the message
Dec 29 16:05:22 <jow> makes tracking the origin of the commits easier
Dec 29 17:50:41 <owrt-snap-builds> build #1206 of brcm63xx/generic is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/brcm63xx%2Fgeneric/builds/1206  blamelist: Deng Qingfang <dengqf6@mail2.sysu.edu.cn>, David Bauer <mail@david-bauer.net>, Christian Lamparter <chunkeey@gmail.com>, Hans Dedecker <dedeckeh@gmail.com>, Andreas
Dec 29 17:50:41 <owrt-snap-builds> Ziegler <dev@andreas-ziegler.de>, Simon Quigley <squigley@squigley.net>, Mathias Kresin <dev@kresin.me>, Eduardo Barros <geadas@gmail.com>, David Santamar?a Rogado <howl.nsp@gmail.com>
Dec 29 18:00:15 <rotanid> nbd: will there be another backport of mt76 to 18.06 eventually? just saw another big amount of improvements in master :D
Dec 29 18:02:02 <SwedeMike> rotanid: what improvements?
Dec 29 18:07:58 <rotanid> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3c899aaf11580353bc9ab1c3d9c3f638db80ba7c
Dec 29 18:23:46 <nbd> rotanid: yes, i plan on doing that soon
Dec 29 18:24:32 <rotanid> nbd: nice. thank you ;) (and whoever is financing this work, if there is someone)
**** BEGIN LOGGING AT Sat Dec 29 19:17:48 2018
**** ENDING LOGGING AT Sat Dec 29 20:17:59 2018

**** BEGIN LOGGING AT Tue Jan 01 01:50:09 2019
**** ENDING LOGGING AT Tue Jan 01 01:52:48 2019

**** BEGIN LOGGING AT Wed Jan 02 12:40:08 2019
Jan 02 13:38:56 <wigyori> Hauke: i've found the issue of the sunxi mmc boot error on the pcduinos
Jan 02 13:39:12 <wigyori> Hauke: it's due to the DTS resync in the 2018.11 release
Jan 02 13:57:52 <Hauke> wigyori: nice
Jan 02 13:59:04 <Hauke> wigyori: for me it complianed that some power was not configured correctly
Jan 02 14:00:34 <ArthurML1> rmilecki: ping
Jan 02 14:00:53 <ArthurML1> rmilecki: The router I was talking has a BCM4708A0 for CPU(according to wikidev, https://wikidevi.com/wiki/Tenda_AC18, I did not remove the heatsink).
Jan 02 14:01:19 <ArthurML1> rmilecki: The boot log contained special characters, including some for colors, so I uploaded it to drive instead(https://goo.gl/JK6gBW). I can remove special characters and put it in pastebin if you prefer.
Jan 02 14:02:58 <ArthurML1> rmilecki: you said during week and work hours, so I decided to wait for after new year. happy new year, btw
Jan 02 14:03:15 <wigyori> Hauke: well i'm bisecting that dts sync now
Jan 02 14:03:23 <wigyori> pain in the ass
Jan 02 14:04:13 <wigyori> there is a mmc0_cd_refpin change (but reverting only that one doesn't solve the issue) - which was discussed on the kernel list that it admittedly breaks the mmc on some boards
Jan 02 14:04:35 <wigyori> but it went in anyway
Jan 02 14:35:17 <rmilecki> ArthurML1: hey, let me check
Jan 02 14:37:13 <Monkeh> blogic: Did we have any luck getting the mystical datasheet?
Jan 02 17:49:50 <Foxtrot> Hi guys
Jan 02 18:45:50 <tripolar> hi
Jan 02 18:46:53 <tripolar> i am using the latest version of trunk and i get a "Illegal instruction" message  when i use aria2, what's the fastest way to find out what causes the error?
Jan 02 18:48:50 <Borromini> tripolar: sounds like an instruction your CPU does not support
Jan 02 18:57:37 <tripolar> i bet bug is caused by 2b87d184ad7be34886a39cc8769b23d86444218e
Jan 02 19:09:12 <ynezz> I doubt that
Jan 02 19:09:43 <ynezz> I would bet on 2d58169f1453886e4557ce28c29e32290de1bd97
Jan 02 19:10:06 <ynezz> but it's hard to tell since we don't know which version was working for you
Jan 02 19:11:33 <ynezz> anyway, enabling coredump and inspecting it in gdb would be a good start
Jan 02 19:12:03 <tripolar> coredumps got ignored
Jan 02 19:12:12 <tripolar> i just did a
Jan 02 19:12:13 <tripolar> sysctl -w kernel.core_uses_pid=1
Jan 02 19:12:22 <tripolar> maybe i'm missing some helper prog?
Jan 02 19:13:32 <ynezz> ulimit -c unlimited
Jan 02 19:13:43 <tripolar> i'm missing ulimit
Jan 02 19:14:07 <tripolar> seems i have to enable CONFIG_BUSYBOX_DEFAULT_HUSH_ULIMIT ?
Jan 02 19:14:25 <tripolar> ahh it's here tab doesn't seem to work
Jan 02 19:14:59 <tripolar> i will try to remove the "aria2: Fix compilation without deprecated OpenSSL APIs" commit first
Jan 02 19:16:40 <tripolar> just removing code that breaks isn't always the best idea and the patch feels like this
Jan 02 19:21:21 <tripolar> same error
Jan 02 19:21:23 <tripolar> :(
Jan 02 19:27:47 <ynezz> well, it would be very strange, that this commit could cause SIGILL
Jan 02 19:28:35 <tripolar> the last thing is try is to remove the -flto stuff, could be the more likely reason
Jan 02 19:28:53 <tripolar> the commit you pointed out before 2d58169f1453886e4557ce28c29e32290de1bd97
Jan 02 19:48:26 <tripolar> -flto causes the "Illegal instruction"
Jan 02 20:05:19 <ynezz> what platform is that?
Jan 02 20:07:17 <tripolar> ar71xx
Jan 02 20:07:52 <tripolar> created a pull request
Jan 02 21:13:10 <owrt-snap-builds> build #716 of layerscape/armv8_64b is complete: Failure [failed images]  Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/716  blamelist: Hauke Mehrtens <hauke@hauke-m.de>
Jan 02 22:04:13 <foxtrot> Is there anyone here that's familar with cfg80211 and realtek drivers on openwrt? I've been trying to get the aircrack-ng RTL8812AU driver onto the latest trunk of OpenWRT (MIPS, Kernel 4.14.90)
Jan 02 22:04:40 <foxtrot> I managed to get a package with a loadable kmod, but the phy seems to be null when trying to register it with the kernel
Jan 02 22:05:05 <foxtrot> I gather that it's a pretty specific issue, but also one that I can't find any information on anywhere
Jan 02 22:08:49 <foxtrot> On a standard linux install though, it works well
Jan 02 22:19:46 <Mister_X> foxtrot, have you tried running the tools anyway?
Jan 02 22:20:06 <foxtrot> Which tools, sorry?
Jan 02 22:20:14 <Mister_X> airodump-ng, aireplay-ng
Jan 02 22:20:30 <Mister_X> put the card in monitor mode, then run the tools
Jan 02 22:20:31 <foxtrot> My issue is not with the tools, I can't get that far anyway
Jan 02 22:20:43 <Mister_X> ah ok
Jan 02 22:20:46 <foxtrot> The module inserts but crashes when the USB is inserted
Jan 02 22:20:50 <foxtrot> I added some logging to the driver
Jan 02 22:21:05 <Mister_X> I wasn't sure what you meant since a null phy can also happen with airmon-ng
Jan 02 22:21:20 <Mister_X> (and this isn't always a dealbreaker)
Jan 02 22:21:50 <foxtrot> Unfortunately my kernel dev skills are lacking, but comparing the logs between openwrt and desktop linux, on one it trys to register a null device, on the other it says "phy0", "phy1" etc
Jan 02 22:21:53 <foxtrot> Aye
Jan 02 22:22:27 <foxtrot> If seeing the panic would help, its here
Jan 02 22:22:28 <foxtrot> https://github.com/aircrack-ng/rtl8812au/issues/250
Jan 02 22:22:44 <Mister_X> I was already looking at it
Jan 02 22:23:24 <Mister_X> you can add more details on how you compiled it and the system you're running
Jan 02 22:23:29 <Mister_X> in the bug report
Jan 02 22:24:09 <foxtrot> That's a good idea. Although the compilation wasn't much different than on a standard system
Jan 02 22:24:31 <foxtrot> I just created a makefile for the OpenWRT buildroot that pulls from github
Jan 02 22:26:37 <Mister_X> stuff that can make it easier to reproduce the bug helps
Jan 02 22:26:51 <Mister_X> there is some learning curve to compiling openwrt
Jan 02 22:27:40 <foxtrot> I've been compiling it for a while, but never tackled 'porting' a driver until now.
Jan 02 22:28:17 <foxtrot> I have a feeling it's not actually the driver though, but the version of the backports instead
Jan 02 22:28:29 <Mister_X> what do you mean?
Jan 02 22:28:46 <foxtrot> With the backports?
Jan 02 22:29:05 <Mister_X> yes
Jan 02 22:29:24 <foxtrot> The kernel version is 4.14.90, but from the logs i've seen on the device i'm using the wireless backports are from 4.17.something
Jan 02 22:29:43 <foxtrot> from memory, anyway. I don't have the thing turned on right now
Jan 02 22:30:39 <Mister_X> that driver should work on 4.17
Jan 02 22:30:46 <foxtrot> Right
Jan 02 22:31:27 <ynezz> Loading modules backported from Linux version v4.19.7-0-g61c68f2a2af0
Jan 02 22:49:22 <Mister_X> foxtrot, 2 other things I can think about that can be useful is explain how you compile the driver for openwrt (or in) and tell which branch+commit you used
Jan 02 22:51:38 <foxtrot> I can get branch+commit in a second or two,
Jan 02 22:52:57 <foxtrot> For compiling the driver I modified a Makefile to pull from aircrack-ng (or kimocoder, i dont recall which i tried last)'s repo and create an ipk
Jan 02 22:53:12 <foxtrot> But i'm also building the module into the firmware
Jan 02 22:53:50 <foxtrot> To build, I'm simply cloning and configuring for my device, as it's already upstream in openwrt
Jan 02 22:54:07 <foxtrot> It's the WiFi Pineapple NANO, which is ar71xx
Jan 02 22:57:55 <foxtrot> OpenWRT is master+e790227553c057d38064e720add92b3bee42ecf2
Jan 02 23:02:22 <foxtrot> I'm also 'patching' one of the driver source files to use the kernel byteswap header instead of realteks own, as it breaks compilation
Jan 02 23:02:31 <foxtrot> I'll get the name of the file
Jan 02 23:06:46 <ynezz> this is not kerenel crash, it's just warning caused by this https://elixir.bootlin.com/linux/v4.19.7/source/net/wireless/core.c#L736
Jan 02 23:07:49 <ynezz> so if it fails, then somewhere else
Jan 02 23:09:08 <ynezz> interface_modes are set in the driver here https://github.com/aircrack-ng/rtl8812au/blob/67e27a15be39f1e1d7c189b7aa163c6375182ebe/os_dep/linux/ioctl_cfg80211.c#L7445
Jan 02 23:12:13 <foxtrot> Ah, interesting. I had read that function in the driver codebase (rtw_cfg80211_preinit_wiphy) but didn't suspect ifmodes
Jan 02 23:12:28 <ynezz> if by "phy seems to be null" you mean this `rtw_wiphy_register((null))` then I think, that the debug logging has some issues
Jan 02 23:12:50 <foxtrot> ynezz: that log on non-openwrt shows rtw_wiphy_register(phyX)
Jan 02 23:12:53 <foxtrot> where x is the phy number
Jan 02 23:13:06 <foxtrot> the (null) is returned from the function that gets the wiphy->dev name
Jan 02 23:13:28 <foxtrot> https://elixir.bootlin.com/linux/v4.19.7/source/include/net/cfg80211.h#L4173
Jan 02 23:14:10 <ynezz> ok, I've thought, that they're printing pointer of that parameter
Jan 02 23:14:55 <ynezz> so you're saying, that it works on stock 4.19.7 kernel without OpenWrt patches?
Jan 02 23:15:15 <foxtrot> Because of this, I was thinking that either the wiphy, or some parent of it (_adapter or drvobj) is not being correctly set
Jan 02 23:15:35 <foxtrot> ynezz: I will try 4.19.7 specifically on Ubuntu or something
Jan 02 23:15:49 <foxtrot> But it works for sure on 4.19.11 (Arch)
Jan 02 23:16:26 <ynezz> ok, so it might be some OpenWrt specific patch
Jan 02 23:16:34 <foxtrot> Yeah
Jan 02 23:17:10 <ynezz> now you just need to find out which one :)
Jan 02 23:18:28 <foxtrot> *slight smile*
Jan 02 23:21:41 <ynezz> maybe it's caused by something else, like netifd & co.
Jan 02 23:23:37 <foxtrot> Any tips on figuring out which lead to chase?
Jan 02 23:24:01 <foxtrot> Also out of curiosity how do you know the panic is being raised by the line in net/wireless/core.c you linked?
Jan 02 23:24:36 <ynezz> look closer at that warning message
Jan 02 23:24:50 <ynezz> [ 5715.973450] WARNING: CPU: 0 PID: 2779 at backports-4.19.7-1/net/wireless/core.c:743
Jan 02 23:25:25 <foxtrot> sigh
Jan 02 23:25:31 <foxtrot> Thanks
Jan 02 23:25:52 <foxtrot> I've been looking at it basically non stop for 8 days and I hadn't seen that until now
Jan 02 23:27:12 <foxtrot> Oh, thats why it was unfamiliar to me - line 743 is the return res; but I hadn't seen the WARN_ON right above it
Jan 02 23:27:14 <foxtrot> thank you :)
Jan 02 23:27:27 <ynezz> I would try to rename /sbin/wifi to /sbin/wifi.disabled
Jan 02 23:28:17 <ynezz> and try to reinsert the dongle
Jan 02 23:31:21 <foxtrot> Cool, I will give that a go very soon
Jan 02 23:31:28 <foxtrot> thank you guys for the help :)
Jan 02 23:57:18 <foxtrot> I gave the /sbin/wifi rename a go - no difference
Jan 02 23:58:31 <ynezz> then the problem is in that driver and openwrt kernel (mac80211 probably)
Jan 02 23:59:45 <foxtrot> Hm, ok
Jan 03 00:00:50 <foxtrot> Your point about the warning being thrown because of !ifmodes makes me wonder if the `wiphy` or `adaptor` is being filled out incorrectly
Jan 03 00:00:54 <foxtrot> or, not at all
Jan 03 00:01:14 <foxtrot> and i guess the missing wiphy->dev->name supports that
Jan 03 00:13:48 <foxtrot> thanks again for the help ynezz, i'm going to spend some time looking at what modifys the wiphy struct and see if/where something goes wrong
Jan 03 00:13:53 <foxtrot> modifies*
Jan 03 00:24:10 <Mister_X> foxtrot, I mean the branch+commit for the driver
Jan 03 00:24:32 <Mister_X> make sure to add all that to the ticket, it will speed up testing
Jan 03 00:25:42 <foxtrot> Mister_X: I will, also I am compiling the branch from kimocoder (now) as he seems to be the sole author, and is in the middle of a rollout PR
Jan 03 00:26:05 <Mister_X> don't pull from kimocoder's repo, that is for testing
Jan 03 00:26:12 <Mister_X> pull from the aircrack-ng repo
Jan 03 00:26:19 <Mister_X> aircrack-ng/rtl8812au
Jan 03 00:26:36 <foxtrot> Okay - I will
Jan 03 00:26:38 <Mister_X> kimocoder's repo is for testing and some gets merged later on
Jan 03 00:26:54 <Mister_X> (testing = stuff will break)
Jan 03 00:27:20 <foxtrot> Sure, but just for the record, I do experience the same thing with aircrack-ng/rtl8812au
Jan 03 00:27:36 <foxtrot> I will move to aircrack-ng/rtl8812au now, though
Jan 03 00:32:18 <ynezz> [6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[5~[5~[5~[6~[6~[6~[6~[6~[5~[5~
Jan 03 00:32:50 <ynezz> sorry
Jan 03 00:51:21 <foxtrot> Ouch, something has changed between the latest trunk and the previous version of master I was on
Jan 03 00:51:51 <foxtrot> the aircrack-ng/rtl8812au no longer wants to build for me because it cant find <asm/fpu/api.h>.
Jan 03 00:52:40 <foxtrot> os_dep/linux/ioctl_mp.c:19:11: fatal error: asm/fpu/api.h: No such file or directory
Jan 03 00:52:42 <foxtrot>   #include <asm/fpu/api.h>
Jan 03 00:53:06 <foxtrot> ioctl_mp.c uses the same path on kimocoders git too, though - his compiles.
Jan 03 00:53:26 <Mister_X> are you sure you're running master?
Jan 03 00:53:33 <Mister_X> you should be using 5.2.20 branch
Jan 03 00:53:46 <foxtrot> Sorry, i need to be more specific
Jan 03 00:53:58 <foxtrot> Master of openwrt
Jan 03 00:54:16 <foxtrot> I *am* using 5.2.20 of the driver.
Jan 03 00:54:22 <Mister_X> ok
Jan 03 00:54:43 <Mister_X> were you running from aircrack-ng/rtl8812 before?
Jan 03 00:54:58 <foxtrot> I have ran it in the past, yes
Jan 03 00:56:38 <Mister_X> so, in the past, it worked on openwrt and recently phy became null?
Jan 03 00:57:36 <foxtrot> No, the phy name has always been null, thus stopping the driver from ever working
Jan 03 00:57:47 <Mister_X> ok
Jan 03 00:57:50 <foxtrot> But now I can't compile the aircrack branch
Jan 03 00:57:59 <foxtrot> whereas I can compile kimos
Jan 03 01:00:04 <Mister_X> open a bug report so it can be fixed
Jan 03 01:00:11 <foxtrot> I shall
Jan 03 01:00:28 <foxtrot> I will also edit my existing PR to include the details discussed above^
Jan 03 01:01:32 <Mister_X> awesome
Jan 03 01:04:39 <foxtrot> https://github.com/aircrack-ng/rtl8812au/blob/v5.2.20/os_dep/linux/ioctl_mp.c
Jan 03 01:04:43 <foxtrot> https://github.com/kimocoder/rtl8812au/blob/v5.2.20/os_dep/linux/ioctl_linux.c
Jan 03 01:04:54 <foxtrot> disregard that, i cook socks
Jan 03 01:05:03 <Mister_X> as I said, don't use kimocoder repo
Jan 03 01:05:12 <foxtrot> I know, i'm trying not to
Jan 03 01:05:26 <foxtrot> I am trying to see why one compiles and one doesn't due to that header, though
Jan 03 01:13:44 <foxtrot> Okay, I managed to get it to compile by commenting out the line to set hardware float
Jan 03 01:13:51 <foxtrot> EXTRA_CFLAGS += -DMARK_KERNEL_PFU
Jan 03 01:13:53 <foxtrot> https://github.com/aircrack-ng/rtl8812au/blob/v5.2.20/Makefile#L1046
Jan 03 01:14:01 <foxtrot> will mention in issue
Jan 03 02:09:32 <ipat8> I was wondering who I need to contact to add a page to the wiki
Jan 03 02:09:40 <ipat8> I have an MX64 I'm going to pull apart
**** ENDING LOGGING AT Thu Jan 03 02:59:57 2019