----- Original Message -----
> 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@xxxxxxxxxx <crash-utility-bounces@xxxxxxxxxx> on
> behalf of Dave Anderson <anderson@xxxxxxxxxx>
> Sent: Monday, April 20, 2020 22:54
> To: Discussion list for crash utility usage, maintenance and development
> Subject: [营销邮件] Re: [营销邮件] 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@xxxxxxxxxxxxx>
> >>
> >> 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@xxxxxxxxxx
> 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
