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
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
