LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<owrt-1907-builds> build #229 of apm821xx/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/apm821xx%2Fnand/builds/229
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
Grommish has quit [Read error: Connection reset by peer]
LoopHoldYoaBrown has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
black_ant has quit [Ping timeout: 268 seconds]
<owrt-1907-builds> build #272 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt3883/builds/272
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
elektroman has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
<lipnitsk> aparcar[m]: ping
LoopHoldYoaBrown has joined #openwrt-devel
elektroman has joined #openwrt-devel
<owrt-1907-builds> build #273 of ar71xx/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fmikrotik/builds/273
<aparcar[m]> lipnitsk: semi available pong
<lipnitsk> aparcar[m]: please merge https://github.com/openwrt/gh-action-sdk/pull/3 when you get a chance - minor fix for the CI refresh check to print error
<lipnitsk> I've tested it
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
hbug___ has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
hbug__ has quit [Ping timeout: 268 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
<aparcar[m]> lipnitsk: thanks
LoopHoldYoaBrown has joined #openwrt-devel
<mangix> aparcar[m]: CI's not working on 21.02 yet
goliath has quit [Quit: SIGSEGV]
<mangix> blocktrron: whatever happened to the effort of switching to the upstream ag71xx driver?
Tapper has quit [Ping timeout: 240 seconds]
victhor has quit [Ping timeout: 240 seconds]
<philipp64> who owns target/linux/x86?
Grommish has joined #openwrt-devel
<owrt-1907-builds> build #277 of mvebu/cortexa72 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/277
<mangix> philipp64: people own targets?
<philipp64> um... don't they? I used to be the maintainer for the geode targets like geos2 and net5501...
<philipp64> but then there was the refactoring of everything and creating profiles vs. sub-targets and all of that went by the wayside...
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<mangix> hmm libcap-ng is broken
<mangix> why
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
jlsalvador has joined #openwrt-devel
<mangix> only static libraries are built...
_whitelogger has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
<owrt-1907-builds> build #278 of armvirt/32 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/278
LoopHoldYoaBrown has joined #openwrt-devel
<plntyk> philipp64, ask not about ownership but more likely for the maintainer
<plntyk> sometimes just checking target/linux/x86 commit history might give a single dev / small dev group - especially the "switch kernel" series
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<guidosarducci> anyone tried building ath79 using just merged 5.10 support? Error building kmod-mdio-gpio
mangix has quit [Remote host closed the connection]
mangix has joined #openwrt-devel
<mangix> guidosarducci: nope. something's totally broken locally.
<guidosarducci> mangix: clearly :). was looking for some success stories to confirm
awgh has joined #openwrt-devel
jlsalvador1 has joined #openwrt-devel
jlsalvador has quit [Quit: WeeChat 3.0]
jlsalvador1 is now known as jlsalvador
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
<owrt-1907-builds> build #272 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7622/builds/272
LoopHoldYoaBrown has joined #openwrt-devel
<lipnitsk> guidosarducci: I just built ath79 with my changes from https://github.com/openwrt/openwrt/pull/3885
<guidosarducci> lipnitsk: ok thanks, was that an "all kmods" build? I see failures now with: kmod-mdio-gpio, kmod-usb-chipidea2
<lipnitsk> yeah both of those are fixed in my branch.
<guidosarducci> lipnitsk: oh I see, your first commit. Since it's more general than wireguard, maybe an separate PR/commit? Unless that PR merge is imminent?
<lipnitsk> maybe it should be.
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
<lipnitsk> I think there is still discussion to be had with wireguard, but wireguard is also one of the modules :)
LoopHoldYoaBrown has joined #openwrt-devel
<guidosarducci> lipnitsk: just to be sure I'm testing a build with that commit cherry picked...
<guidosarducci> lipnitsk: yup, that builds OK.
<guidosarducci> lipnitsk: BTW, what are the "needs changes" for that PR? Eyes hurting, can't see...
<lipnitsk> it's the decision on how to proceed with wireguard for 5.4
<lipnitsk> that's the main sticking point I think. Plus any other feedback core folks may have for my changes - I pushed quite a bit today
<mangix> lipnitsk: there's also the exfat module
<mangix> it's included with kernel 5.8 and above I believe
<lipnitsk> hmmm, do we not build it at all now ?
<lipnitsk> something new that needs to be added?
<mangix> i mean, the kmod needs to be selected
<lipnitsk> and then it fails?
<mangix> i don't know if it does. I'm saying it needs to be set to depend on !LINUX5_10
<mangix> 5.10 supports exfat natively
<lipnitsk> okay. I see. there is that ntfs thing too
<lipnitsk> though that will be a backport
<mangix> well, ntfs is in the packages feed
<lipnitsk> there is the paragon kernel work
<lipnitsk> latest patchset
<lipnitsk> probably will get merged sooner or later
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
<mangix> lipnitsk: i believe they're planning on making it a kernel module
<lipnitsk> yeah but in-tree, right? Or would we still just stick it in packages?
<mangix> for ntfs, the module should be in base
<mangix> kernel modules don't really belong in packages
<mangix> Package jsonfilter is missing dependencies for the following libraries:
<mangix> libubox.so
LoopHoldYoaBrown has joined #openwrt-devel
<mangix> i think i need to flip a table
<lipnitsk> ;)
<owrt-1907-builds> build #267 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7623/builds/267
Darkmatter66 has joined #openwrt-devel
mangix_ has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
Darkmatter66 has quit [Quit: ZNC 1.8.2 - https://znc.in]
mangix has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #openwrt-devel
mangix_ is now known as mangix
LoopHoldYoaBrown has joined #openwrt-devel
snh_ has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh_ has quit [Ping timeout: 264 seconds]
snh- has joined #openwrt-devel
snh has quit [Ping timeout: 272 seconds]
snh- is now known as snh
<blocktrron> mangix: nobody took the effort to add the missing workarounds / MII configuration
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
<mangix> unfortunate
<mangix> blocktrron: would it make sense to backport a bunch of stuff?
blb4393 has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
dorf_ has quit [Remote host closed the connection]
dorf_ has joined #openwrt-devel
<owrt-2102-builds> build #6 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/layerscape%2Farmv8_64b/builds/6 blamelist: Seo Suchan <abnoeh@mail.com>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Sander Vanheule <sander@svanheule.net>, Stijn Segers <foss@volatilesystems.org>,
<owrt-2102-builds> Yangbo Lu <yangbo.lu@nxp.com>
<ynezz> noltari: stintel: so whats the issue with urngd and bcm2708?
<noltari> ynezz it doesn't work with bcm2708 but it does with bcm2709, bcm2710 and bcm2711
<noltari> init fails and returns ECOARSETIME
<ynezz> timer is not usable
<ynezz> you can't fix that
<ynezz> IIRC mt7620 has the same issue
<noltari> would it be possible to modify urngd to fallback to a hw rng?
snh_ has joined #openwrt-devel
<ynezz> does it make sense? intention was to have something very basic which can be used on all devices
<ynezz> if the platform has hwrng it probably has enough space to run something more complete then urngd
snh has quit [Ping timeout: 264 seconds]
snh_ is now known as snh
<ynezz> and if there is hwrng, it's usually handled via the kernel driver internally
rmilecki has joined #openwrt-devel
<ynezz> I don't know if it would make sense to leak the entropy into userspace and then feed it back from userspace to kernel
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
<noltari> are you sure that if there's hwrng it's handled internally?
<noltari> that doesn't make sense, considering that it takes >100s to achieve "random crng init done"
<ynezz> this is still the case on 5.10?
<ynezz> I've thought, that Linus fixed it already
lipnitsk has quit [Quit: Leaving.]
<noltari> I haven't tested it with 5.10, only with 5.4
<ynezz> it's commit 50ee7529ec4500c88f8664560770a7a1b65db72b in kernel
<ynezz> but it's probably using similar timer based entropy which probably doesn't work on bcm2708
LoopHoldYoaBrown has joined #openwrt-devel
<ynezz> "This only works when you have a high-frequency time stamp
<ynezz> counter available, but that's the case on all modern x86 CPU's, and on
<ynezz> most other modern CPU's too.
<ynezz> " :)
dedeckeh has joined #openwrt-devel
ivanich has joined #openwrt-devel
<noltari> ynezz yeah, I don't think that works on ARM v6
<ynezz> which RPIs are using this SoC?
<noltari> first generation RPis
<noltari> B, B+, A, A+, Zero, Zero W, Compute Module 1
<ynezz> ah Zero
bala has joined #openwrt-devel
<noltari> anyway, haveged works and now rng-tools works too (which can be configured to use /dev/hwrng)
<noltari> but... should urandom-seed work if I remove urngd on this target?
<noltari> because I couldn't get it to work
<blocktrron> mangix: what do you mean with backport a lot
<noltari> the problem with haveged and rng-tools is that these are hosted in the feeds, so I can't use them to have a working setup OOB which doesn't require external packages
<ynezz> ideally you should solve this in kernel
<ynezz> take the entropy from hwrng and feed kernel with it
<ynezz> no need for this kernel char driver -> userspace daemon -> kernel
<blocktrron> The upstream driver in it's current state is pretty much only usable with EWSs (and maybe AR93x7 switches), as it supports no delay configuration, RGMII clock setting as well as workarounds the RGMII / SGMII hangs
<noltari> ynezz any hints on how to that? xD
<noltari> I mean, I have the feeling that there should be some config flag to achieve that, right?
<ynezz> I didn't wrote anything like that, but while working on urngd I've noticed, that there is framework for that in kernel
<blocktrron> I don't say it's impossible to get the upstream driver up to shape, however with testing on all SoC generations, integration of everything can be multiple weeks of effort.
<blocktrron> But to be realistic - the last time this discussion came up was over a year ago. And nothing happened in that timeframe.
dorf_ has quit [Remote host closed the connection]
<ynezz> noltari: it's add_hwgenerator_randomness in drivers/char/random.c
<mangix> blocktrron: it's not like upstream hasn't been making changes. there's a flow control commit that could be backported for example
<blocktrron> if somebody wishes to backport flow control to our implementation, go ahead
<blocktrron> I was interpreting your proposal to backport stuff from k5.11 to 5.10 and use the in-tree one
<mangix> those two functions have been equivalent since kernel 2.6 days
<blocktrron> are they?
<blocktrron> last time I've checked this was not true for MIPS
<blocktrron> you're right, no idea what i was looking at
<blocktrron> But it's functionally equivalent anyways and will be removed with kernel 5.4 at some point anyways
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
<noltari> ynezz
<noltari> I think that what other distros are doing with RPi is to install rng-tools by default and configure it to use /dev/hwrng
Borromini has joined #openwrt-devel
<noltari> Perhaps we could move rng-tools from openwrt/packages to the main repo and therefore allow targets with a hw rng to include it as a default package
<Borromini> hi guys
<Borromini> blocktrron: ping
<Grommish> Borromini: :D The rabbit hole has reached a new milestone
<blocktrron> Borromini: pong
Droid-MAX has joined #openwrt-devel
<Grommish> I've now gone to the length of recompiling the WSLv2 kernel to enable network block devices ;/
<Grommish> and trying to compile qemu from source so I can make the kernel mod for it
<Borromini> blocktrron: hi. thanks for merging the EX6150 patch. could you backport it to 21.02?
Droid-MAX has quit [Remote host closed the connection]
<blocktrron> Borromini: yup, i can
LoopHoldYoaBrown has joined #openwrt-devel
Droid-MAX has joined #openwrt-devel
<blocktrron> done
Droid-MAX has quit [Remote host closed the connection]
Droid-MAX has joined #openwrt-devel
dorf has joined #openwrt-devel
<Borromini> cool, thanks!
Droid-MAX has quit [Remote host closed the connection]
Darkmatter66 has quit [Ping timeout: 256 seconds]
Droid-MAX has joined #openwrt-devel
Droid-MAX has quit [Remote host closed the connection]
Droid-MAX has joined #openwrt-devel
blb4393 has quit [Ping timeout: 264 seconds]
<blocktrron> mangix: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commit;h=17f2e0f5dda638e0a6056f713797db94e5bf0042 better?
<owrt-1907-builds> build #297 of mvebu/cortexa9 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa9/builds/297
guimo has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
Sebastiii has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<guimo> Hi, can someone add "TARGET_bcm27xx_bcm2711" at cpufreq in feed/packages/utils/collectd/Makefile please.
Darkmatter66 has quit [Ping timeout: 256 seconds]
Droid-MAX has quit [Quit: Leaving]
<mangix> blocktrron: sure
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
rmilecki has quit [Ping timeout: 256 seconds]
Night-Shade has quit [Ping timeout: 240 seconds]
dedeckeh has quit [Ping timeout: 240 seconds]
victhor has joined #openwrt-devel
Night-Shade has joined #openwrt-devel
<owrt-1907-builds> build #293 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa53/builds/293
<owrt-2102-builds> build #5 of ath79/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ath79%2Fmikrotik/builds/5
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
LoopHoldYoaBrown has joined #openwrt-devel
mangix has joined #openwrt-devel
novski has joined #openwrt-devel
Tapper has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
Darkmatter66 has joined #openwrt-devel
ivanich has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<ynezz> noltari: others doing it doesn't mean it is correct
<noltari> ynezz: for sure
<ynezz> noltari: you don't see this nonsense everybody copy&pasting? hwrng -> kernel char driver -> userspace daemon -> kernel entropy feeding
<noltari> ynezz: yes, because it’s the easy way to do it xD
<ynezz> I don't find commitment to the maintenance of rng-tools package easy way
<ynezz> noltari: BTW that jitterng library has advanced, maybe it would be worth trying the latest https://github.com/smuellerDD/jitterentropy-rngd ?
<ynezz> http://www.chronox.de/lrng.html seems to be interesting as well
<ynezz> I plan to bump urngd to the latest in the near future as well, now waiting to the resolution (or maybe fix) of https://github.com/smuellerDD/jitterentropy-library/issues/21
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
guimo has quit [Remote host closed the connection]
guimo has joined #openwrt-devel
<noltari> ynezz: thanks, I will try the latest version of jitternet
<noltari> jitterng*
<rsalvaterra> Uh, guys… shouldn't OpenWrt set net.ipv4.conf.{all,default}.promote_secondaries to 1…? I just noticed it's at the kernel default 0.
<owrt-1907-builds> build #282 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/archs38%2Fgeneric/builds/282
<rsalvaterra> At 0, if the primary address of an interface with multiple IP addresses gets remove, all the secondary IP addresses are removed too(!!).
<rsalvaterra> Not exactly a behaviour I'd personally expect.
LoopHoldYoaBrown has joined #openwrt-devel
<Grommish> What would be the replacement backuip IP? the 169=.xx?
<rsalvaterra> Grommish: the replacement would be link down.
<rsalvaterra> Great for remote management surprises.
<Grommish> Wouldn't the absence of an IP for IPv4 signify that? I geniunely don't know what it does when it drops
<Grommish> ifdown and whatnot?
<rsalvaterra> It means the interface will stop having IP connectivity, basically.
<russell--> i thought secondary addresses were obsolete
<Q_> ynezz: I don't think the author and me are ever going to agree on what amount of entropy it can collect.
<rsalvaterra> russell--: You mean aliases.
<Grommish> Dunno, which is why I was asking :) Its a subject i know nada about
<rsalvaterra> Interface aliases are obsolete, yes.
<russell--> eth0:1 eth0:2 etc
<rsalvaterra> IP aliases, however, are alive and kicking. ISPs use them to save one public IP address per client, for example.
<russell--> ip addr add a.b.c.d/e dev eth0
<Grommish> My ISP gives 4 public IPv4 per customer :D They don't advertise it though
<stintel> noltari: ynezz: could it be that urngd is blocking startup of rngd? that explains why START=0 "fixes" the issue with rngd
<russell--> when i add an address with the command syntax above, it isn't labelled as a secondary address
<russell--> afaict
<Q_> I would hope that if you have a hardware rng you would use that instead of urngd. You really want the kernel to directly use it, and as far as I understand, the kernel wants to support that.
<russell--> if i add an address to an interface, with, e.g. ip addr add 192.168.211.1/24 dev br-pub, i get another address attached to the interface, but no priority: https://pastebin.com/PbQ1d0Lg
<stintel> goddamnit my /etc/ipsec.conf is gone
<rsalvaterra> russell--: Right you are! That's a relief, I hadn't noticed. A bit of knee-jerk on my part. :)
ivanich has joined #openwrt-devel
<russell--> "An IP address becomes secondary if another address within the same prefix (network) already exists."
<stintel> ok I'm just going to revert latest changes to strongswan, that's exactly what I kept warning for, breaking existing ipsec setups is unacceptable
<stintel> goddamnit if you don't to everything yourself
<Grommish> Anyone use qemu?
<stintel> Grommish: yes
<Grommish> I'm trying to qemu a mips64. I'd like to look at alpine because it seems whatever.. Is there a way to use the"mini rootfile system" they have listed?
<russell--> here i get a secondary when i: ip addr add 192.168.211.1/24 dev br-pub ; ip addr add 192.168.211.2/24 dev br-pub ==> https://pastebin.com/Zq4PCkre
<rsalvaterra> russell--: I see, only within the same network. Still, I believe the default behaviour violates the principle of least surprise… :/
<rsalvaterra> Remove the primary, remove them all…
<Grommish> Debian doesn't havea mips64be version :(
<russell--> you shouldn't be removing them ;-)
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
<stintel> have no experience with qemu/mips64 sorry
<rsalvaterra> russell--: Right, I'll just file it under "don't to that", then. :P
<Grommish> Gotcha.. Thanks :)
<Grommish> I've got a mips debian install happening at the moment, but I want to use a mips64 aware OS thru qemu
<rsalvaterra> mangix: I know you love LEDs, so I just want to let you know Linux 5.10 has a driver for the Turris Omnia RGB LEDs (using the brand spanking new multicolour framework). So inclusive! <3
blb4393 has joined #openwrt-devel
<mangix> lol finally upstream?
LoopHoldYoaBrown has joined #openwrt-devel
<plntyk> some qemu stuff is only nice for testing "cross plattform" and uncover some bugs in toolchain / portability issues
<Grommish> Yeah, that's what I'm wanting to use it for
<mangix> Grommish: you use GNOME?
<rsalvaterra> mangix: Oh, yeah! But I'm not putting it in the default mvebu config, for now. It's probably better to build it as a module, not to bloat the core kernel. :)
Borromini has quit [Ping timeout: 264 seconds]
<mangix> Of course
<Grommish> mangix: no, I've got headless Ubuntu 20.04 under WSLv2 and a rebuilt kernel (under Win10)
dedeckeh has joined #openwrt-devel
<Grommish> and I"m using that to build the qemu mips debian install
<Grommish> I want to build out rustc/cargo natively in mips
<mangix> Lol. Best of luck.
<Grommish> First thing is getting an Openwrt build system in Mips ;p
<Grommish> athen waiting for it to build
<russell--> holy crap, this (policyrouting.org) is 20 years old: "Revised Feb 23, 2001"
<mangix> Anyway, alpine has mips64 I believe
<plntyk> buildroot has mips64 CI - maybe look there too http://autobuild.buildroot.org/?subarch=mips64
<Grommish> mangix: they do, but I'm not sure how to use their "mini filesystem" with qemu
<Grommish> which was the original question
<Grommish> (which is the only mips64 version they have)
<plntyk> mips has kernel and rootfs separated - https://openwrt.org/docs/guide-user/virtualization/qemu
<plntyk> i remember writing and testing that mips qemu part and it worked - some years ago
<Grommish> Right.. with the debian install, I grabbed the initrd and the kernel and it is in the process of installing ot the qcow2 vhd I made
<Grommish> but it was for the 4k I think
<Grommish> I tried a docker image, but I coudln't figure out how to expand the storage it had
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<mangix> Anyway, I was going to suggest GNOME Boxes but it seems you're not running Linux.
<Grommish> I've got a native intalled Ubuntu 20.04 on another machine
<Grommish> But qemu lets me run it across devices
<mangix> GNOME Boxes uses QEMU.
<Grommish> I'll take a look
<ynezz> stintel: urngd should bail out on that error, as it makes no sense to be running if the host CPU can't produce usable jitter
<Grommish> I had to build a new kernel so WSL had module support
<rsalvaterra> Alright, v2 of the mvebu 5.10 bringup sent.
<ynezz> Q_: hi! :) thanks for looking into that, I really appreciate your thorough review and bringing this to our attention
<ynezz> Q_: althought I'm probably not able to understand the issue without digging a lot deeper into it, so basicaly relying on Stephan
<ynezz> Q_: BTW is kernel having same entropy overestimation problem? AFAIK similar functionality is being used there as well
<Q_> ynezz: I know the kernel is also doing something like that, I never really looked at it, it's not as easy (for me) to look at it.
<ynezz> Q_: what would you propose as a fix? simply divide the entropy bit count by 100 ?
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<Q_> I'm a little afraid that it would increase boot times
<Q_> But urngd is actually fast
<ynezz> well, we could be afraid once we get real numbers
<ynezz> or maybe just run that collect loop 100x times more
<ynezz> but in the end it's probably the same result
<mangix> Is urngd in 19.07?
<ynezz> yes
<Q_> I've been planning to do real restart tests. As in restart device, not just restart the software.
<mangix> Hmm. Wonder why the turris people use haveged.
<ynezz> because omnia has hwrng?
<Q_> Why use haveged then at all?
<ynezz> ah, then I'm just mistaken, I don't use either, so I've thought, that haveged can use hwrng
<mangix> I don't think the hwrng is functional
csrf has joined #openwrt-devel
<ynezz> bummer, it would be first thing to get going :p
<mangix> Actually I remember replacing haveged on my Omnia. Eliminated rng init warnings
<mangix> Or caring not ready. w/e
<rsalvaterra> The Omnia doesn't have a useable hwrng.
dorf_ has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<rsalvaterra> Sure, it has a random number generator, but with one big caveat…
<mangix> Internal?
dorf has quit [Remote host closed the connection]
<ynezz> grep -c rng drivers/crypto/atmel-sha204a.c -> 19
<rsalvaterra> «Because there is an EEPROM endurance specification that limits the number of times the EEPROM seed can be updated, the Host system should manage power cycles to minimize the number of required updates. In certain circumstances, the system may choose to suppress the EEPROM seed update using the mode parameter to the Nonce and Random commands.»
<ynezz> but still it should be good enough as an additional entropy source
<rsalvaterra> ynezz: I'd rather not use it for that purpose…
<ynezz> you don't use just that, it's a mix of different sources anyway
<ynezz> which makes the overal entropy better
<ynezz> so the more the better, or it won't hurt
<rsalvaterra> IIRC, TurrisOS gets entropy from the ATSHA204 exactly once, at boot time.
<rsalvaterra> If it's used as an additional entropy source, the kernel can get entropy from it as it pleases. Not good.
<Grommish> Wouldn't more entropy be better?
<owrt-1907-builds> build #270 of x86/geode is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeode/builds/270
<rsalvaterra> I'd rather stick an ath9k card in there and get more entropy from the ADC.
<ynezz> I would say, that the quotation you've just pasted might be an issue in MCU world, where that IC is the only source of entropy
<rsalvaterra> ynezz: Undoubtedly.
<ynezz> not an issue for Linux, it gets mixed with other sources anyway
<mangix> Hmm
adrianschmutzler has joined #openwrt-devel
<mangix> That ath9k thing usable at boot?
<stintel> wtf
<stintel> Sat Feb 20 13:59:54 2021 kern.notice kernel: [ 87.112662] random: crng init done
<stintel> Sat Feb 20 13:59:57 2021 daemon.err rngd[1008]: Initializing available sources
<stintel> rngd only starts *after* crng init finished
<stintel> even with START=00
<ynezz> getrandom() :p
<rsalvaterra> ynezz: Yes, it gets mixed, but that's not the point. The point is, how often will the kernel use it, and how long it will take until it gets broken from use?
<stintel> meh
<stintel> I'll bisect it when I return from Dubai
<ynezz> rsalvaterra: it's just stream of random bits, which gets mixed with other random bits and in the end producing the entropy bits for the end user, AFAIK you can't tell kernel to just use one source
<rsalvaterra> mangix: Not until the kernel module is loaded. Because (GAH!) compat.
<rsalvaterra> stintel: In that case, I'd rather not use it. A source of entropy which wears down over time is special.
<rsalvaterra> And it should be treated in a special way.
<rsalvaterra> Just my 0,02 €.
<stintel> what do you mean?
<stintel> something changed between openwrt w/ kernel 5.4.43 and w/ kernel 5.4.80. with 5.4.43 I boot the Pi0W and rngd uses /dev/hwrng to feed entropy and crng init is done in ~20s
<stintel> with 5.4.80 this does not work anymore, rngd starts only after crng init is done already
<stintel> which completely defeats the purpose of running rngd
<stintel> the main problem is that network does not come up until crng init is done
<stintel> so a reboot has the device offline for almost 2 minutes instead of ~30s
<stintel> that's simply not acceptable
<Q_> It seems to have a mode where it doesn't update the EEPROM, but it all looks very weird.
<rsalvaterra> Q_: I see it. Chapter 8.6.14, right?
<rsalvaterra> Heh… but that means it'll be generating from a static seed. Not exactly what "random" means… :)
<stintel> rsalvaterra: what static seed?
<ynezz> stintel: so perhaps 5.4.56, 5.4.68 or 5.4.77 I would say
<stintel> rngd uses /dev/hwrng - the hardware rng available in all RPi SOC
<rsalvaterra> Oh, you're talking about the Pi, I thought it was the ATSHA204.
<Q_> stintel: I see: [ 11.042034] urngd: v1.0.2 started. [ 11.264386] random: crng init done
swex_ has quit [Ping timeout: 256 seconds]
<ynezz> stintel: leaning more towards 5.4.56 or 5.4.77
<stintel> Q_: rpi0w cannot use jitterentropy which urngd uses, so I need rngd instead
<ynezz> Q_: it's bcm2708 which doesn't have suitable timer
swex has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
nitdega has quit [Ping timeout: 260 seconds]
<ynezz> stintel: see 213e1238caccfa8a0d1aa04967486cd8f3025c16
<Q_> Just saying that it should be possible to run rngd before the kernel is done.
<stintel> [ 12.414680] urngd: jent-rng init failed, err: 2 [ 21.940740] random: crng init done [ 35.963169] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
<stintel> Q_: I know, it used to work, it doesn't anymore
<stintel> ^ is from when it worked
<stintel> [ 11.276469] urngd: jent-rng init failed, err: 2 [ 87.112662] random: crng init done [ 102.220810] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
<stintel> and here it doesn't and rngd starts only after crng init done, which seems a regression
<Q_> rsalvaterra: Yes, it all sounds like it's a really crappy RNG that they need to combine it with a seed.
<stintel> does that look like crappy rng?
<Q_> stintel: Still talking about the ATSHA204.
<stintel> ok, I don't even know why we are discussing that ¯\_(ツ)_/¯
<Q_> And testing the output of /dev/random doesn't make any sense.
Darkmatter66 has quit [Ping timeout: 256 seconds]
<stintel> noltari: fyi ^ :)
LoopHoldYoaBrown has joined #openwrt-devel
<rsalvaterra> Actually, /dev/random became non-blocking in 5.10, I believe. It's just the same as /dev/urandom.
<olmari> rsalvaterra: the ef now, that sounds shitty.. I mean I get that peoples uses /dev/random way too.. hmm... "when no need to", but changing that to non-blocking because peoples are stoopid is.. stoopid.. (not that it is your fault, but you said that 😀 )
<stintel> can always hook up an infnoise trng to the pi0 but meh :P
<rsalvaterra> Actually, it was on Linux 5.6, not 5.10.
<rsalvaterra> olmari: The point is /dev/random is best-effort and always has been. The blocking behaviour itself was "stoopid". :P
<Q_> As far as I know, it still blocks as long as it didn't get enough entropy.
<olmari> rsalvaterra: I don't see it that way, but that doesn't obviously even matter =)
<Q_> But the behaviour that made it block after getting data from it never made sense, getting data from it doesn't lower the entropy.
<rsalvaterra> Q_: It blocks at boot *only* until the crng init is completed. After that it's non-blocking.
<Q_> rsalvaterra: Isn't that what I said?
<rsalvaterra> Right, I misread, sorry. :)
<Q_> Anyway, NIST no longer accepts /dev/random as a valid source of entropy. One of the reasons /dev/random didn't get changed was that people where using it for FIPS.
<stintel> ynezz: thanks for that commit, I'll try reverting just that and see what gives. beats bisecting
goliath has joined #openwrt-devel
<stintel> and we're back at bikeshedding
<stintel> ehr, yak shaving*
<stintel> fuck this, I'm going call of duty
<ynezz> well GKH asked for runtime testing of -rc stable kernel releases
<stintel> it's gitlab CI blocking my PR to fix a typo because patches need refreshing
<stintel> I don't even use those packages
<stintel> I'm sick of this shit, every fucking time I want to do something, I ended fixing other people's mess
<ynezz> that's software business :p
snh has quit [Read error: Connection reset by peer]
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
snh has joined #openwrt-devel
Namidairo has quit [Read error: Connection reset by peer]
Namidairo has joined #openwrt-devel
<ynezz> gpg: Good signature from "OpenWrt Build System (PGP key for 19.07 release builds) <pgpsign-19.07@openwrt.org>"
<ynezz> Good signature from "OpenWrt Build System (PGP key for unattended snapshot builds) <pgpsign-snapshots@openwrt.org>" [unknown]
<ynezz> sorry, wrong channel
<Hauke> bookworm: pong
LoopHoldYoaBrown has joined #openwrt-devel
<bookworm> Hauke: ping sure, but why
<Hauke> bookworm: sorry worng nick ;-)
<Hauke> wanted to anser Borromini ping, but he is not here any more
<svanheule> Hauke: I think I can replace Borromini here
<svanheule> Hauke: Borromini asked earlier about the sx150x driver, which is required for a few mt7621 devices
<svanheule> it was decided to create a package for the driver, to not bloat the kernel for other devices
<svanheule> but, the sx150x doesn't support building as a module, only as built-in, so it would have to be enabled for all mt7621 currently to properly support those two devices that use it
<svanheule> so we were wondering how to proceed. add it to the target's kernel config anyway, or try to modularise the driver
<svanheule> I don't think either of us understands kernel module enough to attempt the latter, though...
<Hauke> svanheule: ok, then I would just add it to the default kernel config
<owrt-1907-builds> build #278 of kirkwood/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/kirkwood%2Fgeneric/builds/278
<owrt-snap-builds> build #779 of armvirt/32 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/779 blamelist: Andreas Eberlein <foodeas@aeberlein.de>, David Bauer <mail@david-bauer.net>, Stijn Segers <foss@volatilesystems.org>, Christian Lamparter <chunkeey@gmail.com>, Rapha?l M?lotte
<owrt-snap-builds> <raphael.melotte@mind.be>
<stintel> is it expected that snmpd on realtek/dsa does not show the correct traffic
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<svanheule> stintel: maybe ask in #rtl83xx where the realtek network devs are hiding
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
owrt-1907-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-1907-builds has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
snh has quit [Quit: ZNC - http://znc.in]
xdarklight has quit [Quit: ZNC - http://znc.in]
snh has joined #openwrt-devel
xdarklight has joined #openwrt-devel
owrt-2102-builds has quit [Client Quit]
owrt-2102-builds has joined #openwrt-devel
<owrt-1907-builds> build #233 of lantiq/falcon is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/233
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
jlsalvador1 has joined #openwrt-devel
<adrianschmutzler> BTW I'm about to fix layerscape build ...
jlsalvador has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
<noltari> jitterentropy-rngd doesn't quit if init fails, but urngd does
LoopHoldYoaBrown has joined #openwrt-devel
<ynezz> urngd --dont-care-about-entropy
<ynezz> and then continue instead of the error
<noltari> yes, but that's not what jitterentropy-rngd uses :)
jlsalvador1 has quit [Ping timeout: 246 seconds]
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
victhor has quit [Remote host closed the connection]
<owrt-1907-builds> build #218 of ipq40xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq40xx%2Fgeneric/builds/218
LoopHoldYoaBrown has joined #openwrt-devel
dorf_ has quit [Remote host closed the connection]
dorf_ has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.2% packages reproducible in our current test framework.)
dangole has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
jlsalvador1 has joined #openwrt-devel
<owrt-1907-builds> build #216 of lantiq/xway_legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxway_legacy/builds/216
LoopHoldYoaBrown has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<noltari> ynezz stintel I just found out how to fix the RPi issue...
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
<noltari> khwrngd isn't feeding entropy from bcm2835-rng because quality isn't set, so khwrngd just ignores the hw rng
<noltari> after applying that patch: [ 1.014146] random: crng init done
<noltari> ynezz is it possible to disable urngd? for a whole target?
<stintel> damn 1 sec is nice
LoopHoldYoaBrown has joined #openwrt-devel
<owrt-1907-builds> build #216 of sunxi/cortexa8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa8/builds/216
jlsalvador1 is now known as jlsalvador
<noltari> stintel I'm gonna add the patch in generic. That way bcm63xx can benefit too
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
danitool has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<adrianschmutzler> dangole: ping
nitdega has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
Darkmatter66 has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
Tapper1 is now known as Tapper
LoopHoldYoaBrown has joined #openwrt-devel
<dangole> adrianschmutzler: pong
<adrianschmutzler> dangole: I'm having a build problem with fiptool
<adrianschmutzler> This option here is not available with the fiptool from arm-trusted-firmware-tools
<adrianschmutzler> --ddr-immem-udimm-1d etc.
<adrianschmutzler> So, I wonder whether I need to revert https://github.com/openwrt/openwrt/commit/84bc7d31e0a83688ef00b89b78cd124fb55e594d
lipnitsk has joined #openwrt-devel
<dangole> adrianschmutzler: yes, sounds like it :( may change the install path to something else than 'tfa-fiptool' then, eg. 'fiptool-layerscape'
<adrianschmutzler> currently, building ls-ddr-phy fails with "create: unrecognized option '--ddr-immem-udimm-1d'"
<adrianschmutzler> the final names in tools won't collide so far, since tfa-layerscape uses tfa-fiptool and arm-trusted... uses just fiptool
<adrianschmutzler> in /bin I mean
<adrianschmutzler> However, I wonder whether we get a collision since both use $(HOST_BUILD_DIR)/tools/fiptool
<dangole> adrianschmutzler: yes, but tfa-fiptool isn't really a descriptive name given that it's a special version with option for layerscape
<adrianschmutzler> okay, I don't mind, so I will call it fiptool-layerscape
<dangole> adrianschmutzler: HOST_BUILD_DIR is set to different paths for tfa-layerscape and arm-trusted-firmware-tools
<dangole> adrianschmutzler: sounds perfect. are you going to commit that?
<adrianschmutzler> ah, okay, so there is no collision? I'm not familiar with host package building ...
<dangole> adrianschmutzler: it's like PKG_BUILD_DIR, ie. there is a default which includes PKG_NAME, PKG_VERSION, ...
<adrianschmutzler> ah, fine
<adrianschmutzler> btw, how do I properly trigger clean/build for a host package via make?
<dangole> adrianschmutzler: by rebuilding a package which depends on pkgname/host ...? i wish i knew a better way.... anyone?
<adrianschmutzler> i.e. for tfa-layerscape and arm-trusted-...
<adrianschmutzler> err, wait a sec
<dangole> adrianschmutzler: ie. rm -rf build_dir/hostpkg/tfa-layerscape-* ; make package/tfa-layerscape/compile ; # should do the trick
<stintel> noltari: nice catch, really. thanks!
<adrianschmutzler> dangole: I just tried with "make package/boot/arm-trusted-firmware-tools/clean"
<adrianschmutzler> but that doesn't remove staging_dir/host/bin/fiptool
<noltari> stintel: no problem :)
<adrianschmutzler> can't I trigger the Host/Clean of a specific package somehow?
<owrt-1907-builds> build #230 of x86/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/230
<philipp64> adrianschmutlzer: seeing missing CONFIG_ symbols when building x86_64 after rebasing to HEAD.
<rsalvaterra> tmn505: Thanks for the review, I'll address your comments ASAP. :)
<adrianschmutzler> consider handling config the same way you handle patches, if you have to touch it again anyway:
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
<adrianschmutzler> copy everything first, the just have the refresh in a separate commit
<adrianschmutzler> you might copy config and patches in the same commit ...
<adrianschmutzler> ^ rsalvaterra
<adrianschmutzler> normally, the sequence would be
<adrianschmutzler> 1. copy patches/config/files from 5.4 to 5.10
<adrianschmutzler> 2. refresh patches
<adrianschmutzler> 3. refresh config
<adrianschmutzler> 4. do the rest
<rsalvaterra> adrianschmutzler: Uhh… but that's what I did. The first patch is a brainless copy. The second patch is the refresh.
<adrianschmutzler> yes, but handled the config differently
<adrianschmutzler> *you handled
<adrianschmutzler> you only copied the patches IIRC
<rsalvaterra> Yes, because the patches introduce new kconfig symbols. I can copy the kconfig alongside with the patches, but I'll have to refresh it twice.
<rsalvaterra> Is that what you're suggesting?
<adrianschmutzler> no, 1. you copy patches and config
<adrianschmutzler> no change
<adrianschmutzler> 2. you refresh patches, config won't matter here
<adrianschmutzler> 3. you refresh config
<adrianschmutzler> if you want to be supertidy, you can refresh the 5.4 config beforehand, but I don't think that's really necessary
LoopHoldYoaBrown has joined #openwrt-devel
<rsalvaterra> adrianschmutzler: I have a pending patch refreshing the 5.4 kconfig, yes. It's still dirty. :P
<rsalvaterra> Want me to send it as part of the series?
<adrianschmutzler> not sure whether that's necessary ...
<rsalvaterra> It cleans up all the HAVE_* symbols… I believe it's an improvement.
<rsalvaterra> But not necessarily as part of this series, of course.
<rsalvaterra> However, it would make the 5.4 to 5.10 diff easier to read…
<adrianschmutzler> let's not make it even more complicated. technically, removing the HAVE symbols on 5.4 would make the config-diff smaller, so the changes just due to 5.4->5.10 would become easier to see
<rsalvaterra> So, your call.
<adrianschmutzler> but don't know whether we should even more extend the patchset by theat
<adrianschmutzler> choose what you prefer. My main point is making the diff visible in the patches directly, because just adding files already including changes is not very helpful to read.
<rsalvaterra> In that case, a first automatic patch refreshing the 5.4 kconfig seems reasonable to me. And since it will make the 5.10 diff easier to review, I'll include it.
<adrianschmutzler> okay, fine :-)
<rsalvaterra> I guess this will be a fun evening (no sarcasm). :D
<rsalvaterra> Oh, one question. I don't have mvebu arm64 hardware and tmn505 mentioned I haven't refreshed the respective kconfigs. How would you do it, in such a situation?
<rsalvaterra> Just select a platform with make menuconfig and refresh afterwards?
<adrianschmutzler> you may either just ignore it and only care about your subtarget, like David did e.g. for mpc85xx/p1010
<adrianschmutzler> or you play with kernel_oldconfig CONFIG_TARGET=subtarget
<rsalvaterra> Alright, I'll play with it for a bit and see what comes out. ;)
<adrianschmutzler> but I cannot really guide you on how to use this properly, i.e. in which order you refresh
<adrianschmutzler> *refresh config
<rsalvaterra> No worries, you already helped me a lot. :)
<rsalvaterra> Thanks!
<adrianschmutzler> general question: how are we with 4M flash devices? Can I reject a PR with a "new" 4/32 device right away?
<rsalvaterra> adrianschmutzler: Nooooooo! Exclude it from normal builds, if if you will, but don't downright dismiss them… :)
* rsalvaterra still believes in 4 MiB flash devices…
guimo has quit [Ping timeout: 268 seconds]
<adrianschmutzler> rsalvaterra: nobody will review it
<adrianschmutzler> I was the last one reviewing these
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
<adrianschmutzler> but if there is no other opinion about it, I will just leave it rot
<adrianschmutzler> dangole: thanks for your help, that should be enough for me to clean up the fiptool stuff and merge it after testing.
LoopHoldYoaBrown has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
dedeckeh has joined #openwrt-devel
guimo has joined #openwrt-devel
<owrt-1907-builds> build #233 of mxs/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mxs%2Fgeneric/builds/233
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
<dangole> adrianschmutzler: thanks for taking care of that.
LoopHoldYoaBrown has joined #openwrt-devel
Borromini has joined #openwrt-devel
<mangix> rsalvaterra: and I believe in the Yeti...
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
<mangix> dedekeh: have you tested odhcpd in v4 mode?
<rsalvaterra> mangix: Bah… :P
<philipp64> jow, dangole: anyone have a chance to look at http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033907.html ?
<Borromini> adrianschmutzler: ping
<rsalvaterra> mangix: I still have the IRQ storm with 5.10 on the Omnia… :/
<rsalvaterra> From /proc/interrupts…
<rsalvaterra> 86: 2090203 0 f1018140.gpio 14 Level 8-0071
<rsalvaterra> This is little over a day of uptime.
<rsalvaterra> I feel tempted just to disable that interrupt in the device tree, as dangole suggested…
<mangix> Weird. GPIO on my Helios is fine
<rsalvaterra> Helios != Omnia
<mangix> Same platform
<rsalvaterra> Same GPIO controller?
<mangix> 58:          0          0  f1018100.gpio  23 Edge      0-0020  59:          0          0  f1018100.gpio  20 Edge      f10d8000.sdhci cd  60:          5          0  f1018100.gpio  18 Edge      Wake-On-LAN 
<adrianschmutzler> Borromini: if you are quick
<rsalvaterra> What is surprising is the kernel not complaining after over 2 million interrupts… 5.4 would shut the handler up after around 1 million, sometimes even less.
<mangix> f1018100.gpio is the same
<mangix> you should ask in #turris what's going on.
<rsalvaterra> Hm… but this is OpenWrt, not TurrisOS…
<mangix> Close enough :).
<Pepe> Maybe kab-el might help with that. Not sure if he has running kernel 5.10 on Turris Omnia
<dangole> rsalvaterra: we should ask them, because those spurious interrupts can be caused by unused GPIO lines left in input mode. setting unconnected GPIOs to output mode may also solve it
<rsalvaterra> Pepe: I asked kab-el on this channel, months ago.
<rsalvaterra> dangole: will do, then. :)
<mangix> rsalvaterra: no idea if you noticed the wake-on-lan thing. It's a custom Armbian patch. No idea if it should be imported here.
<rsalvaterra> mangix: Whoa, right. WoL…? o_O
<rsalvaterra> Well, not very useful to me, on the Omnia… I use it to wake up *other* machines. :P
<kab-el> rsalvaterra: can you tell how fast does the interrupt number grow? and if it grows consistently?
<rsalvaterra> kab-el: Let me do a quick estimate.
<kab-el> rsalvaterra: on my omnnia it is 58: 100001 0 f1018140.gpio 14 Level 8-0071
<kab-el> rsalvaterra: uptime 74 days
<lipnitsk> mangix: do you want me to refresh the patch refresh PR? https://github.com/openwrt/packages/pull/14646
<rsalvaterra> kab-el: Constant rate, about 30 per second.
<mangix> lipnitsk: Sure. Mind the mc patch.
<Borromini> adrianschmutzler: could you merge my v2 for the dir-860l dts patch?
<rsalvaterra> kab-el: If this helps, I'm not using the SFP cage (but I'm using the lan4 port).
<Borromini> forgot to put you in copy, sorry
<lipnitsk> mangix: is that the last one of the issues? quilt expanded a variable?
<lipnitsk> you fixed the other patches quilt didn't like, right?
<kab-el> rsalvaterra: what about the eth2 PHY ? do you use eth2 ?
<rsalvaterra> kab-el: Check your dmesg. It stopped at 100001. You probably have a stack trace, "IRQ 71: nobody cared".
<kab-el> rsalvaterra: oh
<rsalvaterra> Oh, indeed.
<mangix> That was the missing - in the patch. I believe the other ones are fine. I also fixed it here: https://github.com/openwrt/packages/pull/14752
<mangix> But I don't use mc.
<lipnitsk> ah ok
<rsalvaterra> kab-el: I'm using eth2, yes, it's my wan. I have an external switch connected to the lan4 port.
<kab-el> ok i am seeing it, 25 interrupts per second for me
<Borromini> adrianschmutzler: and backport it to 21.02 as well pretty please :)
<rsalvaterra> kab-el: Aleluia, someone repros it! :D
<rsalvaterra> (Heh, even wrote in Portuguese. :P)
<mangix> Mea lua
<rsalvaterra> kab-el: I don't know about TurrisOS, but I'm pretty sure it happens there too, it's the same kernel, basically…
<rsalvaterra> (I haven't used TurrisOS in three years.)
<kab-el> rsalvaterra: it's happening for me on my custom built kernel on gentoo, so :)
<rsalvaterra> I used to run Gentoo, but it was too brittle (this was around 2001). Playing with the USE flags didn't help, of course. :P
<owrt-1907-builds> build #231 of lantiq/xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/231
* mangix remembers ALARM on his omnia
<mangix> everything was broken
<kab-el> rsalvaterra: gentoo went through a lot of changes when a new group of people started developing it in the first half of 2010s
<kab-el> rsalvaterra: it is actually in a pretty good shape now, perfect for customizing embedded environments (much better than buildroot imho)
<kab-el> rsalvaterra: if you know what you are doing of course
<rsalvaterra> kab-el: I don't know what I'm doing, most of the time. :P
<kab-el> rsalvaterra: much of the good stuff happened thanks to chromium-os, since it is based on gentoo, so they are contributing
<rsalvaterra> Oh, that explains it.
<stintel> yay, made it to battle pass tier 100 in call of duty
<karlp> that was a goal from a few weeks ago wasn't it? congratulations
<rsalvaterra> I think the only games I play now are in DOSBox… or FS-UAE. :P
* rsalvaterra can still get lost for hours in SimCity 2000…
<stintel> karlp: ack. thanks :)
<stintel> now let's see if I can get some work done without getting too frustrated by yak shaving
<rsalvaterra> Speaking of yak shaving, I'd really like to avoid touching arm64 for now… building toolchains takes a long time here, and to do it just make kernel_oldconfig on two targets I can't even test… :/
<rsalvaterra> *just to make
<zx2c4> lipnitsk: hey!
<lipnitsk> hi - maybe it's better to chat here than spam github, huh
black_ant has quit [Ping timeout: 256 seconds]
<kab-el> rsalvaterra: ok i found what seems to be the problem
<kab-el> rsalvaterra: basically there are two :)
<rsalvaterra> If they're solvable, they're not problems! ;)
<rsalvaterra> So, what happened?
<kab-el> one problem is that the pca9538 interrupt controller generates interrupts even if the changed pin is not an interrupt pin. You can't mask interrupts on this controller
<rsalvaterra> :/
<owrt-1907-builds> build #222 of brcm2708/bcm2709 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/222
<kab-el> the second problem is that the eth2 PHY interrupt pin is not configured as an interrupt pin, but rather as LED[2] pin, and the default behaviour of LED[2] is set to "on - link; blink - activity; off - no link"
<kab-el> so basically this problems goes away if there is no activity on eth2
<kab-el> we have to fix marvell PHY driver to enable the interrupt pin to be interrupt pin istead of LED[2]
<kab-el> this solved the problem
<rsalvaterra> A LED?! o_O
<kab-el> rsalvaterra: yes the pin is a multi-purpose pin, it can either act as a LED[2] pin or as interrupt pin
<kab-el> rsalvaterra: the boards connects it as an interrupt pin, but the driver leaves the configuration to LED[2]
<rsalvaterra> Ok… so this will be fixed in the upstream kernel and backported to stable, right?
<kab-el> i will send patches, hopefully they will be accepted
<rsalvaterra> Alright, if you cc me, I'll test them on my Omnia.
bala has quit [Ping timeout: 264 seconds]
dangole has quit [Remote host closed the connection]
<mangix> rsalvaterra: makes sense why i didn't have this issue :P
<rsalvaterra> mangix: You're not using eth2… :P
<mangix> LEDs
<mangix> I have all of them off
<rsalvaterra> Me too, but I use the front panel button…
<rsalvaterra> … of course, one time I woke up in the middle of the night with my bedroom all lit up. The energy failed for a couple of minutes. After a cold boot, the LEDs on the Omnia come up at full brightness. :P
dedeckeh has quit [Quit: Connection closed]
<kab-el> rsalvaterra: mail sent
<rsalvaterra> kab-el: Thanks!
<kab-el> mangix: it does not matter that you have LEDs OFF
Acinonyx has quit [Ping timeout: 240 seconds]
<kab-el> mangix: the pin is not connected to a LED
<kab-el> mangix: the pin is connected to pca953x gpio/interrupt controller, which generates interrupts when any input pin changes
Acinonyx has joined #openwrt-devel
<owrt-1907-builds> build #231 of brcm2708/bcm2708 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2708/builds/231
<kab-el> mangix: and by default (after reset) the pin is configure into LED[2] mode, and then marvell PHY driver configures the LED into blinking on activity mode
<mangix> OK
<kab-el> mangix: the marvell PHY driver does this by default without any configuration
<mangix> i wonder if this became an issue at kernel 5.7
<rsalvaterra> mangix: 5.7? I was seeing this on 18.06.
<mangix> ah nvm then
<dorf_> I don't know if it's relevant, but on my wrt1900acs, I have to tweak the led config after a reboot to get it to remember the previously saved settings.
<mangix> I'm looking an an LED patch for the helios, which is needed for 5.7 or 5.8 and above
<mangix> Although the issue there is that LEDs stopped working
<rsalvaterra> How can I tell quilt to apply everything it can? Is -f enough?
<mangix> Speaking of quilt, PRs to the packages feed will now become more difficult (or have been already)
<mangix> quilt has become a requirement
<rsalvaterra> Why more difficult?
<mangix> if you think about it, getting a PR merged in the packages feed is somewhat difficult
<mangix> need a proper signoff, PKG_RELEASE bump, get the buildbots happy, and now quilt
<lipnitsk> if there are patches to refresh, you mean?
<mangix> yeah
<rsalvaterra> lipnitsk: Yes, exactly. :)
<mangix> a lot of packages have patches, as I'm sure you've found out :)
<lipnitsk> yeah, I'm running (still) to refresh my refresh PR :)
<mangix> oh I'm sure that takes forever
<lipnitsk> that still leaves version updates requiring a refresh
<mangix> i ran a similar thing
<mangix> gave up after it went through the admin directory
<lipnitsk> yeah I'm sure it could be done faster but the build system does not have the package/feeds/packages/refresh target..
<mangix> well, make is slow in general
<mangix> In other news, I broke patchelf upstream :)
<stintel> we're used to you breaking things ;)
<dorf_> are there any plans to make release upgrades smoother? like a full backup and reinstall of installed apps and configs?
<mangix> stintel: weird thing was it was a driveby merge. no comments.
<mangix> that never happens here
<Borromini> hehe
ivanich has quit [Quit: Konversation terminated!]