**** BEGIN LOGGING AT Tue Jul 17 03:00:03 2018 Jul 17 03:00:45 and looks like i'm not the only one https://github.com/openwrt/mt76/issues/188#issuecomment-404343055 Jul 17 03:17:23 sounds like a memory leak Jul 17 04:39:56 build #2 of mediatek/mt7622 is complete: Failure [failed images] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mediatek%2Fmt7622/builds/2 blamelist: Rafa? Mi?ecki Jul 17 04:56:39 anyone with a unify ap around ? Reportedly the wifi is not recongized and I wonder whats going on there Jul 17 05:03:44 jow: that is odd Jul 17 05:03:56 this is on 18.06 or trunk Jul 17 05:04:28 check dmesg for firmware loading errors Jul 17 05:04:48 jow: i got one I've never installed OpenWrt on yet, for months Jul 17 05:05:01 jow: i'm going holidays today, I can see it during weekend or next week Jul 17 05:05:05 blogic: reportedly on 18.06.0-rc2 Jul 17 05:05:12 rmilecki: that would be great Jul 17 05:05:16 jow: could you scroll up for my mtd package questions? Jul 17 05:06:04 jow: and/or you may see if my 2 latest commits in https://git.openwrt.org/?p=openwrt/staging/rmilecki.git;a=shortlog;h=refs/heads/lede-17.01 look good Jul 17 05:06:07 rmilecki: you can remove the hack and just bump to 22 Jul 17 05:06:17 or rather remove the conditional in PKG_REVISION Jul 17 05:06:32 OK, can I also remove condition in PKG_FLAGS? Jul 17 05:06:42 just leaving PKG_FLAGS:=nonshared Jul 17 05:07:03 rmilecki: no, actually wait Jul 17 05:07:45 this is how i handled it initially: https://git.openwrt.org/?p=openwrt/staging/rmilecki.git;a=commitdiff;h=fe04e02ac66b2e313d59d1a8869a687380841c82 Jul 17 05:14:47 rmilecki: the problem is that we need to keep the shared variant available for older image builder that don't have their own copy yet Jul 17 05:15:16 rmilecki: so I suggest to simply increase 21 to 22 but keep both conditionals Jul 17 05:16:00 ok, i'll keep both, thanks Jul 17 05:17:44 blogic: I'm currently looking into "daemon.notice procd: /etc/rc.d/S19dnsmasq: Failed to parse json data: unexpected end of data" Jul 17 05:18:16 blogic: the cause is simply, dnsmasq starts before netifd and /lib/functions/network.sh bails because the ubus network.interface namespace isn't registered yet Jul 17 05:18:33 what I wonder though... did we always start dnsmasq before netifd or is this new? Jul 17 05:18:38 jow: so I did that: Jul 17 05:18:40 -PKG_RELEASE:=21$(if $(SDK),,.1) Jul 17 05:18:41 +PKG_RELEASE:=22$(if $(SDK),,.1) Jul 17 05:18:53 rmilecki: ack! Jul 17 05:18:56 thank you Jul 17 05:18:57 jow: always Jul 17 05:19:19 jow: that message was reported by dizzy Jul 17 05:19:32 interesting... seems like stuff has been getting faster then or something Jul 17 05:19:42 dnsmasq init defintely depends on ubus network.interface Jul 17 05:19:46 correct Jul 17 05:19:56 i was not able to reproduce it Jul 17 05:20:06 I can reliably reproduce it on a wdr4900 Jul 17 05:20:45 dizzy added a sleep 2 to some script as a work around Jul 17 05:22:14 ubus -t 5 wait_for network.interface Jul 17 05:22:21 will add that to the dnsmasq init Jul 17 05:22:50 ok Jul 17 05:23:00 sounds like the correct fix Jul 17 05:39:20 blogic: ok so there is no error to fix in dnsmasq, I'll change functions/network.sh to gracefully handle missing network.interface Jul 17 06:15:22 does anyone know how too flash an ASUS RT-AC58U Jul 17 06:15:49 openwrt-ipq40xx-asus_rt-ac58u-initramfs-fit-uImage.itbopenwrt-ipq40xx-asus_rt-ac58u-squashfs-sysupgrade.bin Jul 17 06:19:13 OutBackDingo: i normally boot the initrams then sysupgrade from there Jul 17 06:19:20 ahhh ipq4 .... Jul 17 06:19:32 OutBackDingo: Follow the instructions from the commit that added support for the device Jul 17 06:19:32 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=87c42101cfb001b4bd418d1201fa4d8c822dc77b Jul 17 06:19:43 that wont work, QCA managed to so badly mess up uboot that ramboot wont work :-D Jul 17 06:21:06 I followed the instructions and now my AC58U is happily running OpenWRT Jul 17 06:22:54 Basically, it's booting the initramfs from TFTP (from the serial console), delete a UBI partition, and perform a sysupgrade Jul 17 06:23:23 luaraneda: yeah unfortuinately those instructions require a serial console which i dont have Jul 17 06:25:14 blogic: boot initramfs requires serial console also Jul 17 06:25:23 Sadly there isn't yet a -factory.bin image for the device, which would allow to install without a seria cable Jul 17 06:26:39 luaraneda: so i tried the all in oone image i found which did wortk, hhowever i couldnt sysupgrade to a newer openwrt image Jul 17 06:27:53 if i could do that, and get a recent image i built installed after via sysupgrade id be done Jul 17 06:28:38 blogic: unfortunately the ubus wait_for solution does not work (request timeout) Jul 17 06:29:06 jow: hmmmz Jul 17 06:29:15 I suppose some circular ubus thing as the service registration itself runs in an ubus call context Jul 17 06:32:19 OutBackDingo: Can you ssh to that all-in-one image? You could try to sysupgrade from the command line to obtain more info about why it fails. I'm assuming it's based on OpenWRT (I think I read about it some time ago) Jul 17 06:33:06 jow: correct Jul 17 06:33:08 crap Jul 17 06:33:17 luaraneda: http://lede-ac58u.zyxmon.org/HowToFlashENG.html Jul 17 06:33:30 is where i found the original install instructions Jul 17 06:36:21 jow: gimme 15, doing ath79 kernel upstream foo Jul 17 06:36:33 i'll spend some brain cycles on the problem when done Jul 17 06:36:38 where there is a link to the openwrt-r1834-0f04829-ipq806x-asus_rt-ac58u-squashfs-flash-factory.trx only that image is ipq806x based and not ipq804... Jul 17 06:38:34 ipq806x and ipq40xx were maintained in a single target back then, now they're two different targets - but that's of no real difference to the user (although it did make support for the ac58u possible as a side effect) Jul 17 06:38:38 OutBackDingo: I believe the firmware you downloaded was compiled from this repo https://github.com/LEDE-RT-AC58U/LEDE_RT-AC58U Jul 17 06:39:20 yes it was, which no longer builds Jul 17 06:39:25 luaraneda: Jul 17 06:39:36 ^ Jul 17 06:39:40 The last commit was before the split of ipq40xx from the ipq806x target Jul 17 06:42:30 luaraneda: meaning Jul 17 06:42:51 im wondering if i can flash his factory image and sysupgrade to my built image Jul 17 06:50:15 OutBackDingo: It might be posible, but it will depend on the modifications done to the source code Jul 17 06:57:45 OutBackDingo: I don't know if this is possible, and it might brick your device if isn't, but you could try to manually execute the nand sysupgrade commands (delete and create UBI volumes, flash extracted volumes from sysupgrade image). You will have to read and understand the sysupgrade steps before doing it Jul 17 07:05:30 karlp: https://github.com/openwrt/openwrt/pull/747/commits/65263a9ea139c9e8996d3709b1d0672510d2ed86 Jul 17 07:05:33 is that still valid ? Jul 17 07:07:48 luaraneda: nope... that idea failed Jul 17 07:08:42 blogic: I begin to doubt how that dnsmasq-before-netifd init thing could ever have worked Jul 17 07:09:23 jow: and we simply never saw the message ? Jul 17 07:09:35 blogic: I think it heavily relies on the timing. We do have this concurrent runqueue in procd which only allows a certain amount of processes to be run in parallel Jul 17 07:10:10 I could imagine that on some boards, one service takes slightly longer, causing dnsmasq and netifd to not end up in the same "run bucket" (running parallel) Jul 17 07:11:14 so my working theory is that it usually works because dnsamsq and netifd happen to be started concurrently and because dnsmasq init is rather slow due to the huge amounts of shell code Jul 17 07:11:56 hmmm Jul 17 07:11:59 and on those few boards where the error can be observed, dnsmasq is started first, then the runqueues q->running_tasks is execeeded, causing netifd startup to wait for dnsmasq completion Jul 17 07:12:05 procd does use runqueue Jul 17 07:12:06 jow: quick message: I'll have to reboot the VMs at some point (RAM reallocation), maybe we can sync that with config update? Won't bother you now though: I'm on the train ;) Jul 17 07:12:14 but imho it was sequential during init Jul 17 07:12:25 blogic: semi sequential Jul 17 07:13:02 the way I understand runqueue.c / __runqueue_start_next() it starts at most q->max_running_tasks in parallel Jul 17 07:13:47 ah nvm - max_running tasks is defined as 1 Jul 17 07:13:53 for procd Jul 17 07:13:56 yes Jul 17 07:14:03 for hotplug it was parallel i think Jul 17 07:14:13 (I like how rcS.c calls itself "* runqueue-example.c Jul 17 07:14:21 " ... in the header comment) Jul 17 07:14:43 copy & pasta Jul 17 07:15:27 I see that q_initd_run() forks Jul 17 07:15:51 is the runqueue tracking the forked processes ? Jul 17 07:16:19 ah yes, it does Jul 17 07:16:27 correct Jul 17 07:16:33 using uloop_process Jul 17 07:16:43 so even greater mystery... how could dnsmasq init ever have worked Jul 17 07:17:38 I mean I get how it works, its usually restarted a few more times by hotplug later on so we could as well make boot() a no-op Jul 17 07:18:04 and I suppose that https://bugs.openwrt.org/index.php?do=details&task_id=1542 is caused by a system setup not triggering hotplug reloads somehow Jul 17 07:46:26 blogic: I figured it out - dnsmasq previously never started at boot, dedeckeh'c commit introduced the regression Jul 17 07:46:56 "0e84393ee2 dnsmasq: fix dnsmasq startup issue" changed the boot() no-op to a full start sequence Jul 17 07:47:29 dedeckeh: ping :) Jul 17 07:53:08 * blogic gets the trout ready Jul 17 07:53:12 :-D Jul 17 07:53:21 ;) Jul 17 08:49:46 jow:pong Jul 17 08:50:20 dedeckeh: about your dnsmasq start up fix that removed the special boot() handling Jul 17 08:50:53 dedeckeh: there are various issues with the change. The most important one is that there is no ubus network.interface data vailable yet (since netifd is started @ 20 while dnsmasq @ 19) Jul 17 08:51:12 dedeckeh: which means that the various network_get_interface, network_get_ipaddr calls all fail Jul 17 08:51:57 dedeckeh: that by itself should not be fatal as later hotplug events should restart dnsmasq, this time with fully available network state Jul 17 08:52:18 dedeckeh: however for some reason this doesn ot appear to work reliably in all cases: https://bugs.openwrt.org/index.php?do=details&task_id=1542 Jul 17 08:54:41 jow:hmmmm ok ... Jul 17 08:55:09 I think we should do multiple things to address this Jul 17 08:55:14 jow:that commit was added to fix an issue triggering frequent dnsmasq reloads Jul 17 08:55:19 1) swap boot prio of network and dnsmasq Jul 17 08:56:17 so make sure network info is available when dnsmasq starts Jul 17 08:56:49 2) on boot, skip the whole dhcp pool handling since the network needs to settle anyway, yet Jul 17 08:59:55 jow:with the dhcp pool handling you mean skip dhcp_add on boot ? Jul 17 09:00:06 yeah Jul 17 09:00:19 only register the triggers Jul 17 09:01:20 basically any network_*() will be unavaialble on boot unless we swap prio Jul 17 09:01:32 but if we swap the prio I am not sure if we'd miss events Jul 17 09:01:52 so maybe its better to keep starting before netifd but skip anything that relates to network runtime info Jul 17 09:02:25 jow:I fear if we swap prios we will be vulnerable to further race conditions Jul 17 09:02:26 I have no explaination for FS#1542 yet, I asked the reporter for further infromation to see if anything is special abut the config Jul 17 09:04:06 jow:can you reproduce the issue as I failed in reproducing it ? Jul 17 09:04:39 I can reproduce the /etc/rc.d/S19dnsmasq errors Jul 17 09:06:02 but not the missing DHCP range setup Jul 17 09:10:00 i have same /etc/rc.d/S19dnsmasq: Failed to parse json data: unexpected end of data Jul 17 09:10:13 ds_shadof: yeah, that error is uncritical Jul 17 09:10:14 https://pastebin.com/Vfu3SvU2 Jul 17 09:10:47 ds_shadof: or do you encounter the same problem where dnsmasq comes up without a DHCP range? Jul 17 09:11:32 dedeckeh: what I noticed in the ticket is that the dnsmasq init is apparently invoked multiple times with non-yet-avaialble network state. I wonder if netifd delivers interface hotplug events before the ubus objects are registered Jul 17 09:11:50 Here, I see only one pre-netifd start attempt Jul 17 09:12:06 ds_shadof: can you pastebin a full boot log? Jul 17 09:14:30 https://pastebin.com/9JfSr3p8 Jul 17 09:15:12 so i disabled dnsmasq start at 19, and start it later when all network ifaces is up Jul 17 09:16:15 jow:interface_queue_event in netifd first triggers ubus events and than launches hotplug event Jul 17 09:17:16 dedeckeh: and theu bus objects are registered by then? Jul 17 09:17:50 ds_shadof: your boot log looks okay, in line 280 dnsmasq is restarted by the lan hotplug event Jul 17 09:18:42 dedeckeh: what about only starting on boot when no triggers got registered? Jul 17 09:19:25 ... nvm that'd break dns in some configuration sceanrios Jul 17 09:20:02 indeed that triggered another issue which I fixed in commit 0e84393ee2 Jul 17 09:29:53 jow:I've the followig changes https://pastebin.com/E56fTwn2 Jul 17 09:30:14 jow:works fine on my setup Jul 17 09:32:13 jow: in the context of replacing support for a device that required bootloader reflash with support for native bootloader, keeping the same DTS file (modified), is changing the image name enough of a safeguard? Jul 17 09:44:23 dedeckeh: loks like a start Jul 17 09:44:45 dedeckeh: it could still fail with option interface / notinterface Jul 17 09:44:54 as these will not resolve on boot Jul 17 09:52:02 DonkeyHotei: ping Jul 17 10:36:47 any objections against adding libcap-ng in core repo? and enabling support for it in tcpdump-full? Jul 17 11:31:37 stintel: sounds legit Jul 17 11:49:11 btw I'm bumping 4.14 to .56 Jul 17 11:52:20 /o\ Jul 17 11:53:47 jow: bad idea? :P Jul 17 11:56:09 nono, all fine :) Jul 17 11:56:17 I just hope it fixes more than what it breaks this time Jul 17 11:56:26 :D Jul 17 11:56:42 7 CVEs Jul 17 11:56:48 but those are from .55 Jul 17 12:03:50 jow:could you have a look at https://git.openwrt.org/?p=openwrt/staging/dedeckeh.git;a=commitdiff;h=d78a6fd15c69e6aaa4f88a83761b9ebad27c4638;hp=2169798fa4ec33cab927c2042f72c4f519b9020a ? Jul 17 12:04:10 jow:and maybe try it on your setup ? Jul 17 12:13:51 jow: :-) Jul 17 12:29:21 muhaha: pong Jul 17 12:31:08 DonkeyHotei: Are you using lxc-monitord ? I am seeing weir messages in log WARN lxc_monitor - monitor.c:lxc_monitor_fifo_send:111 - Failed to open fifo to send message: No such file or directory. ... I did not find any init.d file for monitord... Jul 17 12:33:24 i haven't gotten around to actually using lxc on that thing yet. other things have higher priority atm Jul 17 12:46:59 Hi all, having a recurring error during building an image of 18.06-rc1 for the Nanopi Neo2, which I've added as a target Jul 17 12:47:02 https://pastebin.com/xKNfPBNq Jul 17 12:49:48 leperet: you need to find where the boot.scr file is generated and make sure it has the correct name Jul 17 12:50:19 leperet: where is sun50i-h5-nanopi-neo2-boot.scr supposed to come from? I see nothing in target/linux/sunxi/ that would generate it Jul 17 12:50:33 usually .scr files are created by a series of echo commands or shipped with the target filder Jul 17 12:52:15 or taking arc770 as example, the .scr files is created using mkimage from an input plain .txt file Jul 17 12:52:19 *file Jul 17 12:53:46 @jow: my modified branch is here https://github.com/lePereT/openwrt/tree/newbranch/target/linux/sunxi Jul 17 12:57:25 leperet: ah, in the sunxi case the .scr file is created by package/boot/uboot-sunxi Jul 17 12:58:48 jow: dammit, i realise now where I went wrong Jul 17 12:58:55 aha, 4.14.56 not booting \o/ Jul 17 12:58:55 Thank you! Jul 17 12:59:19 leperet: I would guess that you need to clone U-Boot/nanopi_neo_plus2 into U-Boot/nanopi_neo2 Jul 17 12:59:26 within package/boot/uboot-sunxi/Makefile Jul 17 12:59:50 Yup, I cloned, but then didn't add the target. Like a grade A doofus Jul 17 13:00:24 stintel: cool Jul 17 13:03:20 it does in qemu, but my apu2 isn't coming back Jul 17 13:03:41 time to attach serial Jul 17 13:04:16 I'm ~70km away from it :P Jul 17 13:04:29 :/ Jul 17 13:04:31 but boot sequence doesn't complete in qemu either Jul 17 13:06:38 build #3 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mediatek%2Fmt7622/builds/3 Jul 17 13:26:35 hahaha Jul 17 13:26:38 ext4 errors Jul 17 13:26:40 ofcourse! Jul 17 13:28:16 ext4_has_uninit_itable Jul 17 13:30:44 oh Jul 17 13:31:02 that might actually be package/utils/e2fsprogs: Update to 1.44.3 Jul 17 13:31:03 grmbl Jul 17 13:37:52 build #3 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mediatek%2Fmt7623/builds/3 Jul 17 13:44:35 stintel: My self-done update to 4.14.55 somehow killed my router. I'm not sure why though because the USB-serial console inconvieniently died at the same time, resulting in a firm-brick. Jul 17 13:45:20 mamarley: are you using ext4-based image ? Jul 17 13:45:29 stintel: Indeed I am. Jul 17 13:45:44 ext4 seems to be broken Jul 17 13:46:13 In retrospect we shouldn't have bumped to 4.14 at all Jul 17 13:46:25 4.14 is a disaster, indeed Jul 17 13:46:40 but yeah we can blame intel and amd and arm and ibm for that Jul 17 13:46:42 testing 4.9 for months and then hastily hop to 4.14 because "oh shiny offloading" (which apparently doesn't work well either) Jul 17 13:47:04 lessons learned :) Jul 17 13:47:11 should have sticked with 4.9 and release in january Jul 17 13:47:41 and for this crapheap of a bug pile we alos lose support for a whole bunch of devices due to size Jul 17 13:48:06 yeah but that's bound to happen anyway Jul 17 13:48:17 yes but its a difference of one to two years Jul 17 13:48:35 maybe "fixed" kernel ext4 doesn't like image generated by make_ext4fs Jul 17 13:48:47 which is plenty given that many oem's lifecycles do not even reach such time spans Jul 17 13:49:07 does it print anything useful in qemu? Jul 17 13:49:19 are there any specific ext4 related changes in 4.14.56 ? Jul 17 13:49:31 no but in 4.14.55 are many Jul 17 13:49:36 sigh Jul 17 13:49:50 hey, lets "optimize" the file system driver in a minor release Jul 17 13:50:03 I thought it was a security bug fix? Jul 17 13:50:03 its probably fine, distros will take care of the fallout Jul 17 13:50:18 there are 7 CVEs Jul 17 13:50:23 fixed in 4.14.55 Jul 17 13:50:31 yeah some xattr or extends fuzzing stuff iirc Jul 17 13:50:32 ext4: add more mount time checks of the superblock Jul 17 13:50:41 that sounds like a candidate Jul 17 13:50:51 could very well be that our make_ext4 creates out of spec superblocks Jul 17 13:50:57 actually, ext4: add more inode number paranoia checks Jul 17 13:50:58 maybe worth looking at android git for updates Jul 17 13:51:02 indeed Jul 17 13:52:00 I ended up replacing the router that 4.14.55 bricked by setting up a homebrew router on the Ubuntu installation of my existing server, but the original router's days were apparently numbered anyway since the console was defective. Jul 17 13:54:15 It looks like those ext4 commits went in to 4.9.x as well, so that may very well also have broken. Jul 17 13:54:33 https://android.googlesource.com/platform/system/extras/+log/c2470654d4b4db09a7052fc5fa108ac21f1b1948/ext4_utils Jul 17 13:54:40 last commit 7 years ago Jul 17 13:55:03 can we just ditch make_ext4fs altogether ? Jul 17 13:55:09 only x86 seems to use it anyway? Jul 17 13:55:23 What would x86 do then? Jul 17 13:55:43 oh wait Jul 17 13:55:55 no, I misread Jul 17 13:56:04 Image/mkfs/ext4 uses it Jul 17 14:04:37 stintel: there are no good alternatives to it Jul 17 14:04:52 especially none that generate sparse files Jul 17 14:05:13 the old genext2fs + convert to ext4 was very ram intensive Jul 17 14:05:20 it required as much ram as the image was large Jul 17 14:17:55 need increase mlock size, it is hard limited to 64KB via ulimit, where can I increase this hard limit? could not find 'limits.conf' on openwrt Jul 17 14:18:22 i have a program that need to mlock 2MB Jul 17 14:18:36 blogic: that ath79 wdt -> regular interrupt is still valid in my mind. pepe2k said I should fix it in the bootloader, but.... that's not happening. Jul 17 14:18:43 I'm certainly going to keep carrying it. Jul 17 14:19:37 in an ideal world, someone would implement the watchdog pre timeout governor or something, so you could configure it at runtime. Jul 17 14:22:33 jow: is offloading broken ten? Jul 17 14:22:34 then* Jul 17 14:27:16 gninrom Jul 17 14:35:30 jow: then I guess I'll have to do some digging :) Jul 17 14:37:02 freshly built x86/64 ext4 image, kpartx -a then fsck.ext4 on /dev/mapper/loop0p2 -> clean Jul 17 14:37:21 after running the image in qemu however, fsck finds errors Jul 17 15:10:02 stintel: comparing superblock before/after might be worthwhile Jul 17 15:11:20 now I couldn't reproduce it Jul 17 15:16:52 it had to be some dwarf in the system :-) Jul 17 15:42:53 now I'm getting this all of a sudden: Package libmosquittopp is missing dependencies for the following libraries: libmosquitto.so.1 Jul 17 15:43:15 you've had that before, and complained to me, and then you resolved it by cleaning and rebuilding iirc... Jul 17 15:43:25 karlp: I just did a make dirclean :/ Jul 17 15:43:30 * karlp shrugs Jul 17 15:43:39 I've not touched it's deps in a while now. Jul 17 15:43:57 perhaps it's trying to build ilbmosuqittopp before libmosquitto has been built? Jul 17 15:44:16 make package/mosquitto/{clean,compile} V=s -j1? Jul 17 15:53:22 still :/ wtf Jul 17 16:33:02 karlp: irclogs/2018/04/Freenode/#lede-dev.log:05|00:31:00< stintel> anyone else seeing this? Package libmosquittopp is missing dependencies for the following libraries: Jul 17 16:33:10 and https://gist.github.com/stintel/5a22a4569623dbcd1f5d16cc075644bd/revisions Jul 17 16:33:18 that's apparently how I "fixed" it Jul 17 16:35:35 going to uninstall mosquitto on my build box host system and see if that helps Jul 17 16:36:36 stintel: whats reported by cat staging_dir/target-*/pkginfo/libmosquittopp.provides and cat staging_dir/target-*/pkginfo/libmosquitto.provides ? Jul 17 16:38:38 jow: https://gist.github.com/stintel/4b6f2883668ac509fc4c7bd3761368e9 Jul 17 16:40:23 karlp: ahhhh Jul 17 16:40:28 karlp: hmmmm Jul 17 16:40:38 lets reopen the PR in that case Jul 17 17:05:22 ldir: ping Jul 17 17:09:28 tobleminer-tSYS: thanks for the feedback, all good! Jul 17 17:27:43 hi folks - anyone know if there is an equivalent of the 'post-up' network script call in 18? Jul 17 17:28:05 i want some scripties to run after an interface has come up Jul 17 17:28:22 (or perhaps there is a more 'proper' way of doing it?) Jul 17 17:53:36 any one seen any god routers going on prime day? Jul 17 17:53:46 good** lol Jul 17 18:36:54 Tapper: netgear r7800 seems to be relatively cheap (118.99 EUR) Jul 17 18:36:59 stintel: some random idea I head wrt. ext4, maybe you could trying to run e2fsck on a generated image? Jul 17 18:37:12 stintel: see if it complains Jul 17 18:38:53 Tapper: linksys wrt3200acm as well (136.99 EUR) Jul 17 18:39:09 jow: I did that, it didn't Jul 17 18:39:26 but maybe I need a newer e2fsprogs on my host Jul 17 18:39:58 first going to revive my router Jul 17 18:40:11 and have a trackday tomorrow, need to prepare some stuff for that as well :/ Jul 17 18:40:34 meanwhile we should not accept kernel bumps until we have a fix or workaround Jul 17 18:43:01 stintel: we could just add target/linux/generic/reverts-4.14/* Jul 17 18:43:02 :-D Jul 17 18:43:48 :D Jul 17 18:44:53 would adding a revert patch be acceptable until we fix make_ext4fs (assuming that is causing the problem) Jul 17 18:46:10 that's probably the safest option, even more if it can be bisected to an individual problematic commit (in which case contacting the ext4 maintainers could help as well) Jul 17 18:55:45 no Jul 17 18:55:59 fixing our mkfs would be the correct solution Jul 17 18:56:17 should be easy to track down Jul 17 18:58:11 blogic: totally not familiar with that stuff unfortunately Jul 17 19:06:22 ok Jul 17 19:06:32 so i can trigger this using qemu on x86 ? Jul 17 19:14:04 blogic: allegedly yes Jul 17 19:22:54 blogic: yes Jul 17 19:23:08 blogic: I can push the 4.14.56 bump to my staging tree Jul 17 19:24:04 blogic: done Jul 17 19:29:44 stintel: thanks Jul 17 19:30:13 can someone merge my fw3 patch pls :D Jul 17 19:30:21 thx and please Jul 17 21:04:36 ldir: ping? Jul 17 22:34:03 have you heard about turris mox? Jul 17 22:51:22 kab-el: your question is probably quite a bit too vague to actually answer, but it can be assumed that quite a few are aware of the existence of the project that plans to release something fuzzy called turris mox (if you consider this answer to be even more vague, it's because it actually is vague at this point) Jul 17 22:56:12 i wonder how that project even got funded Jul 17 22:56:35 same way the omnia did? Jul 17 22:56:38 it was ~80% 3 days before the deadline Jul 17 22:56:40 no Jul 17 22:56:55 omnia got funded within 24 hours Jul 17 22:58:59 the omnia is a sane device, it's beyond my budget (and imho even regardless of that too expensive (yes, I know, small scale can't be much cheaper, doesn't change that it's too expensive realtive to its big-scale commercial competition), but I'd love to have bought the hardware. the turris mox does not tickle me the slightest Jul 17 23:00:53 and the way cz.nic suggested OpenWrt compatibility, but never helped with it at all, wouldn't sway me over either Jul 17 23:02:53 agreed Jul 17 23:03:08 maybe they'll look at openwrt once 18.06 becomes stable Jul 17 23:05:24 can anybody recommend a good pcb design company? I have a specification, but no schematic. Jul 17 23:29:36 mangix: they are looking at openwrt now Jul 17 23:30:53 sure they are, in a one-sided way as they have before, I doubt it will result in /any/ patches from their side though Jul 17 23:32:14 there was an attempt to add turrisos updater to openwrt, but it was too complicated and cz.nic did not have enough manhours Jul 17 23:32:39 they will try to mainline support for turris mox, though, into openwrt and into mainline kernel, as well Jul 17 23:33:05 wake me up when it's there, they have created precedent, and it isn't pretty Jul 17 23:33:11 well it's mailined to the kernel Jul 17 23:33:49 not fully yet Jul 17 23:33:51 one of my projects was to get ALARM booting on it. need to pick it back up Jul 17 23:34:02 sfp on omnia does not work withouth kernel patches yet Jul 17 23:34:05 what's missing? LED driver? Jul 17 23:34:16 why is SFP not working Jul 17 23:35:13 because the way sfp and wan port are connected. There is a sgmii multiplexer which disconnects wan port and connects sfp port when sfp module is connected Jul 17 23:35:23 this functionality is not in phylink abstraction yet Jul 17 23:35:48 i communicated with russell king about this, and it is a little compilcated Jul 17 23:35:56 interesting... Jul 17 23:36:37 if russel king knows about this, it's ony a matter of time then Jul 17 23:37:16 and also the switch in omnia is connected to CPU via two sgmii interfaces, but mainline kernel dsa driver cannot currently support more than one cpu port Jul 17 23:37:29 that's not really an issue Jul 17 23:38:09 unless you reassign one of the switch ports to a WAN port for some reason Jul 17 23:38:13 yes, but i think i will have to work on this as well after sfp Jul 17 23:38:33 its an issue if you want faster connection :) Jul 17 23:38:57 faster in what way? iperf3 maxes out gigabit Jul 17 23:39:22 but only via one port Jul 17 23:39:35 if you try to push gigabit via each lan port, it won't work Jul 17 23:39:54 one sgmii interface can only give 2.5 gbps Jul 17 23:39:59 sure. but that's still an extreme use case. Jul 17 23:40:08 may be useful for NAS Jul 17 23:40:17 in turrisos the separate lan 4 port is connected to the second cpu port Jul 17 23:40:22 kab-el: wanting to use both CPU ports is nice to have, but not required for initial device support - it's nice to have, something to work on for further optimization, but nothing that's mandatory to be present on day 12 Jul 17 23:40:41 no idea if DSA supports pair bonding Jul 17 23:40:53 pkgadd: i know, i will work on this only after everything else Jul 17 23:41:23 mangix: i was in contact with andrew lunn some time ago and he said that it won't be much work Jul 17 23:41:39 there already were attempts to add support for more cpu ports Jul 17 23:42:09 there was talk of it a while back Jul 17 23:42:28 those attempts failed since upstream kept moving the goalpost Jul 17 23:42:46 but they did not provide a good way to set which lan port is connected to which cpu port Jul 17 23:43:56 That dual CPU port issue is very real on devices that have only gigabit interfaces between the switch and CPU though. For example, on the Linksys WRT1200/1900/3200, OpenWRT can currently handle full-duplex routing at the line rate. With only one CPU port, the performance would be cut in half, which is a very real issue for anyone with Google Fiber or AT&T GigaPower or other such 1000/1000 services. Jul 17 23:44:30 mamarley: not on the omnia though :) Jul 17 23:45:14 but it would still be good to have it in mainline kernel and it does not matter if the patch is accepted mainly because of omnia Jul 17 23:46:13 in my opinion turris mox is interesting because one can add three 8-port switch modules, totalling to 24 lan ports Jul 17 23:47:10 uhhh Jul 17 23:47:13 you sure? Jul 17 23:47:25 yes im sure Jul 17 23:47:43 can you? really? given the coding, I think you can only add a single module of each kind (unless they offer the 8-port switch in all 4 possible multiplexes, which I kind of doubt - and your switch fabric wouldn't be fast enough for that either( Jul 17 23:48:13 the 8-port switch module gives sgmii passthrough Jul 17 23:48:18 https://www.marvell.com/switching/assets/LinkStreet_88E6390X_FINAL2.pdf Jul 17 23:48:49 there are 2 sgmii ports, one is connected to previous module (cpu or previous same module), the other for next module Jul 17 23:49:01 btw dsa has another silent benefit Jul 17 23:49:05 lower latency Jul 17 23:49:22 88e6390 supports crosschip switching and it already is in mainline kernel Jul 17 23:50:07 so you can connect [mox cpu module]-[8-port switch]-[8-port switch]-[8-port-switch]-[sfp module] Jul 17 23:50:13 for example Jul 17 23:50:54 in my opinion this was the real killer feature Jul 17 23:51:12 but they didn't put it in the front page of the campaign, sadly Jul 17 23:52:02 it could be, if it were actually true - and I'm not convinced until it's confirmed on the actual hardware (and performance of the cross-switch fabric not to suck) Jul 17 23:52:45 yes, true Jul 17 23:52:58 perhaps this week i will know alread Jul 17 23:53:00 already Jul 17 23:53:08 if not, then in three weeks Jul 17 23:54:56 i'm using dsa on my 7800. turns out both ports are connected to the switch. sadface. Jul 18 00:24:20 build #48 of lantiq/xrx200 is complete: Failure [failed sourceupload] Build details are at http://release-builds.openwrt.org/18.06/images/builders/lantiq%2Fxrx200/builds/48 blamelist: Jo-Philipp Wich Jul 18 00:24:20 build #47 of brcm2708/bcm2709 is complete: Failure [failed sourceupload] Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm2708%2Fbcm2709/builds/47 blamelist: Jo-Philipp Wich Jul 18 00:38:47 anyone have any idea why the ethernet on an older kirkwood (pogoplug) would keep flapping? sound like hw failure? Jul 18 00:39:07 * m4t really needs to update the software on it too Jul 18 00:40:07 barrier breaker 😳 Jul 18 00:40:53 it's not the switch because it did this hooked up to my rspro as well as the current hp switch. and multiple cables. Jul 18 00:42:01 sounds like a question for #openwrt Jul 18 00:42:06 anything in dmesg? Jul 18 00:43:47 nah just the port going up/down sporadically many times per day. i just turned off autoneg on the switch port. Jul 18 00:43:50 * m4t crosses fingers Jul 18 00:45:36 flapped 257 times so far this month, 416 since november Jul 18 00:45:56 if that doesn't work i'll cap it at 100mb i guess Jul 18 00:50:20 m4t: why not arch linux? Jul 18 00:51:05 uhm at the time it was a custom "port". real-time kernel, gps pps connected to the former LED gpio, running ubifs from nand, etc. Jul 18 00:51:33 i was going for 1000 days uptime then my UPS failed. twas working on bringing it up with a recent openembedded rootfs then got distracted and put it on the backburner lol. Jul 18 00:52:39 * mangix hates that device Jul 18 00:52:45 TSO is totally broken on it Jul 18 00:52:48 try disabling it Jul 18 00:53:56 ah yeah i see a patch to disable it in 4.9 Jul 18 00:54:02 maybe ethtool will do Jul 18 00:54:29 gso should be good enough Jul 18 00:56:35 yeah it sees literally only a few ntp packets per minute if that hehe Jul 18 00:58:11 hrm it's already off: tcp-segmentation-offload: off Jul 18 01:00:47 maybe some of the other stuff? no idea Jul 18 01:01:35 i'll play with those if disabling autoneg doesnt fix it Jul 18 01:03:03 m4t, good point regarding autoneg, I've heard it can sometimes be a problem with some equipment and setting the values solves the issue on some HW Jul 18 01:03:33 i'll be sad if it's something with the hardware, it's such a nice stable little ntp server otherwise Jul 18 01:04:00 maybe that'll give me the motivation i need to finally bring it current sw wise **** ENDING LOGGING AT Wed Jul 18 03:00:01 2018