* Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 11 July 2018 at 13:14, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > > * Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > >> On 11 July 2018 at 12:13, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > >> > > >> > * Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > >> > > >> >> The following changes since commit 1e4b044d22517cae7047c99038abb444423243ca: > >> >> > >> >> Linux 4.18-rc4 (2018-07-08 16:34:02 -0700) > >> >> > >> >> are available in the Git repository at: > >> >> > >> >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent > >> >> > >> >> for you to fetch changes up to d7f2e972e702d329fe11d6956df99dfc31211c25: > >> >> > >> >> efi/x86: remove pointless call to PciIo->Attributes() (2018-07-11 10:52:46 +0200) > >> >> > >> >> ---------------------------------------------------------------- > >> >> A single fix for the x86 PCI I/O protocol handling code that got > >> >> broken for mixed mode (64-bit Linux/x86 on 32-bit UEFI) after a > >> >> fix was applied in -rc2 to fix it for ordinary 64-bit Linux/x86. > >> > > >> > Just curious, because it's unclear from the changelog, what was the symptom, a > >> > boot hang, instant reboot, or some other misbehavior? > >> > >> Hans reported that his mixed mode tablet would not boot at all any > >> more, but enter a reboot loop without any logs printed by the kernel. > >> > >> > Also, what's the scope of > >> > the fix: were all 64-bit on 32-bit UEFI mixed-mode bootups affected, or only a > >> > certain subset? > >> > > >> > >> Any mixed mode system with PCI is likely to be affected. I have added > >> a QEMU mixed mode config to my boot test environment to catch errors > >> like this one. > > > > Ok, I've added this information to the commit - will be useful to backporters, > > to judge the severity of the bug fixed. > > > > Perhaps it wasn't clear from the commit log that only v4.18-rc2 and > later is affected by the mixed mode issue, since that is when a fix > for ordinary 64-bit x86 was applied that affected v4.18-rc1. Ah, ok. Still, if for whatever reason the commit that introduced the problem is backported, this one will be too. The chain of sha1's seemed rather long, so there's a chance for that. > However, the EFI stub code is not expected to expand that much, and so for the > time being, I'm fine with a combination of review and rigorous testing Fair enough! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
