* mips: elfinfo
@ 2010-12-16 2:05 Simon Horman
2010-12-16 15:33 ` Maxim Uvarov
2010-12-16 22:53 ` kexec fixes? Eric W. Biederman
0 siblings, 2 replies; 8+ messages in thread
From: Simon Horman @ 2010-12-16 2:05 UTC (permalink / raw
To: kexec; +Cc: Maxim Uvarov, Eric W. Biederman
Hi Maxim,
I noticed that your change "Patch adds kernel data section to final vmcore.
This forces gdb read kernel" causes the build to break as it was applied
after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
crash_elf_info" patch.
I have it in mind to resolve this something along the lines of
the patch below. However, I now see the following warning:
kexec/arch/mips/crashdump-mips.c: In function `get_kernel_vaddr_and_size':
kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too large for "unsigned long" type
Which corresponds to this code:
elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
0xffffffff80000000UL;
I am compiling for 32-bit, so at a glance that constant does
seem to large.
Also, if you have any tips on a cross-compiling environment for 64bit
on a x86_32 or x86_64 host I would be most grateful.
diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index 5ea4f4f..b937ab5 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -51,7 +51,7 @@ unsigned long long saved_max_mem;
/* Read kernel physical load addr from the file returned by proc_iomem()
* (Kernel Code) and store in kexec_info */
-static int get_kernel_paddr(struct kexec_info *info)
+static int get_kernel_paddr(struct crash_elf_info *elf_info)
{
uint64_t start;
@@ -59,7 +59,7 @@ static int get_kernel_paddr(struct kexec_info *info)
return 0;
if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
- info->kern_paddr_start = start;
+ elf_info->kern_paddr_start = start;
#ifdef DEBUG
printf("kernel load physical addr start = 0x%lx\n", start);
#endif
@@ -70,21 +70,22 @@ static int get_kernel_paddr(struct kexec_info *info)
return -1;
}
-static int get_kernel_vaddr_and_size(struct kexec_info *info)
+static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
{
uint64_t end;
- if (!info->kern_paddr_start)
+ if (!elf_info->kern_paddr_start)
return -1;
- info->kern_vaddr_start = info->kern_paddr_start | 0xffffffff80000000UL;
+ elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
+ 0xffffffff80000000UL;
if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
- info->kern_size = end - info->kern_paddr_start;
+ elf_info->kern_size = end - elf_info->kern_paddr_start;
#ifdef DEBUG
printf("kernel_vaddr= 0x%llx paddr %llx\n",
- info->kern_vaddr_start,
- info->kern_paddr_start);
- printf("kernel size = 0x%llx\n", info->kern_size);
+ elf_info->kern_vaddr_start,
+ elf_info->kern_paddr_start);
+ printf("kernel size = 0x%llx\n", elf_info->kern_size);
#endif
return 0;
}
@@ -355,11 +356,20 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
unsigned long sz, elfcorehdr;
int nr_ranges, align = 1024;
struct memory_range *mem_range;
+ crash_create_elf_headers_func crash_create = crash_create_elf32_headers;
+ struct crash_elf_info *elf_info = &elf_info32;
- if (get_kernel_paddr(info))
+#ifdef __mips64
+ if (arch_options.core_header_type == CORE_TYPE_ELF64) {
+ elf_info = &elf_info64;
+ crash_create = crash_create_elf64;
+ }
+#endif
+
+ if (get_kernel_paddr(elf_info))
return -1;
- if (get_kernel_vaddr_and_size(info))
+ if (get_kernel_vaddr_and_size(elf_info))
return -1;
if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
@@ -373,28 +383,9 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
crash_reserved_mem.start,
crash_reserved_mem.end, -1);
-#ifdef __mips64
- /* Create elf header segment and store crash image data. */
- if (arch_options.core_header_type == CORE_TYPE_ELF64) {
- if (crash_create_elf64_headers(info, &elf_info64,
- crash_memory_range, nr_ranges,
- &tmp, &sz,
- ELF_CORE_HEADER_ALIGN) < 0)
- return -1;
- } else {
- if (crash_create_elf32_headers(info, &elf_info32,
- crash_memory_range, nr_ranges,
- &tmp, &sz,
- ELF_CORE_HEADER_ALIGN) < 0)
- return -1;
- }
-#else
- if (crash_create_elf32_headers(info, &elf_info32,
- crash_memory_range, nr_ranges,
- &tmp, &sz,
- ELF_CORE_HEADER_ALIGN) < 0)
+ if (crash_create(info, elf_info, crash_memory_range, nr_ranges,
+ &tmp, &sz, ELF_CORE_HEADER_ALIGN) < 0)
return -1;
-#endif
elfcorehdr = add_buffer(info, tmp, sz, sz, align,
crash_reserved_mem.start,
crash_reserved_mem.end, -1);
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index eccdb9f..060bb88 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -35,6 +35,13 @@ struct crash_elf_info {
int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
};
+typedef int(*crash_create_elf_headers_func)(struct kexec_info *info,
+ struct crash_elf_info *elf_info,
+ struct memory_range *range,
+ int ranges,
+ void **buf, unsigned long *size,
+ unsigned long align);
+
int crash_create_elf32_headers(struct kexec_info *info,
struct crash_elf_info *elf_info,
struct memory_range *range, int ranges,
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: mips: elfinfo
2010-12-16 2:05 mips: elfinfo Simon Horman
@ 2010-12-16 15:33 ` Maxim Uvarov
2010-12-19 23:44 ` Simon Horman
2010-12-16 22:53 ` kexec fixes? Eric W. Biederman
1 sibling, 1 reply; 8+ messages in thread
From: Maxim Uvarov @ 2010-12-16 15:33 UTC (permalink / raw
To: Simon Horman; +Cc: kexec, Eric W. Biederman
2010/12/16 Simon Horman <horms@verge.net.au>:
> Hi Maxim,
>
> I noticed that your change "Patch adds kernel data section to final vmcore.
> This forces gdb read kernel" causes the build to break as it was applied
> after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> crash_elf_info" patch.
>
> I have it in mind to resolve this something along the lines of
> the patch below. However, I now see the following warning:
>
> kexec/arch/mips/crashdump-mips.c: In function `get_kernel_vaddr_and_size':
> kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too large for "unsigned long" type
>
> Which corresponds to this code:
>
> elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> 0xffffffff80000000UL;
>
> I am compiling for 32-bit, so at a glance that constant does
> seem to large.
>
Ah, yes this values does not fit to 32 bit UL.
> Also, if you have any tips on a cross-compiling environment for 64bit
> on a x86_32 or x86_64 host I would be most grateful.
>
I tested it with building on 32 bit host. readelf -a shows that vmcore
had memory segment according to kernel memory.
So that, gdb began to read real values instead of uninitialized.
Actually elf_info->kern_paddr_start | 0xffffffff80000000UL; is needed
only for 64 bit mips.
Because we read kernel memory ranges from /proc/vmcore and there are
values without 0xffffffff at the beginning.
But 0xfffff... are needed in case if we need access to this address from kernel.
32 bit mips kernel does not need adding 0xfffffff. But it think there
will be only warning and nothing wrong.
Maxim.
>
> diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
> index 5ea4f4f..b937ab5 100644
> --- a/kexec/arch/mips/crashdump-mips.c
> +++ b/kexec/arch/mips/crashdump-mips.c
> @@ -51,7 +51,7 @@ unsigned long long saved_max_mem;
>
> /* Read kernel physical load addr from the file returned by proc_iomem()
> * (Kernel Code) and store in kexec_info */
> -static int get_kernel_paddr(struct kexec_info *info)
> +static int get_kernel_paddr(struct crash_elf_info *elf_info)
> {
> uint64_t start;
>
> @@ -59,7 +59,7 @@ static int get_kernel_paddr(struct kexec_info *info)
> return 0;
>
> if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
> - info->kern_paddr_start = start;
> + elf_info->kern_paddr_start = start;
> #ifdef DEBUG
> printf("kernel load physical addr start = 0x%lx\n", start);
> #endif
> @@ -70,21 +70,22 @@ static int get_kernel_paddr(struct kexec_info *info)
> return -1;
> }
>
> -static int get_kernel_vaddr_and_size(struct kexec_info *info)
> +static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
> {
> uint64_t end;
>
> - if (!info->kern_paddr_start)
> + if (!elf_info->kern_paddr_start)
> return -1;
>
> - info->kern_vaddr_start = info->kern_paddr_start | 0xffffffff80000000UL;
> + elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> + 0xffffffff80000000UL;
> if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
> - info->kern_size = end - info->kern_paddr_start;
> + elf_info->kern_size = end - elf_info->kern_paddr_start;
> #ifdef DEBUG
> printf("kernel_vaddr= 0x%llx paddr %llx\n",
> - info->kern_vaddr_start,
> - info->kern_paddr_start);
> - printf("kernel size = 0x%llx\n", info->kern_size);
> + elf_info->kern_vaddr_start,
> + elf_info->kern_paddr_start);
> + printf("kernel size = 0x%llx\n", elf_info->kern_size);
> #endif
> return 0;
> }
> @@ -355,11 +356,20 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
> unsigned long sz, elfcorehdr;
> int nr_ranges, align = 1024;
> struct memory_range *mem_range;
> + crash_create_elf_headers_func crash_create = crash_create_elf32_headers;
> + struct crash_elf_info *elf_info = &elf_info32;
>
> - if (get_kernel_paddr(info))
> +#ifdef __mips64
> + if (arch_options.core_header_type == CORE_TYPE_ELF64) {
> + elf_info = &elf_info64;
> + crash_create = crash_create_elf64;
> + }
> +#endif
> +
> + if (get_kernel_paddr(elf_info))
> return -1;
>
> - if (get_kernel_vaddr_and_size(info))
> + if (get_kernel_vaddr_and_size(elf_info))
> return -1;
>
> if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
> @@ -373,28 +383,9 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
> crash_reserved_mem.start,
> crash_reserved_mem.end, -1);
>
> -#ifdef __mips64
> - /* Create elf header segment and store crash image data. */
> - if (arch_options.core_header_type == CORE_TYPE_ELF64) {
> - if (crash_create_elf64_headers(info, &elf_info64,
> - crash_memory_range, nr_ranges,
> - &tmp, &sz,
> - ELF_CORE_HEADER_ALIGN) < 0)
> - return -1;
> - } else {
> - if (crash_create_elf32_headers(info, &elf_info32,
> - crash_memory_range, nr_ranges,
> - &tmp, &sz,
> - ELF_CORE_HEADER_ALIGN) < 0)
> - return -1;
> - }
> -#else
> - if (crash_create_elf32_headers(info, &elf_info32,
> - crash_memory_range, nr_ranges,
> - &tmp, &sz,
> - ELF_CORE_HEADER_ALIGN) < 0)
> + if (crash_create(info, elf_info, crash_memory_range, nr_ranges,
> + &tmp, &sz, ELF_CORE_HEADER_ALIGN) < 0)
> return -1;
> -#endif
> elfcorehdr = add_buffer(info, tmp, sz, sz, align,
> crash_reserved_mem.start,
> crash_reserved_mem.end, -1);
> diff --git a/kexec/crashdump.h b/kexec/crashdump.h
> index eccdb9f..060bb88 100644
> --- a/kexec/crashdump.h
> +++ b/kexec/crashdump.h
> @@ -35,6 +35,13 @@ struct crash_elf_info {
> int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
> };
>
> +typedef int(*crash_create_elf_headers_func)(struct kexec_info *info,
> + struct crash_elf_info *elf_info,
> + struct memory_range *range,
> + int ranges,
> + void **buf, unsigned long *size,
> + unsigned long align);
> +
> int crash_create_elf32_headers(struct kexec_info *info,
> struct crash_elf_info *elf_info,
> struct memory_range *range, int ranges,
>
--
Best regards,
Maxim Uvarov
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* kexec fixes?
2010-12-16 2:05 mips: elfinfo Simon Horman
2010-12-16 15:33 ` Maxim Uvarov
@ 2010-12-16 22:53 ` Eric W. Biederman
2010-12-17 0:50 ` Simon Horman
1 sibling, 1 reply; 8+ messages in thread
From: Eric W. Biederman @ 2010-12-16 22:53 UTC (permalink / raw
To: Simon Horman; +Cc: kexec
Simon did you ever get my last round of fixes for i386 after
my other changes merged?
I was testing them in my tree, and I was trying to be careful
and not send you something bad. I completed my testing and
but I forget to send you a pull request.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kexec fixes?
2010-12-16 22:53 ` kexec fixes? Eric W. Biederman
@ 2010-12-17 0:50 ` Simon Horman
2010-12-21 9:31 ` Simon Horman
0 siblings, 1 reply; 8+ messages in thread
From: Simon Horman @ 2010-12-17 0:50 UTC (permalink / raw
To: Eric W. Biederman; +Cc: kexec
On Thu, Dec 16, 2010 at 02:53:45PM -0800, Eric W. Biederman wrote:
>
> Simon did you ever get my last round of fixes for i386 after
> my other changes merged?
>
> I was testing them in my tree, and I was trying to be careful
> and not send you something bad. I completed my testing and
> but I forget to send you a pull request.
Hi Eric,
I don't think that I received a pull request and in
any case I don't have anything other than mips fix(es) pending.
So if its not in my tree could you (rebase and) send it again?
Its been a while since there was a release, so it might
be nice (for me) to get a 2.0.3 out the door some time.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mips: elfinfo
2010-12-16 15:33 ` Maxim Uvarov
@ 2010-12-19 23:44 ` Simon Horman
2010-12-21 7:04 ` Maxim Uvarov
0 siblings, 1 reply; 8+ messages in thread
From: Simon Horman @ 2010-12-19 23:44 UTC (permalink / raw
To: Maxim Uvarov; +Cc: kexec, Eric W. Biederman
On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
> 2010/12/16 Simon Horman <horms@verge.net.au>:
> > Hi Maxim,
> >
> > I noticed that your change "Patch adds kernel data section to final vmcore.
> > This forces gdb read kernel" causes the build to break as it was applied
> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> > crash_elf_info" patch.
> >
> > I have it in mind to resolve this something along the lines of
> > the patch below. However, I now see the following warning:
> >
> > kexec/arch/mips/crashdump-mips.c: In function `get_kernel_vaddr_and_size':
> > kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too large for "unsigned long" type
> >
> > Which corresponds to this code:
> >
> > elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> > 0xffffffff80000000UL;
> >
> > I am compiling for 32-bit, so at a glance that constant does
> > seem to large.
> >
>
> Ah, yes this values does not fit to 32 bit UL.
>
> > Also, if you have any tips on a cross-compiling environment for 64bit
> > on a x86_32 or x86_64 host I would be most grateful.
> >
>
> I tested it with building on 32 bit host. readelf -a shows that vmcore
> had memory segment according to kernel memory.
> So that, gdb began to read real values instead of uninitialized.
>
> Actually elf_info->kern_paddr_start | 0xffffffff80000000UL; is needed
> only for 64 bit mips.
> Because we read kernel memory ranges from /proc/vmcore and there are
> values without 0xffffffff at the beginning.
> But 0xfffff... are needed in case if we need access to this address from kernel.
>
> 32 bit mips kernel does not need adding 0xfffffff. But it think there
> will be only warning and nothing wrong.
Understood, but it would be nice to eliminate the warning.
As load_crashdump_segments() is already 32/64 bit aware I wonder
if we could just pass appropriate constant from there as
a parameter of get_kernel_vaddr_and_size().
Perhaps something like the following which
applies on top of my previous patch.
diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index b937ab5..aa50109 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -70,7 +70,8 @@ static int get_kernel_paddr(struct crash_elf_info *elf_info)
return -1;
}
-static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
+static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info,
+ unsigned long start_offset)
{
uint64_t end;
@@ -78,7 +79,7 @@ static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
return -1;
elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
- 0xffffffff80000000UL;
+ start_offset;
if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
elf_info->kern_size = end - elf_info->kern_paddr_start;
#ifdef DEBUG
@@ -358,18 +359,20 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
struct memory_range *mem_range;
crash_create_elf_headers_func crash_create = crash_create_elf32_headers;
struct crash_elf_info *elf_info = &elf_info32;
+ unsigned long start_offset = 0x80000000UL;
#ifdef __mips64
if (arch_options.core_header_type == CORE_TYPE_ELF64) {
elf_info = &elf_info64;
crash_create = crash_create_elf64;
+ start_offset = 0xffffffff80000000UL;
}
#endif
if (get_kernel_paddr(elf_info))
return -1;
- if (get_kernel_vaddr_and_size(elf_info))
+ if (get_kernel_vaddr_and_size(elf_info, start_offset))
return -1;
if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: mips: elfinfo
2010-12-19 23:44 ` Simon Horman
@ 2010-12-21 7:04 ` Maxim Uvarov
2010-12-21 7:36 ` Simon Horman
0 siblings, 1 reply; 8+ messages in thread
From: Maxim Uvarov @ 2010-12-21 7:04 UTC (permalink / raw
To: Simon Horman; +Cc: kexec, Eric W. Biederman
2010/12/20 Simon Horman <horms@verge.net.au>:
> On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
>> 2010/12/16 Simon Horman <horms@verge.net.au>:
>> > Hi Maxim,
>> >
>> > I noticed that your change "Patch adds kernel data section to final vmcore.
>> > This forces gdb read kernel" causes the build to break as it was applied
>> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
>> > crash_elf_info" patch.
>> >
>> > I have it in mind to resolve this something along the lines of
>> > the patch below. However, I now see the following warning:
>> >
>> > kexec/arch/mips/crashdump-mips.c: In function `get_kernel_vaddr_and_size':
>> > kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too large for "unsigned long" type
>> >
>> > Which corresponds to this code:
>> >
>> > elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
>> > 0xffffffff80000000UL;
>> >
>> > I am compiling for 32-bit, so at a glance that constant does
>> > seem to large.
>> >
>>
>> Ah, yes this values does not fit to 32 bit UL.
>>
>> > Also, if you have any tips on a cross-compiling environment for 64bit
>> > on a x86_32 or x86_64 host I would be most grateful.
>> >
>>
>> I tested it with building on 32 bit host. readelf -a shows that vmcore
>> had memory segment according to kernel memory.
>> So that, gdb began to read real values instead of uninitialized.
>>
>> Actually elf_info->kern_paddr_start | 0xffffffff80000000UL; is needed
>> only for 64 bit mips.
>> Because we read kernel memory ranges from /proc/vmcore and there are
>> values without 0xffffffff at the beginning.
>> But 0xfffff... are needed in case if we need access to this address from kernel.
>>
>> 32 bit mips kernel does not need adding 0xfffffff. But it think there
>> will be only warning and nothing wrong.
>
> Understood, but it would be nice to eliminate the warning.
> As load_crashdump_segments() is already 32/64 bit aware I wonder
> if we could just pass appropriate constant from there as
> a parameter of get_kernel_vaddr_and_size().
>
> Perhaps something like the following which
> applies on top of my previous patch.
>
Yes, that has to work. Thanks.
> diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
> index b937ab5..aa50109 100644
> --- a/kexec/arch/mips/crashdump-mips.c
> +++ b/kexec/arch/mips/crashdump-mips.c
> @@ -70,7 +70,8 @@ static int get_kernel_paddr(struct crash_elf_info *elf_info)
> return -1;
> }
>
> -static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
> +static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info,
> + unsigned long start_offset)
> {
> uint64_t end;
>
> @@ -78,7 +79,7 @@ static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
> return -1;
>
> elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> - 0xffffffff80000000UL;
> + start_offset;
> if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
> elf_info->kern_size = end - elf_info->kern_paddr_start;
> #ifdef DEBUG
> @@ -358,18 +359,20 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
> struct memory_range *mem_range;
> crash_create_elf_headers_func crash_create = crash_create_elf32_headers;
> struct crash_elf_info *elf_info = &elf_info32;
> + unsigned long start_offset = 0x80000000UL;
>
> #ifdef __mips64
> if (arch_options.core_header_type == CORE_TYPE_ELF64) {
> elf_info = &elf_info64;
> crash_create = crash_create_elf64;
> + start_offset = 0xffffffff80000000UL;
> }
> #endif
>
> if (get_kernel_paddr(elf_info))
> return -1;
>
> - if (get_kernel_vaddr_and_size(elf_info))
> + if (get_kernel_vaddr_and_size(elf_info, start_offset))
> return -1;
>
> if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
>
--
Best regards,
Maxim Uvarov
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mips: elfinfo
2010-12-21 7:04 ` Maxim Uvarov
@ 2010-12-21 7:36 ` Simon Horman
0 siblings, 0 replies; 8+ messages in thread
From: Simon Horman @ 2010-12-21 7:36 UTC (permalink / raw
To: Maxim Uvarov; +Cc: kexec, Eric W. Biederman
On Tue, Dec 21, 2010 at 10:04:34AM +0300, Maxim Uvarov wrote:
> 2010/12/20 Simon Horman <horms@verge.net.au>:
> > On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
> >> 2010/12/16 Simon Horman <horms@verge.net.au>:
> >> > Hi Maxim,
> >> >
> >> > I noticed that your change "Patch adds kernel data section to final vmcore.
> >> > This forces gdb read kernel" causes the build to break as it was applied
> >> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> >> > crash_elf_info" patch.
> >> >
> >> > I have it in mind to resolve this something along the lines of
> >> > the patch below. However, I now see the following warning:
> >> >
> >> > kexec/arch/mips/crashdump-mips.c: In function `get_kernel_vaddr_and_size':
> >> > kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too large for "unsigned long" type
> >> >
> >> > Which corresponds to this code:
> >> >
> >> > elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> >> > 0xffffffff80000000UL;
> >> >
> >> > I am compiling for 32-bit, so at a glance that constant does
> >> > seem to large.
> >> >
> >>
> >> Ah, yes this values does not fit to 32 bit UL.
> >>
> >> > Also, if you have any tips on a cross-compiling environment for 64bit
> >> > on a x86_32 or x86_64 host I would be most grateful.
> >> >
> >>
> >> I tested it with building on 32 bit host. readelf -a shows that vmcore
> >> had memory segment according to kernel memory.
> >> So that, gdb began to read real values instead of uninitialized.
> >>
> >> Actually elf_info->kern_paddr_start | 0xffffffff80000000UL; is needed
> >> only for 64 bit mips.
> >> Because we read kernel memory ranges from /proc/vmcore and there are
> >> values without 0xffffffff at the beginning.
> >> But 0xfffff... are needed in case if we need access to this address from kernel.
> >>
> >> 32 bit mips kernel does not need adding 0xfffffff. But it think there
> >> will be only warning and nothing wrong.
> >
> > Understood, but it would be nice to eliminate the warning.
> > As load_crashdump_segments() is already 32/64 bit aware I wonder
> > if we could just pass appropriate constant from there as
> > a parameter of get_kernel_vaddr_and_size().
> >
> > Perhaps something like the following which
> > applies on top of my previous patch.
> >
> Yes, that has to work. Thanks.
Thanks, I have pushed this and the previous change.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: kexec fixes?
2010-12-17 0:50 ` Simon Horman
@ 2010-12-21 9:31 ` Simon Horman
0 siblings, 0 replies; 8+ messages in thread
From: Simon Horman @ 2010-12-21 9:31 UTC (permalink / raw
To: Eric W. Biederman; +Cc: kexec
On Fri, Dec 17, 2010 at 09:50:31AM +0900, Simon Horman wrote:
> On Thu, Dec 16, 2010 at 02:53:45PM -0800, Eric W. Biederman wrote:
> >
> > Simon did you ever get my last round of fixes for i386 after
> > my other changes merged?
> >
> > I was testing them in my tree, and I was trying to be careful
> > and not send you something bad. I completed my testing and
> > but I forget to send you a pull request.
>
> Hi Eric,
>
> I don't think that I received a pull request and in
> any case I don't have anything other than mips fix(es) pending.
> So if its not in my tree could you (rebase and) send it again?
>
> Its been a while since there was a release, so it might
> be nice (for me) to get a 2.0.3 out the door some time.
Hi Eric,
do you have any pending changes?
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-12-21 9:31 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-16 2:05 mips: elfinfo Simon Horman
2010-12-16 15:33 ` Maxim Uvarov
2010-12-19 23:44 ` Simon Horman
2010-12-21 7:04 ` Maxim Uvarov
2010-12-21 7:36 ` Simon Horman
2010-12-16 22:53 ` kexec fixes? Eric W. Biederman
2010-12-17 0:50 ` Simon Horman
2010-12-21 9:31 ` Simon Horman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.