On 1/22/24 11:20, Uwe Kleine-König wrote:
On Thu, Jan 18, 2024 at 09:04:05PM +0100, Mirsad Todorovac wrote:
On 1/18/24 08:45, Uwe Kleine-König wrote:
Hello Mirsad,
On Wed, Jan 17, 2024 at 07:47:49PM +0100, Mirsad Todorovac wrote:
On 1/16/24 01:32, Mirsad Todorovac wrote:
On the Ubuntu 22.04 LTS Jammy platform, on a mainline vanilla torvalds tree kernel, the boot
freezes upon first two lines and before any systemd messages.
(Please find the config attached.)
Bisecting the bug led to this result:
marvin@defiant:~/linux/kernel/linux_torvalds$ git bisect good
d97a78423c33f68ca6543de510a409167baed6f5 is the first bad commit
commit d97a78423c33f68ca6543de510a409167baed6f5
Merge: 61da593f4458 689237ab37c5
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Fri Jan 12 14:38:08 2024 -0800
[...]
Hope this helps.
P.S.
As I see that this is a larger merge commit, with 5K+ lines changed, I don't think I can
bisect further to determine the culprit.
Actually it's not that hard. If a merge commit is the first bad commit
for a bisection, either the merge wasn't done correctly (less likely,
looking at d97a78423c33f68ca6543de510a409167baed6f5 I'd bet this isn't
the problem); or changes on different sides conflict or you did
something wrong during bisection.
To rule out the third option, you can just retest d97a78423c33,
61da593f4458 and 689237ab37c5. If d97a78423c33 is the only bad one, you
did it right.
This was confirmed.
Then to further debug the second option you can find out the offending
commit on each side with a bisection as follows, here for the RHS (i.e.
689237ab37c5):
git bisect start 689237ab37c5 $(git merge-base 61da593f4458 689237ab37c5)
and then in each bisection step do:
git merge --no-commit 61da593f4458
test if the problem is present
git reset --hard
git bisect good/bad
In this case you get merge conflicts in drivers/video/fbdev/amba-clcd.c
and drivers/video/fbdev/vermilion/vermilion.c. In the assumption that
you don't have these enabled in your .config, you can just ignore these.
Side note: A problem during bisection can be that the .config changes
along the process. You should put your config into (say)
arch/x86/configs/lala_defconfig and do
make lala_defconfig
before building each step to prevent this.
I must have done something wrong:
marvin@defiant:~/linux/kernel/linux_torvalds$ git bisect log
# bad: [689237ab37c59b9909bc9371d7fece3081683fba] fbdev/intelfb: Remove driver
# good: [de927f6c0b07d9e698416c5b287c521b07694cac] Merge tag 's390-6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
git bisect start '689237ab37c5' 'de927f6c0b07d9e698416c5b287c521b07694cac'
# good: [d9f25b59ed85ae45801cf45fe17eb269b0ef3038] fbdev: Remove support for Carillo Ranch driver
git bisect good d9f25b59ed85ae45801cf45fe17eb269b0ef3038
# good: [e2e0b838a1849f92612a8305c09aaf31bf824350] video/sticore: Remove info field from STI struct
git bisect good e2e0b838a1849f92612a8305c09aaf31bf824350
# good: [778e73d2411abc8f3a2d60dbf038acaec218792e] drm/hyperv: Remove firmware framebuffers with aperture helper
git bisect good 778e73d2411abc8f3a2d60dbf038acaec218792e
# good: [df67699c9cb0ceb70f6cc60630ca938c06773eda] firmware/sysfb: Clear screen_info state after consuming it
git bisect good df67699c9cb0ceb70f6cc60630ca938c06773eda
FTR: Now that you identified df67699c9cb0ce as the culprit, calling
git bisect good on it was wrong, so something was fishy in your testing
and it's no surprise the bisection found a wrong result.
Copy that. But it is my first attempt on a bisect of a merge commit, so I will simply
ask to be forgiven. Maybe I forgot "git reset --hard" in some step.
I have to do a thorough homework on the merge commit magic.
Best regards,
Mirsad
Best regards
Uwe
