ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
jato has quit [Ping timeout: 480 seconds]
jato has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
gladiac is now known as Guest1486
gladiac has joined #asahi-dev
Guest1486 has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
leah1 has quit []
jbowen has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
leah has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
flying_sausages has quit [Ping timeout: 480 seconds]
<kloenk> ChaosPrincess: would it be a good idea to include the block size as a const in the block_device trait?
<ChaosPrincess> do you know of a way of doing that w/o forking the crate
<kloenk> No, but would like to upstream it then
<marcan> re signatures, let me take care of that please
<marcan> we are running way ahead of ourselves here
<ChaosPrincess> i will just make a proof of concept implementation for now
<marcan> I said I wanted to look into rust for that future feature, not that I wanted implemented now :p
<ChaosPrincess> the actual checking part isnt that complex and can be replaced
<marcan> *wanted it
<ChaosPrincess> welcome to the news cycle - "scientist say a chemical may increase chances of in-vitro treatment of cancer cells" = "scienctists cured all forms of cancer " :P
<kloenk> marcan: I'm sorry If I'm too fast for you. I will for now continue on my gpt crate, to make that easier/more stable to use.
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
<kettenis> marcan: any progress on the smc mfd stuff?
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
<marcan> kettenis: cleaning up the commits now (modulo stupid IRQ... see twitter... *sigh*)
chadmed has quit [Quit: Konversation terminated!]
blasty has joined #asahi-dev
Ziemas has quit [Ping timeout: 480 seconds]
blasty_ has quit [Ping timeout: 480 seconds]
Ziemas has joined #asahi-dev
chadmed has joined #asahi-dev
flying_sausages has joined #asahi-dev
al3xtjames4 has joined #asahi-dev
al3xtjames has quit [Ping timeout: 480 seconds]
al3xtjames4 is now known as al3xtjames
nsklaus_ has joined #asahi-dev
kgarrington has joined #asahi-dev
<kgarrington> marcan: any word on the pull request sven submitted for m1n1 nvme fixes? https://github.com/AsahiLinux/m1n1/pull/156
kgarrington has quit [Remote host closed the connection]
<marcan> ... merged but I guess they left?
<sven> lol
kgarrington has joined #asahi-dev
<marcan> I have joins/parts disabled but I always get confused when tabcomplete doesn't work, heh
<sven> ah, he's back :D
<kgarrington> Sorry, when I leave this app on my iPad it must sign me out. I mostly watch using whitequark’s log
<j`ey> kgarrington: that nvme support is just for m1n1 though, not used for anything currently
* sven just wants to use it to reproduce that weird random write + flush slowdown
<kgarrington> My other question for marcan is if he’s going to exclusively support schedutil with his upcoming cpufreq work. Seems like the best option
<kgarrington> Might be worth removing performance and ondemand from the kernel config entirely
<marcan> that's purely a config thing, the driver doesn't care
<marcan> but yes schedutil should be the default, probably
<kgarrington> Probably best to enforce that default in the config
<j`ey> kgarrington: the config is up to the distros in the end
<kgarrington> I thought the default distribution was going to be Arch-based, so in that case, it’s very doable
<kgarrington> I’m excited to start turning things off in the Asahi kernel config and getting the total memory footprint of the system down 🤓
<kgarrington> While it’s not hard to use less ram on first boot than macOS, it’s fun to get it as low as possible
<kgarrington> Though turning off the various cpu errata in the arm64 config scares me, I don’t know which apply to M1x
<j`ey> none
<j`ey> kgarrington: I have a pretty minimal kernel and it's still 15M
<kgarrington> I measure based on the memory usage reported by neofetch after boot
<kgarrington> And compare to the numbers reported in Activity Monitor.app on the Mac. My Intel macs use at least 4GB of Ram just to boot to the desktop
kgarrington has quit [Remote host closed the connection]
<povik> uh oh
<povik> protonmail has found pgp keys for bunch of people and has been sending them encrypted copies of patches
<povik> i only found out now from broonie's reply: https://lore.kernel.org/alsa-devel/YfqF9Da6uVHUEA7G@sirena.org.uk/
<j`ey> but its fine on the web page?
<povik> yeah, no pgp key on file for the mailing list :-p
<sven> they also messed with my outgoing patch once (iirc they changed some linebreaks or something? don't remember)
<sven> that was one of the reasons i switched to fastmail
<alyssa> povik: oh dear
<maz> yeah, proton has some interesting policies.
<povik> i guess it might have picked up the key from a signed email on the mailing list in the past? (pull request?) not sure what happened there
<maz> they likely have imported the database from one of the keyuervers.
<maz> keyservers*
<povik> how do they know the keys are valid? i thought anyone can upload to keyservers
<maz> that's the fun part. they have no clue.
<alyssa> cursed
<povik> :/
<maz> but hey, they managed to get my key right, so I can still read email people send me.
<sven> most of their security is also more of a cargo cult
<maz> but I'm everyday grateful I run my own email infrastructure.
<sven> i happily pay someone else so that I don't have to do just that :D
<maz> I used to do that. and then I realised that they were worse than me.
<maz> (and that's saying something)
off^ has quit [Remote host closed the connection]
<povik> well that's one explanation why NCO v3 haven't got any response yet
<povik> (stephen who reviewed v2 got his copy encrypted)
<sven> i think i gave up when gmail.com decided for the n-th time that my mails were spam because the IP range my server was in got added to some spam blacklist
<Chainsaw> Running e-mail infrastructure is hard work. I left it to Microsoft in the end. They have more time to spend on spam defence than I do.
<maz> yeah, I had some run-in with gmail, only solved by some heavy duty DKIM/SPF setup.
<maz> yahoo has been the worse over the years.
<sven> i've heard outlook.com is pretty bad too. apparently they silently blackhole mails they consider spam instead of just moving them to a spam folder
<milek7> in my experience outlook is the worst
<sven> i just decided life's too short to deal with all that :)
<Chainsaw> sven: Funny how "I don't care anymore", "it's someone elses problem" and "it's in the cloud" all mean the same thing :)
<maz> one thing for sure, I'm not going to pay my employer to allow me to do my job... ;-)
<sven> :D
<Chainsaw> maz: That just sounds like you've got a strong negotiation position to me.
<Glanzmann> maz: When you work for Google you can also open an internal ticket and email blocking get resolved quickly or if you have the right permissions you can do it yourself ...
<Glanzmann> maz: I also prefer running my own mailserver and will never let someone else take care of my email, to imortant.
<maz> Glanzmann: I stay away from the internal prod stuff. otherwise, I'll get roped in for ridiculous stuff.
yuyichao has quit [Ping timeout: 481 seconds]
<Glanzmann> maz: I see. :-)
jbowen has joined #asahi-dev
yuyichao has joined #asahi-dev
<povik> web key directory is where protonmail got the keys
<sven> that actually looks reasonable. it’s still annoying that it automatically tries to encrypt every outgoing email then
<povik> but that seems like a bug. as they describe the feature in their support pages there needs to be an action from me first before they start using the key to encrypt for a particular contact
<povik> and i don't see a way to make protonmail not do that... argh...
<alyssa> povik: giving the CLASS_DEPRECATED patch a go
<alyssa> It definitely "seems" to be more likely to work if I warm reboot from macOS
<alyssa> though actually boot chime is enabled regardless
<alyssa> failing even with that patch
<alyssa> at fresh boot, p.read32(0x23d1f002c) = 0xc76202
<povik> fwiw the chime is with a different codec than the one you see probe failures on
<alyssa> oh
<povik> 0xc76202 is the cs42l part in reset, as it should be
<alyssa> failed after a warm boot from 1TR
<alyssa> failed after rebooting from macOS, so much for that theory
<alyssa> ahh bloody h
<alyssa> wait nvm
<alyssa> broken even with {clk,pd}_ignore_unused
<alyssa> yeah im just going to use headphones on another computer.
<povik> oh no the asahi effort failed you there
<povik> went over the bits in 0xc76202 but the drive strength seems high enough, nothing weird
<povik> not that my mini would give a different value (probably, don't have it by me)
<povik> alyssa: you still no friends with the hypervisor?
<povik> i would love to ask you to look at the matter under m1n1's gpiola
<povik> or send me the exact tip commit and .config and i will see if i can't reproduce it with that
MajorBiscuit has quit [Ping timeout: 480 seconds]
<ChaosPrincess> trying to call nvme_init in m1n1 code and it returns 0, what am i doing wrong
<sven> it should complain about something if it fails
<j`ey> ChaosPrincess: marcan just merged a few changes from sven for 12.1 and max/pro, so maybe pull if that could affect you
<sven> oh, yes. Apple decided to change the SART compatible from sart,t8103 to sart,costguard with the 12.0 update
<sven> *coastguard
<ChaosPrincess> ok, that helped
<j`ey> coastguard.. i assume thats an inside joke :P
<sven> :D
<sven> i guess it’s the codename for that hardware block
<alyssa> the West Coast, I assume
<alyssa> :-p
<jannau> I got rid of the force-locked dart-disp0 using reserved regions from the devicetree. Works by not resetting stream ids with reserved regions on probe and recreating the regions on device attach
<jannau> I'm not sure if it would be desirable to verify that only the the reserved resgions are mapped at probe
<sven> nice! not sure what that check would do for us but it feels like that check could be done in m1n1 if we really wanted to
<jannau> ok, easier for me then. I laready check if the reserved regions are mapped continuously in m1n1 but not if anything else is mapped
yamii has joined #asahi-dev
<sven> feels like a sanity check to me tbh. If iboot wants to play nasty games and try to map something else it could also do much more horrible things 🤷🏻‍♂️
<j`ey> like.. not load us :P
<sven> I’m much more enthusiastic about not needing that force locked hack anymore :)
<jannau> checking every page looks indeed over the top. checking the last mapped page shouldbe enough of a sanity check
<jannau> mostly to catch unexpected changes in the adt not catch a nefarious iboot
<alyssa> jannau: Woo :]
<alyssa> reserved-regions is probably the way to go, yeah
<alyssa> sven: aww but the force-locked hack is so cute! :-p
<sven> jannau: yeah, that sounds reasonable
kaprests has quit [autokilled: Possible botnet activity. Mail support@oftc.net with questions. (2022-02-02 19:00:02)]
n1c has quit [Quit: ZNC 1.8.2+deb1+focal2 - https://znc.in]
wCPO6 has quit []
wCPO6 has joined #asahi-dev
n1c has joined #asahi-dev
<jannau> seems to be enough to have just the framebuffer as reserved region
m6wiq has joined #asahi-dev
kaprests has joined #asahi-dev
Tuff has joined #asahi-dev
Guest1237 has quit []
DragoonAethis has joined #asahi-dev
nsklaus_ has quit [Quit: Konversation terminated!]
___nick___ has joined #asahi-dev
chengsun has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #asahi-dev
Tuff has quit [Quit: Textual IRC Client: www.textualapp.com]
<ChaosPrincess> fat loading done, now time to reimplement mach-o parsing in c
<jannau> do we need that? we probably should think of a simpler solution now that we have raw binaries anyway for macos 12.1 and later
<jannau> the macho parsing in python was something needed for loading macos kernels in the HV
___nick___ has quit [Ping timeout: 480 seconds]
<ChaosPrincess> im not sure i understand the raw m1n1 linker script
<ChaosPrincess> like where is the entry point set
<j`ey> you set that when you run kmutil: kmutil configure-boot -c m1n1.bin --raw --entry-point 2048
<j`ey> (which is why https://paste.gg/p/anonymous/f909af7bf7f64a19afb1ae48ae523962 might be useful to apply)
<ChaosPrincess> yea, i just dont get how sections magically end up at 2048
<j`ey> src/start.S has the .init section, and _start is at 2048 into that
loki_val has quit []
crabbedhaloablut has joined #asahi-dev
m6wiq has quit []
c10l has quit [Quit: Bye o/]
jeffmiw has joined #asahi-dev
c10l has joined #asahi-dev
Esmil has quit [Server closed connection]
Esmil has joined #asahi-dev
Fanfwe has quit [Server closed connection]
Fanfwe has joined #asahi-dev