7:33 a.m.
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!******/#
8:02 a.m.
赵乾利 wrote on Thu, May 07, 2020:
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.
This is how the regular unix command `dmesg -T` works, so I think it's
worth having as is: timestamp will be mostly correct until the first
sleep and then off by sleep amount.
This option isn't reliable anyway (drift depends on system but it's not
unusual to be off by a few minutes on most systems with more than a week
of uptime -- it drifts faster when cpu clock varies often), and it's not
like there's any harm in this.. At most print a warning that times after
sleep are wrong if you want to.
This is obviously just my opinion but I think for tools like crash, if a
user wants to shoot themselves in the foot, we should let them to... I'm
always annoyed when system tools know better and I need to waste time
patching them to bypass checks...
PS. Didn't want to send a mail "just" for it but thank you for all these
years Dave, hope you keep in touch a bit when you feel bored :)
And congratulation? to new maintainers!
--
Dominique
9:13 a.m.
----- Original Message -----
赵乾利 wrote on Thu, May 07, 2020:
> 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.
This is how the regular unix command `dmesg -T` works, so I think it's
worth having as is: timestamp will be mostly correct until the first
sleep and then off by sleep amount.
This option isn't reliable anyway (drift depends on system but it's not
unusual to be off by a few minutes on most systems with more than a week
of uptime -- it drifts faster when cpu clock varies often), and it's not
like there's any harm in this.. At most print a warning that times after
sleep are wrong if you want to.
This is obviously just my opinion but I think for tools like crash, if a
user wants to shoot themselves in the foot, we should let them to... I'm
always annoyed when system tools know better and I need to waste time
patching them to bypass checks...
I agree completely with Dominique. Your patch displays "log: -T option not
supported"
and bails out, which is arguably more misleading than just showing the timestamps.
The dmesg man page shows this:
-T, --ctime
Print human readable timestamps. The timestamp could be inaccurate!
The time source used for the logs is not updated after system
SUSPEND/RESUME.
This kind of warning could be added to the log command's help page, or could
be displayed as a preface to the dump of the log. Or things could be just left
as they are.
PS. Didn't want to send a mail "just" for it but thank you for all these
years Dave, hope you keep in touch a bit when you feel bored :)
And congratulation? to new maintainers!
--
Dominique
Thanks Dominique, I will still be watching the list from my personal email.
Dave
9:57 a.m.
New subject: [External Mail][营销邮件] Re: log -T option should not be support after system suspend
Okay, but this command really misled me ,mobile phone often suspend frequently,so this
timestamp often overy inaccurate…
It would be better if it could be prompted like “dmesg -T”
Thank you Dave
Enjoy your time of retirement~
________________________________________
From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com> on behalf
of Dave Anderson <anderson(a)redhat.com>
Sent: Thursday, May 7, 2020 22:13
To: Discussion list for crash utility usage, maintenance and development
Subject: [External Mail][营销邮件] Re: [Crash-utility] log -T option should not be support
after system suspend
----- Original Message -----
赵乾利 wrote on Thu, May 07, 2020:
> 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.
This is how the regular unix command `dmesg -T` works, so I think it's
worth having as is: timestamp will be mostly correct until the first
sleep and then off by sleep amount.
This option isn't reliable anyway (drift depends on system but it's not
unusual to be off by a few minutes on most systems with more than a week
of uptime -- it drifts faster when cpu clock varies often), and it's not
like there's any harm in this.. At most print a warning that times after
sleep are wrong if you want to.
This is obviously just my opinion but I think for tools like crash, if a
user wants to shoot themselves in the foot, we should let them to... I'm
always annoyed when system tools know better and I need to waste time
patching them to bypass checks...
I agree completely with Dominique. Your patch displays "log: -T option not
supported"
and bails out, which is arguably more misleading than just showing the timestamps.
The dmesg man page shows this:
-T, --ctime
Print human readable timestamps. The timestamp could be inaccurate!
The time source used for the logs is not updated after system
SUSPEND/RESUME.
This kind of warning could be added to the log command's help page, or could
be displayed as a preface to the dump of the log. Or things could be just left
as they are.
PS. Didn't want to send a mail "just" for it but thank you for all these
years Dave, hope you keep in touch a bit when you feel bored :)
And congratulation? to new maintainers!
--
Dominique
Thanks Dominique, I will still be watching the list from my personal email.
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!******/#
1516
days inactive
1516
days old
devel@lists.crash-utility.osci.io
3 comments
3 participants
participants (3)
-
Dave Anderson -
Dominique Martinet -
赵乾利