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 Tue, 2013-11-05 at 16:20 +0800, dyo...@redhat.com wrote:
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved in
On Tue, 2013-11-05 at 16:20 +0800, dyo...@redhat.com wrote:
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
:
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *p,
11 matches
Mail list logo
