On Wed, Apr 17, 2013 at 02:49:59PM -0700, Eric W. Biederman wrote:
> Don Zickus writes:
>
> > A common problem with kdump is that during the boot up of the
> > second kernel, the hardware watchdog times out and reboots the
> > machine before a vmcore can be captured.
> >
> > Instead of tellling c
Hello Mahesh,
On Mon, 15 Apr 2013 15:50:52 +0530
Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> The init_dwarf_info() function initializes "dwarf_info.dwfl" handle everytime
> when it is called. The "dwarf_info.dwfl" handle should be freed once we are
> done with searching of desired
Don Zickus writes:
> A common problem with kdump is that during the boot up of the
> second kernel, the hardware watchdog times out and reboots the
> machine before a vmcore can be captured.
>
> Instead of tellling customers to disable their hardware watchdog
> timers, I hacked up a hook to put i
On Wed, Apr 17, 2013 at 05:19:56PM -0400, Don Zickus wrote:
> A common problem with kdump is that during the boot up of the
> second kernel, the hardware watchdog times out and reboots the
> machine before a vmcore can be captured.
>
> Instead of tellling customers to disable their hardware watchd
A common problem with kdump is that during the boot up of the
second kernel, the hardware watchdog times out and reboots the
machine before a vmcore can be captured.
Instead of tellling customers to disable their hardware watchdog
timers, I hacked up a hook to put in the kdump path that provides
o
On Wed, Apr 17, 2013 at 6:52 AM, Thomas Renninger wrote:
> Hi,
>
> while trying to switch to kvm setup with a latest kernel I realized that
> blank:
> crashkernel=64M
> param will reserve this memory area:
> 7b00-7eff : Crash kernel
>
> and kexec does not successfully load the kernel due t
On Wed, Apr 17, 2013 at 03:15:39PM +0100, David Vrabel wrote:
> On 17/04/13 13:34, Daniel Kiper wrote:
> > On Tue, Apr 16, 2013 at 06:13:02PM +0100, David Vrabel wrote:
> >>
> >> The required patch series for kexec-tools have previously been posted
> >> and this series has been rebased on the lates
On 17/04/13 13:34, Daniel Kiper wrote:
> On Tue, Apr 16, 2013 at 06:13:02PM +0100, David Vrabel wrote:
>>
>> The required patch series for kexec-tools have previously been posted
>> and this series has been rebased on the latest kexec-tools and is
>> available from the xen-v3 branch of:
>>
>> http
On Wed, Apr 17, 2013 at 02:53:33PM +0100, David Vrabel wrote:
> On 17/04/13 13:56, Daniel Kiper wrote:
> > On Tue, Apr 09, 2013 at 11:20:36PM +0200, Daniel Kiper wrote:
> >>
> >> arch = (kexec_flags & KEXEC_ARCH_MASK) >> 16;
> >
> > What is wrong with this line?
> > Why did not you applied it?
>
>
On 17/04/13 13:56, Daniel Kiper wrote:
> On Tue, Apr 09, 2013 at 11:20:36PM +0200, Daniel Kiper wrote:
>>
>> arch = (kexec_flags & KEXEC_ARCH_MASK) >> 16;
>
> What is wrong with this line?
> Why did not you applied it?
I haven't reposted the kexec-tools patches so it's not clear what you
are expe
Hi,
while trying to switch to kvm setup with a latest kernel I realized that
blank:
crashkernel=64M
param will reserve this memory area:
7b00-7eff : Crash kernel
and kexec does not successfully load the kernel due to (hole_max output
added myself):
Could not find a free area of memory of
On Tue, Apr 09, 2013 at 11:20:36PM +0200, Daniel Kiper wrote:
> On Mon, Apr 08, 2013 at 08:06:54PM +0100, David Vrabel wrote:
> > From: David Vrabel
> >
> > Xen 4.3 has an improvided kexec hypercall ABI that allows images to be
> > loaded and executed without any kernel involvement. Use the API
>
On Tue, Apr 16, 2013 at 06:13:07PM +0100, David Vrabel wrote:
> From: David Vrabel
>
> 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
On Tue, Apr 16, 2013 at 06:13:02PM +0100, David Vrabel wrote:
> The series improves the kexec hypercall by making Xen responsible for
> loading and relocating the image. This allows kexec to be usable by
> pv-ops kernels and should allow kexec to be usable from a HVM or PVH
> privileged domain.
>
From: Suzuki K. Poulose
Teach uImage_probe_xxx() to return the information about
a corrupted image. This is required to prevent the loading
of a corrupted ramdisk, where we don't have strict checking
for the other formats, unlike the kernel. So, we should abort
the operation than causing a proble
>>> On 17.04.13 at 12:11, David Vrabel wrote:
> On 17/04/13 09:55, Jan Beulich wrote:
> On 16.04.13 at 19:13, David Vrabel wrote:
>>> -static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
>>> +static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg)
>>> {
>>> -xen_kexec_exec_t exec;
On 17/04/13 09:55, Jan Beulich wrote:
On 16.04.13 at 19:13, David Vrabel wrote:
>> -static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
>> +static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg)
>> {
>> -xen_kexec_exec_t exec;
>> -xen_kexec_image_t *image;
>> -int base, bi
>>> On 16.04.13 at 19:13, David Vrabel wrote:
> -static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
> +static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg)
> {
> -xen_kexec_exec_t exec;
> -xen_kexec_image_t *image;
> -int base, bit, pos, ret = -EINVAL;
> +xen_kexec_load_
(2013/04/15 19:18), Joerg Roedel wrote:
> On Mon, Apr 15, 2013 at 06:00:13PM +0900, Takao Indoh wrote:
>> On DMAR initialization during kdump boot, do you guys agree to change
>> order like this?
>>
>> Current order:
>> (1) Disable translation
>> (2) PCI initialization
>> (3) Make pgtable and enabl
19 matches
Mail list logo
