[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2q2t7mgnpuk2t7wq2tmymxv72oki4uetojkz72xofn7wh45l64@smk3wi6zw54g>
Date: Mon, 22 Jan 2024 11:20:50 +0100
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Helge Deller <deller@....de>, "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hans de Goede <hdegoede@...hat.com>,
Huacai Chen <chenhuacai@...nel.org>, Javier Martinez Canillas <javierm@...hat.com>,
Linus Walleij <linus.walleij@...aro.org>, Prathu Baronia <prathubaronia2011@...il.com>,
Sam Ravnborg <sam@...nborg.org>, Sui Jingfeng <suijingfeng@...ngson.cn>,
Thomas Zimmermann <tzimmermann@...e.de>, dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
linux-parisc@...r.kernel.org
Subject: Re: [BUG][BISECTED] Freeze at loading init ramdisk
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@...iant:~/linux/kernel/linux_torvalds$ git bisect good
> > > > d97a78423c33f68ca6543de510a409167baed6f5 is the first bad commit
> > > > commit d97a78423c33f68ca6543de510a409167baed6f5
> > > > Merge: 61da593f4458 689237ab37c5
> > > > Author: Linus Torvalds <torvalds@...ux-foundation.org>
> > > > 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@...iant:~/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.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists