marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
mtjzh has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi
eroux has joined #asahi
eroux has quit [Ping timeout: 480 seconds]
mtjzh has joined #asahi
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
ElvishJerricco[m] has joined #asahi
eroux has joined #asahi
eroux has quit [Ping timeout: 480 seconds]
eroux has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eroux has quit [Ping timeout: 480 seconds]
<coolshaurya>
#flameshot-org:matrix.org
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
eroux has joined #asahi
eroux has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi
eroux has joined #asahi
maman has joined #asahi
marvin24 has joined #asahi
maman has quit []
marvin24_ has quit [Ping timeout: 480 seconds]
<Glanzmann>
kov: I also recall that once bullseye had a working trackpad. But it might be that with the new spi code, it requires a newer libinput. But good that it works for you.
the_lanetly_052 has joined #asahi
eroux has quit [Ping timeout: 480 seconds]
eroux has joined #asahi
eroux has quit [Ping timeout: 480 seconds]
AstaraOS has joined #asahi
* AstaraOS
hi all skraito here how are ya all ?
* AstaraOS
what you guys up to ?
* AstaraOS
hey mind to do some coding advise at channel #0dev , let me know if anyone interested , lets code together
<i509VCB>
might be a bot? saw the same message on #_oftc_#wayland:matrix.org
eroux has joined #asahi
<AstaraOS>
<AstaraOS> yeah actually i am trying to break tor
<AstaraOS>
<arma> ah ha, i see that you have spammed every channel. definitely the wrong place.
<AstaraOS>
<AstaraOS> anyway if i know all node
<AstaraOS>
<AstaraOS> whwat is it that this tor is super bitcha anyway ?
<AstaraOS>
<AstaraOS> i just need to block all node
<AstaraOS>
<AstaraOS> if you go with server less
<AstaraOS>
<AstaraOS> people can block too
<AstaraOS>
<AstaraOS> client -- > server ?
<AstaraOS>
<AstaraOS> that's why in my opinion tor is stupid
<AstaraOS>
<AstaraOS> i don't even need the node
<AstaraOS>
<AstaraOS> just first node
<AstaraOS>
<AstaraOS> and last node
<AstaraOS>
<AstaraOS> if you encrypt it between middle
<AstaraOS>
<AstaraOS> i would rather
<AstaraOS>
<AstaraOS> use proxy
<AstaraOS>
<arma> ok. off you go then. please do not clutter up #tor.
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_lanetly_052 has joined #asahi
<j`ey>
Glanzmann: if you mean 16k, it was tpw_rules
<j`ey>
Im not sure if Debian can do much here
<Glanzmann>
j`ey: I see, thanks. Do you happen to have the url for the patch?
<Glanzmann>
j`ey: I can file a bug report and attach a patch, than it is at least documented. They can also address it upstream and other users have at least workaround.
<j`ey>
nop
<Glanzmann>
tpw_rules: Do you still have the chromium 16k patch?
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<Glanzmann>
jannau / j`ey: What will our way forward be? Will we stay on 16 KB page size for perfromance reason or do we end up using 4 KB page size at some point?
<j`ey>
Glanzmann: moving to 4K cos thats what distros ship
<jannau>
I will use 16k for 10% faster compile time (kernel compile time measured wit kcbench onthe macbook pro 14" p-cores running at 2GHz)
<jannau>
but I'm not the typical user
<j`ey>
I may stay at 16K too, but getting distros to ship it is unlikely
<jannau>
we should not give up before even trying
<jannau>
but I would suggest to wait with filing bugs for distrobutions. I suepect the majority of issues require some interaction with the upstream project
<Glanzmann>
I think I'll also stay ok 16k.
<Glanzmann>
I don't care about chromium, but I prefer to file the bugs now, so that they can be addressed before the next Debian release.
<jannau>
either fixing issues there or add build config options
<j`ey>
jannau: are you going to continue using arch?
<jannau>
I would wait filing issues until we have a convenient way for distro maintainers to fix the issue
<Glanzmann>
And even if they dismiss the bugs at wontfix the workaround is at least documented.
<jannau>
it does not make sense to file the same bug for X distros while it's still hard for them to fix it
<Glanzmann>
jannau: The only thing from Debian missing besides the kernel is the ability to tell grub during installation to use removable media path and not update the nvram. Two options that the normal package already has.
<j`ey>
better to file upstream and keep a list of bugs on the asahi wiki?
<Glanzmann>
j`ey: Yes, probably.
<jannau>
and in the case of a fix which can go into the upstream project, there might not even a need to bother distros with
<Glanzmann>
yep, that's true.
<Glanzmann>
jannau: So you also run at 2GHZ pcores? You don't have the m1n1 crank up patch? :-)
<jannau>
j`ey: I will probably stay on arch in the beginning to help with the asahi linux reference distro testing
<Glanzmann>
I thought about writing a guide to setup arch.
<Glanzmann>
And one to setup OpenBSD.
<j`ey>
jannau: very helpful of you!
<Glanzmann>
jannau: What is your distribution of choice?
<jannau>
Glanzmann: I know what I have to change but I don't wnat that on the macbook. since yesterday thanks to the push by axboe I have a cpufreq driver if I would use the macbook productively
<jannau>
Gentoo
<Glanzmann>
I see. Btw. Does the interrupt firing bug also affect the m1 (not max/pro) models?
<jannau>
I think it affects only systems with magsafe, on the air and 13" macbook pro none of the ports will probe a tps6598x driver so the interrupt never gets enabled
<sven>
if usb hotplug works the interrupts are fine fwiw
equiomax[m] has joined #asahi
<mps>
I built kernel for mediatek mt8173 (arm64) with 16K pages to test how it works, but it doesn't boot even, so I think distros will 'stick' to 4K
<mps>
I'll test next week also 16K kernel on rk3399 to see will it work
<j`ey>
mt8173 is cortex-a72, doesnt support 16K
<j`ey>
rk3399 too, it wont work
<j`ey>
if distro ship, it'd be separate 4k, 16k kernels
<mps>
j`ey: distros like one kernel per arch
<mps>
j`ey: yes I know but anyway wanted to test 16K on them because I'm too much curious
<j`ey>
right, which is why they would take some persuading to do 16k :)
<mps>
sometimes things known to not work with some options if time pass start to work
<j`ey>
the cortex-a72/cortex-a53 CPUs don't support 16K, it's a hw thing, not a software thing!
<mps>
for example yesterday I got u-boot to load compressed kernel on rk3399 though known fact was it doesn't work ;)
<jannau>
persuading them to fix packages to run under a 16k kernel is hopefully much easier than shipping a 16k kernel and is anyway needed as first step
<j`ey>
and hopefully theres not too many packages to fix anyway
<jannau>
good luck persuading them to ship a 16k kernel if 2% (but high profile) packages are broken
<jannau>
yes, I think my random 2% number is probably way to high
<kov>
jannau, where do I find this cpufreq you speak of?
<Glanzmann>
sven: I see, hotplut works.
<sven>
then there’s also no irq storm issue
<Glanzmann>
kov: Probably look at the backlog of dev from yesterday. IIRC the cpufreq driver is from marcan (old one) and some small device tree updates from axboe. But I have no idea if it works for m1 (not pro/max) machines.
<kov>
jannau, ah, nice, will add it to my config thanks
mtjzh has joined #asahi
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi
<Glanzmann>
jannau: Thank you for the instructions on the cpufreq driver, I rebased it on top of smc/work. And it works. mps. If you want to pick that up. Do not forget to update the device tree in u-boot. https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian
<Glanzmann>
I did it by doing 'git format-patch -9' in the cpufreq/v1 branch, than using git am -3 /path/to/patch and resolving the issues manually and reexporting them with git format-patch -9.
<tpw_rules>
last i checked the built chromium only worked with the flags --in-process-gpu --no-sandbox --no-zygote but that may have been a kernel config problem
<Glanzmann>
tpw_rules: Thank you. I'm a firefox user after the apis for u-block origin were removed. But I'll write it down.
<Glanzmann>
j`ey: Okay I'm over cpufreq patch. So removing the power-domains = mmc did not do the trick for me, hangs again.
* kov
also decided to wait
mtjzh has quit [Remote host closed the connection]
<Glanzmann>
kov: Have you tried it?
<Glanzmann>
I mean m a r c a n wants to rewrite it anyway. Than I'll pick it up again.
<kov>
Glanzmann, I did, same problem as you I'm afraid, I thought it could be something I was doing wrong, but since you hit the exact same problem...
<jannau>
removing the power-domains fixes a crash on t600x, to avoid the missed nvme interrupts all mcc related bits from the cpufreq dts change needs to be removed
<kov>
maybe some bad interaction between smc and cpufreq?
<kov>
I can try that
<jannau>
I haven't looked into it assuming it will be rewritten soonish. I need to work on keyboard/trackpad
<kov>
yeah, probably not worth it if it doesn't work out of the box tbh
<Glanzmann>
jannau: Never mind, I'll wait for the rewrite.
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
sheepgoose has quit [Ping timeout: 480 seconds]
<as400[m]>
jannau: I tried today and this 5s sleep in u-boot does the job. It boots correctly unless it stops on another error with reserving memory address.
<jannau>
as400[m]: did you try sven's patch? still strange that you're the only one seing this
<as400[m]>
jannau: but the error I pasted is from u-boot
<j`ey>
kov: thats confusing because webkit is from apple..?
<kov>
j`ey, yeah, but it has linux and windows ports and has different ceilings for those
<j`ey>
ah yeah, just looking at the patch now
<kov>
if you look at the comment, all apple ports are now using 16k for their ceiling
<j`ey>
I wonder if centos/RHEL patched this? since they had 64K kernels
<kov>
I also wonder, I'll try to find out, the first mention I've seen of chromium failing was actually on a bug that mentioned RH kernels
<kov>
I was trying to get an electron build going here for vscode, but I think it'll be easier to cross compile on x86 =/ the whole thing assumes x86-64
<j`ey>
run qemu-x86_64 on the m1 :p
<kov>
haha I think even the xps 13 will be faster than that ;D
<kov>
when linux and qemu with rosetta support
<kov>
but in the end, if there's no big impact on binary size (which seems to be their only motivation?) I think chromium will accept a change to 16k?
<tpw_rules>
i am not a chromium user and the submission process looked somewhat onerous, so i did not plan to
<tpw_rules>
it should probably be changed to 64k for RHEL
<j`ey>
RHEL switched to 4k
<tpw_rules>
i will try and test your patch to webkitgtk later
<kov>
tpw_rules, thanks! it worked with jsc and a couple apps that use webviews
<kov>
in my testing
<kov>
is there any other concern btw other than binary size?
<tpw_rules>
what distro do you use?
<kov>
I guess potential memory bloat, though that would be minimal I guess?
<tpw_rules>
i mean for chromium there is that comment about breakpad relying on segment size
<kov>
tpw_rules, I have debian on the m1 atm
<tpw_rules>
i don't really know what that means. i think breakpad is related to the crash dump infrastructure
<kov>
tpw_rules, but my daily driver has been fedora for a while, I'll try and install that later on
<tpw_rules>
ok. i think debian is still on like libunwind 1.3
<kov>
debian testing, let me check libunwind
<kov>
tpw_rules, yep, 1.3.2
qeeg has joined #asahi
chengsun_ has joined #asahi
chengsun has quit [Ping timeout: 480 seconds]
<landscape15[m]>
marcan: Why don’t you make the asahi installer showing the free space disk identifier? For those like me who have three free space instances.
* AstaraOS
anyone want openbsd source code ? releasing it now
AstaraOS has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2022-02-13 21:35:21)]
<Tramtrist>
ops pls...
<Tramtrist>
it's back..
<Tramtrist>
ok gone
<Tramtrist>
dont have joins/quits on so didnt realize
AstaraOS-- has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
AstaraOS-- has quit []
auwooo has joined #asahi
* auwooo
greeting all , how are you all ? night morning afernoon all , i have setup base here for United Nations , incase you need me just go to channel #astara and leave me a message , i will see your president from there , tell me which country are you from ... .
auwooo has quit [Remote host closed the connection]
<Glanzmann>
bauen1: The hooks from your website did not work. So I solved the issue by executing two scripts manually, one during start, and one when finished. See: https://tg.st/u/m1-d-i.mp4
<Glanzmann>
If someone has some hints how to improve, please let me know.
<Glanzmann>
The arm64 d-i can't create a 512MB or 1GB ESP partition because something is wrong with the fat32 cluster size. So autmatic partitioning fails.