<marcan>
the kernel needs a bunch of patches that aren't upstreamed yet to support mising 4K CPU and 16K IOMMU pages
<marcan>
poke sven :p
<marcan>
*mixing
<Jamie[m]1>
why do we want 4k userspace?
<marcan>
because x86 emulation
<marcan>
which is still a ways off to be useful anyway
<tpw_rules>
and chrome
<Jamie[m]1>
i (naively?) assumed that 16k is being done for performance reasons, right?
<marcan>
no, people should be filing bugs for chrome
<marcan>
it not working on 16K is stupid
<Jamie[m]1>
ah x86, gotcha
<marcan>
as far as I'm concerned we're doing 4K only because distros default to it (so they don't have to ship a separate kernel once everything is upstream) and for FEX to work properly; I still expect 16K to work for everything else, and will be shipping 16K kernels for our ALARM remix until 4K is stable and FEX makes sense
<marcan>
any non-emulation software that doesn't work on 16K pages is broken and needs to be fixed
<Jamie[m]1>
đź‘Ť
<marcan>
my current plan for chrome is to just do our first dev release with a big "chrome doesn't work, please file upstream bugs for 16K page support" known issue :p
<tpw_rules>
chrome deliberately chose to break it for "binary size reduction" so not sure how amenable they'll be to fixing it
<tpw_rules>
do you know if anyone has filed a bug yet though?
<marcan>
yeah well, let's see once enough people complain :-)
<marcan>
no idea
<marcan>
feel free to :)
<marcan>
"chrome is broken on Asahi Linux by choice" is a pretty bad look for them :p
<tpw_rules>
i'm not a chrome user, but i can certainly explain how i tried it
<marcan>
chromium is similarly broken
<tpw_rules>
does it matter which one i file to?
<marcan>
probably not
<tpw_rules>
do all arm64 systems support 16 and 64k kernels?
<marcan>
no, this one does not support 64K
<marcan>
and I think almost no other system supports 16K?
<marcan>
but 64K is common and RHLE defaults to that
<marcan>
*RHEL
<marcan>
(which is why RHEL will never run their default kernels on M1s... that and they also disable DT support because apparently they want the whole world to run on ACPI)
<Jamie[m]1>
what a utopian vision :D
<tpw_rules>
like i said in the other channel i got it building by replacing a few cases of assuming 4k pages but it only works with flags that disable multiple processes. so idk if that's a deeper page related problem or some deficiency in another area of asahi
<marcan>
not just missing kernel features?
<marcan>
as in .config stuff
<tpw_rules>
idk what config features would be missing to cause that
<marcan>
I mean chrome uses some fancy kernel stuff like seccomp and namespaces for sandboxing
<tpw_rules>
maybe the chrome people can weigh in
<tpw_rules>
eh i'll try to build a bigger kernel tomorrow and see what happens. it would be nice to be able to say "make these changes and it will work"
<tpw_rules>
i do have seccomp and namespaces enabled though
<tpw_rules>
relatedly, the nvme stuff in linux-asahi is robust enough to handle a chromium build. maybe tomorrow i can try sven's branch and see if it's worse
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
chengsun has quit [Quit: Quit]
chengsun has joined #asahi-dev
chengsun has quit []
chengsun has joined #asahi-dev
<marcan>
sigh... finally managed to read the OTP on 4364
<marcan>
so it turns out 1) the core was wrong, as I said, 2) you need to flip an OTP enable bit, which I'd found but did not understand went along with the shadow area, *and* the arm64 macOS driver does not do that but the x86 build does, 3) you have to read the OTP area using 16-bit accesses on these chips
<marcan>
so, now just the ACPI shenanigans for module-instance and antenna-sku left to make T2 macs work properly
<Redecorating[m]>
nice!
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow_ has joined #asahi-dev
adityagarg8[m] has joined #asahi-dev
adityagarg8[m] has left #asahi-dev [#asahi-dev]
Major_Biscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
<marcan>
ha, so that random bytes thing corellium was doing?
<marcan>
that's cargo cult on M1 machines, since those wifi chipsets have hardware RNGs
<marcan>
... but it's necessary on at least some T2 macs, without that entropy block the cards won't boot
<marcan>
just got the 4364B3 in this bali to work
<marcan>
still need to figure out where the antenna sku comes from, I just hacked it in for now
<Redecorating[m]>
the random bytes stuff is needed when the firmware is taken from Catalina+ for 4364 and 4355 (not sure about 4377)
<Redecorating[m]>
but bcm4364b3 only has firmware from Catalina onwards
<sven>
tpw_rules: there’s a 4K series somewhere on LKMl that works fine but needs some more adjustments to be accepted upstream
<marcan>
I think I found the antenna SKU; it's another ACPI method
<marcan>
RWCV
<marcan>
that takes it from NVRAM, so that makes sense
<marcan>
as in ACPI NVS, not wifi NVRAM
<Redecorating[m]>
if you have the name of the nvram variable, i can send what I have on bali u X3
<marcan>
it's not an EFI variable
<marcan>
and this is bali u X3 :-)
<marcan>
seems we unfortunately ended up with the same test machine :p
<j`ey>
X3 is very anime
___nick___ has joined #asahi-dev
aleasto has joined #asahi-dev
<mjg59>
marcan: I have sincere appreciation for you improving the state of affairs on last-gen x86 Macs as well
<mjg59>
A lot of what we did in that space was the bare minimum to make things work, and it's clear that in various fields (like wifi) that wasn't actually sufficient
<Jamie[m]1>
flashbacks to bcm4331 hell
Major_Biscuit has quit []
MajorBiscuit has joined #asahi-dev
BastienSaidi[m] has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
___nick___ has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
<marcan>
mjg59: I had to blacklist two drivers since they were misbehaving badly, and there's still no VHCI driver so no keyboard/touchpad... so clearly there is a ways to go :(
<marcan>
but at least it'd feel silly not to fix the wifi situation while I'm here
<marcan>
just pushed wifi/take2 with, hopefully, support for all the T2 macs
<marcan>
Redecorating[m]: ^
<marcan>
I don't actually seem to be able to see any networks in NetworkManager, not sure if that's PEBKAC or something else (it does do scans and returns SSDIs, including some cached ones?)
<marcan>
so maybe there's something else to do, but at least it should get the right firmware/config and boot the card
Dcow__ has joined #asahi-dev
<Redecorating[m]>
marcan: wifi/take2 works fine for me, I can scan and connect to networks (but i'm using iwctl)
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow__ has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Remote host closed the connection]
<marcan>
awesome :)
<marcan>
it's probably some dumb networkmanager thing I have
DragoonAethis has joined #asahi-dev
<marcan>
ah, works for me now, apparently
Gaspare has joined #asahi-dev
<sven>
Redecorating[m]: could you install fio (apt-get install fio on ubuntu should work) and run fio --ioengine=sync --direct=0 --fsync_on_close=1 --randrepeat=0 --nrfiles=1 --name=randwrite --rw=randwrite --bs=4K --size=1G --end_fsync=1 --fallocate=none --overwrite=0 --numjobs=1 --sync=1 --directory=[SOME DIRECTORY ON THE NVME DRIVE]? i'm curious how
<sven>
that behaves on the T2
<sven>
it'll benchmark nvme performance for random writes w/ flushes which are still very slow on the M1 with my driver
<Redecorating[m]>
it says eta 1h 28m so i'll probably be asleep when it finishes
<Redecorating[m]>
dunno if this is useful in the meantime`Jobs: 1 (f=1): [w(1)][1.1%][w=196KiB/s][w=49 IOPS][eta 01h:28m:30s]`
<sven>
you can just ctrl+c then. looks like it behaves as bad as it does on the M1
<Redecorating[m]>
it is btrfs btw
<Redecorating[m]>
if that changes anything
<sven>
don't think so
<sven>
thanks, that's already all i wanted to know :)
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed has quit [Remote host closed the connection]
Dcow_ has joined #asahi-dev
Gaspare has quit [Quit: Gaspare]
<marcan>
sven: fwiw, since I happen to be on a T2 too, changing size to 100M (I only have the EFI partition mountable here): Jobs: 1 (f=1): [w(1)][2.7%][w=108KiB/s][w=27 IOPS][eta 10m:45s]
<marcan>
so yeah, looks pretty terrible
<marcan>
I guess it's not your driver then :p
<sven>
that’s good and bad news I guess :D
yuyichao_ has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: are you really appending a macaddr= line now to the nvram .txt files?
<kettenis>
that'll break OpenBSD
<marcan>
kettenis: not any more
<marcan>
I just removed it
<kettenis>
ah, ok, thanks
<marcan>
(since I realized it overrides SROM for T2s)
<marcan>
linux now appends the macaddr= itself on M1s
<marcan>
originally I thought it would be easier to just have a default and use the standard firmware set MAC call in a generic way, but I realized today that having a macaddr= unconditionally in nvram overrides the SROM MAC for cards which do have it
<kettenis>
admittedly the OpenBSD code is a bit dumb and blindly appends a macaddr= line if a local-mac-address property is found in the device tree
<marcan>
so now I only add it (or replace it if it's already there) iff the platform has a MAC set
<marcan>
yeah, I made the linux code properly remove any existing such lines first :p
<marcan>
but it doesn't matter any more
Gaspare has joined #asahi-dev
<kettenis>
replacing it would require more string parsing code in the kernel, which we don't really like
<marcan>
well, linux already has an nvram parser doing other nonsense
<marcan>
including removing certain other vars
<marcan>
(which also had a potential buffer overflow which I just fixed as part of these changes... so yeah)
<kettenis>
cool
<marcan>
(it wasn't allocating extra space for additional appended props, so if there wasn't enough space saved from comment/junk removal... that would overflow heap)
psykose has quit [Remote host closed the connection]
<kettenis>
heh, we had a similar issue (although I'm not sure we actually overflowed the buffer)
<marcan>
I assume linux wasn't actually overflowing since otherwise people would've noticed
<marcan>
but AFAICT that would've been possible
<marcan>
at least in cases where there is no boardrev so a default gets added, and nothing else removed
psykose has joined #asahi-dev
Gaspare has quit [Quit: Gaspare]
yuyichao_ has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
aleasto has quit []
aleasto has joined #asahi-dev
Gaspare has joined #asahi-dev
skipwich has joined #asahi-dev
Gaspare has quit [Quit: Gaspare]
<jannau>
sigh: "<jemalloc>: Unsupported system page size" from the arch linux arm fd package
<krbtgt>
je m'alloc
<j`ey>
jannau: :/
<jannau>
marcan: wpa3-personal seems to be broken: "ieee80211 phy0: brcmf_set_sae_password: failed to set SAE password in firmware (len=24)" with wifi/take3 on j274
___nick___ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jannau>
marcan: on j314c "brcmfmac 0000:01:00.0: brcmf_pcie_read_otp: OTP unavailable, using default firmware"
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Ping timeout: 480 seconds]
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
manawyrm has joined #asahi-dev
<tpw_rules>
sven: i'm not able to get your asahi-with-new-nvme branch working, but i didn't try all that hard. the nvme driver fails to identify the device, the rtkit driver tries to reset it, then rtkit crashes
<tpw_rules>
but that is also with u-boot in the mix. just wondered if you had seen that in any configuration before
<tpw_rules>
if not, i'll debug more later
<tpw_rules>
but the current nvme drivers in the asahi branch seem quite robust, been compiling junk all day
<tpw_rules>
maybe they are susceptible to problems under high sustained speed but certainly not random i/o