Arnd Bergmann
unread,Jul 9, 2024, 3:33:26 PMJul 9Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Jeff Johnson, Kalle Valo, linux-...@vger.kernel.org, ath...@lists.infradead.org, kasa...@googlegroups.com, Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino
On Tue, Jul 9, 2024, at 17:29, Jeff Johnson wrote:
> On 7/8/2024 10:44 PM, Arnd Bergmann wrote:
>> On Tue, Jul 9, 2024, at 05:55, Jeff Johnson wrote:
>
> I picked my favorite to begin with, enabling KASAN (which in turn enabled a
> few others). The resulting kernel did not boot for me (just saw a black screen
> after the GRUB menu). Diff between working and non-working config is below.
Ok, good to know. I've added the KASAN developers to Cc now, maybe
they have already seen reports of x86 kernels failing with gcc-14?
> I then downloaded and built the config you supplied. With that I have the same
> behavior as my original config, the display is frozen with:
> Loading initial ramdisk ...
Interesting, so the same config that works for me fails on your
machine. I can see three possible reasons for this:
- qemu vs hardware -- Can you try running this kernel in
qemu-system-x86_64 to see if that still boots
- kernel version -- it's possible that this is a known bug
that was already fixed in the 6.10-rc7 kernel source I
tried, or that your source tree has a new bug that I don't.
Which version did you try?
- cross-compile vs native compile -- It's possible that my
cross-built native x86_64 compiler has a bug that is not
in natively built gcc binaries, or in the cross compiler
I have on ARM. I've mostly ruled this one out by building
the same kernel using the x86 compilers through qemu-user.
Arnd