**** BEGIN LOGGING AT Wed Dec 12 03:00:00 2018 Dec 12 05:57:08 morning Dec 12 05:59:29 hello Dec 12 07:53:30 hi Dec 12 08:13:15 Far too early. Morning. Dec 12 09:47:01 still night here. at least there's christmas lights everywhere. Dec 12 09:47:05 moah coffee I guess. Dec 12 09:52:43 Hi! Is dma_alloc_coherent supposed to accept a NULL as the first argument? It seems that the implementation used for MIPS in 4.19 (/kernel/dma/direct.c) doesn't accept this. I bumped ath79 to 4.19 using Hauke's staging tree and I got kernel panic when ag71xx tries to alloc tx_ring. Dec 12 09:53:28 jow: sorry jow, just seen your comment about the iproute2 commit from tony re libelf - and have just committed the libelf package tweak as that looked pretty harmless, had a couple of LGTM and was one of the dependencies tony required. Dec 12 09:56:56 ldir: no problem. I just wonder, if configure happens to enable libelf support if it detects it sort of implies that working without libelf would be perfectly fine Dec 12 09:57:30 unless some tc feature absolutely needs libelf but I can't imagine why a userspace networking utility would need an ELF executable dissector... Dec 12 09:58:19 it's the bpf thingy? Dec 12 09:58:25 ah that could be Dec 12 09:58:35 fancy modern times Dec 12 09:58:42 yes this is all bpf related Dec 12 09:58:58 you don't just configure networking anymore, you upload programs to configure networking Dec 12 10:01:21 lol - indeed - upload bytecode which is then interpreted - interesting times :-) Dec 12 10:02:11 it's neat what it can do though. I just have a hard time finding real uses for much of it. Dec 12 10:02:27 lots of thought problems and scenarios. Dec 12 10:03:44 Tony is keen on doing this sorta stuff and asked me if I would help to herd/corral the PRs rather than them getting lost. I agreed to help. Dec 12 10:04:12 is the OPENWRT_BUILD var used for releases or something? Dec 12 10:04:19 ldir: this is much appreciated. Its just that someone has to fill the grumpy old man role, yelling at peaople for wasting precious kilobytes Dec 12 10:04:53 and I'm building on mac which helps spread the testing net a bit wider :-) Dec 12 10:05:08 karlp: I believe its a kind of internal variable used for things to detect whether they're inside the openwrt build environment Dec 12 10:05:15 karlp: but let me look it up really quickly... Dec 12 10:06:27 ah yes, its a kind of double include / recursion guard Dec 12 10:06:59 jow: of yeah - I hate the size increases, but nothing is getting smaller sadly :-/ Feature creep/bug fixes :-) Dec 12 10:07:00 since various steps implicitely call prepare-tmpinfo which in turn spawns a new make process Dec 12 10:07:15 which then calls back into the main makefile Dec 12 10:07:28 OPENWRT_BUILD perevents recursion because it'll be set for sub-makes Dec 12 10:12:14 ldir: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=8c0f6a010a5b7011acbbf2ac5b345d9cf1c14b1f allegedly breaks ipv6 ipset support Dec 12 10:12:34 ldir: unfortuantely the report is not terribly detailled and from the shortlog in the linked ocmmit nothing jumps out Dec 12 10:12:47 ldir: https://github.com/openwrt/packages/issues/7643 Dec 12 10:14:04 jow: oooh - I'll take a look. Dec 12 10:21:19 jow: ok, was just looking at the buildroot docs again, and saw things like, "don't have GREP_OTIONs set, don't have SED set" and I thought we'd fixed most of those sorts of things. Dec 12 10:21:48 karlp: at least we unset GREP_OPTIONS and CDPATH Dec 12 10:21:51 and it seems like it fixes it... sometimes. Dec 12 10:22:13 I'm no friend of documenting such quirks, it should be simply fixed instead Dec 12 10:22:26 yeah, I thought it had been fixed, I wanted to remove it Dec 12 10:22:55 isn't it only exported as "" when openwrt_build!=1? Dec 12 10:23:21 I guess that's when the first one gets called? and then subsequent re-invocations it is set to 1 already so no need to re-export things, is that how to read the makefile? Dec 12 10:23:25 it is unset when openwrt_build is unset (toplevel invocation) Dec 12 10:23:35 exactly Dec 12 10:39:29 gch981213[w]: 4.19 for ath79, yummy! Do you've already some numbers for binary size difference between 4.14 and 4.19 for ath79 kernel? Dec 12 10:41:15 ok that's good - I can replicate the issue. Dec 12 10:45:01 and I have my suspicions......... Dec 12 11:31:02 ynezz: I'm gonna go with.... "noticeably bigger" Dec 12 11:33:16 25%? :) Dec 12 11:33:28 Got the dma problem solved by passing correct dev pointer as the first argument. Dec 12 11:34:33 ynezz: The size of my firmware increased about 64KB Dec 12 11:35:14 Ah...Actually it's exactly 64KB. I haven't compared the kernel size though. Dec 12 11:37:31 aha - smoking gun spotted... need to prove it. Dec 12 11:41:44 ynezz: LZMA compressed kernel increased 72KB :( PS: I'm compiling ath79/generic and I haven't port the giant 910-unaligned_access_hacks.patch Dec 12 11:45:52 fixed! \o/ Dec 12 11:58:17 gch981213[w]: btw, in 5563d49a391e65fd9c179661b9ddfd79cb903a54 you refer to "undocumented registers" ... afaict, they are documented. Dec 12 12:01:08 russell--: The padconf (0x10001300/0x10001340/0x10001350) and bit 15 of AGPIO_CFG(0x1000003c) are undocumented. (At least undocumented in the leaked datasheet I could found :-P ) Dec 12 12:02:35 * russell-- has been switching the EPHY pads to digital mode with bits 17-20 of the AGPIO_CFG Dec 12 12:05:28 I need the opposite: HC5661A have both a SD card slot and 5 ethernet ports working at the same time, which is impossible according to MTK's datasheet. Dec 12 12:06:08 nice! Dec 12 12:07:10 I typed the wrong reg address. It's bit 15 of GPIO_MODE(0x10000060) Dec 12 12:09:03 ah, yeah. i saw that defined in the mt7688 datasheet Dec 12 12:09:26 but, i think it didn't do what i wanted Dec 12 12:10:37 ESD_MODE Dec 12 12:12:31 my mt7628 datasheet says it's "reserved" :( Dec 12 12:15:32 Alright I've got what I want from a mt7688 datasheet..... Dec 12 12:18:01 Monkeh: It is bit 15 of 0x10000060 which switches between the two mode. Datasheet provided here: https://labs.mediatek.com/en/chipset/MT7688 says that bit determines whether SDXC shares pins with ethernet or I2S/I2C/GPIO0/UART1 pins. Dec 12 12:23:29 gch981213[w]: amusingly, bit 5 in the figure is greyed out ;) Dec 12 12:23:35 15* Dec 12 12:35:36 russell--: mt7628 programming guide didn't mention that bit at all and they marked that field gray. I guess they added the description later but forgot to change the table back. Dec 12 12:37:16 russell--: BTW what do you want? I pasted how MTK set these registers here: https://github.com/openwrt/openwrt/pull/1500#issuecomment-437643835 Dec 12 12:39:51 gch981213[w]: in my application, i don't need the ephy ports Dec 12 12:56:02 russell--: If so, I guess you should set ESD_MODE to 0, switch ephy pad to digital mode and write padconf registers according to the code I pasted above as if CONFIG_ETH_ONE_PORT_ONLY defined. Although I can't find a clean solution for AGPIO_MODE. (Except writing a new pinctrl driver, which is beyond my knowledge.) Dec 12 12:57:24 i didn't need to change the padconf registers, all i needed to do is set the AGPIO_CFG bits 17-20 and they started working as desired Dec 12 12:58:43 my temporary kludge is to use the io program with /dev/mem enabled to poke the registers from userspace Dec 12 12:58:47 dedeckeh: congrats on your fix! Dec 12 12:58:59 but that's pending some proper method Dec 12 13:05:09 jow: does minifiying has and size impact when using squashfs? Dec 12 13:10:53 rmilecki: didn't thoroughly check yet but after lzma (xz) the inified files were about 1KB smaller Dec 12 13:11:11 *minified Dec 12 13:11:25 hm, ok Dec 12 13:12:47 rmilecki: do you think its a bad idea? Dec 12 13:13:04 I mean its not a huge gain but still enough to do it imho Dec 12 13:13:05 i'm afraid people will stary minifying everyhting ;) Dec 12 13:13:22 e.g. all bash scripts Dec 12 13:13:41 at least it's an option which is nice Dec 12 13:13:56 we do some ugly minification in ddns which is not even an option Dec 12 13:14:22 debugging ddns is a pain, you have to modify Makefile first Dec 12 13:14:56 I think ddns is without maintainer Dec 12 13:15:09 we could grab it and change it Dec 12 13:15:27 i think it's in packages repo, right? Dec 12 13:15:29 yep Dec 12 13:16:10 minification will help with memory usage, no? Dec 12 13:16:33 russell--: not for static assets like css and js files Dec 12 13:32:50 * russell-- wonders if mediatek,portdisable could be used to trigger setting the AGPIO_CFG register's pins 17-20, e.g. if ports 1-4 are disabled then make the pads digital Dec 12 13:35:42 ldir:the patch was there faster than I expected :) Dec 12 13:38:18 dedeckeh: must have taken it more seriously than the last time I reported similar issues ;-) Dec 12 13:40:45 ldir:maybe it reminden Dec 12 13:41:10 *reminded him to another similar bug .. Dec 12 13:45:02 AGPIO_CFG should be configured by pinctrl subsystem. I think putting that piece of code anywhere else is a "hack". Dec 12 14:27:47 i have fstools working! :) Dec 12 14:27:55 mounting block devices seems finally stable! Dec 12 14:28:02 just sent the last 2 patches Dec 12 14:38:05 what's the big ticket summary of all these changes? I've got your pdf notes, just wondering what the big user visible changes are, usb and sd card insertions are now "more reliably" detected and events sent? Dec 12 15:11:22 karlp: there are reliable "mount" hotplug.d events Dec 12 15:11:37 so you can write simple scripts starting/stopping/modifying samba, minidlna, etc. Dec 12 15:11:51 these are all coming from blockd now? Dec 12 15:12:24 no, blockd is only for autofs Dec 12 15:12:34 it's possible to have block devices mounting without autofs Dec 12 15:13:08 you need blockd if: 1) you want to use autofs 2) you want to get block devices status using ubus Dec 12 15:24:19 this is bringing back painful memories. Dec 12 15:24:45 if I want to plug in a sdcard or usb drive and have it mounted at a conssitent path, do I need autofs? (and therefore blockd) Dec 12 15:27:28 no Dec 12 15:27:37 you need entry in /etc/config/fstab Dec 12 15:27:50 that's always required me to run "block info" to get it to mount in the past. Dec 12 15:27:53 with UUID or similar and path you want to be used for mounting Dec 12 15:28:07 it would mount at boot ok, but never on insertion. Dec 12 15:28:15 karlp: i'll bump fstools package after getting thoese 2 lasst patches pushed Dec 12 15:28:24 i'll wait 48 h for reviews/nacks before i do that Dec 12 15:28:41 then I'll ask for TESTING :) Dec 12 15:28:58 jow: do you remember sam patch for auto-adding samba mounts to /etc/config/samba? Dec 12 15:29:06 jow: i think there was patch for that... and it got accepted Dec 12 15:29:11 I *think* it was samba Dec 12 15:29:16 can I can't find it now Dec 12 15:29:23 rmilecki: I vaguely recall Dec 12 15:29:30 was that samba? Dec 12 15:29:35 I remember that something bothered me about it Dec 12 15:29:38 yes it was samba Dec 12 15:29:40 i remember we discussed it should be handled direrently Dec 12 15:29:50 jow: speaking of bumping packages, do you have more rpcd work you want to do before you bump that? Dec 12 15:29:52 by adding mounts to /tmp/samba or sth like that Dec 12 15:30:01 karlp: no, will bump it right now Dec 12 15:30:07 i'll keep seraching for that change Dec 12 15:30:08 give me ~5 minutes Dec 12 15:30:12 takk Dec 12 15:35:43 build #339 of ipq40xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/339 Dec 12 16:34:23 gch981213: Ah, interesting, more datasheet bingo. Dec 12 16:37:30 gch981213: I'm waiting to hear on datasheets for the N variant of the chips, and then I hope to look into sorting this mess out Dec 12 16:38:12 can anyone think of a mis-configuration that could cause michael-mic failures? Dec 12 17:41:15 greearb__: Yeah, having TKIP enabled. :) Dec 12 17:42:35 I even reverted back to old code and it still fails. 9984 sta to 9984 AP fails reliably, 9880 to 9984 AP works, 9984 to 9880 AP works Dec 12 18:11:12 hm, wonder how much of a chore VPP will be to port Dec 12 18:16:50 jwh: depends on what you want it to do. Dec 12 18:17:23 well its pretty useful for many things, so I thought it might make sense if I used VPP for map too Dec 12 18:17:47 I still haen't got DPDK in though, so Dec 12 18:17:51 haven't* Dec 12 19:00:56 I am in the process of making a patch to update all candela ath10k firmwares, but I'm not sure what to write in the commit message Dec 12 19:01:37 I don't know when the listed changes in the change logs on the candela tech website were made Dec 12 19:02:58 I don't precisely know either..could find out if I had to, but busy with other things. Dec 12 19:03:30 main recent things for wave-2 is PMF, rate-ctrl related fixes and performance improvements Dec 12 19:03:48 wave-1 is mostly just bug fixes and not many changes of note recently Dec 12 19:04:19 I'll start adding dates to my rls note entries to make it easier next time Dec 12 19:05:17 ok, thanks =) I'll write what you've listed Dec 12 19:35:02 is there any reason to use the regular ath10k these days when the candela version is usable? Dec 12 19:44:01 gch981213: you have to provide a device to dma_alloc_coherent() now, otehrwise you get a panic, see git.kernel.org/linus/2d946e5bcdabc1deef72d01bc92a2801c71d6d8d Dec 12 19:44:53 heh Dec 12 19:44:54 https://bugzilla.kernel.org/show_bug.cgi?id=42608#c8 Dec 12 19:45:17 well let's hope it's just that Dec 12 19:46:21 yikes! missing parameters Dec 12 19:46:55 I just passed my data structures class, so I can attest Dec 12 20:14:03 Hello :) Dec 12 20:16:51 hi Dec 12 20:46:33 Mister_X: pain Dec 12 21:01:26 what do you mean? Dec 12 21:30:35 Mister_X: I've had too many instances of ath10k not working correctly. Dec 12 21:30:44 firmware crashes and whatnot Dec 12 21:31:06 I've seen that on the QCA6xxx series a lot Dec 12 21:31:24 I agree, definitely use the -ct version when possible. It will be the default in the next OpenWRT release. Dec 12 21:31:26 is there a -ct firmware for QCA6xxx now ? Dec 12 21:31:38 no, I have no access to that FW Dec 12 22:26:56 build #242 of at91/sama5d2 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/242 **** ENDING LOGGING AT Thu Dec 13 03:00:01 2018