<stintel>
oh, the uploading of logs only happens on failure
<stintel>
anyway, the stuff I added in the PR isn't built
<stintel>
and can't look at the .config used during CI either
<stintel>
not very useful :(
<aparcar[m]>
stintel: what do you expect there? It builds fine, so some green buttons
<aparcar[m]>
do you want to hand down some extra config options?
<dwfreed>
successful build does not necessarily mean correct build
<dwfreed>
which I think is the issue
<dwfreed>
could always have the workflow stash some artifacts
<dwfreed>
like the log and the .config and stuff
<dwfreed>
artifacts have limited lifetimes, and you can control those lifetimes from the workflow
<stintel>
it doesn't build elfutils at all so it doesn't respect the echo ... >> .config
<stintel>
so to debug this the first thing would be to look at the .config I guess, would be handy if this was available as artifact (even if for limited time)
<stintel>
I'm most likely doing something wrong but not being able to check any logs is not great
<stintel>
anyway, I need to sleep, night folks
<aparcar[m]>
stintel: sweet dreams
hanetzer1 is now known as hanetzer
goliath has quit [Quit: SIGSEGV]
[florian] has joined #openwrt-devel
[florian] has quit []
[florian] has joined #openwrt-devel
[florian] has quit []
[florian] has joined #openwrt-devel
[florian] has quit []
[florian] has joined #openwrt-devel
[florian] has quit []
[florian] has joined #openwrt-devel
[florian] has quit []
[florian] has joined #openwrt-devel
[florian] has quit []
[florian] has joined #openwrt-devel
KGB-0 has quit [Ping timeout: 480 seconds]
AtomiclyCursed2 has quit [Quit: ZNC 1.8.2 - https://znc.in]
StifflersMagic has quit [Server closed connection]
StifflersMagic has joined #openwrt-devel
dwmw2 has quit [Server closed connection]
danitool has joined #openwrt-devel
srslypascal is now known as Guest732
srslypascal has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Guest732 has quit [Ping timeout: 480 seconds]
<f00b4r0>
are the various gmac-config / switch-* DT bindings documented somewhere? I'm trying to properly configure the switch in DT for a device with two gmac, one hooked to a single port through switch and the other direct, and when I add switch-phy-swap it does what I want on the switched port but the other interface stops working :P
AndyCap has quit [Server closed connection]
AndyCap has joined #openwrt-devel
dwmw2_gone has joined #openwrt-devel
dwmw2_gone is now known as dwmw2
Tapper has joined #openwrt-devel
enyc has quit [Server closed connection]
zarzarzar has quit [Server closed connection]
zarzarzar has joined #openwrt-devel
Rondom has quit [Server closed connection]
Rondom has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap has quit [Ping timeout: 480 seconds]
dhewg has quit [Server closed connection]
dhewg has joined #openwrt-devel
<Grommish>
Anyone else seeing package/system/gpio-cdev/nu801 fail? I'm not even sure why/how it's trying to build since it's x86_64 only and not selected in my .config
<Grommish>
I don't have Wifi on the device, and its Mips64, so...
<Grommish>
Rebased as of about 2 hours ago for feeds and the main repo
<neggles>
or resize it online once it's flashed - making it bigger just makes it slower to flash ¯\_(ツ)_/¯
<nick[m]1234>
ah okay, basically, setting those setting in the .config in imagebuilder will have same effect?
<neggles>
correct.
<neggles>
and if you're using squashfs+overlay then rootfs_data should automatically be created & fill all available space so it's kind of moot?
<nick[m]1234>
The size of rootsfs was near 1GB before. After the change, it is stucked at around 100M
<nick[m]1234>
then I think something is wrong?
<neggles>
the size of rootfs doesn't matter if rootfs_data is [size of your SD card minus ~150MiB]
<nick[m]1234>
I talk about emmc
<stintel>
it was hardcoded, which is not great since we have a config option around for it for a very long time. this was rectified (use config option instead of hardcoded 980M), and thus the root partition size changed from the hardcoded 980M to the default for the option. so the change is normal, nothing is wrong. the hardcoded 980M was wrong
<kabel>
rsalvaterra: regarding the non-working aardvark in "kernel: mvebu: add Linux 5.15 support", should I send PR into your rsalvaterra:mvebu-515 branch?
<nick[m]1234>
With "wrong" I mean the size is not automatically fit to the available space or?
<stintel>
no, we don't have such mechanism
<rsalvaterra>
kabel: Sure, either that or a patch series to my email. :)
<rsalvaterra>
kabel: Note that I don't have the required hardware for testing, so I can only build-test.
lucenera has joined #openwrt-devel
<stintel>
using a sensible default leaves the rest of the storage available for the user to do what they want with it. auto resizing to fill the available space is less flexible imo
<nick[m]1234>
okay thanks for all your help! :)
<stintel>
e.g. I use 512 boot 512 root on apu2 and keep the rest as an ext4 fs for container storage
<neggles>
wonder why we're not using squashfs for emmc too
<robimarko_>
rsalvaterra: I can test PCI on Espressobin Ultra
Strykar has quit [Quit: /quit]
<stintel>
user can choose normally? squashfs+jffs2-or-f2fs vs ext4?
<neggles>
stintel: yeah but it seems the default SD card image is squashfs+overlay, but the default eMMC image is not
<neggles>
seems kinda backwards to me?
<rsalvaterra>
robimarko_: Great! I still have to run-test on the Omnia too, but that should settle at least mvebu/cortexa9.
<kabel>
robimarko_: the upstream patches are needed, though, so wait until I rebase the patches (I will also send some others that are still pending for review on linux-pci)
<robimarko_>
kabel: Yeah, that is what I meant
<stintel>
neggles: could it just be a naming confusion?
<robimarko_>
As I know its broken currently
<kabel>
rsalvaterra: Pali also worked on some patches for pci-mvebu, and there are some waiting for review as well. I will probably rebase them as well
<kabel>
rsalvaterra: also some DSA patches will need to be backported
valku has joined #openwrt-devel
Strykar has joined #openwrt-devel
<rsalvaterra>
Ok, so the idea will be to replace the existing (and currently broken) patches we have for 5.15, right?
<neggles>
stintel: hm, i am confused, if you look at snapshot emmc doesn't actually contain an image, it's just the bootloader/preloader
<robimarko_>
kabel: The Marvell roaming DSA hack should be also droppable in 5.15
<robimarko_>
Cause, I believe that was sorted upstream in a nice wa
<robimarko_>
*way
<neggles>
ahhh
<neggles>
but 21.02.2 has a squashfs emmc
<neggles>
squashfs emmc image
<neggles>
and no sdcard image at all? perhaps that's down to the different configs between release and snapshot, or some changes in how the emmc image is built
jlsalvador has quit [Quit: jlsalvador]
<neggles>
I guess the idea is you boot from SD or ramboot tftp, then flash the eMMC, which makes sense
hanetzer1 is now known as hanetzer
jlsalvador has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
guidosarducci_ has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<neggles>
rsalvaterra / robimarko_: I have an oc200 I can test builds on (armada 3720/cortexa54) if that's useful, it doesn't have any pci devices though
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tapper has joined #openwrt-devel
* f00b4r0
notices that json_load with an empty input throws an error message even with _json_no_warning set
<kabel>
robimarko_: yes, but we will need to backport some patches
<f00b4r0>
i could use an intermediary variable, but more memory used :P
<kabel>
robimarko_: I will look into this tomorrow
<jow>
wouldn't worry about memory if parsing JSON with shell
<jow>
at least not about memory occpied by one further intermediate variable
<f00b4r0>
strangely enough it seems that when this fails, json_for_each_item still execute once
<f00b4r0>
jow: heh, you probably have a point :)
<robimarko_>
kabel: sounds good to me
<f00b4r0>
jow: incidentally, there seems to have been a change in behavior between 19.07 and 21.02: in 19.07 network.wireless status shows wlan as "down" for the duration of DFS scan; but in 21.02 it's "up" during the scan
<Ansuel>
Hi, the compilation error was just the kernel using a new api and removing extra code
<Ansuel>
my idea is to merge that now to fix the compilation error and work on using correct patch later with more testing
<rsalvaterra>
Ansuel: Hello! :) I had just told kabel about your pull request. Merging it locally…
<kabel>
there are also other patches for aardvark pending that are not yet in openwrt, so I will send also those
<Ansuel>
rsalvaterra: I now i have the readonly irc open on the browser to stalk you guys !!! ahahahha
<robimarko_>
Dont you use my methods
<rsalvaterra>
Ansuel: You should try Quassel… ;)
<Ansuel>
kabel: i wonder if it will be just specific to 5.15 or also 5.10?
<kabel>
yes, the generic_handle_domain_irq() thing :) I actually had to change it to irq_find_mapping() + generic_handle_irq() when backporting, and now we have to change it back for 5.15
<stintel>
ssh + tmux + irssi ftw :P
<stintel>
hipsters
schmars[m] has joined #openwrt-devel
<kabel>
stintel: s/irssi/weechat/
<Ansuel>
rsalvaterra: i should check if a server can be installed on openwrt
<stintel>
tried a few times to migrate my config, too complex, irssi it'll be until the end
<kabel>
Ansuel: I don't remember actually
* rsalvaterra
waits for someone confessing to use mIRC
<rsalvaterra>
Ansuel: Probably a bit heavy… let me see my server's RAM usage…
<rsalvaterra>
About 33 MiB for quasselcore.
<jow>
stintel: what was the mailing list for nftables patches again?
<stintel>
Ansuel: did you see my question to test my BPF PR? since you reported problems with it on the ml
<Ansuel>
i use quassel the wrong way... think it's also bad ahahah
<schmars[m]>
blocktrron: can I dm you about poemgr? i'm the one with the recent pull requests. i have another one coming, regarding the power budget (calculated vs. actual)
<Ansuel>
stintel: totally missed it let me recheck
<stintel>
jow: hmmm, good question, since this was sent with git send-email it's not in my sent folder :P
<jow>
netfilter-devel@vger.kernel.org
<jow>
found your patch online
<stintel>
I was searching for it too, guess you beat me to it
<Ansuel>
stintel: ok i assume i can just test the dwarves tool part
<stintel>
thanks
<stintel>
I might need to fix 5.15 first
<stintel>
ah but that's not relevant for the tools part
<Ansuel>
mhh how to clean a tool compilation with make?
<stintel>
make tools/foo/clean ?
<Ansuel>
worked
Tapper has quit [Ping timeout: 480 seconds]
<Ansuel>
WARNING: Makefile 'package/feeds/packages/frr/Makefile' has a build dependency on 'elfutils/host', which does not exist
<stintel>
Ansuel: you can ignore that, it's impossible to fix in a single PR as frr is in a different repo
<Ansuel>
stintel: can confirm that it does correctly compile now with the elfutils changes and libdw-dev not present in my system
<Ansuel>
yes just alerting you if you missed that
<stintel>
I'm still struggling to find how to depend on CONFIG_USE_ELFUTILS in frr
<stintel>
I pinged the frr maintainer so at least they know about it
<blocktrron>
schmars[m]: if it's a technical topic - just ask in this channel here
<blocktrron>
maybe it is interesting for orthers (at least i enjoy reading from time to time)
<rsalvaterra>
robimarko_, mvebu/cortexa53 is building fine now, with Ansuel's fix. Would you like to give it a spin? :)
<robimarko_>
rsalvaterra: Sure, I just finished with work
<robimarko_>
I will give it a go later in the eveningn
Misanthropos has joined #openwrt-devel
danitool has joined #openwrt-devel
Tapper has joined #openwrt-devel
<schmars[m]>
blocktrron: sure! :) it's about the Unifi Switch Flex, i'm powering it with a 802.3at injector, and downstream there are 4 passive poe devices each with a 802.3af-to-passive converter (i'm trying out this setup mainly because passive-poe outdoor switches are very hard to buy right now). It turned out pretty hard to actually power on all 4 downstream devices, either they report their max power draw (instead of actual draw) during
<schmars[m]>
802.3.af detection/classification, or they simply draw more than 20W combined during startup. the two option i see are: A) work with delays which is doable but will complicate everything, or B) make the power budget configurable. I tried out option B yesterday and it seems fine
<schmars[m]>
i think the worst that could happen with option B is that the actual real power budget is exceeded and devices crash. like in the good old nanostation daisychaining days.
clayface has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
<blocktrron>
schmars[m]: do you have poc code for that?
<schmars[m]>
not quite yet - i just hardcoded `return 51` in poemgr_uswflex_get_power_budget to try it out. i'd make it a `power_budget` config setting if the approach sounds okay. - have to run an errand, i'll be back in ~3h
<ynezz>
rsalvaterra: hi, whats the problem with 5.15.32?
<ynezz>
rsalvaterra: if there is some regression between 5.15.31 and 5.15.32 then just report it and revert it?
<aparcar[m]>
ynezz: did you somehow improve the caching of toolchains? For me it's still rebuilding everything taking about 50 minutes per build just for tools/toolchain
evils[m] has quit [Server closed connection]
evils[m] has joined #openwrt-devel
<ynezz>
aparcar[m]: I'm not sure if I follow, that script I provided to you was working fine for me in 2019
<ynezz>
aparcar[m]: BTW there are new gotchas if you're using CONFIG_BUILDBOT=y
<aparcar[m]>
oh please provide the script again, thank you
<ynezz>
but with hundred of rebuilds it's some money as they bill you every minute
<hanetzer>
ullo. don't suppose any of your magical people happen to have a handle on a datasheet for the cavium octeon iii cn7130? working on upstreaming some code from an ubiquiti gpl drop :P
<aparcar[m]>
ynezz: mhh still not ideal 🙂 I hoped we could use the pre-compiled toolchain and just use it as some sort of SDK like thing.
<ynezz>
aparcar[m]: yes, external toolchain is the way to go probably
<Ansuel>
wonder if tar extract and use external toolchain would be quicker
<aparcar[m]>
anus
<Ansuel>
(but in theory should be the same of using cache)
<aparcar[m]>
Ansuel: oops sorry, I tried the tar thing and it doesn't work
<Ansuel>
ynezz did you tried to cache both toolchain and ccache cache ?
<Ansuel>
bug again why this doesn't work with aching the entire tools and toolchain directory and restoring it across actions ?
<Ansuel>
isn't that the same?
csharper2005 has joined #openwrt-devel
<ynezz>
no, you need build_dir for make stamps
<ynezz>
and using external toolchain should be more reproducible, which is what you want
<ynezz>
what is happening on CI should ideally happen on your local machine
<ynezz>
Re: "we should've massive build speed improvements and can test every kernel change" -> I find it really crazy to build test every push in the PR branch
<Ansuel>
well if it's ""free""
<aparcar[m]>
ynezz: not every, but Kernel bumps keep introducing missing symbols
<ynezz>
aparcar[m]: if you don't test every push/change in the PR branch, then how would you know, that it's OK?
<rsalvaterra>
… and I'm really tempted to just set the divisor to 2048 instead of 1024. Do we expect a 64 MiB device to handle more than 4096 connections?
<jow>
rmilecki: luci-app-firewall depends on virtual uci-firewall which is provided by firewall and firewall4
<jow>
whicher of the two is selected by default is up to buildroot, but I guess it should be firewall4 since it is the default in master nowadays
<jow>
maybe you ported over an old diffconfig and never unset firewall
csharper2005 has joined #openwrt-devel
<rsalvaterra>
aparcar[m]: And I don't see anything resembling the hacky patch in the netdev mailing list, it probably wasn't sent for review.
<jow>
maybe the metadata is corrupted (tried rm -r tmp/ ?)
<rmilecki>
jow: i tried rm -fr tmp
<rmilecki>
jow: i also tried new .config
<jow>
maybe your luci feed is stale
<rmilecki>
jow: "i use the latest OpenWrt master & LuCI repo"
<jow>
wthen I am out of ideas
<jow>
it works on the buildbots, it works for me and I've not seen any similar reports
<rmilecki>
jow: i think i end up with both: firewall & firewall4 selected
<rmilecki>
i'll debug that tomorrow
<jow>
let me know if you find something
<jow>
maybe you have some unrelated package selected that triggers this
<rmilecki>
jow: no, I did "rm .config" and didn't select any package except luci
<rmilecki>
yeah, selecting luci=y results in:
csharper2005 has quit [Read error: Connection reset by peer]
<rmilecki>
CONFIG_PACKAGE_firewall=y
<rmilecki>
CONFIG_PACKAGE_firewall4=y
<jow>
they conflict with each other
<jow>
so not sure how you end up with such a config