Abort in "kmem -i" command
by Kazuhito Hagio
Hi Dave,
I'm faced with abort in "kmem -i" command with some vmcores
and looking into it, but I haven't found the cause so far.
Could you possibly take a look at this issue?
I attached the abort log. I can send you the core and vmcore.
Depending on execution, the occurrences vary.
* abort, <segmentation violation in gdb>, or no problem
* If not reproduced with interactive "crash> kmem -i", you may
reproduce it with "echo 'kmem -i' | crash vmlinux vmcore".
* observed in "kmem -V" and "kmem -z" as well
* also observed on i686 with kernel 4.14 vmcore
* latest crash (1926150e)
Thanks,
Kazu
7 years, 4 months
Re: [Crash-utility] [PATCH] book3s/ppc64: Increase the VA range
by Dave Anderson
----- Original Message -----
>
> Since kernel commit c2b4d8b7417a ("powerpc/mm/hash64: Increase the VA
> range"), the max virtual (effective) address value has been increased
> to 4PB. Update page table index values accordingly.
>
> Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com>
Hari,
Thanks for the quick response -- queued for crash-7.2.4:
https://github.com/crash-utility/crash/commit/28fa7bd09013455b5ddc020dea4...
Dave
> ---
> defs.h | 1 +
> ppc64.c | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/defs.h b/defs.h
> index 6e6f6be..e6e3850 100644
> --- a/defs.h
> +++ b/defs.h
> @@ -3977,6 +3977,7 @@ struct efi_memory_desc_t {
> #define PMD_INDEX_SIZE_L4_64K_4_12 10
> #define PUD_INDEX_SIZE_L4_64K_4_12 7
> #define PGD_INDEX_SIZE_L4_64K_4_12 8
> +#define PUD_INDEX_SIZE_L4_64K_4_17 10
> #define PTE_INDEX_SIZE_RADIX_64K 5
> #define PMD_INDEX_SIZE_RADIX_64K 9
> #define PUD_INDEX_SIZE_RADIX_64K 9
> diff --git a/ppc64.c b/ppc64.c
> index 0dd8a2a..f5d0dac 100644
> --- a/ppc64.c
> +++ b/ppc64.c
> @@ -451,7 +451,10 @@ ppc64_init(int when)
>
> if (THIS_KERNEL_VERSION >= LINUX(4,12,0)) {
> m->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_12;
> - m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
> + if (THIS_KERNEL_VERSION >= LINUX(4,17,0))
> + m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_17;
> + else
> + m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
> m->l4_index_size = PGD_INDEX_SIZE_L4_64K_4_12;
> } else {
> m->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
>
7 years, 4 months
[PATCH] book3s/ppc64: Increase the VA range
by Hari Bathini
Since kernel commit c2b4d8b7417a ("powerpc/mm/hash64: Increase the VA
range"), the max virtual (effective) address value has been increased
to 4PB. Update page table index values accordingly.
Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com>
---
defs.h | 1 +
ppc64.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/defs.h b/defs.h
index 6e6f6be..e6e3850 100644
--- a/defs.h
+++ b/defs.h
@@ -3977,6 +3977,7 @@ struct efi_memory_desc_t {
#define PMD_INDEX_SIZE_L4_64K_4_12 10
#define PUD_INDEX_SIZE_L4_64K_4_12 7
#define PGD_INDEX_SIZE_L4_64K_4_12 8
+#define PUD_INDEX_SIZE_L4_64K_4_17 10
#define PTE_INDEX_SIZE_RADIX_64K 5
#define PMD_INDEX_SIZE_RADIX_64K 9
#define PUD_INDEX_SIZE_RADIX_64K 9
diff --git a/ppc64.c b/ppc64.c
index 0dd8a2a..f5d0dac 100644
--- a/ppc64.c
+++ b/ppc64.c
@@ -451,7 +451,10 @@ ppc64_init(int when)
if (THIS_KERNEL_VERSION >= LINUX(4,12,0)) {
m->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_12;
- m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
+ if (THIS_KERNEL_VERSION >= LINUX(4,17,0))
+ m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_17;
+ else
+ m->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
m->l4_index_size = PGD_INDEX_SIZE_L4_64K_4_12;
} else {
m->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
7 years, 4 months
regression with System.map handling on 4.14 +?
by Jinpu Wang
Hi Dave, hi co,
I noticed a behaviour change regarding System.map handling regarding
newer kernel like 4.14+
As a example:
below command works:
crash -d 1 vmlinux-4.14.43-1-pserver ps402a-30-dump.201806041421 > good.txt
below command report error:
crash -d 1 vmlinux-4.14.43-1-pserver System.map-4.14.43-1-pserver
ps402a-30-dump.201806041421 > bad.txt
crash: page excluded: kernel virtual address: ffffffff82237f18 type:
"page_offset_base"
When compare the difference between good.txt and bad.txt, I noticed
following only in good.txt:
KASLR:
_stext from vmlinux-4.14.43-1-pserver: ffffffff81000000
_stext from vmcoreinfo: ffffffff9e000000
relocate: 1d000000 (464MB)
I tried also on latest Ubuntu 1804, crash reports same error when run
with System.map file.
Is this expected?
Thanks,
--
Jack Wang
Linux Kernel Developer
ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin
Tel: +49 30 577 008 042
Fax: +49 30 577 008 299
Email: jinpu.wang(a)profitbricks.com
URL: https://www.profitbricks.de
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
7 years, 5 months
regression with System.map handling on 4.14 +?
by Jack Wang
Hi Dave, hi co,
I noticed a behaviour change regarding System.map handling regarding
newer kernel like 4.14+
As a example:
below command works:
crash -d 1 vmlinux-4.14.43-1-pserver ps402a-30-dump.201806041421 > good.txt
below command report error:
crash -d 1 vmlinux-4.14.43-1-pserver System.map-4.14.43-1-pserver
ps402a-30-dump.201806041421 > bad.txt
crash: page excluded: kernel virtual address: ffffffff82237f18 type:
"page_offset_base"
When compare the difference between good.txt and bad.txt, I noticed
following only in good.txt:
KASLR:
_stext from vmlinux-4.14.43-1-pserver: ffffffff81000000
_stext from vmcoreinfo: ffffffff9e000000
relocate: 1d000000 (464MB)
I tried also on latest Ubuntu 1804, crash reports same error when run
with System.map file.
Is this expected?
Thanks,
--
Jack Wang Linux kernel developer ProfitBricks GmbH
PS: sorry for resending, email awaits approval, so send with personal
email address.
7 years, 5 months
