On 11/27/13 at 11:07am, Dave Young wrote:
It will not work for efi 32bit. Only x86_64 currently.
Actually, exporting the tables does work for 32-bit, right? It's just
that kexec doesn't work for 32-bit EFI?
It does not make sense to export them for 32-bit because we do not
support
On 11/26/13 at 08:59am, Toshi Kani wrote:
On Tue, 2013-11-26 at 14:11 +0800, Dave Young wrote:
On 11/25/13 at 08:30am, Toshi Kani wrote:
HI Dave,
I will test v4 again. This time, I will test memmap=exactmap option
as well. I have tested the following cases before. Are there any
On Wed, 27 Nov, at 12:52:37PM, Dave Young wrote:
To make it more readable, I will change them like below:
p = efi_runtime_map;
md = efi_setup-map;
for (i = 0; i nr_efi_runtime_map; i++) {
[...]
md += 1;
}
Actually, md++ is the canonical way to write this.
+
On Tue, 26 Nov, at 01:57:53PM, Dave Young wrote:
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
Signed-off-by: Dave Young
On Tue, 26 Nov, at 01:57:55PM, Dave Young wrote:
+Users:
+ Kexec Mailing List kexec@lists.infradead.org
Kexec please.
+static ssize_t version_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
This is pretty strange
On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly
On Wed, Nov 27, 2013 at 05:29:46PM +0800, Dave Young wrote:
I would like to send a new version which addressing several issues for
code structure improvement and changelog etc.
If there's no further comments I will send them tommorrow.
As a rule of thumb you should wait ~week and give chance
On Tue, 26 Nov, at 01:57:45PM, Dave Young wrote:
Hi,
Here is the V4 resend for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously.
On Tue, Nov 26, 2013 at 01:57:54PM +0800, Dave Young wrote:
Old kexec-tools can not load new kernel. The reason is previously kexec-tools
The reason is, kexec-tools ... previously, thus efi failed to initialize ...
do not fill efi_info in x86 setup header thus efi init fail and switch
to
On Tue, Nov 26, 2013 at 01:57:55PM +0800, Dave Young wrote:
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such
On Tue, Nov 26, 2013 at 01:57:56PM +0800, Dave Young wrote:
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn about ioremap a normal ram range.
I had to stare for a while at this commit
On Wed, Nov 27, 2013 at 11:00:53AM +0900, HATAYAMA Daisuke wrote:
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
On Wed, Nov 27, 2013 at 11:00:48AM +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
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
this flag to clear Bus Master bit on PCI devices only in case of
kexec reboot. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=63861
and avoids any other
On Wed, Nov 27, 2013 at 12:18:28PM -0700, Khalid Aziz wrote:
+/* flag to track if kexec reboot is in progress */
+extern unsigned long kexec_in_progress;
Adding this to pci.h seems a little odd. We may want to use it somewhere
else at some point. Add it to kexec.h instead?
--
Matthew
Khalid Aziz khalid.a...@oracle.com writes:
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
this flag to clear Bus Master bit on PCI devices only in case of
kexec reboot. This fixes
On Wed, Nov 27, 2013 at 12:18:28PM -0700, Khalid Aziz wrote:
+/* flag to track if kexec reboot is in progress */
+extern unsigned long kexec_in_progress;
unsigned long for a flag?
___
kexec mailing list
kexec@lists.infradead.org
On 11/27/2013 12:24 PM, Matthew Garrett wrote:
On Wed, Nov 27, 2013 at 12:18:28PM -0700, Khalid Aziz wrote:
+/* flag to track if kexec reboot is in progress */
+extern unsigned long kexec_in_progress;
Adding this to pci.h seems a little odd. We may want to use it somewhere
else at some
On Wed, Nov 27, 2013 at 12:48:42PM -0700, Khalid Aziz wrote:
I debated between pci.h and kexec.h but pci-driver.c does not
include kexec.h and I didn't want to include a whole new file. Now I
see another problem with adding that extern declaration to pci.h -
if CONFIG_KEXEC is not set, build
On 11/27/2013 12:38 PM, ebied...@xmission.com wrote:
Khalid Aziz khalid.a...@oracle.com writes:
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
this flag to clear Bus Master bit on PCI devices only in case of
On Wed, Nov 27, 2013 at 12:59:40PM -0700, Khalid Aziz wrote:
On 11/27/2013 12:38 PM, ebied...@xmission.com wrote:
Khalid Aziz khalid.a...@oracle.com writes:
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
On Wed, Nov 27, 2013 at 01:22:27PM -0800, Greg KH wrote:
Then fix the drivers please. It's not as if you don't have access to
the source for them all...
Define fix. It's clearly wrong to disable busmastering at shutdown on
some devices, otherwise we wouldn't be having this discussion at all.
On Wed, Nov 27, 2013 at 09:53:09PM +, Matthew Garrett wrote:
On Wed, Nov 27, 2013 at 01:22:27PM -0800, Greg KH wrote:
Then fix the drivers please. It's not as if you don't have access to
the source for them all...
Define fix. It's clearly wrong to disable busmastering at shutdown on
On Wed, Nov 27, 2013 at 02:01:06PM -0800, Greg KH wrote:
On Wed, Nov 27, 2013 at 09:53:09PM +, Matthew Garrett wrote:
On Wed, Nov 27, 2013 at 01:22:27PM -0800, Greg KH wrote:
Then fix the drivers please. It's not as if you don't have access to
the source for them all...
On 11/27/2013 03:07 PM, Matthew Garrett wrote:
On Wed, Nov 27, 2013 at 02:01:06PM -0800, Greg KH wrote:
Anyway, I really don't care either way, but this seems like something
that the drivers should be doing. What suddenly changed that caused
this problem to occur that hasn't happened in the
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
this flag to clear Bus Master bit on PCI devices only in case of
kexec reboot. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=63861
and avoids any other
(2013/11/28 0:10), Vivek Goyal wrote:
On Wed, Nov 27, 2013 at 11:00:48AM +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
This patch is to allow kdump 2nd kernel to wake up multiple CPUs,
a continuing 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 out initial
APIC ID of BSP in the 1st
On 11/27/13 at 12:50pm, Matt Fleming wrote:
On Tue, 26 Nov, at 01:57:45PM, Dave Young wrote:
Hi,
Here is the V4 resend for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
On 11/27/13 at 12:56pm, Borislav Petkov wrote:
On Wed, Nov 27, 2013 at 05:29:46PM +0800, Dave Young wrote:
I would like to send a new version which addressing several issues for
code structure improvement and changelog etc.
If there's no further comments I will send them tommorrow.
As
Hello Daniel,
On 2013/11/27 5:19:56, Daniel Kiper daniel.ki...@oracle.com wrote:
Do not try to process Xen crash dump if dump level is invalid.
Fail immediately and print relevant error message.
Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
---
makedumpfile.c | 18
(2013/11/28 16:08), Atsushi Kumagai wrote:
On 2013/11/22 16:18:20, kexec kexec-boun...@lists.infradead.org wrote:
(2013/11/07 9:54), HATAYAMA Daisuke wrote:
(2013/11/06 11:21), Atsushi Kumagai wrote:
(2013/11/06 5:27), Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma
33 matches
Mail list logo
