On 11/11/13 at 11:58pm, Greg KH wrote:
On Mon, Nov 11, 2013 at 07:20:17PM -0800, H. Peter Anvin wrote:
On 11/11/2013 05:27 PM, Toshi Kani wrote:
On Tue, 2013-11-05 at 16:29 +0800, dyo...@redhat.com wrote:
Not only setup_subarch will get data from debugfs file
boot_params/data, later
On 11/11/13 at 04:40pm, Greg KH wrote:
On Tue, Nov 05, 2013 at 04:20:11PM +0800, dyo...@redhat.com wrote:
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
sysfs files are one-value-per-file.
Please don't
On 11/12/13 at 04:19pm, Dave Young wrote:
On 11/11/13 at 04:40pm, Greg KH wrote:
On Tue, Nov 05, 2013 at 04:20:11PM +0800, dyo...@redhat.com wrote:
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
sysfs
On Tue, Nov 12, 2013 at 04:08:54PM +0800, Dave Young wrote:
On 11/11/13 at 11:58pm, Greg KH wrote:
kexec-tools can have a fallback to debugfs if we really need it, but
making people mount debugfs to have some essential piece of
functionality scares the heck out of me.
I agree, that
On Tue, Nov 12, 2013 at 04:24:01PM +0800, Dave Young wrote:
On 11/12/13 at 04:19pm, Dave Young wrote:
On 11/11/13 at 04:40pm, Greg KH wrote:
On Tue, Nov 05, 2013 at 04:20:11PM +0800, dyo...@redhat.com wrote:
Export fw_vendor, runtime and config tables physical
addresses to
On 11/12/13 at 12:30am, Greg KH wrote:
On Tue, Nov 12, 2013 at 04:08:54PM +0800, Dave Young wrote:
On 11/11/13 at 11:58pm, Greg KH wrote:
kexec-tools can have a fallback to debugfs if we really need it, but
making people mount debugfs to have some essential piece of
functionality
On 11/12/2013 12:30 AM, Greg KH wrote:
And these binary data blobs are a standard somewhere, and will not
change per kernel version change?
If so, that structure is fine with me.
Correct. The structure is documented in Documentation/x86/boot.txt, and
has been largely invariant (but
On Tue, Nov 12, 2013 at 01:37:25AM -0800, H. Peter Anvin wrote:
On 11/12/2013 12:30 AM, Greg KH wrote:
And these binary data blobs are a standard somewhere, and will not
change per kernel version change?
If so, that structure is fine with me.
Correct. The structure is
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.
This is mostly used for the kdump 2nd kernel to disable BSP to wake up
multiple CPUs without causing system reset or hang due to sending INIT
from AP to
Add disable_cpu_apicid kernel parameter to disable the CPU with the
specified number of initial APIC ID, mostly used for the kdump 2nd
kernel to disable BSP to wake up multiple CPUs without causing system
reset or hang due to sending INIT from AP to BSP.
Signed-off-by: HATAYAMA Daisuke
Add bsp_physical_apicid variable that has the initial APIC ID for the
processor with BSP flag on IA32_APIC_BASE MSR. Without this,
boot_cpu_physical_apicid temporarily has the value around MP table
related codes such as kernel/mpparse.c, mm/amdtopology.c and
platform/visws/visws_quirks.c until it
This patch set is to allow kdump 2nd kernel to wake up multiple CPUs
even if 1st kernel crashs on some AP, a continueing work from:
[PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP
https://lkml.org/lkml/2013/10/16/300.
At v4, basic design has changed. Now users need to figure
(2013/11/12 9:40), HATAYAMA Daisuke wrote:
(2013/11/12 1:52), Vivek Goyal wrote:
On Mon, Nov 11, 2013 at 11:52:30AM +0900, HATAYAMA Daisuke wrote:
[..]
Looking at my past investigation, kernel/mpparse.c, mm/amdtopology.c and
platform/visws/visws_quirks.c assumes that boot_cpu_physical_apicid
On Tue, Nov 12, 2013 at 06:51:58PM +0900, HATAYAMA Daisuke wrote:
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.
This is mostly used for the kdump 2nd kernel to disable BSP to wake up
multiple
On Tue, Nov 12, 2013 at 04:58:50PM +1300, Matthew Garrett wrote:
Well, there's one alternative - don't export this at all and only support
UEFI kernels that have an in-kernel loader, then just pass the data
internally.
Hi Matthew,
I am still writing that in-kernel support for kexec/kdump.
Hi,
there was a patch recently from Lubomir, title:
dump-dmesg: Understand = v3.11-rc4 dmesg
But in makedumpfile.h the latest supported version still is:
#define LATEST_VERSION KERNEL_VERSION(3, 9, 6)/* linux-3.9.6 */
resulting in:
The kernel version is not supported.
The created
On 11/12/13 at 06:51pm, Greg KH wrote:
On Tue, Nov 12, 2013 at 01:37:25AM -0800, H. Peter Anvin wrote:
On 11/12/2013 12:30 AM, Greg KH wrote:
And these binary data blobs are a standard somewhere, and will not
change per kernel version change?
If so, that structure is fine with
Sigh, my build just stopped.
kimage.c: In function 'kimage_crash_alloc':
kimage.c:222:9: error: unused variable 'result' [-Werror=unused-variable]
cc1: all warnings being treated as errors
A late change from v9 to v10 missed the removal of this variable.
Here is what I did to fix:
From
For what it is worth.
Reviewed-by: Don Slutz dsl...@verizon.com
-Don Slutz
On 11/06/13 09:49, David Vrabel wrote:
From: David Vrabel david.vra...@citrix.com
In the existing kexec hypercall, the load and unload ops depend on
internals of the Linux kernel (the page list and code page
From: David Vrabel david.vra...@citrix.com
In the existing kexec hypercall, the load and unload ops depend on
internals of the Linux kernel (the page list and code page provided by
the kernel). The code page is used to transition between Xen context
and the image so using kernel code doesn't
On Wed, Nov 06, 2013 at 02:55:19PM +, David Vrabel wrote:
From: David Vrabel david.vra...@citrix.com
libxc from Xen 4.4 added xc_kexec_load() which will be required to
load images into Xen in the future.
Remove all the #ifdef'ery for older versions of libxc.
Signed-off-by: David
21 matches
Mail list logo
