marcan changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
_jannau_ has quit [Server closed connection]
_jannau_ has joined #asahi-alt
marcan has quit [Server closed connection]
marcan has joined #asahi-alt
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-alt
mps has quit [Server closed connection]
mps has joined #asahi-alt
psydroid[m] has quit [Server closed connection]
psydroid[m] has joined #asahi-alt
qyliss has joined #asahi-alt
GeorgeVassilev[m] has joined #asahi-alt
<GeorgeVassilev[m]>
I am in
<GeorgeVassilev[m]>
So I guess it just doesn't list it
<mps>
maybe matrix client issue
<GeorgeVassilev[m]>
It just wasn't listing it, but it's there
<mps>
maybe other users who can't connect will see your message how to connect with matrix client
as400[m] has joined #asahi-alt
<as400[m]>
mps: you changed default scaling governor on Alpine to schedutil, right ?
<mps>
as400[m]: yes
<as400[m]>
mps: with schedutil big cores do not go down as low as 600MHz
<mps>
some users have high temperature with performance governor
<as400[m]>
I'd go for ondemand - it's the best with current state of things
<mps>
as400[m]: as400[m]: they go
<mps>
ok, not
<mps>
but I change to conservative in boot scripts
<as400[m]>
for me machine is much cooler with ondemand
<mps>
did you tried conservative?
<as400[m]>
mps: no, I didn't
<as400[m]>
conservative should be the most reluctant with going up with frequency
<mps>
yes
<mps>
but not so often changing freq like ondemand
<mps>
I see it as ondemand with wider hysteresis
<as400[m]>
ok, I must try it. For me ondemand seems to do the job
<as400[m]>
unfotunately schedutil is still not in the place where it should be
<as400[m]>
*unfortunately
<mps>
both are ok, but I last two years I prefer conservative on workstations
<mps>
s/I/in/
<as400[m]>
well I must try it for sure
<as400[m]>
how is the temperature of the machine ? Is it cool ?
probie has joined #asahi-alt
<mps>
I changed to schedutil because alpine official kernels uses it
<as400[m]>
oh, ok - understandable
<as400[m]>
well, it doesn't even work properly on x86 :P
<mps>
hah, could be. for long time I didn't tested on x86
<as400[m]>
I did just recently. It's kind of disappointing after all these years
<mps>
as400[m]: hm, I will talk with Natanael, alpine linux-lts maintainer
<mps>
thanks for info
<mps>
psykose: what you think about this
<psykose>
about what
<mps>
default frequency governor for alpine
<mps>
I always prefer performance to be fast by default, but people ask for schedutil or ondemand
<psykose>
default kernel one is fine
<mps>
ok, thanks
<psykose>
then there are of course people that actually spend time reading phoronix benchmarks and start trying to rice kernel configs, but that is best left ignored :)
<psykose>
if people want something else they can merely pick it
<psykose>
it's a local.d script away to set at boot
<psykose>
for me i only have two options to begin with, performance and schedutil, since it's the only supported ones for amd p-state
<mps>
yes, local.d is solution for end users, but some are stubborn (not as400[m])
<psykose>
they would be in 6.0 i guess, not even in the 5.19 tree yet
<mps>
hmm, ah
<psykose>
(they are commited ofc, you can go track down the commits, just in latest git)
<psykose>
quite recent
<psykose>
because the bfd change is also from a week or two ago
<mps>
will look when return to home
<psykose>
take yer time
<psykose>
i have to fix bpftrace anyway
<mps>
(I knew adding it to linux-tools early could be problematic)
<psykose>
not in linux-tools
<psykose>
separate
<psykose>
the actual standalone one
<mps>
ah right, bpftool is in linux-tools
<mps>
sorry
ktz_[m] has joined #asahi-alt
<mps>
psykose: I think you are right, linux-tools follows linux-lts which is now 5.15.x
<psykose>
pretty sure it doesn't? they're just part of the tree
<psykose>
in arch for instance they are '5.19'
<psykose>
you can build them from any kernel tree
<psykose>
i would assume the changes do make it into each kernel release
<mps>
I know I can, but I wouldn't because ncopa will frown on me
<psykose>
what for
<psykose>
it's distinct
<mps>
he wants to follow linux-lts
<psykose>
and for the most part linux-tools are just where people get `perf` from :D it's not a mission critical package
<psykose>
but yeah makes sense
<mps>
usbip, cpupower, tmon, gpio, iio
<ktz_[m]>
personally I experienced a huge difference between the changes, both in terms of temps as well as performance. I remember firefox was pumping insane fps on testufo.com, not sure but iirc it was 120+ where now it struggles around 40-60. It was being paid with feeling like your silicon is fried but the performance was insane. It feels like alarm does now, on par performance as well as temp but having firefox being sluggish etc is kind of
<ktz_[m]>
offputting
<ktz_[m]>
psykose will get a m1/m2 soon I feel like hehe
<mps>
ktz_[m]: so machine is not hot now?
<ktz_[m]>
I think its on par with alarm
<ktz_[m]>
feels the same, runs kinda hot in day and can get even total cold on nights
<mps>
good
<ktz_[m]>
yes it improved quite a bit in terms of temp
<psykose>
what changes
<mps>
though keep in mind that when asahi branch merges to mainline that could be changed back to performance
<ktz_[m]>
bit offtopic, can anyone chime in whats missing in the regex? I'm trying to pick the id, 38
<psykose>
mps: upgrading to 5.19 isn't needed; it's still the same patch backports x)
<j`ey>
mps: ok ty
<ktz_[m]>
j`ey: woo lol
<ktz_[m]>
you guys flexing
<j`ey>
oh psykose already answered!
<psykose>
has the dot tho
<j`ey>
mine doesnt!
<psykose>
i mean mine
<psykose>
someone should put a machine readable output into wpctl
<ktz_[m]>
I'm having trouble even wrapping my head around j`eys answer :))
<psykose>
just gets the first match group in $1 inside the ()
<mps>
psykose: about linux-tools, do what you think is best, so I don't have to dive in it :)
<psykose>
sure thing
<mps>
(I'm busy with some things refactoring and testing)
<psykose>
mhm :)
<ktz_[m]>
haha yes sure thing, like half aports :))
<ktz_[m]>
ok I'm out guys, god bless you all
<mps>
have to upgrade alpine on m1 guide, create new boot img, fix u-boot-asahi
<ktz_[m]>
glad to hang around
<mps>
(and fix some chromebooks)
<ktz_[m]>
mps: nice
<ktz_[m]>
Btw, once I tried to run a kernel with the exact same configs as alarm and it wouldn't boot cause it couldn't find the partition with the specific id and I'm wondering is there any fs that could be missing in the config? I'm trying to narrow down my kernel config and I'm not sure if I can disable all the filesystems that I'm not using in case my assumption is correct, anyone got an opinion to share?
<ktz_[m]>
btw mps consider using udev instead of libudev-zero, I'm sure many people will be running into quirks with their devices and if they aren't as literate it can be pretty painful
<mps>
ktz_[m]: that is why I set FS drivers to be built in kernel, not as modules
<ktz_[m]>
yeah, which one in particular is being used? squashfs or?
<mps>
ext4 for now, but I also set btrfs
<ktz_[m]>
so using only ext4 and nothing else won't make it break? then it's some other configuration alpine does differently
<mps>
so rootFS on one of these is 'sure work'
<mps>
everything needed to boot is set in-kernel
<mps>
I don't use initramfs
<mps>
caveat is if you use UUID for root in grub it will not work
<mps>
but PARTUUID will work
<mps>
ktz_[m]: about eudev, apk add eudev, apk del libudev-zero
<ktz_[m]>
still not sure what is the particular configuration I need to change for it to run with the alarm config
<ktz_[m]>
mps: yes I got everything setup after spending a bit of time learning what is what, I'm talking more for other similarly 'casual' users
<mps>
I looked at alarm config but except FS don't see anything of important to set for alpine
<ktz_[m]>
I had lots of problems showing up by libudev-zero, I remember another user having troubles as well
<ktz_[m]>
I'm sure people who know whats up can replace udev if they like
<ktz_[m]>
but going the other way around for not so knowing users is more difficult
<ktz_[m]>
yes, I got everything setup exactly as I need atm, I'm talking for others
<ktz_[m]>
users in general
<mps>
ah, I usually wait for someone to have issue and then look what is the problem, not in advance
<ktz_[m]>
there are definitely issues with many devices, I've had many different peripherials missbehaving, I'm sure its been an issue for others as well, no doupt
lucus has joined #asahi-alt
<ktz_[m]>
and most people won't actually go out any complain to the maintainer, just go with it or try to fix it or migrate to another distro
<ktz_[m]>
gentoo is using udev too atm, libudev-zero is almost unmaintained, check the repo
<mps>
I know this, but I use libudev-zero without problems
<mps>
so I have one less daemon running
<qyliss>
ktz_[m]: what maintenance do you think that libudev-zero needs that it isn't getting, ooc?
<qyliss>
I've always just thought it's the sort of thing that doesn't need much maintenance — it's not like there are issues piling up that aren't getting fixed, and when I have had issues they've been fixed.
<ktz_[m]>
qyliss: you're most likely right and it isn't an issue of libudev-zero in particular, just everything being dependant on udev etc. They got a list of things not working in their readme so its less usable in general
<qyliss>
yeah that's true, it doesn't work for everything
<ktz_[m]>
I'm not knowledgable enough to judge what they're doing, I learned what udev and the likes actually are recently so
<ktz_[m]>
just sharing how I've experienced things as a more casual user
<psykose>
iirc pipewire doesn't work with it either
<qyliss>
yeah that's one of the things mentioned in the README
<psykose>
indeed
<ktz_[m]>
yes, you need to patch pipewire in order to work with libudev-zero
<ktz_[m]>
I think it just works with udev tho, at least does for me atm
<ktz_[m]>
I had many problems with libudev-zero, my soundcard for example wouldn't get recognized until I unplugged/replugged the cable in each reboot, ethernet device wouldn't load properly on boot and I always needed to restart the networking service after, I never got any android phone to actually pop-up, my wireless adapter wouldn't get recognized etc
<ktz_[m]>
maybe I needed to add couple of simple rules, just needs a bit of time getting comfortable with the stack
<qyliss>
the first issue is likely due to not rebroadcasting events (mdevd needs -O4 to do this, not sure about e.g. mdev)
<qyliss>
just to get you a little further if you ever look at it again :)
<ktz_[m]>
wish I can be as care-free in the future so I have the privilege of putting my time into things like this :) I enjoy it thoroughly not gonna lie, its just that I could be putting my time into more important stuff as its not our everyday times apparently
<ktz_[m]>
thanks for your input anyhow
<mps>
only what didn't worked for me is usb-modeswitch, but fixed it with script, and I don't use pipewire
<ktz_[m]>
yes I'm sure any issue you run into is kind of trivial for people like you to get around, most people will be forced to either spend a good amount of effort and time getting up to speed with things to tackle with it. I think setting udev as a default makes more sense for the average user, hackers like you can do w/e they please anyways hehe
bluetail has quit [Read error: Connection reset by peer]