Re: [Crash-utility] new printk ringbuffer interface
by HAGIO KAZUHITO(萩尾 一仁)
ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> -----Original Message-----
>
> ----- Original Message -----
> > Hello Dave,
> >
> > You may or may not be aware that we are working on replacing [0] the
> > Linux printk ringbuffer. Rather than a single buffer containing a single
> > struct type, the new ringbuffer makes use of several different structs.
>
> Yes, I am most definitely aware...
>
> >
> > I am writing to ask your advice about how this should be exported for
> > the crash utility. Should all struct sizes and field offsets be
> > exported? It would look something like this:
> >
> > VMCOREINFO_SYMBOL(prb);
> >
> > VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
> > VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
> > VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
> > VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
> > VMCOREINFO_OFFSET(printk_ringbuffer, fail);
> >
> > VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
> > VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
> > VMCOREINFO_OFFSET(prb_desc_ring, descs);
> > VMCOREINFO_OFFSET(prb_desc_ring, head_id);
> > VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
> >
> > VMCOREINFO_STRUCT_SIZE(prb_desc);
> > VMCOREINFO_OFFSET(prb_desc, info);
> > VMCOREINFO_OFFSET(prb_desc, state_var);
> > VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
> > VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
> >
> > VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
> > VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
> > VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
> >
> > VMCOREINFO_STRUCT_SIZE(printk_info);
> > VMCOREINFO_OFFSET(printk_info, seq);
> > VMCOREINFO_OFFSET(printk_info, ts_nsec);
> > VMCOREINFO_OFFSET(printk_info, text_len);
> > VMCOREINFO_OFFSET(printk_info, dict_len);
> > VMCOREINFO_OFFSET(printk_info, caller_id);
> >
> > VMCOREINFO_STRUCT_SIZE(prb_data_ring);
> > VMCOREINFO_OFFSET(prb_data_ring, size_bits);
> > VMCOREINFO_OFFSET(prb_data_ring, data);
> > VMCOREINFO_OFFSET(prb_data_ring, head_id);
> > VMCOREINFO_OFFSET(prb_data_ring, tail_id);
> >
> > Or would it be enough to just recognize the new "prb" symbol and have
> > all the structures defined in the crash utility? If the latter is
> > preferred, should some sort of version number be exported? Or is the
> > kernel version number enough?
first I don't think we can depend on the kernel version because distribution
kernels backport upstream patches. So we will need a version number of the
ringbuffer if we choose that way.
I think that "exporting all things" can sometimes reflect changes in kernel
automatically and can reduce tool side effort more than "exporting a version
number". But the former requires a lot of entries and it might be hard for
us to track the changes. So having an explicit version might be better and
I'm ok with the latter.
But I hope no missing update of the version number..
Any thoughts from vmcore-dmesg side?
Thanks,
Kazu
> >
> > I appreciate your feedback.
> >
> > John Ogness
>
> With respect to the crash utility, there are two answers.
>
> When running crash session normally, i.e. running "crash vmlinux vmcore", the runtime
> "log" command does not use any VMCOREINFO entries that happen to be attached to a dumpfile.
> Since crash has the vmlinux debuginfo data available, it uses its own interfaces to get
> all kernel symbol and structure related information.
>
> But there is a little-used capability where the the vmlinux file is not required,
> but rather just the vmcore, in its "crash --log vmcore" feature. That functionality
> does require the VMCOREINFO entries to extract/dump the log, and exit. Honestly I wish
> I had never even introduced that feature. And I wonder if it were deprecated,
> would anybody care?
>
> However, your question is highly relevant to the makedumpfile(8) facility
> for its "makedumpfile --dump-dmesg" option. Since it doesn't have the
> luxury of a vmlinux file, it needs all of the VMCOREINF_xxx items. Kazuhito
> Hagio is the makedumpfile maintainer, and since he is the primary customer
> of the VMCOREINFO entries, he would be a better person to answer your
> question.
>
> That being said, due the sheer number VMCOREINFO entries required, I like
> your idea of providing a single version number. But I defer to Kazu for
> his preference.
>
> Thanks,
> Dave
>
>
>
>
4 years, 6 months
- 5
- 8
[ANNOUNCE] My retirement, and crash utility maintainership changes
by Dave Anderson
I'd like to take the opportunity to announce my retirement from
Red Hat, and from the workforce in general. My last day at Red Hat
will be May 29th, 2020.
Accordingly, I will be relinquishing my role as maintainer of the crash
utility. My replacement will be made up of three co-maintainers:
Kazuhito Hagio k-hagio-ab(a)nec.com
Lianbo Jiang lijiang(a)redhat.com
Bhupesh Sharma bhsharma(a)redhat.com
As you may be aware, Kazuhito will be performing double-duty, as he
is also the upstream maintainer of the makedumpfile facility; he has
been a significant contributor to the crash utility. Lianbo and Bhupesh
have both been working extensively in the kexec/kdump area, both in
the kernel and the user-space utilities.
Initially Kazuhito will primarily be handling upstream github duties,
while Lianbo and Bhupesh will be handling Fedora, CentOS stream, and
RHEL maintenance. All three will be involved in the acceptance of
patches posted on this mailing list. Please welcome them in their
new roles; I am confident they will do a terrific job.
Since the https://people.redhat.com/anderson web page will be
decommissioned after my departure, its contents have been moved
to be co-located with the crash-utility github site:
https://crash-utility.github.io
I want to express my appreciation to all of you who have contributed
patches, both bug fixes and new features, and most importantly, to the
support from users who have kept the crash utility alive for over 20 years
now. It has been my great pleasure to have had the chance to work with
such an extraordinary international cast of characters.
I will still be lurking as a regular subscriber to this list, at my
home address: anderson(a)prospeed.net
It will be fun to watch what happens...
Best wishes to all of you in these trying times,
Dave Anderson
4 years, 6 months
- 7
- 10
log -T option should not be support after system suspend
by 赵乾利
Hello,list
I notice a new option about "log -T",which translates the leading timestamp value of each message into human readable format.i have checked the code,the implementation mainly consists of two steps:
1.use "kt->boot_date.tv_sec=kt->date.tv_sec - uptime_sec" to get system bootup time,uptime_sec is come from jiffies
2.use "kt->boot_date.tv_sec + nanos" to translates readable timestamp in every log entry.
This change does not take into account the system sleep,once system suspend this translation will make error,printk timestamp and jiffies won't be update during suspend,and system suspend is a common feature,so i think change is a bug.
As far as i know we can’t get the correct conversion time once the system sleeps.so we have to restrict this option only work in non-suspend state.
patch is attached.
wrong log:
[Thu May 7 03:27:38 2020] PM: suspend entry 2020-05-06 19:22:40.481371186 UTC
[Thu May 7 03:27:38 2020] PM: suspend exit 2020-05-06 19:22:49.168938838 UTC
...
[Thu May 7 03:29:02 2020] PM: suspend entry 2020-05-06 19:28:54.366349876 UTC
[Thu May 7 03:29:03 2020] PM: suspend exit 2020-05-06 19:29:03.162471747 UTC
timestamp=utc+8
Thanks
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#
4 years, 6 months
- 3
- 3