babble has quit [Remote host closed the connection]
babble has joined #asahi
pi1 has joined #asahi
<pi1>
hi. is it possible to test asahi on an m1 mac without destroying the native installation?
<tpw_rules>
yes, in fact you shouldn't touch the native installation
<pi1>
so the installer will help me create a dual boot setup or>
<tpw_rules>
yes
<tpw_rules>
dual boot is the only supported setup
<pi1>
i'm highly skeptical of installers after messing with the debian one last week
<tpw_rules>
which one?
<pi1>
so i want to be absolutely 100% sure i undersatnd everything before trying asahi
<tpw_rules>
afaik, debian on m1 is all manual. but that's kind of a problem if there is a broken automated installer
<pi1>
no i mean on x86
<tpw_rules>
ah ok
qeeg__ has quit [Remote host closed the connection]
<pi1>
i was testing the installer in a vm with varying amounts of memory. the behavior was somewhat inconsistent.
qeeg__ has joined #asahi
<tpw_rules>
the official asahi installer is pretty much completely safe. i think still the only reports i've seen of people who severely broke their machines are people who messed up with a partition editor once they got linux installed
<pi1>
so i wouldn't be surprised if i ran the asahi installer and it wiped my m1 install. that's just how things are in linux land
<pi1>
ok
<pi1>
your confidence is reassuring
<tpw_rules>
no, it's very straightforward
<tpw_rules>
but it's always good to have backups ;)
<pi1>
frankly my opinion of computing is so low i consider backups mandatory.
<pi1>
but thanks i will investigate further. is the wiki good?
<tpw_rules>
i don't think it's super relevant to an ordinary user
ptudor_ has quit [Read error: No route to host]
<pi1>
ok
<tpw_rules>
btw if you do severely break your machine, you'll need access to another one and a usb cable with at least one C end to restore the mac. the other machine can be a VM and/or run linux (not sure about windows).
<nicolas17>
that's an interesting question, idk if anyone has tried it on windows
babble has quit [Read error: Connection reset by peer]
<pi1>
would a laptop running linux suffice? or maybe a bsd?
<tpw_rules>
i'm not sure about a bsd either, but yes anything running linux should work
<tpw_rules>
i've thoroughly tested running idevicerestore from computers and VMs with linux and macos and aarch64 and x86_64 cpus
<tpw_rules>
(and wrote a guide)
ptudor has joined #asahi
qeeg__ has quit [Remote host closed the connection]
qeeg__ has joined #asahi
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tpw_rules>
looked through the wiki and it is actually pretty cleaned up and good looking now
<tpw_rules>
at least check out the FAQ
nicolas17 has quit [Quit: Konversation terminated!]
nicolas17 has joined #asahi
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi
jjleahy has joined #asahi
jjleahy has left #asahi [#asahi]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #asahi
qeeg__ has quit [Remote host closed the connection]
<amw>
Mine are out of order - should I worry and try to re-order them (sounds bit dangerous) as I haven't been bitten by anything yet.
<tpw_rules>
afaik "don't like" is limited to displaying incorrect info
<tpw_rules>
i don't think any of them will actually mangle data but i'm not convinced
<tpw_rules>
in any case it's an easy operation to fix, assuming you used something other than partition numbers in your fstab
<tpw_rules>
you can also do sgdisk --sort /dev/nvme0n1
doggkruse has joined #asahi
qeeg has joined #asahi
qeeg__ has quit [Read error: No route to host]
mini0n has joined #asahi
<amw>
tpw_rules: Thanks - that worked - step 1. switch to labels, step 2. sgdisk (step 0 was installing sdisk package for sgdisk!)
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ry_Darcy has joined #asahi
Ry_Darcy has quit [Quit: Page closed]
Rame has joined #asahi
nicolas17 has quit [Remote host closed the connection]
nicolas17 has joined #asahi
mini0n has quit []
rvalue has quit [Remote host closed the connection]
rvalue has joined #asahi
nicolas17 has quit [Quit: Konversation terminated!]
L1Q has joined #asahi
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_lanetly_052 has joined #asahi
guillaume_g has joined #asahi
<maz>
amarioguy: maintenance interrupts have always been supported, even on M1, and I've always seen them firing. They are simply not represented as a Linux IRQ, but we don't care about that for KVM.
<maz>
all we need is for the FIQ to fire and get us out of the guest. the source of the interrupt will be disabled long before there is anything to handle.
<maz>
and the M1 bug only shows if you violate the GICv3 state machine, such as EOI a non active interrupt.
<maz>
as the M1 implements SEIS, it will deliver an SError. But instead of delivering a *virtual* SError, it delivers a physical one. please see the Linux commit message for the gory details.
<maz>
j`ey: yeah, this only indicates the lack of a *Linux* maintenance IRQ, because the traditional way to represent it is to expose it from the GIC itself. here, the signal comes directly from the CPU, unfiltered by AIC, and we simply don't represent it in the DT. Hence, no Linux view of that signal.
Ry_Darcy has joined #asahi
<maz>
however, the signal very much exists, and is extensively used to manage the vgic.
<j`ey>
aha, normally the vGIC maintenance IRQ is in the irq controller node in DT (looking at Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml)
<j`ey>
maz: so, with more code, this could be used, but there's no need really
<maz>
j`ey: yeah, it is absolutely pointless, because this is not a synchronous signal. it means that you absolutely need to inspect the vgic state on every exit. so we simply enable the interrupt at boot time (because the GIC otherwise gates it), and forget about it. on M1, we do nothing, which is the bestest.
L1Q has quit [Ping timeout: 480 seconds]
qazws[m] has joined #asahi
<qazws[m]>
hello, I seem to have stumbled on a language problem when installing the alpha.
<qazws[m]>
nevermind, I have reread it and I have stumbled on a wetware issue. all good now
bisko has joined #asahi
Techcable has quit [Remote host closed the connection]
Techcable has joined #asahi
Major_Biscuit has joined #asahi
MajorBiscuit has quit [Ping timeout: 480 seconds]
NikolayNikolaev[m] has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
psykose has quit [Remote host closed the connection]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
psykose has joined #asahi
bisko has joined #asahi
cupra has joined #asahi
bobmaster[m] has joined #asahi
cupra has quit [Quit: Leaving...]
Ry_Darcy has quit [Remote host closed the connection]
a_plastic_bag has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<whynothugo>
What's missing for display backlight control to work?
bisko has joined #asahi
bisko has quit [Ping timeout: 480 seconds]
Stroller has joined #asahi
<amarioguy>
maz: ahh gotcha that makes sense
babble has quit [Remote host closed the connection]
babble has joined #asahi
<dottedmag>
whynothugo: display controller driver (= huge amount of work still)
babble has quit []
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
thenailedone has joined #asahi
<whynothugo>
Thanks, I guess I'll have to wait -- it's not even something in which I can contribute.
nehsou^ has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<thenailedone>
Hi all, good thing Konversation doesn't require the hash before a channel name as I haven't been able to figure out how to make one on this imac GB keyboard I am using >.<
<Stroller>
ha!
<Stroller>
I remember when I got my first mac - I was asking on IRC where the hash key was and people were asking "do you mean the pound sign" and I was like "no, I have £, I'm talking about the hash sign for comments in code"
<Stroller>
It's option-3, thenailedone
<thenailedone>
Hi Stroller - option 3 hasn't been working for me. I tried most of the apple keyboard options available and just can't get it to show up... but thanks for the anwer :)
<Willmish[m]>
Stroller: Lol i had the same problem
<thenailedone>
oh snap, right hand option it works, left it doesn't
<Willmish[m]>
Hm, maybe u remapped the left one?
<Stroller>
It's option-3 on my 2018 Macbook (left hand option too), but I think they changed the keyboard arohnd a bit on the M2
<Stroller>
The fn key works as an emoji button on the latter - I haven't started using it peroperly yet
<thenailedone>
haven't touched any of the defaults on this system (mostly playing about to see how well it runs and it is amazing so far) so no keybaord mapping etc. But glad I can now make # and € symbold :p
<Willmish[m]>
Stroller: Oh yeah I found it’s the most pointless thing ever, I just remapped it to change input source as I use GB/Polish keyboard
<tpw_rules>
could this be a bug? iirc there is some special sauce to automatically determine and apply the correct keyboard layout in asahi
<thenailedone>
Now my next issue is more of a mystery. I canplay youtube vids embedded on other sites (like reddit) but I can't open youtube directly. www.youtube.com gived me an unable to connect message and says try again later (bith chromium and firefox)
guillaume_g has quit []
<NikolayNikolaev[m]>
Are there any pointers of what needs to be done to compile the kernel from the asahi branch. I am running debian with 5.19-rc7 kernel and tried multiple times and its always no WLAN interface.
<tpw_rules>
are you using 16k pages?
<_jannau_>
NikolayNikolaev[m]: most likely configure page size as 16k
<NikolayNikolaev[m]>
Will try that. Thanks. But my /boot/config is hmm using 4k. Will double check it.
<tpw_rules>
wifi won't work if you use 4k pages. you have to use 16k
<sven>
maybe we should add a dev_warn print to the dart driver if a dart without bypass support is probed on a 4k kernel
<sven>
or maybe even if the force_bypass/supports_bypass check is triggered in device_attach
babble has joined #asahi
surgeon has joined #asahi
surgeon has quit [Quit: Reconnecting]
surgeon has joined #asahi
thenailedone has quit [Quit: Konversation terminated!]
kefu-away is now known as kefu
<NikolayNikolaev[m]>
Thank you all, 16k made WLAN being discovered.
<mps>
wifi works fine with 4K and 16K page size
<tpw_rules>
if you patch the kernel appropriately
<sven>
yes, with the upstream kernel or the asahi kernel WiFi will not work with 4k
<sven>
I guess it actually won’t work at all with the upstream kernel because the patches haven’t landed yet :D
babble has quit []
<mps>
sven: with Glanzmans rebased patch it works
<sven>
ofc, I wrote that patch
<mps>
yes, I know :)
<sven>
but the point of the discussion above was that WiFi won’t work with 4K unless you apply some more patches
surgeon_ has joined #asahi
surgeon_ has quit []
<NikolayNikolaev[m]>
So, is there an option for the asahi branch to adopt that patch?
<mps>
hmm, I only added this one
<mps>
and font one, unrelated
<mps>
fonts*
<tpw_rules>
no, the official asahi stance and of most people is to use 16k. it's noticeably faster and most of the problematic software has been fixed
<mps>
yes, I only boot 4K kernel when have to work with F2FS
<probie>
Does anyone know off the top of their head which is the minimum version of electron that will work with 16k pages?
<sven>
technically the 4K patch is like 6 patches but people have been merging it into a single patch file for reasons I don’t understand
<AdryzzOLEDEdition[m]1>
probie: 20 afaik
<jannau>
single patch or mbox of 6 patches?
surgeon has quit [Quit: Lost terminal]
<sven>
Sunfle
<sven>
er
<sven>
*single patch unfortunately
<marcan>
we will start offering 4K kernels when they start being useful for e.g. FEX in practical situations (e.g. once the GPU driver is good enough to run games / x86 software)
<marcan>
until then, there is approximately zero reason to use 4K kernels other than as a workaround for broken software, and that software needs to get fixed
<jannau>
probie: I think 19 but it might have been backported to 18, not sure if offciaclly or just some high rofile cases like vscode
surgeon[m] is now known as surgeon
<sven>
the patch will probably also fail in interesting ways once thunderbolt is up fwiw :D
<marcan>
vscode/electron/etc got fixed because we shipped 16K kernels. if we'd been shipping 4K kernels they wouldn't have.
<marcan>
also that.
<marcan>
plus gpu stuff (IIRC DRM was one of the corner cases?)
surgeon has quit [Quit: Reconnecting]
surgeon has joined #asahi
<sven>
I’m not sure the patch that is floating around has the safety check for untrusted devices
<psykose>
if you build electron yourself, apply that to the chromium tree
<marcan>
that patch is not sufficient
<psykose>
if it doesn't apply, then have fun
<psykose>
and yes, there's a few more
<jannau>
switching to an unmanaged iommu domain is the main todo item for dcp for me I just don't get to it
<psykose>
you can also disable the partition alloc and try that if you want
<sven>
jannau: yeah, that’s also a fairly big change unfortunately:(
<NikolayNikolaev[m]>
I guess 64k is out of the question with m1/m2? Even just for basic CLI?
<sven>
but that reminds me that I have to add an api to allocate unmanaged domains with a page size mismatch once I eventually get back to that 4K patch
<jannau>
NikolayNikolaev[m]: 64k is not supported by the hw
<sven>
hm, that reminds me: didn’t you want to look into making WiFi untrusted as well because Broadcom, marcan?
<marcan>
yup
Rame has left #asahi [Leaving]
<marcan>
we are absolutely not shipping kernels that will allow that thing in passthrough mode. nope. not going there.
<marcan>
sven: does the 4K patchset put it in passthrough right now?
<marcan>
if so, then yeah, that's a hard nope
<sven>
it doesn’t work at all with that patch set because those iommus don’t do pass through
<sven>
but if brcmfmac uses non-coherent mappings anywhere it’ll still expose adjacent memory
<marcan>
ah, right
<marcan>
we should be able to fix that with subpage protection, right?
<sven>
yeah… it seems to use dma_map_single at least in one place to map < PAGE_SIZE buffers so it’ll already expose something adjacent
<sven>
yeah, just need to pass through the page offset/size all the way to the iommu driver
<marcan>
right
<marcan>
in the interim, untrusted mode would make it use swiotlb?
<sven>
yup, for dma_map_single at least
<marcan>
right
<marcan>
probably a good idea for now then
* marcan
hopes that DART split patchset gets in already...
<marcan>
it's going to make our life a lot easier
<sven>
but the code is smart enough to use direct mappings for anything dma_alloc_coherent and anything that happens to be page aligned
<jannau>
I need to send a new roll of the iopgtbl-dart patchset, got carried away by Robin's review comments
<sven>
iirc joerg picks up new code between rc4 and 6(?). Still some time left ;)
Major_Biscuit has quit [Ping timeout: 480 seconds]
Foresia has joined #asahi
Foresia has left #asahi [#asahi]
<kettenis>
didn't realize how fortunate we are in BSD land with the bus_dma(9) API
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
pi2 has joined #asahi
pi1 has quit [Ping timeout: 480 seconds]
stellarorbit[m] has joined #asahi
<stellarorbit[m]>
Hello, I have a question. I installed m1n1 and u-boot via the 3rd option in the script so I could install OpenBSD to test it out and i was wondering what the preferred way to update u-boot and m1n1 would be since I am not using asahi linux on my m1 mac mini
cabbage has joined #asahi
<kettenis>
it is relatively easy to copy an updated m1n1.bin to the ESP; could provide that as a package
<jannau>
it depends on you keeping the dts in u-boot up to date
<kettenis>
I think stellarorbit meant "asahi linux" as a linux distro
<kettenis>
although checking out the asahi linux tree just to build the dtb isn't optimal
cabbage has quit [Ping timeout: 480 seconds]
lilly has joined #asahi
Stroller has quit [Quit: Stroller]
___nick___ has quit [Ping timeout: 480 seconds]
<jannau>
yes, I ment would not want to create a asahi-linux package just to update the dtbs
<eeqk[m]>
would you recommend any books that would make it easier for me to contribute some features into this project?
<eeqk[m]>
I'll soon have 2 weeks without an access to my laptop, that's why for now simply cracking on with the code is not an option for me
<eeqk[m]>
FYI my background is with high level programming languages, I'm a full stack+mobile dev
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #asahi
lilly has quit [Remote host closed the connection]
Chainfire has joined #asahi
Major_Biscuit has joined #asahi
<Chainfire>
is it safe yet to upgrade to the macOS 13 beta with a fully updated Asahi?
bisko has joined #asahi
mini0n has quit [Read error: Connection reset by peer]
<princesszoey>
works fine for me Chainfire
<jannau>
Chainfire: yes, both asahi and asahi-dev have the necessary fixes for u-boot and kernel
nehsou^ has joined #asahi
<princesszoey>
I can't believe how fast asahi is, it's nuts.
<princesszoey>
even compiling AUR stuff is like blink and you miss it
nehsou^ has quit [Ping timeout: 480 seconds]
Stroller has joined #asahi
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Major_Biscuit has quit [Remote host closed the connection]
Major_Biscuit has joined #asahi
doggkruse has joined #asahi
<Chainfire>
Possibly offoptic: So, imagine I have lots of k8s services based on dockerfiles based on x64 images I can't easily port. Any recommended way to test/run/dev these on M1? We don't *push* any built images, those are recreated from the Dockerfiles using Google CloudBuild. Searching for this leads me to a lot of suggestions but they all seem focused on building multiarch images which would require both porting the base and isn't really what I'm
<Chainfire>
The only thing I've come up with so far that would end up with giving me working docker-compose without heavily modifying anything else, is using qemu-user-static and systemd-nspawn to fake an entire x86_64 root and run inside there.
<princesszoey>
maybe box64?
<tpw_rules>
qemu-user-static is depressingly slow even on m1
<Chainfire>
I've not used box64 at all as of yet, would it be essentially the same as the setup outlined above but qemu-user-static replaced in binfmt with box64 ?
<tpw_rules>
i don't think so, box64 hooks a lot of libraries inside the x86_64 environment
<Chainfire>
also qemu-user-static is depressingly slow on everything... One of the reasons I got the M1 to begin with is that I have a bunch of stuff I need to compile that can't go through a proper crosscompiler, doing it with qemu-user-static on my ThreadRipper takes something like 90 minutes vs 90 seconds on the M1
Major_Biscuit has quit [Read error: Connection reset by peer]
<jn>
i wonder if qemu-system is faster for workloads with many process spawns (like compiling)
Major_Biscuit has joined #asahi
<jn>
because, in theory, qemu's JIT cache might have a chance then