**** BEGIN LOGGING AT Wed Feb 05 03:00:09 2020 Feb 05 06:45:00 good morning! Feb 05 06:45:06 i'm back alive! ;) Feb 05 06:48:49 ynezz: i just/finally checked ea45c4a0f07c ("system: fix failing image validation due to EINTR") - it's a right direction but you should always handle (len < 0) case and then treat (errno == EINTR) in some specific way if needed Feb 05 06:49:00 ynezz: i totally forgot about handling read() error when writing that code Feb 05 06:49:34 ynezz: so it should be if (len < 0) { if (errno == EINTR) continue; else SOMETING; } Feb 05 06:50:34 ynezz: oh, well, i just saw c7a2db3c1eb6 ("system: sysupgrade: rework firmware validation") which totally reworks that, ignore above Feb 05 06:52:24 ynezz: i'll test if sysupgrade still works for me as expected, thanks for pinging me about it Feb 05 06:59:29 rmilecki: hi Feb 05 06:59:43 blogic: hey, regarding brcmfmac, it's ok, thanks for info Feb 05 07:30:04 rmilecki: just got asked to fix 3 more issues Feb 05 07:30:19 rmilecki: and i bumped bcm53xx to v5.4 Feb 05 07:30:26 i'll publish the tree later today Feb 05 07:33:30 ok! Feb 05 07:33:42 ping me when you do, i'll hapilly look at it Feb 05 07:36:46 blogic, speaking of 5.4: i'm running a couple of wrt3200acm's (mvebu) on 5.4 for a few days, haven't noticed any quirks so far Feb 05 07:38:15 nitroshift: can you publish the patches please so that we can merge them into the v5.4 tree Feb 05 07:38:28 rmilecki: there is just once patch pending for some spi flash Feb 05 07:40:04 blogic, i'm not that handy with github, nor do i want any credit for the work, i'll e-mail them to you, please feel free to check / change / publish / merge them yourself Feb 05 07:40:26 ok Feb 05 07:40:31 so did you create them ? Feb 05 07:40:35 or that other guy Feb 05 07:40:48 don't know any other guy Feb 05 07:40:58 i reworked the 4.19 ones Feb 05 07:41:03 ok Feb 05 07:41:08 just mail them over please Feb 05 07:41:15 will do Feb 05 09:26:03 blogic, e-mail sent Feb 05 09:31:12 What path do I have to drop this file at? nitroshift Feb 05 09:35:52 Tapper, in /lib/firmware/mwlwifi Feb 05 09:36:03 thanks Feb 05 09:44:26 nitroshift Up and running I will keep a eye on things. Feb 05 09:46:41 Tapper, did you replace the old file? Feb 05 09:57:14 hmm trying to build 5.4 kernel on openwrt under macos https://paste.ubuntu.com/p/YDGk5q69j9/ Feb 05 09:58:18 looks like a missing include? Feb 05 09:59:22 the typdef redefinition suggests too many includes - I wish I could C properly :-) Feb 05 10:00:13 I suspect it's an implicit one pulling the systme header when it should have been already declared by the right include? Feb 05 10:00:23 * karlp shrugs. not good with kernel headers sorry Feb 05 10:00:58 neither am I, it's good to know I'm not alone. what on earth does error: array initializer must be an initializer list or string literal mean? Feb 05 10:05:40 I'm going to have to pull DEF_FIELD apart. Oh joy. Feb 05 10:09:13 Gaaahhhh #define DEF_FIELD(m, devid, f) typeof(((struct devid *)0)->f) f = TO_NATIVE(*(typeof(f) *)((m) + OFF_##devid##_##f)) Feb 05 10:12:57 yeah, was pretty sure that was going to be macro soup. I think that error is irrelevant, and is because it oculdn't resolve the uuid type properly first. Feb 05 10:15:39 I've commented out the redefinition of the uuid_t type and am just left with the array initializer error Feb 05 10:16:14 wellll, now it might be using the wrong uuid? Feb 05 10:19:43 dives into header files (urgh) apple's sys/_types.h typedef unsigned char __darwin_uuid_t[16]; Feb 05 10:20:08 it's 16 unsigned bytes whichever def is used. Feb 05 10:28:14 yeah, but probably doesn't like the different names Feb 05 10:28:36 file a bug with linus... Feb 05 10:28:44 or get_maintainer or whatever on the script :) Feb 05 10:34:48 ldir: have you tried https://lkml.org/lkml/2019/7/8/222 ? Feb 05 10:36:20 oooh - trying now :-) Feb 05 10:40:18 that was google hit number one for your error ;p Feb 05 10:41:12 sadly it doesn't solve the problem. Feb 05 11:21:22 hi, say your ram-limited router has two ath10k modules, since you don't need wireless and wish to run other apps on the router, you disable wifi (e/c/wireless) is this enough to free up the ram or should one uninstall ath10k kmods to prevent them being loaded in first place? Feb 05 11:21:34 I recall reading that doing so might cause stability issues? Feb 05 11:24:41 abenz: you can force module unloading by wrigint to sysfs Feb 05 11:30:33 kab-el: yep Feb 05 12:11:22 * ldir has had enough hitting head against typedefs & includes Feb 05 12:12:23 * ldir nbd will no doubt fix it in about 3 seconds Feb 05 12:13:12 is there any way to register dynamic routes with netifd? Feb 05 12:13:32 means pushing routes from a proto manager Feb 05 12:13:41 *proto handler Feb 05 13:42:10 jow: Can you please check this PR https://github.com/openwrt/openwrt/pull/2624 ? Feb 05 14:32:36 blocktrron: please don't bump iwinfo while changing the abi Feb 05 14:33:56 jow: you mean the bss load information-element? Feb 05 14:34:00 blocktrron: I also don't like the load element bss thing. Problem is that the api uses a fixed buffer for the scan results, as long as this is the case we shouldn't bloat the result elements with info Feb 05 14:34:41 the library is in need for a redesign and currently does not do proper ABI tracking (will add this later) Feb 05 14:34:53 as long as this is the case, we must not touch the abi Feb 05 14:36:53 makes sense. I was not entirely sure there, but found several attempts to add information there which simply dies down (and the necessity of a consistent abi was not mentioned) Feb 05 14:37:06 shall i revert this offending commit? Feb 05 14:37:16 I already did Feb 05 14:37:39 I'm fine with adding additional scan info if we introduce a separate api for it Feb 05 14:37:48 i see the point Feb 05 14:38:06 e.g. iwinfo_scan_extended() or similar which returns a dynamic array or a linked list Feb 05 14:38:47 Is there already progress on this somewhere? Feb 05 14:38:51 could be modelled like getifaddrs() & freeifaddrs() Feb 05 14:39:21 no, its just a plan I have in my head.... the rough idea was to add a libiwinfo2 which uses blobs as return values Feb 05 14:39:29 I'm in need of a way to access this IE in lua and iwinfo abstracted the pain far enough for me ;) Feb 05 14:39:36 and later convert libiwinfo(1) to a legacy wrapper around libiwinfo2 Feb 05 14:42:54 as an intermediate solution I'd suggest adding a scanlist_ex() or similar which uses a differnt struct iwinfo_scanlist_entry type as return value Feb 05 14:44:07 is this the libnl(-tiny) only uses a pagesize large buffer, and anything overflowing will get lost issue? Feb 05 14:45:10 jow: I'll have a look in the coming weeks. Would be great if this could be upstreamed. Feb 05 15:42:18 KanjiMonster: no Feb 05 15:42:48 KanjiMonster: however that libnl-tiny issue you mentioned sounbds interesting too Feb 05 15:43:01 could that lead to cases where no ACK is delivered? Feb 05 15:43:05 via netlink Feb 05 15:43:51 I have no idea, been quite a while I looked at netlink/libnl Feb 05 16:40:20 build #93 of x86/generic is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeneric/builds/93 blamelist: Koen Vandeputte , Mason Clarke Feb 05 17:26:15 x86 build failure on 19.07 fixed ^^ Feb 05 17:39:10 I wonder if there's a way to catch these new symbols... I read something recently that suggested 'make olddefconfig' would take a config and default any new symbols. Feb 05 17:59:33 ldir: I checked all kernel version in the Changelog and the Unified diff covering all versions inbetween and didnt see it Feb 05 18:00:23 it's already a lot of work to bump and test all kernels in all branches .. so I try to avoid more manual actions Feb 05 18:01:00 that's why I'm wondering if there's an automated way to do it Feb 05 18:01:01 nevertheless .. it's still frustrating when a buildbot discovers a missing symbol .. Feb 05 18:01:20 you've no doubt noticed .102 is out Feb 05 18:01:35 already refreshing here on all branches currently :-) Feb 05 18:01:41 testing will be for tomorrow Feb 05 18:01:55 amazing Feb 05 18:02:21 did you test 5.4 on apu2? Feb 05 18:03:06 No, not yet, I can't get the kernel to build under macos. Feb 05 18:03:45 any general error or is it macos specific? Feb 05 18:04:21 xback: Do you need anyone to test 5.4 on ath79? I could potentially try it on my no-longer-in-service UAP-LR sometime within the next few days. Feb 05 18:04:37 it's macos specific, or it's macos that finds the issue. Feb 05 18:05:09 mamarley: all testing is highly appreciated :-) just make sure you have a way to revert your device if anything goes south Feb 05 18:05:33 xback: Yep, that device is quite easy to recover with TFTP. I will try it when I get a chance! Feb 05 18:05:44 mamarley: highly appreciated :-) Feb 05 18:05:56 basically uuid_t type gets defined somewhere under macos, and the kernel build process (one of the script tools) redefines it, which produces a nice error. Feb 05 18:06:20 mamarley: please send/mail me the full bootlog when you test it please Feb 05 18:06:31 Sure. Feb 05 18:06:46 ldir: ouch .. sounds fun .. Feb 05 18:06:58 https://paste.ubuntu.com/p/YDGk5q69j9/ Feb 05 18:07:42 I need to find out where/how macos manages to define the type before the build process gets to do it, but after a few hours and my head hurting.... I stopped. Feb 05 18:08:57 I can imagine .. Feb 05 18:09:36 anyways. heading home now to see my kids before they go to bed :-) cya tomorrow Feb 05 18:09:40 The 'hilarious' thing is that both definitions define it ultimately as the same thing... 16 unsigned bytes. But the apple one is a typedef of a typedef Feb 05 18:09:49 see ya Feb 05 18:12:59 ldir: i have a suggestion for an easy fix Feb 05 18:14:07 before the uuid_t definition in file2alias.c, do #define uuid_t compat_uuid_t Feb 05 18:14:21 i haven't tested it, but it should work Feb 05 18:14:54 it's a simple conflict between something the kernel uses internally for its own data structures and a data structure used by darwin system API Feb 05 18:15:17 both have nothing to do with each other, and the kernel's tool code will not use or want the system's version of uuid_t Feb 05 18:20:39 ok, let me try it Feb 05 18:21:00 thanks Feb 05 18:26:39 jow: regarding your iwinfo revert - I've seen you didn't revert the commit in the iwinfo repository itself. Is this intentional? Feb 05 18:26:48 Or was it just the quickest fix for the moment? Feb 05 18:37:17 blocktrron: yes its intentional. We can re-bump iwinfo once the abi version tracking has been added Feb 05 18:40:19 nbd: looks hopeful. You're quite devious :-) Feb 05 19:15:54 hmm ERROR: module '/Users/kevin/wrt/build_dir/target-x86_64_musl/linux-x86_64/linux-5.4.17/arch/x86/crypto/sha256-ssse3.ko' is missing. Feb 05 19:41:02 ldir: who's tree are you building? lots of the crypto modules got split into pieces Feb 05 19:44:44 karlp: xback's Feb 05 19:46:17 hrm, no, cant'ð find sha256 changes in anything I was poking Feb 05 19:46:20 * karlp shrugs Feb 05 19:47:33 * ldir grins Feb 05 21:05:25 nbd: hey, i've problem that's extremely hard for me to fix, would you take a look at my report? it's "Wireless monitor interface causes device to run out of memory" on mailing list Feb 05 21:06:10 Message-ID: Feb 05 21:31:23 rmilecki: what wireless driver are you using in monitor mode? Feb 05 21:31:33 nbd: brcmfmac Feb 05 21:33:24 nbd: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a8d7631858aff156b72f807ee7cc062048e63836 ("brcmfmac: handle msgbuf packets marked with monitor mode flag") Feb 05 21:33:35 nbd: you may want to check brcmf_netif_mon_rx() Feb 05 21:35:13 rmilecki: take a look at openwrt commit 0c285bd081da55bd63da18f7596e7107a46bb798 - maybe it can help in your case too Feb 05 21:37:18 nbd: interesting behavior Feb 05 21:37:34 thanks, i'll see if I can use that to implement similar change in brcmfmac Feb 05 21:37:40 one possible scenario is this: Feb 05 21:37:59 monitor mode reports lots of packets, and ethernet gets packets too Feb 05 21:38:23 if you alternate refilling the ethernet ring and the wifi ring, you get compound pages that are used by both Feb 05 21:39:02 or something where a compound page is held up in the rx ring for just one or two fragments Feb 05 21:39:07 nbd: actually I was running monitor mode on device that didn't have any clients (wired or wireless) - if that matters... Feb 05 21:39:37 shouldn't matter, as long as both wireless and ethernet receive packets somehow Feb 05 21:39:53 from monitor traffic on wireless and from broadcast traffic on ethernet Feb 05 21:40:15 i did see similar behavior on ramips and ar71xx Feb 05 21:40:31 it also looked like a memleak, but memory got freed on wifi restart Feb 05 21:40:46 the commit i posted above got rid of that behavior Feb 05 21:41:05 ok, thanks for pointing that out! Feb 05 22:24:47 oh great spamhaus are being professional again. Feb 05 22:30:40 xback: I have some patches for you again: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/for_koen **** ENDING LOGGING AT Thu Feb 06 02:59:57 2020