Am 09.11.2019 um 18:24 schrieb Kyle Evans:> On Sat, Nov 9, 2019 at 10:42 AM Chris Ross <cross+freebsd at
distal.com> wrote:
>> On Thu, Nov 07, 2019 at 02:53:25PM -0500, Chris Ross wrote:
>>>>> On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer <julian
at freebsd.org> wrote:
>>>>>> You could try some bisection back along the 12
branch..
>>> Yeah. I was hoping for an easier path, but. I can try slogging
back
>>> through stable-12 a month or two at a time.
>> Okay. I spent a bunch of time moving around stable-12 by date, and
>> an ISO build from stable-12 as of 2019-10-14 works (rev 353483), and
>> 2019-10-15 (rev 353541) does not.
?>> That helps- thanks! I'm CC'ing tsoome@, as this is basically
just
>> r353501 in that range. Can you give the latest -CURRENT snapshot boot
>> as another data point?
I can confirm that reverting r353501 on stable/12 from yesterday solves
my problem with booting the setup media.
(My symptoms on ESXi 6.7 guest using SATA vODD: r355263 loads
kernel/modules but stucks with 100%CPU while trying to hand over to kernel)
My svn skills are as lousy as my C skills, but to me it seems like a
mismerge.
The attached patch (against r355263, stable/12 from yesterday _without_
reverting r353501!) solves my problem.
But please could someone familiar with svn&code inspect what happened
and verify/correct/commit the fix.
Solving my problem doesn't mean my approach is correct.? I don't know
HandleProtocol() nor OpenProtocol() nor did I read the code trying to
understand what's happening in "proto.c".
I just text-edited a obvious cannotbe? Maby I missed a lot of things?
In case attachment won't make it to the list (white space nits to be
expected):
Index: stand/efi/boot1/proto.c
==================================================================---
stand/efi/boot1/proto.c???? (Revision 355263)
+++ stand/efi/boot1/proto.c???? (Arbeitskopie)
@@ -61,7 +61,7 @@
??????? int preferred;
??????? /* Figure out if we're dealing with an actual partition. */
-?????? status = BS->HandleProtocol(h, &DevicePathGUID, (void
**)&devpath);
+?????? status = OpenProtocolByHandle(h, &DevicePathGUID, (void
**)&devpath);
??????? if (status == EFI_UNSUPPORTED)
??????????????? return (0);
@@ -77,7 +77,7 @@
??????????????? efi_free_devpath_name(text);
??????? }
?#endif
-?????? status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void
**)&blkio);
+?????? status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void
**)&blkio);
??????? if (status == EFI_UNSUPPORTED)
??????????????? return (0);
Index: stand/efi/gptboot/proto.c
==================================================================---
stand/efi/gptboot/proto.c?? (Revision 355263)
+++ stand/efi/gptboot/proto.c?? (Arbeitskopie)
@@ -146,7 +146,7 @@
??????? EFI_STATUS status;
??????? /* Figure out if we're dealing with an actual partition. */
-?????? status = BS->HandleProtocol(h, &DevicePathGUID, (void
**)&devpath);
+?????? status = OpenProtocolByHandle(h, &DevicePathGUID, (void
**)&devpath);
??????? if (status != EFI_SUCCESS)
??????????????? return;
?#ifdef EFI_DEBUG
@@ -169,7 +169,7 @@
??????????????????????? return;
??????????????? }
??????? }
-?????? status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void
**)&blkio);
+?????? status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void
**)&blkio);
??????? if (status != EFI_SUCCESS) {
??????????????? DPRINTF("Can't get the block I/O protocol
block\n");
??????????????? return;
But reading this thread leaves one question:
Does 12.1-RELEASE refuse to boot on regular ESXi UEFI guests!?
Thanks,
-Harry
(resent due to ?expired? subscription?; original message was addressed
to all other recipients)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efiloader_MFCfix-HandleProtocol2OpenProtocol.patch
Type: text/x-patch
Size: 1526 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20191202/df8905a8/attachment.bin>