mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Ard Biesheuvel <ardb@kernel.org>, Clayton Craft <clayton@craftyguy.net>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-efi@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	regressions@lists.linux.dev
Subject: Re: x86_64 32-bit EFI mixed mode boot broken
Date: Sun, 24 Mar 2024 15:49:23 +0100	[thread overview]
Message-ID: <a3aae375-5582-46e4-866b-6a81641998af@redhat.com> (raw)
In-Reply-To: <CAMj1kXGzH4TiwvSF3bZsJpuuWf04Ri_852fUMTdH8pLRaH3+Yg@mail.gmail.com>

Hi,

On 3/21/24 11:48 PM, Ard Biesheuvel wrote:
> (cc Hans)
> 
> On Thu, 21 Mar 2024 at 23:05, Clayton Craft <clayton@craftyguy.net> wrote:
>>
>> I've been chasing a problem with 32-bit EFI mixed mode booting on two different
>> (x86_64) Intel Bay Trail platforms, where the system reboots or hangs seemingly
>> very early somewhere before or after loading the kernel. I've not been able to
>> get any output from the kernel or stub over efifb when the issue happens[0], and
>> do not have serial console access on these systems.
>>
>> v6.8 fails for me, and presumably so does everything back to v6.2. v6.1 is able
>> to boot OK on these platforms with mixed mode, and it looks like there are a lot
>> of changes from 6.1..6.2 for EFI/mixed mode booting.
> 
> v6.1 just received some EFI related backports, so please check the
> latest v6.1.y as well.
> 
>> I did managed to bisect the
>> issue to:
>>
>>         commit e2ab9eab324cdf240de89741e4a1aa79919f0196
>>         Author: Ard Biesheuvel <ardb@kernel.org>
>>         Date:   Tue Nov 22 17:10:02 2022 +0100
>>
>>             x86/boot/compressed: Move 32-bit entrypoint code into .text section
>>
>> However I'm not sure how to proceed from here, or if my bisect is all that
>> useful since the commit seems to be in the middle of a bunch of changes I do not
>> understand. I've been using systemd-boot to test this (both the full bootloader
>> and UKI w/ the sd-boot stub). Is 32-bit mixed mode on x86_64 working for others?
>>
> 
> I usually test on 32-bit OVMF built with LOAD_X64_ON_IA32_ENABLE,
> which allows the use of the compat entry point. This is different from
> the EFI handover protocol, and I am not sure which one you are using.
> 
> I have never had any reports, or noticed any issues myself. Last time
> I tried (some weeks ago) it was working for me.
> CC'ing Hans who may have more data points.

I've been offline for most of the week and I see that in the mean time
you seem to have found a fix, great.

FWIW I have been booting everything up to 6.8.0 on my own mixed-mode
Bay Trail tablets without issues, so the problem seems to be specific to
certain BIOS-es.

Please Cc me on the final fix, then I can test that early and double check
that things don't regress on other mixed-mode Bay Trail devices.

Regards,

Hans





  parent reply	other threads:[~2024-03-24 14:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21 22:05 Clayton Craft
2024-03-21 22:48 ` Ard Biesheuvel
2024-03-22  0:06   ` Clayton Craft
2024-03-22 12:52     ` Ard Biesheuvel
2024-03-22 16:18       ` Clayton Craft
2024-03-22 16:51         ` Ard Biesheuvel
2024-03-22 17:57           ` Clayton Craft
2024-03-22 18:30             ` Ard Biesheuvel
2024-03-22 19:34               ` Clayton Craft
2024-03-23 12:39                 ` Ard Biesheuvel
2024-03-23 17:18                   ` Ard Biesheuvel
2024-03-24  5:53                     ` Clayton Craft
2024-03-24 14:49   ` Hans de Goede [this message]
2024-03-24 17:43     ` Ard Biesheuvel
2024-03-24 20:45       ` Clayton Craft
2024-03-24 20:53         ` Ard Biesheuvel
2024-04-01 22:44           ` Clayton Craft
2024-04-02  6:25             ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a3aae375-5582-46e4-866b-6a81641998af@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=clayton@craftyguy.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=regressions@lists.linux.dev \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®