----- 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.

Thanks, Dave