**** BEGIN LOGGING AT Thu Jul 18 02:59:56 2019 Jul 18 05:07:49 Isn't 64M enough for OpenWrt nowadays? hostapd got killed on my router due to insufficient memory: https://paste.ubuntu.com/p/VWDvrc3sX6/ Jul 18 05:20:33 gch981213: what else is installed ? Jul 18 05:25:06 blogic: uhttpd and nlbwmon is running. I also installed openvpn and zerotier but haven't got a chance to start them yet. Jul 18 05:25:20 strange Jul 18 05:42:19 gch981213: a kernel memory leak maybe? Jul 18 05:42:31 gch981213: compile kernel with kmemleak Jul 18 05:49:42 gch981213: for ath10k/ ath10k-ct (your paste doesn't really show which device) 64 MB RAM probably wouldn't be enough Jul 18 06:07:28 rmilecki: I've been running the same kernel on another router with bigger ram for several days and that one works pretty well. Jul 18 06:07:48 pkgadd: Oops... I'm using ath10k-ct for QCA9886 Jul 18 06:08:22 gch981213: was both routers handling exactly the same traffic? all network packets send to them were 100% identical? ;) Jul 18 06:08:41 *were Jul 18 06:16:14 rmilecki: I haven't thrown this 64M router any traffic yet. Jul 18 06:16:21 huh Jul 18 06:18:38 gch981213: take a look at https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commitdiff;h=087dc8fcdb96b958e84132fbda98a03897fb8882 ath10k has the corresponding patches applied, ath10k-ct doesn't Jul 18 06:19:34 gch981213: if I read the history of those patches correctly, they resulted from early rt-ac58u support (ipq40xx/ 128 MB), which was also fighting with (severe) memory pressure Jul 18 06:19:51 pkgadd: Oh. I'll try it now. Jul 18 06:22:18 greearb_: ^^ Jul 18 06:41:42 just wondering, does anyone know the approx. price & conditions for ath10k source code? Jul 18 06:44:19 GPL? Jul 18 06:44:30 err, ath10k firmware :) Jul 18 06:44:47 Hauke: this explicitly not a bugreport, as I did quite some experimenting (ipq806x, kernel v4.19.59+USB enablement, mac80211/ 5.2-rc7, ath10k instead of ath10k-ct, qca9984 10.4-3.10-00047 firmware), but when testing https://git.openwrt.org/3000a2b43f2ff6ee156e3a2a579147e4e08274bf I noticed http://paste.debian.net/1092020/ (v4.19.59, ath10k, nbg6817). 84:38:38:xx:xx:xx is an android device with Jul 18 06:44:53 BCM4354 wlan Jul 18 06:49:37 pkgadd: it seems to be ath10k_htt_t2h_msg_handler and ieee80211_sta_register_airtime Jul 18 06:49:41 greearb_: ^^ Jul 18 06:50:16 but it's not -ct Jul 18 06:51:04 yep, it's plain ath10k with the new 10.4-3.10-00047 qca9984 firmware Jul 18 06:51:31 pkgadd: That patches solved it. Thanks :D Jul 18 06:52:15 pkgadd: gch981213: interesting Jul 18 06:52:56 :) I've no idea why lach1012 didn't push those patches (as he did for ath10k) - and my personal lesson from those patches was to buy >=256 MB RAM ath10k devices only ;) Jul 18 06:53:50 crippled performance/features for others with > 64M ? Jul 18 07:43:32 * ldir suspects he has missed blogic's frisbee Jul 18 08:05:07 blogic: BTW http://lists.infradead.org/pipermail/openwrt-devel/2019-July/017989.html :) Jul 18 08:07:05 gch981213: any idea what might be wrong in FS#2349 ? Probably some leftover after the MIB counters/mdio probing? Jul 18 08:09:44 fyi, http://buildbot.openwrt.org/openwrt-19.07/images/ http://buildbot.openwrt.org/openwrt-19.07/packages/ https://downloads.openwrt.org/releases/19.07-SNAPSHOT/ Jul 18 08:09:58 wow, thanks! Jul 18 08:11:44 BTW, is there some wiki page with these links? I always forget them :) Jul 18 08:12:27 maybe it would be worth it to announce this on mailing list as well? Jul 18 08:12:40 https://openwrt.org/infrastructure Jul 18 08:13:27 ok, I'll add those links Jul 18 08:13:55 ah, you're at it already, good! Jul 18 08:15:47 it'll take about 24-48 hours to build all package architectures at least once Jul 18 08:16:00 I can probably throw more builders at the 19.07 package phase Jul 18 08:16:14 the 18.06 ones are mostly idle Jul 18 08:24:13 I don't know how time consuming is this builder shuffling, but as we would like to get 19.07.1 out soon, it might make sense to put more resources in this direction Jul 18 08:24:37 its now mostly ansible managed, so a matter of seconds actually Jul 18 08:24:56 that's nice to hear Jul 18 08:25:01 just need to covnert the 18.06 cluster to the new docker based setup first which is somewhat blocked by pgp issues Jul 18 08:26:48 so it's already possible to add more external builders with this new docker based setup or there is still some work needed? Jul 18 08:27:38 It is possible. Jul 18 08:42:13 ynezz: https://pastebin.com/RWAaWG7a and I confirm HOSTCFLAGS_jevents.o = -I$(srctree)/tools/include Jul 18 08:45:40 so this should be probably reproducible on otherOS outside of OpenWrt as well Jul 18 08:46:46 I can take a look at this later on some BSD box at cfarm Jul 18 08:49:55 great. It's something that I 'fell over' rather than 'need' so not urgent - more a 'did anyone else see this was broken?' :-) Jul 18 08:51:20 you know the answer, right? :p Jul 18 08:51:32 I'm fairly convinced that https://forum.openwrt.org/t/apu2-x86-64-compile-failed-4-19-57/40486 is a manifestation of the 'objtool/libelf' cross compile tool problem I first encountered on macOS. This time on mint. Jul 18 08:52:56 ldir: its broken in the SDK as well for me Jul 18 08:53:03 on debian 10 / x86 Jul 18 08:55:37 ynezz: macOS not supported? ;-) Jul 18 08:56:41 jow: same error? Jul 18 08:57:44 * ldir disappears into the underground rail network on the way to work Jul 18 09:00:44 ynezz: yes, but would need to reconfirm Jul 18 09:13:47 ynezz: That Jul 18 09:13:54 Oops... Jul 18 09:14:03 ynezz: That's the expected behavior Jul 18 09:14:50 lan/gmac1 is connected to built-in switch therefore it's always link up. Jul 18 09:59:39 ldir Hi mate just found the time to get my wrt3200acm up and running agin. You will be pleased to know that all is in tiptop shape. Thanks again for all your help with it mate. Jul 18 10:01:59 btw that loose connecter.. I think it had bin loose for a long time possibly loose from when I got it as the 5 ghz wifi seems to be stronger now. It mite just be me tho :) Jul 18 10:51:35 i don't think this commit is a great idea https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commitdiff;h=d6198d8625310cd1ad22113f137e48261fcc8ff6 Jul 18 10:52:31 a better idea IMHO is more #ifdef's Jul 18 10:55:19 ok, care to explain why? Jul 18 11:03:14 ^ DonkeyHotei Jul 18 11:03:50 that "#ifdef notyet" seems to be there since 63c91af40444 ("mtd: add support for rewriting the fis table layout on redboot based systems") from 2009 Jul 18 11:04:05 is OpenWrt THAT old?! :D Jul 18 11:04:11 yes Jul 18 11:04:32 rmilecki: iirc you were already here prior to that Jul 18 11:04:40 ;) Jul 18 11:07:41 but that #ifdef obviously was for supporting some specific devices, which may still resurface, at which point the "notyet" can be corrected to whatever it's really supposed to be Jul 18 11:08:00 the code is in git Jul 18 11:08:16 if that dead code is eventually needed it can be pulled from the history Jul 18 11:08:35 maybe add /* TODO: */ Jul 18 11:08:43 (replace old code with it?) Jul 18 11:08:56 I mean /* TODO: foo */ Jul 18 11:09:28 isn't redboot dead? Jul 18 11:31:20 fisboot is used ath25 Jul 18 11:34:03 dead, next? :) Jul 18 12:47:37 hello...someone having issues with ath10k-ct? Jul 18 13:03:28 gch981213: pkgadd: I had to switch from ath10k-ct to atk10k on my ASUS rt-ac58u, as a large WiFi transfers were killing other processes (web server, hostapd, etc). Looks like 128 MiB of RAM it's not enough Jul 18 13:03:55 greearb_: ^ Jul 18 13:05:49 greearb_: could you take a look at the patch that pkgadd linked? It reduces the memory usage of ath10k-ct Jul 18 13:08:15 I do not want to add that to my upstream ath10k-ct, because I fear it will decrease performance on large RAM systems. And, I do not have time at the moment to covert that into 'fwcfg' configurable. Jul 18 13:08:26 I don't know if they have a performance impact Jul 18 13:08:48 If someone wants to add that as a add-on patch on top of ath10k-ct in openwrt, then please go ahead and do so. Jul 18 13:09:02 I think it is likely that decreasing buffers will have some impact Jul 18 13:09:37 if someone wants to add it into fwcfg configuration, then I'll add it in my upstream driver. Jul 18 13:09:55 then each user/system can tune it as needed in case defaults do not work well. Jul 18 13:17:20 several tens of MB of RAM for the wifi buffers? Jul 18 13:17:25 looks large, what about bufferbloat? Jul 18 13:19:41 at 500 Mbit/s, 1 MB worth of buffer already takes 16 ms to transmit Jul 18 13:21:07 I make wifi test equipment, if I can move total throughput from 1.3Gbps to 1.35Gbps, then it is a win for me, and my users rarely care much at all about bufferbloat. Jul 18 13:21:52 so, my use case is probably different from openwrt users. I'm happy to have a config option to decrease the bloat, but don't want to have it applied across all of my own stuff. Jul 18 13:40:55 greearb_: I understand that. I just did a lightly read on fwcfg. Could you give us more information and an idea what would have to be done for an OpenWRT implementation? It is upstreamed? I saw some ath10k logs with that Jul 18 13:41:37 nothing about ath10k-ct is 'upstream' as far as the real kernel goes, but I do maintain it in my own upstream stuff. Jul 18 13:42:13 so if you modify the fwcfg logic and send me a patch against ath10k-ct, I'll add it to my driver and then you won't have to carry external patches in openwrt Jul 18 13:42:48 basic idea is to add a new configuration per radio and use that config instead of the hard coded value. Jul 18 13:43:06 (well, fwcfg is per radio already) Jul 18 13:43:22 see how tx-buffers are handled in fwcfg, for instance. Jul 18 13:44:19 sorry, tx_desc is the right thing to look for Jul 18 13:48:41 With upstream I was referring to ath10k, so I (or someone else) could use it as a reference implementation Jul 18 13:51:14 you can clone my tree from here if you wish: https://github.com/greearb/linux-ct-5.2 or just look at the ath10k-specific driver that is pulled into openwrt: https://github.com/greearb/ath10k-ct Jul 18 13:51:47 I have other kernel versions on my github account too, including more stable 4.20, 4.19 kernels. Jul 18 13:59:06 Tapper: no problem, glad it's fixed. There was a very loose screw (not) holding on a heatsink as well, so it's probably a bit cooler too. Jul 18 14:36:45 https://www.spinics.net/lists/netdev/msg586566.html looks a bit upside-down to me, shouldn't the capability rather be named MTK_QDMA with inverted logic rather than MTK_SOC_MT7628 to disabled QDMA (which is needed for other Ralink SoCs as well)... Jul 18 14:37:03 @hauke @nbd @blogic Jul 18 14:59:18 dangole: i don't think @nick works the way you want on irc... Jul 18 15:05:07 i think he knows that Jul 18 15:05:54 * nmrh is not sure why he felt compelled to be "helpful" Jul 18 15:06:49 I would assume most IRC clients ignore special characters before or after the nick for catching highlights, or have their highlight patterns setup that way Jul 18 15:08:26 KanjiMonster: I would think this could result in a lot "false" positives... Jul 18 15:09:01 * nmrh ahh that's it. I feel chatty Jul 18 15:09:32 nmrh: special characters, not any character. so e.g. it still catches the nick like you did with a : at the end ;) Jul 18 15:11:58 hi, looking to install openwrt onto old (headless) laptop with legacy intel 32 bit cpu: core duo t2250; is there 32-bit x86 image release target I could download and flash into sd-card? Jul 18 15:12:26 Matrix "pills" are cool concept too ;) Jul 18 15:13:19 nast: x86 releases there are, no idea about SD card specifically, but normal ide/sata etc Jul 18 15:15:42 olmari: thanks, but there are "generic" and "legacy" images https://downloads.openwrt.org/releases/18.06.4/targets/x86; are these targets both 32-bit? Jul 18 15:16:35 yes Jul 18 15:16:40 olmari: ah, just found it's documented. thanks anyway Jul 18 15:42:12 gch981213: thanks for looking at that, I just don't understand, that it's reported as regression from ar71xx, so maybe it's due to the interface swap on this device? Jul 18 15:47:06 ynezz: It always behaves like that in ath79. Jul 18 15:48:00 I don't care about this stuff that much, so never noticed this :) Jul 18 15:50:47 ldir: it seems like perf needs more love to be crosscompile friendly, on OpenBSD it fails much sooner, `diff: unknown option -- B` :) this is on 5.2.1 Jul 18 16:54:34 ynezz: ping Jul 18 17:47:51 hi, is there a reason why src-cpy feed entries cannot contain a commit or branch? Jul 18 17:48:06 src-cpy luci routing /home/user/feeds/luci^b99e77d5c36a9d51559bae3bb61a138695d60b95 Jul 18 17:48:09 ^ like this Jul 18 17:48:33 it seem simple to fix this Jul 18 18:29:05 mwarning: yes, becasue src-copy must not necessarily point to a git, hg or svn repo Jul 18 18:29:18 could be a simple directory of makefiles Jul 18 18:34:50 What is the `V=` for "show all compilation warnings? Jul 18 18:39:41 jeffsf: V=sc Jul 18 18:39:46 Thanks Jul 18 18:42:25 jow: i carry on a local patch for src-link that checks targets for a ".git" directory AFAIR Jul 18 18:42:31 jow: would you find that useful at all? Jul 18 18:43:16 it results in sth like Jul 18 18:43:33 foo src-link 1234abcd [git url] Jul 18 18:44:00 rmilecki: basically I'm fine if nothing introduces implicit git requirements Jul 18 18:44:14 for src-copy and src-link Jul 18 18:45:20 if ($feed->[0] eq "src-link" && -d "$localpath/.git") Jul 18 18:45:21 $revision = `cd '$localpath'; $update_method{"src-git"}->{'revision'}`; Jul 18 18:45:30 two lines patch Jul 18 18:45:32 I'll send it Jul 18 18:48:41 great Jul 18 19:12:39 rmilecki: couldn't you just use src-git with a file:// link as well? Jul 18 19:52:08 KanjiMonster: i wasn't aware of file:// Jul 18 20:00:27 pkgadd: intresting problem Jul 18 21:02:24 rmilecki: doesn't even need file:// just a path works perfectly well, Jul 18 21:02:32 anything that git can understand. **** ENDING LOGGING AT Fri Jul 19 02:59:57 2019