ruscurdotau

Author here, having both buses is a valid configuration and completely expected for running Linux under the PowerVM hypervisor.

Latest upstream kernel should work, because every time I send patches to arch/powerpc I manage to break one legacy platform or another, so there's still people testing them.

Ubuntu is probably the best option there

I tend to debug like a caveman so I don't know if I'm the right person for that - in this case, I just went through config options (make menuconfig) and turned on CONFIG_DRM_I915_DEBUG and a bunch of associated things, then built and booted and played around. Got nothing useful out of that but I didn't spend a huge amount of time diving into the driver.

In this case it's pretty different to regular kernel debug because I'm not debugging kernel code itself, I'm trying to glean more information out of hardware that I have no knowledge of, it's not as simple as "there's a bug on line X and I need to find out why this pointer is invalid" etc.

Appreciate the response. My main advice would be to try and be as upstream-focused as possible. Partnering with distros is great, but if your hardware is well supported upstream, you cover everything anyone would ever want to use. If there's fixes that need to go into older distro kernel it's typically trivial to get them backported if they're already upstream. Making Ubuntu work fixes Ubuntu, making upstream work fixes everything - and you're gonna have a lot of users that like living on the edge with distros that follow upstream closely like Arch and Fedora anyway.

Critically, the bulk of the resources on the distro side that would test your hardware as part of their regular testing are quite distant from upstream (Ubuntu is the closest, Fedora is largely community driven, RHEL and SLES aren't appealing desktop distros for most users), so having some upstream testing in-house would probably help a lot in getting ahead of problems.

Maybe you could try and get boards into kernelci.org? They're mostly focused on ARM SoCs but they have x86 boards in there too, though I don't think there's much on the desktop side. The i915 driver which has caused me much pain and suffering over the last couple of weeks has some test automation that could be run too: https://intel-gfx-ci.01.org/

I'm sure there has to be more upstream automated testing initiatives for laptops but I'm not super familiar with that space.

Oh and if anyone's interested I gave a talk back in 2020 about how Linux kernel testing is fundamentally boned here: https://www.youtube.com/watch?v=9Fzd6MapG3Y

Good luck!

Linus "Tech Tips" Sebastian introduced the Framework team to the highest level people at AMD he knew last year after his investment in Framework but as of his update video a couple of months ago, nothing really went anywhere.

I highly doubt it's a fanboying issue, they're a small company with big challenges and supporting multiple platforms is not easy at any scale. They also wouldn't want to say anything positive or negative that could sour relations with AMD or other partners in future.

My guess is they make a nice margin on those Windows licenses and they figure if you're going to install your own OS you might as well put in your own SSD and RAM. It does suck for consumers though.

Author here, I wrote this in the hope I wouldn't have to solve my own laptop problems...

Author here, I don't necessarily think they need an in-house kernel dev, but it wouldn't hurt. Mainly they need someone familiar with the ecosystem that knows how upstream works, knows how to interact with distros, knows how to do some kernel debugging themselves, etc. Hiring a kernel dev makes sense because they'd already have those skills and can help out on the firmware side for Framework as well.

Realistically it looks to me like they need a reasonably technical desktop Linux user with social skills and anything else is a bonus, but I have no idea what skills they have internally