>> I think i can go to a date based black list, that removes the manual
>> step. System running firmware before certain date assumes we need
>> to do the work around. If firmware is newer than that date, we don't
>> use the workaround. Blacklist overrides and allows current behavior
>> for new
I think i can go to a date based black list, that removes the manual
step. System running firmware before certain date assumes we need
to do the work around. If firmware is newer than that date, we don't
use the workaround. Blacklist overrides and allows current behavior
for new firmware that
On Mon, Nov 18, 2013 at 5:32 PM, H. Peter Anvin wrote:
> On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>>
>> And IOMMU support is very flaky with kdump. And IOMMU's can be turned
>> off at command line. And that would force one to remove crahkernel_low=0.
>> So change of one command line option
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>
> And IOMMU support is very flaky with kdump. And IOMMU's can be turned
> off at command line. And that would force one to remove crahkernel_low=0.
> So change of one command line option forces change of another. It is
> complicated.
>
> Also there
On Mon, Nov 18, 2013 at 11:34:04AM -0800, Yinghai Lu wrote:
> On Mon, Nov 18, 2013 at 7:32 AM, Vivek Goyal wrote:
> >> You may need bunch of PCIe cards installed.
> >>
> >> The system with 6TiB + 16 PCIe cards, second kernel OOM.
> >> The system with 4.5TiB + 16 PCIe cards, second kernel works
On Mon, Nov 18, 2013 at 7:32 AM, Vivek Goyal wrote:
>> You may need bunch of PCIe cards installed.
>>
>> The system with 6TiB + 16 PCIe cards, second kernel OOM.
>> The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore
>> dumped.
>
> What's the distro you are testing with? Do
On Mon, Nov 18, 2013 at 10:29:18AM -0800, H. Peter Anvin wrote:
> On 11/18/2013 07:22 AM, Vivek Goyal wrote:
> >
> > And if that's true, then reserving 72M extra due to crashkernel=X,high
> > should not be a big issue in KVM guests. It will still be an issue on
> > physical servers though.
> >
>
On 11/18/2013 07:22 AM, Vivek Goyal wrote:
>
> And if that's true, then reserving 72M extra due to crashkernel=X,high
> should not be a big issue in KVM guests. It will still be an issue on
> physical servers though.
>
Yes, but there it is a single instance and not a huge amount of RAM.
On Fri, Nov 15, 2013 at 12:13:08PM -0700, jerry.hoem...@hp.com wrote:
[..]
> > Is it possible to fix it the way hpa suggested?
>
> I think the changes to enable ,high is a step in the
> right direction. its an improvement But it is still green.
>
> We are having lots more problems w/
On Fri, Nov 15, 2013 at 02:24:25PM -0800, Yinghai Lu wrote:
> On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal wrote:
> > On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>
> >> I have one system with 6TiB memory, kdump does not work even
> >> crashkernel=512M in legacy mode. ( it only
On Fri, Nov 15, 2013 at 02:24:25PM -0800, Yinghai Lu wrote:
On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal vgo...@redhat.com wrote:
On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
I have one system with 6TiB memory, kdump does not work even
crashkernel=512M in legacy mode. ( it
On Fri, Nov 15, 2013 at 12:13:08PM -0700, jerry.hoem...@hp.com wrote:
[..]
Is it possible to fix it the way hpa suggested?
I think the changes to enable ,high is a step in the
right direction. its an improvement But it is still green.
We are having lots more problems w/ upstream
On 11/18/2013 07:22 AM, Vivek Goyal wrote:
And if that's true, then reserving 72M extra due to crashkernel=X,high
should not be a big issue in KVM guests. It will still be an issue on
physical servers though.
Yes, but there it is a single instance and not a huge amount of RAM.
On Mon, Nov 18, 2013 at 10:29:18AM -0800, H. Peter Anvin wrote:
On 11/18/2013 07:22 AM, Vivek Goyal wrote:
And if that's true, then reserving 72M extra due to crashkernel=X,high
should not be a big issue in KVM guests. It will still be an issue on
physical servers though.
Yes, but
On Mon, Nov 18, 2013 at 7:32 AM, Vivek Goyal vgo...@redhat.com wrote:
You may need bunch of PCIe cards installed.
The system with 6TiB + 16 PCIe cards, second kernel OOM.
The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore
dumped.
What's the distro you are testing with?
On Mon, Nov 18, 2013 at 11:34:04AM -0800, Yinghai Lu wrote:
On Mon, Nov 18, 2013 at 7:32 AM, Vivek Goyal vgo...@redhat.com wrote:
You may need bunch of PCIe cards installed.
The system with 6TiB + 16 PCIe cards, second kernel OOM.
The system with 4.5TiB + 16 PCIe cards, second kernel
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
And IOMMU support is very flaky with kdump. And IOMMU's can be turned
off at command line. And that would force one to remove crahkernel_low=0.
So change of one command line option forces change of another. It is
complicated.
Also there are very
On Mon, Nov 18, 2013 at 5:32 PM, H. Peter Anvin h...@zytor.com wrote:
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
And IOMMU support is very flaky with kdump. And IOMMU's can be turned
off at command line. And that would force one to remove crahkernel_low=0.
So change of one command line option
On Fri, Nov 15, 2013 at 2:55 PM, wrote:
>> You may need bunch of PCIe cards installed.
>>
>> The system with 6TiB + 16 PCIe cards, second kernel OOM.
>> The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore
>> dumped.
>
> Yinghai,
>
> Your original email said you were using
On Fri, Nov 15, 2013 at 02:24:25PM -0800, Yinghai Lu wrote:
> On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal wrote:
> > On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>
> >> I have one system with 6TiB memory, kdump does not work even
> >> crashkernel=512M in legacy mode. ( it only
On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal wrote:
> On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>> I have one system with 6TiB memory, kdump does not work even
>> crashkernel=512M in legacy mode. ( it only work on system with
>> 4.5TiB).
>
> Recently I tested one system with
On 11/15/2013 10:46 AM, H. Peter Anvin wrote:
> On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>>
>> I agree taking assistance of hypervisor should be useful.
>>
>> One reason we use kdump for VM too because it makes life simple. There
>> is no difference in how we configure, start and manage crash
On Fri, Nov 15, 2013 at 07:24:17AM +0100, Ingo Molnar wrote:
>
> * jerry.hoem...@hp.com wrote:
>
> > On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> > > On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> > > > Making this issue a quirk will be a lot more practical. Its a small,
> > >
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>
> I agree taking assistance of hypervisor should be useful.
>
> One reason we use kdump for VM too because it makes life simple. There
> is no difference in how we configure, start and manage crash dumps
> in baremetal or inside VM. And in practice
On Fri, Nov 15, 2013 at 09:40:49AM -0800, H. Peter Anvin wrote:
> On 11/15/2013 09:33 AM, Yinghai Lu wrote:
> >
> > If the system support intel IOMMU, we only need to that 72M for SWIOTLB
> > or AMD workaround.
> > If the user really care that for intel iommu enable system, they could use
> >
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
> On 11/14/2013 10:55 PM, Yinghai Lu wrote:
> >
> > Why just asking distros to append ",high" in their installation
> > program for 64bit by default?
> >
> [...]
> >
> > What is hpa's suggestion?
> >
>
> Pretty much what you just
On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
[..]
> > I think crashkernel=X,high is not a good default choice for distros.
> > Reserving memory high reserves 72MB (or more) low memory for swiotlb. We
> > work hard to keep crashkernel memory amount low and currently reserve
> > 128M
On 11/15/2013 09:33 AM, Yinghai Lu wrote:
>
> If the system support intel IOMMU, we only need to that 72M for SWIOTLB
> or AMD workaround.
> If the user really care that for intel iommu enable system, they could use
> "crashkernel=0,low" to have that 72M back.
>
> and that 72M is under 4G
On Fri, Nov 15, 2013 at 6:07 AM, Vivek Goyal wrote:
> On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
>> On 11/14/2013 10:55 PM, Yinghai Lu wrote:
>> >
>> > Why just asking distros to append ",high" in their installation
>> > program for 64bit by default?
>> >
>> [...]
>> >
>> >
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
> On 11/14/2013 10:55 PM, Yinghai Lu wrote:
> >
> > Why just asking distros to append ",high" in their installation
> > program for 64bit by default?
> >
> [...]
> >
> > What is hpa's suggestion?
> >
>
> Pretty much what you just
On 11/15/13 2:50 AM, jerry.hoem...@hp.com wrote:
One already has to specify command line arguments to enable kdump.
Yes, so what?
The problem with your patch is that now to enable kdump, I have to know
that there's a second command line option and if my firmware is "broken"
or not. The
On 11/15/13 2:50 AM, jerry.hoem...@hp.com wrote:
One already has to specify command line arguments to enable kdump.
Yes, so what?
The problem with your patch is that now to enable kdump, I have to know
that there's a second command line option and if my firmware is broken
or not. The
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
On 11/14/2013 10:55 PM, Yinghai Lu wrote:
Why just asking distros to append ,high in their installation
program for 64bit by default?
[...]
What is hpa's suggestion?
Pretty much what you just said ;)
I think
On Fri, Nov 15, 2013 at 6:07 AM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
On 11/14/2013 10:55 PM, Yinghai Lu wrote:
Why just asking distros to append ,high in their installation
program for 64bit by default?
[...]
What is
On 11/15/2013 09:33 AM, Yinghai Lu wrote:
If the system support intel IOMMU, we only need to that 72M for SWIOTLB
or AMD workaround.
If the user really care that for intel iommu enable system, they could use
crashkernel=0,low to have that 72M back.
and that 72M is under 4G instead of
On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
[..]
I think crashkernel=X,high is not a good default choice for distros.
Reserving memory high reserves 72MB (or more) low memory for swiotlb. We
work hard to keep crashkernel memory amount low and currently reserve
128M by
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
On 11/14/2013 10:55 PM, Yinghai Lu wrote:
Why just asking distros to append ,high in their installation
program for 64bit by default?
[...]
What is hpa's suggestion?
Pretty much what you just said ;)
The issue
On Fri, Nov 15, 2013 at 09:40:49AM -0800, H. Peter Anvin wrote:
On 11/15/2013 09:33 AM, Yinghai Lu wrote:
If the system support intel IOMMU, we only need to that 72M for SWIOTLB
or AMD workaround.
If the user really care that for intel iommu enable system, they could use
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
I agree taking assistance of hypervisor should be useful.
One reason we use kdump for VM too because it makes life simple. There
is no difference in how we configure, start and manage crash dumps
in baremetal or inside VM. And in practice have not
On Fri, Nov 15, 2013 at 07:24:17AM +0100, Ingo Molnar wrote:
* jerry.hoem...@hp.com jerry.hoem...@hp.com wrote:
On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more
On 11/15/2013 10:46 AM, H. Peter Anvin wrote:
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
I agree taking assistance of hypervisor should be useful.
One reason we use kdump for VM too because it makes life simple. There
is no difference in how we configure, start and manage crash dumps
in
On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal vgo...@redhat.com wrote:
On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
I have one system with 6TiB memory, kdump does not work even
crashkernel=512M in legacy mode. ( it only work on system with
4.5TiB).
Recently I tested one
On Fri, Nov 15, 2013 at 02:24:25PM -0800, Yinghai Lu wrote:
On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal vgo...@redhat.com wrote:
On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
I have one system with 6TiB memory, kdump does not work even
crashkernel=512M in legacy mode. ( it
On Fri, Nov 15, 2013 at 2:55 PM, jerry.hoem...@hp.com wrote:
You may need bunch of PCIe cards installed.
The system with 6TiB + 16 PCIe cards, second kernel OOM.
The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore
dumped.
Yinghai,
Your original email said you were
On 11/14/2013 10:55 PM, Yinghai Lu wrote:
>
> Why just asking distros to append ",high" in their installation
> program for 64bit by default?
>
[...]
>
> What is hpa's suggestion?
>
Pretty much what you just said ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, Nov 14, 2013 at 10:24 PM, Ingo Molnar wrote:
>
> * jerry.hoem...@hp.com wrote:
>
>> On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
>> > On Thu, Nov 14, 2013 at 8:04 PM, wrote:
>> > > Making this issue a quirk will be a lot more practical. Its a small,
>> > > focused
>>
* jerry.hoem...@hp.com wrote:
> On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> > On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> > > Making this issue a quirk will be a lot more practical. Its a small,
> > > focused
> > > change whose implications are limited and more easily
On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> > Making this issue a quirk will be a lot more practical. Its a small,
> > focused
> > change whose implications are limited and more easily understood.
>
> There's nothing practical with
On 11/14/2013 10:44 AM, Pekka Enberg wrote:
> On Thu, Nov 14, 2013 at 8:04 PM, wrote:
>> Making this issue a quirk will be a lot more practical. Its a small, focused
>> change whose implications are limited and more easily understood.
>
> There's nothing practical with requiring users to pass
On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> Making this issue a quirk will be a lot more practical. Its a small, focused
> change whose implications are limited and more easily understood.
There's nothing practical with requiring users to pass a kernel option
to make kdump work. It's a
On Thu, Nov 14, 2013 at 10:24:17AM +0200, Pekka Enberg wrote:
> Hi Jerry,
>
> On Thu, Nov 14, 2013 at 1:57 AM, wrote:
> > I will still point out that as currently used, efi_reserve_boot_services
> > is wrong. A work around for firmware bugs on one platform shouldn't be
> > breaking platforms
On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
[..]
> In other words, allocating the crashkernel high has ALL the advantages,
> plus a few more, and NONE of the disadvantages.
It allocates low memory for swiotlb. So that extra 72M allocation is the
disadvantage. With so many
Hi Jerry,
On Thu, Nov 14, 2013 at 1:57 AM, wrote:
> I will still point out that as currently used, efi_reserve_boot_services
> is wrong. A work around for firmware bugs on one platform shouldn't be
> breaking platforms that don't have that bug. Its just much less likely
> to cause problems
Hi Jerry,
On Thu, Nov 14, 2013 at 1:57 AM, jerry.hoem...@hp.com wrote:
I will still point out that as currently used, efi_reserve_boot_services
is wrong. A work around for firmware bugs on one platform shouldn't be
breaking platforms that don't have that bug. Its just much less likely
to
On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
[..]
In other words, allocating the crashkernel high has ALL the advantages,
plus a few more, and NONE of the disadvantages.
It allocates low memory for swiotlb. So that extra 72M allocation is the
disadvantage. With so many
On Thu, Nov 14, 2013 at 10:24:17AM +0200, Pekka Enberg wrote:
Hi Jerry,
On Thu, Nov 14, 2013 at 1:57 AM, jerry.hoem...@hp.com wrote:
I will still point out that as currently used, efi_reserve_boot_services
is wrong. A work around for firmware bugs on one platform shouldn't be
breaking
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more practical. Its a small, focused
change whose implications are limited and more easily understood.
There's nothing practical with requiring users to pass a kernel option
to make kdump
On 11/14/2013 10:44 AM, Pekka Enberg wrote:
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more practical. Its a small, focused
change whose implications are limited and more easily understood.
There's nothing practical with requiring
On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more practical. Its a small,
focused
change whose implications are limited and more easily understood.
There's nothing
* jerry.hoem...@hp.com jerry.hoem...@hp.com wrote:
On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more practical. Its a small,
focused
change whose implications are
On Thu, Nov 14, 2013 at 10:24 PM, Ingo Molnar mi...@kernel.org wrote:
* jerry.hoem...@hp.com jerry.hoem...@hp.com wrote:
On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more
On 11/14/2013 10:55 PM, Yinghai Lu wrote:
Why just asking distros to append ,high in their installation
program for 64bit by default?
[...]
What is hpa's suggestion?
Pretty much what you just said ;)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Wed, Nov 13, 2013 at 04:05:50PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote:
> >
> > I think i can go to a date based black list, that removes the manual
> > step. System running firmware before certain date assumes we need
> > to do the work around. If
On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote:
>
> I think i can go to a date based black list, that removes the manual
> step. System running firmware before certain date assumes we need
> to do the work around. If firmware is newer than that date, we don't
> use the workaround.
On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 02:45 PM, jerry.hoem...@hp.com wrote:
> >
> > The changes in 3.9 to allow crash kernel to be allocated high helps.
> > But as you say, the default is still to allocate crash kernel low and
> > still susceptible to
On 11/13/2013 02:45 PM, jerry.hoem...@hp.com wrote:
>
> The changes in 3.9 to allow crash kernel to be allocated high helps.
> But as you say, the default is still to allocate crash kernel low and
> still susceptible to this problem. So, a kdump expert can work around it.
> But, not everyone is
On Tue, Nov 12, 2013 at 10:58:42AM -0800, H. Peter Anvin wrote:
> The problem with the crashkernel is that it by default has to sit very low in
> memory because the tools don't know if the crashkernel is me enough to sit
> anywhere. That is the real fix.
The changes in 3.9 to allow crash
On Tue, Nov 12, 2013 at 10:58:42AM -0800, H. Peter Anvin wrote:
The problem with the crashkernel is that it by default has to sit very low in
memory because the tools don't know if the crashkernel is me enough to sit
anywhere. That is the real fix.
The changes in 3.9 to allow crash kernel
On 11/13/2013 02:45 PM, jerry.hoem...@hp.com wrote:
The changes in 3.9 to allow crash kernel to be allocated high helps.
But as you say, the default is still to allocate crash kernel low and
still susceptible to this problem. So, a kdump expert can work around it.
But, not everyone is a
On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
On 11/13/2013 02:45 PM, jerry.hoem...@hp.com wrote:
The changes in 3.9 to allow crash kernel to be allocated high helps.
But as you say, the default is still to allocate crash kernel low and
still susceptible to this
On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote:
I think i can go to a date based black list, that removes the manual
step. System running firmware before certain date assumes we need
to do the work around. If firmware is newer than that date, we don't
use the workaround. Blacklist
On Wed, Nov 13, 2013 at 04:05:50PM -0800, H. Peter Anvin wrote:
On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote:
I think i can go to a date based black list, that removes the manual
step. System running firmware before certain date assumes we need
to do the work around. If firmware
On Tue, Nov 12, 2013 at 08:48:51PM +0200, Pekka Enberg wrote:
> Hi Jerry,
>
> On Tue, Nov 12, 2013 at 7:55 PM, wrote:
> > My change does not address platforms that have misbehaving firmware.
> > It just allows platforms that don't have this issue to avoid issues
> > that the call to
The problem with the crashkernel is that it by default has to sit very low in
memory because the tools don't know if the crashkernel is me enough to sit
anywhere. That is the real fix.
Jerry Hoemann wrote:
>Some platform have firmware that violates UEFI spec and access boot
>service
>code or
Hi Jerry,
On Tue, Nov 12, 2013 at 7:55 PM, wrote:
> My change does not address platforms that have misbehaving firmware.
> It just allows platforms that don't have this issue to avoid issues
> that the call to efi_reserve_boot_services presents.
The problem I have with your patch is that it
On Tue, Nov 12, 2013 at 12:37:29PM +0200, Pekka Enberg wrote:
> On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann wrote:
> > Some platform have firmware that violates UEFI spec and access boot service
> > code or data segments after the system has called Exit Boot Services.
> > The call to
On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann wrote:
> Some platform have firmware that violates UEFI spec and access boot service
> code or data segments after the system has called Exit Boot Services.
> The call to efi_reserve_boot_services in setup_arch is a work around to
> avoid using boot
On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann jerry.hoem...@hp.com wrote:
Some platform have firmware that violates UEFI spec and access boot service
code or data segments after the system has called Exit Boot Services.
The call to efi_reserve_boot_services in setup_arch is a work around to
On Tue, Nov 12, 2013 at 12:37:29PM +0200, Pekka Enberg wrote:
On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann jerry.hoem...@hp.com wrote:
Some platform have firmware that violates UEFI spec and access boot service
code or data segments after the system has called Exit Boot Services.
The call
Hi Jerry,
On Tue, Nov 12, 2013 at 7:55 PM, jerry.hoem...@hp.com wrote:
My change does not address platforms that have misbehaving firmware.
It just allows platforms that don't have this issue to avoid issues
that the call to efi_reserve_boot_services presents.
The problem I have with your
The problem with the crashkernel is that it by default has to sit very low in
memory because the tools don't know if the crashkernel is me enough to sit
anywhere. That is the real fix.
Jerry Hoemann jerry.hoem...@hp.com wrote:
Some platform have firmware that violates UEFI spec and access boot
On Tue, Nov 12, 2013 at 08:48:51PM +0200, Pekka Enberg wrote:
Hi Jerry,
On Tue, Nov 12, 2013 at 7:55 PM, jerry.hoem...@hp.com wrote:
My change does not address platforms that have misbehaving firmware.
It just allows platforms that don't have this issue to avoid issues
that the call to
Some platform have firmware that violates UEFI spec and access boot service
code or data segments after the system has called Exit Boot Services.
The call to efi_reserve_boot_services in setup_arch is a work around to
avoid using boot service memory until after the kernel has done
Set Virtual Map.
Some platform have firmware that violates UEFI spec and access boot service
code or data segments after the system has called Exit Boot Services.
The call to efi_reserve_boot_services in setup_arch is a work around to
avoid using boot service memory until after the kernel has done
Set Virtual Map.
84 matches
Mail list logo
