**** BEGIN LOGGING AT Mon Aug 27 03:00:00 2018 Aug 27 05:27:11 is there some reason other than space that VITESSE_PHY is not enabled for ar71xx? several devices have such chips Aug 27 06:26:22 anybody know where i can find kicad footprints for mediatek bga packages? Aug 27 06:43:02 can someone tell me how the /overlay/upper/etc/config get populated, particularly for files that don't change from /rom/etc/config/ ? I've been looking and haven't found it. Aug 27 06:45:20 russell--: populated in what way ? Aug 27 07:02:08 blogic: copy files there Aug 27 07:02:15 to the overlay, that is Aug 27 07:02:58 diff -u /rom/etc/config/dropbear /overlay/upper/etc/config/dropber is empty Aug 27 07:03:11 after first boot Aug 27 07:03:53 i'm trying to figure out what program is responsible for the copying of those files, even if they aren't different Aug 27 07:04:57 i thought it was the "uci commit" in /etc/init.d/boot, but i tried removing that and the files were still copied Aug 27 07:05:30 the ubifs problems i've been seeing only occur for unchanged (from /rom) /etc/config/$foo files Aug 27 07:05:56 and to look closer at what's happening, i need to know what to watch Aug 27 07:21:51 in short, on every target I have looked at, after first boot, there are a number of config files in /overlay that are unchanged from /rom/etc/config/. i'd like to understand how/why they are getting there. Aug 27 07:28:01 gninrom Aug 27 07:35:37 * russell-- is about to pass out, any clues welcome ;-) Aug 27 07:40:22 russell--: beer? Aug 27 07:47:16 russell--: mount_root Aug 27 07:47:39 blogic: in fstools? Aug 27 07:47:44 yes Aug 27 07:47:50 hang on Aug 27 07:48:39 https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/overlay.c;h=14214a3104d9c6ae670437c570c46200db259ed4;hb=HEAD#l404 Aug 27 07:48:44 that function i believe Aug 27 07:49:30 ah line #314 in that file does the "cp" call Aug 27 07:51:19 blogic: i see it, thank you! but, why is the file in /tmp/root? Aug 27 07:51:40 because it is getting moved Aug 27 07:51:58 there is an transient tmpfs that we use while moving the mount Aug 27 07:52:36 the tmpfs overlay? Aug 27 07:52:42 yes Aug 27 07:52:53 so we have a RO mount, then do a tmpfs overlay Aug 27 07:52:59 then prepare the jffs2 overlay Aug 27 07:53:08 but ... i don't understand why that overlay has it if it isn't changed from /rom Aug 27 07:53:16 and once ready move the tmpfs overlay over to the jffs2 Aug 27 07:53:25 has what Aug 27 07:53:37 e.g. /etc/config/dropbear Aug 27 07:53:52 are you sure its not tweaked ? Aug 27 07:54:01 diff says they are identical Aug 27 07:54:09 maybe mtime Aug 27 07:54:21 oh, interesting Aug 27 07:54:58 probably not, but i wonder if the time jump could be screwing with the write back timer Aug 27 07:55:15 or a uci commit for some reason decided to write the file Aug 27 07:56:18 as i mentioned above, the files that i'm finding zero'd out are all the unmodified config files from /rom that are reproduced in the overlayfs Aug 27 07:56:28 on ubifs Aug 27 07:56:38 ah ok, the ubifs issue Aug 27 07:56:42 a sync gets them written to flash Aug 27 07:56:58 but if i yank power, they come back as nul'd out Aug 27 07:57:29 i've been discussing this with the ubifs guy on #linux-mtd Aug 27 07:58:13 before the power yank, reading the files (presumably from cache) they look fine Aug 27 07:58:50 i wonder if the ubifs should just be mounted -o sync Aug 27 07:59:06 it's not like openwrt writes a lot to non-tmpfs anyway Aug 27 07:59:12 could be Aug 27 07:59:20 or its one of our shitty patches Aug 27 08:01:54 * russell-- sleeps on it Aug 27 08:02:39 russell--: which device did you see this issue on? Aug 27 08:03:23 nbd: being reported over and over by users Aug 27 08:03:32 heard that report several times now Aug 27 08:04:03 nbd: i've seen it on every ubifs based device on 4.14.x Aug 27 08:05:53 including ubnt-erx, meraki mr24, but i don't see it on a mikrotik rb493g (4.9.x) Aug 27 08:19:29 the two reports i'm aware of are these: https://forum.openwrt.org/t/ubifs-failure-to-write-back/14214 and https://bugs.openwrt.org/index.php?do=details&task_id=1755 (the latter was my report) Aug 27 08:29:01 blogic: the mtime is identical in the two copies according to ls -alt --full-time /rom/etc/config/dropbear /overlay/upper/etc/config/dropbear Aug 27 10:43:57 nbd: if you're still around, somebody in #openwrt reported an 18.06.0 regression a week ago, still unfixed, introduced by a commit of yours, FS#1797 Aug 27 11:32:34 rmilecki: if you have a minute would you please take a look at https://github.com/openwrt/openwrt/pull/1237 (specifically the last comment about the partitions) Aug 27 11:32:42 the actual .dtsi is at https://github.com/openwrt/openwrt/pull/1237/files/e712c6be0e13852d7293967a9b285519e55dab5f#diff-380feeedd520356278b0b2c3ea1c05d7 Aug 27 11:33:56 oh my, pretty long discussion there Aug 27 11:33:57 basically, is there a more correct way to both dynamically probe redboot FIS to get kernel/rootfs size and also assign mac addresses from the fixed redboot config partition? Aug 27 11:34:04 yeah...one thing after another. Aug 27 11:34:11 kind of on my last leg here tbh Aug 27 11:34:50 i mean, what is there now works without any dtc errors. it seems a lot cleaner than doing it in userspace with dd or something. Aug 27 11:36:10 i agree with mkresin it looks incorrect Aug 27 11:36:34 he linked your mailing list post, i don't understand how to apply what is mentioned there to it Aug 27 11:38:34 mmm, figured out my build failures at least, atomic ops aren't available for some platforms Aug 27 11:38:49 would be really nice if gcc could figure it out and do the right thing Aug 27 11:41:20 m4t: you would have to rewrite redboot-fis-partitions parser to allow specifying nodes (most likely witohut offsets) in DT Aug 27 11:41:32 and then make redboot-fis-partitions bind these nodes to created partitions Aug 27 11:42:07 there's no way to specify an arbitrary flash address for the mac? it *has* to be a partition? Aug 27 11:42:30 what about creating 1 partition the entire range of flash? Aug 27 11:42:35 i don't know, maybe you can point flash node Aug 27 11:42:47 I didn't read kernel code for reading MAC address Aug 27 11:42:55 ok Aug 27 11:43:44 m4t: the point is that you shouldn't assume the partition is always at the same offset if an on flash partition map exists Aug 27 11:44:25 i want to say it's fixed - it's basically the redboot equivalent of a u-boot environment Aug 27 11:44:27 m4t: we just had another on flash partition thingy, where the factroy/config partition moves as well Aug 27 11:44:41 if it' Aug 27 11:44:59 nevermind Aug 27 11:47:43 and if it's the u-boot env equivalent, does it really uses fixed positions for fields. most of the env equivalents I'm aware of have some kind of internal structure (avm tffs, jboot config..) Aug 27 11:49:36 afaik that part isn't writable Aug 27 11:49:41 it doesn't show up in fconfig Aug 27 11:51:25 actually, no, it seems to be a field called ar7100_esa Aug 27 11:51:47 m4t: I'm just asking because we had this kind of issues already. offset didn't worked for board A but for board B. Aug 27 11:52:33 okay so let's say the mac address can be retrieved in ascii format via fconfig in userspace Aug 27 11:52:40 m4t: turned out, some internal structure is used and for some reason the fields were reordered for later produced boards Aug 27 11:52:49 how would you increment that? :/ Aug 27 11:53:26 and it's go in ath79_setup_macs? Aug 27 11:53:30 it'd* Aug 27 11:54:10 m4t: ath79_setup_macs is the right place. macaddr_add is to increment/decrement the mac address Aug 27 11:54:12 wan_mac=$(macaddr_add "$base_mac" 1) Aug 27 11:54:15 yes Aug 27 11:54:35 mkresin: on both board that I have the environment is on the end of a flash, with size 0x1000 Aug 27 11:54:39 okay. i guess i'll do that with fconfig then...it *is* now part of the rspro default_packages Aug 27 11:55:12 m4t: fconfig is the tool to read the config structure? Aug 27 11:55:35 yes it's the equivalent to u-boot fw_printenv or whatever. i mentioned it in the bottom of my commit message. Aug 27 11:55:54 m4t: sorry, missed it Aug 27 11:56:48 m4t: do it similar to the avm boards Aug 27 11:57:00 ok Aug 27 12:02:26 mkresin: should the mac address be left random before being set by 02_network? Aug 27 12:05:35 m4t: not sure if should, but it is in general random till set by userspace Aug 27 12:08:30 m4t: thinking about it, they need to be random. otherwise two boards booting at the same time might confuse a switch as the same mac is present on two switch ports Aug 27 12:09:06 also - which do you prefer? https://paste.ee/p/zyLTy#Ny0twEK4HoV1LDPA884EsE5sPBvbKhmG Aug 27 12:09:22 everything else is lan,wan but base mac = wan_mac in this case Aug 27 12:10:39 #2 seems kinda silly just to preserve the arbitrary lan,wan ordering which is cosmetic only Aug 27 12:35:13 hrm strange, eth1 retains a random macaddr, but eth0, eth1.1 and br-lan have the right ones Aug 27 12:39:27 mkresin: ^ any thoughts on that? Aug 27 12:55:46 m4t: I'm fine with both ways Aug 27 12:56:14 i'm more worried about eth1's mac not being set Aug 27 12:56:24 m4t: eth1.1 is you logical lan interface, hance it gets the mac address Aug 27 12:56:49 yes i understand that much...still seems less than ideal to not have it properly bound to the base interface Aug 27 12:56:51 m4t: works as expected I would say Aug 27 12:57:43 things were so much simpler using mtd-mac-addres ;( Aug 27 12:58:07 m4t: and so much more wrong, considering the internal structure of the config partition Aug 27 12:58:41 * m4t wonders how ar71xx gets the mac addresses... Aug 27 12:59:00 certainly not via fconfig in userland Aug 27 12:59:13 m4t: wild guess: using a fixed offset on something that isn't that fixed Aug 27 13:00:34 for all intents and purposes i think it is fixed though, which is why it's worked all these years. but don't worry, i've already got it done doing the userspace way. Aug 27 13:02:05 having to rework my commit message again to clarify that fconfig isn't there due to it being useful, but due to it being required now Aug 27 14:30:25 greearb, greearb_: I've tried out the updated ct driver on my R7800 (qca9984), and I get slow speeds on clients connected with 802.11w enabled. I see that the firmware for qca988x has been updated to, presumably, address this issue. Can you take a look at qca9984 as well? Aug 27 14:45:12 man, I am gonna have to ifdef the shit out of this, damn architecture differences Aug 27 14:45:36 u-boot? Aug 27 14:46:52 accel-ppp, mips 24k (at least) doesn't have __sync_add_and_fetch_8 Aug 27 14:47:06 ah Aug 27 14:47:10 mvebu, x86 succeed, ramips, lantiq fails Aug 27 14:47:56 gonna have to rejig all my patches, was bad enough getting it to build with musl Aug 27 14:51:56 I mean I don't actually need it on mips 24k devices, not likely to be fast enough to ever be useful anyway Aug 27 14:52:15 so maybe I should just mark it as suitable architectures anyway Aug 27 14:56:56 perhaps actually its just 32bit that I need to ifdef Aug 27 14:57:42 ooor, libatomic and not fix it Aug 27 14:59:46 isn't libatomic for exactly this? Aug 27 15:00:16 I was under the impression its slower than native accesses Aug 27 15:00:20 as it uses locks Aug 27 15:05:34 huaracheguarache, try one of these? https://www.candelatech.com/downloads/ath10k-9984-10-4b/ath10k-fw-beta/ Aug 27 15:43:15 greearb: I'll give it a shot Aug 27 15:44:29 it is beta, some stuff works, but it certainly has bugs still (AP + STA on same radio is broken). It is my patches rebased on top of a recent upstream QCA firmware. Aug 27 16:21:44 gninrom Aug 27 17:41:41 greearb: I just tried the firmware-5-ct-full-htt-mgt-community.bin beta, but I still get only 20 mbps of upload/download on 802.11w clients Aug 27 17:43:28 bufferbloat is also completely off the carts Aug 27 18:34:22 hi, what is the quick fix for the "/bin/sh: mkhash: not found" on the snapshot sdk's? Aug 27 18:43:19 i get this error all over the place using the snapshot sdk, 18.06.1 works. Aug 27 18:50:06 so getting a list value from UCI in lua returns a table but you cant do a set with a table Aug 27 18:53:25 oh wait Aug 27 19:47:42 ok is there a sane way to grab a list table from a uci, delete some based on their value and then save the remaining list values? Aug 27 19:48:18 so far I need to grab all of them, pop them into a new table, filter the new table, do a set on the result Aug 27 19:50:36 https://git.openwrt.org/ shows errors 502 and 504 Aug 27 20:07:51 server works again. Aug 27 20:37:20 <_lore_> ping nbd Aug 27 23:08:41 the sky is falling Aug 27 23:08:56 the turris omnia people are making pull requests Aug 27 23:27:55 nbd: back? Aug 27 23:51:56 that project is awesome Aug 27 23:52:00 turris omnia **** ENDING LOGGING AT Tue Aug 28 03:00:02 2018