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 Fri, Nov 15, 2013 at 11:16:25AM -0800, H. Peter Anvin wrote:
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
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 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 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 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 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 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-efi in
the body of
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 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
28 matches
Mail list logo
