From: jerry.hoemann@hp.com To: Matt Fleming <matt@console-pimps.org> Cc: Andrew Fish <afish@apple.com>, edk2-devel@lists.sourceforge.net, Laszlo Ersek <lersek@redhat.com>, linux-efi@vger.kernel.org, Gleb Natapov <gleb@redhat.com>, lkml <linux-kernel@vger.kernel.org>, David Woodhouse <dwmw2@infradead.org>, Matthew Garrett <mjg59@srcf.ucam.org>, Brian Richardson <brian.richardson@intel.com>, Colin Ian King <colin.king@canonical.com>, Randy Wright <rwright@hp.com>, Linn Crosetto <linn.crosetto@hp.com>, terry.lee@hp.com, samer.el-haj-mahmoud@hp.com, randy.pawell@hp.com, chrisp@hp.com, linda.knippers@hp.com, dong.wei@hp.com Subject: Re: [edk2] Corrupted EFI region Date: Fri, 13 Sep 2013 14:38:12 -0600 [thread overview] Message-ID: <20130913203812.GA312@anatevka.fc.hp.com> (raw) In-Reply-To: <20130808101730.GJ2515@console-pimps.org> On Thu, Aug 08, 2013 at 11:17:30AM +0100, Matt Fleming wrote: > > Is it possible to have a switch to turn off the not required behavior > > (hiding EFI implementation bugs) so that bad platforms could be > > detected? This would be a good thing to try on platforms at the > > upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI > > Forum, so the bad behavior can be detected and the vendors can fix the > > issue. > > We don't tend to provide switches for the kernel to turn off workarounds > because users run the risk of inadvertently stopping their machines from > booting correctly. Also, because the major distributions will always > enable the workarounds, the kernel would need to be built manually to > see any kind of informative error message. > ... > > > PS Also maybe it would be possible to key this work around behavior on > > the EFI/UEFI version. So for example no work-around after UEFI v2.3.1? > > That would really depend on who has seen this bug and on which > platforms. Is there a particular reason that mapping the boot services > regions as-is would cause problems? > Matt, We have hit an issue on our new platform in development related to the call of efi_reserve_boot_services() from setup_arch(). The reservation can interfere with allocation of the crash kernel. In pre 3.9(?) kernels, the crash kernel is required to be allocated from physically contiguous memory below 896 MB. Our new platforms are large in both the amount of memory and the amount of IO. This requires large crash kernels for kdump to work. This is even after the work done for makedumpfile v 1.5 to allow it to work with a smaller foot print. One of the problems is that drivers will allocate memory as boot code and/or data in the region < 896 that effectively fragments this memory. With the reservation, we can't reuse the memory when needed for the crash kernels. If we remove the reservation and allow the kernel to reuse the memory, we the reservation of the crash kernel succeeds. This is definitely a problem for distros that are pre 3.9. Probably less so for top of tree, but i haven't been focused there. So we are definitely interested in finding a mechanism to not do this reservation on platforms that don't have the issues described earlier in this thread. thanks, Jerry -- ---------------------------------------------------------------------------- Jerry Hoemann Software Engineer Hewlett-Packard 3404 E Harmony Rd. MS 57 phone: (970) 898-1022 Ft. Collins, CO 80528 FAX: (970) 898-XXXX email: jerry.hoemann@hp.com ----------------------------------------------------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: jerry.hoemann-VXdhtT5mjnY@public.gmane.org To: Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> Cc: Andrew Fish <afish-2kanFRK1NckAvxtiuMwx3w@public.gmane.org>, edk2-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Gleb Natapov <gleb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>, Brian Richardson <brian.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>, Randy Wright <rwright-VXdhtT5mjnY@public.gmane.org>, Linn Crosetto <linn.crosetto-VXdhtT5mjnY@public.gmane.org>, terry.lee-VXdhtT5mjnY@public.gmane.org, samer.el-haj-mahmoud-VXdhtT5mjnY@public.gmane.org, randy.pawell-VXdhtT5mjnY@public.gmane.org, chrisp-VXdhtT5mjnY@public.gmane.org, linda.knippers-VXdhtT5mjnY@public.gmane.org, dong.wei-VXdhtT5mjnY@public.gmane.org Subject: Re: [edk2] Corrupted EFI region Date: Fri, 13 Sep 2013 14:38:12 -0600 [thread overview] Message-ID: <20130913203812.GA312@anatevka.fc.hp.com> (raw) In-Reply-To: <20130808101730.GJ2515-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> On Thu, Aug 08, 2013 at 11:17:30AM +0100, Matt Fleming wrote: > > Is it possible to have a switch to turn off the not required behavior > > (hiding EFI implementation bugs) so that bad platforms could be > > detected? This would be a good thing to try on platforms at the > > upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI > > Forum, so the bad behavior can be detected and the vendors can fix the > > issue. > > We don't tend to provide switches for the kernel to turn off workarounds > because users run the risk of inadvertently stopping their machines from > booting correctly. Also, because the major distributions will always > enable the workarounds, the kernel would need to be built manually to > see any kind of informative error message. > ... > > > PS Also maybe it would be possible to key this work around behavior on > > the EFI/UEFI version. So for example no work-around after UEFI v2.3.1? > > That would really depend on who has seen this bug and on which > platforms. Is there a particular reason that mapping the boot services > regions as-is would cause problems? > Matt, We have hit an issue on our new platform in development related to the call of efi_reserve_boot_services() from setup_arch(). The reservation can interfere with allocation of the crash kernel. In pre 3.9(?) kernels, the crash kernel is required to be allocated from physically contiguous memory below 896 MB. Our new platforms are large in both the amount of memory and the amount of IO. This requires large crash kernels for kdump to work. This is even after the work done for makedumpfile v 1.5 to allow it to work with a smaller foot print. One of the problems is that drivers will allocate memory as boot code and/or data in the region < 896 that effectively fragments this memory. With the reservation, we can't reuse the memory when needed for the crash kernels. If we remove the reservation and allow the kernel to reuse the memory, we the reservation of the crash kernel succeeds. This is definitely a problem for distros that are pre 3.9. Probably less so for top of tree, but i haven't been focused there. So we are definitely interested in finding a mechanism to not do this reservation on platforms that don't have the issues described earlier in this thread. thanks, Jerry -- ---------------------------------------------------------------------------- Jerry Hoemann Software Engineer Hewlett-Packard 3404 E Harmony Rd. MS 57 phone: (970) 898-1022 Ft. Collins, CO 80528 FAX: (970) 898-XXXX email: jerry.hoemann-VXdhtT5mjnY@public.gmane.org ----------------------------------------------------------------------------
next prev parent reply other threads:[~2013-09-13 20:38 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-31 20:54 Corrupted EFI region Borislav Petkov 2013-07-31 20:54 ` Borislav Petkov 2013-07-31 20:58 ` Matthew Garrett 2013-07-31 20:58 ` Matthew Garrett 2013-07-31 21:51 ` Borislav Petkov 2013-07-31 21:51 ` Borislav Petkov 2013-07-31 21:54 ` Matthew Garrett 2013-07-31 21:54 ` Matthew Garrett 2013-08-01 16:51 ` Borislav Petkov 2013-08-01 16:51 ` Borislav Petkov 2013-07-31 21:55 ` David Woodhouse 2013-07-31 21:55 ` David Woodhouse 2013-08-01 16:49 ` Borislav Petkov 2013-08-01 16:49 ` Borislav Petkov 2013-08-05 11:27 ` [edk2] " Laszlo Ersek 2013-08-05 11:27 ` Laszlo Ersek 2013-08-05 13:02 ` Borislav Petkov 2013-08-05 13:02 ` Borislav Petkov 2013-08-05 13:39 ` Laszlo Ersek 2013-08-05 13:39 ` Laszlo Ersek 2013-08-05 14:03 ` Borislav Petkov 2013-08-05 14:03 ` Borislav Petkov 2013-08-05 14:27 ` Laszlo Ersek 2013-08-05 14:27 ` Laszlo Ersek 2013-08-05 14:40 ` Borislav Petkov 2013-08-05 14:40 ` Borislav Petkov 2013-08-05 15:15 ` Laszlo Ersek 2013-08-05 15:15 ` Laszlo Ersek 2013-08-05 15:34 ` James Bottomley 2013-08-05 15:34 ` James Bottomley 2013-08-05 16:27 ` Laszlo Ersek 2013-08-05 16:27 ` Laszlo Ersek 2013-08-05 16:12 ` Borislav Petkov 2013-08-05 16:12 ` Borislav Petkov 2013-08-05 16:41 ` Laszlo Ersek 2013-08-05 16:41 ` Laszlo Ersek 2013-08-05 16:47 ` Borislav Petkov 2013-08-05 16:47 ` Borislav Petkov 2013-08-05 17:00 ` Kinney, Michael D 2013-08-05 17:00 ` Kinney, Michael D 2013-08-05 17:09 ` Laszlo Ersek 2013-08-05 17:09 ` Laszlo Ersek 2013-08-05 21:26 ` Laszlo Ersek 2013-08-05 21:26 ` Laszlo Ersek 2013-08-05 22:08 ` Borislav Petkov 2013-08-05 22:08 ` Borislav Petkov 2013-08-06 14:10 ` Borislav Petkov 2013-08-06 14:10 ` Borislav Petkov 2013-08-06 15:31 ` Laszlo Ersek 2013-08-06 15:31 ` Laszlo Ersek 2013-08-07 15:19 ` Borislav Petkov 2013-08-07 17:23 ` Andrew Fish 2013-08-07 17:23 ` Andrew Fish 2013-08-07 20:19 ` Matt Fleming 2013-08-07 20:19 ` Matt Fleming 2013-08-07 20:24 ` Matt Fleming 2013-08-07 20:24 ` Matt Fleming 2013-08-07 21:10 ` Andrew Fish 2013-08-07 21:10 ` Andrew Fish 2013-08-07 21:23 ` Matthew Garrett 2013-08-08 10:17 ` Matt Fleming 2013-08-08 10:17 ` Matt Fleming 2013-08-08 13:46 ` Andrew Fish 2013-08-08 13:46 ` Andrew Fish 2013-09-02 8:19 ` Matt Fleming 2013-09-02 8:19 ` Matt Fleming 2013-09-13 20:38 ` jerry.hoemann [this message] 2013-09-13 20:38 ` jerry.hoemann-VXdhtT5mjnY 2013-09-16 10:59 ` Matt Fleming 2013-09-16 10:59 ` Matt Fleming 2013-09-16 11:50 ` Laszlo Ersek 2013-09-16 11:50 ` Laszlo Ersek 2013-09-16 15:57 ` Josh Triplett 2013-09-16 15:57 ` Josh Triplett 2013-09-16 16:25 ` Laszlo Ersek 2013-09-16 16:25 ` Laszlo Ersek 2013-09-16 16:27 ` Matthew Garrett 2013-09-16 16:27 ` Matthew Garrett 2013-09-16 16:29 ` Josh Triplett 2013-09-16 16:29 ` Josh Triplett 2013-09-18 19:24 ` jerry.hoemann 2013-09-18 19:24 ` jerry.hoemann-VXdhtT5mjnY 2013-09-20 9:06 ` Matt Fleming 2013-09-20 9:06 ` Matt Fleming 2013-08-07 17:49 ` Laszlo Ersek 2013-08-07 17:49 ` Laszlo Ersek 2013-08-08 15:02 ` Borislav Petkov 2013-08-08 15:02 ` Borislav Petkov 2013-08-08 21:45 ` Brian J. Johnson 2013-08-08 21:45 ` Brian J. Johnson 2013-08-18 7:33 ` Jordan Justen 2013-08-18 7:33 ` Jordan Justen 2013-08-05 15:50 ` Andrew Fish 2013-08-05 15:50 ` Andrew Fish 2013-08-05 18:12 ` Borislav Petkov 2013-08-05 18:12 ` Borislav Petkov 2013-08-05 21:37 ` H. Peter Anvin 2013-08-05 21:37 ` H. Peter Anvin 2013-08-05 21:41 ` Borislav Petkov 2013-08-05 21:41 ` Borislav Petkov 2013-08-05 21:49 ` H. Peter Anvin 2013-08-05 21:49 ` H. Peter Anvin 2013-08-05 21:55 ` Laszlo Ersek 2013-08-05 21:55 ` Laszlo Ersek 2013-08-05 22:52 ` James Bottomley 2013-08-05 22:52 ` James Bottomley 2013-08-06 7:26 ` Laszlo Ersek 2013-08-06 7:26 ` Laszlo Ersek
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=20130913203812.GA312@anatevka.fc.hp.com \ --to=jerry.hoemann@hp.com \ --cc=afish@apple.com \ --cc=brian.richardson@intel.com \ --cc=chrisp@hp.com \ --cc=colin.king@canonical.com \ --cc=dong.wei@hp.com \ --cc=dwmw2@infradead.org \ --cc=edk2-devel@lists.sourceforge.net \ --cc=gleb@redhat.com \ --cc=lersek@redhat.com \ --cc=linda.knippers@hp.com \ --cc=linn.crosetto@hp.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=matt@console-pimps.org \ --cc=mjg59@srcf.ucam.org \ --cc=randy.pawell@hp.com \ --cc=rwright@hp.com \ --cc=samer.el-haj-mahmoud@hp.com \ --cc=terry.lee@hp.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.