**** BEGIN LOGGING AT Sun Jun 07 02:59:56 2020
Jun 07 03:30:40 <owrt-snap-builds> build #144 of bcm63xx/generic is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/144  blamelist: Hans Dedecker <dedeckeh@gmail.com>, Toke H?iland-J?rgensen <toke@toke.dk>
Jun 07 03:32:01 <owrt-snap-builds> build #444 of oxnas/ox820 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/444  blamelist: Stijn Tintel <stijn@linux-ipv6.be>, Hans Dedecker <dedeckeh@gmail.com>, Toke H?iland-J?rgensen <toke@toke.dk>
Jun 07 03:33:21 <owrt-snap-builds> build #439 of lantiq/ase is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/439  blamelist: Stijn Tintel <stijn@linux-ipv6.be>, Hans Dedecker <dedeckeh@gmail.com>, Toke H?iland-J?rgensen <toke@toke.dk>
Jun 07 03:34:36 <owrt-snap-builds> build #439 of at91/sam9x is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/439  blamelist: Stijn Tintel <stijn@linux-ipv6.be>, Hans Dedecker <dedeckeh@gmail.com>, Toke H?iland-J?rgensen <toke@toke.dk>
Jun 07 03:34:44 <stintel> config.guess: cannot create a temporary directory in /tmp
Jun 07 03:35:55 <owrt-snap-builds> build #437 of ipq806x/generic is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/437  blamelist: Stijn Tintel <stijn@linux-ipv6.be>, Hans Dedecker <dedeckeh@gmail.com>, Toke H?iland-J?rgensen <toke@toke.dk>
Jun 07 03:37:18 <owrt-snap-builds> build #429 of arc770/generic is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/429  blamelist: Stijn Tintel <stijn@linux-ipv6.be>, Hans Dedecker <dedeckeh@gmail.com>, Toke H?iland-J?rgensen <toke@toke.dk>
Jun 07 04:02:14 <stintel> noltari: please don't make several unrelated changes in a single commit (https://git.openwrt.org/77e97abf) - the switch from kmod-random-bcm2835 to built-in should have gone in a different commit, with an explanation on why it has been done. and ideally the enabling of BCM2711_THERMAL would have been in its own commit as well
Jun 07 04:16:02 <stintel> and indeed. master HEAD has semi-broken UART on RPi0W at least
Jun 07 05:43:11 <stintel> looks like bisecting failed. but somewhere during bisect I came at a commit where kernel build failed, due to cec.ko missing. to work around this I disabled kmod-drm-vc4
Jun 07 05:43:26 <stintel> I suspect it is a problem in the new firmware that only triggers when the vc4 module is loaded
Jun 07 05:58:38 <stintel> interesting. apparently caused by something in /boot/config.txt instead
Jun 07 06:09:50 <noltari> stintel: It’s impossible to separate BCM2711_THERMAL into its own commit when RPi foundation basically removed support for BCMSTB_THERMAL...
Jun 07 06:10:36 <noltari> also, I don’t have any rpi0w, so I can’t perform any tests on that device...
Jun 07 06:10:57 <stintel> noltari: it seems I had /boot/config.txt without include distroconfig.txt
Jun 07 06:11:13 <stintel> noltari: just now figured it was the disable-bt overlay that was missing that was causing the problem
Jun 07 06:11:20 <stintel> weird that this was not an issue on the old firmware thoughj
Jun 07 06:11:33 <stintel> noltari: https://github.com/raspberrypi/firmware/issues/1376
Jun 07 06:11:46 <stintel> there are other issues with the new firmware as well
Jun 07 06:11:53 <stintel> I suggest we revert for now
Jun 07 06:14:06 <stintel> I fail to see how bluetooth (which should be on UART0) can interfere with the mini UART (UART1)
Jun 07 06:17:35 <stintel> looks like not disabling bluetooth also messes with the core clock on the new firmware
Jun 07 06:17:57 <stintel> I now have bluetooth enabled and core_freq=250 and the UART corruption isn't there
Jun 07 06:27:40 <noltari> stintel: I think that the problem of having uart on that device is that the core frequency has to be fixed to an stable value for the uart to work, because the uart clock is somehow linked to the core frequency
Jun 07 06:37:19 <stintel> noltari: during bisecting I even had a sysupgrade failure. it's safe to say this new firmware is not ready for use. can I get an ACK https://git.openwrt.org/d8242547 ?
Jun 07 06:38:50 <stintel> another downstream user has also reverted https://github.com/pftf/RPi3/commit/9300e281023d00d4bb286aeeee1e5a04a8be67ef
Jun 07 07:22:04 <stintel> noltari: how I understand it, this new firmware will need changes in the linux kernel to read the current core clock via mailbox and use that to determine the proper divider for other clocks. so we should revert until those patches arrive
Jun 07 07:23:02 <stintel> I have a revert and then a bump to the last version before the switch to building from the common firmware branch: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=summary
Jun 07 07:23:29 <stintel> and I have just verified that (tested both the commit in the bump and the next one)
Jun 07 07:23:53 <noltari> stintel: ok, then I’m happy to revert it
Jun 07 07:24:24 <noltari> BTW, sorry for not testing that... sometimes is a bit difficult to test everything related to rpi
Jun 07 07:24:38 <stintel> noltari: no worries
Jun 07 07:24:43 <noltari> there are so many devices and configs...
Jun 07 07:24:52 <stintel> FYI also wrote my findings: https://github.com/raspberrypi/firmware/issues/1376#issuecomment-640170167
Jun 07 07:25:10 <stintel> noltari: can I add your ack on those 2 commits ?
Jun 07 07:25:21 <noltari> sure, go ahead
Jun 07 07:25:25 <stintel> alright, thanks
Jun 07 07:28:06 <stintel> it's interesting how I keep running into these problems. guess I just have too much hardware in too many different setups :P
Jun 07 07:28:33 <stintel> this one was particularly annoying as I now have a 24h gap in my power metering
Jun 07 07:29:17 <stintel> I guess I'll have to set up some logfile monitoring on my home-assistant log so that I can detect modbus communication problems this way
Jun 07 07:31:29 <stintel> grafana shows 3kWh for yesterday. with an average over the last 30d of 28 that seems unlikely :P
Jun 07 07:32:49 <stintel> gonna do a final build, flash it on all 5 of my Zero W's and then push
Jun 07 07:45:07 <stintel> noltari: question, is there a reason for disabling BT in distroconfig.txt ?
Jun 07 08:09:53 <noltari> stintel: to avoid using miniuart, which needs a fixed core freq
Jun 07 08:10:51 <noltari> Also, bluetooth is not supported
Jun 07 08:15:25 <stintel> noltari: ok. you're not planning to add BT support?
Jun 07 08:15:57 <stintel> I've been wanting to do so at some point but then I got a few ESP32 boards with BLE and I'm using those for what I wanted to use one of my Pi's
Jun 07 08:57:53 <f00b4r0> russell--: distinction that comes from previous conversation with precurse : "binary" (raw) vs "elf". append-dtb doesn't work with elf kernels.
Jun 07 09:04:05 <dwmw2_gone> Wheee.
Jun 07 09:04:09 <dwmw2_gone> finally worked out the network gremlins.
Jun 07 09:04:15 <dwmw2_gone> It's the switch in the RT-AC85P.
Jun 07 09:04:23 <dwmw2_gone> plugged a USB Ethernet in, and it works fine.
Jun 07 09:19:10 <russell--> wires++
Jun 07 09:19:54 <russell--> f00b4r0: thanks for the explanation, makes sense
Jun 07 09:33:03 <dwmw2_gone> https://bugs.openwrt.org/index.php?do=details&task_id=3155
Jun 07 09:48:01 <stintel> meh, sysupgrade on my Unifi AP AC Pro does nothing, just boots with the old image
Jun 07 09:49:31 <dwmw2_gone> stintel: did you switch over to openhab?
Jun 07 09:49:41 <stintel> dwmw2_gone: home-assistant
Jun 07 09:50:44 <stintel> I had been running the 2 next to each other for a while, z-wave on domoticz and zigbee on home-assistant, using mqtt to control devices on domoticz via home-assistant as well
Jun 07 09:58:49 <stintel> and I'm running home-assistant the lazy way (docker)
Jun 07 09:59:07 <dwmw2_gone> but it doesn't have evohome support, does it? I'd have to do some work to switch.
Jun 07 09:59:13 <russell--> dwmw2_gone: is there anything unusual about your /etc/config/network?
Jun 07 09:59:17 <dwmw2_gone> I assume you'd recommend it over Domoticz? Any particular reason?
Jun 07 09:59:24 <dwmw2_gone> russell--: on the RT-AC85P?
Jun 07 09:59:28 <russell--> yeah
Jun 07 09:59:51 <stintel> dwmw2_gone: actually I preferred domoticz because it's so tiny. when I made the package I tested it on an rspro with 16MB flash
Jun 07 09:59:59 <dwmw2_gone> root@garden:/etc/config# scp network dwmw2@casper.infradead.org:public_html
Jun 07 10:00:04 <dwmw2_gone>  /usr/bin/dbclient: Connection to dwmw2@casper.infradead.org:22 exited: Bad buf_getbyte
Jun 07 10:00:06 * dwmw2_gone frowns
Jun 07 10:00:09 <stintel> dwmw2_gone: home-assistant or openhab are ridiculously huge
Jun 07 10:01:06 <dwmw2_gone> russell--: nothing particularly special. http://david.woodhou.se/rt-ac85p.network.txt
Jun 07 10:01:34 <dwmw2_gone> stintel: why switch then?
Jun 07 10:02:34 <russell--> it's using DSA, i gather
Jun 07 10:02:58 <owrt-snap-builds> build #145 of bcm63xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/145
Jun 07 10:03:07 <stintel> dwmw2_gone: I think I got fed with some weird issues (zwave devices suddenly disappearing etc)
Jun 07 10:03:31 <stintel> plus the development is weird, pain in the ass to maintain
Jun 07 10:04:33 <stintel> home-assistant supports so much more. ok it has its own annoyances, but I was running it anyway and moving what I had to domoticz seemed hard not to say impossible
Jun 07 10:04:48 <stintel> one of the reasons is also how it integrates with esphome
Jun 07 10:05:08 <stintel> and I have a couple of ESPs running esphome
Jun 07 10:06:07 <dwmw2_gone> gizmocuz can be a bit weird.
Jun 07 10:06:45 <stintel> so since I was running home-assistant anyway, and I could very easily move the z-wave devices from domoticz to home-assistant I decided to ditch domoticz
Jun 07 10:06:50 <dwmw2_gone> He's been whining about my fixing the include paths for stuff discovered using pkg-config, where he was using the wrong include paths (e.g. openzwave/Manager.h, minizip/unzip.h) and just relying on the fact that they're in those directories
Jun 07 10:08:27 <dwmw2_gone> I made the openwrt package live in /usr/include/minizip so I don't have to get him to take that fix.
Jun 07 10:08:51 <dwmw2_gone> I think that PR is ready to go now. I've fixed the copyright statements (not that those files are mostly written by me, but OK).
Jun 07 10:08:59 <dwmw2_gone> Do I need to make a formal request to have commit access?
Jun 07 10:09:21 <stintel> dwmw2_gone: actually I don't know how it works for the packages feed
Jun 07 10:09:48 <stintel> you also don't need to get it, many package maintainers just submit PRs
Jun 07 10:09:51 <dwmw2_gone> I suppose I should tidy up these banana pi r2 patches lying around in my tree and submit them too :)
Jun 07 10:10:17 <stintel> also commit access to openwrt and feeds are 2 different things
Jun 07 10:24:15 <stintel> [    0.000000] Failed to get CPU node
Jun 07 10:24:38 <stintel> yay
Jun 07 10:27:04 <stintel> ah, [    0.000000] OF: fdt: No valid device tree found, continuing without
Jun 07 10:27:10 <stintel> how does that work with an initramfs
Jun 07 10:33:56 <stintel> kernel-bin | patch-cmdline | relocate-kernel | lzma ... where do I add the append-dtb
Jun 07 10:34:38 <f00b4r0> stintel: probably replace patch-cmdline with append-dtb, and fix the commandline in dtb?
Jun 07 10:35:03 <f00b4r0> dts*
Jun 07 10:36:23 <stintel> f00b4r0: let me try that
Jun 07 10:36:50 <stintel> I basically copied what is done in ar71xx
Jun 07 10:36:59 <stintel> so there might be some stuff that is not needed
Jun 07 10:37:54 <f00b4r0> ath79 has CONFIG_MIPS_CMDLINE_FROM_DTB=y
Jun 07 10:38:06 <stintel> and I barely remember anything from when I added support for this device (DAP2695)
Jun 07 10:38:26 <stintel> [    0.000000] MIPS: machine is D-link DAP-2695-A1
Jun 07 10:38:32 <stintel> progress!
Jun 07 10:38:59 <f00b4r0> heh :)
Jun 07 10:42:27 <stintel> does anyone have a clue what "mac06_exchange_dis = true" translates to in DTS? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-dap-2695-a1.c;h=2577dbffae03a3ce07effd636ad2a53dadc9b5f9;hb=HEAD#l92
Jun 07 10:59:43 <plntyk> stintel, delete that its not needed anymore it seems
Jun 07 10:59:56 <plntyk> git show 814d70b2fda
Jun 07 11:02:44 <stintel> plntyk: I think you're misunderstanding. look at the commit again. it swapped the default behaviour. I'm 100% sure it is needed for the DAP-2695
Jun 07 11:02:58 <stintel> but this is ar71xx / mach file syntax
Jun 07 11:03:48 <plntyk> ah ok i see now
Jun 07 11:15:35 <plntyk> stintel, I see on some Netgear WNDR devices with 8327 switches that dtsi files have basically magic numbers in them for "mdio" node switch setup (?) - not that nice
Jun 07 11:17:47 <plntyk> is it a PORT6_STATUS there at initvals?
Jun 07 11:35:42 <stintel> I honestly have no clue what all that stuff means
Jun 07 11:36:05 <stintel> and trying to find useful info in a 1000 post forum thread ... not very great
Jun 07 12:09:20 <mirko> mangix: the new 5.15  LTS release, yes
Jun 07 12:09:24 <mirko> before it was 5.9
Jun 07 12:31:48 <stintel> yay, starting to get somewhere
Jun 07 13:08:09 <xdarklight> Hauke: that was fast, thanks :-)
Jun 07 13:12:23 <Hauke> xdarklight: I am anyway working on mails
Jun 07 13:12:39 <Hauke> are you trining to switch to the DSA driver?
Jun 07 13:12:47 <Hauke> *trying
Jun 07 13:13:05 <xdarklight> Hauke: on my HH5A LAN 1, 2 and 4 are already working ;-)
Jun 07 13:13:16 <xdarklight> need to figure out why I have 100% packet loss on LAN 3
Jun 07 13:13:30 <Hauke> I have the device tree for the HH5A with all LAN ports working
Jun 07 13:14:03 <xdarklight> for a recent-ish kernel or v4.17 from your git.openwrt.org tree?
Jun 07 13:14:21 <Hauke> 5.1
Jun 07 13:14:24 <Hauke> I think
Jun 07 13:14:47 <Hauke> I used the HH5A to develop the driver
Jun 07 13:15:20 <xdarklight> it'd be awesome if you could find it :)
Jun 07 13:16:12 <xdarklight> https://github.com/xdarklight/openwrt/commit/174f3a7b4d7135491292762b075fbd136e3a9a79 - here's my working draft if you're interested
Jun 07 13:16:38 <Hauke> xdarklight: https://pastebin.com/J1JXCRUM
Jun 07 13:19:10 <xdarklight> Hauke: hmm, I see no difference. let me double-check if it's working with the old driver
Jun 07 13:19:35 <Hauke> I think the driver did not change
Jun 07 13:19:45 <xdarklight> old driver == out of tree one
Jun 07 13:20:38 <Hauke> ah ok, I didn't care if it will work with the swconfig driver
Jun 07 13:20:45 <xdarklight> OK, suspicious: lan3 is also not working in u-boot for me (this is on my testing HH5A), maybe it's broken hardware
Jun 07 13:23:37 <xdarklight> power cycling the device fixed it
Jun 07 13:23:42 <xdarklight> not sure what went wrong there
Jun 07 13:24:58 <Hauke> strange
Jun 07 13:39:16 <xdarklight> I created a pull request here: https://github.com/openwrt/openwrt/pull/3085 - I'll test it on my TD-W8970 and VGV7510KW22 later
Jun 07 13:41:37 <Hauke> xdarklight: is any vr9 devices using the internal GPHY in fast ethernet mode?
Jun 07 13:41:55 <Hauke> instead of one 1GBit/s phy as 2 100 MBIt/s Phys?
Jun 07 13:54:26 <xdarklight> Hauke: yes, the VGV7510KW22 uses 4x internal PHYs at 100Mbit/s speed plus one external IC-Plus IP101 MII PHY (for the WAN port)
Jun 07 13:57:07 <Hauke> ok
Jun 07 14:14:57 <xdarklight> is this something you couldn't test yet or is there another reason why you're asking (just so that I'm prepared of whatever lies ahead ;))?
Jun 07 14:15:28 <Hauke> I do not have a device which uses the GPHY as Fast Ethernet PHYs
Jun 07 14:15:33 <Hauke> so this is untested
Jun 07 14:15:56 <xdarklight> OK
Jun 07 14:29:34 <xdarklight> Hauke: someone else reported in my PR that Ethernet TX breaks for him after 20-30 minutes. for me TX is broken once I try send data using iperf3 from the HH5A to my computer
Jun 07 14:29:46 <xdarklight> (meaning it doesn't even take 30 minutes to reproduce)
Jun 07 14:30:27 <Hauke> it just breaks after some time, so you do not change any configuration?
Jun 07 14:31:10 <xdarklight> yep
Jun 07 14:31:47 <Hauke> could you try it without the DSL driver please
Jun 07 14:32:00 <xdarklight> my steps are: 1) bring up the board 2) change it's IP (because I forgot do update it in my .config) 3) /etc/init.d/network restart 4) start iperf3 -c server-ip => broken
Jun 07 14:32:20 <Hauke> the ppe engine is controled by the ptm driver and also in the datapath
Jun 07 14:33:17 <Hauke> is RX still working?
Jun 07 14:33:19 <xdarklight> without DSL driver meaning rmmod should be enough or drop it from the image?
Jun 07 14:33:30 <Hauke> I would prefer to frop from the image
Jun 07 14:33:37 <Hauke> I am not sure if rmmod fully works
Jun 07 14:33:45 <xdarklight> OK
Jun 07 14:33:51 <xdarklight> as for RX: interrupt count is still rising at least
Jun 07 14:34:19 <Hauke> for tx could you check the counters on the interfaecs with ethtool -S
Jun 07 14:34:39 <Hauke> there are counters on each LAN port and on the CPU port
Jun 07 14:35:47 <adrianschmutzler> Talking about lantiq, does anyone know what that file is for:
Jun 07 14:35:51 <adrianschmutzler> https://github.com/openwrt/openwrt/blob/master/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
Jun 07 14:36:06 <adrianschmutzler> I didn't find any reference with grep
Jun 07 14:36:31 <adrianschmutzler> And the shebang doesn't look like it belongs into /lib/functions
Jun 07 14:37:02 <Hauke> adrianschmutzler: did you check luci, could be that luci shows some better DSL stats
Jun 07 14:37:34 <xdarklight> adrianschmutzler: it's used for example here: https://github.com/openwrt/openwrt/blob/d1072096f49823eb39357f9555d7854a9c91bcfb/package/network/config/ltq-vdsl-app/files/dsl_control
Jun 07 14:37:54 <adrianschmutzler> ah, I just checked target directory
Jun 07 14:38:21 <adrianschmutzler> and it's not in the package because it's needed in ltq-adsl-app as well
Jun 07 14:39:34 <adrianschmutzler> okay, doesn't look like I should touch it
Jun 07 14:39:56 <adrianschmutzler> just became aware due to the strange shebang '#!/bin/sh /etc/rc.common'
Jun 07 14:42:40 <xdarklight> Hauke: Rx64BytePkts counter in ethtool is rising (on the lan1 interface, which is the port that's connected to my other switch). none of the Tx counters are rising though. will check without the DSL driver now
Jun 07 14:50:15 <Hauke> xdarklight: the counters on the eth0 interface would also be intresting
Jun 07 14:52:29 <xdarklight> Hauke: OK, one by one: even without the DSL drivers TX dies
Jun 07 14:52:52 <xdarklight> eth0 counters are all 0 for me
Jun 07 14:52:55 <Hauke> but it worked for a short time?
Jun 07 14:53:10 <Hauke> could be that the counters do not work on the CPU port
Jun 07 14:53:39 <xdarklight> yes, it works for a very short time, see: https://pastebin.com/tpENXMtm
Jun 07 14:53:50 <xdarklight> .55 is the HH5A
Jun 07 14:54:08 <Hauke> could you try a different port
Jun 07 14:54:52 <xdarklight> sure, I'll move the cable from lan1 (GPHY in GE mode) to lan4 (external RMII PHY)
Jun 07 14:54:59 <xdarklight> sorry, external RGMII PHY
Jun 07 14:57:24 <xdarklight> just moving the Ethernet cable from lan1 to lan4 doesn't "solve" the connection issue and also /etc/init.d/network restart does not get it going again
Jun 07 14:59:24 <xdarklight> after a reboot lan4 shows the same behavior as lan1: it works for a very short period then TX stops
Jun 07 15:01:16 <Hauke> do you see the CPU port on the switch?
Jun 07 15:01:25 <Hauke> the switch should hav counters also on the CPU port
Jun 07 15:02:42 <Hauke> I would like to know where the packets are getting lost
Jun 07 15:02:51 <xdarklight> the only interfaces I see are eth0, lan1-4 and wan, but no "cpu" interface
Jun 07 15:02:58 <Hauke> hmm ok
Jun 07 15:07:06 <xdarklight> all my changes (except the hack to remove the DSL drivers) are pushed to the PR on github in case you want to try it yourself
Jun 07 15:07:52 <Hauke> ok
Jun 07 15:16:28 <stintel> hmmmz. my mtd binary doesn't seem to support the fixwrgg command and I fail to see how to build it so that it does
Jun 07 15:21:40 <stintel> ahh
Jun 07 15:40:48 <stintel> pfft and now the /etc/hotplug.d/firmware/11-ath10k-caldata isn't called
Jun 07 15:41:10 <stintel> it's not called at all, added a logger line right after the shebang and it doesn't show up
Jun 07 16:25:58 <sbruzolo> Hello
Jun 07 16:27:22 <sbruzolo> I have a chinese device which has Breed (instead of U-Boot) and the OEM firmware is already based on OpenWrt. I am connected to the serial console via soldering and managed to flash an image for the same soc (ar9344) and which has the same partition layout as the original firmware (thats' probably why it works).
Jun 07 16:28:18 <sbruzolo> My problem is, the board has two ethernet ports, but only one at a time seems to be working. Whether i connect to the first or the second one, the link always show up as eth0. If i connect to both only the first will works and the second won't even show up in dmesg
Jun 07 16:28:29 <ldir> stintel: hotplug scripts are sourced so the shebang is pointless/ignored anyway
Jun 07 16:29:10 <sbruzolo> I'm willing to look into to proble, but i do not know eher to look at. Might it be related to this error?  [    1.626698] ag71xx ag71xx.0: no PHY found with phy_mask=00000001
Jun 07 16:29:50 <sbruzolo> (here's the relevant thread https://forum.openwrt.org/t/alternative-firmware-for-zbt-apg621/37099/11 )
Jun 07 17:21:23 <blogic> sbruzolo: complete bootlog please on pastebin.com
Jun 07 18:01:16 <owrt-snap-builds> build #440 of lantiq/ase is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/440
Jun 07 18:01:51 <owrt-snap-builds> build #445 of oxnas/ox820 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/445
Jun 07 18:50:18 <owrt-snap-builds> build #438 of ipq806x/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/438
Jun 07 18:50:29 <owrt-snap-builds> build #430 of arc770/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/430
Jun 07 18:55:41 <owrt-snap-builds> build #440 of at91/sam9x is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/440
Jun 07 18:59:57 <blogic> adrianschmutzler: fixed
Jun 07 19:11:08 <sbruzolo> blogic: https://nopaste.linux-dev.org/?1319103
Jun 07 19:11:11 <sbruzolo> here si dmesg output
Jun 07 19:15:02 <sbruzolo> i mean I have eth0, br-lan, eth0.1 and eth0.2
Jun 07 19:45:43 <nick[m]> who is responsible for olsrd daemon?
Jun 07 19:47:29 <nick[m]> I think there is weird stuff happening, like if (!isNaN(gpsdata->fix.time)) where #define isNaN(x) (x != x) and fix.time is a timespec_t {aka struct timespec}
Jun 07 19:53:23 <PaulFertser> sbruzolo: and "swconfig dev switch0 show" please
Jun 07 19:56:37 <PaulFertser> sbruzolo: one with the first port connected, another with both ports connected.
Jun 07 19:58:27 <sbruzolo> https://nopaste.linux-dev.org/?1319124
Jun 07 19:59:07 <sbruzolo> PaulFertser: this is with both ports connected and indeed they are shown, one is 1000tx and the second one is 100tx probably because it's a very old cable
Jun 07 19:59:27 <PaulFertser> sbruzolo: the 1000 is the CPU port most likely, your eth0
Jun 07 20:00:14 <PaulFertser> sbruzolo: your vlan2 isn't suitable then, it mentions a port that you do not physically have.
Jun 07 20:00:34 <PaulFertser> And vlan0 is just useless
Jun 07 20:00:47 <PaulFertser> sbruzolo: is one port supposed to be wan and another lan?
Jun 07 20:01:05 <sbruzolo> here is with only one the interface connected https://nopaste.linux-dev.org/?1319124
Jun 07 20:01:18 <sbruzolo> PaulFertser: yes one is marked as wan/lan and the second one is marked as lan
Jun 07 20:01:42 <PaulFertser> sbruzolo: and what's your current patch adding to network uci defaults script?
Jun 07 20:01:42 <hbug> does anybody know why the 5th switch port on the fritzbox 4040 doesn't show up in the luci interface. configuring it in luci breaks the wan port.
Jun 07 20:02:00 <sbruzolo> ops https://nopaste.linux-dev.org/?1319125 this is the correct link for the second one
Jun 07 20:02:15 <PaulFertser> sbruzolo: just the lan connected?
Jun 07 20:02:19 <sbruzolo> yes
Jun 07 20:02:48 <sbruzolo> PaulFertser: i haven't modified anything yet, so i do not have a patch
Jun 07 20:02:50 <PaulFertser> sbruzolo: ok, so now you know that port 0 is cpu, port 4 is lan and port 5 is wan.
Jun 07 20:02:59 <PaulFertser> sbruzolo: ok, pastebin your /etc/config/network then
Jun 07 20:03:26 <sbruzolo> Mhh but dmesg shows than my lan connection is 1000tx
Jun 07 20:03:34 <PaulFertser> sbruzolo: cpu to switch
Jun 07 20:04:31 <sbruzolo> Is there a way to know the port speed? I'm curious to know if they are 10/100/1000 or just 10/100
Jun 07 20:05:15 <PaulFertser> sbruzolo: you can check the switch datasheet. But it's most likely that all ports are gigabit capable I'd say.
Jun 07 20:05:58 <sbruzolo> This is /etc/network/config https://nopaste.linux-dev.org/?1319126
Jun 07 20:06:06 <sbruzolo> */etc/config/network
Jun 07 20:06:48 <sbruzolo> (this is the device by the way https://zbt.en.alibaba.com/product/60808681088-806891568/5_8_Ghz_Cpe_Antenna_Wifi_Openwrt_Wireless_Bridge_Apg621.html , i'm looking for cheap replacements for ubiquiti devices to run libremesh)
Jun 07 20:08:00 <PaulFertser> sbruzolo: 1. remove eth1 line 12; 2. remove lines 41-49; 3. remove 5 from line, add it to line 39. Save. /etc/init.d/network restart
Jun 07 20:14:50 <sbruzolo> PaulFertser: Here is the edited network file https://nopaste.linux-dev.org/?1319131
Jun 07 20:15:18 <PaulFertser> sbruzolo: remove 5 from line 34
Jun 07 20:15:42 <sbruzolo> But ptobably a big part of the problem is the fact that I do not understand how inrterfaces do work in OpenWrt, compared to a traditional debian or freebsd
Jun 07 20:16:17 <PaulFertser> sbruzolo: I think you're a bit confused because this device has just one ethernet interface. And a managed ethernet switch directly attached to it.
Jun 07 20:17:04 <sbruzolo> I now see it has got an IP on eth0.2 from the secondary interface so i guess it works
Jun 07 20:18:24 <sbruzolo> PaulFertser: although I have to get used to it, it does makes more sense now, thank you! You're always of great help
Jun 07 20:18:40 <PaulFertser> sbruzolo: welcome :)
Jun 07 20:25:53 <sbruzolo> So PaulFertser, when making a pull request to the official openwrt repo in order to add a board, apart from the dts and the led/gpio configuration
Jun 07 20:26:18 <sbruzolo> There are other files that need to be pushed? I mean i think there's a OpenWrt default on how a device should operate out of the box?
Jun 07 20:28:02 <aparcar[m]> adrianschmutzler hey what do you think about the unique profile names? Could that become a thing?
Jun 07 20:31:13 <PaulFertser> sbruzolo: you need to do something like https://git.openwrt.org/6c3c4436ee1af0742de7c29bd9c4f10990ed2019 but use the latest version of the DTS file that you use as a template.
Jun 07 20:31:58 <PaulFertser> sbruzolo: the usual policy is to check how vendor firmware assigns MACs to the ethernet ports and to use the same in OpenWrt.
Jun 07 20:35:31 <sbruzolo> PaulFertser: thank you again
Jun 07 20:35:58 <PaulFertser> sbruzolo: btw, I see you're running ar71xx image, and support is to be added to ath79 of course.
Jun 07 20:40:45 <sbruzolo> The boards that are in the ar71xx target but are not being built for OpenWrt version 19 are so because nobody ported them to the new target? I mean, i used the DB120 image because other paople reported that it worked but couldnt find the latest release
Jun 07 20:44:42 <PaulFertser> sbruzolo: yes, just nobody was interested to port.
Jun 07 20:46:17 <sbruzolo> Understood
Jun 07 20:46:20 <sbruzolo> good night!
Jun 07 21:08:44 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Jun 07 21:32:09 <karlp> adrianschmutzler: dropping the shebang lines, is that to save flash space?
Jun 07 21:32:29 <karlp> I know it's "useless", but it helps IDEs autolint and recognise file types.
Jun 07 21:41:12 <adrianschmutzler> aparcar: karlp: sorry, don't have time right now.
Jun 07 21:43:42 <adrianschmutzler> karlp: don't think it will have much effect on flash space, it's basically to have it tidy/proper. part of the existing files won't have them anyway, and having it inconsistent won't help much I think. but if three people say it's nonsense, I will drop the patch and nothing bad will happen
Jun 07 23:03:32 <aparcar[m]> Is it possible to attach a dtb file to a x86 kernel?
Jun 07 23:04:53 <mangix> mirko: i don't see qt anywhere
Jun 07 23:08:14 <txt-file> linux 5.4.43 is working fine on my wndr3800 :-)
Jun 07 23:12:28 <mirko> mangix: it's in the video feed
Jun 07 23:12:38 <mirko> funny enough, i *just* pushed v5.15: https://github.com/openwrt/video
Jun 07 23:17:11 <mangix> interesting...i was not aware of this feed
Jun 07 23:17:35 <mangix> ah, disabled by default
Jun 07 23:18:30 <mirko> mangix: yes, i put into feeds.conf.default quite a while ago, to raise some awareness of its existence - didn't work too well apparently :)
Jun 07 23:28:34 <mirko> my personal iconv rant in a nut^Wpatch: https://github.com/openwrt/video/blob/master/frameworks/qt5base/patches/000-fix-gnuiconv-test.patch
Jun 07 23:32:13 <mangix> mirko: i believe freebsd uses char*
Jun 07 23:33:32 <mangix> musl uses const char*
Jun 07 23:33:36 <mangix> it's a mess
Jun 07 23:35:49 <mirko> it already is, but GNU iconv really tops it all
Jun 07 23:36:33 <mirko> GNU libtool: "I'll make you - users, developers, package maintainers, cross-compile folks and whoever else ever crossed my path - suffer, like no one else ever did and no one else will ever do!"
Jun 07 23:36:37 <mirko> GNU iconv: "HOLD! MY! BEER!"
Jun 07 23:39:03 <mirko> mangix: i just checked: musl seems to use `char **`, which also makes more sense to me
Jun 07 23:39:30 <mirko> sense, as in, POSIX compliant
Jun 07 23:41:13 <stintel> mirko: oh neat (qt 5.15)
Jun 07 23:41:38 <stintel> I might give one of my projects another try then (raspi with touchscreen without X)
Jun 07 23:42:21 <stintel> looks like I'm almost done porting the DAP-2695 to ath79
Jun 07 23:43:07 <stintel> a bit annoying that I cannot grab the MAC addresses directly from the flash in the DTS :(
Jun 07 23:43:17 <stintel> they're stored in ASCII
Jun 07 23:59:26 <stintel> ynezz: are you still working on making this possible (get MAC address from NVMEM in DTS?)
Jun 08 00:01:39 <stintel> oh I have an idea
Jun 08 00:17:09 <mirko> stintel: i hate the raspbi SBCs but happy to help once you run into issues
Jun 08 00:17:57 <mirko> note, it's software rendering only for now - however the software rasterizer is quite good. was able to drop proprietary GL blobs in favour os SW only and QtQuick2 GUI is still smooth.
Jun 08 00:22:37 <stintel> mirko: I had a working PoC at some point already
Jun 08 00:22:55 <stintel> just never figured out the touchscreen calibration
Jun 08 00:23:59 <stintel> meh. how do I "patch" ath9k's MAC address if none of the OEM MAC addresses are properly stored in MTD :/ (only in ASCII)
Jun 08 00:24:33 <stintel> I though I could get it from the ath10k caldata but forgot that this is patched in by hotplug
Jun 08 00:28:45 <pkgadd> stintel: nbg6817 is one such device (ea8500 afaik as well)
Jun 08 00:30:07 <pkgadd> both store the MAC in u-boot environment
Jun 08 01:07:11 <stintel> pkgadd: I've binwalk'd the entire mtd dump, nowhere to be found
Jun 08 01:11:41 <pkgadd> stintel: root@nbg6817:~# fw_printenv ethaddr  -->  ethaddr=60:31:97:XX:XX:XX  then mangled first by https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/base-files/etc/board.d/02_network;h=a3aa0fce7071f6b9ce14f457d922b67080b88eb6;hb=HEAD#l51 and finally using
Jun 08 01:11:46 <pkgadd> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata;h=bb505d642fee300f5c1cab40df9919d7a453345c;hb=HEAD#l38
Jun 08 01:14:21 <stintel> pkgadd: I can get the MAC address with mtd_get_mac_ascii in board.d/02_network and hotplug.d/firmware/11-ath10k-caldata
Jun 08 01:14:37 <stintel> pkgadd: the problem is that does not work for the 2.4GHz radio of the SoC
Jun 08 01:16:33 <stintel> and there is no firmware for the ath9k radio so I also cannot use /etc/hotplug.d/firmware/10-ath9k-eeprom
Jun 08 01:20:23 <stintel> I also really dislike the "config device 'lan_eth0_dev'\noption name 'eth0'\noption macaddr '9c:d6:43:...'"
Jun 08 01:20:31 <stintel> kind of clutters the /etc/config/network file
Jun 08 01:22:02 <stintel> I think this is more elegant: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/nand/base-files/lib/preinit/10_fix_eth_mac.sh;h=fdd8381f562b210d46f727b06d68bcb81bf4c050;hb=refs/heads/master
Jun 08 01:25:37 <pkgadd> hmm, neat idea as well
Jun 08 01:28:35 <pkgadd> wouldn't this work for ath9k as well https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/lantiq/xrx200/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom;h=75cc50a207b77dbb2e1a5dfb10662a6babd79b33;hb=refs/heads/master#l26 ?
Jun 08 01:30:46 <stintel> pkgadd: there is no firmware file. all these scripts would exit after the [ -e /lib/firmware/$FIRMWARE ] && exit 0
**** ENDING LOGGING AT Mon Jun 08 02:59:58 2020