<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
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]
<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. :)
<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"
<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.
<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
<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-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]
<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.
<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: 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
<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
<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.