[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130626131200.GN22026@console-pimps.org>
Date: Wed, 26 Jun 2013 14:12:00 +0100
From: "matt@...sole-pimps.org" <matt@...sole-pimps.org>
To: Zachary Bobroff <zacharyb@....com>
Cc: "'H. Peter Anvin'" <hpa@...or.com>,
'Jan Beulich' <jbeulich@...e.com>,
"matt.fleming@...el.com" <matt.fleming@...el.com>,
"mjg59@...f.ucam.org" <mjg59@...f.ucam.org>,
Joey Lee <JLee@...e.com>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86, efi: retry ExitBootServices() on failure
On Thu, 20 Jun, at 06:04:50PM, Zachary Bobroff wrote:
> All,
>
> I am attaching a further updated version of eboot.c . We removed the
> low_alloc routine from the exit_boot function only. We also removed
> the goto statements(sorry we just aren’t huge fans of goto's in c, you
> can change it back to be goto oriented if you want though) and put it
> in a loop that is counting down from retry count. You can see the
> loop is based upon this conditional:
It would be much easier to review these changes if you sent them as a
patch against a git tree, using git to generate the patch. Failing that,
even a plain old diff-format file would be acceptable.
> while((ExitRetryCount > 0) && (status != EFI_SUCCESS)) {
>
> So we have currently set ExitRetryCount to 2 (a couple of lines above):
> int ExitRetryCount = 2;
>
> However, I have a suggestion and im not entirely sure how difficult it
> would be, im just suggesting it might not be a bad idea. We can
> initialize this ExitRetryCount to be some default value, but if
> grub(or a different bootloader) passes some updated value,
> ExitRetryCount could be updated with this value. Myself, I don’t know
> the level of complexity it creates pulling a kernel parameter, but
> given a decent example, I could see about adding that support.
> Allowing passing of a parameter could eliminate problems with the
> systems that may be out of specification.
We try to pull workarounds for these problems into the kernel, rather
than relying on bootloaders to pass in the necessary flags. People
rarely want to update their boot loaders, but most distributions release
updates for installed kernels semi-regularly.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists