Re: [Crash-utility] Kernel Crash Analysis on Android
by Shankar, AmarX
Hi Dave,
Thanks for your info regarding kexec tool.
I am unable to download kexec from below link.
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-too...
It says HTTP 404 Page Not Found.
Could you please guide me on this?
Thanks & Regards,
Amar Shankar
> On Wed, Mar 21, 2012 at 06:00:00PM +0000, Shankar, AmarX wrote:
>
> > I want to do kernel crash Analysis on Android Merrifield Target.
> >
> > Could someone please help me how to do it?
>
> Merrifield is pretty much similar than Medfield, e.g it has x86 core. So I
> guess you can follow the instructions how to setup kdump on x86 (see
> Documentation/kdump/kdump.txt) unless you already have that configured.
>
> crash should support this directly presuming you have vmlinux/vmcore files to
> feed it. You can configure crash to support x86 on x86_64 host by running:
>
> % make target=X86
> & make
>
> (or something along those lines).
Right -- just the first make command will suffice, i.e., when running
on an x86_64 host:
$ wget http://people.redhat.com/anderson/crash-6.0.4.tar.gz
$ tar xzf crash-6.0.4.tar.gz
...
$ cd crash-6.0.4
$ make target=X86
...
$ ./crash <path-to>/vmlinux <path-to>/vmcore
Dave
From: Shankar, AmarX
Sent: Wednesday, March 21, 2012 11:30 PM
To: 'crash-utility(a)redhat.com'
Subject: Kernel Crash Analysis on Android
Hi,
I want to do kernel crash Analysis on Android Merrifield Target.
Could someone please help me how to do it?
Thanks & Regards,
Amar Shankar
1 year
[PATCH] kmem, snap: iomem/ioport display and vmcore snapshot support
by HATAYAMA Daisuke
Some days ago I was in a situation that I had to convert vmcore in
kvmdump format into ELF since some extension module we have locally
can be used only on relatively old crash utility, around version 4,
but such old crash utility cannot handle kvmdump format.
To do the conversion in handy, I used snap command with some modifications
so that it tries to use iomem information in vmcore instead of host's
/proc/iomem. This patch is its cleaned-up version.
In this development, I naturally got down to also making an interface
for an access to resource objects, and so together with the snap
command's patch, I also extended kmem command for iomem/ioport
support. Actually:
kmem -r displays /proc/iomem
crash> kmem -r
00000000-0000ffff : reserved
00010000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c7fff : Video ROM
...
and kmem -R displays /proc/ioport
crash> kmem -R
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
...
Looking into old version of kernel source code back, resource structure
has been unchanged since linux-2.4.0. I borrowed the way of walking on
resouce tree in this patch from the lastest v3.3-rc series, but I
guess the logic is also applicable to old kernels. I expect Dave's
regression testsuite.
Also, there would be another command more sutable for iomem/ioport.
If necessay, I'll repost the patch.
---
HATAYAMA Daisuke (4):
Add vmcore snapshot support
Add kmem -r and -R options
Add dump iomem/ioport functions; a helper for resource objects
Add a helper function for iterating resource objects
defs.h | 9 ++++
extensions/snap.c | 54 ++++++++++++++++++++++-
help.c | 2 +
memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 180 insertions(+), 7 deletions(-)
--
Thanks.
HATAYAMA Daisuke
1 year
Re: [Crash-utility] question about phys_base
by Dave Anderson
----- Original Message -----
> >
> > OK, so then I don't understand what you mean by "may be the same"?
> >
> > You didn't answer my original question, but if I understand you correctly,
> > it would be impossible for the qemu host to create a PT_LOAD segment that
> > describes an x86_64 guest's __START_KERNEL_map region, because the host
> > doesn't know that what kind of kernel the guest is running.
>
> Yes. Even if the guest is linux, it is still impossible to do it. Because
> the guest maybe in the second kernel.
>
> qemu-dump walks all guest's page table and collect virtual address and
> physical address mapping. If the page is not used by guest, the virtual is set
> to 0. I create PT_LOAD according to such mapping. So if the guest is linux,
> there may be a PT_LOAD segment that describes __START_KERNEL_map region.
> But the information stored in PT_LOAD maybe for the second kernel. If crash
> uses it, crash will see the second kernel, not the first kernel.
Just to be clear -- what do you mean by the "second" kernel? Do you
mean that a guest kernel crashed guest, and did a kdump operation,
and that second kdump kernel failed somehow, and now you're trying
to do a "virsh dump" on the kdump kernel?
Dave
1 year
question about phys_base
by Wen Congyang
Hi, Dave
I am implementing a new dump command in the qemu. The vmcore's
format is elf(like kdump). And I try to provide phys_base in
the PT_LOAD. But if the os uses the first vcpu do kdump, the
value of phys_base is wrong.
I find a function x86_64_virt_phys_base() in crash's code.
Is it OK to call this function first? If the function
successes, we do not calculate phys_base according to PT_LOAD.
Thanks
Wen Congyang
1 year
[PATCH] runq: search current task's runqueue explicitly
by HATAYAMA Daisuke
Currently, runq sub-command doesn't consider CFS runqueue's current
task removed from CFS runqueue. Due to this, the remaining CFS
runqueus that follow the current task's is not displayed. This patch
fixes this by making runq sub-command search current task's runqueue
explicitly.
Note that CFS runqueue exists for each task group, and so does CFS
runqueue's current task, and the above search needs to be done
recursively.
Test
====
On vmcore I made 7 task groups:
root group --- A --- AA --- AAA
+ +- AAB
|
+- AB --- ABA
+- ABB
and then I ran three CPU bound tasks, which is exactly the same as
int main(void) { for (;;) continue; return 0; }
for each task group, including root group; so total 24 tasks. For
readability, I annotated each task name with its belonging group name.
For example, loop.ABA belongs to task group ABA.
Look at CPU0 collumn below. [before] lacks 8 tasks and [after]
successfully shows all tasks on the runqueue, which is identical to
the result of [sched debug] that is expected to ouput correct result.
I'll send this vmcore later.
[before]
crash> runq | cat
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
<cut>
[after]
crash_fix> runq
CPU 0 RUNQUEUE: ffff88000a215f80
CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
RT PRIO_ARRAY: ffff88000a216098
[no tasks queued]
CFS RB_ROOT: ffff88000a216010
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
<cut>
[sched debug]
crash> runq -d
CPU 0
[120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A"
[120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA"
[120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA"
[120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA"
[120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB"
[120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB"
[120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA"
[120] PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA"
[120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB"
[120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB"
<cut>
Diff stat
=========
defs.h | 1 +
task.c | 37 +++++++++++++++++--------------------
2 files changed, 18 insertions(+), 20 deletions(-)
Thanks.
HATAYAMA, Daisuke
1 year
[RFC] makedumpfile, crash: LZO compression support
by HATAYAMA Daisuke
Hello,
This is a RFC patch set that adds LZO compression support to
makedumpfile and crash utility. LZO is as good as in size but by far
better in speed than ZLIB, leading to reducing down time during
generation of crash dump and refiltering.
How to build:
1. Get LZO library, which is provided as lzo-devel package on recent
linux distributions, and is also available on author's website:
http://www.oberhumer.com/opensource/lzo/.
2. Apply the patch set to makedumpfile v1.4.0 and crash v6.0.0.
3. Build both using make. But for crash, do the following now:
$ make CFLAGS="-llzo2"
How to use:
I've newly used -l option for lzo compression in this patch. So for
example, do as follows:
$ makedumpfile -l vmcore dumpfile
$ crash vmlinux dumpfile
Request of configure-like feature for crash utility:
I would like configure-like feature on crash utility for users to
select wheather to add LZO feature actually or not in build-time,
that is: ./configure --enable-lzo or ./configure --disable-lzo.
The reason is that support staff often downloads and installs the
latest version of crash utility on machines where lzo library is not
provided.
Looking at the source code, it looks to me that crash does some kind
of configuration processing in a local manner, around configure.c,
and I guess it's difficult to use autoconf tools directly.
Or is there another better way?
Performance Comparison:
Sample Data
Ideally, I must have measured the performance for many enough
vmcores generated from machines that was actually running, but now
I don't have enough sample vmcores, I couldn't do so. So this
comparison doesn't answer question on I/O time improvement. This
is TODO for now.
Instead, I choosed worst and best cases regarding compression
ratio and speed only. Specifically, the former is /dev/urandom and
the latter is /dev/zero.
I get the sample data of 10MB, 100MB and 1GB by doing like this:
$ dd bs=4096 count=$((1024*1024*1024/4096)) if=/dev/urandom of=urandom.1GB
How to measure
Then I performed compression for each block, 4096 bytes, and
measured total compression time and output size. See attached
mycompress.c.
Result
See attached file result.txt.
Discussion
For both kinds of data, lzo's compression was considerably quicker
than zlib's. Compression ratio is about 37% for urandom data, and
about 8.5% for zero data. Actual situation of physical memory
would be in between the two cases, and so I guess average
compression time ratio is between 37% and 8.5%.
Although beyond the topic of this patch set, we can estimate worst
compression time on more data size since compression is performed
block size wise and the compression time increases
linearly. Estimated worst time on 2TB memory is about 15 hours for
lzo and about 40 hours for zlib. In this case, compressed data
size is larger than the original, so they are really not used,
compression time is fully meaningless. I think compression must be
done in parallel, and I'll post such patch later.
Diffstat
* makedumpfile
diskdump_mod.h | 3 +-
makedumpfile.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++------
makedumpfile.h | 12 +++++++
3 files changed, 101 insertions(+), 12 deletions(-)
* crash
defs.h | 1 +
diskdump.c | 20 +++++++++++++++++++-
diskdump.h | 3 ++-
3 files changed, 22 insertions(+), 2 deletions(-)
TODO
* evaluation including I/O time using actual vmcores
Thanks.
HATAYAMA, Daisuke
1 year
Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
1 year
Re: [Crash-utility] [External Mail]Re: [PATCH] optimize the way to find the panic task.
by 陈启武
Hi Dave,
Thanks for your review. It's a great honor to give me some valuable suggestions about my patch.
I have different points of view about the definition of max logbuf length.
In upstream kernel, the max logbuf length is still determined by arch-specific CONFIG_LOG_BUF_SHIFT definition.
[kernel/printk/printk.c]
#define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT)
static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN);
LOG_BUF_LEN_MAX comes from commit e6fe3e5b7d16e8f146a4ae7fe481bc6e97acde1e, which give error on
attempt to set log buffer length to over 2G.
For the question where I got the MAX_BUFSIZE of 2MB?
I'm working on QCOM's ARM64 arch. In QCOM's kernel-4.14 code, the max logbuf length is set to 2MB.
[arch/arm64/configs/xxx_config]
CONFIG_LOG_BUF_SHIFT=21
Above your suggestions, I have correct the logic error and made some significant changes for my patch.
The new patch file has been upload to attachment.
Thanks for your review. I’m looking forward to your favourable reply!
Best regards,
Qiwu
-----Original Message-----
From: Dave Anderson <anderson(a)redhat.com>
Sent: Thursday, October 17, 2019 4:33 AM
To: 陈启武 <chenqiwu(a)xiaomi.com>
Subject: [External Mail]Re: [PATCH] optimize the way to find the panic task.
Hi Qiwu,
I tested your patch against several ARM64 dumpfiles that I have on hand, and a couple of them that were created with "virsh dump" generated a segmentation violations like this:
...
please wait... (determining panic task)
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6bba0b0 in __strstr_sse42 () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libgcc-4.8.5-36.el7_6.2.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64 lzo-2.06-8.el7.x86_64 ncurses-libs-5.9-14.20130511.el7_4.x86_64 snappy-1.1.0-3.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) bt
#0 0x00007ffff6bba0b0 in __strstr_sse42 () from /lib64/libc.so.6
#1 0x00000000004b6389 in get_log_panic_task () at task.c:7485
#2 0x00000000004ccefe in panic_search () at task.c:7361
#3 get_panic_context () at task.c:6205
#4 task_init () at task.c:642
#5 0x0000000000460be5 in main_loop () at main.c:774
#6 0x0000000000659383 in captured_command_loop (data=data@entry=0x0) at main.c:258
#7 0x00000000006580aa in catch_errors (func=func@entry=0x659370 <captured_command_loop>, func_args=func_args@entry=0x0,
errstring=errstring@entry=0x890f87 "", mask=mask@entry=6) at exceptions.c:557
#8 0x000000000065a316 in captured_main (data=data@entry=0x7fffffffdb30) at main.c:1064
#9 0x00000000006580aa in catch_errors (func=func@entry=0x659650 <captured_main>, func_args=func_args@entry=0x7fffffffdb30,
errstring=errstring@entry=0x890f87 "", mask=mask@entry=6) at exceptions.c:557
#10 0x000000000065a677 in gdb_main (args=0x7fffffffdb30) at main.c:1079
#11 gdb_main_entry (argc=<optimized out>, argv=argv@entry=0x7fffffffdc98) at main.c:1099
#12 0x00000000004eeab4 in gdb_main_loop (argc=<optimized out>, argc@entry=3, argv=argv@entry=0x7fffffffdc98) at gdb_interface.c:76
#13 0x000000000045f03a in main (argc=3, argv=0x7fffffffdc98) at main.c:707
(gdb)
The SIGSEGV is the strstr() call in get_log_panic_task(), where the "buf"
pointer must be OK, but for some reason "i" is not available in the gdb session. So I added the following debug line:
7479 BZERO(buf, MAX_BUFSIZE);
7480 open_tmpfile();
7481 dump_log(SHOW_LOG_TEXT);
7482 rewind(pc->tmpfile);
7483 if (fread(buf, 1, MAX_BUFSIZE, pc->tmpfile)) {
7484 while (panic_keywords[i++]) {
7485 fprintf(stderr, "[%d][%s]\n", i, panic_keywords[i]);
7486 if ((p1 = strstr(buf, panic_keywords[i]))) {
7487 if ((p1 = strstr(p1, "CPU: "))) {
7488 p1 += strlen("CPU: ");
7489 p2 = p1;
7490
and as expected, it runs off the end of the panic_keywords[] array:
...
please wait... (determining panic task)[1][BUG: unable to handle kernel]
[2][Kernel BUG at]
[3][kernel BUG at]
[4][Bad mode in]
[5][Oops]
[6][Kernel panic]
[7][(null)]
Segmentation fault (core dumped)
$
But anyway, aside from the logic error above, a couple other comments:
(1) I do not want to change the order in which the panic task
search is made -- it should still try "foreach bt" first,
and only if that fails, search the log.
(2) The upstream kernel has a LOG_BUF_LEN_MAX that is 2GB,
so I'm not sure where you got the MAX_BUFSIZE of 2MB?
(3) But regardless of the log buffer size, I don't like the idea
of reading the whole log into a buffer. It's already captured
into a temporary file that can be searched, so why bother copying
it into another buffer?
I would suggest using "while (fgets(buf, BUFSIZE, pc->tmpfile))"
instead. BUFSIZE should be large enough to contain any line in the log buffer, or certainly any line that contains one of the panic_keywords[] strings.
Also, can you please post any patches to the crash-utility mailing list instead of emailing me directly?
Thanks,
Dave
----- Original Message -----
> Hi Dave,
> I‘m working on arm64 kdump by crash-7.2.7, there is a warning msg "
> panic task not found " gernarated as below:
>
> please wait... (determining panic task)
> KERNEL: vmlinux
> DUMPFILES: /var/tmp/ramdump_elf_8mA3xU [temporary ELF header]
> DDRCS0_0.BIN
> DDRCS1_0.BIN
> DDRCS1_1.BIN
> CPUS: 8
> DATE: Sat Feb 6 10:11:39 1971
> UPTIME: 00:00:07
> LOAD AVERAGE: 0.64, 0.13, 0.04
> TASKS: 624
> NODENAME: localhost
> RELEASE: 4.4.184-perf-gdaa9cd595d7e-dirty
> VERSION: #1 SMP PREEMPT Thu Aug 22 14:41:16 CST 2019
> MACHINE: aarch64 (unknown Mhz)
> MEMORY: 5.7 GB
> PANIC: "Unable to handle kernel paging request at virtual address
> ffffffd532a1b2f8"
> PID: 0
> COMMAND: "swapper/0"
> TASK: ffffff803ec15390 (1 of 8) [THREAD_INFO: ffffff803ec15390]
> CPU: 0
> STATE: TASK_RUNNING
> WARNING: panic task not found
>
> The panic task cannot be found by the following backtrace, result in
> the error running task info in the overview showing :
> [ 7.630611] Process swapper/4 (pid: 0, stack limit = 0xffffffd536704000)
> [ 7.630614] Call trace:
> [ 7.630661] [<ffffffd532a1b2f8>] 0xffffffd532a1b2f8
> [ 7.630666] [<ffffff803c71d92c>] run_timer_softirq+0x508/0x554
> [ 7.630671] [<ffffff803c6835e4>] __do_softirq+0x1fc/0x3e4
> [ 7.630676] [<ffffff803c6aa0f0>] irq_exit+0x88/0xd0
> [ 7.630681] [<ffffff803c70b330>] __handle_domain_irq+0x8c/0xac
> [ 7.630685] [<ffffff803c681154>] gic_handle_irq+0xc8/0x190
>
> So I introduce this patch to optimize the way for finding the panic task.
> We can find the panic task by searching arch-specific panic keywords
> from kernel log.
> I define some arch-specific panic keywords in a const array by
> printing order of panic:
> const char* panic_keywords[] = {
> "Unable to handle kernel",
> "BUG: unable to handle kernel",
> "Kernel BUG at",
> "kernel BUG at",
> "Bad mode in",
> "Oops",
> "Kernel panic"
> };
> We can search these panic keywords orderly from kernel log.
> Generally, these panic keywords follow by printing out the stack trace
> info of panic. Arch-specific dump_stack() implementations can use
> dump_stack_print_info() function to print out the same generic debug
> info. So we can determine the panic task by finding the first
> keyword("CPU: ") behind the panic keyword have found.
>
> The patch file has been upload to attachment.
> Thanks for your review. I’m looking forward to your favourable reply!
>
> Best regards,
> Qiwu
> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部
> 或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> XIAOMI, which is intended only for the person or entity whose address
> is listed above. Any use of the information contained herein in any
> way (including, but not limited to, total or partial disclosure,
> reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error,
> please notify the sender by phone or email immediately and delete
> it!******/#
>
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
5 years, 1 month
[PATCH] Fix for "kmem -n" option on Linux 5.4-rc1
by Masayoshi Mizuma
From: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
Fix for Linux 5.4-rc1 and later kernels that contain commit
b6c88d3b9d38 ("drivers/base/memory.c: don't store end_section_nr
in memory blocks"). Without this patch, kmem -n stops as the following:
crash> kmem -n
...
kmem: invalid structure member offset: memory_block_end_section_nr
FILE: memory.c LINE: 17426 FUNCTION: print_memory_block()
[./crash] error trace: 4b0b83 => 4b00fe => 5430e1 => 543063
543063: OFFSET_verify.part.28+51
5430e1: OFFSET_verify+49
4b00fe: print_memory_block+147
4b0b83: dump_memory_blocks+813
To fix this, use either memory_block_size_probed. If the symbol
doesn't exist, then use memory_block.end_section_nr. Either value
should be available on the kernel.
And the start section number is enough to get the memory block,
so change the output to show the start section number.
Signed-off-by: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
---
help.c | 2 +-
memory.c | 42 +++++++++++++++++++++++++-----------------
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/help.c b/help.c
index a5218a7..cfd46c3 100644
--- a/help.c
+++ b/help.c
@@ -7177,7 +7177,7 @@ char *help_kmem[] = {
" 6 ffff88003d4d90c0 ffffea0000000000 ffffea0000c00000 PM 196608",
" 7 ffff88003d4d90e0 ffffea0000000000 ffffea0000e00000 PM 229376",
" ",
-" MEM_BLOCK NAME PHYSICAL RANGE STATE SECTIONS",
+" MEM_BLOCK NAME PHYSICAL RANGE STATE START_SECTION_NO",
" ffff88003a707c00 memory0 0 - 7ffffff ONLINE 0",
" ffff88003a6e0000 memory1 8000000 - fffffff ONLINE 1",
" ffff88003a6e1000 memory2 10000000 - 17ffffff ONLINE 2",
diff --git a/memory.c b/memory.c
index fe82fac..a7ed915 100644
--- a/memory.c
+++ b/memory.c
@@ -17402,20 +17402,18 @@ fill_memory_block_name(ulong memblock, char *name)
}
static void
-fill_memory_block_srange(ulong start_sec, ulong end_sec, char *srange)
+fill_memory_block_srange(ulong start_sec, char *srange)
{
memset(srange, 0, sizeof(*srange) * BUFSIZE);
- if (start_sec == end_sec)
- sprintf(srange, "%lu", start_sec);
- else
- sprintf(srange, "%lu-%lu", start_sec, end_sec);
+ sprintf(srange, "%lu", start_sec);
}
static void
print_memory_block(ulong memory_block)
{
ulong start_sec, end_sec, start_pfn, end_pfn, nid;
+ ulong memblock_size, mbs, start_addr, end_addr;
char statebuf[BUFSIZE];
char srangebuf[BUFSIZE];
char name[BUFSIZE];
@@ -17430,15 +17428,25 @@ print_memory_block(ulong memory_block)
readmem(memory_block + OFFSET(memory_block_start_section_nr), KVADDR,
&start_sec, sizeof(void *), "memory_block start_section_nr",
FAULT_ON_ERROR);
- readmem(memory_block + OFFSET(memory_block_end_section_nr), KVADDR,
- &end_sec, sizeof(void *), "memory_block end_section_nr",
- FAULT_ON_ERROR);
- start_pfn = section_nr_to_pfn(start_sec);
- end_pfn = section_nr_to_pfn(end_sec + 1);
+ start_addr = pfn_to_phys(section_nr_to_pfn(start_sec));
+
+ if (symbol_exists("memory_block_size_probed")) {
+ memblock_size = symbol_value("memory_block_size_probed");
+ readmem(memblock_size, KVADDR,
+ &mbs, sizeof(ulong), "memory_block_size_probed",
+ FAULT_ON_ERROR);
+ end_addr = start_addr + mbs - 1;
+ } else {
+ readmem(memory_block + OFFSET(memory_block_end_section_nr), KVADDR,
+ &end_sec, sizeof(void *), "memory_block end_section_nr",
+ FAULT_ON_ERROR);
+ end_addr = pfn_to_phys(section_nr_to_pfn(end_sec + 1)) - 1;
+ }
+
fill_memory_block_state(memory_block, statebuf);
fill_memory_block_name(memory_block, name);
- fill_memory_block_srange(start_sec, end_sec, srangebuf);
+ fill_memory_block_srange(start_sec, srangebuf);
if (MEMBER_EXISTS("memory_block", "nid")) {
readmem(memory_block + OFFSET(memory_block_nid), KVADDR, &nid,
@@ -17448,9 +17456,9 @@ print_memory_block(ulong memory_block)
MKSTR(memory_block)),
mkstring(buf2, 12, CENTER, name),
mkstring(buf3, PADDR_PRLEN, RJUST|LONG_HEX,
- MKSTR(pfn_to_phys(start_pfn))),
+ MKSTR(start_addr)),
mkstring(buf4, PADDR_PRLEN, LJUST|LONG_HEX,
- MKSTR(pfn_to_phys(end_pfn) - 1)),
+ MKSTR(end_addr)),
mkstring(buf5, strlen("NODE"), CENTER|LONG_DEC,
MKSTR(nid)),
mkstring(buf6, strlen("CANCEL_OFFLINE"), LJUST,
@@ -17462,9 +17470,9 @@ print_memory_block(ulong memory_block)
MKSTR(memory_block)),
mkstring(buf2, 10, CENTER, name),
mkstring(buf3, PADDR_PRLEN, RJUST|LONG_HEX,
- MKSTR(pfn_to_phys(start_pfn))),
+ MKSTR(start_addr)),
mkstring(buf4, PADDR_PRLEN, LJUST|LONG_HEX,
- MKSTR(pfn_to_phys(end_pfn) - 1)),
+ MKSTR(end_addr)),
mkstring(buf5, strlen("CANCEL_OFFLINE"), LJUST,
statebuf),
mkstring(buf6, 12, LJUST, srangebuf));
@@ -17552,14 +17560,14 @@ dump_memory_blocks(int initialize)
mkstring(buf3, PADDR_PRLEN*2 + 2, CENTER, "PHYSICAL RANGE"),
mkstring(buf4, strlen("NODE"), CENTER, "NODE"),
mkstring(buf5, strlen("CANCEL_OFFLINE"), LJUST, "STATE"),
- mkstring(buf6, 12, LJUST, "SECTIONS"));
+ mkstring(buf6, 12, LJUST, "START_SECTION_NO"));
else
sprintf(mb_hdr, "\n%s %s %s %s %s\n",
mkstring(buf1, VADDR_PRLEN, CENTER|LJUST, "MEM_BLOCK"),
mkstring(buf2, 10, CENTER, "NAME"),
mkstring(buf3, PADDR_PRLEN*2, CENTER, "PHYSICAL RANGE"),
mkstring(buf4, strlen("CANCEL_OFFLINE"), LJUST, "STATE"),
- mkstring(buf5, 12, LJUST, "SECTIONS"));
+ mkstring(buf5, 12, LJUST, "START_SECTION_NO"));
fprintf(fp, "%s", mb_hdr);
for (i = 0; i < klistcnt; i++) {
--
2.18.1
5 years, 1 month
