ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
mildsunrise3 has quit [Quit: Ping timeout (120 seconds)]
m5zs7k has quit [Remote host closed the connection]
mildsunrise3 has joined #asahi-dev
m5zs7k has joined #asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
<amarioguy>
just refreshing my memory here since i'm at the point where i have to finish the vgic implementation now: AICv2 and v3 i hear don't support setting CPU affinities?
<amarioguy>
(ik you can have CPUs opt out of interrupts via the SIQ cfg msr but iirc that only allows filtering between P and E core clusters
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
popey__ has quit [Ping timeout: 480 seconds]
<amarioguy>
maz: not sure if you're still active so apologies in advance for the ping, but does kvm exactly care much about AIC2 seemingly routes interrupts to cores at random? didn't seem like there was any special code to do that in either the AIC driver or the KVM vgic code, but then again the fact that virtual CPU state is entirely maintained by the HV means that it may not matter much i suppose
glem810054889 has quit [Ping timeout: 480 seconds]
glem8100548897 is now known as glem810054889
<alyssa>
yay!
Larwive has joined #asahi-dev
<nickchan>
yay! I need similar logic too
<nickchan>
i think usb3 is not sensitive enough to absolutely require tunables do they
<nickchan>
and by tunables I mean device specific tunables
<sven>
atcphy needs then because what Apple calls „tunables“ are there is in reality 10% tunables and 90% init sequence they didn’t want to put into the atcphy kext for whatever reason
<sven>
*them
Larwive has quit [Ping timeout: 480 seconds]
zkrx has quit []
zkrx has joined #asahi-dev
glem810054889 has quit [Ping timeout: 480 seconds]
chadmed_ has quit [Quit: Konversation terminated!]
chadmed_ has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
<sven>
on m1+ the dwc3 tunables in the ADT are just documented writes to the normal dwc3 regs iirc
<sven>
e.g. the device one just sets the right bit in DWC3_GCTL_PRTCAP
<sven>
jannau: so i'm even more confused by that mmu_setup_secondary abort. i also see a different address inside m1n1 for x29 vs sp which looks reasonable. maybe x29 gets corrupted as well? but i dont see how :/
break95 has joined #asahi-dev
iyes has joined #asahi-dev
pb17 has joined #asahi-dev
<sven>
00125f7c fd 7b bf a9 stp x29,x30,[sp, #local_10]! <-- so that's x29 and lr before it branches to supports_pan. by the time it returns both seem to be corrupted
chadmed_ has quit [Quit: Konversation terminated!]
chadmed_ has joined #asahi-dev
<jannau>
my suspicion are guest intercepts but I'm puzzled why those would only break in this specific place. I also suspect the issue would vanish if llvm would save SP at function entry
<jannau>
better debugability of the host m1n1 than writing to random registers would be nice
<sven>
the truly weird part is that sometimes bringing up core 1 works and then it fails at the same place for core 2
<sven>
if this really is some timing issue i'm not sure even a SWD debugger for host m1n1 would help debugging this
lion328 has quit [Quit: Leaving]
lion328 has joined #asahi-dev
<jannau>
I still do not understand against what we could be racing though
<sven>
I didn't even find any instruction that would write 0x2000000 somewhere and would make sense in that context when I checked a few weeks ago
<sven>
and adding just slightly too much debugging made the exception disappear as well
<jannau>
could be memory contents
<sven>
true
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
<jannau>
according to my debugging SP was consistent within mmu_setup_secondary but I don't see how "too much" debugging inside mmu_setup_secondary would prevent something corrupting the secondary stack of the affected core
<sven>
i'll have to try again but I think what happened is that supports_pan was somehow inline when I added "too much debugging" to mmu_setup_secondary
<sven>
*inlined
<sven>
and then it never stored/loaded lr from the stack
<sven>
what I don't understand is why increasing DUMMY_STACK makes the issue disappear as well
john-cabaj has quit [Quit: john-cabaj]
<jannau>
I haven't seen supports_pan being inlined. one variant of "fixed by too much debug" I've seen was saving LR at function entry
<jannau>
my theory of how increasing dummy_stack avoids the problem is that something else gets overwritten
mx08 has quit [Quit: WeeChat 3.8]
mx08 has joined #asahi-dev
iyes has quit [Quit: Leaving]
chadmed has joined #asahi-dev
chadmed_ has quit [Read error: Connection reset by peer]