[Crash-utility] [PATCH] add log -T option to display the message text with human readable timestamp

[Wang Long]

On 20/4/2020 11:28 pm, Dave Anderson wrote:
> 
> 
> ----- Original Message -----
>>
>>
>> On 20/4/2020 3:48 am, Dave Anderson wrote:
>>>
>>> FWIW, I tried it on another RHEL7 machine running live,
>>> but then also on a RHEL8 kernel dumpfile, and they all hang:
>>
>> I apply this patch on RHEL7 virtual machine(VirtualBbox) and it work ok.
>> and on a RHEL7 kernel dumpfile, I found it hang after I send the patch.
>>
>>
>> and I debug it and found the  machdep->hz == 0 on the following:
>>
>>             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;
>>
>> because machdep-> hz has not been initialized here.  divide by zero make
>> the cpu spinning at 100%.
>>
>> I thought two solutions:
>>
>> (1) add misc_init function after machdep_init(POST_INIT) call, and
>> calculate the value of kt-> boot_date in it.
>>                           read_in_kernel_config(IKCFG_INIT);
>>                           kernel_init();
>>                           machdep_init(POST_GDB);
>>                           vm_init();
>>                           machdep_init(POST_VM);
>>                           module_init();
>>                           help_init();
>>                           task_init();
>>                           vfs_init();
>>                           net_init();
>>                           dev_init();
>>                           machdep_init(POST_INIT);
>> +                       misc_init();
>>
>> (2) calculate the value of kt-> boot_date on cmd_log function, when we
>> call log command.
>>
>>
>> Dave, Which one do you like?
> 
> Definitely option #2.  Since it's not required unless your new command option is run,
> you can simply check whether the new boot_date structure is still zero-filled, and do
> your initialization at that time.
> 
> And BTW, please move the boot_date structure to the end of the kernel_table
> to prevent any possible breakage of previously-compiled extension modules
> that use the kernel_table.  And also can you please display the new structure's
> contents in dump_kernel_table()?  You can put the display under the current
> "date" display.
> 
OK, I will send the v2 patch.

Thanks
> Thanks,
>    Dave
> 
>