On Mon, 10 Mar 2014 05:26:34 +
Atsushi Kumagai wrote:
> >-CFLAGS = -g -O2 -Wall -D_FILE_OFFSET_BITS=64 \
> >+CFLAGS = $(INCLUDES) -g -O2 -Wall -D_FILE_OFFSET_BITS=64 \
> > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
> > -DVERSION='"$(VERSION)"' -DRELEASE_DATE='"$(DATE)"'
> > CFLAG
>On Mon, 3 Mar 2014 03:11:23 +
>Atsushi Kumagai wrote:
>
>> Hello Michael,
>>
>> >Hello Atsushi,
>> >
>> >On s390 we have the following little problem:
>> >
>> >We use hypervisor or stand-alone dump tools to create Linux system
>> >dumps. These tools do not know the kernel parameter line and d
On Mon, Mar 10, 2014 at 8:54 AM, Muli Ben-Yehuda wrote:
> Patch looks good to me.
>
> Acked-by: Muli Ben-Yehuda
Me too (just in case you want us both).
Acked-by: Jon Mason
>
> Cheers,
> Muli
___
kexec mailing list
kexec@lists.infradead.org
http://l
On Sun, Mar 9, 2014 at 12:06 AM, Muli Ben-Yehuda wrote:
> On Thu, Mar 06, 2014 at 07:46:44AM -0700, Jon Mason wrote:
>
>> > I don't know of anyone still using it, but it's not
>> > impossible. Calgary and CalIOC2 machines would now be ~5-8 years
>> > old.
>>
>> It is getting a bit crufty in arch/x
- Original Message -
> On Mon, Mar 10, 2014 at 05:25:11PM +0800, arthur wrote:
> > Description
> > in dump_dmesg_structured() the out_buf size is 4096, and if the
> > length is less than 4080( 4096-16 ) it won't really write out.
> > Normally, after writing one or four chars to the out_bu
On Fri, Jan 10, 2014 at 03:07:26PM -0700, Bill Sumner wrote:
[..]
> This patch set modifies the behavior of the iommu in the (new) crashdump
> kernel:
> 1. to accept the iommu hardware in an active state,
> 2. to leave the current translations in-place so that legacy DMA will continue
>usin
On Mon, Mar 10, 2014 at 05:25:11PM +0800, arthur wrote:
> Description
> in dump_dmesg_structured() the out_buf size is 4096, and if the
> length is less than 4080( 4096-16 ) it won't really write out.
> Normally, after writing one or four chars to the out_buf, it will
> check the length of out_buf.
On Tue 3/4/2014 8:59 AM, Joerg Roedel wrote
>On Fri, Jan 10, 2014 at 03:07:29PM -0700, Bill Sumner wrote:
>> +context_get_entry(struct context_entry *context_addr,
>> +struct intel_iommu *iommu, u32 bus, int devfn) {
>> +unsigned long long q; /* quadword scratch */
Hi Joerg,
On Tue 3/4/2014 9:06 AM, Joerg Roedel wrote:
>
>On Fri, Jan 10, 2014 at 03:07:26PM -0700, Bill Sumner wrote:
>> Bill Sumner (6):
>> Crashdump-Accepting-Active-IOMMU-Flags-and-Prototype
>> Crashdump-Accepting-Active-IOMMU-Utility-functions
>> Crashdump-Accepting-Active-IOMMU-Domain-
Patch looks good to me.
Acked-by: Muli Ben-Yehuda
Cheers,
Muli
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Mon, Mar 10, 2014 at 10:52:00PM +0800, WANG Chao wrote:
> New kexec-tools wants to pass kdump kernel needed memmap via E820
> directly, instead of memmap=exactmap. This makes saved_max_pfn not
> be passed down to 2nd kernel. To keep 1st kernel and 2nd kernel using
> the same TCE table size, Muli
On Mon, Mar 10, 2014 at 11:01:43AM +0100, Borislav Petkov wrote:
[..]
> > I think address does not matter here. You can't add a segemnt after you
> > have allocated a control page. So I am not sure how printing address will
> > help.
>
> Ok, so what's the urgency of that warning? The "can't add a
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao
---
kexec/arch/i386/include/arch/options.h | 2 ++
kexec/arch/i386/kexec-x86.c|
Use these two variables to store the memory ranges and the number of
memory ranges for crash kernel to boot into:
struct memory_range crash_memory_range;
int crash_memory_range;
These two variables are not static now, so can be used in other file
later.
Signed-off-by: WANG Chao
---
kexec/arch/
Hi, All
When kaslr comes in and kdump is broken, it seems about the right time to use
E820 instead of memmap=exactmap to pass memmap for kdump for the default memmap
passing mechanism:
http://lists.infradead.org/pipermail/kexec/2014-February/011048.html
Unfortunately, saved_max_pfn still got its
dbgprint_mem_range is used for printing the given memory range under
debugging mode.
Signed-off-by: WANG Chao
---
kexec/arch/i386/kexec-x86-common.c | 6 +-
kexec/kexec.c | 10 ++
kexec/kexec.h | 1 +
3 files changed, 12 insertions(+), 5 de
command line size is restricted by kernel, sometimes memmap=exactmap has
too many memory ranges to pass to cmdline. A better approach, to pass the
memory ranges for crash kernel to boot into, is filling the memory
ranges into E820.
boot_params only got 128 slots for E820 map to fit in, when the nu
New kexec-tools wants to pass kdump kernel needed memmap via E820
directly, instead of memmap=exactmap. This makes saved_max_pfn not
be passed down to 2nd kernel. To keep 1st kernel and 2nd kernel using
the same TCE table size, Muli suggest to hard code the size to max (8M).
We can't get rid of sa
On Fri, Mar 07, 2014 at 07:39:59PM +0100, Borislav Petkov wrote:
[..]
> > Well, this is mandated by the boot protocol, no?
> >
> > "If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
> > the boot protocol version is "old". Loading an old kernel, the
> > following parameters sh
On Mon, Mar 10, 2014 at 04:38:34PM +0800, WANG Chao wrote:
[..]
> > So we have two scenarios.
> >
> > - Old first kernel and new second kernel.
> > - New first kernel and old second kernel.
> >
> > If we want to make these two scenarios work with calgary, we need to
> > use kexec-tools with --pa
On Fri, Feb 28, 2014 at 11:56:28AM -0500, Vivek Goyal wrote:
> This is more of future proofing it. I have been putting this check to
> catch any accidental errors if somebody ends up calling this function
> from old mode.
>
> But I am not very particular about it. If you don't like it, I can get
>
Description
in dump_dmesg_structured() the out_buf size is 4096, and if the
length is less than 4080( 4096-16 ) it won't really write out.
Normally, after writing one or four chars to the out_buf, it will
check the length of out_buf. But in extreme cases, 19 chars was
written to the out_buf before
On 03/07/14 at 11:09am, Vivek Goyal wrote:
> On Fri, Mar 07, 2014 at 11:52:04PM +0800, WANG Chao wrote:
> > Hi, Vivek
> >
> > On 03/07/14 at 09:14am, Vivek Goyal wrote:
> > > On Fri, Mar 07, 2014 at 04:10:16PM +0800, WANG Chao wrote:
> > >
> > > [..]
> > > > }
> > > >
> > > > - sp
23 matches
Mail list logo
