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
stipa has quit [Read error: Connection reset by peer]
<Ry_Darcy>
I have not seen any progress on either Arch or Debian working on an M2 Mini. Any developments here?
Bey0ndB1nary has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
eiln has quit [Quit: Page closed]
<jannau>
maz: pushed a preliminary fix for wifi
Ry_Darcy has quit [Remote host closed the connection]
Ry_Darcy has joined #asahi-dev
roxfan2 has joined #asahi-dev
Ry_Darcy has quit [Remote host closed the connection]
roxfan has quit [Ping timeout: 480 seconds]
<maz>
jannau: now building.
<maz>
jannau: success!
<maz>
jannau: feel free to add my TB tag to it when you post it (given that the original patch has a Cc stable, it is going to quickly trickle down older kernels and wreck havoc...)
<marcan>
I'm going to throw on some stuff for the 6.2 branch and cut a release, if that works we might as well go straight to 6.3-rc1
<marcan>
ps_ans2 os !on but ps_apcie_st_sys and ps_apcie_st1_sys are <- that is definitely an illegal combination since there is a dep
<marcan>
so this sounds like a driver core regression
<chadmed>
apple-pmgr-pstate 28e080000.power-management:power-controller@2XX: failed to add to parent domain: -22
<chadmed>
thats what im getting
<marcan>
wait hold on
<marcan>
I bet it's e7d90cfac5510f8c94baa18f9f3f7808859c8332 + ae8ac19655e0cd7ca5ac2f45837d386745aaed7f
<marcan>
or something related
nyilas has joined #asahi-dev
<marcan>
hm but that doesn't make sense
<marcan>
are we probing racily?
<marcan>
here's the thing
<marcan>
ps_apcie_st_sys probes, gets deferred because ps_ans2 hasn't probed
<marcan>
ps_ans2 probes
<marcan>
some random mailbox for nvme probes
<marcan>
mailbox supports runtime-pm now
<marcan>
rpm suspends ps_ans2
<marcan>
ps_apcie_st_sys probes again
<marcan>
fails because it finds itself on but ps_ans2 off
<marcan>
this is, again, the problem of domains getting shut down greedily as soon as *one* consumer has probed
<marcan>
it is particularly bad with subdomains
<marcan>
we need to do something to make sure all the subdomains probe before anything else can start shutting things down
<marcan>
maybe using syscon/simple-mfd for this was a bad idea...
<marcan>
wait no
<marcan>
argh it's because it's a different pmgr altogether
<marcan>
goddammit we need some real solution for this mess
<marcan>
I think we can probably fix it with some ugly custom module init stuff in apple-pmgr-pwrstate, so that it greedily keeps scanning for and probing devices at load time until everything is probed, instead of letting EPROBE_DEFER go back to the driver core
<jannau>
uboot issue seems to CONFIG_LMB_MAX_REGIONS=8 being too small
<marcan>
heh
<marcan>
that's easy then
<jannau>
nice, the sd-boot menu is fixed
<kettenis>
mailine u-boot already bumped CONFIG_LMB_MAX_REGIONS to 16
<kettenis>
do we anticipate needing more?
<marcan>
I think what we *really* want here is something in the genpd core to make it refuse to shut down any PDs that have consumers in OF that have not probed yet
<marcan>
kaprests: I think we may need way more for dcpext on e.g. M1 Ultra? if this is about reserved-regions
<marcan>
since there's like 8 of those
<marcan>
blergh this PD thing is going to suck to fix
<jannau>
kettenis: hard to say, depends on the regions being consectutive
<jannau>
8 worked so far only because u-boot combines consectutive regions
<Cyrinux9>
Hey, marcan, I just update my m2 air, I can't boot anymore https://ibb.co/g9GD2GP
<marcan>
Cyrinux9: too late, already on it
<Cyrinux9>
If this can help. Should I update macosx blob? Ok sorry
<kettenis>
maybe I should just bump it to 64 for m1; it is not as if we're starved for memory
<jannau>
povik: are you sure that increasing CONFIG_LMB_MAX_REGIONS didn't fix the sio issues
<marcan>
Cyrinux9: unless you intend your system to break, you shouldn't be using asahi-dev
<marcan>
(so this is on you to fix, we don't support asahi-dev)
<jannau>
kettenis: I'll send a patch
<Cyrinux9>
Don't worry :) I will fix from recovery when fix ready
<marcan>
Cyrinux9: reverting m1n1/boot.bin to boot.bin.old from recovery will probably work enough to boot to linux and update again
<kettenis>
jannau: cool
<Cyrinux9>
OK, will do now
<kettenis>
jannau: did you reach a conclusion about pcie?
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit []
MajorBiscuit has joined #asahi-dev
<jannau>
kettenis: no, only thing which worked are workarounds: 1. do not init already up ports and 2. skip ports with pwren-gpios in u-boot
<marcan>
robher: is OF probe order across buses/sub-buses defined at all? we have a problem with pmgr nodes, where some nodes probe before their power-domain parents, so they get deferred. then some other device probes, and as the first consumer goes into suspend and the parent gets powered off. then the deferred child probes, and bails when it finds itself on but the parent off, which is illegal.
<marcan>
this is a deeper problem we also have with e.g. DCP (where its PD is illegal to turn off until the DCP driver probes), but that's a bit of a special case
<marcan>
(we hack around that one by marking it always-on and then the DCP driver unmarks it)
<marcan>
however, PD dependencies not being honored are a much bigger problem
<jannau>
marcan: booted with updated u-boot from asahi-dev
<marcan>
so basically we need some way for the pmgr driver to synchronously ensure the entire hierarchy it is responsible for is probed, not just a single pass with stuff ending up deferred
chadmed has joined #asahi-dev
<marcan>
I know OF already has some stuff to pre-populate fwnode links based on power-domains properties, maybe what we should do is make the PM core refuse to power off a domain if there are any links that haven't probed yet?
<chadmed>
aaand we're back, apple,always-on in ps_ans2 sorted it
<marcan>
we don't really want that since it makes nvme PM worse, but for now it will do
<Cyrinux9>
the workaround works, thanks marcan
<chadmed>
yeah :/
<chadmed>
odd that it didnt affect your machine, is that code path racey?
<marcan>
it would depend on probe order, yes
<sven>
lovely :(
<marcan>
we can also do the same thing DCP does for now and unmark that flag in the nvme driver
<marcan>
I'll try doing it "properly" with some fwlink based thing in the PM core
<marcan>
but if people don't like that then hack it is
<marcan>
new kernels should be up too
<marcan>
the "proper" fix might have to wait until later though, since I have way too much stuff on my plate first
Bey0ndB1nary has quit []
* sven
has been busy with $work that actually pays my bills as well :D
<marcan>
:D
<chadmed>
couple of other pcie niggles seem to have cropped up too https://tpaste.us/RBEv
gladiac has joined #asahi-dev
<jannau>
that warning shouldn't be there
<marcan>
I think I saw the patch for that
<marcan>
jannau: added your fix to bits/030-misc
<kettenis>
hah: [ 0.000000] efi: EFI v2.100 by Das U-Boot
<kettenis>
that version number isn't printed quite right
<jannau>
chadmed: do you have d57163d701f2 and aad9b063352e?
<chadmed>
jannau: yeah they made it into asahi-6.2-5
<chadmed>
ill pull down the new tag and test tomorrow anyway
<jannau>
no need, I see it with asahi-6.2-6 as well
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jannau>
I blame that on u-boot's pcie code. I don't see those warnings when booted directly through m1n1
<jannau>
I disn't realize that until now that we use u-boot with PCIe support
pzc has joined #asahi-dev
DarkShadow44 has joined #asahi-dev
<jannau>
marcan: did you already test on mini, imac or studio? I expect ethernet and usb xhci (on imac, studio)
<robher>
marcan: only parent-child dependencies. The device that defers should have a dependency on the PD provider and not attempt to probe. But how is the PD turned off if its driver hasn't probed yet?
<marcan>
robher: PDs turn off when their *first* dependency probes and idles itself
<marcan>
so then another dependency comes along that expected that not to happen and it breaks
<robher>
ah
veeyee has joined #asahi-dev
<robher>
That's probably broken for any provider. Or if you defer for provider A, and then provider B is disabled.
<marcan>
this is a particular problem for PDs because hardware has interesting rules for that, like you can't just turn off some power domains that are on at boot without first hooking up their dependencies
<marcan>
(because hardware is already on at the bootloader and you can't just yank power from it, or because it's outright a dependent PD)
chadmed_ has joined #asahi-dev
<robher>
A shared clock (or parent) would have the same issue.
<marcan>
yeah
<marcan>
so I'm thinking the genpd core should refuse to power off PDs if there are any unprobed/unfulfilled fwlinks
<marcan>
I don't particularly care about clocks for this platform so someone else can worry about that :-)
<robher>
And if it was on already at boot.
<marcan>
yeah
<marcan>
if that sounds like a sensible solution to you I'll go with that
<marcan>
(but not now, this is going on my queue for later)
<robher>
I think there's been some binding proposal for 'boot clocks'. It's been a while back.
<povik>
jannau: re max_regions. i will double check. i haven't tried that other option kettenis suggested
<jannau>
marcan: confirmed, broken ethernet and usb pcie xhci on the studio. easiest workaround is disabling pcie in the u-boot defconfig
<marcan>
sigh.
<marcan>
yeah okay let's do that
<marcan>
want to send the patch?
<jannau>
otherwise I have workaround patches for linux and u-boot
<marcan>
at this point I just want to get this out ASAP, we've delayed this release long enough
<marcan>
more involved fixes can wait
chadmed_ has quit [Remote host closed the connection]
<marcan>
I'll send the wifi fix
chadmed has quit [Read error: No route to host]
<jannau>
ok, I'll prepare the u-boot config change
<robher>
marcan: That could leave domains powered forever if there is not a driver. It's a common problem because we never know 'all drivers are loaded' except for !CONFIG_MODULES
chadmed has joined #asahi-dev
<marcan>
robher: yeah, but what are we going to do? if it was on at boot, and the DT describes devices that depend on it, we can't know it's safe to power it off
<marcan>
I would say that's a platform bug
<marcan>
either ship the drivers or have the bootloader turn it off
<marcan>
either that or we add a new DT property to mark devices that may require PDs active at boot...
<robher>
marcan: It might be better to have some hint in the DT as to what domains are critical. Maybe simple-framebuffer node needs a power-domains property (though the display phandle link could provide that).
<marcan>
yes, that is the case for us, though that's just one instance of an issue
<marcan>
but then really every domain that has PD children is effectively critical, since turning off a parent before children is a bad idea
<marcan>
new u-boot in asahi-dev
<marcan>
warnings gone
<robher>
marcan: I suppose the PD driver could prevent that assuming it's all one driver and instance. Otherwise, if your refcounts and actual h/w state are mismatched, kind of hard for s/w to do the right thing,
<marcan>
the way we bind the PD driver it's one instance per PD, which is what is causing the issue (but actually even if it were a whole driver for a set of PDs, we have a cross-PD-set dependency and those would probably be separate instances no matter what)
<marcan>
(the bigger chips have multiple PMGRs)
<marcan>
it is all one driver though, so I think it could prevent that by using a custom module init function that makes triple sure everything is probed until nothing defers, and the driver core never sees the defers (or something like that)
<marcan>
but it feels really ugly
<jannau>
ethernet+xhci restored on the studio
<marcan>
OK, I *think* we dealt with all the explosions so far
<marcan>
I should get some dinner+sleep
<marcan>
please do continue to test stuff
<marcan>
ideally I'd like to release this next week or so
<marcan>
I'll give it a spin on some more machines myself
roxfan has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
Hibyehello_ has joined #asahi-dev
roxfan2 has joined #asahi-dev
c10l has quit [Quit: Bye o/]
roxfan has quit [Ping timeout: 480 seconds]
Hibyehello has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
veeyee has quit [Quit: Leaving.]
veeyee has joined #asahi-dev
c10l5 has joined #asahi-dev
c10l has quit [Read error: Connection reset by peer]
<Glanzmann>
Disabling freedreno let me compile mesa. Kernel boots, xorg starts.
MajorBiscuit has joined #asahi-dev
Hibyehello_ has joined #asahi-dev
<Glanzmann>
marcan: You probably won't do anything about it, but with xorg and xfeerdp, I have still display artefacts. The rosa tiles when I log in for a fraction of the second as with jannaus video and when I open firefox in a rdp session and zoom in/out the result is: tg.st/u/screenshot-air-2023-03-11-19_10_58.png
<Glanzmann>
I use this command line: xfreerdp +clipboard:use-selection:PRIMARY /u:Administrator /p:'Pa$$w0rd' -grab-keyboard /cert-ignore /f /bpp:32 /v:zh17w2k22.glanzmann.de -gfx /rfx
<Glanzmann>
If you or someone else needs a rdp account to reproduce, let me know.
Hibyehello has quit [Ping timeout: 480 seconds]
<Glanzmann>
marcan: A regression for me: When I type 'reboot' in Linux. The screen turns off, but I think the system does not. It does not reboot. But when I press the power button for a long time, release it, press it again, the system boots again.
<Glanzmann>
Nothing in /var/log/kern.log unfortunately.
Bey0ndB1nary has quit [Remote host closed the connection]