**** BEGIN LOGGING AT Mon Dec 10 03:00:00 2018 Dec 10 04:19:27 what's the best way to set up a LED that is on when an interface is down, but off when it is up? sort of the opposite of a netdev link Dec 10 06:11:48 does anyone know how to specify an offset in device tree? Dec 10 06:11:59 in a memory mapped device Dec 10 06:30:03 biangbia_: if that is GPIO controller LED, you can fake it being active by an opposite value Dec 10 06:30:10 e..g. replace ACTIVE_LOW with ACTIVE_HIGH Dec 10 06:30:15 but it's the most hacky wayt Dec 10 06:30:18 definitely not the best way Dec 10 06:30:32 the best way is to extrend trigger to allow such a configuration Dec 10 06:30:49 that's just dangerous and crazy enough to work :) Dec 10 06:30:56 so then user can do sth like echo 1 > /sys/class/leds/*/reverse Dec 10 06:30:59 or sth like that Dec 10 06:33:40 i'd like to look into extending rssileds to work with modems Dec 10 06:34:43 and as i was thinking about it did occur to me that we might need at least one more led trigger for that concept to work Dec 10 09:45:11 Borromini: the 4.9 bump is marked as Work-In-Progress as it contains changes which I could not verify myself. Stintel checked these parts and altered the patch accordingly Dec 10 09:46:24 i'll push 3.18 and 4.14 hopefully this morning still, stintel will push the altered 4.9 on top of it Dec 10 09:46:51 after those are done, ill make new bumps to push again to the latest, minimizing any risks Dec 10 09:48:08 xback: feel free to grab the updated commit from my staging tree and push all 3 at once Dec 10 09:48:18 not sure if I will get to it today Dec 10 09:48:26 stintel, ok. thanks Dec 10 09:48:41 np, thank you too Dec 10 09:48:53 brcm2708 to 4.14 is gonna be delayed again Dec 10 09:49:04 no wifi when HDMI isn't plugged in on rpi0w :/ Dec 10 09:49:18 did you runtime tested the 4.9 patch on bcm2708? Dec 10 09:49:52 Linux sensorpi0w-01 4.9.143 #0 Fri Dec 7 03:41:54 2018 armv6l GNU/Linux Dec 10 09:50:05 11:50:02 up 1 day, 8:37, load average: 0.19, 0.19, 0.12 Dec 10 09:50:22 build #24 of ath79/generic is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fgeneric/builds/24 blamelist: Kevin Darbyshire-Bryant Dec 10 09:50:40 excellent, thanks, looks like the assembly code changes are also working then Dec 10 09:50:49 or I might not be hitting them ;) Dec 10 09:51:08 xback: either way, if there is report of breakage we can just drop that patch entirely Dec 10 09:55:00 xback: actually, we should have looked at https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/lib/copy_from_user.S#L92 Dec 10 09:55:20 iirc our patch results in the same code Dec 10 09:57:54 Hauke: thanks, on it Dec 10 09:58:25 stintel, excellent!. ill double check it to be sure Dec 10 09:58:46 reverted the dnsmasq bump attempt Dec 10 09:59:35 build #23 of ath79/nand is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/23 blamelist: Kevin Darbyshire-Bryant Dec 10 09:59:38 build #23 of ath79/tiny is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Ftiny/builds/23 blamelist: Kevin Darbyshire-Bryant Dec 10 10:08:27 testing raspbian now with the kernel/firmware/modules from rpi themselves to see if it also has the no wifi when headless problem on the zero w Dec 10 10:08:36 I really hope it does, otherwise I'm in for some fun :( Dec 10 10:15:26 build #1250 of x86/64 is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/x86%2F64/builds/1250 blamelist: Kevin Darbyshire-Bryant Dec 10 10:19:57 build #1195 of ar7/ac49x is complete: Failure [failed pkgbuild] Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fac49x/builds/1195 blamelist: Kevin Darbyshire-Bryant Dec 10 10:21:01 owrt-snap-builds: I know! :-) and I reverted the change - and I have a fix now as well Dec 10 10:29:43 heh Dec 10 10:29:45 -rw-r--r-- 1 stijn users 5470743 dec 7 22:26 target/linux/brcm2708/patches-4.14/950-0094-net-Add-non-mainline-source-for-rtl8192cu-wlan.patch Dec 10 10:29:52 gonna drop that one for sure Dec 10 10:36:33 stintel: talkin' to me? Dec 10 10:37:07 xback: nah, just to myself Dec 10 10:37:35 currently compile testing all 4.9 targets (new symbol) and 2x 4.14 targets Dec 10 10:37:48 I'm expecting to push around noon Dec 10 10:37:53 awesome :) Dec 10 10:58:52 build #725 of arc770/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/arc770%2Fgeneric/builds/725 Dec 10 11:04:19 stintel: bumps pushed. Dec 10 11:04:34 i'm currently running the bumps to the latest today Dec 10 11:07:04 xback: awesome, thanks! Dec 10 11:37:25 why are we building this unbound stuff during the phase1 builds? Is it somehow subtarget dependant? Dec 10 11:41:47 stintel: latest bumps in my staging Dec 10 11:44:14 ah, openvswitch, of course Dec 10 11:44:16 sigh Dec 10 12:17:04 does anyone know how to specify an offset in device tree for a memory mapped device? the mac address I am trying to read is offset by 4 Dec 10 12:18:53 i mean 2 bytes Dec 10 12:19:20 Broadcom has released 4366c0 firmware! Dec 10 12:19:27 finally Dec 10 12:19:32 I think it took 2 years or so Dec 10 12:22:28 .oO( I wish they'd release specs for their BCM4331 Wifi chipset... ) Dec 10 12:31:41 biangbiangmian: I'm fairly sure, mtd-mac-address = <&art 0x0>; the 0x0 at the end is the offset into the partition name... Dec 10 12:32:37 grep for mtd-mac-addresse in the dts dir shows lots of options and alternatives... Dec 10 12:34:26 if I'v eonly got a single target selected in ath79, (multi devices, CONFIG_TARGET_MULTI_PROFILE=y but then just a single target) how come I spend ages building kernels for all the other devices? Dec 10 12:41:54 nvm, think it's because I had imagebuilder enabled. Dec 10 12:47:14 build #1145 of brcm47xx/legacy is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm47xx%2Flegacy/builds/1145 Dec 10 13:32:40 my ddns IP is not recognized, since 3 days already an old IP active. What is stuck at openwrt? Dec 10 13:36:17 doesn't likely to be an openwrt problem? Dec 10 14:17:25 karlp, in lucy also a wrong one is displayed in dynamic DDNS Dec 10 14:23:55 "wrong" what? Dec 10 14:24:09 karlp: IP Dec 10 14:25:58 wrong IP Dec 10 14:26:57 can i set the IP manual? Dec 10 15:32:43 hey all, how does opkg determine the kernel version magic of the kernel it is running on? Is vermagic stored in the rootfs? And if so where is it? thanks Dec 10 15:33:24 it's computed when building, using a hash of the kernel config iirc Dec 10 15:35:13 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/kernel-defaults.mk;h=cc1e2361be50437fb725b42cb9248d42d7095649;hb=HEAD#l108 Dec 10 15:35:46 it's stored in the builddir but I don't think it's included in the image itself (you can probably obtain it through "opkg info linux" or something similar) Dec 10 15:43:25 latest kernels pushed to master. I'll handle 18.06 next .. Dec 10 15:45:33 Neighbor11111116: a virtual package "kernel" is installed Dec 10 15:46:00 Neighbor11111116: this package is omitted from the repositories so that you cannot discover (update, upgrade) it Dec 10 15:48:15 makes sense. Thanks jow Dec 10 15:48:30 Neighbor11111116: see https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=scripts/ipkg-make-index.sh;h=dcd11ca191adc36d92d6790cb1a1e61a5be36dce;hb=f6e9f2377119965d4db164568b4a90c4e895cd3d#l17 Dec 10 15:48:32 thanks zorun as well Dec 10 15:49:05 ahh very cool, misses libc as well Dec 10 15:50:21 Neighbor11111116: if you run "find bin/ -name 'kernel*.ipk'" in your buildroot, you should be able to find the "hidden" kernel meta package Dec 10 15:52:38 jow got it. untarred the ipk, data is empty as expected and the control vile contains kernel number and magic version Dec 10 15:52:39 thanks! Dec 10 15:54:18 If opkg uses version field in that control file to represent kernel version then OPKG must be aware of this special virtual ipk. Is that correct? Dec 10 16:07:29 yes, it is "manually" installed during rootfs generation Dec 10 16:08:00 the libc and kernel meta packages are staged using opkg install and the direct path to the .ipk Dec 10 16:08:27 the rest is then installed normally from a transient temporarily created repo made from packages/ Dec 10 16:08:39 *bin/ Dec 10 16:11:42 ok got it. One last unreleated question if you have time jow. I can see that user header files are generated during kernel configuration and stored in $(LINUX_DIR)/user_headers Dec 10 16:14:00 but then I don't see it referenced anywhere. I would have thought PATH would be updated to include $(LINUX_DIR)/user_headers in rules.mk. How does the C preprocessor know to use the latest header files? Or is it not by design so CPP use the headers files that were generated when the toolchain was made. Otherwise one could accidentally use wrong header files. Dec 10 16:22:42 nbd: what's the proper command to refresh gcc patches? "make toolchain/gcc/refresh" doesn't seem to be a valid here. thank you :) Dec 10 16:22:55 xback: try gcc/final/refresh Dec 10 16:23:04 toolchain/gcc/final/frefresh Dec 10 16:23:14 aah. it's hidden even deeper :) Dec 10 16:23:29 jow: thanks. ill give it a try Dec 10 16:24:00 the wiki needs some updating here Dec 10 16:25:28 it is a wiki... :) Dec 10 16:25:37 jow:I've reported the iproute2 issue on the netdev mailing list; waiting for feedback Dec 10 16:26:11 dedeckeh: can't rule out one of our kernel patches Dec 10 16:26:25 what about the thing ipv6 policy rejects etc. Dec 10 16:27:24 jow:I think it's caused by commit https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/lib/json_print.c?id=45ec4771d40cb367377e4148a2af22f25c20f3bf Dec 10 16:27:38 Reverting that patch fixed it for me Dec 10 16:27:57 ah, I think ldir had some issues with this as well Dec 10 16:28:03 cake related Dec 10 16:28:26 I can imagine this to be the case Dec 10 16:29:14 grepping for print_0xhex learns it's called a few times Dec 10 16:30:32 what surprises me a bit is that nobody flagged that issue or at least I could not find any reference to it Dec 10 16:31:16 maybe its arch specific Dec 10 16:31:23 64bit int vs. 32bit int or so Dec 10 16:31:27 hrm, ubus list isn't showing the "file" module, even though /usr/lib/rpcd/file.so is there... Dec 10 16:31:45 oh, hrm, I wonder if I hadn't pulled in that dlload fix Dec 10 16:31:52 maybe not in this branch..... Dec 10 16:31:58 karlp: was about to ask that Dec 10 16:32:06 held off on asking for ages, rechecking things Dec 10 16:32:15 finally ask, and instantly realize what I'd probably not checked :| Dec 10 16:34:57 hrm, except, I've got the latest from package/system/rpcd. Dec 10 16:38:07 karlp: I think I didn't bump it yet Dec 10 16:38:28 karlp: yeah, needs a bump yet Dec 10 16:39:06 oh bah humbug. Dec 10 16:39:47 I take it no-one's been using ubus file then for a couple of weeks :) Dec 10 16:41:42 now just a upnp bug that's master only, and I can go back to 1806 for a while again :) Dec 10 16:59:09 build #728 of layerscape/armv8_32b is complete: Failure [failed kmods] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_32b/builds/728 blamelist: Koen Vandeputte , Kevin Darbyshire-Bryant Dec 10 17:03:45 if I leave out kmod-drm-vc4, the rpi0w boots 4.14 fine without hdmi plugged in Dec 10 17:12:47 is $(LINUX_DIR)/user_headers passed as include path to CPP by OpenWRT? I've grep'd for it but cannot find it Dec 10 17:23:07 jow: is this syntax error in luci related to the new tabbing code you've got in luci? this is my own theme, I could be missing things you're relying on? https://zerobin.net/?2c0b4f4ad308d153#O3rzm6gCmhbvJOK/7AP7P7DxU9vTNOHcS1hL41wy68c= Dec 10 17:23:21 * karlp tries another theme to check Dec 10 17:24:29 I get that on lots of pages Dec 10 17:24:50 aha. it's booting headless now with kmod-drm-vc4 installed Dec 10 17:25:28 looks like all pages using cbis Dec 10 17:30:44 no, brked on all themes. Dec 10 20:17:55 trying to reproduce the wifi not working when HDMI not plugged on rpi0w running 4.14 with CONFIG_KERNEL_GIT_CLONE_URI="https://github.com/raspberrypi/linux.git" but that seems to fail due to things that are enabled in the .config not even building :/ Dec 10 20:19:22 it seems to skip drivers/dma-buf/ completely for example Dec 10 20:36:34 build #1111 of brcm2708/bcm2709 is complete: Failure [failed kmods] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2709/builds/1111 blamelist: Koen Vandeputte , Kevin Darbyshire-Bryant Dec 10 20:44:19 dedeckeh: it's big-endian specific and occurs when there's a 'hidden' promotion/demotion of int size in that the pointer to the assigned value doesn't start at the correct memory address. little endian ints always have the least significant byte at the lowest address. big endian you have to know how big the int is so you point at the most significant byte and eventually arrive at the least significant. Dec 10 20:45:45 ldir:was the issue already reported upstream ? Dec 10 20:46:46 I thought it had been fixed....let me see if I can dig up the commit Dec 10 20:50:45 have a look at 4db2ff0db46f6368d89cfb3498a700e1256d2a04 in iproute2 repo Dec 10 20:54:22 ldir:so it seems there's another issue now Dec 10 20:55:25 ldir:issue reported in https://forum.openwrt.org/t/strange-behavior-of-ip-rule/26597 is caused by https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/lib/json_print.c?id=45ec4771d40cb367377e4148a2af22f25c20f3bf Dec 10 20:59:31 ah yes, it's a different issue but I suspect a similar cause - 'hidden' type changes on big endian = fun fun fun Dec 10 21:00:29 yep is indeed again related to a hidden type change Dec 10 21:04:18 here's where I first alerted https://marc.info/?l=linux-netdev&m=152235195027973&w=2 and then rapidly lost the will due to my perception of lack of interest/care/wanting the fix on a plate/me to do some dance. fortunately Toke picked it up and did something considered more sensible. Clearly there were more gremlins :-) Dec 10 23:13:59 build #114 of layerscape/armv7 is complete: Failure [failed kmods] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv7/builds/114 blamelist: Koen Vandeputte , Kevin Darbyshire-Bryant Dec 10 23:47:35 kim0: have a look at gargoyle Dec 10 23:47:55 https://www.gargoyle-router.com/index.php Dec 11 01:04:17 whee, gadgets on sunxi work nicely now: https://github.com/karlp/openwrt/commit/6133c075f5921400e4a2c822f5700de85b4da8c8 Dec 11 01:04:34 no idea what the current state of dma is for musb though... Dec 11 02:36:44 build #25 of ath79/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fgeneric/builds/25 Dec 11 02:44:07 build #24 of ath79/tiny is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Ftiny/builds/24 **** ENDING LOGGING AT Tue Dec 11 03:00:01 2018