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
nyilas has quit [Remote host closed the connection]
nyilas has joined #asahi-dev
nyilas has quit [Remote host closed the connection]
Deewiant has quit [Remote host closed the connection]
Deewiant has joined #asahi-dev
<maz>
does anyone remember which bit of the kernel is responsible for resetting the boot count that invalidates the m1n1 install after 10 or so failed boots?
<maz>
I'm getting the itch to replicate this in m1n1 or u-boot...
<maz>
(if only I could find what it is)
roxfan2 has joined #asahi-dev
<j`ey>
pmu
roxfan has quit [Ping timeout: 480 seconds]
<j`ey>
proxyclient/m1n1/hw/pmu.py in m1n1
<j`ey>
reset_panic_counter(self):
<maz>
awesome, thanks!
nsklaus has joined #asahi-dev
jannau has joined #asahi-dev
<jannau>
maz: proxyclient/tools/reset_panic_counter.py shoould be executable from proxyclient
<kettenis>
doing this in u-boot would involve writing an spmi driver
<maz>
yeah, figured out that it is way easier to add this to my chainload script and forget about it.
<maz>
this machine is likely to be tethered for the rest of its like anyway.
<maz>
life*
<kettenis>
we probably wouldn't want u-boot to do this by default anyway
<maz>
agreed. this is more specific to my own use case where I'm not quite in a position to boot the OS yet, and having to fish for keyboard/mouse every 20 minutes is driving me potty.
<jannau>
one could argue that chainload.py should reset the counter. when chainload runs the system obviously booted successfully to m1n1's proxymode
<kettenis>
yeah, that'd make sense
<maz>
+1.
<marcan>
maz: m1n1.setup already does the PMU counter reset, so almost all m1n1 scripts automatically do it, including chainload.py
<marcan>
I haven't had to manually invoke that reset script in a looooong time :)
<marcan>
chadmed: um, that hvc is a reboot() call
<marcan>
probably means m1n1 is panicking which means you should be getting a message over the vUART
<maz>
marcan: my scripts are based on a m1n1 version that is about 2 year old... that might explain why.
<marcan>
yeah, it would :p
<chadmed>
odd, nothing in the console except that same exception after trying to jump to the kernel
<marcan>
remember we don't guarantee ABI compat for the uart protocol, I only actively try to keep chainload.py working
<marcan>
chadmed: same exception from the guest in the vUART?
<chadmed>
it's the m1n1 at the front of the guest payload throwing it before the kernel starts printing at all
<marcan>
yeah but it can't be that same exception because it's an hvc
<marcan>
only the HV would catch that
<marcan>
can you paste the guest exception?
<marcan>
the guest exception would cause a panic which then triggers the hvc
<marcan>
there are very few commits to the good commit so it should be very obvious what is wrong from the guest exception
<marcan>
but probably in the kernel before it installs its own exception handlers, so it goes back to m1n1
<chadmed>
oh right, interesting
<marcan>
are you using earlycon?
mx08 has quit [Quit: WeeChat 3.0]
mx08 has joined #asahi-dev
<chadmed>
yeah its in chosen.bootargs for that payload
<chadmed>
it works with run_guest_kernel.sh though so probably something up with the payload
<marcan>
oh, like you made the payload yourself?
<marcan>
if you send it to me I can try to make sense of it
<marcan>
(the payload binary)
<chadmed>
theres nothing special about it, just m1n1 at HEAD, earlycon and debug in chosen.bootargs, the j474s dtb from asahi-wip, the debian netinstaller, then Image from asahi-wip with everything built in
<marcan>
okay but I need the binary if I'm going to try to disassemble it to figure out what it's doing :p
<marcan>
a 68MB mach-o when the max mach-o payload size is 64MB in the linker script
<marcan>
kernel's probably missing the last few megabytes or something
<marcan>
(please don't use mach-o any more)
<chadmed>
oh yup yup that'd do it
<chadmed>
yeah i didnt realise we had raw binary support until ~5 minutes ago
<chadmed>
im going to update the wiki, it still says no raw bins :/
<marcan>
yeah, for the HV that is somewhat recent
<marcan>
so I guess the last few commits just made m1n1 slightly larger enough that the kernel lost something more critical :p
<chadmed>
ooh does that mean people are going to call it bloated now :P
benpoulson has joined #asahi-dev
<maz>
... and I thought my 12MB mini+firmware+dt+u-boot was big... :D
<chadmed>
if you search the logs you can find me bumbling around with a 300mb initramfs that decompresses to like a few bytes above 1gb, which broke payload.c and the hypervisor's default heap
<chadmed>
"i'll just add a few zeroes to the maximum ~weight~ heap size"
<kettenis>
marcan: when we change the installer to produce a .cpio with just the firmwares that u-boot cares about, it will still have pauths that start with vendorfw/ ?
<kettenis>
s/pauths/paths (I've been playing around with pointer authentication last week)
<marcan>
kettenis: might as well, for consistency
<kettenis>
maybe I should introduce a tiny abstraction layer in u-boot that prepends vendorfw/ such that the firmware name in the driver matches what Linux has
cylm has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
korreckj328__ has quit [Read error: Connection reset by peer]
korreckj328__ has joined #asahi-dev
korreckj328 has joined #asahi-dev
korreckj328__ has quit [Ping timeout: 480 seconds]
korreckj328 has quit [Remote host closed the connection]
<marcan>
did anyone around here have a CPU-downbinned machine?
<marcan>
there's a reddit post about bad interactivity on an 8-core j314 and now I'm wondering if we're doing something wrong with the AIC2 or cpustart setup...
<marcan>
since that kind of thing could be explained by IRQs getting delivered to nonexistent CPUs first (AIC2 will fallback to all CPUs after a timeout if no CPU acks the IRQ)
<marcan>
could be completely unrelated of course, but might as well check...
<marcan>
though I guess I could probably emulate it on my j314 with ADT hacks
<kettenis>
hmm, u-boot actually has some infrastructure to load firmware from a filesystem
<marcan>
jannau: ok, nothing unexpected there
<kettenis>
loading the firmware directly from the ESP would make updating u-boot easier and I suspect it would result in less resistence upstream
<marcan>
kettenis: works for me, but then we need the magic ESP selection stuff upstream too, and all that has to run before PCIe/USB init which means NVMe has to come first
<kettenis>
yes, but I think I can pull all that off
<marcan>
I figured an initramfs would be easier but if you think all that can work... :p
<marcan>
can you load it from the vendorfw.cpio directly? or do you want it standalone?
<kettenis>
standalone would be easier
<marcan>
I think as a one-off we can do that, maybe <esp>/vendorfw/uboot/<filename>?
<marcan>
just to make it clear this is for uboot and not the kernel
<marcan>
(hope we never have to deal with the complex firmware trees in uboot, those need hard/symlinks :p)
<marcan>
I *think* those symptoms could be explained by some kind of pathological IRQ routing in KVM, like as if host IRQs don't get handled when they arrive at CPUs that are in the guest
<marcan>
but it could also be something completely unrelated
<marcan>
reason being that I believe AIC2 will always try to deliver IRQs to CPUs that are alive instead of waking up CPUs that are asleep, and then will prefer e-clusters by default or if all CPUs are asleep, and it has a fallback where if the IRQ is not acked in a while it broadcasts to all CPUs, which would explain lag if a guest is busy but its CPUs are not properly handling host IRQs
<marcan>
could also be we screwed something up in lower core machines, though I haven't found anything yet
thomas has joined #asahi-dev
Tomdownsouth has quit [Read error: Connection reset by peer]
<ChaosPrincess>
the rust for linux crowd really needs to work on kernel build ux. just too many things that can cause a random "you aren't getting gpu drivers this kernel build"
<sam_>
marcan: meh I might have misremembered wrt the thing I just cc'd you on for gdb
<sam_>
but in any case you may still have opinions so hopefully it's not pure noise
<kettenis>
indeed, it tries to solve a different problem (and largely fails at doing so)
<maz>
marcan: it'd be good to have some details. I'm running my desktop in a VM on the Studio, and otherwise compiling on the host. the host definitely doesn't feel sluggish...
<maz>
even if an IRQ ends up on the "wrong" core, we can service the interrupt in about 1000 cycles, which wouldn't register at all, so something else must be at odds.
<maz>
could be cpufreq, as I'm not using any PM on my boxes (frequencies set at boot time).
amarioguy has quit [Remote host closed the connection]
<maz>
marcan: in any case, I'd love the person with the problem to show up on the list. if they are experiencing issues, they probable aren't the only ones (and there's a long list of details I need to know about...)
gladiac has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
gladiac is now known as Guest191
gladiac has joined #asahi-dev
Guest191 has quit [Ping timeout: 480 seconds]
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
Guest12533 has quit [Quit: Bridge terminating on SIGTERM]
Jamie has joined #asahi-dev
rhysmdnz has joined #asahi-dev
Jamie is now known as Guest192
thomas has quit [Remote host closed the connection]
drubrkletern has joined #asahi-dev
brolin has joined #asahi-dev
roxfan has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
<maz>
does someone have the part numbers of M2 max CPUs? I'm adding the -pro versions to the vgic SError shit-list, and I might as well do the full M2 range, since it is likely to be the same old story.
<maz>
ah, m1n1 of course have them. sorted.
roxfan has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
brolin has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
nsklaus has quit [Quit: WeeChat 3.8]
nsklaus has joined #asahi-dev
korreckj328_ has joined #asahi-dev
korreckj328 has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
brolin has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
korreckj328_ has quit [Remote host closed the connection]