There have been patches floating around for a while now to ensure that GPUs work; the current approach, AFAIK, is not upstreamable and was rejected. When rebasing them onto Linux 7.1.9, I asked Claude to refactor to make something upstreamable. I promptly decided to update my Ampere box to Fedora 45, which has a 7.2 kernel. So I fixed a couple of minor issues to get them to apply there. I have tested on my ADLink box, and they seem okay with my minimal use. I would appreciate some wider testing before trying to take them upstream and possibly someone smarter than me to fix any issues with them. linux-ampere-altra-erratum-pcie-65/v7.2 at main · ausil/linux-ampere-altra-erratum-pcie-65 · GitHub . The two patches live in that directory of my fork
Why do you think this will be accepted upstream where the old patches wouldn’t? This looks like the same approach to me.
GitHub - AmpereComputing/linux-ampere-altra-erratum-pcie-65: Kernel patches with workaround for Altra erratum PCIE_65 · GitHub is the official upstream repo by Ampere Computing.
Is Ampere’s repo officially dead and is ausil’s repo its (de facto) official successor?
Chimera Linux has been maintaining the patch with up to date linux kernels for a long time. You could just pull the patch from their git. I don’t see what passing the patch through AI is going to do to make it upstreamable. It’s the same workaround approach as far as I can tell; just because you told the AI to make it upstreamable doesn’t make it so.
Please offer correction is I’m missing something.
I am not sure they will be accepted. the biggest difference is that Affected apertures are learned per root complex from the matching PCI host bridge’s own resource windows (drivers/pci/quirks.c’s early fixup on the RC’s PCI ID calls into arch/arm64/kernel/altra_82288.c), rather than assumed from fixed physical-address ranges, since aperture placement is board/firmware dependent and Altra platforms may expose several independently-windowed root complexes.
Most of that came from the commit message. and it makes sense to me why it may be accepted, but this is not my strongest suite. I wanted to kick off a discussion because carrying patches and maintaining a kernel fork for it is really not ideal, but it is the only way I can use the system as I want to. This bug is a major hindrance to using the hardware.
My fork is definelty not a sucessor, it was something I threw together to facilitate a discussion and hopefully get people smarter than me to talk and actually come up with a solution