On Sat, Jul 31, 2021 at 9:19 AM jarmo <oh1mrr@xxxxxx> wrote: > > Now working. Just changed screen resolution from 1280x720 16:9 > which was good for my old eyes :) to 1920x1080. Only bad thing > is, that texts are so small, have to tri increas font size... > But, booting and running, so SOLVED... It's a work around that suggests there's still a bug here, if an older kernel can do 1280x720 but a new kernel cannot. Sounds somewhat like this but the kernel version doesn't match up. https://gitlab.freedesktop.org/drm/amd/-/issues/1589 Consider filing a new upstream bug there. Attached dmesg for both non-working and working kernels. And also lspci -vvnn (attached as file). The best way to get this resolved though, is tedious. Kernel bisect. You know the working kernel is 5.12 series and the non-working kernel is 5.13 series. If you decide to bisect, it's easiest to test already built kernels in koji to narrow down when the problem started. Some of the early 5.13-rc kernels for fc35 were built against a new glibc which had an inadvertent ABI break (as I understand it) and those kernels wouldn't install for me on Fedora 34. But I don't remember when they stopped working or resumed working...so this particular kernel series might be harder to test with prebuilt kernels in koji than it ordinarily would be. But the gist of the strategy is to test 5.13-rc7, rc5, rc3, rc1 to see if the problem goes away as you work backward. You are trying to understand the last known working kernel and first known broken kernel. That'll help upstream figure out what commit broke it. Or you could start with the first 5.13 build in Fedora which was kernel-5.13.0-0.rc0.20210428gitacd3d2859453.2.fc35 Note that this contains a partial git hash, acd3d2859453 which helps distinguish between these "not really rc builds" because officially there's no such thing as rc0. Next you'll work you way up the rc0 kernels and see which one breaks (has the problem). Viola, first known bad kernel. It is also possible to do 'git bisect' on the kernel's mainline git, and git bisect does most of the work. But it's slow because you get to rebuild the kernel (just 'make -j4' is fine) in between each git checkout step. But then all you have to do is boot it to test, and either it works or doesn't, and you report this as "git bisect good" or "git bisect bad" and git tracks this as it continues doing checkouts to narrow down to exactly which commit is the bad one. Everyone has their own preference I suppose, and mine is to just use the upstream kernel mainline git, and build the kernel the upstream way. I do use Fedora config files, e.g. cp /boot/config-5.12... .config to create a .config in the kernel source directory. https://kernelnewbies.org/KernelBuild Clone the latest rc tree. That's mainline. For this kind of problem you don't need to test any of the stable updates because the problem must have been introduced during the 5.13 development cycle and just didn't get caught for some reason. That's the basics. It's not that hard. But there's lots of tricks and personal preferences that are all non-obvious, so if you get stuck, head to irc.libera.chat or matrix.org and ask in #fedora-qa or #fedora-kernel if you get stuck. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
