It's just a risk,i found this risk when i try to fix
crash-utility launch
error with arm64 in 5.4.
i made the fix patch the almost same as Vinayak's,As a supplement, I make
these two suggestion(vmemmap_start &physvirt_offset).
If the advice is reasonable, you can take it
Let's wait for Vinayak to consolidate everything in his v2 patch update. When he
posts it, please review and give your ACK/NAK.
Thanks,
Dave
________________________________________
From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com> on
behalf of Dave Anderson <anderson(a)redhat.com>
Sent: Monday, April 20, 2020 22:54
To: Discussion list for crash utility usage, maintenance and development
Subject: [营销邮件] Re: [Crash-utility] [营销邮件] Re: [营销邮件] Re: [营销邮件] Re:
[External Mail][????] Re: ramdump support for va_bits_actual
----- Original Message -----
> In fact,vmemmap not easy to calculated in crash-utility,if
> CONFIG_RANDOMIZE_BASE is configured,memstart_addr will be changed since
> below codes:
> [arm64_memblock_init]
> 348 vmemmap = ((struct page *)VMEMMAP_START - (memstart_addr >>
> PAGE_SHIFT));
> ...
> 413 if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> 414 extern u16 memstart_offset_seed;
> 415 u64 range = linear_region_size -
> 416 (memblock_end_of_DRAM() -
> memblock_start_of_DRAM());
> 417
> 418 /*
> 419 * If the size of the linear region exceeds, by a
> sufficient
> 420 * margin, the size of the region that the available
> physical
> 421 * memory spans, randomize the linear region as well.
> 422 */
> 423 if (memstart_offset_seed > 0 && range >=
> ARM64_MEMSTART_ALIGN) {
> 424 range /= ARM64_MEMSTART_ALIGN;
> 425 memstart_addr -= ARM64_MEMSTART_ALIGN *
> 426 ((range *
> memstart_offset_seed) >> 16);
> 427 }
> 428 }
OK.
>
> the reason i showed the "address_markers " is just to prove vmemmap and
> ms->vmemmap_start is wrong.we'd better to do below change.
> - vmemmap_start = (-vmemmap_size);
> + vmemmap_start = (-vmemmap_size - MEGABYTES(2));
>
> $ crash vmlinux vmcore
>
> crash 7.2.9rc13
> Copyright (C) 2002-2020 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005, 2011 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public
> License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> GNU gdb (GDB) 7.6
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <
http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> WARNING: kernel relocated [950MB]: patching 94929 gdb minimal_symbol
> values
>
> crash: start patch...
>
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> Sometimes, we need to know the accurate time of the log, which
>>> helps us analyze the problem.
>>>
>>> add -T option(like dmesg -T command) for log command to display
>>> the message text with human readable timestamp.
>>>
>>> Signed-off-by: Wang Long <w(a)laoqinren.net>
>>
>> Did you attempt this patch on a live system? Because your patch to
>> kernel_init() hangs the session. I didn't bother to investigate beyond
>> adding these two debug statements around your addition to kernel_init():
>>
>> error(INFO, "start patch...\n");
>> get_uptime(NULL, &uptime_jiffies);
>> uptime_sec = (uptime_jiffies)/(ulonglong)machdep->hz;
>> kt->boot_date.tv_sec = kt->date.tv_sec - uptime_sec;
>> kt->boot_date.tv_nsec = 0;
>> error(INFO, "end patch...\n");
>>
>> And that's where it hangs:
>>
>> $ ./crash
>>
>> crash 7.2.9rc13
>> Copyright (C) 2002-2020 Red Hat, Inc.
>> Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
>> Copyright (C) 1999-2006 Hewlett-Packard Co
>> Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
>> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
>> Copyright (C) 2005, 2011 NEC Corporation
>> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
>> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
>> This program is free software, covered by the GNU General Public
>> License,
>> and you are welcome to change it and/or distribute copies of it under
>> certain conditions. Enter "help copying" to see the conditions.
>> This program has absolutely no warranty. Enter "help warranty"
for
>> details.
>>
>> GNU gdb (GDB) 7.6
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <
http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law. Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-unknown-linux-gnu"...
>>
>> WARNING: kernel relocated [796MB]: patching 85687 gdb minimal_symbol
>> values
>>
>> crash: start patch...
>>
>> <hang>
>>
>> And it shows a cpu spinning at 100%:
>>
>> $ top
>> top - 15:26:43 up 38 days, 3:41, 5 users, load average: 1.00, 0.89,
>> 0.65
>> Tasks: 280 total, 2 running, 278 sleeping, 0 stopped, 0 zombie
>> %Cpu(s): 3.9 us, 8.7 sy, 0.0 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si,
>> 0.0 st
>> KiB Mem : 15907600 total, 455876 free, 1232832 used, 14218892
>> buff/cache
>> KiB Swap: 8060924 total, 7395580 free, 665344 used. 14176220 avail
>> Mem
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
>> COMMAND
>> 26668 root 20 0 350268 213688 5680 R 100.0 1.3 5:42.70
>> crash
>> 1707 root 20 0 115692 1184 688 S 0.3 0.0 2:16.52
>> ksmtuned
>> 12852 anderson 20 0 4235240 274608 20320 S 0.3 1.7 601:46.85
>> gnome-shell
>> 13060 anderson 20 0 804924 14100 3744 S 0.3 0.1 118:44.59
>> gsd-color
>> 27045 anderson 20 0 172452 2532 1648 R 0.3 0.0 0:00.08 top
>> 1 root 20 0 210504 5592 3224 S 0.0 0.0 18:14.19
>> systemd
>> ...
>>
>> I'll let you figure it out...
>>
>> Dave
>>
>>
>>
>>
>>
>>
>>> ---
>>>
This looks correct, although I've never seen a problem using the current
setting on 5.4 and later kernels. What happens on your system? Is your
system's memstart_addr within that low 2MB?
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
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!******/#
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility