sorinello has quit [Read error: Connection reset by peer]
sorinello has joined #openwrt-devel
Piraty has quit [Remote host closed the connection]
castiel652 has quit [Quit: Leaving]
danitool has joined #openwrt-devel
goliath has joined #openwrt-devel
shoragan_ has joined #openwrt-devel
shoragan is now known as Guest933
shoragan_ is now known as shoragan
csrf has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest935
floof58 has joined #openwrt-devel
Guest935 has quit [Ping timeout: 480 seconds]
ephemer0l has quit [Ping timeout: 480 seconds]
pepes has quit [Quit: WeeChat 3.5]
minimal has joined #openwrt-devel
<karlp>
so, kernel people replied that if you're using gpio cdev, you should leave the v1 interface enabled in kernel config, even though it defaults to off, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1953613 is there an easy way to make that magically do the right with via he DEPENDS:=@GPIO_SUPPORT?
<karlp>
or can the config be enabled globabbly and if gpiolib isn'
<karlp>
t turned on, it won't have any impact?
<karlp>
I'm not enough of an expert on how kernel options work like that.
<karlp>
I know I can do it for my own builds with make kernel_menuconfig, but that won't fix things for anyone else?
f00b4r0 has quit [Quit: brb]
robimarko has joined #openwrt-devel
Guest933 has quit []
f00b4r0 has joined #openwrt-devel
<stintel>
karlp: the help text for GPIO_CDEV_V1 is not very clear about this. but looking at v5.15.77 sources, the symbol has default y so I'd say we should just enable it globally
<stintel>
how to pull that off is another story
<stintel>
well not globally, but for all targets that enable GPIOLIB
<stintel>
that's gonna be fun
<stintel>
maybe a new option in config/Config-kernel.in that depends on GPIO_SUPPORT (gpio in features)
<stintel>
it would also allow people to disable it individually
<stintel>
maybe even GPIOLIB could be moved there, default y if GPIO_SUPPORT, and remove it from all the target configs
<stintel>
because right now it's really error prone, you could enable feature gpio for a target, then forget to enable it in the target kernel config
<stintel>
(iiuc)
<stintel>
someone please correct me if wrong :)
<karlp>
yeah, I've currently just made CDEV_V1=y, in generic kernel config.
<karlp>
iiuc, unless a target enables GPIO_CDEV itself, that should have no impact?
<stintel>
actually I just notice GPIO_CDEV_V1 depends on GPIO_CDEV
<karlp>
yeah, that's what I was reliying on.
f00b4r0 has quit [Read error: Connection reset by peer]
f00b4r0 has joined #openwrt-devel
<karlp>
it's built ok here, with sunxi/config-5.15 having CONFIG_GPIO_CDEV=y and generic/config-5.15 having # CONFIG_GPIO_CDEV is not set and CONFIG_GPIO_CDEV_V1=y ?
<stintel>
karlp: all those symbols are hidden behind GPIOLIB
<karlp>
so it's "worked for me" at least by adding V1=y to generic.
<stintel>
so if a target doesn't enable that, I would expect it to have no impact
<karlp>
where do you see it as v1 being y by default?
<stintel>
karlp: kernel source
<karlp>
it sure didn't work until I manually enabled it.
<stintel>
karlp: this is from kernel pov, not openwrt
<stintel>
in openwrt it's disabled
<stintel>
what I meant earlier is that because it's default y in kernel 5.15 I think it's fine to follow that in openwrt
<karlp>
so it was only "off" for me out of the box, because generic/config-5.15 had it as " is not set" ?
<karlp>
and "someone" had manually done that somewhere?
<karlp>
how would that have happened, it appears to be default=y since it came in in 5.10 and is still default=y in 6.1?
<stintel>
it's disabled in openwrt generic configs, this overrides kernel's default y
<stintel>
karlp: the main reason I went for this approach is that it actually makes the gpio feature a bit more useful, by actually enabling GPIO support in the kernel. right now it's super confusing, you can FEATURES+=gpio, then in the same target # CONFIG_GPIOLIB is not set and it would not have gpio. at the same time, once libgpiod support the new ABI we can just change KERNEL_GPIO_CDEV_V1 from default y
<stintel>
to default n
<f00b4r0>
eventually I will. But I don't want to run off-tree
<\x>
ah, youre device didnt get the dsa treatment I guess
<\x>
your*
<f00b4r0>
nope
<stintel>
and it avoids confusing things like GPIO_CDEV=n and GPIO_CDEV_V1=y in the same generic config
<\x>
i say just try to move tx and rx to differing cores
<\x>
maybe itll do something
<f00b4r0>
yeah I'll poke around
<karlp>
tmn505: nominally yes, but no release, a single giant commit, zero downstream testing, I'd hardly see it as relevant yet.
<karlp>
stintel: yeah, I like the main top level bit you did with the feature gpio not requiring manual GPIOLIB config.
<karlp>
and given that CDEV and CDEV_V1 both depend on gpiolib, there's no "confusion" with CDEV=n and CDEV_V1=y, you just have both =y in generic?
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<karlp>
but I mean, hey, your way works, jsut seemed like more work :)
<stintel>
haha :P
<karlp>
do you want me to pull that series and send your a tested-by? will you take it from there?
<karlp>
I can only test it on sunxi right now though.
<stintel>
yeah that sounds like a good idea, I tried to abuse github CI but it would require me to do a PR, it doesn't work in my local fork apparentkly
<Habbie>
for packages, the github CI infra requires a useful base branch so it knows what to build against - you may be able to override this
<Habbie>
(but I just PR to my own repo)
<Habbie>
for non-packages, this might be similar, or not
<stintel>
it's looking for container ghcr.io/stintel/tools:latest
<stintel>
instead of ghcr.io/openwrt/tools:latest
<Habbie>
ah, that's a different problem than in packages :D
<stintel>
maybe we should hardcode that instead of using variable
<stintel>
karlp: I'd send it to the ML for review also but I'd like to run it through CI at least
<stintel>
I'll just do a PR
<stintel>
github is a trashcan already anyway
<karlp>
aight, buildig locally here, but I've got lunch and some offsite shits later, will let you know this afternoon how it went here :)
<stintel>
enjoy!
<karlp>
I'd add to the help text here: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commitdiff;h=792ae6ca9e29cf56ea4f305c95aac87ed99adb92
<karlp>
that this is automatically enabled by your target if it has teh FEATURE flag "gpio" ?
<stintel>
makes sense
<stintel>
karlp: CI already failed ;p
<stintel>
Character device (/dev/gpiochipN) support (GPIO_CDEV) [Y/n/?] (NEW)
<karlp>
oh, I just did make menuconfig and they all showed up nicely and with * for them, but I guess menuconfig already autoaccepted them...
<stintel>
looks like it's for targets not enabling gpio feature
<stintel>
maybe a side-effect of removing CONFIG_GPIOLIB=y from generic config
<stintel>
I'll let CI finish first before drawing conclusions
castiel652 has joined #openwrt-devel
clandmeter has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
danieli has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
clandmeter has joined #openwrt-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Ansuel>
o/
<castiel652>
o/ Ansuel
MaxSoniX has quit [Quit: Konversation terminated!]
lemmi has quit [Remote host closed the connection]
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
<karlp>
stintel: well, your series works fine here on sunxi...
<karlp>
Tested-by: Karl Palsson <karlp@etactica.com>
<karlp>
I have not tested all options exhaustively though
<stintel>
thanks karlp, however I'm going to have to revise it
<stintel>
the problem in CI comes from removing CONFIG_GPIOLIB=y from generic - some targets didn't have CONFIG_GPIO_CDEV while still using GPIO_GENERIC e.g.
<stintel>
but I guess those targets should also get FEATURES+=gpio
<karlp>
soundsd like it, yes?
<stintel>
makes me wonder what the usefulness of this feature is, if it's lacking on several targets without issues
<stintel>
maybe this is a legacy thing, do we even have targets left that don't have GPIO enabled at all
<karlp>
probably not, even x86 has it for qmeu stuff, and leds, I can't imagine what target doesn't have it...
<karlp>
but the pixel peepers might like to turn it off to save space :)
<stintel>
I'll sit on it for a bit
<karlp>
I'm not deploying today, it's ok, now that I have a workaround... :)
<stintel>
as it's currently in kernel configs it requires kernel_menuconfig or a variant of that anyway
<karlp>
realtek wifi and bluetooth are goign to give me more pain...
lemmi has joined #openwrt-devel
<stintel>
:P
<karlp>
you've used sunxi in the past, what's the general goal with sysupgrade? how's it emant to work?
<stintel>
unfortunately I've not gotten that far yet
<stintel>
the only thing I've done with sunxi is dd to sd via workstation then try boot that in the device
<karlp>
ah, yeah, that works fine.
<karlp>
my "upgrade" procedure at the moment is reboot to uboot, then "ums 0 mmc 1" and dd to the gadget disk that pops up, but that's a pretty big hammer :)
<stintel>
I got a pair of olimex olinuxino to investigate if they could be a raspberry pi alternative, the raspberry pi I currently have are operational, not really need replacements atm, it's more out of idealism, but as such low prio
<stintel>
spreadsheet to the rescue for figuring out some GPIO stuff :P
<soxrok2212>
apparently it boosts tx power/controls FEM> idk
<Ansuel>
and set high clk freq
<Ansuel>
or even just set performance gov
<Slimey>
lol turbo button
<Ansuel>
mhhh boosting tx power = against reg domain
<Ansuel>
aka they will brake in your house in china i think
<soxrok2212>
good thing im not in china
<Ansuel>
imagine having that thing on your desk
<Ansuel>
"My internet is slooow" "let me push the turbo button" "WOOOOOOOOOOW"
<soxrok2212>
LOL
<soxrok2212>
i think there's going to be issues with the 2.5g chip though
<Slimey>
back in the day your PC had a fast CPU so if you had a program that ran too fast you would have to turn off the trubo to lower the clock rate so the application would run correctly
<Ansuel>
but if something in build-base change than every child should be refreshed
<Ansuel>
(but yes i like the idea since that way we can stop caching toolchain tar and cache ccache
<stintel>
let's see if I can come up with a PoC by next meeting :)
<Ansuel>
also if we plan to make everything public i think it's a good idea to hardcode our container and disable container build for forked project (as I'm noticing some complain about that)
<stintel>
did you ever hit Error opening terminal: unknown. ?
<stintel>
tried ENV TERMINAL=linux in the Dockerfile but doesn't seem to help
<stintel>
happens during make tools/install
minimal has joined #openwrt-devel
<Ansuel>
mhhhh nope didn't encounter it but shell on the buildbot container is ""strange""did you tried with the TERM env ?
<Ansuel>
export TERM=xterm
goliath has joined #openwrt-devel
Borromini has joined #openwrt-devel
<stintel>
wait am I so stupid to mistake TERM for TERMINAl
* stintel
slaps himself
<stintel>
quick grocery run, bbiab
<Ansuel>
anyway something we should for real investigate is a way to build every kernel package... i don't really like the current approach of build everything as we are building stuff multiple time
<Ansuel>
aka check if we can create some define to build just kernel packages and nothing else
f00b4r0 has quit [Quit: brb]
<Ansuel>
anyway working on ipq806x is getting problematic... currently the 2 linksys device are broken for an unknown reason but they can't be found online...
<Ansuel>
i see buying a device the only way to fix them and waste good time to bisect all the kernel version...
<Ansuel>
(i don't think an user would like to test 5 kernel version and check when it broke)
<Borromini>
Ansuel: on 6.1? or 5.15?
<Ansuel>
5.15
* Borromini
only has a few ipq40xx devices and only one for testing
<Ansuel>
every other device works... but it seems linksys did some strange tweak
<Ansuel>
and that thing broke on with 5.15 kernel version...
<Ansuel>
i should prepare 5 image to make that user test... i already have the meme of openwrt supporting 5.11 12 13 14 LOL....
<Ansuel>
so not impossible but annyoing for the user
<Borromini>
:P
<Mangix>
Ansuel: mt7622 CPU is 2.5gbps ues
<Mangix>
The WAX206 has an interesting setup. 2.5gbps CPU port connects to a realtek 2.5 gbps PHY. mt753x to the 1gbps CPU port.
<dwfreed>
> realtek
<Ansuel>
honestly i have never ever tought seeing realtek switch on consumer router and even supported on openwrt lol...
<Ansuel>
what is next intel? broadcom ?
<Mangix>
Broadcom switches are supported.
<Ansuel>
mhhh even all the offload stuff?
<Mangix>
Probably. Broadcom supplied/develops the upstream driver.
<stintel>
ah welp, TERM=linux now opens menuconfig 😂
<Ansuel>
:D
<stintel>
I should run make defconfig first
<stintel>
weird though that this is required for make tools/install
<Borromini>
Ansuel: this is no Realtek switch though :)
<Borromini>
just a PHY
<Ansuel>
>:(
<Mangix>
Switch on the WAX206 is gigabit
<Ansuel>
stintel probably cmake or ninja require some strange stuff to have fancy complilation progress stuff ?
<Mangix>
I'm guessing realtek PHY is cheaper than Aquantia :)
<Borromini>
prolly
<Mangix>
Aquantia NICs are interesting. They have firmware updates
<Ansuel>
pro and cons with that
<Mangix>
Hmm?
<Borromini>
the Realtek multigig switches have Aquantias onboard afaik
<Ansuel>
Mangix another fw blob to care
<Mangix>
Hmm? Doesn't it get flashed to the NIC?
<stintel>
maybe the NIC, maybe the NOR, maybe the NAND, OEMs will do weird things :P
<Ansuel>
or nothing at all and it needs to be loeaded every time
Tapper has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
<nbd>
fyi, i've updated mac80211 in my staging tree to 6.1-rc4
<Ansuel>
i should update my pr to 6.1-rc4...
<rmilecki>
Ansuel: what Linksys models broke with 5.15?
<Ansuel>
ea7500 and ea8500
<hauke>
Ansuel: maybe some user does not need his device any more and would send it to you as a gift
<Ansuel>
mhhh don't know i would love to fix without user sending me ""gift"" for breaking devices ahahaha
<Ansuel>
well nice the user said he can test the various images... now i just need to compile them...
<stintel>
imagine creating a CI for bisecting that spits out images for all commits between X and Y :D
<robimarko>
nbd: Thanks
<dwfreed>
stintel: that'd be handy
<robimarko>
Ansuel: Well, its getting rather crazy with only certain devices getting broke and no hw
<dwfreed>
and also really not difficult to do either
<Ansuel>
stintel means adding support for each kernel version only someone like me can think of doing that instead of doing correct tools like a buildroot...
<Ansuel>
robimarko still convinced there are some reset stuck and the switch is just dead
<Ansuel>
and coicinentally the reset are only connected on the 2 linksys device
<Ansuel>
dwfreed problem is the generic/hack dir
<Ansuel>
robimarko right i didn't think of the fact that it may be that the bootloader is applying some strange regs and with new kernel we are just clearing that...
<stintel>
I don't understand why AUTOREMOVE is needed
<stintel>
it would probably be a good idea to document this in comments of the pipeline config
<stintel>
right now I'll do it in commit messages locally and then when I start cleaning up / squashing commits I'll translate that to comments in the pipeline files
<rmilecki>
nbd: ^^ check all those buildbot fails for build commit revert
<rmilecki>
Ansuel: thanks for handling that
<rmilecki>
Ansuel: it seems I may get that 7500ea / 8500ea if really needed in Poland (costs a bit though)
<rmilecki>
Ansuel: let me know if you can debug that regressions
<rmilecki>
*ssion
<Ansuel>
stintel AUTOREMOVE is needed as the stamp generation logic change with that config and reproducible
<Ansuel>
i didn't apply this logic globally as it may cause perf regression and extra build time
<Ansuel>
rmilecki currently my idea is to build an initramfs image for each kernel from 5.10 to 5.15 and hope that things are not broken from 5.11 and up...
<Ansuel>
there is one user that can help with that so i hope we don't need to waste some money on overpriced hw
<Ansuel>
stintel (i skipped a pieace with AUTOREMOVE the stamp is reproducible as it's generated based on the has of the hash of each package file)
<Ansuel>
currently the stamp is generated based on the time of the package file and that change with each git clone
<slh>
the problem with getting an ea7500, would be getting rev1 (ipq8074x), not rev2 (mt7621a)
<hauke>
stintel: why do these servers have only SATA / SAS interfaces and not a lot of M2 interfaces for storage?
<slh>
and yes, they've been barely sold in Europe, so hard to get - not for a reasonable price
<slh>
hauke: probably because of the hotpluggable SATA bays in the front (you don't want to take a server out of the rack, just to replace a faulty drive)
<hauke>
ok, but NVMe is much faster than SATA
<zorun_>
U.2 is starting to become more common (it's hot-pluggable NVMe)
<dwfreed>
generally storage performance isn't as much of a concern as large amounts of it
<zorun_>
depends on your use-case
<dwfreed>
and large amounts of SAS is a lot cheaper than large amounts of NVMe
<stintel>
all valid points, there are U.2 models available if you want NVMe speeds
<hauke>
ok
<stintel>
but for me it's mostly because I have SAS SSDs and HDDs and I'd move them into this new server
<stintel>
so that's why I'm looking at models with SAS/LFF backplane
<f00b4r0>
stintel: buying refurb is always an option :)
<stintel>
yeah
<stintel>
anyway I should probably wait until I know if I'm part of the layoffs or not :P
<olmari>
Sidenote from adhoc commenter: also in broad general storage best compromise is is shitton of spinning rust, few quick-e-mart SSD, enough ram for context and then ZFS or some other similar FS to cater it awesomely
<stintel>
I'm getting excited to try bcachefs again
<olmari>
Rarely "NVMe speeds" are needed anywhere near 100% workload
<stintel>
marketing ;)
<olmari>
So few nice caching ssd to take in the spikes (and still be exactly sync writes), let em flow to spinning rust when time availbale (which is bulkload of actual timeø
<olmari>
Sure, plenty places offers all ssd things, with all ssd prices, so yeah...
<olmari>
Also, ofcourse YMMV etc, not all shit is same
goliath has quit [Quit: SIGSEGV]
mcbridematt has joined #openwrt-devel
Mathew has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
minimal has quit [Quit: Leaving]
<Borromini>
we got 2x 1TB NVMe here but the storage needs aren't huge
<Borromini>
then again with 10 GbE it's a bit silly to stick to S-ATA.
<Slimey>
heh
<Borromini>
always a bottleneck somewhere right? :^)
<stintel>
;)
robimarko has quit [Quit: Leaving]
<Borromini>
stintel: hope you don't get laid off. Sucky times.
<Borromini>
i don't think i could have sold my brother on a U.2 server, I already went way overboard with his present setup >_>
<stintel>
:P
<stintel>
Borromini: thanks, not that worried, many companies have a hard time finding qualified people, I suspect there's going to be a big shift
<stintel>
would also be an excuse to take a sabbatical and travel a bit
<Mangix>
mediatek ethernet performance. cool.
floof58 is now known as Guest991
floof58 has joined #openwrt-devel
Guest991 has quit [Ping timeout: 480 seconds]
<Borromini>
stintel: good :)
* Borromini
is out
<Borromini>
night gents.
Borromini has quit [Quit: leaving]
<Mangix>
nbd: BSD can compile OpenWrt?
<dwfreed>
maybe in a linux jail
<dwfreed>
but I wouldn't really call that BSD anymore
<Mangix>
oh the commit is probably talking about macOS
<Habbie>
if it can be done on macos, surely bsd would not be a stretch
<Mangix>
last I tried FreeBSD it needed a bunch of patching