00:03 <jannau> marcan: PR with a revert (Aand tracing fixes) in https://github.com/AsahiLinux/linux/pull/90

00:51 <marcan> cyrozap: could possibly be a PCIe issue

00:51 <marcan> the SD card controller has the opposite problem: it has an issue on Apple machines that the same chips don't seem to have anywhere else

00:51 <marcan> (<32bit writes don't work)

02:30 <marcan> jannau: someone mentioned a race between gdm and DCP (probably). right now the DRM device is only registered asynchronously of the probe function, right?

02:31 <marcan> can we add a completion or something to either DCP or display subsystem to ensure that when all probe functions have returned DCP is alive?

02:31 <marcan> I think udev & co will only wait for probe to complete effectively, and without blocking there graphical stuff could try to start before DCP is actually there

08:03 <kettenis> marcan: instead of setting the suspend frquency in the cpufreq driver, would marking the lowest state as "opp-suspend" work?

08:05 <marcan> kettenis: not with the current driver, the code would have to be changed to explicitly pick that up from the OPP

08:05 <marcan> like policy->suspend_freq = dev_pm_opp_get_suspend_opp_freq(...) / 1000

08:05 <kettenis> not worth it then ;)

08:25 <marcan> d

08:28 <cyrozap> marcan: I haven't ruled out PCIe as the issue yet, but based on the traces I've analyzed (I have some PCIe analyzer equipment), I don't believe it's an issue at the PCIe layer. I've been working on scripts to parse the trace data (https://github.com/cyrozap/agilent-pcie-analyzer-re), and have some (unpublished, hacked-together) code to do higher-level tracing and analysis of the xHCI traffic, but the

08:28 <cyrozap> xHCI spec is _huge_ so progress on that is slow :/

08:28 <marcan> tell me about it (I wrote the QEMU virtual xHCI emulation...)

08:29 <marcan> it could also be a driver issue though, perhaps a bad interaction with that particular IOMMU driver

08:31 <cyrozap> Yeah, that's the worst part--the bug could be in the hardware (I've already found a couple other hardware bugs), or in the firmware, or in the IOMMU driver, or in how the xhci driver interacts with the IOMMU driver. So, basically _anywhere_.

08:41 <_jannau_> marcan: yes, we probably should use dcp/depext* as components of the drm driver (include/linux/component.h)

08:42 <cyrozap> marcan: btw, if you want to deliberately trigger an IOMMU access fault, you can use the BAR0 registers to access the internal MMIO registers of the host controller's PCIe controller (holy indirection, Batman!) to perform arbitrary DMA reads and writes. I haven't publicly documented that for this generation of the host controller (I have some registers documented for the previous generation, the

08:42 <_jannau_> full device links would be an alternative but I haven't looked into what would be required to create them

08:42 <cyrozap> ASM1142: https://github.com/cyrozap/asmedia-xhc-re/blob/3817694cb8c47f1a959b91cf0b91749aeac3d5af/data/regs-asm1142.yaml#L561-L648), but it's basically the same register interface at a different offset, so I can provide that info if you need it.

08:43 <_jannau_> would be annoying if we had to create custom of device probe for that to add the device links

08:44 <marcan> ah neat, drm_of_component_* is a thing

08:46 <marcan> cyrozap: I already fixed one of these in the FireWire OHCI driver - some JMicron controllers overread queue entries (because they read a fixed size regardless of the queue entry type), so the driver has to leave a bit of space at the end to avoid it ever overreading into unmapped space

08:46 <marcan> it could be something dumb like that

09:05 <cyrozap> marcan: It very well could be. This controller has a limitation where it will read two 32-bit dwords when you tell it to read 1-8 bytes, and four dwords if you tell it to read 9-16 bytes, and while that shouldn't normally cause any issues, it wouldn't surprise me if there were more such quirks in its design. Especially since the PCIe interface has a "software-controlled" part (for use by the 8051) and

09:05 <cyrozap> a "hardware-controlled" part (for the USB data TX/RX), and even if the quirks of the software-controlled part don't cause issues, the as-yet unknown quirks of the hardware-controlled part could. Which is why I'm writing this analyzer code--to find exactly where the bad write happens, since the POWER9 doesn't send a Completer Abort TLP until the device tries reading again, which could be a very long

09:05 <cyrozap> time after the original bad write.

09:06 <marcan> yeah, makes sense

09:48 <ncopa> good morning! how is the 6.1.0 rebase going?

09:49 <ncopa> i wonder if i should give the rebase a try? do you merge v6.1 -> asahi branch or do you rebase on top of v6.1?

09:50 <j`ey> the rebase is done.. but it needs a few extra changes on top

09:50 <j`ey> (asahi-wip is the rebase, but there were some breakages)

09:51 <j`ey> ncopa: the asahi branch is made up of feature/topic branches: the bits/ branches (eg: bits/130-cpufreq)

09:51 <j`ey> each of those is rebased, and then theyre all merged into one branch

09:51 <ncopa> aha

10:00 <ncopa> so, i bought a mbp with the intention to run (and build) alpine linux on it

10:00 <ncopa> would it make sense to add alpine linux as an option for the asahi installer?

10:18 <sven> sure, I assume you’re involved with the alpine Linux project?

10:21 <ncopa> i am

10:22 <mps> sven: ncopa is alpine project leader

10:23 <ncopa> well, founder at least

10:24 <mps> and I hope he will save me from trying to make alpine easier on m1 ;)

10:24 <mps> (though alpine is already easy)

10:26 <j`ey> ncopa: https://github.com/AsahiLinux/asahi-installer/blob/main/data/installer_data.json this is probably the only relevant part of the installer

10:46 <kettenis> marcan: the asahi streams are no longer listed under https://www.youtube.com/@marcan42/videos

10:47 <kettenis> took me some effort yesterday to find the last stream

10:47 <_jannau_> https://www.youtube.com/@marcan42/streams

10:48 <_jannau_> is there somewhere a link to https://www.youtube.com/@marcan42/videos ?

10:48 <kettenis> maybe not

10:48 <kettenis> but that is where I looked

10:49 <j`ey> pretty sure that's just a youtube change?

10:49 <kettenis> because why would I click on "Live" of I wanted to see a stream that had already finished?

10:49 <kettenis> so yes, youtube UI retardedness

10:49 <_jannau_> yes, it's a youtube change splitting (old) live streams from videos

10:53 <kettenis> sorry for the noise

12:08 <sven> ncopa: shouldn’t be an issue then since that probably as official as it gets ;)

12:08 <sven> *that’s

12:09 <sven> we only don’t want to put user-contributed images where there’s no real QA, etc. which would then lead to users spamming us and the distro with big reports neither requested

12:09 <sven> *bug

12:30 <ncopa> yeah, i understand that. i wouldn't want add it there unless i have a plan for long term maintenance

12:53 <ncopa> where are the source to generatae the zip files here? https://de.mirror.asahilinux.org/os/

12:54 <ncopa> I suppose it is here? https://github.com/AsahiLinux/asahi-alarm-builder

13:35 <j`ey> ncopa: yup

13:36 <ncopa> i have read up a bit on the boot loader etc, and got some help from mps. this is a bit complicated :)

13:37 <ncopa> now, my plan is to have an install for building stuff, like kernels etc, and i would prefer not to wipe this dev env when working on the installer

13:38 <ncopa> so, I'm thinking that i should have 2 instances of asahi. one dev env and one smaller that i wipe to test the installer

13:39 <ncopa> if i understand things correcly, i should create a second 2.5GB iBoot/MacOS/m1n1 APFS container + uefi partition + rootfs?

13:40 <j`ey> you can just run the installer a second time, yup

13:40 <ncopa> or can i reuse the APFS container and only create a second uefi + root partition?

13:41 <qyliss> A

13:50 <j`ey> not sure, but I guess if you want to test normal user installs, just having the second copy would be best?

13:51 <ncopa> yeah, that makes sense

13:51 <j`ey> ncopa: which model did you get?

13:51 <kettenis> the APFS and UEFI partition are more or less tied together so that wouldn't make sense

13:51 <ncopa> mpb 14" 2021

13:52 <kettenis> multiple OSes could share a single set of APFS+UEFI, but then they get the same set of firmware and the same device tree

13:53 <kettenis> that means an upgrade of any of those components from one OS may break the other OS

13:54 <kettenis> if your goal is to make alpine work well alongside asahi, you should install asahi first and then create the partitions for alpine

13:54 <ncopa> yeah, i'll create a second APFS+UEFI+rootfs

13:55 <kettenis> and make sure that whenever alpine touches the UEFI partition, it uses "its" UEFI partition (the 2nd one)

15:35 <zzywysm_> ncopa: reminder that you can't redistribute Apple's firmware blobs

15:37 <ncopa> 👍

16:38 <marcan> ncopa: I assume you saw https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-Macs

16:38 <ncopa> i didn't. will read. thanks

16:38 <ncopa> a lot to read...

16:40 <mps> ncopa: oh yes, I forgot to tell you about above url, sorry